cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Heron (App Definition and Development / Streaming & Messaging)
File: cluster-config-overview.md

id: version-0.20.0-incubating-cluster-config-overview title: Cluster Config Overview sidebar_label: Cluster Config Overview original_id: cluster-config-overview <!-- 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. --> Heron clusters can be configured at two levels: The system level System-level configurations apply to the whole Heron cluster rather than to any specific component (e.g. logging configurations). The component level Component-level configurations enable you to establish default configurations for different components. These configurations are fixed at any stage of the topology's , once the topology is deployed. Neither system- nor component-level configurations can be overridden by topology developers. All system-level configs and component-level defaults are declared in a config file in `heron/config/src/yaml/conf/{cluster}/heron_internals.yaml` in the Heron codebase. You can leave that file as is when [compiling Heron](compiling-overview) or modify the values to suit your use case. There are a small handful of system-level configs for Heron. These are detailed in . There is a wide variety of component-level configurations that you can establish as defaults in your Heron cluster. These configurations tend to apply to specific components in a topology and are detailed in the docs below: The Heron configuration applies globally to a cluster. It is discouraged to modify the configuration to suit one topology. It is not possible to override the Heron configuration for a topology via Heron client or other Heron tools. More on Heron's CLI tool can be found in [Managing Heron Topologies](user-manuals-heron-cli).
Project: KICS (Provisioning / Security & Compliance)
File: 9025b2b3-e554-4842-ba87-db7aeec36d35.md

title: Unscanned ECR Image hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 9025b2b3-e554-4842-ba87-db7aeec36d35 Query name: Unscanned ECR Image Platform: CloudFormation Severity: <span style="color:#edd57e">Low</span> Category: Observability URL: Checks if the ECR Image has been scanned<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="5" AWSTemplateFormatVersion: "2010-09-11" Resources: MyRepository3: Type: AWS::ECR::Repository Properties: RepositoryName: "test-repository" RepositoryPolicyText: Version: "2012-10-17" Statement: Sid: AllowPushPull Effect: Allow Principal: AWS: "arn:aws:iam::123456789012:user/Bob" "arn:aws:iam::123456789012:user/Alice" Action: "ecr:GetDownloadUrlForLayer" "ecr:BatchGetImage" "ecr:BatchCheckLayerAvailability" "ecr:PutImage" "ecr:InitiateLayerUpload" "ecr:UploadLayerPart" "ecr:CompleteLayerUpload" ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="8" AWSTemplateFormatVersion: "2010-09-11" Resources: MyRepository4: Type: AWS::ECR::Repository Properties: RepositoryName: "test-repository" ImageScanningConfiguration: ScanOnPush: "false" ``` ```json title="Positive test num. 3 - json file" hl_lines="6" { "AWSTemplateFormatVersion": "2010-09-09T00:00:00Z", "Resources": { "MyRepository5": { "Type": "AWS::ECR::Repository", "Properties": { "RepositoryName": "test-repository", "RepositoryPolicyText": { "Version": "2008-10-17", "Statement": [ { "Sid": "AllowPushPull", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/Bob", "arn:aws:iam::123456789012:user/Alice" ] }, "Action": [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability", "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload" ] } ] } } } } } ``` <details><summary>Positive test num. 4 - json file</summary> ```json hl_lines="9" { "AWSTemplateFormatVersion": "2010-09-11T00:00:00Z", "Resources": { "MyRepository6": { "Type": "AWS::ECR::Repository", "Properties": { "RepositoryName": "test-repository", "ImageScanningConfiguration": { "ScanOnPush": "false" } } } } } ``` </details> ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: "2010-09-11" Resources: MyRepository: Type: AWS::ECR::Repository Properties: RepositoryName: "test-repository" ImageScanningConfiguration: ScanOnPush: "true" ``` ```json title="Negative test num. 2 - json file" { "AWSTemplateFormatVersion": "2010-09-11T00:00:00Z", "Resources": { "MyRepository2": { "Type": "AWS::ECR::Repository", "Properties": { "RepositoryName": "test-repository", "ImageScanningConfiguration": { "ScanOnPush": "true" } } } } } ```
Project: Sonobuoy (Provisioning / Security & Compliance)
File: sonobuoy_delete.md

