cwielenb/CNCF-Dataset huggingface dataset:
Project: Meshery (Provisioning / Automation & Configuration)
File: psmdb-operator.md

layout: integration title: Percona Operator for MongoDB subtitle: Collaborative and visual infrastructure as code for Percona Operator for MongoDB image: /assets/img/integrations/psmdb-operator/icons/color/psmdb-operator-color.svg permalink: extensibility/integrations/psmdb-operator docURL: https://docs.meshery.io/extensibility/integrations/psmdb-operator description: integrations-category: Database integrations-subcategory: App Definition and Development registrant: Artifact Hub components: name: percona-server-mongo-db-backup colorIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db-backup/icons/color/percona-server-mongo-db-backup-color.svg whiteIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db-backup/icons/white/percona-server-mongo-db-backup-white.svg description: name: percona-server-mongo-db-restore colorIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db-restore/icons/color/percona-server-mongo-db-restore-color.svg whiteIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db-restore/icons/white/percona-server-mongo-db-restore-white.svg description: name: percona-server-mongo-db colorIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db/icons/color/percona-server-mongo-db-color.svg whiteIcon: assets/img/integrations/psmdb-operator/components/percona-server-mongo-db/icons/white/percona-server-mongo-db-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: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_node_templates.md

+++ title = "googlecomputenode_templates resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputenode_templates" identifier = "inspec/resources/gcp/googlecomputenodetemplates.md googlecomputenodetemplates resource" parent = "inspec/resources/gcp" +++ A `googlecomputenode_templates` is used to test a Google NodeTemplate resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputenode_templates(project: 'chef-gcp-inspec', region: 'europe-west2') do its('names') { should include 'inspec-node-template' } end ``` Properties that can be accessed from the `googlecomputenode_templates` resource: See the resource for more information. `creation_timestamps` : an array of `googlecomputenodetemplate` creationtimestamp `descriptions` : an array of `googlecomputenode_template` description `names` : an array of `googlecomputenode_template` name `nodeaffinitylabels` : an array of `googlecomputenodetemplate` nodeaffinity_labels `node_types` : an array of `googlecomputenodetemplate` nodetype `nodetypeflexibilities` : an array of `googlecomputenodetemplate` nodetype_flexibility `server_bindings` : (Beta only) an array of `googlecomputenodetemplate` serverbinding `regions` : an array of `googlecomputenode_template` region This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_bigquery_datasets.md

+++ title = "googlebigquerydatasets resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlebigquerydatasets" identifier = "inspec/resources/gcp/googlebigquerydatasets.md googlebigquerydatasets resource" parent = "inspec/resources/gcp" +++ A `googlebigquerydatasets` is used to test a Google Dataset resource ```ruby describe googlebigquerydatasets(project: 'chef-gcp-inspec') do its('count') { should be >= 1 } its('friendly_names') { should include 'A BigQuery dataset test' } its('locations') { should include 'EU' } end googlebigquerydatasets(project: 'chef-gcp-inspec').ids.each do |name| googlebigquerydataset(project: 'chef-gcp-inspec', name: name.split(':').last).access.each do |access| describe access do its('iammember') { shouldnot cmp 'allUsers' } end end end ``` Properties that can be accessed from the `googlebigquerydatasets` resource: See the resource for more information. `dataset_references` : an array of `googlebigquerydataset` dataset_reference `defaultpartitionexpiration_ms` : an array of `googlebigquerydataset` defaultpartitionexpiration_ms `etags` : an array of `googlebigquerydataset` etag `friendly_names` : an array of `googlebigquerydataset` friendly_name `ids` : an array of `googlebigquerydataset` id `labels` : an array of `googlebigquerydataset` labels `locations` : an array of `googlebigquerydataset` location `defaultencryptionconfigurations` : an array of `googlebigquerydataset` defaultencryptionconfiguration 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: Apache Storm (App Definition and Development / Streaming & Messaging)
File: index.md

title: Documentation layout: documentation documentation: true Trident is an alternative interface to Storm. It provides exactly-once processing, "transactional" datastore persistence, and a set of common stream analytics operations. -- basic concepts and walkthrough -- operations for transforming and orchestrating data -- exactly-once processing and fast, persistent aggregation -- transactional and non-transactional data intake -- using the Resource Aware Scheduler with Trident. Stream APIs is another alternative interface to Storm. It provides a typed API for expressing streaming computations and supports functional style operations. NOTE: Streams API is an `experimental` feature, and further works might break backward compatibility. We're also notifying it via annotating classes with marker interface `@InterfaceStability.Unstable`. The Storm SQL integration allows users to run SQL queries over streaming data in Storm. NOTE: Storm SQL is an `experimental` feature, so the internals of Storm SQL and supported features are subject to change. But small change will not affect the user experience. We will notify the user when breaking UX change is introduced. with Maven (how to provide support for another language)
Project: FOSSA (Provisioning / Security & Compliance)
File: python.md

The python buildtool ecosystem consists of three major toolchains: setuptools (requirements.txt, setup.py), pipenv, and conda. | Strategy | Direct Deps | Transitive Deps | Edges | Container Scanning | | - | | | | | | | :heavycheckmark: | :heavycheckmark: | :heavycheckmark: | :x: | | | :heavycheckmark: | :heavycheckmark: | :x: | :x: | | | :heavycheckmark: | :whitecheckmark: | :whitecheckmark: | :heavycheckmark: | | | :heavycheckmark: | :whitecheckmark: | :whitecheckmark: | :heavycheckmark: | | | :heavycheckmark: | :whitecheckmark: | :x: | :x: | | | :heavycheckmark: | :whitecheckmark: | :whitecheckmark: | :heavycheckmark: | | | :heavycheckmark: | :whitecheckmark: | :whitecheckmark: | :heavycheckmark: | :heavycheckmark: - Supported in all projects :whitecheckmark: - Supported only when relevant data is available (e.g. lockfiles are present) :x: - Not Supported
Project: KICS (Provisioning / Security & Compliance)
File: 26763a1c-5dda-4772-b507-5fca7fb5f165.md

title: Service With External Load Balancer hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 26763a1c-5dda-4772-b507-5fca7fb5f165 Query name: Service With External Load Balancer Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: Service has an external load balancer, which may cause accessibility from other networks and the Internet<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="33 4 48 18 63" apiVersion: v1 kind: Service metadata: name: sample-service 05 spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 05334443 annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 'false' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 07 annotations: service.beta.kubernetes.io/azure-load-balancer-internal: 'false' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 08 annotations: networking.gke.io/load-balancer-type: 'External' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 09 annotations: cloud.google.com/load-balancer-type: 'External' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Service metadata: name: sample-service 01 annotations: cloud.google.com/load-balancer-type: 'Internal' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 02 annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 'true' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 03 annotations: service.beta.kubernetes.io/azure-load-balancer-internal: 'true' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx apiVersion: v1 kind: Service metadata: name: sample-service 04 annotations: networking.gke.io/load-balancer-type: 'Internal' spec: ports: port: 80 targetPort: 80 protocol: TCP type: LoadBalancer selector: app: nginx ```
Project: YugabyteDB (App Definition and Development / Database)
File: managed-cli-permission.md

