cwielenb/CNCF-Dataset huggingface dataset:
Project: Beam (App Definition and Development / Streaming & Messaging)
File: tutanota.md

title: "Tutanota" icon: /images/logos/powered-by/tutanota.png hasLink: "https://tutanota.com/" <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->
Project: GraphScope (App Definition and Development / Database)
File: cypher_sdk.md

We have implemented Neo4j's protocol for you to connect your Neo4j applications to the GIE's Frontend service. Your first step is to obtain the Cypher endpoint for the connector Follow the while deploying GIE in a K8s cluster, Follow the while starting GIE on a local machine. GIE makes it easy to connect to a loaded graph with Neo4j's . You first install the dependency: ```bash pip3 install neo4j ``` Then connect to the service and run queries: ```Python from neo4j import GraphDatabase, RoutingControl URI = "neo4j://localhost:7687" # neo4j:// + Cypher endpoint you've obtained AUTH = ("", "") # We have not implemented authentication yet def printtop10(driver): records, , = driver.execute_query( "MATCH (n) RETURN n Limit 10", routing_=RoutingControl.READ, ) for record in records: print(record["n"]) with GraphDatabase.driver(URI, auth=AUTH) as driver: printtop10(driver) ``` ````{hint} A simpler option is to use the `interactive` object for submitting Cypher queries through , which is a wrapper that encompasses Neo4j's Python Driver and will automatically acquire the endpoint. ```` Download and extract `cypher-shell` ```bash wget https://dist.neo4j.org/cypher-shell/cypher-shell-4.4.19.zip unzip cypher-shell-4.4.19.zip && cd cypher-shell ``` Connect to the Bolt connector with the Cypher endpoint you've obtained ```bash ./cypher-shell -a neo4j://localhost:7687 ``` Run Queries ```bash @neo4j> Match (n) Return n Limit 10; ```
Project: Trivy (Provisioning / Security & Compliance)
File: ecr.md

Trivy uses AWS SDK. You don't need to install `aws` CLI tool. You can use . You may need to grant permissions to allow Trivy to pull images from private ECR. It depends on how you want to provide AWS Role to trivy. or Add the AWS role in trivy's service account annotations: ```yaml trivy: serviceAccount: annotations: {} ``` Add the AWS role to pod's annotations: ```yaml podAnnotations: {} ```
Project: KubeDB by AppsCode (App Definition and Development / Database)
File: kubectl-dba_data_drop.md

title: Kubectl-Dba Data Drop menu: docs_{{ .version }}: identifier: kubectl-dba-data-drop name: Kubectl-Dba Data Drop parent: reference-cli menuname: docs{{ .version }} sectionmenuid: reference Drop data from a database Drop data in a database. ``` kubectl-dba data drop ``` ``` kubectl dba data drop mariadb -n demo sample-maria kubectl dba data drop es -n demo Valid resource types include: elasticsearch mongodb mariadb mysql postgres redis ``` ``` -h, --help help for drop ``` ``` --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation. --cache-dir string Default cache directory (default "/home/runner/.kube/cache") --certificate-authority string Path to a cert file for the certificate authority --client-certificate string Path to a client certificate file for TLS --client-key string Path to a client key file for TLS --cluster string The name of the kubeconfig cluster to use --context string The name of the kubeconfig context to use --default-seccomp-profile-type string Default seccomp profile --disable-compression If true, opt-out of response compression for all requests to the server --insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kubeconfig string Path to the kubeconfig file to use for CLI requests. --match-server-version Require server version to match client version -n, --namespace string If present, the namespace scope for this CLI request --password string Password for basic authentication to the API server --request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0") -s, --server string The address and port of the Kubernetes API server --tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used --token string Bearer token for authentication to the API server --user string The name of the kubeconfig user to use --username string Username for basic authentication to the API server ``` - Insert, Drop or Verify data in a database - Delete data from elasticsearch database - Drop data from MariaDB - Drop data from mongodb - Drop data from mysql - Delete data from postgres database - Delete data from redis database
Project: ORY Hydra (Provisioning / Key Management)
File: Version.md

