cwielenb/CNCF-Dataset huggingface dataset:
Project: YugabyteDB (App Definition and Development / Database)
File: yba_universe_list.md

List YugabyteDB Anywhere universes List YugabyteDB Anywhere universes ``` yba universe list [flags] ``` ``` -n, --name string [Optional] Name of the universe. -h, --help help for list ``` ``` -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") -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 YugabyteDB Anywhere universes
Project: FOSSA (Provisioning / Security & Compliance)
File: strategy-command-selection.md

In some strategies, FOSSA CLI uses actual package managers or build tools in order to analyze the dependencies of a project. FOSSA refers to such strategies as "dynamic analysis strategies". Some dynamic analysis strategies have multiple command options to use, preferred in a fallback manner. FOSSA refers to these as "candidate commands". FOSSA CLI chooses which command in a list of candidate commands to use by running each command with a set of flags suitable for determining whether the candidate will work for FOSSA CLI. The particular flags used are up to each strategy; sometimes they simply test whether the command is able to run, and sometimes they may test that the command is of a particular minimum version or supports some capability. FOSSA refers to these flags as evaluation flags. If the command, run with the evaluation flags, exits with a non-zero exit code FOSSA CLI determines that the candidate command is unsuitable and moves on to the next candidate. If no suitable command is found, the overall strategy fails. If a candidate command was chosen, but then later fails, FOSSA CLI treats this as an overall strategy failure since that command was determined to be the correct one to use for the project. For example the "Maven" strategy prefers, in order: The command provided by the user via `FOSSAMAVENCMD`, if present. The local `mvnw` command, if one is found in the project or an ancestor directory. The `mvn` command in `$PATH`. Suppose FOSSA CLI is analyzing the following project: ``` . mvnw pom.xml readme.md src main java org apache maven wrapper BootstrapMainStarter.java ``` And that FOSSA CLI is being run with the following command: ``` FOSSAMAVENCMD=/usr/local/bin/custom-mvn fossa analyze ``` This results in the following list of candidate commands, where the earlier in the list the command appears, the higher priority that command has: ``` [ "/usr/local/bin/custom-mvn" , "./mvnw" , "mvn" ] ``` FOSSA CLI evaluates these candidates with the following commands in sequence, stopping after the first one evaluates with exit code zero (signifying no error): ``` ; /usr/local/bin/custom-mvn -v # exit code 1 ; ./mvnw -v # exit code 0 ``` Since `./mvnw` appears suitable, FOSSA CLI chooses that as the command to use and performs analysis on this Maven project using the `./mvnw` command.
Project: StarRocks (App Definition and Development / Database)
File: ALTER_RESOURCE.md

displayed_sidebar: "English" You can use the ALTER RESOURCE statement to modify the properties of a resource. ```SQL ALTER RESOURCE 'resource_name' SET PROPERTIES ("key"="value", ...) ``` `resource_name`: the name of the resource to be modified. `PROPERTIES ("key"="value", ...)`: the properties of the resource. You can modify different properties based on resource types. Currently, StarRocks supports modifying the URI of the Hive metastore of the following resources. Apache Iceberg resources support modifying the following properties: `iceberg.catalog-impl`: the fully qualified class name of . `iceberg.catalog.hive.metastore.uris`: the URI of the Hive metastore. Apache Hive resources and Apache Hudi resources support modifying `hive.metastore.uris`, which indicates the URI of the Hive metastore. After you reference a resource to create an external table, if you modify the URI of the Hive metastore of this resource, the external table becomes unavailable. If you still want to use the external table to query data, make sure that the new metastore contains a table whose name and schema are the same as that in the original metastore. Modify the URI of the Hive metastore of Hive resource `hive0`. ```SQL ALTER RESOURCE 'hive0' SET PROPERTIES ("hive.metastore.uris" = "thrift://xx.xx.xx.xx:9083") ```
Project: Paralus (Provisioning / Security & Compliance)
File: CHANGELOG.md