title: ybm CLI permission resource headerTitle: ybm permission linkTitle: permission description: YugabyteDB Managed CLI reference Permission resource. headcontent: List permissions menu: preview_yugabyte-cloud: identifier: managed-cli-permission parent: managed-cli-reference weight: 20 type: docs Use the `permission` resource to list available permissions that can be assigned to . ```text Usage: ybm permission [command] [flags] ``` List permissions in YugabyteDB Managed: ```sh ybm permission list ``` List the permissions in your YugabyteDB Managed account.
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno_create_metrics-config.md

Create a Kyverno metrics-config file. Create a Kyverno metrics-config file. ``` kyverno create metrics-config [flags] ``` ``` kyverno create metrics-config -i ns-included-1 -i ns-included-2 -e ns-excluded ``` ``` -e, --exclude strings Excluded namespaces -h, --help help for metrics-config -i, --include strings Included namespaces -n, --name string Name (default "kyverno-metrics") --namespace string Namespace (default "kyverno") -o, --output string Output path (uses standard console output if not set) ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Helps with the creation of various Kyverno resources.
Project: StarRocks (App Definition and Development / Database)
File: REFRESH_MATERIALIZED_VIEW.md

displayed_sidebar: "English" Manually refresh a specific asynchronous materialized view or partitions within. CAUTION You can only manually refresh materialized views that adopt ASYNC or MANUAL refresh strategy. You can check the refresh strategy of an asynchronous materialized view using . This operation requires the REFRESH privilege on the target materialized view. ```SQL REFRESH MATERIALIZED VIEW [database.]mv_name [PARTITION START ("<partitionstartdate>") END ("<partitionenddate>")] [FORCE] [WITH { SYNC | ASYNC } MODE] ``` | Parameter | Required | Description | | - | | | | mv_name | yes | The name of the materialized view to refresh manually. | | PARTITION START () END () | no | Manually refresh partitions within a certain time interval. | | partitionstartdate | no | The start date of the partitions to refresh manually. | | partitionenddate | no | The end date of the partitions to refresh manually. | | FORCE | no | If you specify this parameter, StarRocks forcibly refreshes the corresponding materialized view or partitions. If you do not specify this parameter, StarRocks automatically judges if the data is updated and refreshes the partition only when needed. | | WITH ... MODE | no | Make a synchronous or asynchronous call of the refresh task. `SYNC` indicates making a synchronous call of the refresh task, and StarRocks returns the task result only when the task succeeds or fails. `ASYNC` indicates making an asynchronous call of the refresh task, and StarRocks returns success right after the task is submitted, leaving the task to be executed asynchronously in the background. You can check the refresh task status of an asynchronous materialized view by querying the `tasks` and `task_runs` metadata views in StarRocks' Information Schema. For more information, see . Default: `ASYNC`. Supported from v2.5.8 and v3.1.0 onwards. | CAUTION When refreshing materialized views created based on the external catalogs, StarRocks refreshes all partitions in the materialized views. Example 1: Manually refresh a specific materialized view via an asynchronous call. ```Plain REFRESH MATERIALIZED VIEW lo_mv1; REFRESH MATERIALIZED VIEW lo_mv1 WITH ASYNC MODE; ``` Example 2: Manually refresh certain partitions of a specific materialized view. ```Plain REFRESH MATERIALIZED VIEW lo_mv1 PARTITION START ("2020-02-01") END ("2020-03-01"); ``` Example 3: Forcibly refresh certain partitions of a specific materialized view. ```Plain REFRESH MATERIALIZED VIEW lo_mv1 PARTITION START ("2020-02-01") END ("2020-03-01") FORCE; ``` Example 4: Manually refresh a materialized view via a synchronous call. ```Plain REFRESH MATERIALIZED VIEW lo_mv1 WITH SYNC MODE; ```
Project: KubeArmor (Provisioning / Security & Compliance)
File: least_permissive_access.md

KubeArmor helps organizations enforce a zero trust posture within their Kubernetes clusters. It allows users to define an allow-based policy that allows specific operations, and denies or audits all other operations. This helps to ensure that only authorized activities are allowed within the cluster, and that any deviations from the expected behavior are denied and flagged for further investigation. By implementing a zero trust posture with KubeArmor, organizations can increase their security posture and reduce the risk of unauthorized access or activity within their Kubernetes clusters. This can help to protect sensitive data, prevent system breaches, and maintain the integrity of the cluster. KubeArmor supports allow-based policies which results in specific actions to be allowed and denying/auditing everything else. For example, a specific pod/container might only invoke a set of binaries at runtime. As part of allow-based rules you can specify the set of processes that are allowed and everything else is either audited or denied based on the . <img src="../.gitbook/assets/zero-trust.png" width="512" class="center" alt="KubeArmor enforcing Zero Trust Posture"> Install the nginx deployment using `kubectl create deployment nginx --image=nginx`. Set the default security posture to default-deny. `kubectl annotate ns default kubearmor-file-posture=block --overwrite` Apply the following policy: ``` cat <<EOF | kubectl apply -f - apiVersion: security.kubearmor.com/v1 kind: KubeArmorPolicy metadata: name: only-allow-nginx-exec spec: selector: matchLabels: app: nginx file: matchDirectories: dir: / recursive: true process: matchPaths: path: /usr/sbin/nginx path: /bin/bash action: Allow EOF ``` Observe that the policy contains Allow action. Once there is any KubeArmor policy having Allow action then the pods enter least permissive mode, allowing only explicitly allowed operations. Note: Use kubectl port-forward $POD --address 0.0.0.0 8080:80 to access nginx and you can see that the nginx web access still works normally. Lets try to execute some other processes: ``` kubectl exec -it $POD -- bash -c "chroot" ``` This would be permission denied. Achieving Zero Trust Security Posture is difficult. However, the more difficult part is to maintain the Zero Trust posture across application updates. There is also a risk of application downtime if the security posture is not correctly identified. While KubeArmor provides a way to enforce Zero Trust Security Posture, identifying the policies/rules for achieving this is non-trivial and requires that you keep the policies in dry-run mode (or default audit mode) before using the default-deny mode. KubeArmor provides framework so as to smoothen the journey to Zero Trust posture. For e.g., it is possible to set dry-run/audit mode at the namespace level by . Thus, you can have different namespaces in different default security posture modes (default-deny vs default-audit). Users can switch to default-deny mode once they are comfortable (i.e., they do not see any alerts) with the settings.
Project: KICS (Provisioning / Security & Compliance)
File: b7b9d1c7-2d3b-49b4-b867-ebbe68d0b643.md

title: App Service Not Using Latest TLS Encryption Version hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: b7b9d1c7-2d3b-49b4-b867-ebbe68d0b643 Query name: App Service Not Using Latest TLS Encryption Version Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: Ensure App Service is using the latest version of TLS encryption<br> ```tf title="Positive test num. 1 - tf file" hl_lines="10" resource "azurermappservice" "positive1" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" mintlsversion = 1.1 } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermappservice" "negative1" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" mintlsversion = 1.2 } } ``` ```tf title="Negative test num. 2 - tf file" resource "azurermappservice" "negative1" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" } } ``` ```tf title="Negative test num. 3 - tf file" resource "azurermappservice" "negative3" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id } ```
Project: ko (App Definition and Development / Application Definition & Image Build)
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. <!-- TODO: Need a real CoC contact list. --> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. 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