cwielenb/CNCF-Dataset huggingface dataset:
Project: Meshery (Provisioning / Automation & Configuration)
File: kubernetes-ingress.md

layout: integration title: HAProxy Kubernetes Ingress subtitle: Collaborative and visual infrastructure as code for NGINX Service Mesh image: /assets/img/integrations/kubernetes-ingress/icons/color/kubernetes-ingress-color.svg permalink: extensibility/integrations/kubernetes-ingress docURL: https://docs.meshery.io/extensibility/integrations/kubernetes-ingress description: integrations-category: Cloud Native Network integrations-subcategory: Service Proxy registrant: Artifact Hub components: name: backend colorIcon: assets/img/integrations/kubernetes-ingress/components/backend/icons/color/backend-color.svg whiteIcon: assets/img/integrations/kubernetes-ingress/components/backend/icons/white/backend-white.svg description: name: defaults colorIcon: assets/img/integrations/kubernetes-ingress/components/defaults/icons/color/defaults-color.svg whiteIcon: assets/img/integrations/kubernetes-ingress/components/defaults/icons/white/defaults-white.svg description: name: global colorIcon: assets/img/integrations/kubernetes-ingress/components/global/icons/color/global-color.svg whiteIcon: assets/img/integrations/kubernetes-ingress/components/global/icons/white/global-white.svg description: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] 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: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: SECURITY.md

To report a security problem in Artifact Hub, please contact the Maintainers Team at <cncf-artifacthub-maintainers@lists.cncf.io>. The maintainers will evaluate the report to verify the security issue. If the issue does not have a security impact, the report and follow-up will move to GitHub issues. If a security issue exists, the maintainers use the following process: Create a new draft advisory via GitHub Security Advisories Request a CVE identification number Collaborate on a private fork, part of the GitHub Security Advisory system, to fix the issue. Once a solution is ready, the CVE will be finalized and published, the change will be merged, and there will be a new release of Artifact Hub including the security fix.
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: API-006-universal-namespace.md

Proposed For cloud-edge hybrid scenarios and multie-region deployment scenarios, we need the ability to facilitate communications cross clusters. Specifically, it's desirable to have services scoped by cluster names so that a service in one cluster can address and invoke services on another trusted cluster through fully qualified names in a universal namespace, such as cluster1.serviceb. We should consider adding universal namespace capabilities to Dapr.
Project: KICS (Provisioning / Security & Compliance)
File: 66dae697-507b-4aef-be18-eec5bd707f33.md

title: OSLogin Is Disabled In VM Instance hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 66dae697-507b-4aef-be18-eec5bd707f33 Query name: OSLogin Is Disabled In VM Instance Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: VM instance should have OSLogin enabled<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="4" name: oslogin-disabled google.cloud.gcpcomputeinstance: metadata: enable-oslogin: no zone: us-central1-a auth_kind: serviceaccount ``` ```yaml title="Negative test num. 1 - yaml file" name: oslogin-enabled google.cloud.gcpcomputeinstance: metadata: enable-oslogin: yes zone: us-central1-a auth_kind: serviceaccount name: oslogin-missing google.cloud.gcpcomputeinstance: metadata: startup-script-url: gs:://graphite-playground/bootstrap.sh cost-center: '12345' zone: us-central1-a auth_kind: serviceaccount ```
Project: Athenz (Provisioning / Key Management)
File: cent_authz_flow.md

