cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: cd290efd-6c82-4e9d-a698-be12ae31d536.md

title: Shared Host IPC Namespace hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: cd290efd-6c82-4e9d-a698-be12ae31d536 Query name: Shared Host IPC Namespace Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Resource Management URL: Container should not share the host IPC namespace<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="6" apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: hostIPC: true securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="9" apiVersion: serving.knative.dev/v1 kind: Configuration metadata: name: dummy-config namespace: knative-sequence spec: template: spec: hostIPC: true securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: hostIPC: false securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: serving.knative.dev/v1 kind: Configuration metadata: name: dummy-config namespace: knative-sequence spec: template: spec: hostIPC: false securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 volumes: name: sec-ctx-vol emptyDir: { } containers: name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ] volumeMounts: name: sec-ctx-vol mountPath: /data/demo securityContext: allowPrivilegeEscalation: false ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: jenkins-job-authorization.md

title: Jenkins Job Trigger Policy Enforcement labels: layer: cicd software: jenkins inventors: pinterest videos: title: 'OPA at Scale: How Pinterest Manages Policy Distribution' speakers: name: Will Fu organization: pinterest name: Jeremy Krach organization: pinterest venue: OPA Summit at Kubecon San Diego 2019 link: https://www.youtube.com/watch?v=LhgxFICWsA8 Jenkins automates software development processes. OPA lets you control which people and which machines can run which Jenkins jobs.
Project: StarRocks (App Definition and Development / Database)
File: SHOW_CREATE_CATALOG.md

