cwielenb/CNCF-Dataset huggingface dataset:
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.11.7.md

RabbitMQ `3.11.7` is a maintenance release in the `3.11.x` . Please refer to the upgrade section from if upgrading from a version prior to 3.11.0. This release requires Erlang 25. has more details on Erlang version requirements for RabbitMQ. As of 3.11.0, RabbitMQ requires Erlang 25. 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. Release notes can be found on GitHub at . `directexchangerouting_v2` feature flag could sometimes fail to enable on freshly started nodes. GitHub issue: Improvements to the feature flag subsystem. GitHub issues: , , Preserve additional information in the log message when heartbeat frame cannot be sent due to a TCP timeout. GitHub issue: `rabbitmqctl add_vhost` now coerces a single string value of `--tags` into an array. GitHub issue: Core server did not correctly translate empty stream message bodies to AMQP 0-9-1 when a stream was consumed by an AMQP 0-9-1 (as opposed to RabbitMQ Stream protocol) client. GitHub issue: `ERROR` frames delivery is now correctly delivered w.r.t. TCP connection closure for clients that run into certain types of exceptions. Contributed by @csicar. GitHub issue: `prometheus.erl` was upgraded To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.11.7.tar.xz` instead of the source tarball produced by GitHub.
Project: YugabyteDB (App Definition and Development / Database)
File: concepts.md

Definitions of the terms used in this project ============================================================================== Two main strategies are used: Dynamic Masking* offers an altered view of the real data without modifying it. Some users may only read the masked data, others may access the authentic version. Permanent Destruction* is the definitive action of substituting the sensitive information with uncorrelated data. Once processed, the authentic data cannot be retrieved. The data can be altered with several techniques: Deletion or Nullification* simply removes data. Static Substitution* consistently replaces the data with a generic value. For instance: replacing all values of a TEXT column with the value "CONFIDENTIAL". Variance* is the action of "shifting" dates and numeric values. For example, by applying a +/- 10% variance to a salary column, the dataset will remain meaningful. Generalization* reduces the accuracy of the data by replacing it with a range of values. Instead of saying "Bob is 28 years old", you can say "Bob is between 20 and 30 years old". This is useful for analytics because the data remains true. Shuffling* mixes values within the same columns. This method is open to being reversed if the shuffling algorithm can be deciphered. Randomization replaces sensitive data with random-but-plausible* values. The goal is to avoid any identification from the data record while remaining suitable for testing, data analysis and data processing. Partial scrambling* is similar to static substitution but leaves out some part of the data. For instance : a credit card number can be replaced by '40XX XXXX XXXX XX96' Custom rules* are designed to alter data following specific needs. For instance, randomizing simultaneously a zipcode and a city name while keeping them coherent. Pseudonymization is a way to protect* personal information by hiding it using additional information. Encryption and Hashing are two examples of pseudonymization techniques. However a pseudonymizated data is still linked to the original data.
Project: KICS (Provisioning / Security & Compliance)
File: 8f3c16b3-354d-45db-8ad5-5066778a9485.md

title: Group With Privilege Escalation By Actions 'glue:UpdateDevEndpoint' hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 8f3c16b3-354d-45db-8ad5-5066778a9485 Query name: Group With Privilege Escalation By Actions 'glue:UpdateDevEndpoint' Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Group with privilege escalation by actions 'glue:UpdateDevEndpoint' and Resource set to '*'. For more information see https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "awsiamgroup" "cosmic" { name = "cosmic" } resource "awsiamgrouppolicy" "testinline_policy" { name = "testinlinepolicy" group = awsiamgroup.cosmic.name policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = [ "glue:UpdateDevEndpoint", ] Effect = "Allow" Resource = "*" }, ] }) } ``` ```tf title="Negative test num. 1 - tf file" resource "awsiamuser" "cosmic2" { name = "cosmic2" } resource "awsiamuserpolicy" "inlinepolicyruninstances2" { name = "inlinepolicyrun_instances" user = awsiamuser.cosmic2.name policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = [ "ec2:Describe*", ] Effect = "Allow" Resource = "*" }, ] }) } ```
Project: Meshery (Provisioning / Automation & Configuration)
File: apisix.md

