cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: b7063015-6c31-4658-a8e7-14f98f37fd42.md

title: EBS Volume Without KmsKeyId hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b7063015-6c31-4658-a8e7-14f98f37fd42 Query name: EBS Volume Without KmsKeyId Platform: CloudFormation Severity: <span style="color:#edd57e">Low</span> Category: Secret Management URL: EBS Volume should specify a KmsKeyId value<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" AWSTemplateFormatVersion: 2010-09-09 Description: Creating ECS service Resources: NewVolume: Type: AWS::EC2::Volume Properties: Size: 100 Encrypted: true AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone Tags: Key: MyTag Value: TagValue DeletionPolicy: Snapshot ``` ```json title="Positive test num. 2 - json file" hl_lines="7" { "AWSTemplateFormatVersion": "2010-09-09T00:00:00Z", "Description": "Creating ECS service", "Resources": { "NewVolume": { "Type": "AWS::EC2::Volume", "Properties": { "Size": 100, "Encrypted": true, "AvailabilityZone": "Ec2Instance.AvailabilityZone", "Tags": [ { "Key": "MyTag", "Value": "TagValue" } ] }, "DeletionPolicy": "Snapshot" } } } ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: 2010-09-09 Description: Creating ECS service Resources: MyKey: Type: "AWS::KMS::Key" Properties: KeyPolicy: Version: 2012-10-17 Id: key-default-1 Statement: Sid: Enable IAM User Permissions Effect: Allow Principal: AWS: !Join "" - "arn:aws:iam::" !Ref "AWS::AccountId" ":root" Action: "kms:*" Resource: "*" NewVolume: Type: AWS::EC2::Volume Properties: Size: 100 Encrypted: true AvailabilityZone: !GetAtt Ec2Instance.AvailabilityZone Tags: Key: MyTag Value: TagValue KmsKeyId: !Ref MyKey DeletionPolicy: Snapshot ``` ```json title="Negative test num. 2 - json file" { "Resources": { "MyKey": { "Type": "AWS::KMS::Key", "Properties": { "KeyPolicy": { "Version": "2012-10-17T00:00:00Z", "Id": "key-default-1", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": [ "", [ "arn:aws:iam::", "AWS::AccountId", ":root" ] ] }, "Action": "kms:*", "Resource": "*" } ] } } }, "NewVolume": { "DeletionPolicy": "Snapshot", "Type": "AWS::EC2::Volume", "Properties": { "KmsKeyId": "MyKey", "Size": 100, "Encrypted": true, "AvailabilityZone": "Ec2Instance.AvailabilityZone", "Tags": [ { "Key": "MyTag", "Value": "TagValue" } ] } } }, "AWSTemplateFormatVersion": "2010-09-09T00:00:00Z", "Description": "Creating ECS service" } ```
Project: KICS (Provisioning / Security & Compliance)
File: 075ca296-6768-4322-aea2-ba5063b969a9.md

title: Etcd TLS Certificate Files Not Properly Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 075ca296-6768-4322-aea2-ba5063b969a9 Query name: Etcd TLS Certificate Files Not Properly Set Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: When using etcd commands, the '--cert-file' and '--key-file' should be defined<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="21" apiVersion: apps/v1 kind: Deployment metadata: name: app-etcd-deployment spec: selector: matchLabels: app: app replicas: 1 template: metadata: labels: app: app version: v1 spec: serviceAccountName: database containers: name: database image: gcr.io/google_containers/etcd:v3.2.18 imagePullPolicy: IfNotPresent command: ["etcd"] args: ["--cert-file=/etc/env/file.crt"] nodeSelector: kubernetes.io/hostname: worker02 restartPolicy: OnFailure ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="21" apiVersion: apps/v1 kind: Deployment metadata: name: app-etcd-deployment spec: selector: matchLabels: app: app replicas: 1 template: metadata: labels: app: app version: v1 spec: serviceAccountName: database containers: name: database image: gcr.io/google_containers/etcd:v3.2.18 imagePullPolicy: IfNotPresent command: ["etcd"] args: ["--key-file=/etc/env/file2.key"] nodeSelector: kubernetes.io/hostname: worker02 restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: apps/v1 kind: Deployment metadata: name: app-etcd-deployment spec: selector: matchLabels: app: app replicas: 1 template: metadata: labels: app: app version: v1 spec: serviceAccountName: database containers: name: database image: gcr.io/google_containers/etcd:v3.2.18 imagePullPolicy: IfNotPresent command: ["etcd"] args: ["--cert-file=/etc/env/file.crt", "--key-file=/etc/env/file2.key"] nodeSelector: kubernetes.io/hostname: worker02 restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: apps/v1 kind: Deployment metadata: name: app-etcd-deployment spec: selector: matchLabels: app: app replicas: 1 template: metadata: labels: app: app version: v1 spec: serviceAccountName: database containers: name: database image: gcr.io/google_containers/etcd:v3.2.18 imagePullPolicy: IfNotPresent command: ["etcd", "--cert-file=/etc/env/file.crt", "--key-file=/etc/env/file2.key"] args: [] nodeSelector: kubernetes.io/hostname: worker02 restartPolicy: OnFailure ```
Project: StarRocks (App Definition and Development / Database)
File: grouping.md