Deletes Kubernetes resources that were generated by a Sonobuoy run ``` sonobuoy delete [flags] ``` ``` --all In addition to deleting Sonobuoy namespaces, also clean up dangling e2e namespaces (those with 'e2e-framework' and 'e2e-run' labels). --context string Context in the kubeconfig to use. --dry-run If true, only print the image operations that would be performed. -h, --help help for delete --kubeconfig Kubeconfig Path to explicit kubeconfig file. -n, --namespace string The namespace to run Sonobuoy in. Only one Sonobuoy run can exist per namespace simultaneously. (default "sonobuoy") --rbac RBACMode Whether to enable RBAC on Sonobuoy. Valid modes are Enable, Disable, and Detect (query the server to see whether to enable RBAC). (default Detect) --wait int[=60] Wait for resources to be deleted before completing. 0 indicates do not wait. By providing --wait the default is to wait up to 1 hour. --wait-output string Specify the type of output Sonobuoy should produce when --wait is used. Valid modes are silent, spinner, or progress (default "Progress") ``` ``` --level level Log level. One of {panic, fatal, error, warn, info, debug, trace} (default info) ``` - Generate reports on your Kubernetes cluster by running plugins
Project: OpenFGA (Provisioning / Security & Compliance)
File: dependencies-policy.md

This policy describes how OpenFGA maintainers consume third-party packages. This policy applies to all OpenFGA maintainers and all third-party packages used in the OpenFGA project. OpenFGA maintainers must follow these guidelines when consuming third-party packages: Only use third-party packages that are necessary for the functionality of OpenFGA. Use the latest version of all third-party packages whenever possible. Do not ue using third-party packages that are known to have security vulnerabilities. Pin all third-party packages to specific versions in the OpenFGA codebase. Use a dependency management tool, such as Go modules, to manage third-party dependencies. Integrate with monitoring tools to ensure that third-party packages are up-to-date and do not have security vulnerabilities. When adding a new third-party package to OpenFGA, maintainers must follow these steps: Evaluate the need for the package. Is it necessary for the functionality of OpenFGA? Research the package. Is it well-maintained? Does it have a good reputation? Choose a version of the package. Use the latest version whenever possible. Pin the package to the specific version in the OpenFGA codebase. Update the OpenFGA documentation to reflect the new dependency. This policy is enforced by the OpenFGA maintainers. Maintainers are expected to review each other's code changes to ensure that they comply with this policy. Exceptions to this policy may be granted by the OpenFGA project lead on a case-by-case basis. This policy was adapted from the
Project: Beam (App Definition and Development / Streaming & Messaging)
File: tostring.md

title: "ToString" <!-- 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. --> {{< localstorage language language-py >}} {{< button-pydoc path="apache_beam.transforms.util" class="ToString" >}} Transforms every element in an input collection to a string. Any non-string element can be converted to a string using standard Python functions and methods. Many I/O transforms, such as , expect their input elements to be strings. The following example converts a `(key, value)` pair into a string delimited by `','`. You can specify a different delimiter using the `delimiter` argument. {{< playground height="700px" >}} {{< playgroundsnippet language="py" path="SDKPYTHONToStringKvs" show="tostringkvs" >}} {{< /playground >}} The following example converts a dictionary into a string. The string output will be equivalent to `str(element)`. {{< playground height="700px" >}} {{< playgroundsnippet language="py" path="SDKPYTHONToStringElement" show="tostringelement" >}} {{< /playground >}} The following example converts an iterable, in this case a list of strings, into a string delimited by `','`. You can specify a different delimiter using the `delimiter` argument. The string output will be equivalent to `iterable.join(delimiter)`. {{< playground height="700px" >}} {{< playgroundsnippet language="py" path="SDKPYTHONToStringIterables" show="tostringiterables" >}} {{< /playground >}} applies a simple 1-to-1 mapping function over each element in the collection {{< button-pydoc path="apache_beam.transforms.util" class="ToString" >}}
Project: RBAC Manager (Provisioning / Security & Compliance)
File: gke.md

Google Kubernetes Engine (GKE) takes a unique approach to auth. Google IAM users are automatically mapped to Kubernetes RBAC users. Unfortunately there is no mapping for IAM groups to RBAC groups with GKE at this point. The first time you configure RBAC on a GKE cluster, you may need to first grant yourself RBAC access. That can be accomplished with a command like this: ``` kubectl create clusterrolebinding initial-cluster-admin \ --clusterrole=cluster-admin \ --user=$(gcloud config get-value account) ``` Google IAM users are mapped to Kubernetes RBAC users with their email as the username. This is also the case for Google IAM Service accounts. That makes RBAC Bindings very straightforward: ```yaml apiVersion: rbacmanager.reactiveops.io/v1beta1 kind: RBACDefinition metadata: name: sample-config rbacBindings: name: web-developers subjects: kind: User name: jane@example.com kind: User name: joe@example.com roleBindings: clusterRole: edit namespace: web ``` Google Cloud IAM roles can provide fairly specific Kubernetes authorization configuration that overlaps with RBAC roles. This means that a user's access to a GKE cluster ends up being a union of both IAM and RBAC roles. This blog post provides more information on . If you're simply trying to see relevant GKE IAM and RBAC roles in one place, with that.
Project: Vald (App Definition and Development / Database)
File: template.md

