cwielenb/CNCF-Dataset huggingface dataset:
Project: KICS (Provisioning / Security & Compliance)
File: 5c281bf8-d9bb-47f2-b909-3f6bb11874ad.md

title: Service Type is NodePort hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 5c281bf8-d9bb-47f2-b909-3f6bb11874ad Query name: Service Type is NodePort Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Networking and Firewall URL: Service type should not be NodePort<br> ```tf title="Positive test num. 1 - tf file" hl_lines="15" resource "kubernetes_service" "example" { metadata { name = "terraform-example" } spec { selector = { app = kubernetes_pod.example.metadata.0.labels.app } session_affinity = "ClientIP" port { port = 8080 target_port = 80 } type = "NodePort" } } ``` ```tf title="Negative test num. 1 - tf file" resource "kubernetes_service" "example2" { metadata { name = "terraform-example" } spec { selector = { app = kubernetes_pod.example.metadata.0.labels.app } session_affinity = "ClientIP" port { port = 8080 target_port = 80 } type = "LoadBalancer" } } ```
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: PULL_REQUEST_TEMPLATE.md

What issue type does this pull request address? (keep at least one, remove the others) /kind bugfix /kind enhancement /kind feature /kind documentation /kind test What does this pull request do? Which issues does it resolve? (use `resolves #<issue_number>` if possible) resolves # Please provide a short message that should be published in the DevSpace release notes Fixed an issue where DevSpace ... What else do we need to know?
Project: OAuth2 Proxy (Provisioning / Key Management)
File: installation.md

id: installation title: Installation Choose how to deploy: a. Using a (current release is `v7.6.0`) b. Using Go to install the latest release ```bash $ go install github.com/oauth2-proxy/oauth2-proxy/v7@latest ``` This will install the binary into `$GOPATH/bin`. Make sure you include `$GOPATH` in your `$PATH`. Otherwise your system won't find binaries installed via `go install` c. Using a (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available) d. Using a (AMD64, PPC64LE, ARMv6, ARMv7, and ARM64 available) e. Using the official (Helm) Prebuilt binaries can be validated by extracting the file and verifying it against the `sha256sum.txt` checksum file provided for each release starting with version `v3.0.0`. ``` $ sha256sum -c sha256sum.txt oauth2-proxy-x.y.z.linux-amd64: OK ``` (example provided for Nginx)
Project: FOSSA (Provisioning / Security & Compliance)
File: snippets.md

This subcommand is the home for FOSSA's snippet scanning feature. It is made up of two subcommands: See the pages linked above for more details. ```shell export FOSSAAPIKEY=XXXX cd $MYPROJECTDIR fossa snippets analyze -o snippets fossa snippets commit --analyze-output snippets fossa analyze ``` Short version: No. More detail explaining this is below. FOSSA CLI fingerprints your first party source code but does not send it to the server. The fingerprint is a SHA-256 hashed representation of the content that made up the snippet. FOSSA CLI does send the fingerprint to the server, but since SHA-256 hashes are , it is effectively not possible for FOSSA to reproduce the original code that went into the snippet. Of course, if the fingerprint matches FOSSA could then infer that the project contains that snippet of code, but since FOSSA CLI does not send any additional context in the file there's no way for FOSSA or anyone else to make use of this information. The code to perform this is open source in this CLI; users can also utilize tooling such as to report the information being uploaded. FOSSA snippet scanning operates over a matrix of options: ``` Targets Kinds Methods ``` Valid options for `Targets` are: Target | Description --|-- `Function` | Considers function declarations in the source code as snippet targets. Valid options for `Kinds` are: Kind | Description |- `Full` | The full expression that makes up the target. `Signature` | The function signature of `Function` targets. `Body` | The function body of `Function` targets. Valid options for `Methods` are: Method | Description --|-- `Raw` | The expression that makes up the target as written in the source code file. `NormalizedSpace` | The expression with any character in the Unicode replaced with a space, and any contiguous spaces collapsed to a single space. `NormalizedComment` | The expression with comments removed, as defined by the source code language. `NormalizedCode` | Equivalent to `NormalizedComment` followed by `NormalizedSpace`. Given these options, the fully defined matrix of options is as follows: ``` {Function} {Full, Signature, Body} {Raw, NormalizedSpace, NormalizedComment, NormalizedCode} ``` FOSSA then scans open source projects for these snippets and records them along with their metadata, such as where in the file the snippet originated and from what project. Finally, when users scan their first-party projects, FOSSA extracts snippets in the same manner and compares the fingerprints of the content of those snippets against the database. If a match is found, FOSSA reports all open source projects in which the snippet was found, along with recorded metadata about that snippet.
Project: StarRocks (App Definition and Development / Database)
File: sm3.md