displayed_sidebar: "English" Queries the creation statement of an external catalog, including: (since v3.0) (since v3.2) (since v3.3) Note that authentication-related information in the return result will be anonymized. This command is supported from v3.0 onwards. ```SQL SHOW CREATE CATALOG <catalog_name>; ``` | Parameter | Required | Description | | - | | | | catalog_name | Yes | The name of the catalog whose creation statement you want to view. | ```Plain ++--+ | Catalog | Create Catalog | ++--+ ``` | Field | Description | | -- | | | Catalog | The name of the catalog. | | Create Catalog | The statement that was executed to create the catalog. | The following example queries the creation statement of a Hive catalog named `hivecataloghms`: ```SQL SHOW CREATE CATALOG hivecataloghms; ``` The return result is as follows: ```SQL CREATE EXTERNAL CATALOG `hivecataloghms` PROPERTIES ("aws.s3.access_key" = "AKM4", "hive.metastore.type" = "glue", "aws.s3.secret_key" = "iViD", "aws.glue.secret_key" = "iViD", "aws.s3.useinstanceprofile" = "false", "aws.s3.region" = "us-west-1", "aws.glue.region" = "us-west-1", "type" = "hive", "aws.glue.access_key" = "AKM4" ) ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: connectors-java-sdk.md

title: "Connectors - Java SDK" <!-- 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. --> Roadmap for connectors developed using Java SDK. Couchbase is a NoSQL document-oriented database. See for more details on the planned Beam connector for Couchbase. InfluxDB is a database for fast and highly available storage and retrieval of time series data. See for more details on the planned Beam connector for InfluxDB. Memcached is a distributed memory caching system. See for more details on the planned Beam connector for Memcached.
Project: ClickHouse (App Definition and Development / Database)
File: date.md

slug: /en/sql-reference/data-types/date sidebar_position: 12 sidebar_label: Date A date. Stored in two bytes as the number of days since 1970-01-01 (unsigned). Allows storing values from just after the beginning of the Unix Epoch to the upper threshold defined by a constant at the compilation stage (currently, this is until the year 2149, but the final fully-supported year is 2148). Supported range of values: \[1970-01-01, 2149-06-06\]. The date value is stored without the time zone. Example Creating a table with a `Date`-type column and inserting data into it: ``` sql CREATE TABLE dt ( `timestamp` Date, `event_id` UInt8 ) ENGINE = TinyLog; ``` ``` sql -- Parse Date -- - from string, -- - from 'small' integer interpreted as number of days since 1970-01-01, and -- - from 'big' integer interpreted as number of seconds since 1970-01-01. INSERT INTO dt VALUES ('2019-01-01', 1), (17897, 2), (1546300800, 3); SELECT * FROM dt; ``` ``` text timestampevent_id 2019-01-01 1 2019-01-01 2 2019-01-01 3 ``` See Also
Project: StarRocks (App Definition and Development / Database)
File: str_to_date.md

displayed_sidebar: "English" Converts a string into a DATETIME value according to the specified format. If the conversion fails, NULL is returned. The format must be consistent with that described in . This function is inverse to . ```Haskell DATETIME STRTODATE(VARCHAR str, VARCHAR format) ``` `str`: the time expression you want to convert. It must be of the VARCHAR type. `format`: the format used to return the value. For the supported format, see . Returns a value of the DATETIME type. If `format` specifies a date, a DATE value is returned. NULL is returned if `str` or `format` is NULL. Example 1: Convert the input into a DATETIME value. ```Plain Text MySQL > select strtodate('2014-12-21 12:34:56', '%Y-%m-%d %H:%i:%s'); ++ | strtodate('2014-12-21 12:34:56', '%Y-%m-%d %H:%i:%s') | ++ | 2014-12-21 12:34:56 | ++ ``` Example 2: Convert the input into a DATE value. ```Plain Text MySQL > select strtodate('2014-12-21 12:34:56', '%Y-%m-%d'); +--+ | strtodate('2014-12-21 12:34:56', '%Y-%m-%d') | +--+ | 2014-12-21 | +--+ ``` Example 3: Convert the input "200442 Monday" into a DATE value. ```Plain Text MySQL > select strtodate('200442 Monday', '%X%V %W'); +--+ | strtodate('200442 Monday', '%X%V %W') | +--+ | 2004-10-18 | +--+ ``` STRTODATE,STR,TO,DATE
Project: Checkov (Provisioning / Security & Compliance)
File: unexpected.md

This folder is for different cases of test runner test data where the input HCL is maybe unexpectedly transformed when you see the json representation. This area can be used to verify that certain checks are robust in catching issues which can't be caught by unit testing the HCL input level alone. `remoteaccess` is omitted in HCL. But is represented as `remoteaccess: [ ]` in the Plan. This needs to be taken in to account when writing the check. ``` resource "awseksnode_group" "test" { cluster_name = "test" nodegroupname = "example" noderolearn = "example-arn" subnet_ids = ["subnet-ids"] scaling_config { desired_size = 1 max_size = 1 min_size = 1 } } ```
Project: kaniko (App Definition and Development / Application Definition & Image Build)
File: bug_report.md

name: Bug report about: Report a bug in kaniko Actual behavior A clear and concise description of what the bug is. Expected behavior A clear and concise description of what you expected to happen. To Reproduce Steps to reproduce the behavior: ... ... Additional Information Dockerfile Please provide either the Dockerfile you're trying to build or one that can reproduce this error. Build Context Please provide or clearly describe any files needed to build the Dockerfile (ADD/COPY commands) Kaniko Image (fully qualified with digest) Triage Notes for the Maintainers <!-- Thank you for an opening an issue !!! We are doing our best to get to this. Please help us by helping us prioritize your issue by filling the section below --> | Description | Yes/No | |-|| | Please check if this a new feature you are proposing | <ul><li>- [ ] </li></ul>| | Please check if the build works in docker but not in kaniko | <ul><li>- [ ] </li></ul>| | Please check if this error is seen when you use `--cache` flag | <ul><li>- [ ] </li></ul>| | Please check if your dockerfile is a multistage dockerfile | <ul><li>- [ ] </li></ul>|
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_create_trigger.md

title: CREATE TRIGGER statement [YSQL] headerTitle: CREATE TRIGGER linkTitle: CREATE TRIGGER description: Use the CREATE TRIGGER statement to create a trigger. menu: v2.18: identifier: ddlcreatetrigger parent: statements type: docs Use the `CREATE TRIGGER` statement to create a trigger. {{%ebnf%}} create_trigger, event {{%/ebnf%}} the `WHEN` condition can be used to specify whether the trigger should be fired. For low-level triggers it can reference the old and/or new values of the row's columns. multiple triggers can be defined for the same event. In that case, they will be fired in alphabetical order by name. Set up a table with triggers for tracking modification time and user (role). Use the pre-installed extensions `insert_username` and `moddatetime`. ```plpgsql CREATE EXTENSION insert_username; CREATE EXTENSION moddatetime; CREATE TABLE posts ( id int primary key, content text, username text not null, moddate timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL ); CREATE TRIGGER insert_usernames BEFORE INSERT OR UPDATE ON posts FOR EACH ROW EXECUTE PROCEDURE insert_username (username); CREATE TRIGGER update_moddatetime BEFORE UPDATE ON posts FOR EACH ROW EXECUTE PROCEDURE moddatetime (moddate); ``` Insert some rows. For each insert, the triggers should set the current role as `username` and the current timestamp as `moddate`. ```plpgsql SET ROLE yugabyte; INSERT INTO posts VALUES(1, 'desc1'); SET ROLE postgres; INSERT INTO posts VALUES(2, 'desc2'); INSERT INTO posts VALUES(3, 'desc3'); SET ROLE yugabyte; INSERT INTO posts VALUES(4, 'desc4'); SELECT * FROM posts ORDER BY id; ``` ``` id | content | username | moddate -++-+- 1 | desc1 | yugabyte | 2019-09-13 16:55:53.969907 2 | desc2 | postgres | 2019-09-13 16:55:53.983306 3 | desc3 | postgres | 2019-09-13 16:55:53.98658 4 | desc4 | yugabyte | 2019-09-13 16:55:53.991315 ``` {{< note title="Note" >}} YSQL should have users `yugabyte` and (for compatibility) `postgres` created by default. {{< /note >}} Update some rows. For each update the triggers should set both `username` and `moddate` accordingly. ```plpgsql UPDATE posts SET content = 'desc1_updated' WHERE id = 1; UPDATE posts SET content = 'desc3_updated' WHERE id = 3; SELECT * FROM posts ORDER BY id; ``` ``` id | content | username | moddate -++-+- 1 | desc1_updated | yugabyte | 2019-09-13 16:56:27.623513 2 | desc2 | postgres | 2019-09-13 16:55:53.983306 3 | desc3_updated | yugabyte | 2019-09-13 16:56:27.634099 4 | desc4 | yugabyte | 2019-09-13 16:55:53.991315 ```
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: ip.md

Specify a static IPv4 address for the <<container|pod>>, for example 10.88.64.128. This option can only be used if the <<container|pod>> is joined to only a single network - i.e., --network=network-name is used at most once - and if the <<container|pod>> is not joining another container's network namespace via --network=container:_id_. The address must be within the network's IP address pool (default 10.88.0.0/16). To specify multiple static IP addresses per <<container|pod>>, set multiple networks using the --network option with a static IP address specified for each using the `ip` mode for that option.
Project: Krator (App Definition and Development / Application Definition & Image Build)
File: developers.md

This guide explains how to set up your environment for developing Krator. To build Krator, you will need The latest stable version of Rust openssl (Or use the feature) git If you want to test Krator, you will also require A Kubernetes cluster. We use `cargo` to build our programs: ```console $ cargo build ``` Krator is a library crate, meaning that you cannot run Krator directly, but must import it into other "binary" crates which can then be run. To see an example of using Krator in this way, check out the . Krator does not configure `k8s-openapi` to use a specific version of Kubernetes. You will need to select a version and enable its feature when building your application: ```toml [dependencies.k8s-openapi] version = "0.13" default-features = false features = ["v1_22"] ``` Krator is tested against Kubernetes v1.22. If you are on a system that doesn't have OpenSSL (or has the incorrect version), you have the option to build Krator using the Rustls project (Rust native TLS implementation): ```console $ cargo build --no-default-features --features rustls-tls ``` The same flags can be passed to `cargo run` if you want to just the project instead. The underlying dependencies for Rustls do not support certs with IP SANs (subject alternate names). Because of this, the serving certs requested during bootstrap will not work for local development options like minikube or KinD as they do not have an FQDN You can build Krator on WSL but will need a few prerequisites that aren't included in the Ubuntu distro in the Microsoft Store: ```console $ sudo apt install build-essential libssl-dev pkg-config ``` NOTE: We've had mixed success developing Krator on WSL. It has been successfully run on WSL2 using the WSL2-enabled Docker Kubernetes or Azure Kubernetes. If you're on WSL1 you may be better off running in a full Linux VM under Hyper-V. We have support for building on Windows using PowerShell: ```console $ cargo build --no-default-features --features rustls-tls ``` NOTE: Windows builds use the `rustls` library, which means there are some things to be aware of. See the section for more details The included example with Krator is the . ```console cargo run --example moose ``` Krator contains both unit tests and doc tests, and is routinely checked using `clippy` and `rustfmt` as well. For unit tests: ```console $ cargo test --workspace ``` For doc tests: ```console $ cargo test --doc --all ``` For `clippy`: ```console $ cargo clippy --workspace ``` For `rustfmt`: ```console cargo fmt --all -- --check ``` If you want to create your own Operator based on Krator, all you need to do is implement an `Operator`. See the to see how this is done.
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: opa_policies_repositories.md

OPA policies repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path to packages provided can contain one or more packages. Each package version must be on a separate folder. You can have multiple policies in a single package, or create a package for each policy, it's completely up to you. In the same way, you can decide if you want to provide one or multiple versions of your policies packages. The structure of a repository with multiple packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml more policies3.rego policies1.rego policies2.rego 2.0.0 README.md artifacthub-pkg.yml policies1.rego package2 1.0.0 README.md artifacthub-pkg.yml policies1.rego ``` This structure is flexible, and in some cases where you only have a package and a version it can be greatly simplified. The repository illustrated below, for example, is using a simpler structure. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml policies1.rego policies2.rego ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file for more details. Policies files must have the `.rego` extension. If you want to exclude some paths in your package from the indexing, you can do it using the `ignore` field in your , which uses `.gitignore` syntax. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. Once you have added your repository, you are all set up. As you add new versions of your policies or even new policies packages to your git repository, they'll be automatically indexed and listed in Artifact Hub. Policies source GitHub URL: Repository metadata file: Package metadata file: Repository URL used in Artifact Hub: `https://github.com/swade1987/deprek8ion/policies` (please note how the tree/master part is not used) Policies displayed in Artifact Hub:
Project: ClickHouse (App Definition and Development / Database)
File: odbc-bridge.md

