cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: pyspark-migration-guide.md

layout: global title: "Migration Guide: PySpark (Python on Spark)" displayTitle: "Migration Guide: PySpark (Python on Spark)" license: | Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. The migration guide is now archived on .
Project: Harbor (Provisioning / Container Registry)
File: 11-02-project-admin-manage-project-level-labels.md

Test 11-02 - Project admins manage project level labels ======= To verify that the project administrators can manage(CURD) the project level labels. User guide This test requires that a Harbor instance is running and available. The project admin user logs in to the UI. The project admin user creates a project level label under a project from the UI. The project admin user edits the label created in Step1. The project admin user deletes the label created in Step1. The project developer user logs in to the UI. The project developer user tries to create a project level label under a project from the UI. In Step2, the label can be created successfully. In Step3, the label can be updated successfully. In Step4, the label can be deleted successfully. In Step6, the project developer user can not create project level labels. None
Project: YugabyteDB (App Definition and Development / Database)
File: ta-21218.md

title: TA-21218 headerTitle: DML and DDL operations fail on a colocated table with Packed Rows headcontent: 12 Mar 2024 type: docs showRightNav: true cascade: unversioned: true menu: preview_releases: identifier: ta-21218 weight: 1 rightNav: hideH2: true type: docs | Product | Affected Versions | Related Issues | Fixed In | | :- | : | :- | :- | | {{<product "ysql">}} | {{<release "2.20.x">}} | {{<issue 21218>}} | {{<release "2.20.2, 2.18, 2.21">}} | Colocated table and Packed Rows: DML and DDL workloads fail with an error related to missing schema packing. In v2.20.0+ builds, the packed row feature is enabled by default for YSQL API.However, this only applies to new clusters; existing clusters upgraded from older releases such as v2.14, v2.6, or v2.18 won't be impacted. If you create colocated tables and perform many DDLs to them after a PITR, there is a chance that the workload could result in errors mentioned in {{<issue 21218>}}. This may result in a yb-tserver crash loop on the impacted node. Note that this issue could also affect v2.18 builds, if you have explicitly enabled YSQL packed row feature for colocated tables, using the flag, `ysqlenablepackedrowforcolocatedtable`. If you are using a build without the fix, you can disable packed row for YSQL for colocated table by setting the flag `ysqlenablepackedrowforcolocatedtable` to false. Note that if you encounter the issue, disabling the flag won't help anymore. The flag needs to be disabled on the workloads from the beginning. During the garbage collection of schema packing in DocDB, the `TableInfoPtr` in `KvStoreInfo::tables` is updated to a new value but the pointer in `KvStoreInfo::colocationtotable` is left unchanged in certain scenarios after a PITR. This can lead to corruption of the tablet metadata, that causes workloads to fail, missing schema packing info at the DocDB layer.
Project: KICS (Provisioning / Security & Compliance)
File: fd632aaf-b8a1-424d-a4d1-0de22fd3247a.md

title: VPC Without Network Firewall hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fd632aaf-b8a1-424d-a4d1-0de22fd3247a Query name: VPC Without Network Firewall Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: VPC should have a Network Firewall associated<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "aws_vpc" "positive" { cidr_block = "10.0.0.0/16" } ``` ```tf title="Negative test num. 1 - tf file" resource "aws_vpc" "negative" { cidr_block = "10.0.0.0/16" } resource "awsnetworkfirewallfirewall" "example" { name = "example" firewallpolicyarn = awsnetworkfirewallfirewall_policy.example.arn vpcid = awsvpc.negative.id subnet_mapping { subnetid = awssubnet.example.id } tags = { Tag1 = "Value1" Tag2 = "Value2" } } ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: springsecurity-api.md

title: Authorization for Java Spring Security labels: layer: network category: application software: javaspringsecurity code: https://github.com/open-policy-agent/contrib/tree/master/spring_authz https://github.com/Bisnode/opa-spring-security https://github.com/build-security/opa-java-spring-client https://github.com/massenz/jwt-opa https://github.com/eugenp/tutorials/tree/master/spring-security-modules/spring-security-opa tutorials: https://github.com/open-policy-agent/contrib/blob/master/spring_authz/README.md https://github.com/massenz/jwt-opa#web-server-demo-app https://www.baeldung.com/spring-security-authorization-opa inventors: styra build-security bisnode alertavert docs_features: rest-api-integration: note: | OPA Spring Security uses the REST API to query OPA about authz decisions. See an example application in OPA's . Spring Security provides a framework for securing Java applications. These integrations provide simple implementations for Spring Security that use OPA for making API authorization decisions. They provide support for both traditional Spring Security (MVC), as well as an implementation for Spring Reactive (Web Flux).
Project: YugabyteDB (App Definition and Development / Database)
File: set_constraints.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="473" height="95" viewbox="0 0 473 95"><path class="connector" d="M0 22h15m43 0h10m106 0h30m42 0h72m-129 0q5 0 5 5v50q0 5 5 5h25m-5 0q-5 0-5-5v-20q0-5 5-5h20m24 0h20q5 0 5 5v20q0 5-5 5m-5 0h25q5 0 5-5v-50q0-5 5-5m5 0h30m85 0h25m-125 0q5 0 5 5v20q0 5 5 5h5m90 0h5q5 0 5-5v-20q0-5 5-5m5 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="43" height="25" rx="7"/><text class="text" x="25" y="22">SET</text><rect class="literal" x="68" y="5" width="106" height="25" rx="7"/><text class="text" x="78" y="22">CONSTRAINTS</text><rect class="literal" x="204" y="5" width="42" height="25" rx="7"/><text class="text" x="214" y="22">ALL</text><rect class="literal" x="239" y="35" width="24" height="25" rx="7"/><text class="text" x="249" y="52">,</text><a xlink:href="../../../syntaxresources/grammardiagrams#name"><rect class="rule" x="224" y="65" width="54" height="25"/><text class="text" x="234" y="82">name</text></a><rect class="literal" x="348" y="5" width="85" height="25" rx="7"/><text class="text" x="358" y="22">DEFERRED</text><rect class="literal" x="348" y="35" width="90" height="25" rx="7"/><text class="text" x="358" y="52">IMMEDIATE</text><polygon points="469,29 473,29 473,15 469,15" style="fill:black;stroke-width:0"/></svg>
Project: Airship (Provisioning / Automation & Configuration)
File: README.md

