cwielenb/CNCF-Dataset huggingface dataset:
Project: YugabyteDB (App Definition and Development / Database)
File: overview.md

title: Overview of YugabyteDB Query Layer headerTitle: Overview of YugabyteDB Query Layer linkTitle: Overview description: The YugabyteDB Query Layer is the upper layer of YugabyteDB. Applications interact directly with YQL using client drivers. menu: v2.18: identifier: architecture-query-layer-yql parent: architecture-query-layer weight: 1172 type: docs The YugabyteDB Query Layer (YQL) is the upper layer of YugabyteDB. Applications interact directly with YQL using client drivers. This layer deals with the API-specific aspects such as query and command compilation, as well as the runtime functions such as data type representations, built-in operations, and so on. YQL is designed with extensibility in mind, allowing for new APIs to be added. Currently, YQL supports two types of distributed SQL APIs: and . As per the preceding diagram, every YB-TServer is configured to support both types of query languages on different ports: port 5433 is the default port for YSQL and 9042 is the default port for YCQL. From the application perspective, YQL is stateless and the clients can connect to one or more YB-TServers on the appropriate port to perform operations against a YugabyteDB cluster. The YQL inside of each YB-TServer implements some API-specific aspects required for each of the supported APIs, but ultimately it is responsible for replication storage, and retrieval of data using DocDB, which is YugabyteDBs common underlying strongly-consistent and distributed store. The following are some of the subcomponents in YQL for each API: A statement cache that caches compiled or execution plans for prepared statements to avoid overheads associated with repeated parsing of statements. A command parser and execution layer. Language-specific built-in operations, data type encodings, and so on.
Project: KICS (Provisioning / Security & Compliance)
File: 48677914-6fdf-40ec-80c4-2b0e94079f54.md

title: IAM User Has Too Many Access Keys hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 48677914-6fdf-40ec-80c4-2b0e94079f54 Query name: IAM User Has Too Many Access Keys Platform: CloudFormation Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: Any IAM User should not have more than one access key since it increases the risk of unauthorized access and compromise credentials<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="10 14" AWSTemplateFormatVersion: "2010-09-09" Description: A sample template Resources: myuser: Type: AWS::IAM::User Properties: Path: "/" LoginProfile: Password: myP@ssW0rd firstKey: Type: AWS::IAM::AccessKey Properties: UserName: !Ref myuser secondKey: Type: AWS::IAM::AccessKey Properties: UserName: !Ref myuser ``` ```json title="Positive test num. 2 - json file" hl_lines="20 5" { "AWSTemplateFormatVersion": "2010-09-09", "Description": "A sample template", "Resources": { "secondKey": { "Type": "AWS::IAM::AccessKey", "Properties": { "UserName": "myuser" } }, "myuser": { "Type": "AWS::IAM::User", "Properties": { "LoginProfile": { "Password": "myP@ssW0rd" }, "Path": "/" } }, "firstKey": { "Type": "AWS::IAM::AccessKey", "Properties": { "UserName": "myuser" } } } } ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: "2010-09-09" Description: A sample template Resources: myuser: Type: AWS::IAM::User Properties: Path: "/" LoginProfile: Password: myP@ssW0rd firstKey: Type: AWS::IAM::AccessKey Properties: UserName: Ref: myuser ``` ```json title="Negative test num. 2 - json file" { "Resources": { "myuser": { "Type": "AWS::IAM::User", "Properties": { "Path": "/", "LoginProfile": { "Password": "myP@ssW0rd" } } }, "firstKey": { "Type": "AWS::IAM::AccessKey", "Properties": { "UserName": { "Ref": "myuser" } } } }, "AWSTemplateFormatVersion": "2010-09-09", "Description": "A sample template" } ```
Project: KICS (Provisioning / Security & Compliance)
File: 1239f54b-33de-482a-8132-faebe288e6a6.md

title: Google Storage Bucket Level Access Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 1239f54b-33de-482a-8132-faebe288e6a6 Query name: Google Storage Bucket Level Access Disabled Platform: GoogleDeploymentManager Severity: <span style="color:#bb2124">High</span> Category: Insecure Configurations URL: Google Storage Bucket Level Access should be enabled<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" resources: name: a-new-pubsub-topic1 type: storage.v1.bucket properties: storageClass: STANDARD location: EUROPE-WEST3 versioning: enabled: true iamConfiguration: uniformBucketLevelAccess: enabled: false ``` ```yaml title="Negative test num. 1 - yaml file" resources: name: a-new-pubsub-topic2 type: storage.v1.bucket properties: storageClass: STANDARD location: EUROPE-WEST3 versioning: enabled: true iamConfiguration: uniformBucketLevelAccess: enabled: true ```
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: moderation.md