Name | Type | Description | Notes | - | - | - Version | Pointer to string | Version is the service&#39;s version. | [optional] `func NewVersion() *Version` NewVersion instantiates a new Version object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewVersionWithDefaults() *Version` NewVersionWithDefaults instantiates a new Version object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *Version) GetVersion() string` GetVersion returns the Version field if non-nil, zero value otherwise. `func (o Version) GetVersionOk() (string, bool)` GetVersionOk returns a tuple with the Version field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *Version) SetVersion(v string)` SetVersion sets Version field to given value. `func (o *Version) HasVersion() bool` HasVersion returns a boolean if a field has been set.
Project: KICS (Provisioning / Security & Compliance)
File: e3aa0612-4351-4a0d-983f-aefea25cf203.md

title: Root Containers Admitted hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: e3aa0612-4351-4a0d-983f-aefea25cf203 Query name: Root Containers Admitted Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Best Practices URL: Containers must not be allowed to run with root privileges, which means the attributes 'privileged','allowPrivilegeEscalation' and 'readOnlyRootFilesystem' must be set to false, 'runAsUser.rule' must be set to 'MustRunAsNonRoot', and adding the root group must be forbidden<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="32 12 13 27 31" apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: true allowPrivilegeEscalation: true requiredDropCapabilities: ALL volumes: 'configMap' 'emptyDir' 'projected' 'secret' 'downwardAPI' 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'MustRunAs' ranges: min: 0 max: 65535 ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: ALL volumes: 'configMap' 'emptyDir' 'projected' 'secret' 'downwardAPI' 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'MustRunAsNonRoot' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: min: 1 max: 65535 readOnlyRootFilesystem: true ```
Project: Harbor (Provisioning / Container Registry)
File: 2-24-admin-delete-projects.md

Test 2-24 - Admin User Delete Projects (DB Mode) ======= To verify that an admin user can delete other user's projects when users are managed locally by Harbor (DB mode). User guide This test requires that two(2) Harbor instances are running and available. Harbor is set to authenticate against a local database. ( auth_mode is set to db_auth* .) The user data is stored in a local database. A linux host with Docker CLI installed (Docker client). At least a non-admin user. NOTE: In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names. Must use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. DO NOT use the same browser to log in two users in different windows(tabs). Log in to UI as user A (non-admin). Create a project X so that the user has the project admin role. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1. Run `docker pull` to verify images can be pulled successfully. In UI, log out user A. Log in as admin user. Delete project X. (should fail with errors) Delete all images of project X. Delete project X. As an admin user, view the log in dashboard and should see delete operation of project X and its images. Step 7, deleting project X should fail because there are images under it. Step 8-9, deleting images of project X and then deleting project X should succeed. Step 10, there should be logs for deletion and creation of project X. None
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: pulumi.md

title: Pulumi software: pulumi aws gcp azure labels: category: publiccloud layer: orchestration code: https://github.com/pulumi/pulumi-policy-opa blogs: https://www.pulumi.com/blog/opa-support-for-crossguard/ videos: title: Testing Configuration with Open Policy Agent speakers: name: Gareth Rushgrove organization: snyk venue: Cloud Engineering Summit 2020 link: https://www.pulumi.com/resources/testing-configuration-with-open-policy-agent/ inventors: pulumi docs_features: go-integration: note: | The Pulumi OPA bridge uses the Rego API to evaluate policies in a policy pack. View the . Build infrastructure as code in familiar languages. CrossGuard is Pulumi's policy as code offering, providing OPA as one of the options to use for defining policy.
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-filter-view.md

layout: default title: mesheryctl-filter-view permalink: reference/mesheryctl/filter/view redirect_from: reference/mesheryctl/filter/view/ type: reference display-title: "false" language: en command: filter subcommand: view View filter(s) Displays the contents of a specific filter based on name or id <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl filter view [filter-name | ID] [flags] </div> </pre> View the specified WASM filter A unique prefix of the name or ID can also be provided. If the prefix is not unique, the first match will be returned. <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl filter view [filter-name | ID] </div> </pre> View all filter files <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl filter view --all </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -a, --all (optional) view all filters available -h, --help help for view -o, --output-format string (optional) format to display in [json|yaml] (default "yaml") </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -t, --token string Path to token file default from current context -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: Clair (Provisioning / Security & Compliance)
File: matching.md

A node is responsible for matching vulnerabilities to a provided IndexReport. Matchers by default are also responsible for keeping the database of vulnerabilities up to date. Matchers will typically run a set of Updaters which periodically probe their data sources for new contents, storing new vulnerabilities in the database when discovered. The matcher API is designed to be called often and will always provide the most up-to-date VulnerabilityReport when queried. This VulnerabilityReport summaries both a manifest's contents and any vulnerabilities affecting the contents. See our guide to learn how to view our api specification and work with the Matcher api. A remote matcher behaves similarly to a matcher, except that it uses api calls to fetch vulnerability data for a provided IndexReport. Remote matchers are useful when it is not possible to persist data from a given source into the database. The `crda` remote matcher is responsible for fetching vulnerabilities from Red Hat Code Ready Dependency Analytics (CRDA). By default, this matcher serves 100 requests per minute. The rate-limiting can be lifted by requesting a dedicated API key, which is done via . In summary you should understand that a Matcher node provides vulnerability reports given the output of an Indexing process. By default it will also run background Updaters keeping the vulnerability database up-to-date. For a more indepth look at indexing check out the
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.8.30.md

RabbitMQ `3.8.30` is a maintenance release. All users are recommended to upgrade to this release. RabbitMQ releases are distributed via , , and . This release and . explains what package repositories and tools can be used to provision modern Erlang versions. See the for general documentation on upgrades and for release notes of other releases. If upgrading from a `3.7.x` release, see upgrade and compatibility notes first. If upgrading from a `3.6.x` or older , first upgrade to and then to this version. Any questions about this release, upgrades or RabbitMQ in general are welcome on the and . Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and more consistent release schedule. Significantly faster queue re-import from on subsequent node restarts. Initial definition import still takes the same amount of time as before. GitHub issue: Significantly faster exchange re-import from on subsequent node restarts. Initial definition import still takes the same amount of time as before. GitHub issue: `rabbitmq-upgrade awaitonlinesynchronized_mirror` is now a no-op in single node clusters GitHub issue: `observer-cli` was upgraded To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.8.30.tar.xz` instead of the source tarball produced by GitHub.
Project: Teleport (Provisioning / Security & Compliance)
File: 0140-azure-blob-sessions.md

