cwielenb/CNCF-Dataset huggingface dataset:
Project: ThreatMapper (Provisioning / Security & Compliance)
File: deploy-console.md

title: Deploy Console You should first and push the images to a suitable repository. You can then adapt the standard installation instructions (, ) to refer to your custom images rather than the Deepfence-provided ones. :::tip Refer to the along with the modifications below. ::: Download the file to the system that will host the Console ```bash wget https://github.com/deepfence/ThreatMapper/raw/release-2.1/deployment-scripts/docker-compose.yml ``` Execute the following command to install and start the Console. Note the override to specify your repository `myorg`, rather than the `deepfenceio` default: ```bash ACC=myorg # the name of the dockerhub account docker login -u $ACC # log in to the account IMAGE_REPOSITORY=$ACC docker-compose -f docker-compose.yml up --detach ``` :::tip Refer to the along with the modifications below. ::: Prepare the cluster, installing the storage driver and metrics service Follow the instructions to install the OpenEBS storage and metrics server: Install your Management Console We will install the Management Console using the helm chart, but overriding the repository source for the images: ```bash helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper helm repo update helm show values deepfence/deepfence-console --version 2.1.3 > deepfenceconsolevalues.yaml ``` Edit the `deepfenceconsolevalues.yaml` file, replacing the `image: repository:` value to point to your repository, and making any other changes as needed. Install the management console: ```bash helm install -f deepfenceconsolevalues.yaml deepfence-console deepfence/deepfence-console --version 2.1.3 ``` Full instructions can be found in the . Optional: enable external access with the `deepfence-router` package: Refer to the instructions to install the , typically as follows: ```bash helm show values deepfence/deepfence-router --version 2.1.1 > deepfenceroutervalues.yaml ``` Edit the `deepfenceroutervalues.yaml` file, replacing the `image: repository:` value to point to your repository, and making any other changes as needed. ```bash helm install -f deepfenceroutervalues.yaml deepfence-router deepfence/deepfence-router --version 2.1.1 ```
Project: external-secrets (Provisioning / Security & Compliance)
File: getting-started.md

External-secrets runs within your Kubernetes cluster as a deployment resource. It utilizes CustomResourceDefinitions to configure access to secret providers through SecretStore resources and manages Kubernetes secret resources with ExternalSecret resources. Note: The minimum supported version of Kubernetes is `1.16.0`. Users still running Kubernetes v1.15 or below should upgrade to a supported version before installing external-secrets. The default install options will automatically install and manage the CRDs as part of your helm release. If you do not want the CRDs to be automatically upgraded and managed, you must set the `installCRDs` option to `false`. (e.g. `--set installCRDs=false`) You can install those CRDs outside of `helm` using: ```bash kubectl apply -k "https://raw.githubusercontent.com/external-secrets/external-secrets/<replacewithyour_version>/deploy/crds/bundle.yaml" ``` Uncomment the relevant line in the next steps to disable the automatic install of CRDs. ```bash helm repo add external-secrets https://charts.external-secrets.io helm install external-secrets \ external-secrets/external-secrets \ -n external-secrets \ --create-namespace \ ``` Build and install the Helm chart locally after cloning the repository. ```bash make helm.build helm install external-secrets \ ./bin/chart/external-secrets.tgz \ -n external-secrets \ --create-namespace \ ``` ```shell echo -n 'KEYID' > ./access-key echo -n 'SECRETKEY' > ./secret-access-key kubectl create secret generic awssm-secret --from-file=./access-key --from-file=./secret-access-key ``` Create a file 'basic-secret-store.yaml' with the following content. ```yaml {% include 'basic-secret-store.yaml' %} ``` Apply it to create a SecretStore resource. ``` kubectl apply -f "basic-secret-store.yaml" ``` Create a file 'basic-external-secret.yaml' with the following content. ```yaml {% include 'basic-external-secret.yaml' %} ``` Apply it to create an External Secret resource. ``` kubectl apply -f "basic-external-secret.yaml" ``` ```bash kubectl describe externalsecret example Name: example Status: Binding: Name: secret-to-be-created Conditions: Last Transition Time: 2021-02-24T16:45:23Z Message: Secret was synced Reason: SecretSynced Status: True Type: Ready Refresh Time: 2021-02-24T16:45:24Z Events: <none> ``` For more advanced examples, please read the other . External-secrets can be managed by (OLM) via an installer operator. It is made available through , this installation method is suited best for OpenShift. See installation instructions on the package. Before continuing, ensure that all external-secret resources that have been created by users have been deleted. You can check for any existing resources with the following command: ```bash kubectl get SecretStores,ClusterSecretStores,ExternalSecrets --all-namespaces ``` Once all these resources have been deleted you are ready to uninstall external-secrets. Uninstall the helm release using the delete command. ```bash helm delete external-secrets --namespace external-secrets ```
Project: Meshery (Provisioning / Automation & Configuration)
File: 10-31-2023-03-55-10_d2f1b165.md