These guidelines have been adapted from . In Lagoon spaces, strive to promote understanding, empathy, and increase personal awareness of all people. This includes people from across the Drupal Community and the greater Technical Community, even those you may personally disagree with. If kicked from the Discord, the kicked user can send a private message (PM) to the kicker or another Moderator, if desired, for re-admittance. If a disruptive person is engaging in what appears to be intentionally inflammatory, bullying, or harassing behavior provoking hostile responses (or acting in a hostile manner), kicking is faster and easier than trying to placate a disruptive person whose behavior is causing distress to other channel members. The kick is not a ban. There are times when disruptive or triggering comments and statements are genuine and break the lines of communication between two parties. By speaking with a Moderator, the (potentially) disruptive person can be coached on using more sensitive, inclusive, and diverse-aware language, and on engaging in a more constructive manner. Tier One Response User is welcomed in the channel, asked to read some scroll back, and given a link to participation guidelines. Tier Two Response User is gently reminded in channel to keep posts on topic, and/or of participation guidelines. Tier Three Response User is PMd by available Moderator to explain the problem(s) with their posts and given suggestions of what to do differently. Tier Four Response If behavior continues, User is kicked for no less than 24 hours from the Discord. Intentionally disruptive individuals get kicked, not tiered. Repeated offenses will result in a ban.
Project: SuperEdge (Provisioning / Automation & Configuration)
File: CONTRIBUTING.md

Welcome to SuperEdge! Please do check our before making contributions. Email: Slack: Fork the repository on GitHub Read the README.md for build instructions Reporting is one of the best ways to contribute. This is a rough outline of what a contributor's workflow looks like: Create a topic branch from where to base the contribution. This is usually master. Make commits of logical units. Make sure commit messages are in the proper format (see below). Push changes in a topic branch to a personal fork of the repository. Submit a pull request to . The PR must receive a LGTM from two maintainers found in the MAINTAINERS file. Thanks for contributing! *FORK* repository. The `Fork` button is in the top right corner of home page. *CLONE* repository. `git clone https://github.com/<yourname>/superedge.git` *SET REMOTE*. ``` git remote add upstream https://github.com/superedge/superedge.git git remote set-url --push upstream no-pushing ``` The coding style suggested by the Golang community is used in superedge. See the for details. We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why. ``` tunnel: add grpc interceptor to log info on incoming requests To improve debuggability of superedge. Added a grpc interceptor to log info on incoming requests to tunnel server. The log output includes remote client info, request content (with value field redacted), request handling latency, response size, etc. Uses zap logger if available, otherwise uses capnslog. Fixes #10 ``` The format can be described more formally as follows: ``` <package>: <what changed> <BLANK LINE> <why this change was made> <BLANK LINE> <footer> ``` If multiple files in a package are changed in a pull request for example: ``` tunnel/tunnel.go edgeadm/edgeadm.go ``` At the end of the review process if multiple commits exist for a single package they should be squashed/rebased into a single commit before being merged. ``` tunnel: <what changed> [..] ``` If a pull request spans many packages these commits should be squashed/rebased into a single commit using message with a more generic `*:` prefix. ``` *: <what changed> [..] ```
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: harbor-jobservice.md