In this section, we're going to examine the centralized authorization flow. Before we go into the details of the authorization flow, it's important to understand the subsystems involved. The authorization (AuthZ) system shown in the figure below consists of several logical subsystems, which we will elaborate on in the following section. ZMS is where domains, roles, and policies are defined. This is Athenz's centralized authorization system and is likely part of a larger management system. In addition to allowing CRUD operations on the basic entities, ZMS provides an API to replicate the entities, per domain, to ZTS. It also can directly support the access check, both for internal management system checks, as well as a simple centralized deployment. ZMS is the source of truth for domains, roles, and policies for centralized authorization. ZMS supports a centralized call to check if a principal has access to a resource. Because ZMS supports service identities, ZMS can authenticate services. For centralized authorization, ZMS may be the only Athenz subsystem that you need to interact with. SIA is required for authenticating existing unmanaged services. Any service that launches other services should integrate SIA (or an equivalent system). To confirm a service's identity, SIA communicates with ZTS. A traditional centralized mechanism works as expected for services that are not dealing with the decentralized authorization: the server with resources can simply ask the ZMS directly about access, passing its credentials (X.509 Cert) and resource/action information for a given principal to get a simple boolean answer. In this model, the Athenz Management Service is the only component that needs to be deployed and managed within your environment. This does not scale well enough for data-plane access, since a central service must be consulted, but requires no local installation of other components and related storage and synchronization logic, so it is suitable for human interaction and control-plane provisioning uses where the number of requests processed by the server is small and the latency for authorization checks is not important. In Athenz, actors that can assume a role are called principals. Principals can be users or services, and users can be those looking for resources from a service or use the ZMS management console. The user or service must be configured with Athenz CA certificates and require mutual client authentication to accept and validate the service's X.509 certificate. Once validated, it can extract the CN field from the certificate would be the service's identity. Finally, just like the user case, it which would perform an identical check with ZMS to confirm access passing the action, resource and service name to ZMS.
Project: Pravega (App Definition and Development / Streaming & Messaging)
File: client-auth.md

<!-- Copyright Pravega Authors. 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. --> Pravega client can access Pravega APIs through `grpc`. Some of the admin APIs can be accessed via `REST` API. The Authorization/Authentication API and plugin works for both of these interfaces. If multiple plugin exists, a client selects its auth handler by setting a `grpc` header with the name `method`. This is performed by implementing interface by passing through the object to the Pravega client. The parameters for authentication are passed through custom `grpc` headers. These are extracted through `grpc` interceptors and passed on to the specific auth plugin. This plugin is identified by the `method` header. Dynamic extraction of parameters is also possible using the system properties or environment variables. The order of preference is listed below: User explicitly provides a credential object through the API. This results in overriding the other settings. System properties: System properties are defined in the format: `pravega.client.auth.*` Environment variables: Environment variables are defined in the format: `pravegaclientauth_*` In case of option 2 and 3, the caller decides on whether, the class needs to be loaded dynamically by setting the property `pravega.client.auth.loadDynamic` to true. The `REST` client in order to access the Pravega API uses the similar approach as mentioned in the above sections. The custom auth parameters are sent as the part of the `Authorization` HTTP header. The `REST` server implementation on Pravega Controller extracts these headers and passes it to the valid auth plugin implementation. Then it resumes, if the authentication and authorization matches the intended access pattern.
Project: KICS (Provisioning / Security & Compliance)
File: 80b7ac3f-d2b7-4577-9b10-df7913497162.md

