cwielenb/CNCF-Dataset huggingface dataset:
Project: Confidential Containers (Provisioning / Security & Compliance)
File: eaa_verdictd.md

EAA/Verdictd support has been deprecated in Confidential Containers EAA is used to perform attestation at runtime and provide guest with confidential resources such as keys. It is based on . is the Key Broker Service and Attestation Service of EAA. The EAA KBC is an optional module in the attestation-agent at compile time, which can be used to communicate with Verdictd. The communication is established on the encrypted channel provided by rats-tls. EAA can now be used on Intel TDX and Intel SGX platforms. Before build encrypted image, you need to make sure Skopeo and Verdictd(EAA KBS) have been installed: : the command line utility to perform encryption operations. : EAA Key Broker Service and Attestation Service. Pull unencrypted image. Here use `alpine:latest` for example: ```sh ${SKOPEO_HOME}/bin/skopeo copy --insecure-policydocker://docker.io/library/alpine:latest oci:busybox ``` Follow the to encrypt the image. Publish the encrypted image to your registry. Build rootfs with EAA component: Specify `AAKBC=eaakbc` parameters when using kata-containers `rootfs.sh` scripts to create rootfs. Launch Verdictd Verdictd performs remote attestation at runtime and provides the key needed to decrypt the image. It is actually both Key Broker Service and Attestation Service of EAA. So when deploy the encrypted image, Verdictd is needed to be launched: ```sh verdictd --listen <$ip>:<$port> --mutual ``` Note The communication between Verdictd and EAA KBC is based on rats-tls, so you need to confirm that has been correctly installed in your running environment. Agent Configuration Add configuration `aakbcparams= 'eaa_kbc::<$IP>:<$PORT>'` to agent config file, the IP and PORT should be consistent with verdictd.
Project: Hazelcast IMDG (App Definition and Development / Database)
File: pull_request_template.md

<!-- Contributing to Hazelcast and looking for a challenge? Why don't you check out our open positions? https://hazelcast.pinpointhq.com/ --> INSERTPRDESCRIPTION_HERE Fixes INSERTLINKTOTHEISSUE_HERE Backport of: INSERTLINKTOTHEORIGINALPRHERE Breaking changes (list specific methods/types/messages): API client protocol format serialized form snapshot format Checklist: [ ] Labels (`Team:`, `Type:`, `Source:`, `Module:`) and Milestone set [ ] Add `Add to Release Notes` label if changes should be mentioned in release notes or `Not Release Notes content` if changes are not relevant for release notes [ ] Request reviewers if possible [ ] New public APIs have `@Nonnull/@Nullable` annotations [ ] New public APIs have `@since` tags in Javadoc [ ] Send backports/forwardports if fix needs to be applied to past/future releases
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: add-project.md

Run this command: ```bash title="Add project" lagoon add project \ --gitUrl <YOUR-GITHUB-REPO-URL> \ --openshift 1 \ --productionEnvironment <YOUR-PROD-ENV> \ --branches <THE-BRANCHES-YOU-WANT-TO-DEPLOY> \ --project <YOUR-PROJECT-NAME> ``` The value for `--openshift` is the ID of your Kubernetes cluster. Your production environment should be the name of the branch you want to have as your production environment. The branches you want to deploy might look like this: `^(main|develop)$` The name of your project is anything you want - Company Website, example, etc. Go to the Lagoon UI, and you should see your project listed! Lagoon creates a deploy key for each project. You now need to add it as a deploy key in your Git repository to allow Lagoon to download the code. Run the following command to get the deploy key: ```bash title="Get project-key" lagoon get project-key --project <YOUR-PROJECT-NAME> ``` Copy the key and save it as a deploy key in your Git repository. { .md-button } { .md-button } { .md-button } In order for Lagoon to be able to deploy on code updates, it needs to be connected to your Git repository Add your Lagoon cluster's webhook endpoint to your Git repository Payload URL: `<LAGOON-WEBHOOK-INGRESS>` Content Type: JSON Active: Active (allows you to enable/disable as required) Events: Select the relevant events, or choose All. Usually push, branch create/delete are required { .md-button } { .md-button } { .md-button }
Project: Harbor (Provisioning / Container Registry)
File: 7-04-Proj-replication-rules-filter.md

