cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 6d7b121a-a2ed-4e37-bd2f-80d9df1dfd35.md

title: DNSSEC Using RSASHA1 hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 6d7b121a-a2ed-4e37-bd2f-80d9df1dfd35 Query name: DNSSEC Using RSASHA1 Platform: GoogleDeploymentManager Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: DNSSEC should not use the RSASHA1 algorithm<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="9" resources: name: dns type: dns.v1.managedZone properties: name: my-zone dnssecConfig: state: "on" defaultKeySpecs: algorithm: rsasha1 ``` ```yaml title="Negative test num. 1 - yaml file" resources: name: dns2 type: dns.v1.managedZone properties: name: my-zone2 dnssecConfig: state: "on" defaultKeySpecs: algorithm: rsasha256 ```
Project: Distribution (Provisioning / Container Registry)
File: dockerhub.md

This repository provides container images for the Open Source Registry implementation for storing and distributing container artifacts in conformance with the . <img src="https://raw.githubusercontent.com/distribution/distribution/main/distribution-logo.svg" width="200px" /> ](https://github.com/distribution/distribution/actions/workflows/build.yml?query=workflow%3Abuild) ](https://github.com/distribution/distribution/actions?query=workflow%3Aconformance) ](LICENSE) Run the registry locally with the : ``` docker run -d -p 5000:5000 --restart always --name registry distribution/distribution:edge ``` NOTE: in order to run push/pull against the locally run registry you must allow your docker (containerd) engine to use insecure registry by editing `/etc/docker/daemon.json` and subsequently restarting it ``` { "insecure-registries": ["host.docker.internal:5000"] } ``` Now you are ready to use it: ``` docker pull alpine docker tag alpine localhost:5000/alpine docker push localhost:5000/alpine ``` Beware the default configuration uses and the above example command does not mount a local filesystem volume into the running container. If you wish to mount the local filesystem to the `rootdirectory` of the `filesystem` storage driver run the following command: ``` docker run -d -p 5000:5000 $PWD/FS/PATH:/var/lib/registry --restart always --name registry distribution/distribution:edge ``` If you don't wan to use the default configuration file, you can supply your own custom configuration file as follows: ``` docker run -d -p 5000:5000 $PWD/PATH/TO/config.yml:/etc/docker/registry/config.yml --restart always --name registry distribution/distribution:edge ``` For async communication and long-running discussions please use issues and pull requests on the . For sync communication we have a #distribution channel in the that everyone is welcome to join and chat about development.
Project: Druid (App Definition and Development / Database)
File: joins.md

id: joins title: "Joins" <!-- ~ Licensed to the Apache Software Foundation (ASF) under one ~ or more contributor license agreements. See the NOTICE file ~ distributed with this work for additional information ~ regarding copyright ownership. The ASF licenses this file ~ to you 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. --> Apache Druid has two features related to joining of data: operators. These are available using a in native queries, or using the in Druid SQL. Refer to the documentation for information about how joins work in Druid native queries, or the for information about how joins work in multi-stage query tasks. , simple key-to-value mappings. These are preloaded on all servers that are involved in queries and can be accessed with or without an explicit join operator. Refer to the documentation for more details. Whenever possible, for best performance it is good to avoid joins at query time. Often this can be accomplished by joining data before it is loaded into Druid. However, there are situations where joins or lookups are the best solution available despite the performance overhead, including: The fact-to-dimension (star and snowflake schema) case: you need to change dimension values after initial ingestion, and aren't able to reingest to do this. In this case, you can use lookups for your dimension tables. Your workload requires joins or filters on subqueries.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_project_metrics.md

+++ title = "googleprojectmetrics resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleprojectmetrics" identifier = "inspec/resources/gcp/googleprojectmetrics.md googleprojectmetrics resource" parent = "inspec/resources/gcp" +++ A `googleprojectmetrics` is used to test a Google Metric resource ```ruby describe googleprojectmetrics(project: 'chef-gcp-inspec') do it { should exist } its('metricfilters') { should include 'resource.type=gaeapp AND severity>=ERROR' } its('metric_names') { should include 'some/metric' } end describe.one do googleprojectmetrics(project: 'chef-gcp-inspec').metrictypes.each do |metrictype| describe metric_type do it { should match 'some/metric' } end end end ``` describe googleprojectmetrics(project: 'chef-inspec-gcp') do its('count') { should be <= 100} end describe googleprojectmetrics(project: 'chef-inspec-gcp') do its('metric_names') { should include "metric-name" } end googleprojectmetrics(project: 'chef-inspec-gcp').where(metricname: /project/).metricnames.each do |metric_name| describe googleprojectmetric(project: 'chef-inspec-gcp', metric: metric_name) do its('filter') { should eq "(protoPayload.serviceName=\"cloudresourcemanager.googleapis.com\")" } end end Properties that can be accessed from the `googleprojectmetrics` resource: See the resource for more information. `metric_names` : an array of `googleprojectmetric` name `descriptions` : an array of `googleprojectmetric` description `metric_filters` : an array of `googleprojectmetric` filter `metric_descriptors` : an array of `googleprojectmetric` metric_descriptor `label_extractors` : an array of `googleprojectmetric` label_extractors `value_extractors` : an array of `googleprojectmetric` value_extractor `bucket_options` : an array of `googleprojectmetric` bucket_options 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.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: host.md

+++ title = "host resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "host" identifier = "inspec/resources/os/host.md host resource" parent = "inspec/resources/os" +++ Use the `host` Chef InSpec audit resource to test the specific host name and its availability. This test includes the internet protocols and ports on which the respective host name must be available. The Chef InSpec distributes this resource. This resource is available from InSpec version 1.0. A `host` resource block declares a host name, a port, and a protocol. describe host('example.com', port: 80, protocol: 'tcp') do it { should be_reachable } it { should be_resolvable } its('ipaddress') { should include '12.34.56.78' } end where `host()` must specify a host name. The port number and protocol are optional values. `example.com` is the host name. `port` is the port number. `protocol` is the internet protocol, TCP (`protocol: 'tcp'`), UDP (`protocol: 'udp'`), and ICMP (`protocol: 'icmp'`) The `ipaddress` property returns the IP addresses of the host. its('ipaddress') { should include '93.184.216.34' } The `ipv4_address` property returns the IPv4 address of the host. its('ipv4_address') { should include '93.184.216.34' } The `ipv6_address` property returns the IPv6 addresses of the host. its('ipv6_address') { should include '2404:6800:4009:82a::200e' } The `connection` property returns the connection string. its('connection') { should match /connection refused/ } The `protocol` property returns the protocol the specified host uses. its('protocol') { should eq 'TCP' } its('socket') { should match /STATUS_OK/ } This Chef InSpec audit resource has the following special matchers. {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `be_reachable` matcher tests if the host name is available. it { should be_reachable } The `be_resolvable` matcher tests for host name resolution. For example, "resolvable to an IP address". it { should be_resolvable } describe host('example.com') do its('ipaddress') { should include '93.184.216.34' } end describe host('example.com') do its('ipv4_address') { should include '93.184.216.34' } end describe host('example.com') do its('ipv6_address') { should include '2404:6800:4009:82a::200e' } end describe host('example.com') do it { should be_resolvable } its('ipaddress') { should include '93.184.216.34' } end describe host('example.com', port: 80, protocol: 'tcp') do it { should be_reachable } end describe host('example.com', port: 12345, protocol: 'tcp') do it { should be_reachable } its('connection') { should_not match /connection refused/ } its('socket') { should match /STATUS_OK/ } end
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_iam_organization_custom_roles.md

+++ title = "googleiamorganizationcustomroles resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleiamorganizationcustomroles" identifier = "inspec/resources/gcp/googleiamorganizationcustomroles.md googleiamorganizationcustomroles resource" parent = "inspec/resources/gcp" +++ A `googleiamorganizationcustomroles` is used to test a Google OrganizationCustomRole resource ```ruby describe googleiamorganizationcustomroles(org_id: '190694428152') do its('names') { should include "organizations/123456/roles/role-id" } end ``` Properties that can be accessed from the `googleiamorganizationcustomroles` resource: See the resource for more information. `names` : an array of `googleiamorganizationcustomrole` name `titles` : an array of `googleiamorganizationcustomrole` title `descriptions` : an array of `googleiamorganizationcustomrole` description `included_permissions` : an array of `googleiamorganizationcustomrole` included_permissions `stages` : an array of `googleiamorganizationcustomrole` stage `deleteds` : an array of `googleiamorganizationcustomrole` deleted 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.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.25.md

layout: release date: 2022-11-14 tag: v0.6.25 language: en Fix prettification logic @Revolyssup (#6526) fix: the logic for toggler's disable and enable state @Abhishek-kumar09 (#6529) Newer Field Widgets UX . @harkiratsm (#6519) replace "Service Mesh Discussion forum" with 'Discussion Forum' @ayushthe1 (#6521) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Revolyssup, @ayushthe1, @harkiratsm and @leecalcote
Project: Chef InSpec (Provisioning / Security & Compliance)
File: platforms.md

+++ title = "InSpec Profile Platform Support" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "Platforms" identifier = "inspec/profiles/platforms" parent = "inspec/profiles" weight = 90 +++ Use the `supports` setting in the to specify one (or more) platforms for which a profile is targeting. The list of supported platforms may contain the following: Use `platform-family` to restrict to a specific platform family. Use `platform-name` to restrict on a specific platform name. `platform-name` supports asterisk (`*`) wildcard use. Use `release` to restrict to a specific platform version, and use together with `platform-name`. `release` supports asterisk (`*`) wildcard use. Use `platform` to restrict on either platform-name or platform-family. To get a list of all valid values for `platform-name` and `platform-family`, run `inspec schema platforms`, which returns the supported list in JSON format. For compatibility we support `os-name` and `os-family`. We recommend all users to change `os-name` to `platform-name` and `os-family` to `platform-family`. With Chef InSpec 2.0, we introduced new families to help distinguish the cloud platforms. The new families can restrict the platform family to `os`, `aws`, `azure` or `gcp`. For example, to target anything running Debian Linux, use: ```yaml name: ssh supports: platform-name: debian ``` To target only Ubuntu version 20.04, use: ```yaml name: ssh supports: platform-name: ubuntu release: 20.04 ``` To target the entire release of Ubuntu version 20.x, use: ```yaml name: ssh supports: platform-name: ubuntu release: 20.* ``` To target the Red Hat and derivative platforms such as CentOS and Oracle Linux, use: ```yaml name: ssh supports: platform-family: redhat ``` To target the entire Windows 2019 platform family, including Datacenter and Core Servers, use: ```yaml name: ssh supports: platform-name: windowsserver2019* ``` To target anything running on Amazon AWS, use: ```yaml name: ssh supports: platform: aws ``` To target all of these examples in a single `inspec.yml` file, use: ```yaml name: ssh supports: platform-name: debian platform-name: ubuntu release: 20.04 platform-family: redhat platform: aws ```
Project: ThreatMapper (Provisioning / Security & Compliance)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: "" labels: bug, needs-triage assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Components/Services affected [ ] UI/Frontend [ ] API/Backend [ ] Agent [ ] Deployment/YAMLs [ ] CI/CD Integration [ ] Other (specify) Additional context Add any other context about the problem here.
Project: KCL (Provisioning / Automation & Configuration)
File: E2H13.md

KCL will report `UnKnownDecoratorError` when an unknown decorator is used in KCL. The `ewcode` of `UnKnownDecoratorError` is `E2H13`. For example: ```python @err_deprecated # It is an unknown decorator schema Person: firstName: str = "John" lastName: str name: str JohnDoe = Person { name: "deprecated" } ``` The KCL program will cause the following error message. ```shell error[E2L23]: CompileError --> deprecated/unknownfail1/main.k:1:2 | 1 | @err_deprecated # This is a error decorator | ^ UnKnown decorator err_deprecated | ``` Possible resolution: Check whether the decorator exists.
Project: Falco (Provisioning / Security & Compliance)
File: 20191030-api.md