Ability to regularly check in on the target cluster connection status () () add custom Empty instead of google.protobuf.Empty () () migration error on Postgresql version below 14 () () mapper for keycloak () added yaml marshal/unmarshal for enums () () changes to view auditlogs by project role users () () Prior to v0.2.4, users will not have org, partner metadata information in kratos identities which will impact audit logs screens, apply below migrations if you are upgrading paralus update identities set metadatapublic = jsonbset(metadata_public, '{organization}', '"replace-with-your-organization-id"', true); update identities set metadatapublic = jsonbset(metadata_public, '{partner}', '"replace-with-your-partner-id"', true); change relays annotation of Cluster to paralus.dev/relays () () cluster list API send internal error for non-exist project () generate fixtures for download.yaml () () fix for org admins to view secrets with org restrictions () () incorrect number of wg.add () () re-running admindb migration fails () () remove references to admindbuser user in admindb migrations () () Okta JSONNet mapper configuration for SSO login got changed to support multiple groups. This may impact the existing Okta user logins configured with paralus versions prior to v0.2.1. As a workaround use to your existing Okta OIdC configuration. Support more than one IdP groups mapping from Add project name validation Fix to error out multiple bootstrap agent registration requests from Updated Documentation for APIs and Configure the service account lifetime from User should not be able to delete project with clusters in it from Namespace limitation input on roles Fix project id is recorded as part of cluster related auditlogs from Enhance: Ability to set auto generated password during installation and force reset during first login Upgraded Ory Kratos to v0.10.1 Enhance: record user.login event via kratos hooks Fix modify userinfo service to include scope in response Kubectl commands work even after deleting an imported cluster from and Added database auditlog storage option Added last login field to user spec from Fixed creating project scoped role failed from cli Fixed issue where relay server is not coming up in arm64 (Mac M1) from Fixed issue where relay server is not coming up in arm64 (Mac M1) from Fixed cluster lister and set group created at property Added more audit points for better visibility from Added audit point for kubeconfig download Fixed lint issues due to buf from Fixed init failing with db validation error from Fix to validate bare minimum role permissions for custom roles from Initial release
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.10.17.md

RabbitMQ `3.10.17` is a maintenance release in the `3.10.x` . This series . Please refer to the upgrade section from if upgrading from a version prior to 3.10.0. This release requires Erlang 24.3 and supports Erlang 25. has more details on Erlang version requirements for RabbitMQ. Erlang 23 and 24 versions older than 24.3 have reached . This release of RabbitMQ requires Erlang 24.3 or later versions. Nodes will fail to start on older Erlang releases. Erlang 25 is recommended: it offers much improved performance on ARM64 architectures, across all architectures, and the most recent TLS 1.3 implementation. Release notes can be found on GitHub at . The Admin tab in the management UI failed to render in the `3.10.16` release. GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.10.17.tar.xz` instead of the source tarball produced by GitHub.
Project: KICS (Provisioning / Security & Compliance)
File: 72a931c2-12f5-40d1-93cc-47bff2f7aa2a.md

title: API Gateway With CloudWatch Logging Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 72a931c2-12f5-40d1-93cc-47bff2f7aa2a Query name: API Gateway With CloudWatch Logging Disabled Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: AWS CloudWatch Logs for APIs is not enabled<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="3" name: Setup AWS API Gateway setup on AWS cloudwatchlogs community.aws.cloudwatchlogsloggroup: state: present kmskeyid: arn:aws:kms:region:account-id:key/key-id ``` ```yaml title="Negative test num. 1 - yaml file" name: Setup AWS API Gateway setup on AWS cloudwatchlogs community.aws.cloudwatchlogsloggroup: state: present loggroupname: test-log-group tags: {Name: test-log-group, Env: QA} kmskeyid: arn:aws:kms:region:account-id:key/key-id ```
Project: Vald (App Definition and Development / Database)
File: discoverer.md

