cwielenb/CNCF-Dataset huggingface dataset:
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: istio-authorization-mixer.md

title: Container Network Authorization with Istio (as part of Mixer) labels: category: servicemesh layer: network software: istio tutorials: https://istio.io/docs/reference/config/policy-and-telemetry/adapters/opa/ code: https://github.com/istio/istio/tree/master/mixer/adapter/opa inventors: google Istio is a networking abstraction for cloud-native applications. In this Istio integration OPA hooks into the centralized Mixer component of Istio, to provide fine-grained, context-aware authorization for network or HTTP requests.
Project: Tetragon (Provisioning / Security & Compliance)
File: TROUBLESHOOTING.md

The most common reason for this issue is improper use of struct tags (eg. `yaml` or `json`). Viper uses under the hood for unmarshaling values which uses `mapstructure` tags by default. Please refer to the library's documentation for using other struct tags. Viper installation seems to fail a lot lately with the following (or a similar) error: ``` cannot find package "github.com/hashicorp/hcl/tree/hcl1" in any of: /usr/local/Cellar/go/1.15.7_1/libexec/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOROOT) /Users/user/go/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOPATH) ``` As the error message suggests, Go tries to look up dependencies in `GOPATH` mode (as it's commonly called) from the `GOPATH`. Viper opted to use to manage its dependencies. While in many cases the two methods are interchangeable, once a dependency releases new (major) versions, `GOPATH` mode is no longer able to decide which version to use, so it'll either use one that's already present or pick a version (usually the `master` branch). The solution is easy: switch to using Go Modules. Please refer to the on how to do that. tl;dr* `export GO111MODULE=on` This is a YAML 1.1 feature according to . Potential solutions are: Quoting values resolved as boolean Upgrading to YAML v3 (for the time being this is possible by passing the `viper_yaml3` tag to your build)
Project: YugabyteDB (App Definition and Development / Database)
File: managed-cli-vpc.md

title: ybm CLI vpc resource headerTitle: ybm vpc linkTitle: vpc description: YugabyteDB Managed CLI reference VPC resource. headcontent: Manage account VPCs menu: preview_yugabyte-cloud: identifier: managed-cli-vpc parent: managed-cli-reference weight: 20 type: docs Use the `vpc` resource to create and delete . ```text Usage: ybm vpc [command] [flags] ``` Create a global VPC on GCP: ```sh ybm vpc create \ --name demo-vpc \ --cloud-provider GCP \ --global-cidr 10.0.0.0/18 ``` Create a VPC. | Flag | Description | | : | : | | --name | Required. Name for the VPC. | | --cloud-provider | Cloud provider for the VPC. `AWS`, `AZURE`, or `GCP`. | | --global-cidr | Global CIDR for a GCP VPC. | | --region | Comma-delimited list of regions for the VPC. | | --cidr | Comma-delimited list of CIDRs for the regions in the VPC. Only required if `--region` specified. | Delete a specified VPC. | Flag | Description | | : | : | | --name | Required. Name of the VPC. | List the VPCs configured for your account. | Flag | Description | | : | : | | --name | Name of a VPC. |
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.146.md