slug: /ru/operations/utilities/odbc-bridge Simple HTTP-server which works like a proxy for ODBC driver. The main motivation was possible segfaults or another faults in ODBC implementations, which can crash whole clickhouse-server process. This tool works via HTTP, not via pipes, shared memory, or TCP because: It's simpler to implement It's simpler to debug jdbc-bridge can be implemented in the same way `clickhouse-server` use this tool inside odbc table function and StorageODBC. However it can be used as standalone tool from command line with the following parameters in POST-request URL: `connection_string` -- ODBC connection string. `columns` -- columns in ClickHouse NamesAndTypesList format, name in backticks, type as string. Name and type are space separated, rows separated with newline. `maxblocksize` -- optional parameter, sets maximum size of single block. Query is send in post body. Response is returned in RowBinary format. ```bash $ clickhouse-odbc-bridge --http-port 9018 --daemon $ curl -d "query=SELECT PageID, ImpID, AdType FROM Keys ORDER BY PageID, ImpID" --data-urlencode "connection_string=DSN=ClickHouse;DATABASE=stat" --data-urlencode "columns=columns format version: 1 3 columns: \`PageID\` String \`ImpID\` String \`AdType\` String " "http://localhost:9018/" > result.txt $ cat result.txt # Result in RowBinary format 12246623837185725195925621517 ```
Project: Meshery (Provisioning / Automation & Configuration)
File: CHANGELOG.md

