cwielenb/CNCF-Dataset huggingface dataset:
Project: KubeArmor (Provisioning / Security & Compliance)
File: differentiation.md

<img src="../.gitbook/assets/differentiation.png" width="784" class="center" alt="KubeArmor Differentiation"> KubeArmor supports attack prevention, not just observability and monitoring. More importantly, the prevention is handled inline: even before a process is spawned, a rule can deny execution of a process. Most other systems typically employ "post-attack mitigation" that kills a process/pod after malicious intent is observed, allowing an attacker to execute code on the target environment. Essentially KubeArmor uses inline mitigation to reduce the attack surface of a pod/container/VM. KubeArmor leverages best of breed Linux Security Modules (LSMs) such as AppArmor, BPF-LSM, and SELinux (only for host protection) for inline mitigation. LSMs have several advantages over other techniques: KubeArmor does not change anything with the pod/container. KubeArmor does not require any changes at the host level or at the CRI (Container Runtime Interface) level to enforce blocking rules. KubeArmor deploys as a non-privileged DaemonSet with certain capabilities that allows it to monitor other pods/containers and the host. A given cluster can have multiple nodes utilizing different LSMs. KubeArmor abstracts away complexities of LSMs and provides an easy way to enforce policies. KubeArmor manages complexity of LSMs under-the-hood. <img src="../.gitbook/assets/post-attack-mitigation.png" width="400" class="center" alt="Post Attack Mitigation"> Post-exploit Mitigation works by killing a suspicious process in response to an alert indicating malicious intent. Attacker is allowed to execute a binary. Attacker could disable security controls, access logs, etc to circumvent attack detection. By the time a malicious process is killed, sensitive contents could have already been deleted, encrypted, or transmitted. , post-exploitation detection/mitigation is at the mercy of an exploit writer putting little to no effort into avoiding tripping these detection mechanisms. allows one to specify or policies. <img src="../.gitbook/assets/pod security context.png" width="512" class="center" alt="Pod Security Context"> This approach has multiple problems: It is often difficult to predict which LSM (AppArmor or SELinux) would be available on the target node. BPF-LSM is not supported by Pod Security Context. It is difficult to manually specify an AppArmor or SELinux policy. Changing default AppArmor or SELinux policies might result in more security holes since it is difficult to decipher the implications of the changes and can be counter-productive. Different managed cloud providers use different default distributions. Google GKE COS uses AppArmor by default, AWS Bottlerocket uses BPF-LSM and SELinux, and AWS Amazon Linux 2 uses only SELinux by default. Thus it is challenging to use Pod Security Context in multi-cloud deployments. <img src="../.gitbook/assets/multi-cloud.png" width="784" class="center" alt="Multi Cloud issues with LSMs"> <img src="../.gitbook/assets/bpf-lsm.png" width="512" class="center" alt="BPF-LSM with KubeArmor"> References:
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: podman-system-prune.1.md

% podman-system-prune 1 podman\-system\-prune - Remove all unused pods, containers, images, networks, and volume data podman system prune [options] podman system prune removes all unused containers (both dangling and unreferenced), pods, networks, and optionally, volumes from local storage. Use the --all option to delete all unused images. Unused images are dangling images as well as any image that does not have any containers based on it. By default, volumes are not removed to prevent important data from being deleted if there is currently no container using the volume. Use the --volumes flag when running the command to prune volumes as well. Recursively remove all unused pods, containers, images, networks, and volume data. (Maximum 50 iterations.) Removes all leftover container storage files from local storage not managed by Podman. In normal circumstances, no such data exists, but in case of an unclean shutdown, the Podman database may be corrupted and cause this. However, when using transient storage mode, the Podman database does not persist. This means containers leave the writable layers on disk after a reboot. When using a transient store, it is recommended that the podman system prune --external command is run during boot. This option is incompatible with --all and --filter and drops the default behaviour of removing unused resources. Provide filter values. The filters argument format is of `key=value`. If there is more than one filter, then pass multiple OPTIONS: --filter foo=bar --filter bif=baz. Supported filters: | Filter | Description | |::|--| | label | Only remove containers and images, with (or without, in the case of label!=[...] is used) the specified labels. | | until | Only remove containers and images created before given timestamp. | The `label` filter accepts two formats. One is the `label`=key or `label`=key=value, which removes containers and images with the specified labels. The other format is the `label!`=key or `label!`=key=value, which removes containers and images without the specified labels. The `until` filter can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. 10m, 1h30m) computed relative to the machines time. Do not prompt for confirmation Print usage statement Prune volumes currently unused by any container , February 2019, Originally compiled by Dan Walsh (dwalsh at redhat dot com) December 2020, converted filter information from docs.docker.com documentation by Dan Walsh (dwalsh at redhat dot com)
Project: Numaflow (App Definition and Development / Streaming & Messaging)
File: conditional-forwarding.md

After processing the data, conditional forwarding is doable based on the `Tags` returned in the result. Below is a list of different logic operations that can be done on tags. and - forwards the message if all the tags specified are present in Message's tags. or - forwards the message if one of the tags specified is present in Message's tags. not - forwards the message if all the tags specified are not present in Message's tags. For example, there's a UDF used to process numbers, and forward the result to different vertices based on the number is even or odd. In this case, you can set the `tag` to `even-tag` or `odd-tag` in each of the returned messages, and define the edges as below: ```yaml edges: from: p1 to: even-vertex conditions: tags: operator: or # Optional, defaults to "or". values: even-tag from: p1 to: odd-vertex conditions: tags: operator: not values: odd-tag from: p1 to: all conditions: tags: operator: and values: odd-tag even-tag ```
Project: Sonobuoy (Provisioning / Security & Compliance)
File: sonobuoy_logs.md

Dumps the logs of the currently running Sonobuoy containers for diagnostics ``` sonobuoy logs [flags] ``` ``` --context string Context in the kubeconfig to use. -f, --follow Continue following the logs of the Sonobuoy created containers. -h, --help help for logs --kubeconfig Kubeconfig Path to explicit kubeconfig file. -n, --namespace string The namespace to run Sonobuoy in. Only one Sonobuoy run can exist per namespace simultaneously. (default "sonobuoy") -p, --plugin string Show logs only for a specific plugin. If 'sonobuoy' is provided, only shows the aggregator logs. ``` ``` --level level Log level. One of {panic, fatal, error, warn, info, debug, trace} (default info) ``` - Generate reports on your Kubernetes cluster by running plugins
Project: kpt (Provisioning / Automation & Configuration)
File: kpt-cli.md

Users can get kpt CLI in a variety of ways: Download pre-compiled binaries: Optionally verify the generated using the OpenSSF's during the release process. To verify a release binary: Install the verification tool from . Download the signature file `attestation.intoto.jsonl` from the . Run the verifier: ```shell slsa-verifier -artifact-path kpt-<os>-<arch> -provenance attestation.intoto.jsonl -source github.com/GoogleContainerTools/kpt -tag <the-tag> ``` On Linux and MacOS, make it executable: ```shell $ chmod +x kpt ``` ?> On MacOS the first time, it may be necessary to open the program from the finder with ctrl-click open. Verify the version: ```shell $ kpt version ``` kpt provides auto-completion support for several of the common shells. To see the options for enabling shell auto-completion: ```shell $ kpt completion -h ``` Previous installations of kpt completion may have added the following line to the shell's config file (e.g. `.bashrc`, `.zshrc`, etc.): ```shell $ complete -C <KPT_PATH> kpt ``` This line needs to be removed for kpt's completion implementation to function properly. The kpt completion script for a shell can be generated with the commands `kpt completion bash`, `kpt completion zsh`, etc. For instructions on how to enable the script for the given shell, see the help page with the commands `kpt completion bash -h`, `kpt completion zsh -h`, etc. Install with gcloud. ```shell $ gcloud components install kpt ``` ```shell $ kpt version ``` The version of kpt installed using `gcloud` may not be the latest released version, and can lag behind. Please use another installation method if you need to latest release. Install the latest release with Homebrew on MacOS. ```shell $ brew tap GoogleContainerTools/kpt https://github.com/GoogleContainerTools/kpt.git $ brew install kpt ``` ```shell $ kpt version ``` The version of kpt installed using `brew` can only be a tagged release, master releases are not shipped. Use one of the kpt docker images. | Feature | `kpt` | `kpt-gcloud` | | | :: | :-: | | kpt | | | | git | | | | diffutils | | | | gcloud | | | ```shell $ docker run gcr.io/kpt-dev/kpt:v1.0.0-beta.49 version ``` An image which includes kpt based upon the Google [cloud-sdk] alpine image. ```shell $ docker run gcr.io/kpt-dev/kpt-gcloud:v1.0.0-beta.49 version ``` Install by compiling the source. This requires having Go version 1.21+: ```shell $ go install -v github.com/GoogleContainerTools/kpt@main ``` kpt version will return `unknown` for binaries built from source: ```shell $ kpt version ```
Project: KubeBlocks by ApeCloud (App Definition and Development / Database)
File: README.md

Additional external test apps and test data. Feel free to structure the `/test` directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have `/test/data` or `/test/testdata` if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory. Examples: https://github.com/openshift/origin/tree/master/test (test data is in the `/testdata` subdirectory)
Project: Meshery (Provisioning / Automation & Configuration)
File: 09-27-2022-21-04-09_6cf960c6.md