layout: release date: 2023-09-24 tag: v0.6.146 MeshKit v0.6.67 @leecalcote (#8897) [UI] Notification Center: Increase size of unread indicator @leecalcote (#8891) [extensions] fix error msg @theBeginner86 (#8892) changed smi_results.js @EraKin575 (#8868) Connections row expand data with styling @senali-d (#8840) [Fix] k8s-switcher select-all @aabidsofi19 (#8876) [CI] e2e test job improvements @MarioArriaga92 (#8643) updating node versions workflow actions @Philip-21 (#8856) [CI] e2e test job improvements @MarioArriaga92 (#8643) Thank you to our contributors for making this release possible: @EraKin575, @MUzairS15, @MarioArriaga92, @Philip-21, @aabidsofi19, @l5io, @leecalcote, @senali-d, @theBeginner86 and l5io
Project: EMQ Technologies (App Definition and Development / Streaming & Messaging)
File: fix-12895.en.md

Complemented some necessary but missed keys for the DynamoDB connector and the action. The old configuration no longer works, although it actually didn't work properly until this fix. For DynamoDB connector, a new key `region` is necessary. `hashkey` and `rangekey` are now supported in the DynamoDB action, and `hash_key` is required.
Project: StackRox (Provisioning / Security & Compliance)
File: 0008-nvd-enricher.md

Author(s): J. Victor Martins <jvdm@sdf.org> Created: [2024-01-22 Mon] Status: Accepted. Updates: The CVSS scores enricher does not offer all the necessary functionality to fulfill Stackrox Scanner's need for NVD data: It only pulls CVSS scores into the enrichment table. Stackrox Scanner must pull additional data in NVD CVE objects to fill in incomplete information in specific security sources (e.g., Alpine). Additionally, Stackrox Scanner wants to open the door to offer users the option to pull NVD in addition to the vulnerability information provided by the image provider's security source. At the time of this writing, ClairCore enricher does not support NVD API v2 and is still relying on the deprecated NVD v2 JSON documents. Moreover, after the merge of ClairCore's , enrichment can bundle their data into offline JSON blobs, which can be consumed with vulnerability data. Previously, this was not possible, and created a pipeline for that data. This pipeline is now unnecessary. Stackrox Scanner will have its own CVSS enricher that: Pulls information from NVD API v2. Pulls additional CVE information from NVD, leaving the door open to add or remove information as needed. Replaces the NVD CVSS score pipeline by using the enricher in the vulnerability bundle exporter to consume the enrichments and vulnerability data later. Stackrox Scanner can decommission the NVD CVSS pipeline (workflows and Central handlers). Stackrox Scanner can programmatically add or remove additional NVD information to the security sources. The enricher allows for filtering NVD data not used to reduce bundle sizes and increase them as needed. Vulnerability bundles are currently versioned, so changes to NVD information captured by the enricher don't have to be backward compatible.
Project: YDB (App Definition and Development / Database)
File: parameterized_queries.md

{{ ydb-short-name }} supports and recommends the use of so-called . In such queries, the data is transmitted separately from the request body itself, and in the SQL query, special parameters are used to indicate the location of the data. Request with data in the request body: ```sql SELECT sa.title AS seasontitle, sr.title AS seriestitle FROM seasons AS sa INNER JOIN series AS sr ON sa.seriesid = sr.seriesid WHERE sa.seriesid = 15 AND sa.seasonid = 3 ``` The corresponding parameterized query: ```sql DECLARE $seriesId AS Uint64; DECLARE $seasonId AS Uint64; SELECT sa.title AS seasontitle, sr.title AS seriestitle FROM seasons AS sa INNER JOIN series AS sr ON sa.seriesid = sr.seriesid WHERE sa.seriesid = $seriesId AND sa.seasonid = $seasonId ``` Parameterized queries are written in the form of a template in which certain types of names are replaced with specific parameters each time the query is executed. Tokens starting with the sign `$` such as `$seriesId` and `$seasonId` in the query above are used to denote parameters. Parameterized queries provide the following advantages: For repeated requests, the database server has the ability to cache the query plan for parameterized requests. This radically reduces CPU consumption and increases system throughput. The use of parameterized queries saves from vulnerabilities like . {{ ydb-short-name }} SDK automatically caches parameterized query plans by default, the setting `KeepInCache = true` is usually used for this.
Project: ShardingSphere (App Definition and Development / Database)
File: alter-readwrite-splitting-rule.en.md

+++ title = "ALTER READWRITE_SPLITTING RULE" weight = 2 +++ The `ALTER READWRITE_SPLITTING RULE` syntax is used to alter a readwrite-splitting rule. {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterReadwriteSplittingRule ::= 'ALTER' 'READWRITE_SPLITTING' 'RULE' readwriteSplittingDefinition (',' readwriteSplittingDefinition)* readwriteSplittingDefinition ::= ruleName '(' dataSourceDefinition (',' transactionalReadQueryStrategyDefinition)? (',' loadBalancerDefinition)? ')' dataSourceDefinition ::= 'WRITESTORAGEUNIT' '=' writeStorageUnitName ',' 'READSTORAGEUNITS' '(' storageUnitName (',' storageUnitName)* ')' transactionalReadQueryStrategyDefinition ::= 'TRANSACTIONALREADQUERY_STRATEGY' '=' transactionalReadQueryStrategyType loadBalancerDefinition ::= 'TYPE' '(' 'NAME' '=' algorithmType (',' propertiesDefinition)? ')' ruleName ::= identifier writeStorageUnitName ::= identifier storageUnitName ::= identifier transactionalReadQueryStrategyType ::= string algorithmType ::= string propertiesDefinition ::= 'PROPERTIES' '(' key '=' value (',' key '=' value)* ')' key ::= string value ::= literal ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} `transactionalReadQueryStrategyType` specifies the routing strategy for read query within a transaction, please refer to ; `algorithmType` specifies the load balancing algorithm type, please refer to . ```sql ALTER READWRITESPLITTING RULE msgroup_0 ( WRITESTORAGEUNIT=write_ds, READSTORAGEUNITS(readds0,readds1), TYPE(NAME="random") ); ``` `ALTER`, `READWRITESPLITTING`, `RULE`, `WRITESTORAGEUNIT`, `READSTORAGE_UNITS` , `TYPE`, `NAME`, `PROPERTIES`, `TRUE`, `FALSE`
Project: KICS (Provisioning / Security & Compliance)
File: ec28bf61-a474-4dbe-b414-6dd3a067d6f0.md

title: Cognito UserPool Without MFA hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ec28bf61-a474-4dbe-b414-6dd3a067d6f0 Query name: Cognito UserPool Without MFA Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Best Practices URL: AWS Cognito UserPool should have MFA (Multi-Factor Authentication) defined to users<br> ```tf title="Positive test num. 1 - tf file" hl_lines="16 1 32" resource "awscognitouser_pool" "positive1" { smsauthenticationmessage = "Your code is {####}" sms_configuration { external_id = "example" snscallerarn = awsiamrole.example.arn } softwaretokenmfa_configuration { enabled = true } } resource "awscognitouser_pool" "positive2" { mfa_configuration = "OFF" smsauthenticationmessage = "Your code is {####}" sms_configuration { external_id = "example" snscallerarn = awsiamrole.example.arn } softwaretokenmfa_configuration { enabled = true } } resource "awscognitouser_pool" "positive3" { mfa_configuration = "ON" smsauthenticationmessage = "Your code is {####}" } ``` ```tf title="Negative test num. 1 - tf file" resource "awscognitouser_pool" "negative1" { mfa_configuration = "ON" smsauthenticationmessage = "Your code is {####}" sms_configuration { external_id = "example" snscallerarn = awsiamrole.example.arn } } resource "awscognitouser_pool" "negative2" { mfa_configuration = "OPTIONAL" smsauthenticationmessage = "Your code is {####}" softwaretokenmfa_configuration { enabled = true } } ```
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: sql-ref-syntax-aux-conf-mgmt.md

layout: global title: Configuration Management displayTitle: Configuration Management 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. *
Project: external-secrets (Provisioning / Security & Compliance)
File: multi-tenancy.md

External Secrets Operator provides different modes of operation to fulfill organizational needs. This guide outlines the flexibility of ESO and should give you a first impression of how you can employ this operator in your organization. For a multi-tenant deployment you should first examine your organizational structure: what roles (i.e. Application Developers, Cluster Admins, ...) do you have in your organization, what responsibilities do they have and how does that map to Kubernetes RBAC roles. Further, you should examine how your external API provider manages access control for your secrets. Can you limit access by secret names (e.g. `db/dev/*`)? Or only on a bucket level? Please keep in mind that not all external APIs provide fine-grained access management for secrets. Note: The following examples should not be considered as best practice but rather as a example to show how to combine different mechanics and techniques for tenant isolation. A Cluster Administrator deploys a `ClusterSecretStore` (CSS) and manages access to the external API. The CSS is shared by all tenants within the cluster. Application Developers do reference it in a `ExternalSecret` but can not create a ClusterSecretStores or SecretStores on their own. Now all application developers have access to all the secrets. You probably want to limit access to certain keys or prefixes that should be used. ESO does not provide a mechanic to limit access to certain keys per namespace. More advanced validation should be done with an Admission Webhook, e.g. with or ). This setup suites well if you have one central bucket that contains all of your secrets and your Cluster Administrators should manage access to it. This setup is very simple but does not scale very well. Cluster Administrators manage one or multiple `SecretStores` per Namespace. Each SecretStore uses it's own role that limits access to a small set of keys. The peculiarity of this is approach is, that access is actually managed by the external API which provides the roles. The Cluster Administrator does just the wiring. This approach may be desirable if you have an external entity - let's call it Secret Administrator - that manages access and lifecycle of the secrets. Every namespace is self-contained. Application developers manage `SecretStore`, `ExternalSecret` and secret infrastructure on their own. Cluster Administrators just provide the External Secrets Operator as a service. This makes sense if application developers should be completely autonomous while a central team provides common services.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_ml_engine_models.md