title: EBS Volume Encryption Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 80b7ac3f-d2b7-4577-9b10-df7913497162 Query name: EBS Volume Encryption Disabled Platform: CloudFormation Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: EBS volumes should be encrypted<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="8" AWSTemplateFormatVersion: "2010-09-09" Description: "Volume" Resources: NewVolume: Type: AWS::EC2::Volume Properties: Size: 100 Encrypted: false AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone Tags: Key: MyTag Value: TagValue DeletionPolicy: Snapshot ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="6" AWSTemplateFormatVersion: "2010-09-09" Description: "Volume 02" Resources: NewVolume02: Type: AWS::EC2::Volume Properties: Size: 100 AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone Tags: Key: MyTag Value: TagValue DeletionPolicy: Snapshot ``` ```json title="Positive test num. 3 - json file" hl_lines="15" { "AWSTemplateFormatVersion": "2010-09-09", "Description": "Volume", "Resources": { "NewVolume": { "Type": "AWS::EC2::Volume", "Properties": { "Tags": [ { "Key": "MyTag", "Value": "TagValue" } ], "Size": 100, "Encrypted": false, "AvailabilityZone": "Ec2Instance.AvailabilityZone" }, "DeletionPolicy": "Snapshot" } } } ``` <details><summary>Positive test num. 4 - json file</summary> ```json hl_lines="6" { "Description": "Volume 02", "Resources": { "NewVolume02": { "Type": "AWS::EC2::Volume", "Properties": { "Size": 100, "AvailabilityZone": "Ec2Instance.AvailabilityZone", "Tags": [ { "Key": "MyTag", "Value": "TagValue" } ] }, "DeletionPolicy": "Snapshot" } }, "AWSTemplateFormatVersion": "2010-09-09" } ``` </details> ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: "2010-09-09" Description: "Volume" Resources: NewVolume: Type: AWS::EC2::Volume Properties: Size: 100 Encrypted: true AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone Tags: Key: MyTag Value: TagValue DeletionPolicy: Snapshot ``` ```json title="Negative test num. 2 - json file" { "AWSTemplateFormatVersion": "2010-09-09", "Description": "Volume", "Resources": { "NewVolume": { "Type": "AWS::EC2::Volume", "Properties": { "Encrypted": true, "AvailabilityZone": "Ec2Instance.AvailabilityZone", "Tags": [ { "Key": "MyTag", "Value": "TagValue" } ], "Size": 100 }, "DeletionPolicy": "Snapshot" } } } ```
Project: KICS (Provisioning / Security & Compliance)
File: 1056dfbb-5802-4762-bf2b-8b9b9684b1b0.md

title: API Gateway With Open Access hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1056dfbb-5802-4762-bf2b-8b9b9684b1b0 Query name: API Gateway With Open Access Platform: CloudFormation Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: API Gateway Method should restrict the authorization type, except for the HTTP OPTIONS method.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" AWSTemplateFormatVersion: "2010-09-09" Description: "Router53" Resources: MockMethod: Type: 'AWS::ApiGateway::Method' Properties: RestApiId: !Ref MyApi ResourceId: !GetAtt MyApi RootResourceId HttpMethod: GET AuthorizationType: NONE Integration: Type: MOCK ``` ```json title="Positive test num. 2 - json file" hl_lines="7" { "AWSTemplateFormatVersion": "2010-09-09", "Description": "Router53", "Resources": { "MockMethod": { "Type": "AWS::ApiGateway::Method", "Properties": { "RestApiId": "MyApi", "ResourceId": [ "MyApi", "RootResourceId" ], "HttpMethod": "GET", "AuthorizationType": "NONE", "Integration": { "Type": "MOCK" } } } } } ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: "2010-09-09" Description: "Router53" Resources: MockMethod: Type: 'AWS::ApiGateway::Method' Properties: RestApiId: !Ref MyApi ResourceId: !GetAtt MyApi RootResourceId HttpMethod: OPTIONS AuthorizationType: NONE Integration: Type: MOCK ``` ```json title="Negative test num. 2 - json file" { "Description": "Router53", "Resources": { "MockMethod": { "Type": "AWS::ApiGateway::Method", "Properties": { "RestApiId": "MyApi", "ResourceId": [ "MyApi", "RootResourceId" ], "HttpMethod": "OPTIONS", "AuthorizationType": "NONE", "Integration": { "Type": "MOCK" } } } }, "AWSTemplateFormatVersion": "2010-09-09" } ```
Project: Polaris (Provisioning / Security & Compliance)
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, gender identity and expression, level of experience, 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 opensource@fairwinds.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
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: device-write-bps.md

Limit write rate (in bytes per second) to a device (e.g. --device-write-bps=/dev/sda:1mb). On some systems, changing the resource limits may not be allowed for non-root users. For more details, see https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error This option is not supported on cgroups V1 rootless systems.
Project: Sonobuoy (Provisioning / Security & Compliance)
File: 2019-04-02-isolated-to-conformant.md