Vald Discoverer runs individually and helps automate operations for the Vald cluster. It is also the only component that communicates with . Vald Discoverer is responsible for retrieving each Node and Pod resource usage from and sharing it with other components in the Vald cluster. Vald Discoverer requires to get Node and Pod metrics in the Vald cluster. It synchronizes the metrics when it changes by the `Reconcile function`, one of the internal functions. The kind of metrics are here: Node | Key name | Description | | | - | | Name | node name | | InternalAddr | node internal address | | ExternalAddr | node external address | | CPU | CPU limit and CPU request | | Memory | Memory limit and Memory request | | Pods | Pod information in the node | Pod | Key name | Description | | | - | | AppName | AppName of pod | | Name | pod name | | Namespace | namespace where pod runs | | IP | IP address | | CPU | CPU limit and CPU request | | Memory | Memory limit and Memory request | When syncing success, Vald Discoverer chooses the necessary metrics from the result and stores them into their four kinds of `Map` on their local memory: | Map name | Description | | | | | podsByNode | pod metrics list group by node | | podsByNamespace | pod metrics list group by namespace | | podsByName | pod metrics list group by pod name | | nodebyName | node metrics list group by node name | <!-- TODO:image --> Vald Discoverer provides the internal client for another component. The component, which requires the metrics information, uses when it needs. Vald LB Gateway and Vald Manager Index in the Vald cluster require it to achieve its responsibility. For example, Vald LB Gateway creates the new `discoverer client` with config parameters and binds it to the new `gateway lb client` when Vald LB Gateway starts the container. When the `initContainer` successes, Vald LB Gateway can get the metrics asynchronously according to its set parameters. <!-- TODO:image --> Please refer for more information about the cluster role configuration.
Project: YugabyteDB (App Definition and Development / Database)
File: add-users.md

title: Add database users linkTitle: Add database users description: Add users to YugabyteDB Managed clusters headcontent: Grant team members and applications access to your database menu: preview_yugabyte-cloud: identifier: add-users parent: cloud-secure-clusters weight: 350 type: docs When you create a cluster in YugabyteDB Managed, you set up the database admin credentials, which you use to access the YugabyteDB database installed on your cluster. Use this account to: add more database users assign privileges to users change your password, or the passwords of other users YugabyteDB uses (RBAC) to . A database user's access is determined by the roles they are assigned. You should grant database users only the privileges that they require. To manage database users, first connect to your cluster using or a . To create and manage database roles and users (users are roles with login privileges), use the following statements: | I want to | YSQL Statement | YCQL Statement | | : | : | : | | Create a user or role. | | | | Delete a user or role. | | | | Assign privileges to a user or role. | | | | Remove privileges from a user or role. | | | | Change your own or another user's password. | | | Add database users as follows: Add the user using the CREATE ROLE statement. Grant the user any roles they require using the GRANT statement. Authorize their network so that they can access the cluster. Refer to . Send them the credentials. {{< note title="Database users and case sensitivity" >}} Like SQL and CQL, both YSQL and YCQL are case-insensitive by default. When specifying an identifier, such as the name of a table or role, YSQL and YCQL automatically convert the identifier to lowercase. For example, `CREATE ROLE Alice` creates the role "alice". To use a case-sensitive name, enclose the name in quotes. For example, to create the role "Alice", use `CREATE ROLE "Alice"`. {{< /note >}} To add a database user in YSQL, use the CREATE ROLE statement as follows: ```sql yugabyte=# CREATE ROLE <username> WITH LOGIN PASSWORD '<password>'; ``` To grant a role to a user, use the GRANT statement as follows: ```sql yugabyte=# GRANT <rolename> TO <username>; ``` {{< note title="Note" >}} You can't create YSQL superusers in YugabyteDB Managed. To create another database administrator, grant the `yb_superuser` role. Refer to . {{< /note >}} To add a database user in YCQL, use the CREATE ROLE statement as follows: ```sql admin@ycqlsh> CREATE ROLE <username> WITH PASSWORD = '<password>' AND LOGIN = true; ``` To grant a role to a user, use the GRANT ROLE statement as follows: ```sql admin@ycqlsh> GRANT ROLE <rolename> to <username>; ``` To change your own or another user's password, use the ALTER ROLE statement. In YSQL, enter the following: ```sql yugabyte=# ALTER ROLE <username> PASSWORD 'new-password'; ``` In YCQL, enter the following: ```sql cassandra@ycqlsh> ALTER ROLE <username> WITH PASSWORD = 'new-password'; ```
Project: Paladin Cloud (Provisioning / Security & Compliance)
File: ---feature-request.md