displayed_sidebar: "English" Indicates whether a column is an aggregate column. If it is an aggregate column, 0 is returned. Otherwise, 1 is returned. ```Haskell GROUPING(col_expr) ``` `col_expr`: An expression for a dimension column specified in the expression-list of the ROLLUP, CUBE, or GROUPING SETS expansion of the GROUP BY clause. ```plain text MySQL > select * from t; +++ | k1 | k2 | +++ | NULL | B | | NULL | b | | A | NULL | | A | B | | A | b | | a | NULL | | a | B | | a | b | +++ 8 rows in set (0.12 sec) MySQL > SELECT k1, k2, GROUPING(k1), GROUPING(k2), COUNT(*) FROM t GROUP BY ROLLUP(k1, k2); +++--+--+-+ | k1 | k2 | grouping(k1) | grouping(k2) | count(*) | +++--+--+-+ | NULL | NULL | 1 | 1 | 8 | | NULL | NULL | 0 | 1 | 2 | | NULL | B | 0 | 0 | 1 | | NULL | b | 0 | 0 | 1 | | A | NULL | 0 | 1 | 3 | | a | NULL | 0 | 1 | 3 | | A | NULL | 0 | 0 | 1 | | A | B | 0 | 0 | 1 | | A | b | 0 | 0 | 1 | | a | NULL | 0 | 0 | 1 | | a | B | 0 | 0 | 1 | | a | b | 0 | 0 | 1 | +++--+--+-+ 12 rows in set (0.12 sec) ```
Project: Tetragon (Provisioning / Security & Compliance)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.2.4.md

layout: release date: 2019-11-7 tag: v0.2.4 language: en Mesheryctl Homebrew support available for mesheryctl. Meshery Server Meshery Adapter for Octarine released as stable. Documentation Revised quick start guide for Mac, Linux and Windows. WSL2 support published. GKE kubeconfig generation script switched to `--decode`.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: x509_private_key.md

+++ title = "x509privatekey resource" draft = false gh_repo = "inspec" platform = "unix" [menu] [menu.inspec] title = "x509privatekey" identifier = "inspec/resources/os/x509privatekey.md x509privatekey resource" parent = "inspec/resources/os" +++ Use the `x509privatekey` Chef InSpec audit resource to test the x509 private key. The Chef InSpec distributes this resource. An `x509privatekey` Chef InSpec audit resource allows you to test the x509 private key. ```ruby describe x509privatekey("/home/x509privatekey.pem", "key_password") do it { should be_valid } it { should be_encrypted } it { should havematchingcertificate("/home/x509_certificate.crt") } end ``` where `"/home/x509privatekey.pem"` is the path of the private key. `"key_password"` is the password of the private key. This is optional for private keys without password. `bevalid`, `beencrypted`, and `havematchingcertificate` are matchers of this resource `"/home/x509_certificate.crt"` is a x509 certificate generated using the specified private key. For a full list of available matchers, please visit the . The specific matchers of this resource are: `bevalid`, `beencrypted`, and `havematchingcertificate`. The `be_valid` matcher tests if the specified private key is valid. ```ruby it { should be_valid } ``` The `be_encrypted` matcher tests if the specified private key is encrypted. ```ruby it { should be_encrypted } ``` The `havematchingcertificate` matcher tests if the x509 private key has a matching certificate. ```ruby it { should havematchingcertificate("/home/x509_certificate.crt") } ``` The following examples show how to use this Chef InSpec audit resource. `be_valid` checks if the x509 private key is valid. ```ruby describe x509privatekey("/home/x509privatekey.pem", "key_password") do it { should be_valid } end ``` `be_valid` checks if the x509 private key is valid. ```ruby describe x509privatekey("/home/x509privatekey.pem") do it { should be_valid } end ``` `be_encrypted` checks if the x509 private key is encrypted. ```ruby describe x509privatekey("/home/x509privatekey.pem", "key_password") do it { should be_encrypted } end ``` `be_valid` checks if the x509 private key has a matching certificate. ```ruby describe x509privatekey("/home/x509privatekey.pem", "key_password") do it { should havematchingcertificate("/home/x509_certificate.crt") } end ```
Project: Meshery (Provisioning / Automation & Configuration)
File: kubesphere.md

layout: default title: KubeSphere permalink: installation/kubernetes/kubesphere type: installation category: kubernetes redirect_from: installation/platforms/kubershphere display-title: "false" language: en list: include image: /assets/img/platforms/kubesphere.png abstract: Install Meshery on KubeSphere {% include installation/installation_prerequisites.html %} is the open source, cloud native management plane that enables the adoption, operation, and management of Kubernetes, any service mesh, and their workloads. This tutorial walks you through an example of deploying Meshery from the App Store of KubeSphere. Please make sure you enable the OpenPitrix system. You need to create a workspace, a project, and a user account (`project-regular`) for this tutorial. The account needs to be a platform regular user and to be invited as the project operator with the `operator` role. In this tutorial, you log in as `project-regular` and work in the project `demo-project` in the workspace `demo-workspace`. For more information, see Create Workspaces, Projects, Users and Roles. Perform the following steps in order: On the Overview page of the project `demo-project`, click App Store in the upper-left corner. Search for Meshery in the App Store, and click on the search result to enter the app. In the App Information page, click Install on the upper right corner. In the App Settings page, set the application Name, Location (as your Namespace), and App Version, and then click Next on the upper right corner. Configure the values.yaml file as needed, or click Install to use the default configuration. Wait for the deployment to be finished. Upon completion, Meshery will be shown as Running in KubeSphere. Go to Services and click the service name of Meshery. In the Resource Status page, copy the NodePort of Meshery. Access the Meshery Dashboard by entering ${NodeIP}:${NODEPORT} in your browser. {% include related-discussions.html tag="meshery" %}
Project: YugabyteDB (App Definition and Development / Database)
File: dbeaver-ycql.md

