cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 39750e32-3fe9-453b-8c33-dd277acdb2cc.md

title: Disk Encryption Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 39750e32-3fe9-453b-8c33-dd277acdb2cc Query name: Disk Encryption Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: Disks should have encryption enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "aliclouddisk" "diskencryption1" { availability_zone = "cn-beijing-b" name = "New-disk" description = "Hello ecs disk." category = "cloud_efficiency" size = "30" tags = { Name = "TerraformTest" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="8" resource "aliclouddisk" "diskencryption2" { availability_zone = "cn-beijing-b" name = "New-disk" description = "Hello ecs disk." category = "cloud_efficiency" size = "30" encrypted = false kmskeyid = "2a6767f0-a16c-4679-a60f-13bf*" tags = { Name = "TerraformTest" } } ``` ```tf title="Negative test num. 1 - tf file" resource "aliclouddisk" "diskencryption3" { availability_zone = "cn-beijing-b" name = "New-disk" description = "Hello ecs disk." category = "cloud_efficiency" size = "30" encrypted = true kmskeyid = "2a6767f0-a16c-4679-a60f-13bf*" tags = { Name = "TerraformTest" } } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.7.31.md

layout: release date: 2024-03-11 tag: v0.7.31 bump meshkit to v0.7.18 @MUzairS15 (#10532) bump sistent @captain-Akshay (#10529) Bump eslint-config-next from 14.1.0 to 14.1.3 in /provider-ui @dependabot (#10527) Bump eslint-config-next from 14.1.0 to 14.1.3 in /provider-ui @dependabot (#10527) Thank you to our contributors for making this release possible: @MUzairS15, @captain-Akshay, @dependabot and @leecalcote
Project: Copa (Provisioning / Security & Compliance)
File: SECURITY.md

Copacetic remains in the process of getting to a stable v1.0 release, and as such does not currently provide a long-term supported version. We make a good faith effort to respond to security issues in a timely manner and will release version updates as needed to address them. Users should expect to upgrade to the latest release version to stay current on security updates. We will publish known vulnerabilities through a once they have been addressed to inform the community of their potential scope, impact, and mitigation. Project Copacetic and its maintainers takes the security of the project seriously, and we appreciate your efforts to responsibly disclose your findings to us. Please do not report security vulnerabilities through public GitHub issues. Instead, please report them through our form. Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) Full paths of source file(s) related to the manifestation of the issue The location of the affected source code (tag/branch/commit or direct URL) Any special configuration required to reproduce the issue Step-by-step instructions to reproduce the issue Proof-of-concept or exploit code (if possible) Impact of the issue, including how an attacker might exploit the issue This information will help us triage your report more quickly. We believe in and will work with you through the private advisory report. We prefer all communications to be in English.
Project: CloudEvents (App Definition and Development / Streaming & Messaging)
File: contributors.md

<!-- no verify-links --> We welcome you to join us! This list acknowledges those who contribute whether it be via GitHub pull request or in real life in the project, as well as those who contributed before this became a CNCF project. If you are participating in some way, please add your information via pull request. This list is intended to build community, helping the project to connect github handles to real world identities and get to know each other, and for new folks to see who has been involved already. Contributions do not constitute an official endorsement. Alibaba Ryan Zhang - Haoran Yang, Hongqi Wang Heng Du - Amazon Arun Gupta, Ajay Nair, Rob Leidle, Orr Weinstein commercetools Christoph Neijenhuis - Confluent Neil Avery - Google Sarah Allen - Rachel Myers - Thomas Bouldin - Mike McDonald, Morgan Hallmon, Robert-Jan Huijsman Scott Nichols - Jon Skeet - Huawei Cathy Hong Zhang - Louis Fourie - IBM Doug Davis - Daniel Krook - Matt Rutkowski - Michael M Behrendt - Iguazio Yaron Haviv - Orit Nissan-Messing - Intel David Lyle - Lightbend James Roper - Linkall Jie Ding - Microsoft Clemens Vasters - Bahram Banisadr - Dan Rosanova - Cesar Ruiz-Meraz, Raja Ravipati Oracle Chad Arimura - Stanley Halka - Travis Reeder - Red Hat Jim Curtis - William Markito Oliveira - Gunnar Morling - Tihomir Surdilovic - Lance Ball - SAP Nathan Oyler - Stevo Slavi - Klaus Deissner - Serverless Inc Austen Collins - Rupak Ganguly - Brian Neisler - Jeremy Coffield, Ganesh Radhakirshnan SolarWinds Lee Calcote - VMWare Mark Peek - Individuals Rmi Cattiau - Jem Day - Vladimir Bacvanski
Project: KUDO (App Definition and Development / Application Definition & Image Build)
File: 0005-cluster-resources-for-crds.md

kep-number: 5 title: Cluster Resources for CRDs short-description: Cluster Resources for CRDs authors: "@runyontr" owners: "@runyontr" editor: TBD creation-date: 2019-02-18 last-updated: 2019-02-19 status: provisional In order to enable the creation use of certain CRDs, some cluster scoped objects may need to be created. This should not be part of the creation of a particular CRD instantiation since the deletion of that instance would remove the dependency from all objects. Allowing an Operator or OperatorVersion to define a set of Cluster objects that are present to support the creation and management of CRDs would circumvent the CRD from having to create and manage the object. * * * * In order to enable the creation use of certain CRDs, some cluster scoped objects, or common objects, may need to be created. This should not be part of the creation of a particular CRD instantiation since the deletion of that instance would remove the dependency from all objects. Allowing an Operator or OperatorVersion to define a set of Cluster objects that are present to support the creation and management of CRDs would circumvent the CRD from having to create and manage the object. Allow the creation of common Kubernetes components in support of running a CRD. A mechanism for CRDs to create cluster scoped objects. A database Operator may want a Restic server deployed as part of the Operator to provide a central location for storing backups. The capability here would define a namespace, service and deployment that provides Restic to the instance of the Operator to use by default. An Operator could leverage a MutatingWebHook for modifying pods deployments based on Node metadata (e.g. use a different image for nodes configured with GPU, PMEM, etc) The creation of a CRD should be controlled by a ClusterRole that defines permissions on who can create instances of the CRD. These should probably be created OperatorVersions require the existance of CRDs that are not controlled by Kudo (e.g. ETCD Operator) and require those to be installed when FV is enabled. The MySQL Operator could be modified to deploy a central repo for backups and leverage those in each instance of MySQL Initial KEP - 20190218 More complicated Operator/OperatorVersion specs Implications of OperatorVersion installation making MORE cluster level changes than just a CRD. Security around leveraging the common component. If deploying minio for backups, how do we ensure Instances don't restore someone else's data, or overwrite someone else's backup? Shared Components: What happens when two different Operators require the same common object?
Project: Meshery (Provisioning / Automation & Configuration)
File: amd-gpu.md

layout: integration title: AMD GPU subtitle: Collaborative and visual infrastructure as code for AMD GPU image: /assets/img/integrations/amd-gpu/icons/color/amd-gpu-color.svg permalink: extensibility/integrations/amd-gpu docURL: https://docs.meshery.io/extensibility/integrations/amd-gpu description: integrations-category: Provisioning integrations-subcategory: Automation & Configuration registrant: Artifact Hub components: name: node-feature colorIcon: assets/img/integrations/amd-gpu/components/node-feature/icons/color/node-feature-color.svg whiteIcon: assets/img/integrations/amd-gpu/components/node-feature/icons/white/node-feature-white.svg description: name: node-feature-rule colorIcon: assets/img/integrations/amd-gpu/components/node-feature-rule/icons/color/node-feature-rule-color.svg whiteIcon: assets/img/integrations/amd-gpu/components/node-feature-rule/icons/white/node-feature-rule-white.svg description: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: ArangoDB (App Definition and Development / Database)
File: outcome_throw_as_system_error_with_payload_std_error_code.md

+++ title = "`void outcomethrowassystemerrorwithpayload(const std::error_code &)`" description = "Specialisation of `outcomethrowassystemerrorwithpayload()` for `std::error_code`." +++ A specialisation of `outcomethrowassystemerrorwithpayload()` for `std::errorcode`. This executes {{% api "BOOSTOUTCOMETHROWEXCEPTION(expr)" %}} with a {{% api "std::system_error" %}} constructed from the input. Overridable: Argument dependent lookup. Requires: Nothing. Namespace: `std` Header: `<boost/outcome/std_result.hpp>`
Project: Apache Heron (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTING.md

<!-- 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. --> Discussion about Heron happens on GitHub and over the mailing list. GitHub: Heron User Group: Community is critical to Heron. Contributions are welcomed! You can first read the following pages to have a basic understanding of Heron: Heron includes a script to bootstrap an IntelliJ IDEA project. The project includes support for Heron code styles and copyright headers. To bootstrap an IDEA project run the following from the root folder of the repo:: ```bash $ ./scripts/setup-intellij.sh ``` Alternatively, you may install the Bazel plugin from the Intellij Marketplace and utilize it to automatically configure the IDE. File -> Import Bazel Project... Workspace: Select the root folder for the Heron codebase. Generate from BUILD file: select the BUILD file in the Heron source root directory. Finish. This will open up the Heron project and initiate a Bazel build. Once completed the IDE should be fully configured. To bootstrap an Eclipse project fun the following from the root folder of the repo: ```bash $ ./scripts/setup-eclipse.sh ``` In general, contributions that fix bugs or add features (as opposed to stylistic, refactoring, or "cleanup" changes) are preferred. If you're looking for places to contribute, issues with label are good candidates. Please check with the if your patch involves lots of changes. If you have any question or issues about troubleshooting, you should post on instead of opening GitHub issues. Discuss your plan and design, and get agreement on . Implement proper unit tests along with your change. Verify that all tests can pass. Submit a GitHub pull request that includes your change and test cases. Describe clearly in your pull request the changes made. Verify that Travis CI passes. Complete a code review by addressing the reviewer's comments. A project committer will merge the patch to the master branch.
Project: Druid (App Definition and Development / Database)
File: druid-vs-kudu.md

id: druid-vs-kudu title: "Apache Druid vs Kudu" <!-- ~ 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. --> Kudu's storage format enables single row updates, whereas updates to existing Druid segments requires recreating the segment, so theoretically the process for updating old values should be higher latency in Druid. However, the requirements in Kudu for maintaining extra head space to store updates as well as organizing data by id instead of time has the potential to introduce some extra latency and accessing of data that is not needed to answer a query at query time. Druid summarizes/rollups up data at ingestion time, which in practice reduces the raw data that needs to be stored significantly (up to 40 times on average), and increases performance of scanning raw data significantly. Druid segments also contain bitmap indexes for fast filtering, which Kudu does not currently support. Druid's segment architecture is heavily geared towards fast aggregates and filters, and for OLAP workflows. Appends are very fast in Druid, whereas updates of older data are higher latency. This is by design as the data Druid is good for is typically event data, and does not need to be updated too frequently. Kudu supports arbitrary primary keys with uniqueness constraints, and efficient lookup by ranges of those keys. Kudu chooses not to include the execution engine, but supports sufficient operations so as to allow node-local processing from the execution engines. This means that Kudu can support multiple frameworks on the same data (e.g., MR, Spark, and SQL). Druid includes its own query layer that allows it to push down aggregations and computations directly to data processes for faster query processing.
Project: YugabyteDB (App Definition and Development / Database)
File: cloudformation.md

title: Deploy on Amazon Web Services using AWS CloudFormation headerTitle: Amazon Web Services linkTitle: Amazon Web Services description: Deploy a YugabyteDB cluster on Amazon Web Services using AWS CloudFormation menu: v2.18: identifier: deploy-in-aws-1-cloudformation parent: public-clouds weight: 630 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../cloudformation/" class="nav-link active"> <i class="icon-shell"></i> CloudFormation </a> </li> <li > <a href="../terraform/" class="nav-link"> <i class="icon-shell"></i> Terraform </a> </li> <li> <a href="../manual-deployment/" class="nav-link"> <i class="icon-shell"></i> Manual deployment </a> </li> </ul> You need to have an IAM user who has `AWSCloudFormationFullAccess`, `AmazonEC2FullAccess` and `ssm:GetParameters` privilege. If you are going to create the stack via AWS Console then make sure the user also has `s3:CreateBucket`, `s3:PutObject` and `s3:GetObject` policies. Create an SSH key pair that you want to attach to the nodes. In the region you want to bring up the stack, make sure you can launch new VPCs. Download the template file. ```sh $ wget https://raw.githubusercontent.com/yugabyte/aws-cloudformation/master/yugabyte_cloudformation.yaml ``` {{< note title="Note" >}} When using an instance with local disks (as opposed to EBS), the `.yaml` file needs to be changed for YugabyteDB to recognize the local disks, as per that demonstrates the use of different instance types. {{< /note >}} Create CloudFormation template: ```sh $ aws cloudformation create-stack \ --stack-name <stack-name> \ --template-body file://yugabyte_cloudformation.yaml \ --parameters ParameterKey=DBVersion,ParameterValue=2.1.6.0-b17 ParameterKey=KeyName,ParameterValue=<ssh-key-name> \ --region <aws-region> ``` Once resource creation completes, check that stack was created: ```sh $ aws cloudformation describe-stacks \ --stack-name <stack-name> \ --region <aws-region> ``` From this output, you can get the VPC ID and YugabyteDB Admin URL. Because the stack creates a security group that restricts access to the database, you might need to update the security group inbound rules if you have trouble connecting to the DB. Navigate to your AWS console and open the CloudFormation dashboard. Click Create Stack. Prepare a template using the downloaded template. Specify the template file downloaded in Prerequisites: `yugabyte_cloudformation.yaml` Provide the required parameters. Each of these fields is prefilled with information from the configuration YAML file that was uploaded. `LatestAmiId` refers to the ID of the machine image to use, see . Configure stack options. For more information, see . Finalize changes before creation. Check stack output in the dashboard.
Project: YDB (App Definition and Development / Database)
File: SYSTEM_REQUIREMENTS.md

<!-- *LicensedundertheApacheLicense,Version2.0(the"License"); *youmaynotusethisfileexceptincompliancewiththeLicense. *YoumayobtainacopyoftheLicenseat *http://www.apache.org/licenses/LICENSE-2.0 *Unlessrequiredbyapplicablelaworagreedtoinwriting,software *distributedundertheLicenseisdistributedonan"ASIS"BASIS, *WITHOUTWARRANTIESORCONDITIONSOFANYKIND,eitherexpressorimplied. *SeetheLicenseforthespecificlanguagegoverningpermissionsand *limitationsundertheLicense. */--> This document provides details about hardware, operating system, and software prerequisites for the oneAPI Threading Building Blocks (oneTBB). - Intel(R) Celeron(R) processor family Intel(R) Core* processor family Intel(R) Xeon(R) processor family Intel(R) Xeon Phi* processor family Intel(R) Atom* processor family Non-Intel(R) processors compatible with the processors listed above Systems with Microsoft Windows operating systems Microsoft Windows 10 Microsoft Windows Server 2016 Microsoft Windows Server 2019 Systems with Linux* operating systems Clear Linux* Amazon* Linux 2 CentOS* 8 Debian* 10 Fedora* 34 Red Hat Enterprise Linux 7, 8 SuSE Linux Enterprise Server 15 Ubuntu* 18.04 LTS, 20.04, 21.04 Systems with macOS* operating systems macOS* 10.15, 11.x Systems with Android* operating systems Android* 9 Intel* oneAPI DPC++/C++ Compiler Intel* C++ Compiler 19.0 and 19.1 version Microsoft Visual C++ 14.1 (Microsoft Visual Studio 2017, Windows OS only) Microsoft Visual C++ 14.2 (Microsoft Visual Studio 2019, Windows OS only) For each supported Linux* operating system, the standard gcc version provided with that operating system is supported GNU Compilers (gcc) 4.8.5 - 11.1.1 GNU C Library (glibc) version 2.17 - 2.33 Clang* 6.0.0 - 12.0.0
Project: KICS (Provisioning / Security & Compliance)
File: 7350fa23-dcf7-4938-916d-6a60b0c73b50.md

title: CMK Is Unusable hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 7350fa23-dcf7-4938-916d-6a60b0c73b50 Query name: CMK Is Unusable Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Availability URL: AWS Key Management Service (KMS) must only possess usable Customer Master Keys (CMK), which means the CMKs must have the attribute 'is_enabled' set to true<br> ```tf title="Positive test num. 1 - tf file" hl_lines="3" resource "awskmskey" "a" { description = "KMS key 1" is_enabled = false } ``` ```tf title="Negative test num. 1 - tf file" resource "awskmskey" "a3" { description = "KMS key 1" is_enabled = true } ```
Project: sso (Provisioning / Key Management)
File: 2018-08-16-circuit-breaker.md

Gracefully handle provider-side faults and failures. Status: Implemented SS fundamentally relies on a third-party provider service to authenticate requests (e.g. OAuth2 via Google). The provider may experience transient faults for any number of reasons - perhaps the provider is experiencing a transient outage, or our traffic has been temporarily rate limited. We wanted to build SS to anticipate and handle the presence of faults during communication with authentication providers, no matter the underlying cause. We implemented a generic `circuit.Breaker` type, which implements the "Circuit Breaker" design pattern made popular by Michael T. Nygard's book, ["Release It!"]( https://pragprog.com/book/mnee/release-it). All requests to the provider service are issued through a stateful `circuit.Breaker` instance, which tracks the frequency of request failures. When the `Breaker` sees that enough requests are failing, it temporarily suspends all outgoing traffic to the provider (i.e. "enters `Open` state). After some time, the `Breaker` transitions to a `HalfOpen` state, in which a limited number of outbound requests are allowed. If failures persist, then the `Breaker` will once again suspend outbound traffic, re-enter `Open` state, and typically will wait for a longer interval of time before trying again. If instead the `Breaker` observes that requests are consistently succeeding, then it will resume all outbound traffic (i.e. enter `Closed` state). The SS directory contains a [Circuit Breaker]( /docs/architecture/circuit-breaker.md) document with more details. The implementation can be found in SS now utilizes a robust and generic strategy for handling faults originating from the upstream authentication provider service.
Project: KubeVirt (App Definition and Development / Application Definition & Image Build)
File: README_VGPU.md

Provides a pre-deployed k8s cluster that runs using The cluster is completely ephemeral and is recreated on every cluster restart. The KubeVirt containers are built on the local machine and are then pushed to a registry which is exposed at `localhost:5000`. The following needs to be executed as root. ```bash export KUBEVIRT_PROVIDER=kind-1.x-vgpu make cluster-up ``` The cluster can be accessed as usual: ```bash $ cluster-up/kubectl.sh get nodes NAME STATUS ROLES AGE VERSION vgpu-control-plane Ready master 6m14s v1.x.y ``` ```bash make cluster-down ``` This destroys the whole cluster. In order to use a custom kind image / kind version, export KINDNODEIMAGE, KIND_VERSION before running cluster-up. For example in order to use kind 0.9.0 (which is based on k8s-1.19.1) use: ```bash export KINDNODEIMAGE="kindest/node:v1.19.1@sha256:98cf5288864662e37115e362b23e4369c8c4a408f99cbc06e58ac30ddc721600" export KIND_VERSION="0.9.0" ``` This allows users to test or use custom images / different kind versions before making them official. See https://github.com/kubernetes-sigs/kind/releases for details about node images according to the kind version. In order to use `make cluster-down` please make sure the right `CLUSTER_NAME` is exported.