title: Isolated to Conformant - Testing Air-Gapped Kubernetes with Sonobuoy 0.14 image: /img/sonobuoy.svg excerpt: With support for running Kubernetes end-to-end tests in air-gapped environments, it is now possible to run the end-to-end suite and validate your clusters state without Internet connectivity. author_name: John Schnake author_url: https://github.com/johnschnake author_avatar: /img/contributors/john-schnake.png categories: [kubernetes] tags: ['Sonobuoy Team', 'John Schnake'] date: 2019-04-02 slug: isolated-to-conformant Previously posted on the Today we are releasing Sonobuoy 0.14.0, which delivers on one of our top roadmap goals: support for running Kubernetes end-to-end tests in air-gapped environments. It is now possible to run the end-to-end suite and validate your clusters state without Internet connectivity or investment in a custom, ad hoc work around. Running critical systems in air-gapped environments, where the system cant reach out to the Internet, has long been a common practice to limit the attack surface. Although installing Kubernetes in air-gapped environments has been possible since before Kubernetes 1.6, testing those clusters for conformance was difficult. The end-to-end suite uses numerous test images, which it tries to pull from public Docker registries; without access to those registries, the cluster is unable to run many of the tests required. Even without an air-gapped environment, restrictive networking policies can make it impossible to effectively run the Kubernetes end-to-end test suite. Since 2017, multiple people in the community have been working together to make the Kubernetes changes necessary to centralize and then customize the registries used during testing. Since Kubernetes 1.13, testing in air-gapped installations using private registries has technically been possible but was still a pain point for most users. The images were localized in the code, but you still had to manually look them up, get them into your private registry, and inform the tests to use your registry. Sonobuoy solves all three of these problems for you. By tracking the images required to run the end-to-end test suite and automating all the scripting to move the images, the new version of Sonobuoy makes it easier than ever to test your air-gapped installations.
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: cluster-issues.md

Welcome to the Monokle troubleshooting guide for cluster connections. This page will provide you with two methods to help resolve any issues you may be experiencing when attempting to connect to your Kubernetes clusters through the Monokle app. The first method involves using the in-app proxy setting, while the second method involves manually configuring a proxy using the kubectl command. Using the Proxy setting in Monokle Within the Monokle application, navigate to the Settings panel and go to the "Global Settings" section. Click on the checkbox for "Enable Proxy". This setting will start a proxy to the Kubernetes API server before connecting to the cluster, which can be helpful for advanced authentication setups. or Starting a Proxy server manually If the proxy setting does not resolve the issue, you can try using a proxy manually. To do this, run the command "kubectl proxy --port=PROXY_PORT" in a terminal, replacing PROXY_PORT with the port you would like to open the proxy on. Next, create a kubeconfig file in any location on your local system, using the following format: ```yaml apiVersion: v1 clusters: cluster: server: http://127.0.0.1:PROXY_PORT name: proxy contexts: context: cluster: proxy user: proxy name: proxy current-context: proxy users: name: proxy ``` Remember to replace PROXY_PORT with the same port you've used to open the proxy. In the Monokle application, open the Settings panel and navigate to the KUBECONFIG setting under Project Settings. Browse for the file you've created and select it to be used by Monokle. The Cluster Selector in the header should be updated with the new "proxy" context. Try connecting to the cluster again to see if the problem persists. If the above solutions do not resolve your issue, please contact us on GitHub or Discord for further assistance.
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. This library adapts the stdlib `encoding/json` decoder to be compatible with Kubernetes JSON decoding, and is not expected to actively add new features. It may be updated with changes from the stdlib `encoding/json` decoder. Any code that is added must: Have full unit test and benchmark coverage Be backward compatible with the existing exposed go API Have zero external dependencies Preserve existing benchmark performance Preserve compatibility with existing decoding behavior of `UnmarshalCaseSensitivePreserveInts()` or `UnmarshalStrict()` Avoid use of `unsafe` We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers You can reach the maintainers of this project via the . - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: Hazelcast IMDG (App Definition and Development / Database)
File: index.md

title: Introduction description: Various Design Documents for Hazelcast Jet features This section contains documents detailing technical design of Jet features, created during the development process. Design docs for features appears under that version's docs. Features developed for the upcoming version appears under the [pre-release version docs](/docs/next/design-docs). Each document is numbered, though since we're just starting this process we'll only include features for Jet starting from Jet 4.1.