name: "\U0001F64B Feature request" about: Suggest an idea for this project title: "[Issue]" labels: enhancement assignees: '' <! Thanks for filing an issue ! Before you submit, please read the following: Search open/closed issues before submitting since someone might have asked the same thing before! --> <! Provide a general summary of the issue here --> <! Tell us how the feature should work --> <! Explain the difference from current behavior --> <! Ideas how to implement this feature or a similar solution/workaround that already exists --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <!-- Examples help us understand the requested feature better -->
Project: StarRocks (App Definition and Development / Database)
File: SET_ROLE.md

displayed_sidebar: "English" Activates roles, along with all of its associated privileges and nested roles, for the current session. After the role is activated, users can use this role to perform operations. After running this command, you can run `select isroleinsession("<rolename>");` to verify whether this role is active in the current session. This command is supported from v3.0. Users can only activate roles that have been assigned to them. You can query the roles of a user using . You can query the active roles of the current user using `SELECT CURRENT_ROLE()`. For more information, see . ```SQL -- Active specific roles and perform operations as this role. SET ROLE <rolename>[,<rolename>,..]; -- Activate all roles of a user, except for specific roles. SET ROLE ALL EXCEPT <rolename>[,<rolename>,..]; -- Activate all roles of a user. SET ROLE ALL; ``` `role_name`: the role name Query all the roles of the current user. ```SQL SHOW GRANTS; +--++-+ | UserIdentity | Catalog | Grants | +--++-+ | 'test'@'%' | NULL | GRANT 'dbadmin', 'useradmin' TO 'test'@'%' | +--++-+ ``` Activate the `db_admin` role. ```SQL SET ROLE db_admin; ``` Query active roles of the current user. ```SQL SELECT CURRENT_ROLE(); +--+ | CURRENT_ROLE() | +--+ | db_admin | +--+ ``` : creates a role. : assigns roles to users or other roles. : modifies roles. : show all roles in the system. : show roles of the current user. : verifies whether a role (or a nested role) is active in the current session. : drops a role.
Project: KICS (Provisioning / Security & Compliance)
File: eb8c2560-8bee-4248-9d0d-e80c8641dd91.md