Harbor-Jobservice requires a configuration file to start, which is located at `/etc/jobservice/config.yml` within the container. Any changes made to this config file are temporary and will not persist once the pod is restarted. The configmap from which this config file is generated is stored within Lagoon in the `services/harbor-jobservice/harbor-jobservice.yml` file. Any changes made to this configmap will be persisted across container restarts. `CORE_URL`* This value tells `harbor-jobservice` where `harbor-core` can be reached. The default value is `http://harbor-core:8080`. `CORE_SECRET`* This value is a pre-shared key that must match between the various services connecting to `harbor-core`. The default value is set to `secret123` when Harbor is run locally or during CI testing. This value is retrieved from a secret created when Harbor is first set up on a running Lagoon. `HTTP_PROXY`* The default value is an empty string. `HTTPS_PROXY`* The default value is an empty string. `JOBSERVICE_SECRET`* This value is a pre-shared key that must match between the various services connecting to `harbor-jobservice`. The default value is set to `secret123` when Harbor is run locally or during CI testing. This value is retrieved from a secret created when Harbor is first set up on a running Lagoon. `LOG_LEVEL`* The logging level this service should use. The default value is `error`. This can also be set to `debug` to enable very verbose logging. `NO_PROXY`* A list of hosts which should never have their requests proxied. The default is `harbor-core,harbor-jobservice,harbor-database,harbor-trivy,harborregistry,harbor-portal,127.0.0.1,localhost,.local,.internal`. `REGISTRY_CONTROLLER_URL`* This value tells the service where to connect to the `harborregistryctl` service. The default value is set to `http://harborregistryctl:8080` `SCANNER_LOG_LEVEL`* The logging level the scanning service should use. The default value is `error`. This can also be set to `debug` to enable very verbose logging. `SCANNER_STORE_REDIS_URL`* This value tells `harbor-trivy` how to connect to its Redis store. The default value is `redis://harbor-redis:6379/4`.
Project: SlimToolkit (Provisioning / Security & Compliance)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting urfave-governance@googlegroups.com, a members-only group that is world-postable. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: KICS (Provisioning / Security & Compliance)
File: 86f92117-eed8-4614-9c6c-b26da20ff37f.md

title: AKS RBAC Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 86f92117-eed8-4614-9c6c-b26da20ff37f Query name: AKS RBAC Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Azure Container Service (AKS) instance should have role-based access control (RBAC) enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="35 7" resource "azurermkubernetescluster" "positive1" { name = "example-aks1" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks1" rolebasedaccesscontrolenabled = false defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "azure" } } resource "azurermkubernetescluster" "positive2" { name = "example-aks2" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks2" rolebasedaccess_control { enabled = false } defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "calico" } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermkubernetescluster" "negative1" { name = "example-aks1" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name dns_prefix = "exampleaks1" rolebasedaccesscontrolenabled = true defaultnodepool { name = "default" node_count = 1 vmsize = "StandardD2_v2" } identity { type = "SystemAssigned" } tags = { Environment = "Production" } network_profile { network_policy = "azure" } } ```
Project: StarRocks (App Definition and Development / Database)
File: bitmap_xor.md

displayed_sidebar: "English" Calculates the set consisting elements unique to `lhs` and `rhs`. It is logically equivalent to `bitmapandnot(bitmapor(lhs, rhs), bitmap_and(lhs, rhs))` (complementary set). ```Haskell bitmap_xor(BITMAP lhs, BITMAP rhs) ``` ```plain text mysql> select bitmaptostring(bitmapxor(bitmapfromstring('1, 3'), bitmapfrom_string('2'))) cnt; ++ |cnt | ++ |1,2,3 | ++ ``` BITMAP_XOR, BITMAP
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: troubleshooting.md