authors: Edoardo Spadolini (edoardo.spadolini@goteleport.com) state: draft Engineering: @fspmarshall && (@rosstimothy || @zmb3) Product: @xinding33 || @klizhentas || @russjones Enable users to leverage the Azure Blob Storage managed object storage service for Teleport session recordings. To support deployments of Teleport in Azure with the same convenience and reliability that's currently available when using managed storage in AWS and GCP. Azure Blob Storage offers similar functionality to S3, including all we need for `lib/events.MultipartUploader` in the strictest sense. In addition to that, it's possible to configure containers (the equivalent of a S3 bucket) to have a time-based immutability policy that prevents moving, renaming, overwriting or deleting a blob for a fixed amount of time after it's first written, which will allow us to not rely on versioning (like we do for S3 session storage). Similarly to other cloud-based session storage, the configuration looks like this, specifying a storage account URL. ```yaml teleport: storage: ... auditsessionsuri: "azblob://<storage account name>.blob.core.windows.net" ``` The `azblob` schema is only used by Teleport to identify the storage backend, and will actually result in a `https` URL. For testing against simulators (or other services with the same API surface) over `http`, the `azblob-http` schema is also supported (but we will leave it undocumented for end users). Teleport will require access to two containers in the storage account, named `session`, which will store the completed session files, and `inprogress`, which will be used as temporary space to hold parts. The container names can be tweaked with query parameters in the fragment of the URL: `#sessioncontainer=foo&inprogresscontainer=bar`. To signify the creation of an upload, a random UUID is generated, and an empty blob is created in `inprogress` with name `upload/<session id>/<upload id>`; this will be used when listing unfinished uploads, by listing blobs whose name begins with `upload/`. Parts are uploaded in `inprogress` with name `part/<session id>/<upload id>/<part number>`, which will allow listing the parts for a specific upload. To complete an upload, parts will be used as blocks to compose the final session recording in the `session` container (in a blob that has the session ID as its name); this can be done efficiently with the "Put Block By URL" call. Using a separate container for the final recordings lets the user configure an at the container level, which will prohibit any modification of completed blobs until a specified amount of time has passed or the block is removed; likewise, recordings older than a certain date can be configured to be automatically deleted via a .
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_spanner_databases.md

+++ title = "googlespannerdatabases resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googlespannerdatabases" identifier = "inspec/resources/gcp/googlespannerdatabases.md googlespannerdatabases resource" parent = "inspec/resources/gcp" +++ A `googlespannerdatabases` is used to test a Google Database resource ```ruby describe.one do googlespannerdatabases(project: 'chef-gcp-inspec', instance: 'spinstance').names.each do |name| describe name do it { should match 'spdatabase' } end end end ``` Properties that can be accessed from the `googlespannerdatabases` resource: See the resource for more information. `names` : an array of `googlespannerdatabase` name `instances` : an array of `googlespannerdatabase` instance 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: Hazelcast IMDG (App Definition and Development / Database)
File: feature_request.md

name: "Feature request" about: Suggest an idea for this project labels: 'Type: Enhancement' <!-- Thank you for suggesting an idea to make Hazelcast better. Please fill in as much of the template below as you're able. --> Please describe the problem you are trying to solve ... Please describe the desired behavior ... Describe alternatives you've considered ...
Project: YugabyteDB (App Definition and Development / Database)
File: docs-page-structure.md

title: Docs page structure headerTitle: Docs page structure linkTitle: Docs page structure description: Overview of the Markdown structure of YugabyteDB documentation pages menu: preview: identifier: docs-page-structure parent: docs-edit weight: 2914 type: docs All documentation pages must start with frontmatter as shown below. ```yaml title: SEO-Title-Browser-Tab-Title headerTitle: Doc-Page-Title linkTitle: Navigation-Link description: SEO-Meta-Description headcontent: Brief-description image: Icon-For-Page-Title menu: preview: identifier: page-identifier parent: parent-page-identifier weight: number-to-decide-display-order type: docs showRightNav: true rightNav: showH4: true ``` | Field name | Description | | : | :- | | `title` | Title text to display in browser tab and search engine results. This should be unique to the page. | | `headerTitle` | Title text to appear as the page title | | `linkTitle` | Title text to display in the navigation bar and breadcrumbs | | `description` | Description text to display in search results. This should be unique to the page. | | `headcontent` | Subtitle text below the headerTitle | | `menu` | Needs a menu name as defined in `menus.toml`. | | `identifier` | ID for the page. The page identifier must be unique within the scope of the menu. | | `parent` | The page's parent in the left nav. Required unless the page is a top-level page. | | `weight` | Determines menu ordering. Pages of lower weight display higher in the menu. Entries of equal weight are ordered alphabetically. | | `type` | Must be `docs` or `indexpage`. See . | | Field name | Default | Description | | :--: | :--: | :- | | `image` | N/A | Optional icon displayed next to the title (index pages only) | | `layout` | (depends) | On pages of `type: indexpage` (where the filename is not `index.*`), set `layout: list` to get Hugo to render the page `image`. You may also need to set `layout: single` on files of `type: docs` with a name of `index.*` to force Hugo to render them as regular pages. | | `showRightNav` | (depends) | Controls display of the TOC on the right. For pages of `type: docs`, default is true. For pages of `type: indexpage`, default is false. | | `rightNav:` > `hideH4` | `false` | Controls whether H4 elements show up in the TOC on the right. Set this to `true` to show only heading levels 2 and 3 in the right nav. | There are two different types of documentation pages: index pages, and content pages. Index pages have links to subtopics in a topic. These pages are generally named `index.html` or `index.md`, and have `type: indexpage` in their frontmatter. Content pages contain information about topics. These pages are named in the format `my-docs-page.md`, and have `type: docs` in their frontmatter.