displayed_sidebar: "English" Uses the SM3 digest algorithm to encrypt a string into a 256-bit hexadecimal string. Every 32 bits are separated by a space. Digest algorithms have a broad range of use cases in digital signature, message authentication, and data integrity check. The SM3 algorithm is an enhancement of SHA-256. ```Haskell SM3(str); ``` `str`: the string to encrypt. It must be of the VARCHAR type. Returns a value of the VARCHAR type. If the input is NULL, NULL is returned. If the input is empty, an error is returned. This function accepts only one string. More than one input string causes an error. ```Plain Text mysql> select sm3('l'); +-+ | sm3('l') | +-+ | 1dec1a7a 94236240 49db411e 2c32c62d c0c93856 8208ac3a 09d395eb 2468b445 | +-+ 1 row in set (0.01 sec) ```
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: Style.md

In the runtime code the use of unwrap & friends is forbidden as they do not provide hygienic errors to developers. Instead errors should be checked and a proper Result returned or error printed. If a function contains unwraps it often is a good path to make the function return a `Result<()>` even if we do not need the return value. In functions returning a Result an Option should be turned into an possible error instead of unwrapping it. This can be done by usin `okorelse` ```rust id.instance_port().unwrap() // becomes: id.instanceport().okor_else(|| Error::from(format!("missing instance port in {}.", id)))? ``` For unwraps that are known to be Some() (due to prior check) the unwrap can be written more explicitly: ```rust Ok(self.find(id).unwrap()) // becomes: if let Some(w) = self.find(id) { Ok(&w.artefact) } else { unreachable!() } ``` In tests `expect` can be used instead to give an indication of why something failed other then 'panic': ```rust let mut runtime = incarnate(config).unwrap(); // becomes: let mut runtime = incarnate(config).expect("failed to incarnate runtime"); ``` In `assert(_eq)!` statments Ok(...) can be shoud used on the right side if we want to test a positive result. ```rust assert_eq!( world.bind_onramp(id.clone()).unwrap(), ActivationState::Deactivated, ); // becomes: assert_eq!( world.bind_onramp(id.clone()), Ok(ActivationState::Deactivated), ); ```
Project: YugabyteDB (App Definition and Development / Database)
File: subprogram_call_signature.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="143" height="65" viewbox="0 0 143 65"><path class="connector" d="M0 52h35m-5 0q-5 0-5-5v-20q0-5 5-5h29m24 0h30q5 0 5 5v20q0 5-5 5m-5 0h35"/><polygon points="0,59 5,52 0,45" style="fill:black;stroke-width:0"/><rect class="literal" x="59" y="5" width="24" height="25" rx="7"/><text class="text" x="69" y="22">,</text><a xlink:href="../../syntaxresources/grammardiagrams#arg-type"><rect class="rule" x="35" y="35" width="73" height="25"/><text class="text" x="45" y="52">arg_type</text></a><polygon points="139,59 143,59 143,45 139,45" style="fill:black;stroke-width:0"/></svg>
Project: external-secrets (Provisioning / Security & Compliance)
File: all-keys-one-secret.md

To get multiple key-values from an external secret, not having to worry about how many, or what these keys are, we have to use the dataFrom field of the ExternalSecret resource, instead of the data field. We will give an example here with the gcp provider (should work with other providers in the same way). Please follow the authentication and SecretStore steps of the to setup access to your google cloud account first. Then create a secret in Google Cloud Secret Manager that contains a JSON string with multiple key values like this: Let's call this secret all-keys-example-secret on Google Cloud. Now, when creating our ExternalSecret resource, instead of using the data field, we use the dataFrom field: ```yaml {% include 'gcpsm-data-from-external-secret.yaml' %} ``` Here, "example" is the name of the external secret that will be created in our cluster. Whereas, "secret-to-be-created" is the name of Kubernetes secrets that will be created. Note: Since these secrets are namespace-based resources, you can also explicitly specify the "namespace" under the "metadata" block of the above external secret file. when we use, ``` dataFrom: extract: key: all-keys-example-secret ``` We get all the key-value pairs present over the remote secret store (GCP or AWS or Azure) and can pass either all or a few key-values as environment variables. Please note that, "all-keys-example-secret" is the name of your secret present on GCP/AWS secrets manager/Azure We can pass a few secrets as env variables as below: ``` env: name: key1 valueFrom: secretKeyRef: name: secret-to-be-created key: username name: key2 valueFrom: secretKeyRef: name: secret-to-be-created key: surname ``` Here, \<key1\> and \<key2> are the names of keys that will be created and passed as env variables. \<secret-to-be-created\>: is the name of your Kubernetes secret created by you. \<username\> and \<surname>: is the particular key in the secrets manager whose value you want to pass. To check both values we can run: ``` kubectl get secret secret-to-be-created -n <namespace> -o jsonpath='{.data.username}' | base64 -d kubectl get secret secret-to-be-created -n <namespace> -o jsonpath='{.data.surname}' | base64 -d ``` Also, if you have a large number of secrets and you want to pass all of them as enviromnent variables, then either you can replicate the above steps in your deployment file for all the keys or you can use the envFrom block as below: ``` spec: containers: command: mkdir abc.sh envFrom: secretRef: name: secret-to-be-created ```
Project: KICS (Provisioning / Security & Compliance)
File: 151187cb-0efc-481c-babd-ad24e3c9bc22.md

title: Remote Desktop Port Open To Internet hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 151187cb-0efc-481c-babd-ad24e3c9bc22 Query name: Remote Desktop Port Open To Internet Platform: Terraform Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: The Remote Desktop port is open to the internet in a Security Group<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1 14" resource "awssecuritygroup" "positive1" { name = "rdppositivetcp_1" description = "Gets the remote desktop port open with the tcp protocol" ingress { description = "Remote desktop port open" from_port = 3380 to_port = 3450 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } } resource "awssecuritygroup" "positive2" { name = "rdppositivetcp_2" description = "Gets the remote desktop port open with the tcp protocol" ingress { description = "Remote desktop port open" from_port = 3381 to_port = 3445 protocol = "tcp" cidr_blocks = ["1.0.0.0/0"] } ingress { description = "Remote desktop port open" from_port = 3000 to_port = 4000 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } } ``` ```tf title="Negative test num. 1 - tf file" resource "awssecuritygroup" "negative1" { name = "Dont open remote desktop port" description = "Doesn't enable the remote desktop port" } resource "awssecuritygroup" "negative2" { ingress { description = "Remote desktop open private" from_port = 3380 to_port = 3450 protocol = "tcp" } } resource "awssecuritygroup" "negativerdp2" { ingress { description = "Remote desktop open private" from_port = 3380 to_port = 3450 protocol = "tcp" cidr_blocks = ["0.1.0.0/0"] } } ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: ini.md

+++ title = "ini resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "ini" identifier = "inspec/resources/os/ini.md ini resource" parent = "inspec/resources/os" +++ Use the `ini` Chef InSpec audit resource to test settings in an INI file. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. An `ini` resource block declares the configuration settings to be tested: describe ini('path') do its('setting_name') { should eq 'value' } end where `'setting_name'` is a setting key defined in the INI file `('path')` is the path to the INI file `{ should eq 'value' }` is the value that is expected For example: describe ini('path/to/ini_file.ini') do its('port') { should eq '143' } its('server') { should eq '192.0.2.62' } end Settings inside of sections, such as the following: [section_name] setting_name = 123 ... can be retrieved by prefixing the setting_name with the section. its('sectionname.settingname') { should cmp 123 } In the event a section or setting name has a period in it, the alternate syntax can be used: its(['section.with.a.dot.in.it', 'setting.name.with.dots']) { should cmp 'lots-of-dots' } This resource supports any of the settings listed in an INI file as properties. The following examples show how to use this Chef InSpec audit resource. For example, a PHP INI file located at contains the following settings: [mail function] SMTP = smtp.gmail.com smtp_port = 465 and can be tested like this: describe ini('/etc/php5/apache2/php.ini') do its('mail function.smtp_port') { should eq('465') } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: DevSpace (App Definition and Development / Application Definition & Image Build)
File: devspace_build.md