This is a proposal to better structure the Falco API. The Falco API is a set of contracts describing how users can interacts with Falco. By defining a set of interfaces the Falco Authors intend to decouple Falco from other software and data (eg., from the input sources) and, at the same time, make it more extensible. Thus, this document intent is to propose a list of services that constitute the Falco API (targeting the first stable version of Falco, v1.0.0). We want to enable users to use third-party clients to interface with Falco outputs, inputs, rules, and configurations. Such ability would enable the community to create a whole set of OSS tools, built on top of Falco. Some examples, already in place, are: To design and implement an API to make Falco more configurable To design and implement an API to make Falco more consumable To have an API so that users are able to interface with Falco To design a set of simple contract interfaces To have an API which is secure by default To implement this API in C++ using gRPC as a first implementation To replace the existing inputs: the inputs will be only for new source events users may want to add, initially To document the API: to be approached as separate task To create/update the API client: to be approached as a separate task Receive Falco events with a well-defined contract --> outputs Receive Falco drops with a well-defined contract --> drops Receive current Falco version and related meta information (commit hash, built type, etc.) --> version Configure Falco via API (CRUD) -> configs Inject and/or modify Falco rules via API (CRUD) --> rules Send input events to Falco --> inputs Version Rules Configs Outputs Drops Inputs We propose to have: 1 gRPC server 1 service grouping services This translates in having the following set of `proto` files. a `.proto` containing the request and response messages for each service - eg., `version.proto`, `outputs.proto` etc. For example, ```proto3 message request { ... } // The `response` message contains the version of Falco. // It provides the whole version as a string and also // its parts as per semver 2.0 specification (https://semver.org). message response { string version = 1; uint32 major = 2; uint32 minor = 3; uint32 patch = 4; string prerelease = 5; string build = 6; } ``` one or more `.proto` containing the command models - ie., the already existing `schema.proto` containing source enum, etc. ```proto3 enum priority { .. } enum source { option allow_alias = true; SYSCALL = 0; syscall = 0; Syscall = 0; K8S_AUDIT = 1; k8s_audit = 1; K8s_audit = 1; K8S_audit = 1; } ``` a `.proto` for service definitions For example, ```proto3 service api { rpc version(request) returns (response); rpc outputs(request) returns (stream response); rpc drops(request) returns (stream response); ... } ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: java-sdk.md

title: "Java SDK Roadmap" <!-- 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. --> Work to support the next LTS release of Java is in progress. For more details about the scope and info on the various tasks please see the GitHub Issue. GitHub:
Project: KICS (Provisioning / Security & Compliance)
File: 8ed0bfce-f780-46d4-b086-21c3628f09ad.md

title: SES Policy With Allowed IAM Actions hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 8ed0bfce-f780-46d4-b086-21c3628f09ad Query name: SES Policy With Allowed IAM Actions Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: SES policy should not allow IAM actions to all principals<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="5" name: add sending authorization policy to email identityyy community.aws.awssesidentity_policy: identity: example@example.com policy_name: ExamplePolicy policy: > { "Version": "2012-10-17", "Statement": [ { "Action": "*", "Principal": { "AWS": "*" }, "Effect": "Allow", "Resource": "*", "Sid": "" } ] } state: present ``` ```yaml title="Negative test num. 1 - yaml file" name: add sending authorization policy to email identity2 community.aws.awssesidentity_policy: identity: example@example.com policy_name: ExamplePolicy policy: > { "Version": "2012-10-17", "Statement": [ { "Action": "*", "Principal": { "AWS": "arn:aws:iam::987654321145:root" }, "Effect": "Allow", "Resource": "*", "Sid": "" } ] } state: present ```
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: pull_request_template.md