+++ title = "googlemlengine_models resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlemlengine_models" identifier = "inspec/resources/gcp/googlemlenginemodels.md googlemlenginemodels resource" parent = "inspec/resources/gcp" +++ A `googlemlengine_models` is used to test a Google Model resource ```ruby describe googlemlengine_models(project: 'chef-gcp-inspec') do its('descriptions') { should include 'My awesome ML model' } its('onlinepredictionloggings') { should include 'true' } its('onlinepredictionconsole_loggings') { should include 'true' } end ``` Properties that can be accessed from the `googlemlengine_models` resource: See the resource for more information. `names` : an array of `googlemlengine_model` name `descriptions` : an array of `googlemlengine_model` description `default_versions` : an array of `googlemlenginemodel` defaultversion `regions` : an array of `googlemlengine_model` regions `onlinepredictionloggings` : an array of `googlemlenginemodel` onlineprediction_logging `onlinepredictionconsole_loggings` : an array of `googlemlenginemodel` onlinepredictionconsolelogging `labels` : an array of `googlemlengine_model` labels 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: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-secret-create.1.md

% podman-secret-create 1 podman\-secret\-create - Create a new secret podman secret create [options] name file|- Creates a secret using standard input or from a file for the secret content. Create accepts a path to a file, or `-`, which tells podman to read the secret from stdin A secret is a blob of sensitive data which a container needs at runtime but is not stored in the image or in source control, such as usernames and passwords, TLS certificates and keys, SSH keys or other important generic strings or binary content (up to 500 kb in size). Secrets are not committed to an image with `podman commit`, and does not get committed in the archive created by a `podman export` command. Secrets can also be used to store passwords for `podman login` to authenticate against container registries. Specify the secret driver (default file). Specify driver specific options. Read secret data from environment variable. Print usage statement. Add label to secret. These labels can be viewed in podman secrete inspect or ls. If existing secret with the same name already exists, update the secret. The `--replace` option does not change secrets within existing containers, only newly created containers. The default is false. Secret resides in a read-protected file. Secret resides in a GPG-encrypted file. Secret is managed by custom scripts. An environment variable SECRET_ID is passed to the scripts (except for list), and secrets are communicated via stdin/stdout (where applicable). Driver options list, lookup, store, and delete serve to install the scripts: ``` [secrets] driver = "shell" [secrets.opts] list = lookup = store = delete = ``` Create the specified secret based on local file. ``` echo -n mysecret > ./secret.txt $ podman secret create my_secret ./secret.txt ``` Create the specified secret via stdin. ``` $ printf <secret> | podman secret create my_secret - ``` Create gpg encrypted secret based on local file using the pass driver. ``` $ podman secret create --driver=pass my_secret ./secret.txt.gpg ``` Create a secret from an environment variable called 'MYSECRET'. ``` $ podman secret create --env=true my_secret MYSECRET ``` , , January 2021, Originally compiled by Ashley Cui <acui@redhat.com> February 2024, Added example showing secret creation from an environment variable by Brett Calliss <brett@obligatory.email>
Project: BigchainDB (App Definition and Development / Database)
File: LICENSE.md