title: Web App Accepting Traffic Other Than HTTPS hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: eb8c2560-8bee-4248-9d0d-e80c8641dd91 Query name: Web App Accepting Traffic Other Than HTTPS Platform: Ansible Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: Web app should only accept HTTPS traffic in Azure Web App Service.<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="12 5" name: Create a windows web app with non-exist app service plan azurermwebapp: resource_group: myResourceGroup name: myWinWebapp https_only: false plan: resourcegroup: myAppServicePlanrg name: myAppServicePlan is_linux: false sku: S1 name: Create another windows web app azurermwebapp: resource_group: myResourceGroup name: myWinWebapp plan: resourcegroup: myAppServicePlanrg name: myAppServicePlan is_linux: false sku: S1 ``` ```yaml title="Negative test num. 1 - yaml file" name: Create a windows web app with non-exist app service plan azurermwebapp: resource_group: myResourceGroup name: myWinWebapp https_only: true plan: resourcegroup: myAppServicePlanrg name: myAppServicePlan is_linux: false sku: S1 ```
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: speed-limit.md

The SeaTunnel provides a powerful speed control feature that allows you to manage the rate at which data is synchronized. This functionality is essential when you need to ensure efficient and controlled data transfer between systems. The speed control is primarily governed by two key parameters: `readlimit.rowspersecond` and `readlimit.bytespersecond`. This document will guide you through the usage of these parameters and how to leverage them effectively. SeaTunnel Zeta<br/> Flink<br/> Spark<br/> To use the speed control feature, you need to configure the `readlimit.rowspersecond` or `readlimit.bytespersecond` parameters in your job config. Example env config in your config file: ```hocon env { job.mode=STREAMING job.name=SeaTunnel_Job readlimit.bytesper_second=7000000 readlimit.rowsper_second=400 } source { MySQL-CDC { // ignore... } } transform { } sink { Console { } } ``` We have placed `readlimit.bytespersecond` and `readlimit.rowspersecond` in the `env` parameters, completing the speed control configuration. You can configure both of these parameters simultaneously or choose to configure only one of them. The value of each `value` represents the maximum rate at which each thread is restricted. Therefore, when configuring the respective values, please take into account the parallelism of your tasks.
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-registry-generate.md

layout: default title: mesheryctl-registry-generate permalink: reference/mesheryctl/registry/generate redirect_from: reference/mesheryctl/registry/generate/ type: reference display-title: "false" language: en command: registry subcommand: generate Generate Models Prerequisite: Excecute this command from the root of a meshery/meshery repo fork. Given a Google Sheet with a list of model names and source locations, generate models and components any Registrant (e.g. GitHub, Artifact Hub) repositories. Generated Model files are written to local filesystem under `/server/models/<model-name>`. <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl registry generate [flags] </div> </pre> Generate Meshery Models from a Google Spreadsheet (i.e. "Meshery Integrations" spreadsheet). <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl registry generate --spreadsheet-id "1DZHnzxYWOlJ69Oguz4LkRVTFM79kC2tuvdwizOJmeMw" --spreadsheet-cred </div> </pre> Directly generate models from one of the supported registrants by using Registrant Connection Definition and (optional) Registrant Credential Definition <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl registry generate --registrant-def [path to connection definition] --registrant-cred [path to credential definition] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for generate -o, --output string location to output generated models, defaults to ../server/meshmodels (default "../server/meshmodel") --registrant-cred string path pointing to the registrant credetial definition --registrant-def string path pointing to the registrant connection definition --spreadsheet-cred string base64 encoded credential to download the spreadsheet --spreadsheet-id string spreadsheet it for the integration spreadsheet </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -v, --verbose verbose output </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: KICS (Provisioning / Security & Compliance)
File: 15ccec05-5476-4890-ad19-53991eba1db8.md

title: API Gateway With Open Access hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 15ccec05-5476-4890-ad19-53991eba1db8 Query name: API Gateway With Open Access Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: API Gateway Method should restrict the authorization type, except for the HTTP OPTIONS method.<br> ```tf title="Positive test num. 1 - tf file" hl_lines="4" resource "awsapigateway_method" "positive1" { restapiid = awsapigatewayrestapi.this.id resourceid = awsapigatewayresource.this.id http_method = "GET" authorization = "NONE" authorizerid = awsapigatewayauthorizer.this.id request_parameters = { "method.request.path.proxy" = true } } ``` ```tf title="Negative test num. 1 - tf file" resource "awsapigateway_method" "negative1" { restapiid = awsapigatewayrestapi.this.id resourceid = awsapigatewayresource.this.id http_method = "OPTIONS" authorization = "NONE" authorizerid = awsapigatewayauthorizer.this.id request_parameters = { "method.request.path.proxy" = true } } ```
Project: Checkov (Provisioning / Security & Compliance)
File: cloudsplaining.md

We make use of the Cloudsplaining project to perform some IAM-related checks. This folder is for test data to ensure we are making use of the Cloudsplaining policies as expected. https://github.com/salesforce/cloudsplaining https://docs.aws.amazon.com/IAM/latest/UserGuide/accesspoliciesunderstand-policy-summary-access-level-summaries.html https://github.com/bridgecrewio/checkov/issues/1037