cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: ea6bc7a6-d696-4dcf-a788-17fa03c17c81.md

title: Security Group Ingress Not Restricted hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ea6bc7a6-d696-4dcf-a788-17fa03c17c81 Query name: Security Group Ingress Not Restricted Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: AWS Security Group should restrict ingress access<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="26 7" name: example ec2 group amazon.aws.ec2_group: name: example description: an example EC2 group vpc_id: 12345 region: eu-west-1 rules: proto: -1 from_port: 0 to_port: 0 cidr_ip: 0.0.0.0/0 proto: all from_port: 0 to_port: 0 cidr_ip: 0.0.0.0/0 proto: 12121 from_port: 0 to_port: 0 cidr_ip: 0.0.0.0/0 name: example ec2 group v2 amazon.aws.ec2_group: name: example description: an example EC2 group vpc_id: 12345 region: eu-west-1 rules: proto: -1 from_port: 0 to_port: 0 cidr_ipv6: ::/0 proto: all from_port: 0 to_port: 0 cidr_ipv6: ::/0 proto: 121212 from_port: 0 to_port: 0 cidr_ipv6: ::/0 ``` ```yaml title="Negative test num. 1 - yaml file" name: example ec2 group v3 amazon.aws.ec2_group: name: example description: an example EC2 group vpc_id: 12345 region: eu-west-1 rules: proto: tcp from_port: 80 to_port: 80 cidr_ip: 10.0.0.0/8 name: example ec2 group v4 amazon.aws.ec2_group: name: example description: an example EC2 group vpc_id: 12345 region: eu-west-1 rules: proto: tcp from_port: 80 to_port: 80 cidr_ipv6: 2001:DB8:8086:6502::/32 ```
Project: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_data.md

title: Kubectl-Dba Data menu: docs_{{ .version }}: identifier: kubectl-dba-data name: Kubectl-Dba Data parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Insert, Drop or Verify data in a database Insert random data or verify data in a database. ``` kubectl-dba data ``` ``` kubectl dba data insert mysql mysql-demo -n demo --rows=100 kubectl dba data verify postgres sample-postgres -n demo --rows=100 kubectl dba data drop mg -n demo sample-mg Valid resource types include: elasticsearch mongodb mariadb mysql postgres redis ``` ``` -h, --help help for data ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "/home/runner/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --default-seccomp-profile-type string Default seccomp profile --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --password string Password for basic authentication to the API server --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use --username string Username for basic authentication to the API server ``` - kubectl plugin for KubeDB - Drop data from a database - Insert random data in a database - Verify data in a database
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_nfs_list.md