layout: integration title: Apisix subtitle: Collaborative and visual infrastructure as code for Apisix image: /assets/img/integrations/apisix/icons/color/apisix-color.svg permalink: extensibility/integrations/apisix docURL: https://docs.meshery.io/extensibility/integrations/apisix description: integrations-category: Provisioning integrations-subcategory: Security & Compliance registrant: Artifact Hub components: name: apisix-route colorIcon: assets/img/integrations/apisix/components/apisix-route/icons/color/apisix-route-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-route/icons/white/apisix-route-white.svg description: name: apisix-cluster-config colorIcon: assets/img/integrations/apisix/components/apisix-cluster-config/icons/color/apisix-cluster-config-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-cluster-config/icons/white/apisix-cluster-config-white.svg description: name: apisix-consumer colorIcon: assets/img/integrations/apisix/components/apisix-consumer/icons/color/apisix-consumer-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-consumer/icons/white/apisix-consumer-white.svg description: name: apisix-global-rule colorIcon: assets/img/integrations/apisix/components/apisix-global-rule/icons/color/apisix-global-rule-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-global-rule/icons/white/apisix-global-rule-white.svg description: name: apisix-plugin-config colorIcon: assets/img/integrations/apisix/components/apisix-plugin-config/icons/color/apisix-plugin-config-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-plugin-config/icons/white/apisix-plugin-config-white.svg description: name: apisix-tls colorIcon: assets/img/integrations/apisix/components/apisix-tls/icons/color/apisix-tls-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-tls/icons/white/apisix-tls-white.svg description: name: apisix-upstream colorIcon: assets/img/integrations/apisix/components/apisix-upstream/icons/color/apisix-upstream-color.svg whiteIcon: assets/img/integrations/apisix/components/apisix-upstream/icons/white/apisix-upstream-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: KICS (Provisioning / Security & Compliance)
File: e29a75e6-aba3-4896-b42d-b87818c16b58.md

title: Redis Cache Allows Non SSL Connections hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e29a75e6-aba3-4896-b42d-b87818c16b58 Query name: Redis Cache Allows Non SSL Connections Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: Redis Cache resources should not allow non-SSL connections<br> ```tf title="Positive test num. 1 - tf file" hl_lines="8" resource "azurermrediscache" "positive1" { name = "example-cache" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name capacity = 2 family = "C" sku_name = "Standard" enablenonssl_port = true minimumtlsversion = "1.2" redis_configuration { } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermrediscache" "negative1" { name = "example-cache" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name capacity = 2 family = "C" sku_name = "Standard" enablenonssl_port = false minimumtlsversion = "1.2" redis_configuration { } } resource "azurermrediscache" "negative2" { name = "example-cache" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name capacity = 2 family = "C" sku_name = "Standard" minimumtlsversion = "1.2" redis_configuration { } } ```
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: adr004-module-export-structure.md

id: adrs-adr004 title: 'ADR004: Module Export Structure' description: Architecture Decision Record (ADR) log on Module Export Structure With a growing number of exports of packages like `@backstage/core-components`, it is becoming more and more difficult to answer questions such as Is the export in this module also exported by the package? or What is exported from this directory? We currently do not use any pattern for how to structure exports. There is a mix of package-level re-exports deep into the directory tree, shallow re-exports for each directory, exports using `*` and explicit lists of each symbol, etc. The mix and lack of predictability make it difficult to reason about the boundaries of a module, and for example knowing whether it is safe to export a symbol in a given file. We will make each exported symbol traceable through index files all the way down to the root of the package, `src/index.ts`. Each index file will only re-export from its own immediate directory children, and only index files will have re-exports. This gives a file tree similar to this: ```text index.ts components/index.ts /ComponentX/index.ts /ComponentX.tsx /SubComponentY.tsx lib/index.ts /UtilityX/index.ts /UtilityX.ts /helper.ts ``` To check whether for example `SubComponentY` is exported from the package, it should be possible to traverse the index files towards the root, starting at the adjacent one. If there is any index file that doesn't export the previous one, the symbol is not publicly exported. For example, if `components/ComponentX/index.ts` exports `SubComponentY`, but `components/index.ts` does not re-export `./ComponentX`, one should be certain that `SubComponentY` is not exported outside the package. This rule would be broken if for example the root `index.ts` re-exports `./components/ComponentX` In addition, index files that are re-exporting other index files should always use wildcard form, that is: ```ts // in components/index.ts export * from './ComponentX'; ``` Index files that are re-exporting symbols from non-index files should always enumerate all exports, that is: ```ts // in components/ComponentX/index.ts export { ComponentX } from './ComponentX'; export type { ComponentXProps } from './ComponentX'; ``` Internal cross-directory imports are allowed from non-index modules to index modules, for example: ```ts // in components/ComponentX/ComponentX.tsx import { UtilityX } from '../../lib/UtilityX'; ``` Imports that bypass an index file are discouraged, but may sometimes be necessary, for example: ```ts // in components/ComponentX/ComponentX.tsx import { helperFunc } from '../../lib/UtilityX/helper'; ``` We will actively work to rework the export structure in our codebase, prioritizing the library packages such as `@backstage/core-components` and `@backstage/backend-common`. If possible, we will add tools, such as lint rules, to help enforce the export structure.
Project: KICS (Provisioning / Security & Compliance)
File: fc775e75-fcfb-4c98-b2f2-910c5858b359.md