timestamp: "2023-10-31 03:54:43 UTC Tue" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "*name" k8s-distro: minikube k8s-version: "v1.25.2" service-mesh: Consul service-mesh-version: "v1.2.2" tests: consul-client: null consul-server: null overall-status: "failing"
Project: Kubescape (Provisioning / Security & Compliance)
File: PULL_REQUEST_TEMPLATE.md

<!-- Please provide a brief overview of the changes made in this pull request. e.g. current behavior/future behavior --> <!-- Any additional information that may be useful for reviewers to know --> <!-- Please provide instructions on how to test the changes made in this pull request --> <!-- Here you add related screenshots --> <!-- Here you add related issues and PRs. If this resolved an issue, write "Resolved #<issue number> e.g. If this PR resolves issues 1 and 2, it should look as follows: Resolved #1 Resolved #2 --> <!-- put an [x] in the box to get it checked [ ] My code follows the style guidelines of this project [ ] I have commented on my code, particularly in hard-to-understand areas [ ] I have performed a self-review of my code [ ] If it is a core feature, I have added thorough tests. [ ] New and existing unit tests pass locally with my changes -->
Project: kube-bench (Provisioning / Security & Compliance)
File: asff.md

You can configure kube-bench with the `--asff` to send findings to AWS Security Hub. There are some additional steps required so that kube-bench has information and permissions to send these findings. You will need AWS Security Hub to be enabled in your account In the Security Hub console, under Integrations, search for kube-bench <p align="center"> <img src="./images/kube-bench-security-hub.png"> </p> Click on `Accept findings`. This gives information about the IAM permissions required to send findings to your Security Hub account. kube-bench runs within a pod on your EKS cluster, and will need to be associated with a Role that has these permissions. Grant these permissions to the IAM Role that the kube-bench pod will be associated with. There are two options: You can run the kube-bench pod under a specific that has these permissions to write Security Hub findings. Alternatively the pod can be granted permissions specified by the Role that your . Here is an example IAM Policy that you can attach to your EKS node group's IAM Role: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "securityhub:BatchImportFindings", "Resource": [ "arn:aws:securityhub:us-east-1::product/aqua-security/kube-bench" ] } ] } ``` Modify the kube-bench Configmap in `job-eks-asff.yaml` to specify the AWS account, AWS region, and the EKS Cluster ARN. In the same file, modify the image specifed in the Job to use the kube-bench image pushed to your ECR , you will need to add the IAM role arn to the kube-bench ServiceAccount in `job-eks-asff.yaml`. Make sure that `job-eks-asff.yaml` specifies the container image you just pushed to your ECR registry. You can now run kube-bench as a pod in your cluster: `kubectl apply -f job-eks-asff.yaml` Findings will be generated for any kube-bench test that generates a `[FAIL]` or `[WARN]` output. If all tests pass, no findings will be generated. However, it's recommended that you consult the pod log output to check whether any findings were generated but could not be written to Security Hub. <p align="center"> <img src="./images/asff-example-finding.png"> </p>
Project: YugabyteDB (App Definition and Development / Database)
File: perf_deallocate.md

title: DEALLOCATE statement [YSQL] headerTitle: DEALLOCATE linkTitle: DEALLOCATE description: Use the `DEALLOCATE` statement to deallocate a previously prepared SQL statement. menu: v2.18: identifier: perf_deallocate parent: statements type: docs Use the `DEALLOCATE` statement to deallocate a previously prepared SQL statement. {{%ebnf%}} deallocate {{%/ebnf%}} Specify the name of the prepared statement to deallocate. Deallocate all prepared statements. Prepare and deallocate an insert statement. ```plpgsql yugabyte=# CREATE TABLE sample(k1 int, k2 int, v1 int, v2 text, PRIMARY KEY (k1, k2)); ``` ```plpgsql yugabyte=# PREPARE ins (bigint, double precision, int, text) AS INSERT INTO sample(k1, k2, v1, v2) VALUES ($1, $2, $3, $4); ``` ```plpgsql yugabyte=# DEALLOCATE ins; ```
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.2.7.6.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Major | Add posixGroups support for LDAP groups mapping service* Add posixGroups support for LDAP groups mapping service. The change in LDAPGroupMapping is compatible with previous scenario. In LDAP, the group mapping between {{posixAccount}} and {{posixGroup}} is different from the general LDAPGroupMapping, one of the differences is the {{"memberUid"}} will be used to mapping {{posixAccount}} and {{posixGroup}}. The feature will handle the mapping in internal when configuration {{hadoop.security.group.mapping.ldap.search.filter.user}} is set as "posixAccount" and {{hadoop.security.group.mapping.ldap.search.filter.group}} is "posixGroup". | Major | Support timeouts in LDAP queries in LdapGroupsMapping.* This patch adds two new config keys for supporting timeouts in LDAP query operations. The property "hadoop.security.group.mapping.ldap.connection.timeout.ms" is the connection timeout (in milliseconds), within which period if the LDAP provider doesn't establish a connection, it will abort the connect attempt. The property "hadoop.security.group.mapping.ldap.read.timeout.ms" is the read timeout (in milliseconds), within which period if the LDAP provider doesn't get a LDAP response, it will abort the read attempt. | Major | Reload cached groups in background after expiry* hadoop.security.groups.cache.background.reload can be set to true to enable background reload of expired groups cache entries. This setting can improve the performance of services that use Groups.java (e.g. the NameNode) when group lookups are slow. The setting is disabled by default.
Project: Flink (App Definition and Development / Streaming & Messaging)
File: flink-1.6.md

title: "Release Notes - Flink 1.6" <!-- 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. --> These release notes discuss important aspects, such as configuration, behavior, or dependencies, that changed between Flink 1.5 and Flink 1.6. Please read these notes carefully if you are planning to upgrade your Flink version to 1.6. The default value of the slot idle timeout `slot.idle.timeout` is set to the default value of the heartbeat timeout (`50 s`). Previous APIs in the Flink Elasticsearch 5.x Sink's `RequestIndexer` interface have been deprecated in favor of new signatures. When adding requests to the `RequestIndexer`, the requests now must be of type `IndexRequest`, `DeleteRequest`, or `UpdateRequest`, instead of the base `ActionRequest`. <!-- Remove once FLINK-10712 has been fixed --> Flink's non-default failover strategies are still a very experimental feature which come with a set of limitations. You should only use this feature if you are executing a stateless streaming job. In any other cases, it is highly recommended to remove the config option `jobmanager.execution.failover-strategy` from your `flink-conf.yaml` or set it to `"full"`. In order to avoid future problems, this feature has been removed from the documentation until it will be fixed. See for more details. {{< top >}}
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: kbcli_clusterversion_list.md

title: kbcli clusterversion list List ClusterVersions. ``` kbcli clusterversion list [flags] ``` ``` kbcli clusterversion list ``` ``` --cluster-definition string Specify cluster definition, run "kbcli clusterdefinition list" to show all available cluster definition -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml, wide (default table) -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Matching objects must satisfy all of the specified label constraints. --show-labels When printing, show all labels as the last column (default hide labels column) ``` ``` --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/.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 --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 --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 ``` - ClusterVersion command.
Project: ClickHouse (App Definition and Development / Database)
File: opentelemetry_span_log.md

slug: /en/operations/system-tables/opentelemetryspanlog Contains information about for executed queries. Columns: `trace_id` () ID of the trace for executed query. `span_id` () ID of the `trace span`. `parentspanid` () ID of the parent `trace span`. `operation_name` () The name of the operation. `kind` () The of the span. `INTERNAL` Indicates that the span represents an internal operation within an application. `SERVER` Indicates that the span covers server-side handling of a synchronous RPC or other remote request. `CLIENT` Indicates that the span describes a request to some remote service. `PRODUCER` Indicates that the span describes the initiators of an asynchronous request. This parent span will often end before the corresponding child CONSUMER span, possibly even before the child span starts. `CONSUMER` - Indicates that the span describes a child of an asynchronous PRODUCER request. `starttimeus` () The start time of the `trace span` (in microseconds). `finishtimeus` () The finish time of the `trace span` (in microseconds). `finish_date` () The finish date of the `trace span`. `attribute.names` (()) names depending on the `trace span`. They are filled in according to the recommendations in the standard. `attribute.values` (()) Attribute values depending on the `trace span`. They are filled in according to the recommendations in the `OpenTelemetry` standard. Example Query: ``` sql SELECT * FROM system.opentelemetryspanlog LIMIT 1 FORMAT Vertical; ``` Result: ``` text Row 1: trace_id: cdab0847-0d62-61d5-4d38-dd65b19a1914 span_id: 701487461015578150 parentspanid: 2991972114672045096 operation_name: DB::Block DB::InterpreterSelectQuery::getSampleBlockImpl() kind: INTERNAL starttimeus: 1612374594529090 finishtimeus: 1612374594529108 finish_date: 2021-02-03 attribute.names: [] attribute.values: [] ``` See Also
Project: KICS (Provisioning / Security & Compliance)
File: 4003118b-046b-4640-b200-b8c7a4c8b89f.md