timestamp: "2022-09-27 21:04:22 UTC Tue" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "v0.6.9" k8s-distro: minikube k8s-version: "v1.20.11" service-mesh: Consul service-mesh-version: "v0.48.0" tests: consul-client: null consul-server: null overall-status: "failing"
Project: Juju (Provisioning / Automation & Configuration)
File: cleanup.md

Cleanup is called by the cleaner worker. The cleaner worker watches the cleanups collection and acts when something changes in the collection related to the current model. It will also act on a period time frame. Cleanup will interate over the current docs in the collection and call a method to handle the doc based on its kind. If the method is successful, the corresponding doc will be removed from the collection. Otherwise the method will be retried later. Docs in the cleanups collection are handled in a specific order. E.g. cleaning up a machine requires that it's units are gone, so clean up the units first. Model cleanup starts with `juju destroy-model`, or `juju destroy-controller`. Simplistically model destroyOps, causes the model is marked as dying and up to 5 docs are inserted into the cleanup collection: cleanupModelsForDyingController, only for controller models cleanupApplicationsForDyingModel, only with non empty models cleanupMachinesForDyingModel, only with non empty IAAS models cleanupStorageForDyingModel, only with non empty models with storage cleanupBranchesForDyingModel, for all models First it attempts to remove all remote applications from the model, then attempts to remove all applications from the model. Removing an application inserts a cleanupForceApplication into the cleanups collection. For all machines in the model, which are not managers, call DestroyWithContainers. If force is used, call ForceDestroy instead. Force is not allowed for manual machines. The first failure causes the method to exit. DestroyWithContainers advances the machine's lifecycle to Dying, and inserts a cleanupDyingMachine job into the cleanups collection. Once a machine is dying, it's lifecycle takes over. For the dying machine, call cleanupDyingMachineResources. After that, if force is in use, and the machine hasn't been forcedestroyed yet, schedule cleanupForceRemoveMachine by inserting the doc into the cleanups collection. cleanupDyingMachineResources checks that the machine has no filesystem nor volume attachments. Then calls cleanupDyingEntityStorage, which detaches all detachable storge and destroys storage which cannot be detached.
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: inspektor_gadgets_repositories.md

Inspektor gadgets repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path/to/packages provided can contain metadata for one or more packages. Each package version must be on a separate folder, and it's up to you to decide if you want to publish one or multiple versions of your package. The structure of a repository with multiple gadgets packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml 2.0.0 README.md artifacthub-pkg.yml package2 1.0.0 README.md artifacthub-pkg.yml ``` This structure is flexible, and in some cases where you only have a package and a version it can be greatly simplified. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file for more details. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. The allows defining containers images. Inspektor gadgets packages are required to provide an image named `gadget` that points to the image containing the gadget. Packages can optionally provide an alternative location for the gadget image by defining a second image named `gadget-alternative-location`. Artifact Hub will check if the images provided have been signed with `cosign` and will consider the package to be signed when all images are signed. Once you have added your repository, you are all set up. As you add new versions of your gadgets packages or new packages to your git repository, they'll be automatically indexed and listed in Artifact Hub.
Project: Kapitan (Provisioning / Automation & Configuration)
File: kapitan_searchvar.md

Shows all inventory files where a variable is declared: !!! example "" ```shell ./kapitan searchvar parameters.components.*.image ``` ??? example "click to expand output" ```shell ./inventory/classes/components/vault.yml ${vault:image} ./inventory/classes/components/logstash.yml eu.gcr.io/antha-images/logstash:7.5.1 ./inventory/classes/components/gke-pvm-killer.yml estafette/estafette-gke-preemptible-killer:1.2.5 ./inventory/classes/components/mysql.yml mysql:5.7.28 ./inventory/classes/components/postgres-proxy.yml gcr.io/cloudsql-docker/gce-proxy:1.16 ./inventory/classes/components/echo-server.yml jmalloc/echo-server ./inventory/classes/components/trivy.yml ${trivy:image} ./inventory/classes/components/filebeat.yml ${filebeat:image}:${filebeat:version} ./inventory/classes/components/pritunl/pritunl-mongo.yml docker.io/bitnami/mongodb:4.2.6-debian-10-r23 ./inventory/classes/components/pritunl/pritunl.yml alledm/pritunl ./inventory/classes/components/weaveworks/user-db.yml weaveworksdemos/user-db:0.3.0 ./inventory/classes/components/weaveworks/catalogue.yml weaveworksdemos/catalogue:0.3.5 ./inventory/classes/components/weaveworks/user.yml weaveworksdemos/user:0.4.7 ./inventory/classes/components/weaveworks/session-db.yml redis:alpine ./inventory/classes/components/weaveworks/catalogue-db.yml weaveworksdemos/catalogue-db:0.3.0 ./inventory/classes/components/weaveworks/carts-db.yml mongo ./inventory/classes/components/weaveworks/orders-db.yml mongo ./inventory/classes/components/weaveworks/orders.yml weaveworksdemos/orders:0.4.7 ./inventory/classes/components/weaveworks/shipping.yml weaveworksdemos/shipping:0.4.8 ./inventory/classes/components/weaveworks/queue-master.yml weaveworksdemos/queue-master:0.3.1 ./inventory/classes/components/weaveworks/rabbitmq.yml rabbitmq:3.6.8-management ./inventory/classes/components/weaveworks/payment.yml weaveworksdemos/payment:0.4.3 ./inventory/classes/components/weaveworks/front-end.yml weaveworksdemos/front-end:0.3.12 ./inventory/classes/components/weaveworks/carts.yml weaveworksdemos/carts:0.4.8 ./inventory/classes/components/kapicorp/tesoro.yml kapicorp/tesoro ```
Project: sso (Provisioning / Key Management)
File: feature_request.md