This is a manually generated log to track changes to the repository for each release. Each section should include general headers such as Implemented enhancements and Merged pull requests. All closed issued and bug fixes should be represented by the pull requests that fixed them. Critical items to know are: renamed commands deprecated / removed commands changed defaults backward incompatible changes migration guidance changed behaviour adding site.url to config, making links in readme absolute (0.0.1) start of theme (0.0.0) Liquid Docs: Jekyll Docs:
Project: KICS (Provisioning / Security & Compliance)
File: 57ced4b9-6ba4-487b-8843-b65562b90c77.md

title: Security Group With Unrestricted Access To SSH hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 57ced4b9-6ba4-487b-8843-b65562b90c77 Query name: Security Group With Unrestricted Access To SSH Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: 'SSH' (TCP:22) should not be public in AWS Security Group<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="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: tcp from_port: 22 to_port: 22 cidr_ip: 79.32.0.0/12 proto: tcp from_port: -1 to_port: -1 cidr_ip: 79.32.0.0/12 proto: tcp from_port: 22 to_port: 22 cidr_ipv6: 2607:F8B0::/24 ``` ```yaml title="Negative test num. 1 - yaml file" 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: tcp from_port: 80 to_port: 80 cidr_ip: 79.32.0.0/8 proto: tcp from_port: 80 to_port: 80 cidr_ipv6: 64:ff9b::/96 ```
Project: Trivy-Operator (Provisioning / Security & Compliance)
File: webhook.md

Trivy Operator allows you to send reports externally to a webhook as they get produced. This is useful in cases where you would like to "set-and-forget" the operator and monitor the reports elsewhere. It's also useful when you have to make decisions based on a report, e.g. prune a vulnerable image, remove a deployment with exposed secrets etc. The latter use case can be fulfilled by using a SOAR tool . Out of the box, Postee offers a variety of integrations with other third party services such as ServiceNow, Slack, AWS Security Hub and many more. You can enable the Webhook integration as follows: Required: Set `OPERATORWEBHOOKBROADCAST_URL` to the webhook endpoint you'd like to send the reports to. Optional: Set `OPERATORWEBHOOKBROADCAST_TIMEOUT` to a time limit that suites your use case. Default is `30s`. Optional: Set `OPERATORSENDDELETED_REPORTS` to `true` to send webhook notifications when reports are deleted. Default is `false`. Optional: Set `OPERATORWEBHOOKBROADCASTCUSTOMHEADERS` to comma seperated `key:value` to send webhook notifications with custom headers. Default is `` The Webhook integration support the following reports types: `vulnerabilityreport` `exposedsecretreport` `configAuditReport` `infraAssessmentReport` `rbacAssessmentReport` `clusterRbacAssessmentReport` `clusterConfigAuditReport` `clusterInfraAssessmentReport` `clusterComplianceReport` `sbomReport`