title: "Command - devspace build" sidebar_label: devspace build Builds all defined images and pushes them ``` devspace build [flags] ``` ``` Builds all defined images and pushes them ``` ``` --build-sequential Builds the images one after another instead of in parallel --dependency strings Builds only the specific named dependencies -b, --force-build Forces to build every image --force-dependencies Forces to re-evaluate dependencies (use with --force-build --force-deploy to actually force building & deployment of dependencies) (default true) -h, --help help for build --max-concurrent-builds int The maximum number of image builds built in parallel (0 for infinite) --skip-dependency strings Skips building the following dependencies --skip-push Skips image pushing, useful for minikube deployment --skip-push-local-kube Skips image pushing, if a local kubernetes environment is detected -t, --tag strings Use the given tag for all built images --verbose-dependencies Builds the dependencies verbosely (default true) ``` ``` --config string The devspace config file to use --debug Prints the stack trace if an error occurs --disable-profile-activation If true will ignore all profile activations --inactivity-timeout int Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems (default 180) --kube-context string The kubernetes context to use -n, --namespace string The kubernetes namespace to use --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before -p, --profile strings The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified --profile-parent strings One or more profiles that should be applied before the specified profile (e.g. devspace dev --profile-parent=base1 --profile-parent=base2 --profile=my-profile) --profile-refresh If true will pull and re-download profile parent sources --restore-vars If true will restore the variables from kubernetes before loading the config --save-vars If true will save the variables to kubernetes after loading the config --silent Run in silent mode and prevents any devspace log output except panics & fatals -s, --switch-context DEPRECATED: Switches and uses the last kube context and namespace that was used to deploy the DevSpace project --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) --vars-secret string The secret to restore/save the variables from/to, if --restore-vars or --save-vars is enabled (default "devspace-vars") ```
Project: KICS (Provisioning / Security & Compliance)
File: 59a849c2-1127-4023-85a5-ef906dcd458c.md

title: BOM - AWS SQS hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 59a849c2-1127-4023-85a5-ef906dcd458c Query name: BOM - AWS SQS Platform: CloudFormation Severity: <span style="color:#CCCCCC">Trace</span> Category: Bill Of Materials URL: A list of SQS resources specified. Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="2" Resources: MyQueue: Type: AWS::SQS::Queue Properties: QueueName: "SampleQueue" KmsMasterKeyId: wewewewewewe SampleSQSPolicy: Type: AWS::SQS::QueuePolicy Properties: Queues: !Ref MyQueue PolicyDocument: Statement: Action: "SQS:SendMessage" "SQS:ReceiveMessage" Effect: "Allow" Resource: "arn:aws:sqs:us-east-2:444455556666:queue2" Principal: AWS: "111122223333" ``` ```json title="Positive test num. 2 - json file" hl_lines="3" { "Resources": { "MyQueue": { "Type": "AWS::SQS::Queue", "Properties": { "QueueName": "SampleQueue" } } } } ``` ```yaml title="Negative test num. 1 - yaml file" AWSTemplateFormatVersion: '2010-09-09' Resources: myDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true ``` ```json title="Negative test num. 2 - json file" { "AWSTemplateFormatVersion": "2010-09-09", "Resources": { "myDistribution": { "Type": "AWS::CloudFront::Distribution", "Properties": { "DistributionConfig": { "Enabled": "true" } } } } } ```
Project: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_debug_postgres.md

title: Kubectl-Dba Debug Postgres menu: docs_{{ .version }}: identifier: kubectl-dba-debug-postgres name: Kubectl-Dba Debug Postgres parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Debug helper for postgres database ``` kubectl-dba debug postgres [flags] ``` ``` kubectl dba debug postgres -n demo sample-postgres --operator-namespace kubedb ``` ``` -h, --help help for postgres -o, --operator-namespace string the namespace where the kubedb operator is installed (default "kubedb") ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "/home/runner/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --default-seccomp-profile-type string Default seccomp profile --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --password string Password for basic authentication to the API server --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use --username string Username for basic authentication to the API server ``` - Debug any Database issue
Project: Kyverno (Provisioning / Security & Compliance)
File: CODE_OF_CONDUCT.md

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Examples of unacceptable behavior by participants include: The use of sexualized language or imagery Personal attacks Trolling or insulting/derogatory comments Public or private harassment Publishing other's private information, such as physical or electronic addresses, without explicit permission Other unethical or unprofessional conduct. 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. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Instances of abusive, harassing, or otherwise unacceptable behavior in Kubernetes may be reported by contacting the project maintainer(s). This Code of Conduct is adapted from the and the , .
Project: ClickHouse (App Definition and Development / Database)
File: v21.5.3.1-prestable.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix crash when `PREWHERE` and row policy filter are both in effect with empty result. (). Backported in : Fixed remote JDBC bridge timeout connection issue. Closes . (). Backported in : Fix `CLEAR COLUMN` does not work when it is referenced by materialized view. Close . (). Backported in : Fix error `Can't initialize pipeline with empty pipe` for queries with `GLOBAL IN/JOIN` and `usehedgedrequests`. Fixes . (). Backported in : HashedDictionary complex key update field initial load fix. Closes . (). Flat, Hashed dictionary include update field bytes into bytes_allocated ().