cwielenb/CNCF-Dataset huggingface dataset:
Project: ShardingSphere (App Definition and Development / Database)
File: alter-sharding-table-reference-rule.en.md

+++ title = "ALTER SHARDING TABLE REFERENCE RULE" weight = 13 +++ The `ALTER SHARDING TABLE REFERENCE RULE` syntax is used to alter sharding table reference rule. {{< tabs >}} {{% tab name="Grammar" %}} ```sql AlterShardingTableReferenceRule ::= 'ALTER' 'SHARDING' 'TABLE' 'REFERENCE' 'RULE' referenceRelationshipDefinition (',' referenceRelationshipDefinition)* referenceRelationshipDefinition ::= ruleName '(' tableName (',' tableName)* ')' ruleName ::= identifier tableName ::= identifier ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} A sharding table can only be associated with one sharding table reference rule; The referenced sharding tables should be sharded in the same storage units and have the same number of sharding nodes. For example `ds${0..1}.torder${0..1}` and `ds${0..1}.torderitem_${0..1}`; The referenced sharding tables should use consistent sharding algorithms. For example `torder{orderid % 2}` and `torderitem{orderitemid % 2}`; ```sql ALTER SHARDING TABLE REFERENCE RULE ref0 (torder,torderitem); ``` ```sql ALTER SHARDING TABLE REFERENCE RULE ref0 (torder,torderitem), ref1 (tproduct,tproductitem); ``` `ALTER`, `SHARDING`, `TABLE`, `REFERENCE`, `RULE`
Project: Sonobuoy (Provisioning / Security & Compliance)
File: sonobuoy_plugin_uninstall.md

Uninstall a plugin. You can continue to run any plugin via specifying a file or URL. ``` sonobuoy plugin uninstall <plugin filename> [flags] ``` ``` -h, --help help for uninstall ``` ``` --level level Log level. One of {panic, fatal, error, warn, info, debug, trace} (default info) ``` - Manage your installed plugins
Project: KICS (Provisioning / Security & Compliance)
File: 4bb06fa1-2114-4a00-b7b5-6aeab8b896f0.md

title: ROS Stack Retention Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 4bb06fa1-2114-4a00-b7b5-6aeab8b896f0 Query name: ROS Stack Retention Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Backup URL: The retain_stacks should be enabled to keep the Stack upon deleting the stack instance from the stack group<br> ```tf title="Positive test num. 1 - tf file" hl_lines="6" resource "alicloudrosstack_instance" "example" { stackgroupname = alicloudrosstackgroup.example.stackgroup_name stackinstanceaccountid = "examplevalue" stackinstanceregionid = data.alicloudrosregions.example.regions.0.regionid operation_preferences = "{\"FailureToleranceCount\": 1, \"MaxConcurrentCount\": 2}" retain_stacks = false parameter_overrides { parameter_value = "VpcName" parameter_key = "VpcName" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="1" resource "alicloudrosstack_instance" "example" { stackgroupname = alicloudrosstackgroup.example.stackgroup_name stackinstanceaccountid = "examplevalue" stackinstanceregionid = data.alicloudrosregions.example.regions.0.regionid operation_preferences = "{\"FailureToleranceCount\": 1, \"MaxConcurrentCount\": 2}" parameter_overrides { parameter_value = "VpcName" parameter_key = "VpcName" } } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudrosstack_instance" "example" { stackgroupname = alicloudrosstackgroup.example.stackgroup_name stackinstanceaccountid = "examplevalue" stackinstanceregionid = data.alicloudrosregions.example.regions.0.regionid operation_preferences = "{\"FailureToleranceCount\": 1, \"MaxConcurrentCount\": 2}" retain_stacks = true parameter_overrides { parameter_value = "VpcName" parameter_key = "VpcName" } } ```
Project: YDB (App Definition and Development / Database)
File: balancing-random-choice.md

{% include %} The {{ ydb-short-name }} SDK uses the `random_choice` algorithm by default. Below are examples of the code for forced setting of the "random choice" balancing algorithm in different {{ ydb-short-name }} SDKs. {% list tabs %} Go (native) ```go package main import ( "context" "os" "github.com/ydb-platform/ydb-go-sdk/v3" "github.com/ydb-platform/ydb-go-sdk/v3/balancers" ) func main() { ctx, cancel := context.WithCancel(context.Background()) defer cancel() db, err := ydb.Open(ctx, os.Getenv("YDBCONNECTIONSTRING"), ydb.WithBalancer( balancers.RandomChoice(), ), ) if err != nil { panic(err) } defer db.Close(ctx) ... } ``` Go (database/sql) Client load balancing in the {{ ydb-short-name }} `database/sql` driver is performed only when establishing a new connection (in `database/sql` terms), which is a {{ ydb-short-name }} session on a specific node. Once the session is created, all queries in this session are passed to the node where the session was created. Queries in the same {{ ydb-short-name }} session are not balanced between different {{ ydb-short-name }} nodes. Example of the code for setting the "random choice" balancing algorithm: ```go package main import ( "context" "database/sql" "os" "github.com/ydb-platform/ydb-go-sdk/v3" "github.com/ydb-platform/ydb-go-sdk/v3/balancers" ) func main() { ctx, cancel := context.WithCancel(context.Background()) defer cancel() nativeDriver, err := ydb.Open(ctx, os.Getenv("YDBCONNECTIONSTRING"), ydb.WithBalancer( balancers.RandomChoice(), ), ) if err != nil { panic(err) } defer nativeDriver.Close(ctx) connector, err := ydb.Connector(nativeDriver) if err != nil { panic(err) } db := sql.OpenDB(connector) defer db.Close() ... } ``` {% endlist %}
Project: Meshery (Provisioning / Automation & Configuration)
File: mattermost-operator.md

layout: integration title: Mattermost Operator subtitle: Collaborative and visual infrastructure as code for Mattermost Operator image: /assets/img/integrations/mattermost-operator/icons/color/mattermost-operator-color.svg permalink: extensibility/integrations/mattermost-operator docURL: https://docs.meshery.io/extensibility/integrations/mattermost-operator description: integrations-category: Tools integrations-subcategory: Uncategorized registrant: Artifact Hub components: name: cluster-installation colorIcon: assets/img/integrations/mattermost-operator/components/cluster-installation/icons/color/cluster-installation-color.svg whiteIcon: assets/img/integrations/mattermost-operator/components/cluster-installation/icons/white/cluster-installation-white.svg description: name: mattermost-restore-db colorIcon: assets/img/integrations/mattermost-operator/components/mattermost-restore-db/icons/color/mattermost-restore-db-color.svg whiteIcon: assets/img/integrations/mattermost-operator/components/mattermost-restore-db/icons/white/mattermost-restore-db-white.svg description: name: mattermost colorIcon: assets/img/integrations/mattermost-operator/components/mattermost/icons/color/mattermost-color.svg whiteIcon: assets/img/integrations/mattermost-operator/components/mattermost/icons/white/mattermost-white.svg description: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Connect Mattermost with any of your favorite cloud native apps in just a few clicks. Design, build, and automate anything for your work by integrating apps like Mattermost to create visual automated workflows. Choose from thousands of ready-made apps or use our no-code toolkit to connect to apps not yet in our library." howItWorksDetails: "Configuring your own Mattermost environment See the Mattermost documentation - https://docs.mattermost.com." language: en list: include type: extensibility category: integrations
Project: Presto (App Definition and Development / Database)
File: usage-question.md

name: Usage Question about: Report an issue faced while using Presto labels: usage <!--Tips before filing an issue --> <!-- Join the Presto Slack Channel to engage in conversations and get faster support at https://https://prestodb.io/slack. --> <!-- If you have triaged this as a bug, then file an directly. --> A clear and concise description of the problem. Was this working before or is this a first try? If this worked before, then what has changed that recently? Provide table DDLs and `` EXPLAIN ANALYZE `` for your Presto queries. Presto version used: Storage (HDFS/S3/GCS..): Data source and connectors or catalogs used: Deployment (Cloud or On-prem): link to the complete debug logs: Steps to reproduce the behavior: <! A clear and concise description of what you expected to happen.--> <! Add any other context about the problem here. What is your use case? What are you trying to accomplish? Providing context helps us come up with a solution that is most useful in the real world.--> <!Add the complete stacktrace of the error.-->
Project: YugabyteDB (App Definition and Development / Database)
File: aggregations-ysql.md

title: Aggregations in YugabyteDB YSQL headerTitle: Aggregations linkTitle: 5. Aggregations description: Learn how YugabyteDB YSQL supports standard aggregation functions. menu: v2.18: identifier: aggregations-2-ysql parent: learn weight: 567 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../aggregations-ysql/" class="nav-link active"> <i class="icon-postgres" aria-hidden="true"></i> YSQL </a> </li> <li > <a href="../aggregations-ycql/" class="nav-link"> <i class="icon-cassandra" aria-hidden="true"></i> YCQL </a> </li> </ul> YSQL content coming soon.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_spanner_instance_iam_binding.md

+++ title = "googlespannerinstanceiambinding resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlespannerinstanceiambinding" identifier = "inspec/resources/gcp/googlespannerinstanceiambinding.md googlespannerinstanceiambinding resource" parent = "inspec/resources/gcp" +++ A `googlespannerinstanceiambinding` is used to test a Google Instance Iam Bindings ```ruby describe googlespannerinstanceiambinding(project: "project", name: "name", role: "roles/editor") do it { should exist } its('members') { should include 'user:testuser@example.com' } end ``` Properties that can be accessed from the `googlespannerinstanceiambinding` resource: `role` : Role that is assigned to members. For example, roles/viewer, roles/editor, or roles/owner. `members` : Specifies the identities requesting access for a Cloud Platform resource. Ensure the is enabled for the current project.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: postgres_conf.md

+++ title = "postgres_conf resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "postgres_conf" identifier = "inspec/resources/os/postgresconf.md postgresconf resource" parent = "inspec/resources/os" +++ Use the `postgres_conf` Chef InSpec audit resource to test the contents of the configuration file for PostgreSQL, typically located at `/etc/postgresql/<version>/main/postgresql.conf` or `/var/lib/postgres/data/postgresql.conf`, depending on the platform. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `postgres_conf` resource block declares one (or more) settings in the `postgresql.conf` file, and then compares the setting in the configuration file to the value stated in the test: describe postgres_conf('path') do its('setting') { should eq 'value' } end where `'setting'` specifies a setting in the `postgresql.conf` file `('path')` is the non-default path to the `postgresql.conf` file (optional) `should eq 'value'` is the value that is expected This resource supports any of the settings listed in an postgresql.conf file as properties for e.g. max_connections its('max_connections') { should eq '5' } The following examples show how to use this Chef InSpec audit resource. describe postgres_conf do its('max_connections') { should eq '5' } end describe postgres_conf do its('logging_collector') { should eq 'on' } its('log_connections') { should eq 'on' } its('log_disconnections') { should eq 'on' } its('log_duration') { should eq 'on' } its('log_hostname') { should eq 'on' } its('loglineprefix') { should eq '%t %u %d %h' } its(['pgaudit.log_parameter']) { should cmp 'on' } end describe postgres_conf do its('port') { should eq '5432' } end describe postgres_conf do its('unixsocketdirectories') { should eq '.s.PGSQL.5432' } its('unixsocketgroup') { should eq nil } its('unixsocketpermissions') { should eq '0770' } end where `unixsocketgroup` is set to the PostgreSQL default setting (the group to which the server user belongs). {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: OAuth2 Proxy (Provisioning / Key Management)
File: index.md

id: index title: OAuth Provider Configuration You will need to register an OAuth application with a Provider (Google, GitHub or another provider), and configure it with Redirect URI(s) for the domain you intend to run `oauth2-proxy` on. Valid providers are : default / The provider can be selected using the `provider` configuration value. Please note that not all providers support all claims. The `preferred_username` claim is currently only supported by the OpenID Connect provider. To authorize a specific email-domain use `--email-domain=yourcompany.com`. To authorize individual email addresses use `--authenticated-emails-file=/path/to/file` with one email per line. To authorize all email addresses use `--email-domain=*`. Follow the examples in the to define a new `Provider` instance. Add a new `case` to to allow `oauth2-proxy` to use the new `Provider`.
Project: LinuxKit (Provisioning / Automation & Configuration)
File: 2017-07-05.md

Time: 9am PDT (12pm EDT, 5pm BST) Meeting location: https://docker.zoom.us/j/779801882 Announcement: Video recording: https://youtu.be/qkp0JqtlST0 Previous meeting notes: Introductions & Administrivia (5 min) Automatic privilege separation and `Memorizer` deep dive - @ndauten (30 min) What is automatic privilege separation? Introduction to `Memorizer` Discussion about tracking namespaces, other feedback demo Project updates (10 min) Next meeting: 2017-07-19 deep dive TBD we can propose additional deep dives and discussion topics! Scribe: @mgoelzer Next meeting: July 19th Automatic Privilege Separation - OPS = opportunistic privilege separation (meta project) Our infra operates on a large, untrusted code base. Easily exploitable. Titanic Lots of layers of vulnerable code. Lots of code. E.g., Every version of Linux kernel is >1000 developers contributing Monolithic Strategies to address these problems: Replace (microkernel), or Harden + Separate Harden = making external shell more resistant to attack Separate = each internal component having minimal privileges so even a compromised component can do only limited damage (eg SELinux, Landlock) What about flipping the script? - by default everything is protected and then whitelist In contrast to current model where by default you have access to everything and then you bolt on protections after the fact Limitations of existing approaches No ephemeral state manual policy dont address kernel principles lack of visibility into app (others mentioned) Tools / Projects: OPS (Opportunistic Priv. Sep.): end to end approach for fine grained security policy retrofitting Core hypoth: we can automatically derive policies from system behavior. Use ML to set up initial separation policy. Similar to an optimizing compiler. LINX: linux nested kernel kr^x: kernel randomization Memorizer: dynamic tracer Creates maps (like CAPs) CAPMAPs Takes kernel source -> pass it through instrumentation (piggybacking on kernel address sanitizer to hook all allocations with KASAN) -> now all allocs are hooked Stack is hooked through KASAN SLICE
Project: secureCodeBox (Provisioning / Security & Compliance)
File: CONTRIBUTORS.md

<!-- SPDX-FileCopyrightText: the secureCodeBox authors SPDX-License-Identifier: Apache-2.0 --> If you would like to make contributions to this repository, please certify to the following Developer's Certificate of Origin (DCO) in . Please confirm your certification to the DCO by adding a sign-of tag to all your commit messages and adding your author name (e.g. `gordon shumway <alf@melmak.com>`) to the following list of contributors and open a pull request. If you are a developer who is authorized to contribute on behalf of your employer, then please use your corporate email address in the signed-off-by tag. Unless please use your personal email address. Each commit must contain the signed-off-by tag with your real name and email address at the bottom: ```text Signed-off-by: gordon shumway <alf@melmak.com> ``` Committing with `git commit -s` will add the sign-off at the end of the commit message automatically for you. Robert Seedorff <robert.seedorff@iteratec.com> Sven Strittmatter <sven.strittmatter@iteratec.com> Tim Walter <tim.walter@iteratec.com> Yannik Fuhrmeister <yannik.fuhrmeister@iteratec.com> Sebastian Franz <sebastian.franz@iteratec.com> Jannik Hollenbach <jannik.hollenbach@iteratec.com> Johannes Zahn <johannes.zahn@iteratec.com> Jop Zitman <jop.zitman@secura.com> Florian Buchmeier <florian.buchmeier@audi.de> Max Maass <max.maass@iteratec.com> Chuck McAuley <nobletrout@gmail.com> Ilyes Ben Dlala <ilyes.bendlala@iteratec.com> Simon Hlkenberg <simon.huelkenberg@iteratec.com> Johanna Walker <johanna.walker@iteratec.com> Felix Belz <felix.belz@iteratec.com> Mateusz Majcher <m.majcher91@gmail.com> Guillermo Rodriguez <guimo.spritekin@gmail.com> Lyuben Dimitrov <ldimitrov070@gmail.com> Felix Hrsting <felix.hoersting@iteratec.com> Matthew Cascio <cascio@cybercapsicum.com> Patryk Miek <patrykmilek96@gmail.com> Renato Burton <renatoburton96@gmail.com> Samreet Singh <samreet.singh@iteratec.com> Silvia Milde <silvia.milde@iteratec.com> Sofia Lohr <sofia.lohr@iteratec.com> Vanessa Hermann <vanessa.hermann@iteratec.com> Lukas Fischer <lukas.fischer@iteratec.com> Heiko Kiesel <heiko.kiesel@iteratec.com> Frank Belter <frank.belter@iteratec.com> Maximilian Dorner <maximilian.dorner@clever-soft.com> Boris Shek <boris.shek@iteratec.com> Kamiren Dawkins <kamiren@dawkins.dev> Tobias Stenby Brixen <kind.job1347@fastmail.com>
Project: Checkov (Provisioning / Security & Compliance)
File: What is Checkov.md

layout: default published: true title: What is Checkov? nav_order: 1 Checkov is a static code analysis tool for scanning infrastructure as code (IaC) files for misconfigurations that may lead to security or compliance problems. Checkov includes more than 750 predefined policies to check for common misconfiguration issues. Checkov also supports the creation and contribution of . Checkov scans these IaC file types: Terraform (for AWS, GCP, Azure and OCI) CloudFormation (including AWS SAM) Azure Resource Manager (ARM) Serverless framework Helm charts Kubernetes Docker Custom policies can be created to check cloud resources based on configuration attributes (in or or connection states (in ). For composite policies, Checkov creates a cloud resource connection graph for deep misconfiguration analysis across resource relationships. In addition, Checkov scans for compliance with common industry standards such as the Center for Internet Security (CIS) and Amazon Web Services (AWS) Foundations Benchmark. Checkov integrates with advanced features in . Prisma Cloud extends Checkov's capabilities to provide runtime scanning and visibility, native VCS integrations, drift detection, and more. Prisma Cloud can validate Checkov IaC policies against your runtime cloud environments in AWS, Azure, Google Cloud, AliCloud, and Oracle Cloud Infrastructure, allowing you to find and fix issues in existing deployments and detect cloud drifts. Read more in . Prisma Cloud will detect drift and provide automatic pull requests to fix drifted resources in HCL. Enable automated pull/merge request annotations on your repositories without having to build a CI pipeline or run scheduled checks. Prisma Cloud will automatically scan new pull requests and annotate them with comments for any policy violations discovered. Read more in .
Project: external-secrets (Provisioning / Security & Compliance)
File: pushsecrets.md

Contrary to what `ExternalSecret` does by pulling secrets from secret providers and creating `kind=Secret` in your cluster, `PushSecret` reads a local `kind=Secret` and pushes its content to a secret provider. The update behavior of `PushSecret` is controlled by `spec.updatePolicy`. The default policy is `Replace`, such that secrets are overwritten in the provider, regardless of whether there already is a secret present in the provider at the given location. If you do not want `PushSecret` to overwrite existing secrets in the provider, you can set `spec.UpdatePolicy` to `IfNotExists`. With this policy, the provider becomes the source of truth. Please note that with using `spec.updatePolicy=IfNotExists` it is possible that the secret value referenced by the `PushSecret` within the cluster differs from the secret value at the given location in the provider. By default, the secret created in the secret provided will not be deleted even after deleting the `PushSecret`, unless you set `spec.deletionPolicy` to `Delete`. ``` yaml {% include 'full-pushsecret.yaml' %} ``` An interesting use case for `kind=PushSecret` is backing up your current secret from one provider to another one. Imagine you have your secrets in GCP and you want to back them up in Azure Key Vault. You would then create a `SecretStore` for each provider, and an `ExternalSecret` to pull the secrets from GCP. This will generate a `kind=Secret` in your cluster that you can use as the source of a `PushSecret` configured with the Azure `SecretStore`. There are two ways to push an entire secret without defining all keys individually. By leaving off the secret key and remote property options. ```yaml {% include 'full-pushsecret-no-key-no-property.yaml' %} ``` This will result in all keys being pushed as they are into the remote location. By leaving off the secret key but setting the remote property option. ```yaml {% include 'full-pushsecret-no-key-with-property.yaml' %} ``` This will marshal the entire secret data and push it into this single property as a JSON object. !!! warning inline This should ONLY be done if the secret data is marshal-able. Values like, binary data cannot be marshaled and will result in error or invalid secret data. You can also set `data.
Project: YugabyteDB (App Definition and Development / Database)
File: yba_storage-config_azure_create.md

Create an Azure YugabyteDB Anywhere storage configuration Create an Azure storage configuration in YugabyteDB Anywhere ``` yba storage-config azure create [flags] ``` ``` --backup-location string [Required] The complete backup location including "https://<account-name>.blob.core.windows.net/<container-name>/<blob-name>". --sas-token string AZ SAS Token. Provide the token within double quotes. Can also be set using environment variable AZURESTORAGESAS_TOKEN. -h, --help help for create ``` ``` -a, --apiToken string YugabyteDB Anywhere api token. --config string Config file, defaults to $HOME/.yba-cli.yaml --debug Use debug mode, same as --logLevel debug. --disable-color Disable colors in output. (default false) -H, --host string YugabyteDB Anywhere Host (default "http://localhost:9000") -l, --logLevel string Select the desired log level format. Allowed values: debug, info, warn, error, fatal. (default "info") -n, --name string [Optional] The name of the storage configuration for the operation. Required for create, delete, describe, update. -o, --output string Select the desired output format. Allowed values: table, json, pretty. (default "table") --timeout duration Wait command timeout, example: 5m, 1h. (default 168h0m0s) --wait Wait until the task is completed, otherwise it will exit immediately. (default true) ``` - Manage a YugabyteDB Anywhere Azure storage configuration