cwielenb/CNCF-Dataset huggingface dataset:
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: jwt-blacklisting.md

id: jwt-blacklisting title: JWT Blacklisting sidebar_label: JWT Blacklisting Blacklisting is one of the RIG's core features. Imagine a use case where someone does a malicious action using specific JWT. By blacklisting this JWT, you can prevent any other malicious actions. Once it's blacklisted, user is not able to do any action within the RIG (unless it's an unsecured action -- e.g. unsecured reverse proxy endpoint). You can blacklist a JWT via REST API call to `POST :4010/v3/session-blacklist` and in body specify the `sessionId` and `validityInSeconds`. `sessionId` is by default expecting , but you can change it via `JWTSESSIONFIELD` env var. Blacklist is using so called tables to store JTIs and their expiration time. These information are automatically synchronized across RIG cluster. That means you can blacklist a JWT via whatever RIG node and it will apply to all RIG nodes. Blacklisted JTIs in ETS tables are cleaned up based on the `validityInSeconds` property provided in a request. `validityInSeconds` should be ideally set to at least **JWT expiration time - current time**. There are 2 APIs that are easily accessible via built-in Swagger UI (`your_host:4010/swagger-ui`). `POST :4010/v3/session-blacklist` - to blacklist a JWT `GET :4010/v3/session-blacklist/{sessionId}` - to check whether JWT is blacklisted at the moment JWT used below has the following payload: ```json { "sub": "1234567890", "name": "John Doe", "iat": 1516239022, "jti": "johndoe", "exp": 4516239022 } ``` Run in terminal: ```bash docker run -d --name rig \ -e PROXYCONFIGFILE='[{"id":"service","name":"service","authtype":"jwt","auth":{"useheader":true,"headername":"Authorization","usequery":false,"queryname":""},"versioned":false,"versiondata":{"default":{"endpoints":[{"id":"secured","pathregex":"todos/1","method":"GET","secured":true}]}},"proxy":{"targeturl":"http://jsonplaceholder.typicode.com","port":80}}]' \ -e JWTSECRETKEY='rigsecret' \ -p 4000:4000 \ -p 4010:4010 \ accenture/reactive-interaction-gateway curl "http://localhost:4010/v3/session-blacklist/johndoe" \ -H "accept: application/json" curl http://localhost:4000/todos/1 \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJqdGkiOiJqb2huZG9lIiwiZXhwIjo0NTE2MjM5MDIyfQ.gPPYaQphNAas3NXqqlfwvyzyTSN5sheMqX0Xnf4" curl -X POST "http://localhost:4010/v3/session-blacklist" -H "accept: application/json" -H "content-type: application/json" -d "{ \"validityInSeconds\": 60,\"sessionId\": \"johndoe\"}" curl "http://localhost:4010/v3/session-blacklist/johndoe" \ -H "accept: application/json" curl http://localhost:4000/todos/1 \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJqdGkiOiJqb2huZG9lIiwiZXhwIjo0NTE2MjM5MDIyfQ.gPPYaQphNAas3NXqqlfwvyzyTSN5sheMqX0Xnf4" ``` You can restrict access also to your WS/SSE/Longpolling connections/subscriptions via `SUBSCRIPTION_CHECK` env var, check the .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: README.md

Make sure you have python 3.6 or newer installed on your system before you begin. Once you you have the prerequisites installed, simply run the `bootstrap` script from this directory to set up a virtual environment using python 3 and start running the tool. ``` $ ./bootstrap ... Setup complete! To begin working, simply activate your virtual environment, run the CLI, and then deactivate the virtual environment when you are done. $ source activate $ mesos <command> [<args>...] $ source deactivate ``` You can also run the `bootstrap` script from any directory and specify the `VIRTUALENV_DIRECTORY` to set where it should be created. ``` $ VIRTUALENV_DIRECTORY=~/.mesos-cli-venv $ ${MESOSDIR}/src/python/clinew/bootstrap ... Setup complete! To begin working, simply activate your virtual environment, run the CLI, and then deactivate the virtual environment when you are done. $ source ~/.mesos-cli-venv/bin/activate $ source ~/.mesos-cli-venv/bin/postactivate $ mesos <command> [<args>...] $ source ~/.mesos-cli-venv/bin/predeactivate $ deactivate The postactivate and predeactivate files set up autocompletion. Add the mesos binary parent directory ${MESOSDIR}/src/python/clinew/bin/ to your path, export it, and source ${MESOSDIR}/src/python/clinew/mesos.bash_completion to skip these two steps in the future. ``` To run the unit tests developed for the Mesos CLI, use `mesos-cli-tests`: ``` $ ./bootstrap ... Setup complete! To begin working, simply activate your virtual environment, run the CLI, and then deactivate the virtual environment when you are done. $ source activate $ mesos-cli-tests Running the Mesos CLI unit tests ... OK ``` In order to use this tool, you will need to create a configuration file in your home directory under `~/.mesos/config.toml`. A template for this config can be seen below: ``` plugins = [ "</absolute/path/to/plugin-1/directory>", "</absolute/path/to/plugin-2/directory>" ] [master] address = "10.10.0.30:5050" principal = "username" secret = "password" [agent] ssl = true ssl_verify = false principal = "username" secret = "password" timeout = 5 ``` You can override the location of this configuration file using the environment variable `MESOSCLICONFIG`.
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: self-assessment.md

2023-10-31 K8gb is a Global Service Load Balancing solution with a focus on having cloud native qualities and work natively in a Kubernetes context. Quick reference information, later used for indexing. | | | | -- | -- | | Software | https://github.com/k8gb-io/k8gb | | Security Provider | No | | Languages | Golang | | SBOM | https://github.com/k8gb-io/k8gb/releases/download/v0.11.5/k8gb0.11.5linux_amd64.tar.gz.sbom.json | | | | | Doc | url | | -- | -- | | Security file | https://github.com/k8gb-io/k8gb/blob/master/SECURITY.md | | Security insights | https://github.com/k8gb-io/k8gb/blob/master/SECURITY-INSIGHTS.yml | | Cosign pub-key | https://github.com/k8gb-io/k8gb/blob/master/cosign.pub | To increase the software supply chain security, we encourage our users to consume k8gb container images with Kyverno's admission webhook () that will ensure that images are signed and nobody had tempered with them. Our public key that can be used to verify this is in the root or our repository.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.2.3.md

+++ title = "CoreDNS-1.2.3 Release" description = "CoreDNS-1.2.3 Release Notes." tags = ["Release", "1.2.3", "Notes"] release = "1.2.3" date = "2018-10-16T11:37:29+01:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.2.3! This is a big release that spans almost 6 weeks of development, slightly longer than normal. You may also have noticed that CoreDNS wasn't made the default in Kubernetes 1.12 due to increased memory used compared to kube-dns. This release contains a fix for that. The underlying DNS library has seen multiple updates to improve throughput and memory and we have enabled REUSE_PORT on the ports CoreDNS opens on \*nix. return a correct answer (SERVFAIL) if availability-zone or region labels are missing from a node. * Refactor add-on to support batch querying of Route 53 along with all AWS record types (including `CNAME`). Add support for zones with overlapping domains (split config) Minor improvements (`fallthrough`, `upstream` options, AWS credentials file support) add a minttl option to set the minimal TTL for records being cached. The cache key moved to hash/fnv64. can now also rewrite TTLs * Uses less memory (~30% less). Do not block on startup when connecting to the API server; returns SERVFAIL in the mean time. Support for using a `kubeconfig` file, including various auth providers (Azure not supported due to a compilation issue with that code). allows the reload interval to be configured. fix a crash when health checking is enabled in some circumstances. Aaron Riekenberg, Billie Cleek, Brad Beam, Can Yucel, Chris O'Haver, dilyevsky, Eugen Kleiner, Francois Tur, John Belamaric, Manuel Alejandro de Brito Fontes, Manuel Stocker, marqc, Miek Gieben, Nic Cope, Paul G, Ruslan Drozhdzh, Tom Thorogood, Yong Tang, Zach Eddy. For documentation see our (in progress!) . For help and other resources, see our .
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0001-use-actor-model.md

Accepted The key unit of deployment in this project is a securely signed WebAssembly module. This is a mouthful and becomes awkward and unwieldy when describing what people will be building and the tools they'll be using. When creating distributed systems, the need for consistent naming and terminology is a top concern for ensuring a smooth onboarding and new developer experience. We were heavily inspired by the prior work for the past several decades on the Actor model, including implementations like those found in Erlang/Elixir/OTP. Ease of accessibility to new developers Correctness of terms as they relate to distributed, concurrent systems Need for accurate shared language in documentation, comments, and evangelism Actor Model Create a new Name / Abstraction No abstraction (use the word module*) Chosen option: Actor model, because it matches with our inspiration, nomenclature, and the shared language we use to discuss the components of the overall system architecture. It also provides the right frame of reference for new developers unfamiliar with this project but who have past exposure to actor models (e.g. a familiar paradigm).
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: sagemaker.md

is a fully managed machine learning service. With Amazon SageMaker, data scientists and developers can quickly build and train machine learning models, and then deploy them into a production-ready hosted environment. is a tool for building machine learning pipelines that take advantage of direct SageMaker integration. For users using big data and machine learning, SageMaker task plugin help users connect big data workflows with SageMaker usage scenarios. DolphinScheduler SageMaker task plugin features are as follows: Start a SageMaker pipeline execution. Continuously get the execution status until the pipeline completes execution. Click `Project -> Management-Project -> Name-Workflow Definition`, and click the "Create Workflow" button to enter the DAG editing page. Drag from the toolbar <img src="../../../../img/tasks/icons/sagemaker.png" width="15"/> task node to canvas. Please refer to `Default Task Parameters` section for default parameters. Here are some specific parameters for the SagaMaker plugin: SagemakerRequestJson: Request parameters of StartPipelineExecutionsee also The task plugin are shown as follows: Some AWS configuration is required, modify a field in file `common.properties` ```yaml resource.aws.access.key.id=<YOUR AWS ACCESS KEY> resource.aws.secret.access.key=<YOUR AWS SECRET KEY> resource.aws.region=<AWS REGION> ```
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_create_secret_azure.md

title: "glooctl create secret azure" weight: 5 Create an Azure secret with the given name Create an Azure secret with the given name. The format of the secret data is: `{"azure" : [api-keys]}` ``` glooctl create secret azure [flags] ``` ``` --api-keys strings comma-separated list of azure api key=value entries -h, --help help for azure ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) --use-vault use Vault Key-Value storage as the backend for reading and writing secrets --vault-address string address of the Vault server. This should be a complete URL such as "http://vault.example.com". Use with --use-vault (default "https://127.0.0.1:8200") --vault-ca-cert string CACert is the path to a PEM-encoded CA cert file to use to verify the Vault server SSL certificate.Use with --use-vault --vault-ca-path string CAPath is the path to a directory of PEM-encoded CA cert files to verify the Vault server SSL certificate.Use with --use-vault --vault-client-cert string ClientCert is the path to the certificate for Vault communication.Use with --use-vault --vault-client-key string ClientKey is the path to the private key for Vault communication.Use with --use-vault --vault-path-prefix string The Secrets Engine to which Vault should route traffic. (default "secret") --vault-root-key string key prefix for Vault key-value storage inside a storage engine. (default "gloo") --vault-tls-insecure Insecure enables or disables SSL verification.Use with --use-vault --vault-tls-server-name string TLSServerName, if set, is used to set the SNI host when connecting via TLS.Use with --use-vault --vault-token string The root token to authenticate with a Vault server. Use with --use-vault ``` - Create a secret
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_completion_zsh.md

Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(kusk completion zsh); compdef _kusk kusk To load completions for every new session, execute once: kusk completion zsh > "${fpath[1]}/_kusk" kusk completion zsh > $(brew --prefix)/share/zsh/site-functions/_kusk You will need to start a new shell for this setup to take effect. ``` kusk completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` - Generate the autocompletion script for the specified shell
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-dashboard-apis-status.md

Health monitoring of your APIs by sending requests to an `health` endpoint on each API. The API backend should perform the necessary checks by providing some probes and return an indication of its status. You can hide or show APIs which do not have any health-check configuration. You can click the `View detail` link on a card to navigate to the health-check page of a specific API.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Katalyst (Orchestration & Management / Scheduling & Orchestration)
File: GOVERNANCE.md

The governance model adopted in Katalyst is influenced by many CNCF projects. Open: Katalyst is open source community. See (TODO: add Contributor License Agreement). Welcoming and respectful: See . Transparent and accessible: Work and collaboration should be done in public. Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles. The Katalyst is aligned with the CNCF Code of Conduct. See community membership (TODO: add community membership). Decisions are made based on consensus between maintainers. Proposals and ideas can either be submitted for agreement via a GitHub issue or PR, or by sending an email to (TODO: register an email for the org). In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background on the issue, but not involved in the conflict) to intercede and the final decision will be made. Decision-making process should be transparent to adhere to the principles of Katalyst project. Some contents in this documents have been borrowed from , , and projects.
Project: Kong (Orchestration & Management / API Gateway)
File: PULL_REQUEST_TEMPLATE.md

<!-- NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch, and ensure you followed them all: https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributing Refer to the Kong Gateway Community Pledge to understand how we work with the open source community: https://github.com/Kong/kong/blob/master/COMMUNITY_PLEDGE.md --> <! Why is this change required? What problem does it solve? --> [ ] The Pull Request has tests [ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE <! If it fixes an open issue, please link to the issue here. --> Fix #[issue number]
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Please refer to the contribution document ```bash ./mvnw clean install -Prelease ``` The default Zookeeper Server version supported is 3.8.0. ```bash ./mvnw clean install -Prelease ./mvnw clean install -Prelease -Dzk-3.4 ``` Artifact: ``` dolphinscheduler-dist/target/apache-dolphinscheduler-${latest.release.version}-bin.tar.gz: Binary package of DolphinScheduler dolphinscheduler-dist/target/apache-dolphinscheduler-${latest.release.version}-src.tar.gz: Source code package of DolphinScheduler ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.