All code in this directory is copyright BigchainDB GmbH, except for the configuration files obtained from 3scale (NGINX configuration file and NGINX Lua script). `nginx.conf.template` and `nginx.lua.template` are based on files we got from 3scale (by going to the 3scale admin site - API - Integration - Download the NGINX Config files). The original files (from 3scale) were licensed under an MIT License, the text of which can be found below. The derived files (`nginx.conf.template` and `nginx.lua.template`), along with the other files in this directory, are also licensed under an MIT License, the text of which can be found below. The documentation in this directory is licensed under a Creative Commons Attribution 4.0 International license, the full text of which can be found at . <hr> The MIT License Copyright (c) 2016-2017 BigchainDB GmbH. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. <hr> The MIT License Copyright (c) 2007-2016 3scale Networks S.L. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: testing.md

Monokle Desktop tests are written with . First create a build to run the tests `npm run electron:build` To run specific tests `npm run ui-test -- tests/<filename>.test.ts` To run all the tests `npm run ui-test` To start writing tests first create a build(tests are run against the build which will be published), any changes made to the source code, adding identifiers, changing logic will need a new build for those changes to be in the tests `npm run electron:build` The `startApp()` function should be called and that will start a new Monokle Desktop instance with the `automation` flag set. More examples of tests can be found in the `./tests` folder The `automation` flag is used to change some handlers which cannot be automated by playwright since they are open by the specific OS's Models should contain most of the logic, we can think of models a mirror for some components in the app with some logic and identifiers for certain elements. Having most of the logic in the models can help with reusing most of the logic we have around tests and more lightweight tests. To change handlers such as `dialog.showOpenDialogSync` the function `getChannelName('channel-name')` should be called when creating a new handler on `ipcRenderer`, this will create different handler just for automation. To add a new handler in automation something like this is required: ``` const name = 'some-value'; const chanel = getChannelName('channel-name', true); await electronApp.evaluate(({ ipcMain }, params) => { ipcMain.handle(params.chanel, () => { return [params.name]; }); }, { chanel, name }); ``` Examples: