cwielenb/CNCF-Dataset huggingface dataset:
Project: Vald (App Definition and Development / Database)
File: contacts.md

Welcome to the Vald project!! Vald is an open source project and we would like to hear from you. If you are interested in Vald, or you have any questions about Vald, please feel free to contact us. We recommend communicating on slack, but using E-mail is also welcome. Slack: E-mail: We are waiting for your contact.
Project: Meshery (Provisioning / Automation & Configuration)
File: 10-31-2023-04-09-10_d2f1b165.md

timestamp: "2023-10-31 04:09:26 UTC Tue" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "*name" k8s-distro: minikube k8s-version: "v1.25.2" service-mesh: Consul service-mesh-version: "v1.2.2" tests: consul-client: null consul-server: null overall-status: "failing"
Project: Trivy (Provisioning / Security & Compliance)
File: trivy_plugin_install.md

Install a plugin ``` trivy plugin install NAME | URL | FILE_PATH ``` ``` $ trivy plugin install referrer $ trivy plugin install referrer@v0.3.0 $ trivy plugin install github.com/aquasecurity/trivy-plugin-referrer ``` ``` -h, --help help for install ``` ``` --cache-dir string cache directory (default "/path/to/cache") -c, --config string config path (default "trivy.yaml") -d, --debug debug mode --generate-default-config write the default config to trivy-default.yaml --insecure allow insecure server connections -q, --quiet suppress progress bar and log output --timeout duration timeout (default 5m0s) -v, --version show version ``` - Manage plugins
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.1.2.md