title: SSO Identity User Unsafe Creation hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 4003118b-046b-4640-b200-b8c7a4c8b89f Query name: SSO Identity User Unsafe Creation Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: The use of AWS SSO for creating users may pose a security risk as it does not synchronize with external Identity Providers (IdP) or Active Directory (AD). This can lead to inconsistencies and potential unauthorized access to resources. It is recommended to review and update user creation processes to ensure proper security protocols are in place.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "awsidentitystoreuser" "example" { identitystoreid = tolist(data.awsssoadmininstances.example.identitystoreids)[0] display_name = "John Doe" user_name = "johndoe" name { given_name = "John" family_name = "Doe" } emails { value = "john@example.com" } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsssoadminpermissionsetinline_policy" "neg1" { instancearn = awsssoadminpermissionset.example.instance_arn permissionsetarn = awsssoadminpermission_set.example.arn inline_policy = <<POLICY { "Statement": [ { "Action": [ "s3:ListBucket*", "s3:HeadBucket", "s3:Get*" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::b1", "arn:aws:s3:::b1/*", "arn:aws:s3:::b2", "arn:aws:s3:::b2/*" ], "Sid": "" }, { "Action": "s3:PutObject*", "Effect": "Allow", "Resource": "arn:aws:s3:::b1/*", "Sid": "" } ], "Version": "2012-10-17" } POLICY } ```
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: service-binding.eg.md

Prepare a Kubernetes Secret The secret can be manually created, or generated by other component or external system. For example, we have a secret `db-conn-example` whose data is as below: ```yaml endpoint: https://xxx.com password: 123 username: myname ``` Bind the Secret into your component by `service-binding` trait For example, we have a webservice component who needs to consume a database. The database connection string should be set to Pod environments: `endpoint`, `username` and `DB_PASSWORD`. We can set the properties for envMappings as below. For each environment, `secret` represents the secret name, and `key` represents the key of the secret. Here is the complete properties for the trait. ```yaml traits: type: service-binding properties: envMappings: DB_PASSWORD: secret: db-conn-example key: password endpoint: secret: db-conn-example key: endpoint username: secret: db-conn-example key: username ``` In particular, if the environment name, like `endpoint`, is same to the `key` of the secret, we can omit the `key`. So we can simplify the properties as below. ```yaml traits: type: service-binding properties: envMappings: DB_PASSWORD: secret: db-conn-example key: password endpoint: secret: db-conn-example username: secret: db-conn-example ``` We can finally prepare an Application for the business component `binding-test-comp` to consume the secret, which is a representative of a database cloud resource. ```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: webapp spec: components: name: binding-test-comp type: webservice properties: image: zzxwill/flask-web-application:v0.3.1-crossplane ports: 80 traits: type: service-binding properties: envMappings: DB_PASSWORD: secret: db-conn-example key: password endpoint: secret: db-conn-example username: secret: db-conn-example ``` Deploy this YAML and the Secret `db-conn-example` will be binding into environment of workload.
Project: FOSSA (Provisioning / Security & Compliance)
File: setuptools-qr.md

Ideal `requirements.txt` files present in your project Minimum `setup.py` files present in your project. Unfortunately, we fail to parse many valid `setup.py` files. In general, we recommend the use of `requirements.txt` files for better analysis. Directories containing `setup.py` files or `requirements.txt`-like files (e.g., `req-dev.txt`, `test-requires.txt` are valid -- or any filename matching the regex `.req.\.txt`) are treated as setuptools projects.
Project: Pomerium (Provisioning / Key Management)
File: feature_request.md

name: Feature request about: Suggest something! Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like Describe alternatives you've considered Explain any additional use-cases If there are any use-cases that would help us understand the use/need/value please share them as they can help us decide on acceptance and prioritization. Additional context Add any other context or screenshots about the feature request here.
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: cache-to.md

Set this flag to specify a remote repository that is used to store cache images. Buildah attempts to push newly built cache image to the remote repository. Note: Use the `--cache-from` option in order to use cache content in a remote repository. Example ```bash buildah build -t test --layers --cache-to registry/myrepo/cache --cache-from registry/myrepo/cache . ``` Note: `--cache-to` option is ignored unless `--layers` is specified.
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: print-message-in-status.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: print-message-in-status namespace: default spec: components: name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 workflow: steps: name: express-server type: apply-component properties: component: express-server name: message type: print-message-in-status properties: message: "All addons have been enabled successfully, you can use 'vela addon list' to check them." ```