title: Using DBeaver with YCQL headerTitle: Using DBeaver linkTitle: DBeaver description: Use the DBeaver multi-platform database tool to explore and query YugabyteDB YCQL. menu: v2.18: identifier: dbeaver-2-ycql parent: tools weight: 40 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../dbeaver-ysql/" class="nav-link"> <i class="icon-postgres" aria-hidden="true"></i> YSQL </a> </li> <li > <a href="../dbeaver-ycql/" class="nav-link active"> <i class="icon-cassandra" aria-hidden="true"></i> YCQL </a> </li> </ul> is a free multi-platform, cross-platform database tool for developers, SQL programmers, and database administrators. DBeaver supports various databases including PostgreSQL, MariaDB, MySQL, YugabyteDB. In addition, there are plugins and extensions for other databases that support the JDBC driver. supports non-JDBC data sources and allows you to explore Yugabyte YCQL tables. Before you can start using DBeaver with YCQL, you need to perform the following: Start YugabyteDB. For more information, see . Install JRE or JDK for Java 8 or later. Installers can be downloaded from , , or . Note that some of the installers include a JRE accessible only to DBeaver. Install . You can create a connection as follows: Launch DBeaver. Navigate to Database > New Database Connection to open the Connect to a database window shown in the following illustration. In the Select your database list, select NoSQL > Yugabyte CQL, and then click Next.\ \ Use Connection Settings to specify the following: Host: localhost Port: 9042 Keyspace: system User: leave blank if YCQL authentication is not enabled. If enabled, enter username. Password: leave blank if YCQL authentication is not enabled. If enabled, enter the password. Select Show all databases. Click Test Connection to verify that the connection is successful, as shown in the following illustration:\ \ DBeaver's Database Navigator should display system. You can expand the list to see all keyspaces available in YugabyteDB cluster, as shown in the following illustration: For sample data to explore YCQL using DBeaver, see .
Project: KICS (Provisioning / Security & Compliance)
File: bc3dabb6-fd50-40f8-b9ba-7429c9f1fb0e.md