Improvements to Asure Service Bus component behavior under throttling (https://github.com/dapr/dapr/issues/3047) If you are not using the Azure Service Bus pubsub component, you do not need to upgrade to 1.1.2. If you are using this component, please read on. We received a report of excess errors under load when publishing messages to the Azure Service Bus. With some investigation and a successful reproduction, we determined that if the upstream Azure Service Bus throttles a request, the upstream Azure Service Bus client go library would close the connection and any outstanding publish operations will fail with an error. Workloads with publication bursts on the order of thousands of messages per second can trigger rate limiting in the upstream service and thus experience failed publish attempts. This patch release address this condition in two ways: The Azure Service Bus pubsub component will now retry with exponential backoff by default. This allows bursty traffic a chance to recover a deliver successfully during the next rate limit window. While diagnosing this issue, we also discovered an exteraneous API call being made in line with every publish request. This API call counts towards the total upstream service throttling limit, so removing it allows Dapr users to publish more messages before hitting the throttling limit. Big thanks to @javageek79 for bringing this to our attention, and to @pkedy for root cause analysis and patch.
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.9.3.md

RabbitMQ `3.9.3` is a maintenance release in the `3.9.x` release series that addresses a regression introduced in `3.9.0`. All users are recommended to upgrade to this release. . Please refer to the Upgrading to 3.9 section from if you are upgrading from a version prior to 3.9.0. This release requires at least Erlang 23.2, and supports the latest Erlang 24 version, 24.0.5 at the time of release. has more details on Erlang version requirements for RabbitMQ. Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and more consistent release schedule. Queues that had messages with per-message TTL in them could fail to recover their indices after a restart. GitHub issues: , JSON logging could fail with an exception when a logged event included epoch-based timestamp value. GitHub issue: JSON logging now uses integers (as opposed to floats) to represent epoch-based timestamps GitHub issue: RabbitMQ application no longer reports the `stopping` event to systemd. This was counterproductive when the application was stopped but the runtime (Erlang VM) was kept running, e.g. via `rabbitmqctl stop_app` or by the pause minority partition handling strategy. Now systemd service monitoring will recognize a node as stopped only when the runtime is stopped, which is usually the behavior operators expect. GitHub issues: , No dependency changes in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.9.3.tar.xz` instead of the source tarball produced by GitHub.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_node_template.md

+++ title = "googlecomputenode_template resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputenode_template" identifier = "inspec/resources/gcp/googlecomputenodetemplate.md googlecomputenodetemplate resource" parent = "inspec/resources/gcp" +++ A `googlecomputenode_template` is used to test a Google NodeTemplate resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputenode_template(project: 'chef-gcp-inspec', region: 'europe-west2', name: 'inspec-node-template') do it { should exist } its('nodeaffinitylabels') { should include('key' => 'value') } end describe googlecomputenode_template(project: 'chef-gcp-inspec', region: 'europe-west2', name: 'nonexistent') do it { should_not exist } end ``` Properties that can be accessed from the `googlecomputenode_template` resource: `creation_timestamp` : Creation timestamp in RFC3339 text format. `description` : An optional textual description of the resource. `name` : Name of the resource. `nodeaffinitylabels` : Labels to use for node affinity, which will be used in instance scheduling. `node_type` : Node type to use for nodes group that are created from this template. Only one of nodeTypeFlexibility and nodeType can be specified. `nodetypeflexibility` : Flexible properties for the desired node type. Node groups that use this node template will create nodes of a type that matches these properties. Only one of nodeTypeFlexibility and nodeType can be specified. `cpus` : Number of virtual CPUs to use. `memory` : Physical memory available to the node, defined in MB. `local_ssd` : Use local SSD `server_binding` : (Beta only) The server binding policy for nodes using this template. Determines where the nodes should restart following a maintenance event. `type` : Type of server binding policy. If `RESTARTNODEONANYSERVER`, nodes using this template will restart on any physical server following a maintenance event. If `RESTARTNODEONMINIMALSERVER`, nodes using this template will restart on the same physical server following a maintenance event, instead of being live migrated to or restarted on a new physical server. This option may be useful if you are using software licenses tied to the underlying server characteristics such as physical sockets or cores, to avoid the need for additional licenses when maintenance occurs. However, VMs on such nodes will experience outages while maintenance is applied. Possible values: RESTARTNODEONANYSERVER RESTARTNODEONMINIMALSERVERS `region` : Region where nodes using the node template will be created Ensure the is enabled for the current project.
Project: YugabyteDB (App Definition and Development / Database)
File: connections.md

title: Connection metrics headerTitle: Connections linkTitle: Connection metrics headcontent: Monitor YSQL connections description: Learn about YugabyteDB's connection metrics, and how to select and use the metrics. menu: v2.18: identifier: connections parent: metrics-overview weight: 110 type: docs Connection metrics represent the cumulative number of connections to the YSQL backend per node. This includes various background connections, such as checkpointer, active connections count that only includes the client backend connections, newly established connections, and connections rejected over the maximum connection limit. Connection metrics are only available in Prometheus format. The following table describes key connection metrics. All units are in number of connections. | Metric | Type | Description | | :-- | : | :- | | `ybysqlserveractiveconnectiontotal` | gauge | The number of active client backend connections to YSQL server. If a client connection is executing a statement, it is considered an active connection. Any client connection not executing a statement is considered an idle connection.| | `ybysqlserverconnection_total` | gauge | The total number of all connections to YSQL, which includes active connections, idle connections, and background connections. | | `ybysqlservermaxconnectiontotal` | gauge | The maximum number of concurrent connections that a YSQL server can support at any given time. The default is 300. This value can be changed using the `--ysqlmaxconnections` YB-TServer flag. | | `ybysqlserverconnectionoverlimittotal` | counter | The number of connection requests rejected by the YSQL server over the maximum connection limit, based on `ybysqlservermaxconnection_total`. | | `ybysqlservernewconnectiontotal` | counter | The total number of connections established with the YSQL server since the start of the process. | These metrics can be aggregated across the entire cluster using appropriate aggregations.
Project: Checkov (Provisioning / Security & Compliance)
File: Contribute New Argo Workflows Policies.md

layout: default published: true title: Contribute New Argo Workflows configuration policy nav_order: 5 In this example, we'll add support for a new Argo Workflows configuration check to validate the usage of a user defined ServiceAccount. Go to `checkov/argo_workflows/checks/template` and add `DefaultServiceAccount.py`: ```python from future import annotations from typing import Any from checkov.argoworkflows.checks.baseargoworkflowscheck import BaseArgoWorkflowsCheck from checkov.common.models.enums import CheckResult, CheckCategories from checkov.yaml_doc.enums import BlockType class DefaultServiceAccount(BaseArgoWorkflowsCheck): def init(self) -> None: name = "Ensure Workflow pods are not using the default ServiceAccount" id = "CKVARGO1" super().init( name=name, id=id, categories=(CheckCategories.IAM,), supported_entities=("spec",), block_type=BlockType.OBJECT, ) def scan_conf(self, conf: dict[str, Any]) -> tuple[CheckResult, dict[str, Any]]: if "serviceAccountName" in conf.keys() and conf["serviceAccountName"] != "default": return CheckResult.PASSED, conf return CheckResult.FAILED, conf check = DefaultServiceAccount() ``` Create a new folder under `tests/argoworkflows/checks/template` with the name of your check `exampleDefaultServiceAccount` for adding example configuration files. Try to add at least 2 test cases, one passing and one failing. `pass.yaml`: ```yaml apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: hello-world- spec: serviceAccountName: custom-sa entrypoint: whalesay templates: name: whalesay container: image: docker/whalesay:latest command: [cowsay] args: ["hello world"] ``` Lastly add the test file `test_DefaultServiceAccount.py` to scan the example files. ```python from pathlib import Path from checkov.argo_workflows.runner import Runner from checkov.argo_workflows.checks.template.DefaultServiceAccount import check from checkov.runner_filter import RunnerFilter def test_examples(): testfilesdir = Path(file).parent / "example_DefaultServiceAccount" report = Runner().run(rootfolder=str(testfilesdir), runnerfilter=RunnerFilter(checks=[check.id])) summary = report.get_summary() passing_resources = { f"{testfilesdir}/pass.yaml.spec.spec.CKVARGO1[6:14]", } failing_resources = { f"{testfilesdir}/faildefault.yaml.spec.spec.CKVARGO_1[6:14]", f"{testfilesdir}/failnone.yaml.spec.spec.CKVARGO_1[6:13]", } passedcheckresources = {c.resource for c in report.passed_checks} failedcheckresources = {c.resource for c in report.failed_checks} assert summary["passed"] == len(passing_resources) assert summary["failed"] == len(failing_resources) assert summary["skipped"] == 0 assert summary["parsing_errors"] == 0 assert passedcheckresources == passing_resources assert failedcheckresources == failing_resources ``` So there you have it! A new check will be scanned once your contribution is merged!
Project: Beam (App Definition and Development / Streaming & Messaging)
File: Commands.md

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> The following commands are available for interaction with the PR Bot All commands are case insensitive. | Command | Description | | -- | -- | | `r: @username` | Ask someone for a review. This will disable the bot for the PR since it assumes you are able to find a reviewer. | | `assign to next reviewer` | If someone has been assigned to a PR by the bot, this unassigns them and picks a new reviewer. Useful if you don't have the bandwitdth or context to review. | | `stop reviewer notifications` | This will disable the bot for the PR. | | `remind me after tests pass` | This will comment after all checks complete and tag the person who commented the command. | | `waiting on author` | This shifts the attention set to the author. The author can shift the attention set back to the reviewer by commenting anywhere or pushing. | | `assign set of reviewers` | If the bot has not yet assigned a set of reviewers to the PR, this command will trigger that happening. |
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.7.22.md

RabbitMQ `3.7.22` is a maintenance release that focuses on bug fixes. RabbitMQ `3.7.x` series is supported . Per the new Erlang version support policy in effect starting with January 2019, this release . Make sure a is used before upgrading. explains what package repositories and tools can be used to provision latest patch versions of Erlang `21.3.x` and `22.x`. When upgrading to this release and upgrading Erlang to 21.x or later at the same time, extra care has to be taken. Since CLI tools from RabbitMQ releases older than 3.7.7 will fail on Erlang 21 or later, RabbitMQ must be upgraded before Erlang. See upgrade and compatibility notes first if upgrading from an earlier release. See the for general documentation on upgrades and for release notes of other releases. Any questions about this release, upgrades or RabbitMQ in general are welcome on the . One-off Erlang VM starts used by startup scripts now do as little work as possible in order to avoid starting subcomponents, loading configuration and so on. GitHub issue: `rabbitmqctl await_startup` failed with an exception when RabbitMQ application was stopped but the runtime (Erlang VM) was running. GitHub issue: Definition import via HTTP API could fail in if performed via HTTP API (but not management UI) and contained operator policies. GitHub issue: When a node cannot compute the number of file descriptors it uses, it will be more resilient and will log warnings (e.g. about missing `handle.exe` in `PATH` on Windows) much more proactively. GitHub issue: Metric aggregation optimizations. GitHub issue: Throughput improvements and reduced CPU usage but slightly higher per connection RAM footprint. Contributed by Grigory Starinkin (Erlang Solutions). GitHub issues: , Last Will messages that use QoS 2 will now be downgraded to QoS 1 just like with "regular" published messages. GitHub issue: Warning: The source code archive provided by GitHub only contains the source of the broker, not the plugins or the client libraries. Please download the archive named `rabbitmq-server-3.7.22.tar.xz`.
Project: KubeEdge (Provisioning / Automation & Configuration)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: KICS (Provisioning / Security & Compliance)
File: 72ceb736-0aee-43ea-a191-3a69ab135681.md

title: No ROS Stack Policy hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 72ceb736-0aee-43ea-a191-3a69ab135681 Query name: No ROS Stack Policy Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Resource Management URL: ROS Stack should have a stack policy in order to protect stack resources from and during update actions<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "alicloudrosstack" "pos" { stack_name = "tf-testaccstack" template_body = <<EOF { "ROSTemplateFormatVersion": "2015-09-01" } EOF } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" resource "alicloudrosstack" "pos2" { stack_name = "tf-testaccstack" template_body = <<EOF { "ROSTemplateFormatVersion": "2015-09-01" } EOF stackpolicybody = <<EOF { "Statement": [{ "Action": "Update:Delete", "Resource": "*", "Effect": "Allow", "Principal": "*" }] } EOF } ``` ```tf title="Positive test num. 3 - tf file" hl_lines="1" resource "alicloudrosstack" "pos3" { stack_name = "tf-testaccstack" template_body = <<EOF { "ROSTemplateFormatVersion": "2015-09-01" } EOF stackpolicyduringupdatebody = <<EOF { "Statement": [{ "Action": "Update:Delete", "Resource": "*", "Effect": "Allow", "Principal": "*" }] } EOF } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudrosstack" "neg1" { stack_name = "tf-testaccstack" template_body = <<EOF { "ROSTemplateFormatVersion": "2015-09-01" } EOF stackpolicybody = <<EOF { "Statement": [{ "Action": "Update:Delete", "Resource": "*", "Effect": "Allow", "Principal": "*" }] } EOF stackpolicyduringupdatebody = <<EOF { "Statement": [{ "Action": "Update:Delete", "Resource": "*", "Effect": "Allow", "Principal": "*" }] } EOF } ``` ```tf title="Negative test num. 2 - tf file" resource "alicloudrosstack" "neg2" { stack_name = "tf-testaccstack" template_body = <<EOF { "ROSTemplateFormatVersion": "2015-09-01" } EOF stackpolicyurl = "oss://ros/stack-policy/demo" stackpolicyduringupdatebody = "oss://ros/stack-policy/demo" } ```
Project: Apache Hadoop (App Definition and Development / Database)
File: UsingHttpTools.md

<! Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. See accompanying LICENSE file. --> Hadoop HDFS over HTTP - Using HTTP Tools ======================================== Security -- Out of the box HttpFS supports both pseudo authentication and Kerberos HTTP SPNEGO authentication. With pseudo authentication the user name must be specified in the `user.name=<USERNAME>` query string parameter of a HttpFS URL. For example: $ curl "http://<HTTFS_HOST>:14000/webhdfs/v1?op=homedir&user.name=babu" Kerberos HTTP SPNEGO authentication requires a tool or library supporting Kerberos HTTP SPNEGO protocol. IMPORTANT: If using `curl`, the `curl` version being used must support GSS (`curl -V` prints out 'GSS' if it supports it). For example: $ kinit Please enter the password for user@LOCALHOST: $ curl --negotiate -u foo "http://<HTTPFS_HOST>:14000/webhdfs/v1?op=homedir" Enter host password for user 'foo': NOTE: the `-u USER` option is required by the `--negotiate` but it is not used. Use any value as `USER` and when asked for the password press [ENTER] as the password value is ignored. As most authentication mechanisms, Hadoop HTTP authentication authenticates users once and issues a short-lived authentication token to be presented in subsequent requests. This authentication token is a signed HTTP Cookie. When using tools like `curl`, the authentication token must be stored on the first request doing authentication, and submitted in subsequent requests. To do this with curl the `-b` and `-c` options to save and send HTTP Cookies must be used. For example, the first request doing authentication should save the received HTTP Cookies. Using Pseudo Authentication: $ curl -c ~/.httpfsauth "http://<HTTPFS_HOST>:14000/webhdfs/v1?op=homedir&user.name=foo" Using Kerberos HTTP SPNEGO authentication: $ curl --negotiate -u foo -c ~/.httpfsauth "http://<HTTPFS_HOST>:14000/webhdfs/v1?op=homedir" Then, subsequent requests forward the previously received HTTP Cookie: $ curl -b ~/.httpfsauth "http://<HTTPFS_HOST>:14000/webhdfs/v1?op=liststatus"
Project: Chef InSpec (Provisioning / Security & Compliance)
File: gcp.md

+++ title = "Chef InSpec and GCP" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "GCP" identifier = "inspec/cloud/gcp" parent = "inspec/cloud" +++ Chef InSpec has resources for auditing GCP. With Chef InSpec 4 or greater, you can create a profile for testing GCP resources with `inspec init profile`: ```bash $ inspec init profile --platform gcp my-profile Create new profile at /Users/me/my-profile Creating directory libraries Creating file README.md Creating directory controls Creating file controls/example.rb Creating file inspec.yml Creating file inputs.yml Creating file libraries/.gitkeep ``` Assuming the `inputs.yml` file contains your GCP project ID, this sample profile can then be executed using the following command: ```bash inspec exec my-profile --input-file=my-profile/inputs.yml -t gcp:// ``` To use Chef InSpec GCP resources, you will need to install and configure the Google Cloud SDK. Instructions for this pre-requisite can be found in the . While InSpec can use user accounts for authentication, recommends using service accounts. Create a with the scopes appropriate for your needs. Download the credential JSON file, for example `project-credentials.json`, to your workspace and activate your service account with `gcloud auth activate-service-account`. ```bash gcloud auth activate-service-account --key-file project-credentials.json ``` You may also set the GCP credentials json file via the `GOOGLEAPPLICATIONCREDENTIALS` environment variable. ```bash export GOOGLEAPPLICATIONCREDENTIALS='/Users/me/.config/gcloud/myproject-1-feb7993e8660.json' ``` Once you have your environment variables set, you can verify your credentials by running: ```bash $ inspec detect -t gcp:// == Platform Details Name: gcp Families: cloud, api Release: google-cloud-v ``` {{< inspec/inspec_resources platform="gcp" >}}