List NFS YugabyteDB Anywhere storage-configurations List NFS YugabyteDB Anywhere storage-configurations ``` yba storage-config nfs list [flags] ``` ``` -h, --help help for list ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the storage configuration for the operation. 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 NFS storage configuration
Project: kpt (Provisioning / Automation & Configuration)
File: 02-workflows.md

In this section, we'll describe the typical workflows in kpt. We say "typical", because there is no single right way of using kpt. A user may choose to use some command but not another. This modularity is a key design principle. However, we still want to provide guidance on how the functionality could be used in real-world scenarios. A workflow in kpt can be best modelled as performing some verbs on the noun package. For example, when consuming an upstream package, the initial workflow can look like this: Get: Using `kpt pkg get` Explore: Using an editor or running commands such as `kpt pkg tree` Edit: Customize the package either manually or automatically using `kpt fn eval`. This may involve editing the functions pipeline in the `Kptfile` which is executed in the next stage. Render: Using `kpt fn render` First, you get a package from upstream. Then, you explore the content of the package to understand it better. Then you typically want to customize the package for you specific needs. Finally, you render the package which produces the final resources that can be directly applied to the cluster. Render is a required step as it ensures certain preconditions and postconditions hold true about the state of the package. This workflow is an iterative process. There is usually a tight Edit/Render loop in order to produce the desired outcome. Some time later, you may want to update to a newer version of the upstream package: Update: Using `kpt pkg update` Updating the package involves merging your local changes with the changes made by the upstream package authors between the two specified versions. This is a resource-based merge strategy, and not a line-based merge strategy used by `git merge`. Instead of consuming an existing package, you can also create a package from scratch: Create: Initialize a directory using `kpt pkg init`. Now, let's say you have rendered the package, and want to deploy it to a cluster. The workflow may look like this: Initialize: One-time process using `kpt live init` Preview: Using `kpt live apply --dry-run` Apply: Using `kpt live apply` Observe: Using `kpt live status` First, you use dry-run to validate the resources in your package and verify that the expected resources will be applied and pruned. Then if that looks good, you apply the package. Afterwards, you may observe the status of the package on the cluster. You typically want to store the package on Git: Publish: Using `git commit` The publishing flow is orthogonal to deployment flow. This allows you to act as a publisher of an upstream package even though you may not deploy the package personally.
Project: kpt (Provisioning / Automation & Configuration)
File: 01-initializing-a-package-for-apply.md

Before you can apply the package to the cluster, it needs to be initialized using `live init`. This is a one-time client-side operation that adds metadata to the `ResourceGroup` CR (by default located in `resourcegroup.yaml` file) specifying the name, namespace and inventoryID of the `ResourceGroup` resource `live apply` command will use to store the inventory (list of the resources applied). Let's initialize the `wordpress` package: ```shell $ kpt live init wordpress initializing "resourcegroup.yaml" inventory info (namespace: default)...success ``` This creates the `ResourceGroup` CR in the `resourcegroup.yaml` file: ```yaml apiVersion: kpt.dev/v1alpha1 kind: ResourceGroup metadata: name: inventory-74096247 namespace: default labels: cli-utils.sigs.k8s.io/inventory-id: 0a32e2c0200b4bd4c19cd3e097086b4648b8902d-1653113657067255815 ``` `ResourceGroup` is a namespace-scoped resource. By default, `live init` command uses heuristics to automatically choose the namespace. In this example, all the resources in `wordpress` package were in the `default` namespace, so it chose `default` for the namespace. Alternatively, you can manually configure the name and namespace of the `ResourceGroup` resource. ?> Refer to the for usage. !> Once a package is applied to the cluster, you do not want to change the `ResourceGroup` CR; doing so severs the association between the package and the inventory in the cluster, leading to destructive operations.
Project: Checkov (Provisioning / Security & Compliance)
File: dockerfile.md

layout: default published: true title: Dockerfile configuration scanning nav_order: 20 Checkov supports the evaluation of policies on your Dockerfile files. When using checkov to scan a directory that contains Dockerfile it will validate if the file is compliant with Docker best practices such as not using root user, making sure health check exists and not exposing SSH port. Full list of Dockerfile policies checks can be found . ```dockerfile FROM node:alpine WORKDIR /usr/src/app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 22 HEALTHCHECK CMD curl --fail http://localhost:3000 || exit 1 CMD ["node","app.js"] ``` ```bash checkov -d . --framework dockerfile ``` ```bash _| | _ | | / | '_ \ / _ \/ | |/ / _ \ \ / / | (| | | | / (| < (_) \ V / \_|_| |_|\|\|_|\_\/ \/ By Prisma Cloud | version: x.x.x dockerfile scan results: Passed checks: 3, Failed checks: 2, Skipped checks: 0 Check: CKVDOCKER5: "Ensure update instructions are not use alone in the Dockerfile" PASSED for resource: /Dockerfile. File: /Dockerfile:1-8 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/docker-policy-index/ensure-update-instructions-are-not-used-alone-in-the-dockerfile Check: CKVDOCKER7: "Ensure the base image uses a non latest version tag" PASSED for resource: /Dockerfile. File: /Dockerfile:1-8 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/ensure-the-base-image-uses-a-non-latest-version-tag Check: CKVDOCKER2: "Ensure that HEALTHCHECK instructions have been added to container images" PASSED for resource: /Dockerfile.HEALTHCHECK File: /Dockerfile:7-7 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/ensure-that-healthcheck-instructions-have-been-added-to-container-images Check: CKVDOCKER1: "Ensure port 22 is not exposed" FAILED for resource: /Dockerfile.EXPOSE File: /Dockerfile:6-6 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/ensure-port-22-is-not-exposed 6 | EXPOSE 3000 22 Check: CKVDOCKER3: "Ensure that a user for the container has been created" FAILED for resource: /Dockerfile. File: /Dockerfile:1-8 Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/docker-policies/ensure-that-a-user-for-the-container-has-been-created 1 | FROM node:alpine 2 | WORKDIR /usr/src/app 3 | COPY package*.json ./ 4 | RUN npm install 5 | COPY . . 6 | EXPOSE 3000 22 7 | HEALTHCHECK CMD curl --fail http://localhost:3000 || exit 1 8 | CMD ["node","app.js"] ```
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_core.CommandOptions.md