id: troubleshooting title: Troubleshooting TechDocs sidebar_label: Troubleshooting description: Troubleshooting for TechDocs This may happen if you have TechDocs set up using the "out-of-the-box" configuration, wherein documentation is built dynamically by the TechDocs backend, and your TechDocs files are being pulled from a git-based source control management system (e.g. GitHub, BitBucket, etc). If you experience this, check that TechDocs-related files (e.g. markdown, assets, or the `mkdocs.yml` file) are not matched by an `export-ignore` attribute in a `.gitattributes` file in the relevant repository. TechDocs' backend is not able to see such files, and therefore may generate partial (or no) TechDocs as a result. You'll need to reconsider how you distribute tar archives based on your source code (and how you prevent internal documentation from being included in those archives). Alternatively, you could consider switching to the "recommended" TechDocs architecture (documentation generated and published in CI/CD). Using the , you can troubleshoot MkDocs build issues locally. Note this requires you have Docker available to launch images. First, `git clone` the target repository locally, then in the root of the repository, run: ``` npx @techdocs/cli serve ``` For example, if you have forgotten to put an MkDocs configuration file in your repo, the resulting error will be: ``` npx: installed 278 in 9.089s [techdocs-preview-bundle] Running local version of Backstage at http://localhost:3000 INFO - Building documentation... Config file '/content/mkdocs.yml' does not exist. ``` When it works, a local copy of both Backstage and your site will be launched locally: ``` npx: installed 278 in 9.682s [techdocs-preview-bundle] Running local version of Backstage at http://localhost:3000 INFO - Building documentation... WARNING - Config value: 'dev_addr'. Warning: The use of the IP address '0.0.0.0' suggests a production environment or the use of a proxy to connect to the MkDocs server. However, the MkDocs' server is intended for local development purposes only. Please use a third party production-ready server instead. INFO - Cleaning site directory DEBUG - Successfully imported extension module "plantuml_markdown". DEBUG - Successfully loaded extension "plantuml_markdown.PlantUMLMarkdownExtension". INFO - Documentation built in 0.23 seconds [I 210115 19:00:45 server:335] Serving on http://0.0.0.0:8000 INFO - Serving on http://0.0.0.0:8000 [I 210115 19:00:45 handlers:62] Start watching changes INFO - Start watching changes [I 210115 19:00:45 handlers:64] Start detecting changes INFO - Start detecting changes ``` The MkDocs plugin available in supports different formats for rendering diagrams. TechDocs does however not support all of them. The `svg_object` format renders a diagram as an HTML `<object>` tag but this is not allowed as it enables bad actors to inject malicious content into documentation pages. See for more details. Instead use `svg_inline` which renders as an `<svg>` tag and provides the same benefits as `svg_object`.
Project: KICS (Provisioning / Security & Compliance)
File: ad9dabc7-7839-4bae-a957-aa9120013f39.md

title: Lambda With Vulnerable Policy hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ad9dabc7-7839-4bae-a957-aa9120013f39 Query name: Lambda With Vulnerable Policy Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Access Control URL: The attribute 'action' should not have wildcard<br> ```tf title="Positive test num. 1 - tf file" hl_lines="35" provider "aws" { region = "us-east-1" } resource "awslambdafunction" "my-lambda" { filename = "~/Downloads/lambda.json.zip" function_name = "my-lambda" role = awsiamrole.lambda-role.arn handler = "lambdafunction.lambdahandler" runtime = "python3.8" } resource "awsiamrole" "lambda-role" { name = "lambda-role" assumerolepolicy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Action": "sts:AssumeRole", "Principal": { "Service": "lambda.amazonaws.com" }, "Effect": "Allow", "Sid": "" } ] } EOF } resource "awslambdapermission" "all" { statement_id = "AllowAllResources" action = "lambda:*" functionname = awslambdafunction.my-lambda.functionname principal = "s3.amazonaws.com" source_arn = "arn:aws:s3:::delete-me-us-east-1-permissions-tests" source_account = "111111111111" qualifier = awslambdaalias.my-lambda-alias.name } resource "awslambdaalias" "my-lambda-alias" { name = "v1" description = "a sample description" functionname = awslambdafunction.my-lambda.functionname function_version = "$LATEST" } ``` ```tf title="Negative test num. 1 - tf file" resource "awslambdapermission" "allow_cloudwatch" { statement_id = "AllowExecutionFromCloudWatch" action = "lambda:InvokeFunction" functionname = awslambdafunction.testlambda.function_name principal = "events.amazonaws.com" source_arn = "arn:aws:events:eu-west-1:111122223333:rule/RunDaily" qualifier = awslambdaalias.test_alias.name } resource "awslambdaalias" "test_alias" { name = "testalias" description = "a sample description" functionname = awslambdafunction.testlambda.function_name function_version = "$LATEST" } resource "awslambdafunction" "test_lambda" { filename = "lambdatest.zip" functionname = "lambdafunction_name" role = awsiamrole.iamforlambda.arn handler = "exports.handler" runtime = "nodejs12.x" } resource "awsiamrole" "iamforlambda" { name = "iamforlambda" assumerolepolicy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Sid = "" Principal = { Service = "lambda.amazonaws.com" } }, ] }) } ```