The "kustomization" of dex-aio service is achieved through replacement transformer and patches. The rationale for supporting two different kustomization approaches is values for Dex service are shared with its corresponding API server. The replacement transformer/catalogue avoids duplication of variables/values avoiding configuration errors (DRY: Don't Repeat Yourself principle). The LDAP values are only used for the LDAP backend so supporting through patchesStrategyMerge avoids "complexity", e.i., the need to support a catalog + replacement rules. Dex dependent values are collected in a catalogue located at manifests/function/treasuremap-base-catalogues/utility.yaml. Some of these values are common to the Dex service and API Server/OIDC flags (DRY principle). Dex values are substituted using replacement transformer and the replacement rules for the Dex service can be found in manifests/function/dex-aio/replacements. NOTE: The replacement transformer is invoked in treasuremap/manifests/type/multi-tenant/target/workload/replacements/kustomization.yaml. The LDAP dependent values are kustomized through the patchesStrategyMerge and the values for the LDAP backend can be found in ./dex-aio-helm-patch.yaml.
Project: ShardingSphere (App Definition and Development / Database)
File: alter-transaction-rule.en.md

+++ title = "ALTER TRANSACTION RULE" weight = 3 +++ The `ALTER TRANSACTION RULE` syntax is used to alter transaction rule configuration. {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterTransactionRule ::= 'ALTER' 'TRANSACTION' 'RULE' '(' 'DEFAULT' '=' defaultTransactionType ',' 'TYPE' '(' 'NAME' '=' transactionManager ',' propertiesDefinition ')' ')' propertiesDefinition ::= 'PROPERTIES' '(' key '=' value (',' key '=' value)* ')' defaultTransactionType ::= string transactionManager ::= string key ::= string value ::= literal ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} `defaultTransactionType` support `LOCAL`, `XA`, `BASE` `transactionManager` support `Atomikos` and `Narayana` Alter transaction rule ```sql ALTER TRANSACTION RULE( DEFAULT="XA", TYPE(NAME="Narayana", PROPERTIES("databaseName"="jbossts", "host"="127.0.0.1")) ); ``` `ALTER`, `TRANSACTION`, `RULE`, `DEFAULT`, `TYPE`, `NAME`, `PROPERTIES`
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: feat-10607.en.md

Simplified log configuration: Replaced `log.consolehandler` with `log.console`, keeping only `enable, level, formatter, and timeoffset`. Replaced `log.filehandlers` with `log.file`, keeping only `enable, level, formatter, timeoffset, rotationcount, rotationsize, to`.
Project: NeuVector (Provisioning / Security & Compliance)
File: CONTRIBUTORS.md

The following people, listed in alphabetical order, have contributed to docker-bench-security: alberto <alberto@tutum.co> Andreas Stieger <astieger@suse.com> Anthony Roger <aroger@softwaymedical.fr> Aurlien Gasser <aurelien.gasser@gmail.com> binary <binary@webdev.fritz.box> Boris Gorbylev <ekho@ekho.name> Cheng-Li Jerry Ma <chengli.ma@gmail.com> Csaba Palfi <csaba@palfi.me> Daniele Marcocci <daniele.marcocci@par-tec.it> Dhawal Patel <dhawal.patel@nordstrom.com> Diogo Monica <diogo@docker.com> Diogo Mnica <diogo.monica@gmail.com> Ernst de Haan <ernst@ernstdehaan.com> HuKeping <hukeping@huawei.com> Ivan Angelov <iangelov@users.noreply.github.com> J0WI <J0WI@users.noreply.github.com> jammasterj89 <jammasterj89@gmail.com> Jessica Frazelle <princess@docker.com> Joachim Lusiardi <jlusiardi@users.noreply.github.com> Joachim Lusiardi <joachim@lusiardi.de> Joachim Lusiardi <shing19m@dev1.lusiardi.de> Joe Williams <joe.williams@github.com> Julien Garcia Gonzalez <julien@giantswarm.io> Jrgen Hermann <jh@web.de> kakakakakku <y.yoshida22@gmail.com> Karol Babioch <kbabioch@suse.de> Kevin Lim <kevin.lim@sap.com> kevinll <imhael@gmail.com> Liron Levin <liron@twistlock.com> liron-l <levinlir@gmail.com> LorensK <LorensK@users.noreply.github.com> lusitania <lusitania@users.noreply.github.com> Maik Ellerbrock <opensource@frapsoft.com> Mark Stemm <mark.stemm@gmail.com> Matt Fellows <matt.fellows@onegeek.com.au> Michael Crosby <crosbymichael@gmail.com> Michael Stahn <michael.stahn.42@gmail.com> Mike Ritter <mike.ritter@target.com> Mr. Secure <ben.github@mrsecure.org> MrSecure <MrSecure@users.noreply.github.com> Nigel Brown <nigel@windsock.io> Paul Czarkowski <username.taken@gmail.com> Paul Morgan <jumanjiman@gmail.com> Pete Sellars <psellars@gmail.com> Peter <lusitania@users.noreply.github.com> Ravi Kumar Vadapalli <vadapalli.ravikumar@gmail.com> Scott McCarty <scott.mccarty@gmail.com> Sebastiaan van Stijn <github@gone.nl> telepresencebot2 <telepresencebot2@users.noreply.github.com> Thomas Sjgren <konstruktoid@users.noreply.github.com> Tom Partington <tom.partington@cevo.com.au> Werner Buck <wernerbuck@gmail.com> will Farrell <willfarrell@users.noreply.github.com> Zvi "Viz" Effron <zeffron@riotgames.com> This list was generated Tue Nov 5 09:45:35 UTC 2019.
Project: KICS (Provisioning / Security & Compliance)
File: 5f89001f-6dd9-49ff-9b15-d8cd71b617f4.md

title: Kubelet Not Managing Ip Tables hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 5f89001f-6dd9-49ff-9b15-d8cd71b617f4 Query name: Kubelet Not Managing Ip Tables Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Networking and Firewall URL: Kubelet argument --make-iptables-util-chains should be true<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: foo/bar command: ["kubelet"] args: ["--make-iptables-util-chains=false"] restartPolicy: OnFailure ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="8" apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration address: "192.168.0.8" port: 20250 serializeImagePulls: false evictionHard: memory.available: "200Mi" makeIPTablesUtilChains: false ``` ```json title="Positive test num. 3 - json file" hl_lines="7" { "apiVersion": "kubelet.config.k8s.io/v1beta1", "evictionHard": { "memory.available": "200Mi" }, "kind": "KubeletConfiguration", "makeIPTablesUtilChains": false, "port": 20250, "serializeImagePulls": false, "address": "192.168.0.8" } ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: foo/bar command: ["kubelet"] args: ["--make-iptables-util-chains=true"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration address: "192.168.0.8" port: 20250 serializeImagePulls: false evictionHard: memory.available: "200Mi" makeIPTablesUtilChains: true ``` ```yaml title="Negative test num. 3 - yaml file" apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration address: "192.168.0.8" port: 20250 serializeImagePulls: false evictionHard: memory.available: "200Mi" ``` <details><summary>Negative test num. 4 - yaml file</summary> ```yaml apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: foo/bar command: ["kubelet"] args: [""] restartPolicy: OnFailure ``` </details> <details><summary>Negative test num. 5 - json file</summary> ```json { "port": 20250, "evictionHard": { "memory.available": "200Mi" }, "kind": "KubeletConfiguration", "makeIPTablesUtilChains": true, "serializeImagePulls": false, "address": "192.168.0.8", "apiVersion": "kubelet.config.k8s.io/v1beta1" } ``` </details>
Project: KICS (Provisioning / Security & Compliance)
File: 25c0ea09-f1c5-4380-b055-3b83863f2bb8.md

title: SQLServer Ingress From Any IP hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 25c0ea09-f1c5-4380-b055-3b83863f2bb8 Query name: SQLServer Ingress From Any IP Platform: Terraform Severity: <span style="color:#ff0000">Critical</span> Category: Networking and Firewall URL: Check if all IPs are allowed, check from start 0.0.0.0 to end 255.255.255.255.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "azurermsqlfirewall_rule" "positive1" { name = "FirewallRule1" resourcegroupname = azurermresourcegroup.example.name servername = azurermsql_server.example.name startipaddress = "0.0.0.0" endipaddress = "255.255.255.255" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermsqlfirewall_rule" "negative1" { name = "FirewallRule1" resourcegroupname = azurermresourcegroup.example.name servername = azurermsql_server.example.name startipaddress = "10.0.17.62" endipaddress = "10.0.17.62" } ```
Project: Clair (Provisioning / Security & Compliance)
File: commit_style.md

The Clair project utilizes well structured commits to keep the history useful and help with release automation. We suggest signing off on your commits as well. A typical commit will take on the following structure: ``` <scope>: <subject> <body> Fixes #1 Pull Request #2 Signed-Off By: <email> ``` The header of the commit is regexp checked before commit and your commit will be kicked back if it does not conform. This is the section of code this commit influences. You will often see scopes such as "notifier", "auth", "chore", "cicd". We use this field to group commits by scope in our automated changelog generation. It would be wise to take a look at our changelog before contributing to get an idea of the common scopes we use. Subject is a short and concise summary of the change the commit is introducing. It should be a sentence fragment without starting capitalization and ending punctuation and limited to about 60 characters, to allow for the scope prefix and decoration in the git log. Body should be full of detail. Explain what this commit is doing and why it is necessary. You may include references to issues and pull requests as well. Our automated changelog process will discover references prefixed with "Fixes", "Closed" and "Pull Request"
Project: Chef InSpec (Provisioning / Security & Compliance)
File: oracledb_listener_conf.md

+++ title = "oracledblistenerconf resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "oracledblistenerconf" identifier = "inspec/resources/os/oracledblistenerconf.md oracledblistenerconf resource" parent = "inspec/resources/os" +++ Use the `oracledblistenerconf` Chef InSpec audit resource to test the listeners settings of Oracle DB, typically located at `$ORACLEHOME/network/admin/listener.ora` or `$ORACLEHOME\network\admin\listener.ora` depending upon the platform. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} You must have sufficient permission to access listener settings defined in `listener.ora` file. Value for environment variable `ORACLE_HOME` should be set in the system. A `oracledblistenerconf` resource block fetches listeners settings in the `listener.ora` file, and then compares them with the value stated in the test: describe oracledblistenerconf do its('config item') { should eq 'value' } end The following examples show how to use this Chef InSpec audit resource. describe oracledblistenerconf do its('DEFAULTSERVICELISTENER') { should eq 'XE' } its('EMEXPRESSPORT') { should eq '5500' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: external-secrets (Provisioning / Security & Compliance)
File: bitwarden.md

Bitwarden is an integrated open source password management solution for individuals, teams, and business organizations. To make external-secrets compatible with Bitwarden, we need: External Secrets Operator >= 0.8.0 Multiple (Cluster)SecretStores using the webhook provider BitWarden CLI image running `bw serve` When you create a new external-secret object, the External Secrets webhook provider will query the Bitwarden CLI pod that is synced with the Bitwarden server. Bitwarden account (it also works with Vaultwarden!) A Kubernetes secret which contains your Bitwarden credentials A Docker image running the Bitwarden CLI. You could use `ghcr.io/charlesthomas/bitwarden-cli:2023.12.1` or build your own. Here is an example of a Dockerfile used to build the image: ```dockerfile FROM debian:sid ENV BWCLIVERSION=2023.12.1 RUN apt update && \ apt install -y wget unzip && \ wget https://github.com/bitwarden/clients/releases/download/cli-v${BWCLIVERSION}/bw-linux-${BWCLIVERSION}.zip && \ unzip bw-linux-${BWCLIVERSION}.zip && \ chmod +x bw && \ mv bw /usr/local/bin/bw && \ rm -rfv *.zip COPY entrypoint.sh / CMD ["/entrypoint.sh"] ``` And the content of `entrypoint.sh`: ```bash set -e bw config server ${BW_HOST} export BWSESSION=$(bw login ${BWUSER} --passwordenv BW_PASSWORD --raw) bw unlock --check echo 'Running `bw server` on port 8087' bw serve --hostname 0.0.0.0 #--disable-origin-protection ``` ```yaml {% include 'bitwarden-cli-secrets.yaml' %} ``` ```yaml {% include 'bitwarden-cli-deployment.yaml' %} ``` NOTE: Deploying a network policy is recommended since there is no authentication to query the Bitwarden CLI, which means that your secrets are exposed. NOTE: In this example the Liveness probe is querying /sync to ensure that the Bitwarden CLI is able to connect to the server and is also synchronised. (The secret sync is only every 2 minutes in this example) There are four possible (Cluster)SecretStores to deploy, each can access different types of fields from an item in the Bitwarden vault. It is not required to deploy them all. ```yaml {% include 'bitwarden-secret-store.yaml' %} ``` (Cluster)SecretStores: `bitwarden-login`: Use to get the `username` or `password` fields `bitwarden-fields`: Use to get custom fields `bitwarden-notes`: Use to get notes `bitwarden-attachments`: Use to get attachments remoteRef: `key`: ID of a secret, which can be found in the URL `itemId` parameter: `https://myvault.com/#/vault?type=login&itemId=........-....-....-....-............`s `property`: Name of the field to access `username` for the username of a secret (`bitwarden-login` SecretStore) `password` for the password of a secret (`bitwarden-login` SecretStore) `nameofthecustomfield` for any custom field (`bitwarden-fields` SecretStore) `idornameofthe_attachment` for any attachment (`bitwarden-attachment`, SecretStore) ```yaml {% include 'bitwarden-secret.yaml' %} ```
Project: KubeArmor (Provisioning / Security & Compliance)
File: multiubuntu.md

Deployment To deploy the multiubuntu microservice, please run the following commands. ```text $ cd KubeArmor/examples/multiubuntu ~/KubeArmor/examples/multiubuntu$ kubectl apply -f . ``` Use Cases To verify KubeArmor's functionalities, we provide sample security policies for the multiubuntu microservice. Example 1 - Block a process execution Deploy a security policy ```text $ cd KubeArmor/examples/multiubuntu/security-policies .../multiubuntu/security-policies$ kubectl -n multiubuntu apply -f ksp-group-1-proc-path-block.yaml ``` Execute /bin/sleep inside of the ubuntu-1 pod ```text $ PODNAME=$(kubectl get pods -n multiubuntu -l "group=group-1,container=ubuntu-1" -o jsonpath='{.items[0].metadata.name}') && kubectl -n multiubuntu exec -it $PODNAME -- bash (Permission Denied) ``` Check audit logs ```text $ karmor log --json Run the above command in other terminal to see logs live. To install karmor cli tool . ``` Example 2 - Block a file access Deploy a security policy ```text $ cd security-policies .../multiubuntu/security-policies$ kubectl -n multiubuntu apply -f ksp-ubuntu-5-file-dir-recursive-block.yaml ``` Access /credentials/password inside of the ubuntu-5 pod ```text $ PODNAME=$(kubectl get pods -n multiubuntu -l "group=group-2,container=ubuntu-5" -o jsonpath='{.items[0].metadata.name}') && kubectl -n multiubuntu exec -it $PODNAME -- bash (Permission Denied) ``` Check audit logs ```text $ karmor log --json ```