/ / CommandOptions .CommandOptions `CapabilityRequirements` `CommandOptions` `Optional` docs: `string` `Optional` flags: `YargsParserFlags` `Optional` fullscreen: `boolean` CapabilityRequirements.fullscreen `Optional` height: `number` `Optional` hidden: `boolean` `Optional` hide: `boolean` `Optional` incognito: `"popup"`[] `Optional` isDirectory: `boolean` is this an interior node ("directory", versus a leaf-node with a command handler `Optional` isExperimental: `boolean` Is the command experimental? e.g. initial release, lack of test coverage `Optional` listen: `CommandListener` `Optional` needsUI: `boolean` CapabilityRequirements.needsUI `Optional` noArgs: `boolean` does this command accept no arguments of any sort (neither positional nor optional)? `Optional` noAuthOk: `boolean` \| `string`[] CapabilityRequirements.noAuthOk `Optional` noCoreRedirect: `boolean` controller wants to handle redirect `Optional` okOptions: `string`[] `Optional` outputOnly: `boolean` Is the command only want to show output and hide input? `Optional` override: <<`any`\>, \> `Optional` plugin: `string` `Optional` preferReExecute: `boolean` When this command is being replayed, prefer to re-execute if possible `Optional` requiresLocal: `boolean` CapabilityRequirements.requiresLocal `Optional` semiExpand: `boolean` Semicolon-expand the command line? Default: true `Optional` synonymFor: `Command`<<`any`\>, \> `Optional` usage: `Optional` viewName: `string` `Optional` viewTransformer: <<`any`\>, \> model to view transformer `Optional` width: `number`
Project: ClickHouse (App Definition and Development / Database)
File: playground.md

slug: /ru/getting-started/playground sidebar_position: 14 sidebar_label: Playground allows people to experiment with ClickHouse by running queries instantly, without setting up their server or cluster. Several example datasets are available in Playground. You can make queries to Playground using any HTTP client, for example or , or set up a connection using or drivers. More information about software products that support ClickHouse is available . | Parameter | Value | |:--|:--| | HTTPS endpoint | `https://play.clickhouse.com:443/` | | Native TCP endpoint | `play.clickhouse.com:9440` | | User | `explorer` or `play` | | Password | (empty) | The queries are executed as a read-only user. It implies some limitations: DDL queries are not allowed INSERT queries are not allowed The service also have quotas on its usage. HTTPS endpoint example with `curl`: ``` bash curl "https://play.clickhouse.com/?user=explorer" --data-binary "SELECT 'Play ClickHouse'" ``` TCP endpoint example with : ``` bash clickhouse client --secure --host play.clickhouse.com --user explorer ```
Project: Meshery (Provisioning / Automation & Configuration)
File: confidential-containers.md

layout: integration title: Confidential Containers subtitle: Collaborative and visual infrastructure as code for Confidential Containers image: /assets/img/integrations/confidential-containers/icons/color/confidential-containers-color.svg permalink: extensibility/integrations/confidential-containers docURL: https://docs.meshery.io/extensibility/integrations/confidential containers description: integrations-category: Runtime integrations-subcategory: Security & Compliance registrant: Artifact Hub components: featureList: [ "Allows cloud native application owners to enforce application security requirements.", "Transparent deployment of unmodified containers.", "Support for multiple TEE and hardware platforms." ] 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: DevSpace (App Definition and Development / Application Definition & Image Build)
File: request-readme.md

The request based API allows for custom backends in a way similar to the http package. In order to create a backend you need to implement 4 handler interfaces; one for reading, one for writing, one for misc commands and one for listing files. Each has 1 required method and in each case those methods take the Request as the only parameter and they each return something different. These 4 interfaces are enough to handle all the SFTP traffic in a simplified manner. The Request structure has 5 public fields which you will deal with. Method (string) - string name of incoming call Filepath (string) - POSIX path of file to act on Flags (uint32) - 32bit bitmask value of file open/create flags Attrs ([]byte) - byte string of file attribute data Target (string) - target path for renames and sym-links Below are the methods and a brief description of what they need to do. Handler for "Get" method and returns an io.Reader for the file which the server then sends to the client. Handler for "Put" method and returns an io.Writer for the file which the server then writes the uploaded file to. The file opening "pflags" are currently preserved in the Request.Flags field as a 32bit bitmask value. See the [SFTP spec](https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-6.3) for details. Handles "SetStat", "Rename", "Rmdir", "Mkdir" and "Symlink" methods. Makes the appropriate changes and returns nil for success or an filesystem like error (eg. os.ErrNotExist). The attributes are currently propagated in their raw form ([]byte) and will need to be unmarshalled to be useful. See the respond method on sshFxpSetstatPacket for example of you might want to do this. Handles "List", "Stat", "Readlink" methods. Gathers/creates FileInfo structs with the data on the files and returns in a list (list of 1 for Stat and Readlink). Add support for API users to see trace/debugging info of what is going on inside SFTP server. Unmarshal the file attributes into a structure on the Request object.
Project: KICS (Provisioning / Security & Compliance)
File: dc5c5fee-6c53-43b0-ab11-4c660e064aaf.md

title: Node Auto Upgrade Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: dc5c5fee-6c53-43b0-ab11-4c660e064aaf Query name: Node Auto Upgrade Disabled Platform: GoogleDeploymentManager Severity: <span style="color:#ff7213">Medium</span> Category: Resource Management URL: Kubernetes nodes must have auto upgrades set to true, which means the attribute 'nodePools' must be defined and the subattribute 'managment' must be defined and have the attribute 'autoUpgrade' set to true<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="4" resources: name: cluster type: container.v1.cluster properties: description: my-cluster ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="6" resources: name: cluster type: container.v1.cluster properties: description: my-cluster nodePools: initialNodeCount: 2 ``` ```yaml title="Positive test num. 3 - yaml file" hl_lines="8" resources: name: cluster type: container.v1.cluster properties: description: my-cluster nodePools: initialNodeCount: 2 management: autoRepair: true ``` <details><summary>Positive test num. 4 - yaml file</summary> ```yaml hl_lines="9" resources: name: cluster type: container.v1.cluster properties: description: my-cluster nodePools: initialNodeCount: 2 management: autoUpgrade: false ``` </details> ```yaml title="Negative test num. 1 - yaml file" resources: name: cluster type: container.v1.cluster properties: description: my-cluster nodePools: initialNodeCount: 2 management: autoUpgrade: true ```
Project: StarRocks (App Definition and Development / Database)
File: CREATE_VIEW.md

displayed_sidebar: "English" Creates a view. A view, or a logical view, is a virtual table whose data is derived from a query against other existing physical tables. Therefore, a view uses no physical storage, and all queries against the view are equivalent to sub-queries of the query statement used to build the view. For information about materialized views supported by StarRocks, see and . :::tip Only users with the CREATE VIEW privilege on a specific database can perform this operation. ::: ```SQL CREATE [OR REPLACE] VIEW [IF NOT EXISTS] [<database>.]<view_name> ( <column_name>[ COMMENT 'column comment'] [, <column_name>[ COMMENT 'column comment'], ...] ) [COMMENT 'view comment'] AS <query_statement> ``` | Parameter | Description | | | | | OR REPLACE | Replace an existing view. | | database | The name of the database where the view resides. | | view_name | The name of the view. For the naming conventions, see . | | columnname | The name of the column(s) in the view. Note that the columns in the view and the columns queried in the `querystatement` must agree in number. | | COMMENT | The comment on the column in the view or the view itself. | | query_statement | The query statement used to create the view. It can be any query statement supported by StarRocks. | Querying a view requires the SELECT privilege on the view and on its corresponding base tables. If the query statement used to build a view cannot be executed due to the Schema Change on the base tables, StarRocks returns an error when you query the view. Example 1: Create a view named `exampleview` in `exampledb` with an aggregate query against `example_table`. ```SQL CREATE VIEW exampledb.exampleview (k1, k2, k3, v1) AS SELECT c1 as k1, k2, k3, SUM(v1) FROM example_table WHERE k1 = 20160112 GROUP BY k1,k2,k3; ``` Example 2: Create a view named `exampleview` in the database `exampledb` with an aggregate query against the table `example_table`, and specify comments for the view and each column in it. ```SQL CREATE VIEW exampledb.exampleview ( k1 COMMENT 'first key', k2 COMMENT 'second key', k3 COMMENT 'third key', v1 COMMENT 'first value' ) COMMENT 'my first view' AS SELECT c1 as k1, k2, k3, SUM(v1) FROM example_table WHERE k1 = 20160112 GROUP BY k1,k2,k3; ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_spanner_instances.md

+++ title = "googlespannerinstances resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlespannerinstances" identifier = "inspec/resources/gcp/googlespannerinstances.md googlespannerinstances resource" parent = "inspec/resources/gcp" +++ A `googlespannerinstances` is used to test a Google Instance resource ```ruby describe.one do googlespannerinstances(project: 'chef-gcp-inspec', config: 'regional-us-east1').configs.each do |config| describe config do it { should match 'regional-us-east1' } end end end ``` Properties that can be accessed from the `googlespannerinstances` resource: See the resource for more information. `names` : an array of `googlespannerinstance` name `configs` : an array of `googlespannerinstance` config `display_names` : an array of `googlespannerinstance` display_name `node_counts` : an array of `googlespannerinstance` node_count `labels` : an array of `googlespannerinstance` labels This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.