title: Run Using 'wget' and 'curl' hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fc775e75-fcfb-4c98-b2f2-910c5858b359 Query name: Run Using 'wget' and 'curl' Platform: Dockerfile Severity: <span style="color:#edd57e">Low</span> Category: Supply-Chain URL: Shouldn't use both 'wget' and 'curl' since they are two tools that have the same effect<br> ```dockerfile title="Positive test num. 1 - dockerfile file" hl_lines="8 3 7" FROM debian RUN wget http://google.com RUN curl http://bing.com FROM baseImage RUN wget http://test.com RUN curl http://bing.com RUN ["curl", "http://bing.com"] ``` ```dockerfile title="Negative test num. 1 - dockerfile file" FROM debian RUN curl http://google.com RUN curl http://bing.com RUN ["curl", "http://bing.com"] ```
Project: Meshery (Provisioning / Automation & Configuration)
File: teller.md

layout: integration title: Teller subtitle: Collaborative and visual infrastructure as code for Teller image: /assets/img/integrations/teller/icons/color/teller-color.svg permalink: extensibility/integrations/teller docURL: https://docs.meshery.io/extensibility/integrations/teller description: integrations-category: Provisioning integrations-subcategory: Key Management 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: Eclipse Che (App Definition and Development / Application Definition & Image Build)
File: README.md

This script tests the performance of an OpenShift environment by running multiple workspaces simultaneously. It evaluates the system under test by checking the average results across all pods and identifying any failures that occur during the testing process. To run these tests, you will need: The `kubectl` client installed An OpenShift cluster with running OpenShift DevSpaces A test user logged into the DevSpaces Dashboard (this ensures that user namespaces are created) Follow these steps to run the load tests: Log in to the OpenShift cluster with OpenShift DevSpaces or Eclipse Che deployed from the terminal. Start the `load-test.sh` script from `test/e2e/performance/load-tests`. Set the number of workspaces to start using the `-c` parameter (e.g., `./load-test.sh -c 5`). Set the timeout for waiting for workspaces to start using the `-t` parameter in seconds (e.g., `./load-test.sh -t 240`). This script uses the local `example.yaml` file to start the workspaces. Alternatively, you can provide a link to the test devworkspace YAML file using the `-l` argument (e.g., `./load-test.sh -l https://raw.githubusercontent.com/eclipse/che/main/tests/performance/load-tests/samples/simple-with-editor-pvc.yaml`). If you want to start workspaces in separate namespaces (one workspace per namespace), use the `-s` as flag option (e.g., `./load-test.sh -s `). The script will provide the average time for workspace starting and the number of failed workspaces. If a workspace fails to start, the logs will be saved in the `logs` directory.
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: Patterns.md

