cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 2f37c4a3-58b9-4afe-8a87-d7f1d2286f84.md

title: IAM Policies With Full Privileges hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 2f37c4a3-58b9-4afe-8a87-d7f1d2286f84 Query name: IAM Policies With Full Privileges Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: IAM policies shouldn't allow full administrative privileges (for all resources)<br> ```tf title="Positive test num. 1 - tf file" hl_lines="19 5" resource "awsiamrole_policy" "positive1" { name = "apigateway-cloudwatch-logging" role = awsiamrole.apigatewaycloudwatchlogging.id policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["*"], "Resource": "*" } ] } EOF } data "awsiampolicy_document" "example" { statement { sid = "1" effect = "Allow" actions = [ "*" ] resources = [ "*", ] } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsiamrole_policy" "negative1" { name = "apigateway-cloudwatch-logging" role = awsiamrole.apigatewaycloudwatchlogging.id policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["some:action"], "Resource": "*" } ] } EOF } data "awsiampolicy_document" "example" { statement { sid = "1" effect = "Allow" actions = [ "*" ] resources = [ "arn:aws:s3:::*", ] } } ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: bug_report.md

name: Bug report about: Report a problem for the OPA community to investigate title: '' labels: bug assignees: '' <!-- Thanks for opening an issue to request a feature or file a bug! If you provide some basic information, it helps us address problems faster. --> <!-- Any information you think might be helpful. Examples include the environment where OPA was running (e.g., if inside Kubernetes, what resource limits did you configure OPA with?), how long OPA had been running for, what was happening around the time when you identified the problem, etc. Examples: OPA version Example query, input, data, and policy that OPA was given Example output that OPA returned For server and CLI, the flags/configuration that you provided to OPA For server, any relevant log messages from OPA For Go and Wasm, the arguments you invoked OPA with --> <!-- Go to '...' Click on '....' Scroll down to '....' See an error --> <!-- Describe what you expected to happen. --> <!-- Add any other context about the problem here. -->
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.9.23.md

RabbitMQ `3.9.23` is a maintenance release in the `3.9.x` release series. Please refer to the Upgrading to 3.9 section from if upgrading from a version prior to 3.9.0. This release requires at least Erlang 24.2, and supports Erlang 25. has more details on Erlang version requirements for RabbitMQ. Erlang 23 support has reached its . Starting with this release, RabbitMQ requires Erlang 24.2 or later versions. Nodes will fail to start on older Erlang releases. Erlang 25 as our new baseline means much improved performance on ARM64 architectures, across all architectures, and the most recent TLS 1.3 implementation available to all RabbitMQ 3.11 users. Nodes now default to 65536 concurrent client connections instead of using the effective kernel open file handle limit. Users who want to override this default, that is, have nodes that should support more concurrent connections and open files, now have to perform an additional configuration step: Pick a new limit value they would like to use, for instance, 100K Set the maximum open file handle limit (for example, via `systemd` or similar tooling) for the OS user used by RabbitMQ to 100K Set the to 100K This change was introduced because of a change in several Linux distributions: they now use a default open file handle limit so high, they cause a significant (say, 1.5 GiB) memory preallocated the Erlang runtime. For example, are examples of such distributions. The new default . See and for details. Release notes can be found on GitHub at . Force GC after definition import to reduce peak memory load by mostly idle nodes that import a lot of definitions. GitHub issue: Reduced log noise from exceptions connections could run into when a client was closings it connection end concurrently with other activity. GitHub issue: `rabbitmq-env-conf.bat on Windows could fail to load when its path contained spaces. GitHub issue: Stream declaration could run into an exception when stream parameters failed validation. GitHub issue: Some counters on the Overview page have been moved to global counters introduced in RabbitMQ 3.9. GitHub issue: A way to configure an authentication timeout, much like in some other protocols RabbitMQ supports. Contributed by @gomoripeti. GitHub issue: Avoid an exception when MQTT client closes TCP connection before server could fully process a `CONNECT` frame sent earlier by the same client. GitHub issue: A way to configure an authentication timeout, much like in some other protocols RabbitMQ supports. Contributed by @gomoripeti. GitHub issue: Service startup is now optional. More environment variables are respected by the installer. Contributed by @inikulshin. GitHub issues: `prometheus` upgraded to `eetcd` upgraded to To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.9.23.tar.xz` instead of the source tarball produced by GitHub.
Project: KubeArmor (Provisioning / Security & Compliance)
File: bug_report.md