Test 7-04 Filter replication rules ======= To verify rule filter works correctly. User guide This test requires that two Harbor instance are running and available. Login as admin user. In `Administration->Replications`,input some character in rule filter and then clear the filter. Repeat steps 1-2 under `Projects->Project_Name->Replication` page. In step2, rules can be filtered, after clearing filter, all rules are shown again. None
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: helm_charts_repositories.md

Artifact Hub is able to process chart repositories as defined by the Helm project. For more information about the repository structure and different options to host your own, please check their . Most of the metadata Artifact Hub needs is extracted from the `Chart.yaml` file and other files in the chart package, like the `README` or `LICENSE` files. However, there is some extra Artifact Hub specific metadata that you can set using some special annotations in the `Chart.yaml` file. For more information, please see the . There is an extra metadata file that you can add at the repository URL's path named , which can be used to setup features like or . Please note that the artifacthub-repo.yml metadata file must be located at the same level of the chart repository index.yaml file, and it must be served from the chart repository HTTP server as well. Once you have added your repository, you are all set up. As you add new versions of your charts or even new charts to your repository, they'll be automatically indexed and listed in Artifact Hub. Artifact Hub is able to process chart repositories stored in . To add a repository stored in a OCI registry, the url used must follow the following format: `oci://registry/namespace/chart-name` Each of the chart versions are expected to match an OCI reference tag, which are expected to be valid versions. OCI specific installation instructions will be provided in the Artifact Hub UI when appropriate (only for Helm >=3.7). For additional information about Helm OCI support, please see the . There is an extra Artifact Hub specific metadata file named , which can be used to setup features like or . Once your repository metadata file is ready, you can push it to the OCI registry using : ```bash oras push \ registry/namespace/chart-name:artifacthub.io \ --config /dev/null:application/vnd.cncf.artifacthub.config.v1+yaml \ artifacthub-repo.yml:application/vnd.cncf.artifacthub.repository-metadata.layer.v1.yaml ``` The repository metadata file is pushed to the registry using a special tag named `artifacthub.io`. Artifact Hub will pull that artifact looking for the `application/vnd.cncf.artifacthub.repository-metadata.layer.v1.yaml` layer when the repository metadata is needed. Please note that there are some features that are not yet available for Helm repositories stored in OCI registries: Force an existing version to be reindexed by changing its digest
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: kustomize-patch.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: bucket-app spec: components: name: bucket-comp type: kustomize traits: type: kustomize-patch properties: patches: patch: |- apiVersion: v1 kind: Pod metadata: name: not-used labels: app.kubernetes.io/part-of: test-app target: labelSelector: "app=podinfo" ```
Project: Trivy (Provisioning / Security & Compliance)
File: debian.md

Trivy supports the following scanners for OS packages. | Scanner | Supported | | :--: | :-: | | SBOM | | | Vulnerability | | | License | | Please see for supported versions. The table below outlines the features offered by Trivy. | Feature | Supported | | :--: | :-: | | Unfixed vulnerabilities | | | | | Trivy detects packages that have been installed through package managers such as `apt` and `dpkg`. While there are some exceptions, like Go binaries and JAR files, it's important to note that binaries that have been custom-built using `make` or tools installed via `curl` are generally not detected. Debian offers its own security advisories, and these are utilized when scanning Debian for vulnerabilities. See . When looking at fixed versions, it's crucial to consider the patches supplied by Debian. For example, for CVE-2023-3269, the fixed version for Debian 12 (bookworm) is listed as `6.1.37-1` in . This patch is provided in [DSA-5448-1]. Note that this is different from the upstream fixed version, which is `6.5`. Typically, only the upstream information gets listed on [NVD], so it's important not to get confused. Trivy calculates the severity of an issue based on the 'Urgency' metric found in the Security Tracker. If 'Urgency' isn't provided by Debian, the severity from the NVD is taken into account. Using CVE-2019-15052 as an example, while it is rated as "Critical" in NVD, Debian has marked its "Urgency" as . As a result, Trivy will display it as "Low". Trivy supports the following [vulnerability statuses] for Debian. | Status | Supported | | :--: | :-: | | Fixed | | | Affected | | | Under Investigation | | | Will Not Fix | | | Fix Deferred | | | End of Life | | To identify the license of a package, Trivy checks the copyright file located at `/usr/share/doc/*/copyright`. However, this method has its limitations as the file isn't machine-readable, leading to situations where the license isn't detected. In such scenarios, the `--license-full` flag can be passed. It compares the contents of known licenses with the copyright file to discern the license in question. Please be aware that using this flag can increase memory usage, so it's disabled by default for efficiency.
Project: The Update Framework (TUF) (Provisioning / Security & Compliance)
File: 0002-pre-1-0-deprecation-strategy.md

Date: 2020-11-05 Technical Story: https://github.com/theupdateframework/python-tuf/issues/1127 We plan to refactor the reference implementation significantly and, as part of that effort, drop support for no-longer maintained versions of Python (see ADR 0001). However, a major user of (and contributor to) the project has users of the client stuck on older Python versions. We would like to define a reasonable support policy for the current, Python 2.7 supporting, codebase. We have finite resources. A major adopter/user of the project has a need to maintain support for Python 2.7 clients. Maintain the code in parallel for a fixed period of time after releasing the refactored code. Abandon the old code once the refactored code is released. Support the old code on a best-effort basis once the refactored code is released. Chosen option: "Support the old code on a best-effort basis once the refactored code is released", because we only have finite resources and want to focus them on moving the project forward, including supporting PyPI/pip integration and providing a solid implementation for developing specification enhancements in. We should document this outcome clearly in a governance document describing the release process with words along the lines of: "Support for older releases: Bugs reported with tuf versions prior to 1.0.0 will likely not be addressed directly by tufs maintainers. Pull Requests to fix bugs in the last release prior to 1.0.0 will be considered, and merged (subject to normal review processes). Note that there may be delays due to the lack of developer resources for reviewing such pull requests." Python version
Project: YugabyteDB (App Definition and Development / Database)
File: layered-architecture.md

title: Layered architecture for queries and storage headerTitle: Layered architecture linkTitle: Layered architecture description: Learn about the layered architecture of YugabyteDB in the query layer and the storage layer. menu: v2.18: identifier: architecture-layered-architecture parent: architecture weight: 1109 type: docs YugabyteDB architecture follows a layered design. The logical layers are the Yugabyte Query Layer, and the DocDB distributed document store, as per the following diagram: For more information, see the following: The (YQL) is the upper layer of YugabyteDB. Applications interact directly with YQL using client drivers. This layer deals with the API-specific aspects such as query and command compilation, as well as the run-time (data type representations, built-in operations, and so on). YQL is designed with extensibility in mind, allowing new APIs to be added. YQL supports two types of distributed SQL APIs: Yugabyte SQL (YSQL) and Yugabyte Cloud QL (YCQL). YSQL is a distributed SQL API that is built by reusing the PostgreSQL language layer code. It is a stateless SQL query engine that is wire-format compatible with PostgreSQL. YCQL is a semi-relational language that has its roots in Cassandra Query Language. It is a SQL-like language built specifically to be aware of clustering of data across nodes. For more information, see . is a distributed document store with the following properties: Extreme resiliency to failures Automatic sharding and load balancing Zone-, region-, and cloud-aware data placement policies Data in DocDB is stored in tables. Each table is composed of rows, with each row containing a key and a document. Data is stored inside tables in DocDB. A DocDB table is often sharded into a number of tablets whose sharding is transparent. For more information, see . Each tablet consisting of user data is replicated according to some replication factor using the Raft consensus algorithm. Replication is performed at a tablet level, and ensures single row linearizability even in the presence of failures. For more information, see . In order to persist data, a log-structured row- and document-oriented storage is used. It includes several optimizations for handling ever-growing data sets efficiently. For more information, see . DocDB supports both single-row and multi-row transactions, therefore allowing to modify multiple keys while preserving atomicity, consistency, isolation, and durability (ACID) properties. For more information, see the following:
Project: kpt (Provisioning / Automation & Configuration)
File: ROADMAP.md

Last updated: February 9th, 2023 Please follow the guide for installing the latest version of kpt. https://github.com/GoogleContainerTools/kpt/releases Please refer to the [release notes] page for more information about the latest features. A few areas of work are ongoing. (This is not exhaustive.) See the for more details. Currently, `kpt fn render` has dependency on docker to execute functions in pipeline. There are performance and docker dependency issues reported by customers. We will be exploring different function runtimes in order to address those issues. This is just an exploratory step and actual implementation if any, will be taken up after December 2021. . Currently, `kpt pkg` workflows only support Git repositories. There is some increasing demand from users to support other storage options beyond git(e.g., OCI). We will be spending time understanding the use-cases and need for this project. . File a [new issue] on Github, but please search first. kpt-users@googlegroups.com
Project: YugabyteDB (App Definition and Development / Database)
File: yba_provider_azure_describe.md

Describe an Azure YugabyteDB Anywhere provider Describe an Azure provider in YugabyteDB Anywhere ``` yba provider azure describe [flags] ``` ``` -h, --help help for describe ``` ``` -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") -n, --name string [Optional] The name of the provider for the action. Required for create, delete, describe, update. -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 a YugabyteDB Anywhere Azure provider
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: rdp.md

Every VM and VMI provides a `/portforward` subresource that can be used to create a websocket backed network tunnel to a port inside the instance similar to Kubernetes pods. One use-case for this subresource is to forward RDP traffic into the VMI either from the CLI or a web-UI. To connect to a Windows Guest via RDP, first open a `port-forward` tunnel: ```sh virtctl port-forward vm/win10 udp/3389 tcp/3389 ``` Then you can use the tunnel with an RDP client of your preference: ```sh freerdp /u:Administrator /p:YourPassword /v:127.0.0.1:3389 ```
Project: KICS (Provisioning / Security & Compliance)
File: 594f54e7-f744-45ab-93e4-c6dbaf6cd571.md

title: S3 Bucket Without Server-side-encryption hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 594f54e7-f744-45ab-93e4-c6dbaf6cd571 Query name: S3 Bucket Without Server-side-encryption Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: AWS S3 Storage should be protected with SSE (Server-Side Encryption)<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="5" name: Create a simple s3 bucket amazon.aws.s3_bucket: name: mys3bucket state: present encryption: "none" ``` ```yaml title="Negative test num. 1 - yaml file" name: Create a simple s3 bucket v2 amazon.aws.s3_bucket: name: mys3bucket state: present encryption: aws:kms ```
Project: sso (Provisioning / Key Management)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at sso@buzzfeed.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.11.15.md

RabbitMQ `3.11.15` is a maintenance release in the `3.11.x` . Please refer to the upgrade section from if upgrading from a version prior to 3.11.0. This release requires Erlang 25 and supports Erlang versions up to `25.3.x`. has more details on Erlang version requirements for RabbitMQ. As of 3.11.0, RabbitMQ requires Erlang 25. Nodes will fail to start on older Erlang releases. Erlang 25 as our new baseline means much improved performance on ARM64 architectures, across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users. Release notes can be found on GitHub at . Operator policies now can define `"ha-sync-mode"`, a classic mirrored queue setting. Note that classic mirrored queues are . All users of CMQs should or , or a combination of both. Contributed by @SimonUnge (AWS). GitHub issue: The package unintentionally limited supported Erlang versions to `<= 25.3.0` instead of `< 26`. GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.11.15.tar.xz` instead of the source tarball produced by GitHub.
Project: SuperEdge (Provisioning / Automation & Configuration)
File: edge-node-ops.md

In the scenario of edge clusters, edge nodes are distributed in different areas, and there is a one-way network between the edge nodes and the cloud (edge nodes and access to the cloud, the cloud cannot directly access the edge nodes), providing a unified entry for cloud SSH login can simplify the node Ops work. In response to this need, an SSH module was added to the tunnel component of the SuperEdge project to achieve unified operation of nodes in the cloud. The nodes of the edge nodes are distributed in different areas. The edge nodes can access the cloud master node, but the master node cannot access the nodes in the edge area. The user needs to log in to the node through SSH to access the port of the master node to perform Ops work. Install , Mac install directly with brew ``` brew install corkscrew ``` Or install netcat (centos) ``` yum install -y netcat ``` To log in to the edge node node-A-1 through SSH, you can use the following command: ``` ssh -o ProxyCommand="corkscrew masterIP cloud-port node-A-1 22" root@127.0.0.1 ``` Or ``` ssh -o ProxyCommand="nc -X connect -x masterIp:cloud-port node-A-1 22" root@127.0.0.1 ``` materIP: the external network ip of the node where the master node is located cloud-port: NodePort port, the server port of the corresponding SSH module Get cloud-port ```shell kubectl -n edge-system get svc tunnel-cloud -o=jsonpath='{range .spec.ports[*]}{.name}{"\t"}{.nodePort}{"\n"}{end}' | grep ssh | awk '{print $2}' ```