Tremor uses two seperators `,` and `;`. The pattern when which is used is as following: Commands are separated with a `;`. This can be seen in top-level troy, trickle, and tremor script, in `patch`, `match`, and `for`. Data is seperated by `,` this can be seen in arrays and records as well as in the window declerators for select and the with and args part of troy and trickle defines and creates A general pattern that repeats in troy/trickle/tremor-script is: ``` <action> <target> <source> ``` ```tremor define connector <myalias> from <buildin_connector>; define window <myalias> from <windowtype>; define operator <myalias> from <operatortype>; define flow <my_alias>; define script <my_alias>; define pipeline <my_alias>; ``` CHAGE: it was: ``` define <buildinconnector> connector <my_alias>; define <windowtype> window <myalias>; define <operatortype> operator <myalias>; ``` ```tremor create stream <my_alias> create script <my_definition>; create script <myalias> from <mydefinition>; create operator <my_definition>; create operator <myalias> from <mydefinition>; create pipeline <my_definition>; create pipeline <myalias> from <mydefinition>; create connector <my_definition>; create connector <myalias> from <mydefinition>; deploy flow <myalias> from <mydefinition>; ``` ``` args <target>[ = <source>] with <target> = <source> end ``` ```tremor let <target> = <srouce>; ``` ```tremor merge <target> from <source> end; patch <target> from <source> end; ``` ```tremor { "<name>": <source-data> } `connect` switches target and source, while it would be possible to swap those around to follow the same `target` first `source` second pattern, it is counter-intuitive to the fact that tremor uses the English language and pipelining here is commonly thought of as something going from left to right. ```tremor connect <source> to <target>; ``` `match` and `for` both do not follow the pattern of `target` first `source` second. The reasoning for this is twofold. Again with English being the foundation of the language for control statements, it is more idiomatic to put the condition before the consequence. This pattern is also widespread in other programming languages. The second factor is that we have multiple possible targets, and moving them upfront would lead to a very hard-to-read construct. ```tremor match <source> of case <target> => ... end; ``` ```tremor for <source> in case <target> => ... end; ``` `select is a unique case as it conforms and does not conform to this pattern in different places. We look at the different parts and explain why. The non-conforming part is the `from` / `to` section. The reasoning here follows the same reasoning in `connect` we have a dataflow, and in the English language, this typically moves left to right. ```tremor ... from <source> to <target> ``` The conforming part is the `select` / `from` section. Here we have the target (`script`) on the left and the source (`from`) on the right. We choose This to conform with SQL. ```tremor select <target> from <source> ... ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_ssl_policies.md

+++ title = "googlecomputessl_policies resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputessl_policies" identifier = "inspec/resources/gcp/googlecomputesslpolicies.md googlecomputesslpolicies resource" parent = "inspec/resources/gcp" +++ A `googlecomputessl_policies` is used to test a Google SslPolicy resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputessl_policies(project: 'chef-gcp-inspec') do it { should exist } its('names') { should include 'inspec-gcp-ssl-policy' } its('profiles') { should include 'CUSTOM' } its('count') { should eq 1 } end googlecomputesslpolicies(project: 'chef-gcp-inspec').names.each do |policyname| describe googlecomputesslpolicy(project: 'chef-gcp-inspec', name: policyname) do its('mintlsversion') { should eq 'TLS12' } end end ``` Properties that can be accessed from the `googlecomputessl_policies` resource: See the resource for more information. `creation_timestamps` : an array of `googlecomputesslpolicy` creationtimestamp `descriptions` : an array of `googlecomputessl_policy` description `ids` : an array of `googlecomputessl_policy` id `names` : an array of `googlecomputessl_policy` name `profiles` : an array of `googlecomputessl_policy` profile `mintlsversions` : an array of `googlecomputesslpolicy` mintls_version `enabled_features` : an array of `googlecomputesslpolicy` enabledfeatures `custom_features` : an array of `googlecomputesslpolicy` customfeatures `fingerprints` : an array of `googlecomputessl_policy` fingerprint `warnings` : an array of `googlecomputessl_policy` warnings 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 Habitat (App Definition and Development / Application Definition & Image Build)
File: application_rebuild_flow.md

+++ title = "Application Rebuild Flow" description = "Application Rebuild Flow" gh_repo = "habitat" [menu] [menu.habitat] title = "Application Rebuild Flow" identifier = "habitat/diagrams/application-rebuild-flow Application Rebuild Flow" parent = "habitat/diagrams" weight = 40 +++
Project: Kyverno (Provisioning / Security & Compliance)
File: MAINTAINERS.md

Maintainers are approvers who have shown good technical judgement in guiding feature design & development, have displayed overall knowledge of the project and features in the project, and are nurturing and receptive to everyone in the community. | Maintainer | GitHub ID | Affiliation | |--|--|| | Jim Bugwadia | | Nirmata | | Shuting Zhao | | Nirmata | | Chip Zoller | | Stackwatch (Kubecost) | | Marcel Mller | | Giant Swarm GmbH | | Trey Dockendorf | | Ohio Supercomputer Center | | Charles-Edouard Brtch | | Nirmata | | Vishal Choudhary | | Nirmata | | Mariam Fahmy | | Nirmata | Note: Please refer to the for more information on the responsibilities and privileges of a maintainer in Kyverno. | Maintainer | GitHub ID | Affiliation | |--|--|| | Vyankatesh Kudtarkar | | | | Prateek Pandey | | | | Sambhav Kothari | | Bloomberg |
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-filter.md

layout: default title: mesheryctl-filter permalink: reference/mesheryctl/filter redirect_from: reference/mesheryctl/filter/ type: reference display-title: "false" language: en command: filter subcommand: nil Cloud Native Filter Management Cloud Native Filter Management <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl filter [flags] </div> </pre> Base command for WASM filters: <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl filter [subcommands] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for filter -t, --token string Path to token file default from current context </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -v, --verbose verbose output </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.