cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: cb8e4bf0-903d-45c6-a278-9a947d82a27b.md

title: Storage Account Not Forcing HTTPS hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: cb8e4bf0-903d-45c6-a278-9a947d82a27b Query name: Storage Account Not Forcing HTTPS Platform: Pulumi Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: Storage Accounts should enforce the use of HTTPS<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="9" name: azure-aks runtime: yaml description: An Aks cluster resources: storageAccount: type: azure-native:storage:StorageAccount properties: accountName: sto4445 enableHttpsTrafficOnly: false enableNfsV3: true isHnsEnabled: true kind: BlockBlobStorage location: eastus networkRuleSet: bypass: AzureServices defaultAction: Allow ipRules: [] virtualNetworkRules: virtualNetworkResourceId: /subscriptions/{subscription-id}/resourceGroups/res9101/providers/Microsoft.Network/virtualNetworks/net123/subnets/subnet12 resourceGroupName: res9101 sku: name: Premium_LRS ``` ```yaml title="Negative test num. 1 - yaml file" name: azure-aks runtime: yaml description: An Aks cluster resources: storageAccount: type: azure-native:storage:StorageAccount properties: accountName: sto4445 enableHttpsTrafficOnly: true enableNfsV3: true isHnsEnabled: true kind: BlockBlobStorage location: eastus networkRuleSet: bypass: AzureServices defaultAction: Allow ipRules: [] virtualNetworkRules: virtualNetworkResourceId: /subscriptions/{subscription-id}/resourceGroups/res9101/providers/Microsoft.Network/virtualNetworks/net123/subnets/subnet12 resourceGroupName: res9101 sku: name: Premium_LRS ```
Project: YugabyteDB (App Definition and Development / Database)
File: cutover.md

title: cutover reference headcontent: yb-voyager cutover linkTitle: cutover description: YugabyteDB Voyager cutover reference menu: preview_yugabyte-voyager: identifier: voyager-cutover-initiate parent: cutover-archive weight: 110 type: docs rightNav: hideH4: true The following page describes the following cutover commands: Initiate to the target YugabyteDB database. ```text Usage: yb-voyager initiate cutover to target [ <arguments> ... ] ``` The valid arguments for initiate cutover to target are described in the following table: | Argument | Description/valid options | | :- | : | | -e, --export-dir | Path to the export directory. This directory is a workspace used to store exported schema DDL files, export data files, migration state, and a log file.| | -h, --help | Command line help for initiate cutover to target. | | &#8209;&#8209;prepare&#8209;for&#8209;fall&#8209;back | Prepare for fall-back by streaming changes from the target YugabyteDB database to the source database. Not applicable to the fall-forward workflow.<br> Accepted parameters: true, false, yes, no, 0, 1 | ```sh yb-voyager initiate cutover to target --export-dir /dir/export-dir --prepare-for-fall-back false ``` Initiate a to the source database. ```text Usage: yb-voyager initiate cutover to source [ <arguments> ... ] ``` The valid arguments for initiate cutover to source are described in the following table: | Argument | Description/valid options | | :- | : | | -e, &#8209;&#8209;export&#8209;dir | Path to the export directory. This directory is a workspace used to store exported schema DDL files, export data files, migration state, and a log file.| | -h, --help | Command line help for cutover. | ```sh yb-voyager initiate cutover to source --export-dir /path/to/yb/export/dir ``` Initiate a to the source-replica database. ```text Usage: yb-voyager initiate cutover to source-replica [ <arguments> ... ] ``` The valid arguments for initiate cutover to source-replica are described in the following table: | Argument | Description/valid options | | :- | : | | -e, &#8209;&#8209;export&#8209;dir | Path to the export directory. This directory is a workspace used to store exported schema DDL files, export data files, migration state, and a log file.| | -h, --help | Command line help for cutover. | ```sh yb-voyager initiate cutover to source-replica --export-dir /path/to/yb/export/dir ``` Shows the status of the cutover process, whether it is , , or . Status can be INITIATED, NOT INITIATED, or COMPLETED. ```text Usage: yb-voyager cutover status [ <arguments> ... ] ``` The valid arguments for cutover status are described in the following table: | Argument | Description/valid options | | :- | : | | -e, &#8209;&#8209;export&#8209;dir | Path to the export directory. This directory is a workspace used to store exported schema DDL files, export data files, migration state, and a log file.| | -h, --help | Command line help for cutover status. | ```sh yb-voyager cutover status --export-dir /dir/export-dir ```
Project: Carvel (App Definition and Development / Application Definition & Image Build)
File: bug-report.md

name: Bug report about: Tell us about a problem you are experiencing title: '' labels: bug, carvel triage assignees: '' What steps did you take: [A clear and concise description steps and yaml files that can be used to reproduce the problem.] What happened: [A small description of the result or the yaml that was generated] What did you expect: [A description of what was expected and the yaml that should have been generated] Anything else you would like to add: [Additional information that will assist in solving the issue.] Environment: ytt version (use `ytt --version`): OS (e.g. from `/etc/os-release`): Vote on this request This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote. "I would like to see this addressed as soon as possible" "There are other more important things to focus on right now" We are also happy to receive and review Pull Requests if you want to help working on this issue.
Project: Keycloak (Provisioning / Security & Compliance)
File: PR-CHECKLIST.md

Before merging a PR the PR should follow these rules: The PR does not have the label "hold" There is an associated GitHub Issue linked to the PR A GitHub Issue is not required if the PR is not introducing a new feature or enhancement to Keycloak, or is resolving a bug where released versions of Keycloak are not affected There is sufficient test coverage Required documentation is included in the PR or an associated PR. Including updates to release notes and upgrade guide if applicable There are no unresolved negative reviews, or unresolved comments The PR does not contain changes not relevant to the GitHub Issue PRs has been reviewed by the relevant team, and approved by either a global maintainer or a team maintainer All required status checks have passed successfully If the PR is affected by unstable workflows or tests verify the issues are not introduced by the PR Merging a PR: In most cases a PR should be merged by a team maintainer in the affected area Global maintainers can merge any PRs, but this is considered a fallback If a PR affects multiple areas it can be merged by any of the affected team maintainers as long as someone from each affected team has completed a review.
Project: Trivy-Operator (Provisioning / Security & Compliance)
File: pull_request_template.md

Close #XXX Remove this section if you don't have related PRs. to this repository. [ ] I've added tests that prove my fix is effective or that my feature works. with the relevant information (if needed). [ ] I've added usage information (if the PR introduces new options) [ ] I've included a "before" and "after" example to the description (if the PR is a user interface change).
Project: Harbor (Provisioning / Container Registry)
File: 10-04-Clair-data-not-ready-hint.md

Test 10-04 Trivy data not ready hint ======= To verify there will be a hint if vulnerability data is not ready. User guide This test requires that a Harbor instance is running and available. Harbor is installed with trivy enable. A linux host with Docker CLI installed. Limit the Harbor's bandwidth to less than 1Mbps after Harbor is installed. NOTE:This test need to be done as soon as possible after Harbor is installed Login Harbor as admin. Go into project page. Go to configuration. Click vulnerability. Step2 should see Vulnerability database might not be fully ready hint. Step4 should see a warning symbol with Vulnerability database might not be fully ready hint. None
Project: Dragonfly (Provisioning / Container Registry)
File: dfstore_remove.md

% DFCACHE(1) Version v2.1.0 | Frivolous "Dfstore" Documentation dfstore rm remove object from P2P storage system Remove object from P2P storage system. ```shell dfstore rm <target> [flags] ``` ```shell -h, --help help for rm -e, --endpoint string endpoint of object storage service (default "http://127.0.0.1:65004") ``` - object storage client of dragonfly
Project: GraphScope (App Definition and Development / Database)
File: user_guide_and_examples_of_gae.md

In , we have introduced how to run built-in algorithms with Python. In many cases, users need to use different programming languages, or customize their own graph analytics algorithms. To this end, GraphScope has provided various mechanisms to satisfy such demands. Users may write their own algorithms if the built-in algorithms do not meet their needs. GraphScope enables users to write algorithms in the in a pure Python mode. In addition to the sub-graph based PIE model, GraphScope supports vertex-centric Pregel model as well. Please refer to for more details. GraphScope also allows users to develop their algorithms in C++. Specially, GraphScope provides a C++ SDK and users can develop their own algorithms with the PIE programming model. In each customized algorithms, users only need to three functions: the Init is a function to set the initial status; PEval is a sequential method for partial evaluation; and IncEval is a sequential function for incremental evaluation over the partitioned fragment. The full tutorials can be found in . Java plays an important role in big data ecosystem, and a lot of graph processing systems developed by Java (e.g., Apache Giraph and GraphX) have been widely applied. To integrate with Java ecosystem, GraphScope allows graph analytics algorithms developed for Apache Giraph and GraphX to directly run over GraphScope GAE. In addition, GraphScope GAE supports the PIE programming model, which can provide better performance than widely-used vertex-centric model. GraphScope GAE is equipped with `Java PIE` interface exposed by `GRAPE-jdk`, and users can develop their own algorithms using the PIE programming model. The following tutorials will introduce how to leverage the above features in GraphScope GAE Java SDK.
Project: YugabyteDB (App Definition and Development / Database)
File: type_binary.md

title: Binary data types [YSQL] headerTitle: Binary data types linkTitle: Binary summary: Binary data types description: Use the BYTEA data type to represent binary string of bytes (octets). menu: v2.18: identifier: api-ysql-datatypes-binary parent: api-ysql-datatypes type: docs Use the `BYTEA` data type to represent binary string of bytes (octets). Binary strings allow zeros (`0`) and non-printable bytes. Data type | Description | -|-| BYTEA | Variable length binary string | `BYTEA` is used to declare a binary entity. ``` type_specification ::= BYTEA ``` Escaped input can be used for input binary data. ``` SELECT E'\\001'::bytea ```
Project: FOSSA (Provisioning / Security & Compliance)
File: projectassetsjson.md

The `project.assets.json` file is used in `.NET Core` projects to manage dependencies and other resources Walk the directory and find all files names `project.assets.json` Note, `fossa-cli` expects that the project is compiled, and built prior to using `fossa analyze` command. Parse the JSON file, and construct a full dependency graph (direct and transitive dependencies). From the `project.assets.json`, `fossa-cli` uses: `targets`: To infer edges between dependencies of a framework. `project`: To infer which dependencies are direct dependencies for the target framework. For example, ```json { "version": 1, "targets": { ".NETFramework,Version=v4.0": { "one/1.0.0": { // Dependency Name and Version "type": "package", "dependencies": { "three": "3.0.0" } }, "three/3.0.0": { "type": "package" }, } }, "project": { "frameworks": { "net4.0": { "targetAlias": "net4.0", "dependencies": { "one": {}, // Direct Dependency } } } } } ``` Key heading under `targets.$frameworkName` are used to infer resolved dependency. For instance `one/1.0.0` will be inferred as a dependency with name of `one` and version of `1.0.0`. For each dependency, all entries under `dependencies` will form edges. From the previous example, `fossa-cli` will infer edge from dependency `one` to dependency `three`. Dependencies listed under `project.$frameworkName` are used to infer if the dependency is direct or not. From aforementioned example, `one` will be considered a direct dependency. Any dependency of type `"project"` will be ignored from the analysis.
Project: KICS (Provisioning / Security & Compliance)
File: f4a6bcd3-e231-4acf-993c-aa027be50d2e.md

title: RUN Instruction Using 'cd' Instead of WORKDIR hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: f4a6bcd3-e231-4acf-993c-aa027be50d2e Query name: RUN Instruction Using 'cd' Instead of WORKDIR Platform: Dockerfile Severity: <span style="color:#edd57e">Low</span> Category: Build Process URL: When using RUN command 'cd' should only be used for full path. For relative path make use of WORKDIR command instead.<br> ```dockerfile title="Positive test num. 1 - dockerfile file" hl_lines="9 3 15" FROM nginx ENV AUTHOR=Docker RUN cd /../share/nginx/html COPY Hello_docker.html /usr/share/nginx/html CMD cd /usr/share/nginx/html && sed -e s/Docker/"$AUTHOR"/ Hello_docker.html > index.html ; nginx -g 'daemon off;' FROM nginx ENV AUTHOR=Docker RUN cd ../share/nginx/html COPY Hello_docker.html /usr/share/nginx/html CMD cd /usr/share/nginx/html && sed -e s/Docker/"$AUTHOR"/ Hello_docker.html > index.html ; nginx -g 'daemon off;' FROM nginx ENV AUTHOR=Docker RUN cd /usr/../share/nginx/html COPY Hello_docker.html /usr/share/nginx/html CMD cd /usr/share/nginx/html && sed -e s/Docker/"$AUTHOR"/ Hello_docker.html > index.html ; nginx -g 'daemon off;' ``` ```dockerfile title="Negative test num. 1 - dockerfile file" FROM nginx ENV AUTHOR=Docker WORKDIR /usr/share/nginx/html COPY Hello_docker.html /usr/share/nginx/html CMD cd /usr/share/nginx/html && sed -e s/Docker/"$AUTHOR"/ Hello_docker.html > index.html ; nginx -g 'daemon off;' ``` ```dockerfile title="Negative test num. 2 - dockerfile file" FROM nginx ENV AUTHOR=Docker RUN cd /usr/share/nginx/html COPY Hello_docker.html /usr/share/nginx/html CMD cd /usr/share/nginx/html && sed -e s/Docker/"$AUTHOR"/ Hello_docker.html > index.html ; nginx -g 'daemon off;' ```
Project: kpt (Provisioning / Automation & Configuration)
File: development.md

If you change the API resources, in `api/.../*.go`, update the generated code and manifests by running: ```sh make generate make manifests ``` Remove current Rollout and RemoteSync objects from your cluster. Then, remove old CRDs and apply the new CRDs to your cluster by running: ```sh make uninstall make install ``` Rollouts comprises of several software components: : Definition of the KRM API supported by the rollouts controllers. : The generated rollouts manifests. : The controllers and related code for the Rollout CRDs. : The generated rollouts manifests in kpt package format. : Represents a store of kubernetes clusters. : Matches discovered packages to known clusters. : Discovers config packages to be rolled out. : Exchanges tokens for authenticating GCP service accounts. : A client for the rollouts API. See dedicated documentation on running Rollouts: on GKE (getting started guide coming soon) Build Docker images of Rollout components: ```sh make docker-build make docker-push IMG=gcr.io/<your-project>/rollouts-controller:v0.0.x make docker-push ``` Follow to run Rollouts locally. Follow for the current Rollouts release process. `make manifests`: generate Rollouts manifests under `config` `make generate`: generate code based on Rollouts API definitions (runs k8s code generators) `make tidy`: run go mod tidy `make fmt`: formats golang sources `make vet`: vets golang sources `make test`: runs tests `make build`: builds manager binary `make docker-build`: builds Rollouts Docker images `make docker-push`: pushes Rollouts Docker images `make install`: install CRDs into the K8s cluster specified in ~/.kube/config `make uninstall`: uninstall CRDs from the K8s cluster specified in ~/.kube/config `make deploy`: deploy controller to the K8s cluster specified in ~/.kube/config (must provide IMG variable for the controller image) `make undeploy`: undeploy controller from the K8s cluster specified in ~/.kube/config `make license`: add licenses to source code works really well for editing and debugging.
Project: Meshery (Provisioning / Automation & Configuration)
File: crossplane.md

layout: integration title: Crossplane subtitle: Collaborative and visual infrastructure as code for Crossplane image: /assets/img/integrations/crossplane/icons/color/crossplane-color.svg permalink: extensibility/integrations/crossplane docURL: https://docs.meshery.io/extensibility/integrations/crossplane description: integrations-category: Orchestration & Management integrations-subcategory: Scheduling & Orchestration registrant: Artifact Hub components: featureList: [ "Highly extensible backend that enables you to orchestrate applications and infrastructure no matter where they run.", "Highly configurable frontend that lets you define the declarative API it offers.", "Provides reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just containers." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: KICS (Provisioning / Security & Compliance)
File: a31a5a29-718a-4ff4-8001-a69e5e4d029e.md

title: Instance With No VPC hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a31a5a29-718a-4ff4-8001-a69e5e4d029e Query name: Instance With No VPC Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Insecure Configurations URL: EC2 Instances should be configured under a VPC network. AWS VPCs provide the controls to facilitate a formal process for approving and testing all network connections and changes to the firewall and router configurations.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "aws_instance" "positive1" { ami = "ami-003634241a8fcdec0" instance_type = "t2.micro" } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" module "ec2_instance" { source = "terraform-aws-modules/ec2-instance/aws" version = "~> 3.0" name = "single-instance" ami = "ami-ebd02392" instance_type = "t2.micro" key_name = "user1" monitoring = true subnet_id = "subnet-eddcdzz4" tags = { Terraform = "true" Environment = "dev" } } ``` ```tf title="Negative test num. 1 - tf file" resource "aws_instance" "negative1" { ami = "ami-003634241a8fcdec0" instance_type = "t2.micro" vpcsecuritygroupids = ["awssecurity_group.instance.id"] } ``` ```tf title="Negative test num. 2 - tf file" module "ec2_instance" { source = "terraform-aws-modules/ec2-instance/aws" version = "~> 3.0" name = "single-instance" ami = "ami-ebd02392" instance_type = "t2.micro" key_name = "user1" monitoring = true vpcsecuritygroup_ids = ["sg-12345678"] subnet_id = "subnet-eddcdzz4" tags = { Terraform = "true" Environment = "dev" } } ```
Project: LinuxKit (Provisioning / Automation & Configuration)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: OpenTofu (Provisioning / Automation & Configuration)
File: pull_request_template.md

<!-- Thank you for your contribution! Please read this carefully! Please make sure you go through the checklist below. If your PR does not meet all requirements, please file it as a draft PR. Core team members will only review your PR once it meets all the requirements below (unless your change is something as trivial as a typo fix). --> <!-- If your PR resolves an issue, please add it here. --> Resolves # 1.8.0 <!-- This checklist is mandatory for all PRs: --> . [ ] I have not used an AI coding assistant to create this PR. [ ] I have marked any code I have not written myself (including modified code, e.g. copied from other places and then modified) with a comment indicating where it came from. <!-- If your PR contains Go code, please make sure you check off all items on this list: --> [ ] I have run golangci-lint on my change and receive no errors relevant to my code. [ ] I have run existing tests to ensure my code doesn't break anything. [ ] I have added tests for all relevant use cases of my code, and those tests are passing. [ ] I have only exported functions, variables and structs that should be used from other packages. [ ] I have added meaningful comments to all exported functions, variables, and structs. <!-- If you have changed the website, please follow this checklist: --> and checked my changes.