<!-- please add a description of what the goal of this pull request is --> <!-- please include links to related issues are RFCs, remove if not required --> Related Issues: fixes #000, closed #000 Related <!-- Please fill out the checklist below. If an RFC is required and not submitted yet the PR will be tagged as RFC required and blocked until the RFC is submitted and approved. As a rule of thumb, bugfixes or minimal additions that have no backwards impact and are fully self-contained usually do not require an RFC. Larger changes, changes to behavior, breaking changes usually do. If in doubt, please open a ticket for a PR first to discuss the issue. --> [ ] The RFC, if required, has been submitted and approved [ ] Any user-facing impact of the changes is reflected in docs.tremor.rs [ ] The code is tested [ ] Use of unsafe code is reasoned about in a comment [ ] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior [ ] The performance impact of the change is measured (see below) <!-- Measure or reason about the performance impact of the change. A rough indication is sufficient here, we often use the `real-world-json-throughput` example to cargo build -p tremor-cli --release (on main) ./bench/run real-workflow-throughput-json repeat on main Share the two throughput numbers and the benchmark that produced them. NOTE: We are fully aware this is not a perfect method, but it is a tradeoff between preventing large performance degradation and putting an unreasonable burden on contributors. NOTE: the total number is irrelevant as it will vary from system to system. The delta is what matters. If the benchmarks fail on your system, note it in the issue, and someone will try to run them for you. If your changes do not affect performance, and you can argue this, do it in this section, it is a valid response. -->