<!-- introduction sentence --> `image-name` is the XXX for vald-XXX-YYY. The responsibility of this image is XXX. <!-- FIXME: document URL --> For more details, please refer to the . <div align="center"> <img src="https://github.com/vdaas/vald/blob/main/assets/image/readme.svg?raw=true" width="50%" /> </div> ](https://hub.docker.com/r/vdaas/vald-agent-ngt/tags?page=1&name=latest) ](https://opensource.org/licenses/Apache-2.0) ](https://github.com/vdaas/vald/releases/latest) ](https://twitter.com/vdaas_vald) <!-- FIXME: If image has some requirements, describe here with :warning: emoji --> CPU instruction: requires `AVX2` or `AVX512` RAM: XXX Image: XXX External components: S3 CPU instruction: requires `AVX2` or `AVX512` RAM: XXX Image: XXX External components: S3 This image does NOT support running on M1/M2 Mac. <!-- Get Started --> <!-- Vald Agent NGT requires more chapter Agent Standalone --> `image-name` is used for one of the components of the Vald cluster, which means it should be used on the Kubernetes cluster, not the local environment or Docker. Please refer to the for deploying the Vald cluster. | tag | linux/amd64 | linux/arm64 | description | | : | :: | :: | : | | latest | | | the latest image is the same as the latest version of repository version. | | nightly | | | the nightly applies the main branch's source code of the repository. | | vX.Y.Z | | | the vX.Y.Z image applies the source code of the repository. | | pr-XXX | | | the pr-XXX image applies the source code of the pull request XXX of the repository. | <!-- FIXME --> The `Dockerfile` of this image is . <!-- About Vald Project --> <!-- This chapter is static --> The information about the Vald project, please refer to the following: We're love to support you! Please feel free to contact us anytime with your questions or issue reports. This product is under the terms of the Apache License v2.0; refer file.
Project: YugabyteDB (App Definition and Development / Database)
File: yba_task_list.md

List YugabyteDB Anywhere tasks List YugabyteDB Anywhere tasks ``` yba task list [flags] ``` ``` --task-uuid string [Optional] UUID of the task. -h, --help help for list ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage YugabyteDB Anywhere tasks
Project: kube-bench (Provisioning / Security & Compliance)
File: index.md

][release] ][release] ][docker] ][report-card] ](https://github.com/aquasecurity/kube-bench/actions) ](https://github.com/aquasecurity/kube-bench/blob/main/LICENSE) ][cov] kube-bench is a Go application that checks whether Kubernetes is deployed securely by running the checks documented in the . Tests are configured with YAML files, making this tool easy to update as test specifications evolve. kube-bench implements the as closely as possible. Please raise issues here if kube-bench is not correctly implementing the test as described in the Benchmark. To report issues in the Benchmark itself (for example, tests that you believe are inappropriate), please join the . There is not a one-to-one mapping between releases of Kubernetes and releases of the CIS benchmark. See to see which releases of Kubernetes are covered by different releases of the benchmark. It is impossible to inspect the master nodes of managed clusters, e.g. GKE, EKS, AKS and ACK, using kube-bench as one does not have access to such nodes, although it is still possible to use kube-bench to check worker node configuration in these environments. For help and more information go to our
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.4.3.md

Important: If upgrading to this version using Helm instead of the Dapr CLI, you will need to update the Subscription CRD prior to performing the Helm upgrade. ```cli kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/v1.4.3/charts/dapr/crds/subscription.yaml ``` Subscription v1alpha1 applied in v2alpha1 (https://github.com/dapr/dapr/issues/3731) The Pub/Sub routing feature implemented in 1.4 introduced schema changes and therefore required a new version (`v2alpha1`) in the Subscriptions CRD. This was the first time a multi-version CRD was implemented in Dapr. When adding additional versions to a CRD, one version (typically the latest) must be marked as the storage version. In many cases, versions are added without schema changes to graduate features from alpha to beta or stable. However, the schema changes for Pub/Sub routing also required additional steps we were not fully aware of. The assumed behavior of the Kubernetes API was that each version would return confirming to its own schema. Instead, Kubernetes converts the payload to match the schema of the storage version. For subscriptions, this created an issue. `v1alpha1` subscriptions were being returned as `v2alpha1` with the `route` property being stripped out. The Pub/Sub routing feature included conversion logic that intended to handle this, but it was not exposed through a required conversion webhook. Without the webhook configured in the CRD, Kubernetes was unaware that a translation was required. This resulted in Dapr using an empty string as the route instead of the user's configured value. There are e2e tests that cover declarative/CRD subscriptions; however, the issue was not caught because the CRD topics were also subscribed to programmatically by the test apps. Even though Pub/Sub routing is a preview feature, the behavior of the Kubernetes API could not be protected by the feature flag. This ultimately allowed the regression to surface to users of 1.4. Users could work around this issue by temporarily adjusting their subscription CRDs to conform to the `v2valpha1` structure. This hotfix addresses the declarative subscription tests and configures the subscription CRD to use a conversion webhook to properly convert `v1alpha1` subscriptions to `v2alpha1`. The Helm chart was extended to create a CA and TLS certificate for future webhooks. Webhooks are served by the dapr operator. On startup, the operator patches the subscription CRD to set the `namespace` and `caBundle` fields of the webhook client configuration.
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno_fix_policy.md

Fix inconsistencies and deprecated usage in Kyverno policy files. Fix inconsistencies and deprecated usage in Kyverno policy files. NOTE: This is an experimental command, use `KYVERNO_EXPERIMENTAL=true` to enable it. ``` kyverno fix policy [dir]... [flags] ``` ``` KYVERNO_EXPERIMENTAL=true kyverno fix policy . KYVERNO_EXPERIMENTAL=true kyverno fix policy . --save ``` ``` -h, --help help for policy --save Save fixed file ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Fix inconsistencies and deprecated usage of Kyverno resources.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.45.md

layout: release date: 2023-01-21 tag: v0.6.45 language: en Write SVG on UI file system @Revolyssup (#6769) Add XML tag on SVGs in component updation @Revolyssup (#6901) Add `isNamespaced` in Meshmodel component metadata @Revolyssup (#6912) Add model field in Application generated design @Revolyssup (#6913) [mesheryctl] Added Meshconfig support for provider enforcement @abdullah1308 (#6644) refactor the code for redirecting to playground @Abhishek-kumar09 (#6916) Fix SVG problems in Meshery-UI @Abhishek-kumar09 (#6690) [bug] Fix empty component registration @theBeginner86 (#6917) [Docs] Added token on discussion file update workflow @asubedy (#6909) Add updated_after query parameter @Revolyssup (#6918) Updating Meshery Broker and MeshSync [Docs] @sassukeuchiha (#6910) Update navigation bar [Docs] @sassukeuchiha (#6906) [mesheryctl] Added Meshconfig support for provider enforcement @abdullah1308 (#6644) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Revolyssup, @UtkarshMishra12, @abdullah1308, @alphaX86, @asubedy, @leecalcote, @sassukeuchiha and @theBeginner86
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: FAQ.md

The short story is that there are two main reasons: Currently there is no way how VMs can be launched in a parametrized way, and the second reason is that Kubernetes is built around the assumption of cloud workloads. This assumption is contradicting the assumptions we have on pet VMs. KubeVirt is looking for a solution to manage VMs. This includes both ends: VMs as they are used in the cloud, thus with few tunables, but also pet VMs like they are used in traditional data-center virtualization, which expose a lot more tunables. Especially the pet case requires the exposure of many tunables, and this can currently not be established with CRI - in a scalable way. (I.e. it could be raised that annotations could be used to set VM parameters, but to us this is rather a workaround than a solution). Besides that Kubernetes is built around the assumptions of containers and cloud workloads. And it's difficult to bend Kubernetes to also handle or support assumptions on which pet VMs are based. Currently we are only supporting x86-64. In general we aim to be OS independent by shipping all dependencies in containers (i.e. libvirtd). But in case that you have issues, please . allow you to run containers inside virtual machines. KubeVirt allows you to run full virtual machines on Kubernetes alongside regular containers. One could say they're opposites: Kata containers are containers inside virtual machines. KubeVirt is a virtual machine inside a container. We want to, please open an and we'll try to answer and consider to add it to this FAQ.