name: Feature request about: Suggest an idea for this project Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_compute_router_nats.md

+++ title = "googlecomputerouter_nats resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlecomputerouter_nats" identifier = "inspec/resources/gcp/googlecomputerouternats.md googlecomputerouternats resource" parent = "inspec/resources/gcp" +++ A `googlecomputerouter_nats` is used to test a Google RouterNat resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googlecomputerouter_nats(project: 'chef-gcp-inspec', region: 'europe-west2', router: 'inspec-gcp-router') do its('names') { should include 'inspec-router-nat' } end ``` Properties that can be accessed from the `googlecomputerouter_nats` resource: See the resource for more information. `names` : an array of `googlecomputerouter_nat` name `natipallocate_options` : an array of `googlecomputerouternat` natipallocateoption `nat_ips` : an array of `googlecomputerouternat` natips `drainnatips` : an array of `googlecomputerouternat` drainnat_ips `sourcesubnetworkiprangesto_nats` : an array of `googlecomputerouternat` sourcesubnetworkiprangestonat `subnetworks` : an array of `googlecomputerouter_nat` subnetwork `minportsper_vms` : an array of `googlecomputerouternat` minportspervm `udpidletimeout_secs` : an array of `googlecomputerouternat` udpidletimeoutsec `icmpidletimeout_secs` : an array of `googlecomputerouternat` icmpidletimeoutsec `tcpestablishedidletimeoutsecs` : an array of `googlecomputerouternat` tcpestablishedidletimeout_sec `tcptransitoryidletimeoutsecs` : an array of `googlecomputerouternat` tcptransitoryidletimeout_sec `log_configs` : an array of `googlecomputerouternat` logconfig `routers` : an array of `googlecomputerouter_nat` router `regions` : an array of `googlecomputerouter_nat` region 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: Meshery (Provisioning / Automation & Configuration)
File: v0.4.24.md

layout: release date: 2020-11-24 tag: v0.4.24 [ doc ] add completion doc @jiraguha (#1962) fixes #1954 @vineethvanga18 (#1958) Replace the chart icon @Aisuko (#1955) Reformat the rest of the adapter charts @Aisuko (#1917) fix: backend build for meshery @kushthedude (#1979) fix: docker builds failures in CI @kushthedude (#1959) fix: backend build for meshery @kushthedude (#1979) Bump start-server-and-test from 1.11.2 to 1.11.5 in /ui @dependabot-preview (#1939) Bump cypress from 5.5.0 to 5.6.0 in /ui @dependabot-preview (#1940) fix: docker builds failures in CI @kushthedude (#1959) Bump uuid from 8.3.0 to 8.3.1 in /ui @dependabot-preview (#1932) Bump husky from 4.2.5 to 4.3.0 in /ui @dependabot-preview (#1938)
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.61.md

layout: release date: 2023-03-03 tag: v0.6.61 language: en Install the CodeSee workflow. @codesee-maps (#7263) Thank you to our contributors for making this release possible: @codesee-maps, @codesee-maps[bot] and @leecalcote
Project: YugabyteDB (App Definition and Development / Database)
File: create_role,role_option.grammar.md

```output.ebnf createrole ::= CREATE ROLE rolename [ [ WITH ] role_option [ , ... ] ] role_option ::= SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | INHERIT | NOINHERIT | LOGIN | NOLOGIN | CONNECTION LIMIT connlimit | [ ENCRYPTED ] PASSWORD ' password ' | PASSWORD NULL | VALID UNTIL ' timestamp ' | IN ROLE role_name [ , ... ] | IN GROUP role_name [ , ... ] | ROLE role_name [ , ... ] | ADMIN role_name [ , ... ] | USER role_name [ , ... ] | SYSID uid ```