title: Metadata Label Is Invalid hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: bc3dabb6-fd50-40f8-b9ba-7429c9f1fb0e Query name: Metadata Label Is Invalid Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Best Practices URL: Check if any label in the metadata is invalid.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="5" resource "kubernetes_pod" "test" { metadata { name = "terraform-example" labels = { app = "gdy.l+bel" } } spec { container { image = "nginx:1.7.9" name = "example" env { name = "environment" value = "test" } port { container_port = 8080 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } dns_config { nameservers = ["1.1.1.1", "8.8.8.8", "9.9.9.9"] searches = ["example.com"] option { name = "ndots" value = 1 } option { name = "use-vc" } } dns_policy = "None" } } ``` ```tf title="Negative test num. 1 - tf file" resource "kubernetes_pod" "test2" { metadata { name = "terraform-example" labels = { app = "MyApp" } } spec { container { image = "nginx:1.7.9" name = "example" env { name = "environment" value = "test" } port { container_port = 8080 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } dns_config { nameservers = ["1.1.1.1", "8.8.8.8", "9.9.9.9"] searches = ["example.com"] option { name = "ndots" value = 1 } option { name = "use-vc" } } dns_policy = "None" } } ```
Project: KICS (Provisioning / Security & Compliance)
File: 1123031a-f921-4c5b-bd86-ef354ecfd37a.md

title: Metadata Label Is Invalid hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1123031a-f921-4c5b-bd86-ef354ecfd37a Query name: Metadata Label Is Invalid Platform: Kubernetes Severity: <span style="color:#edd57e">Low</span> Category: Best Practices URL: Check if any label in the metadata is invalid.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" apiVersion: v1 kind: Pod metadata: name: goproxy labels: app: gdy.l+bel. spec: containers: name: goproxy image: k8s.gcr.io/goproxy:0.1 ports: containerPort: 8080 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20 ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: goproxy labels: app: goproxy spec: containers: name: goproxy image: k8s.gcr.io/goproxy:0.1 ports: containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20 ```
Project: external-secrets (Provisioning / Security & Compliance)
File: 009-pushsecret-generator.md

```yaml title: PushSecret generator integration version: v1alpha1 authors: Moritz Johner creation-date: 2023-08-25 status: draft ``` <!-- toc --> // autogen please <!-- /toc --> This design document describes how `PushSecret` can leverage generators to generate short-lived credentials without the need of an intermediary `Secret` resource. Currently, the process of using secure passwords and short-lived credentials within the External Secrets Operator involves multiple steps. Users need to create an `ExternalSecret` resource to generate a value which is stored in a `Secret` resource. This Secret resource is then pushed to a provider using a `PushSecret` resource. However, this intermediary step adds unnecessary complexity and inconvenience to the workflow. To simplify the workflow and enhance user experience, the proposal is to integrate generators directly into the `PushSecret` resource. This will allow users to specify a generator using a `generatorRef` within the PushSecret manifest. When the PushSecret reconciliation process occurs, a value will be generated using the specified generator. This generated value will be securely pushed to the provider and stored there. ```yaml apiVersion: external-secrets.io/v1alpha1 kind: PushSecret spec: selector: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: Password name: "my-password" ``` Simplified Workflow*: This change will simplify the process of generating and pushing secrets by eliminating the need for an intermediary Secret resource. Enhanced Security*: As secrets are generated and pushed directly, there will be a reduction in potential vulnerabilities that may arise from the management of intermediary resources. Increased Flexibility*: Integrating generators into PushSecrets allows for more customization and flexibility in generating secrets according to specific requirements. Potential Learning Curve*: Users who are accustomed to the previous workflow may need to adapt to the new approach, which could require some learning and adjustment. API and Documentation Update*: The API changes need to be well-documented to ensure users understand how to utilize the new feature effectively. tests: controller tests for this new field should be sufficient the API changes need to be documented API/CRD spec inline documentation PushSecret API documentation Guides section for `PushSecret` + `generator` functionality
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_test.TestTable.md

/ / TestTable .TestTable new TestTable(`testName?`, `tests?`) | Name | Type | | :- | :- | | `testName?` | `string` | | `tests?` | `Tests` | `Private` cmdIdx: `number` `Private` ctx: `Private` outputCount: `number` `Private` testName: `string` `Private` tests: `Tests` drilldownFromTable(`expectTable`, `_ctx?`): `void` drilldownFromTable() drilldowns from the table | Name | Type | Description | | : | :-- | :-- | | `expectTable` | `Table`<`Row`\> | is the expected table shown in the REPL | | `_ctx?` | | - | `void` evalStatus(`_`): `void` | Name | Type | | : | :-- | | `_` | `Object` | | `_.command` | `string` | | `_.ctx?` | | | `_.expectRow` | `RowWithBadgeAndMessage`[] | | `_.statusDescription?` | `string` | `void` `Private` executeAndValidate(`command`, `expectTable`, `validation?`, `_ctx?`): `void` Execute the table-generating command, and validate the content. | Name | Type | | : | :-- | | `command` | `string` | | `expectTable` | `Table`<`Row`\> | | `validation?` | `TableValidation` | | `_ctx?` | | `void` run(): `void` new TestTable().run() will start a mocha test suite `void`
Project: KubeArmor (Provisioning / Security & Compliance)
File: GOVERNANCE.md

This document outlines governance for KubeArmor and its related projects unless specifically outlined. In order to promote an open, inclusive, welcoming environment, KubeArmor has adopted a . It is the expectation that all participants have reviewed this document. Maintainers for KubeArmor demonstrate a long-standing commitment to the success, growth, and viability of KubeArmor, its subprojects and dependencies. Maintainers share a responsibility in the project's success and their responsibilities are not limited to code contribution but may also include administrative and outreach responsibilities. Maintainers are nominated and selected on an as-needed basis to reflect the growth of the project and the community at large from amongst the project's contributors and subject matter experts. Maintainers need not have write access to the repo. Maintainers are expected to: Maintaining the mission, vision, values, and scope of the project Assure that the KubeArmor project is of the highest quality, relevancy, and value to the community Refining the governance as needed Making project level decisions Controlling access to KubeArmor assets such as source repositories, hosting, project calendars Addressing Code of Conduct violations Deciding what sub-groups are part of the KubeArmor project Overseeing the resolution and disclosure of security issues On successful merge of a significant pull request from a Contributor any current maintainer can reach to the author behind the pull request and ask them if they are willing to become a KubeArmor maintainer. Once nominated, and the individual accepts, the existing Maintainers will vote and if a 2/3 majority is reached, that individual will become a Maintainer. Contributors are individuals that write, commit, and/or review code, documentation, or provide technical expertise to the KubeArmor project. Any individual that has the demonstrated expertise, interest and dedication to the success of the project may become a contributor. For specific guidance on practical contribution steps for KubeArmor or any of its related projects, please review the outline. The following licenses and contributor agreements will be used for KubeArmor projects: for code for documentation for new contributions This policy was created with guidance from documentation provided by , and .