name: Bug report about: Create a bug report to help us improve title: '' labels: bug assignees: '' <!-- If you have usage questions, please try the or first. Please check the list to check if there is an issue already in the context. --> General Information Environment description (GKE, VM-Kubeadm, vagrant-dev-env, minikube, microk8s, ...) Kernel version (run `uname -a`) Orchestration system version in use (e.g. `kubectl version`, ...) Link to relevant artifacts (policies, deployments scripts, ...) Target containers/pods To Reproduce Instruction 1 Instruction 2 Expected behavior A description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem.
Project: StarRocks (App Definition and Development / Database)
File: negative.md

displayed_sidebar: "English" Returns the negative of input `arg`. ```Plain negative(arg) ``` `arg` supports the following data types: BIGINT DOUBLE DECIMALV2 DECIMAL32 DECIMAL64 DECIMAL128 Returns a value of the same data type as the input. ```Plain mysql> select negative(3); +-+ | negative(3) | +-+ | -3 | +-+ 1 row in set (0.00 sec) mysql> select negative(cast(3.14 as decimalv2)); +--+ | negative(CAST(3.14 AS DECIMAL(9,0))) | +--+ | -3.14 | +--+ 1 row in set (0.01 sec) ```
Project: RBAC Manager (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, 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 the project team at opensource@fairwinds.com. 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
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: enhancement_request.md

name: Enhancement request about: Suggest an enhancement for this project labels: enhancement <!-- Thanks for filing an enhancement request ! --> Describe the problem you are trying to solve <!-- A clear and concise description of the problem this enhancement request is trying to solve. --> Describe the solution you'd like <!-- A clear and concise description of what you want to happen. --> Notes <!-- Any additional context or information you feel may be relevant to the issue. --> If this is an implementation of an provide a URL to the RFC this enhancement implements. If this is a major enhancement or contribution an RFC may be required. It is ok to submit an enhancement first and our core team will assist with major contributions. In general, major contributions should be discussed with the community before submission.
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: template_README.md

Brief description of {{ pkg_name }} Names of core plans maintainers (The Habitat Maintainers humans@habitat.sh is usually sufficient) This should state whether the package is a service package or a binary package. A service package is something that will be run by the Habitat supervisor (i.e. core/postgresql). A service package must always have a run file or define pkgsvcrun in the plan.sh file. A binary package is something that packages up a standalone binary, something that does not need to run under the Habitat supervisor (i.e. core/dep). They are often used as dependencies of other packages. Binary packages do not have a run file and do not need to define pkgsvcrun in the plan.sh file. How would a user use this package? i.e. can a user simply call the package as a dependency of their application? Or is there more they need to do? (This is only required for service packages, not ) How do other services that want to consume this service bind to it? Checkout README for a good example of this. (This is only required for service packages, not ) What topologies does this plan support? (This is only required for service packages, not ) Check out for more details on what the standalone topology is and what it does. If this plan can be used with the standalone topology, how do you do it? Checkout README for a good example of this. (This is only required for service packages, not ) If this plan can be used with the leader/follower topology, how do you do it? Check out for more details on what the leader-follower topology is and what it does. Checkout README for a good example of this (look under the Clustering heading) (This is only required for service packages, not ) What update strategies would work best for this plan? Checkout for information on the strategies Habitat supports. (This is only required for service packages, not ) Checkout the documentation for more information on what configuration updates are and how they are executed. Link to the plan's default.toml file to list all the configurable values of the plan. If your plan has configuration values that require a complete rebuild when updated, note those here. (This is only required for service packages, not ) (Optional, but recommended) How would a user scale this service? Can this service be run in a cluster and/or as high availability? (This is only required for service packages, not ) (Optional, but recommended) How would a user monitor the health of this surface at the application layer? This is separate from information about Habitat's HTTP API monitoring service. This section should include some suggestions about how someone could monitor the application or service outside of Habitat - i.e. using something like sumologic, logstash, etc. It does not need to be prescriptive, but should include some suggestions of where someone might start. (Optional) Anything that does not fit in the above sections should go here - i.e. how does this fit into a user's development workflow?
Project: DragonflyDB (App Definition and Development / Database)
File: faq.md

- - - Dragonfly is released under (Business Source License). BSL 1.1 is considered to be "source available" license and it's not strictly open-source license. We believe that a license is more permissive than licenses like AGPL, and it will allow us to provide a competitive commercial service using our technology. In general terms, it means that Dragonfly's code is free to use and free to change as long as you do not sell services directly related to Dragonfly or in-memory datastores. We followed the trend of other technological companies like Elastic, Redis, MongoDB, Cockroach labs, Redpanda Data to protect our rights to provide service and support for the software we are building. License wise you are free to use dragonfly in your production as long as you do not provide Dragonfly as a managed service. From a code maturity point of view, Dragonfly's code is covered with unit testing and the regression tests. However as with any new software there are use cases that are hard to test and predict. We advise you to run your own particular use case on dragonfly for a few days before considering production usage. We conducted our experiments using a load-test generator called `memtier_benchmark`, and we run benchmarks on AWS network-enhanced instance `c6gn.16xlarge` on recent Linux kernel versions. Dragonfly might reach smaller throughput on other instances, but we would still expect to reach around 1M+ qps on instances with 16-32 vCPUs. Dragonfly optimizes the use of underlying hardware, allowing it to run efficiently on instances as small as 8GB, and scale vertically to large 2TB machines with 128 cores. This versatility significantly reduces the complexity of running cluster workloads on a single node, saving hardware resources and costs. More importantly, it diminishes the total cost of ownership associated with managing multi-node clusters. In contrast, Redis in cluster mode imposes limitations on multi-key and transactional operations, whereas Dragonfly maintains the same semantics as a single-node Redis system. Furthermore, scaling out horizontally with small instances can lead to instability in production environments. We believe that large-scale deployments of in-memory stores require both vertical and horizontal scaling, which is not efficiently achievable with an in-memory store like Redis. Dragonfly implements ~190 Redis commands which we think represent a good coverage of the market. However this is not based empirical data. Having said that, if you have commands that are not covered, please feel free to open an issue for that or vote for an existing issue. We will do our best to prioritise those commands according to their popularity.
Project: Harbor (Provisioning / Container Registry)
File: 10-03-Clair-scan-0-package-image.md

Test 10-03 Trivy scan 0 package image ======= To verify trivy scan result of a 0 package image. User guide This test requires that a Harbor instance is running and available. Harbor is installed with trivy enable. A linux host with Docker CLI installed. Trivy has been updated to the latest. Login Harbor as admin. Create a project. Push a helloworld or busybox image to the created project. Scan the image. Step 4 result should be Severity:Unknown. None
Project: Crunchy Postgres Operator (App Definition and Development / Database)
File: pull_request_template.md

Checklist: <! Make sure your PR is documented and tested before submission. Put an `x` in all the boxes that apply: --> [ ] Have you added an explanation of what your changes do and why you'd like them to be included? [ ] Have you updated or added documentation for the change, as applicable? [ ] Have you tested your changes on all related environments with successful results, as applicable? [ ] Have you added automated tests? Type of Changes: <! What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> [ ] New feature [ ] Bug fix [ ] Documentation [ ] Testing enhancement [ ] Other What is the current behavior (link to any open issues here)? What is the new behavior (if this is a feature change)? [ ] Breaking change (fix or feature that would cause existing functionality to change) Other Information:
Project: Meshery (Provisioning / Automation & Configuration)
File: psmdb-db.md

layout: integration title: Percona Server for MongoDB subtitle: Collaborative and visual infrastructure as code for Percona Server for MongoDB image: /assets/img/integrations/psmdb-db/icons/color/psmdb-db-color.svg permalink: extensibility/integrations/psmdb-db docURL: https://docs.meshery.io/extensibility/integrations/psmdb-db description: integrations-category: Database integrations-subcategory: App Definition and Development registrant: Artifact Hub components: 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: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: tekton_tasks_repositories.md

Artifact Hub is able to process Tekton tasks listed in Tekton catalog repositories. It supports catalogs using the as well as catalogs using the newer and recommended . Repositories are expected to be hosted in GitHub, GitLab or Bitbucket. 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. It's important that `/path/to/packages` points to the directory that contains all the tasks. For more information about the structure of the Tekton catalog repository, please see the Tekton catalog official documentation ( and ). Most of the metadata Artifact Hub needs is extracted from the task's manifest file. However, there is some extra Artifact Hub specific metadata that you can set using some special annotations in the `manifest` file. For more information, please see the . There is an extra metadata file that you can add to your repository named , which can be used to setup features like or . This file must be located at the root of the repository. Tasks source GitHub URL: Repository URL used in Artifact Hub: `https://github.com/tektoncd/catalog/task` (please note how the tree/main part is not used)
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: development.md

This doc explains how to set up a development environment for Numaflow. 1.20+. . . 3.19 for compiling protocol buffers. 2.17 for generating API markdown. for running the UI. . A local Kubernetes cluster for development usage, pick either one of , , or . ```shell brew install kind kind create cluster kind export kubeconfig ``` Please install the metrics server if your local Kubernetes cluster does not bring it by default (e.g., Kind). Without the , we will not be able to see the pods in the UI. ```shell kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml kubectl patch -n kube-system deployment metrics-server --type=json -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]' ``` `make start` Build the source code, image, and install the Numaflow controller in the `numaflow-system` namespace. `make build` Binaries are placed in `./dist`. `make manifests` Regenerate all the manifests after making any base manifest changes. This is also covered by `make codegen`. `make codegen` Run after making changes to `./pkg/api/`. `make test` Run unit tests. `make test-*` Run one e2e test suite. e.g. `make test-kafka-e2e` to run the kafka e2e suite. `make Test*` Run one e2e test case. e.g. `make TestKafkaSourceSink` to run the `TestKafkaSourceSink` case in the kafka e2e suite. `make image` Build container image, and import it to `k3d`, `kind`, or `minikube` cluster if corresponding `KUBECONFIG` is sourced. `make docs` Convert the docs to GitHub pages, check if there's any error. `make docs-serve` Start on your local to host the docs generated Github pages.
Project: Stolon (App Definition and Development / Database)
File: stolonctl_promote.md

Promotes a standby cluster to a primary cluster Promotes a standby cluster to a primary cluster ``` stolonctl promote [flags] ``` ``` -h, --help help for promote -y, --yes don't ask for confirmation ``` ``` --cluster-name string cluster name --kube-context string name of the kubeconfig context to use --kube-namespace string name of the kubernetes namespace to use --kube-resource-kind string the k8s resource kind to be used to store stolon clusterdata and do sentinel leader election (only "configmap" is currently supported) --kubeconfig string path to kubeconfig file. Overrides $KUBECONFIG --log-level string debug, info (default), warn or error (default "info") --metrics-listen-address string metrics listen address i.e "0.0.0.0:8080" (disabled by default) --store-backend string store backend type (etcdv2/etcd, etcdv3, consul or kubernetes) --store-ca-file string verify certificates of HTTPS-enabled store servers using this CA bundle --store-cert-file string certificate file for client identification to the store --store-endpoints string a comma-delimited list of store endpoints (use https scheme for tls communication) (defaults: http://127.0.0.1:2379 for etcd, http://127.0.0.1:8500 for consul) --store-key string private key file for client identification to the store --store-prefix string the store base prefix (default "stolon/cluster") --store-skip-tls-verify skip store certificate verification (insecure!!!) --store-timeout duration store request timeout (default 5s) ``` - stolon command line client