DOCSEARCHbyAlgolia
Submit Docs

Kyverno Policies Library

repository·main·Indexed 19 days ago

https://github.com/kyverno/policies

A centralized library of ready-to-use Kyverno policies for Kubernetes and ecosystem resources. It includes security and governance policies such as Kasten K10 Data Protection Guardrails, KubeVirt VMI management, OpenShift security best practices, and implementations of the official Kubernetes Pod Security Standards (Baseline and Restricted profiles).

Tokens
3.5K
Snippets
4
Records
13
Agent score
67%

What's inside kyverno-policies

  1. Available Kyverno policies for OpenShift

    main

    This repository contains a collection of Kyverno policies specifically designed for OpenShift environments to enforce security best practices and deprecate legacy configurations.

    Key policies include:

    • Enforce etcd encryption on OpenShift ApiServer: Ensures sensitive data in etcd is encrypted.
    • Disallow OpenShift RBAC API groups: Prevents the use of OpenShift-specific RBAC groups, encouraging the use of upstream Kubernetes RBAC.
    • Disallow Jenkins Pipeline Build Strategy: Prevents the use of Jenkins build strategies for OpenShift builds, favoring Tekton instead.
    • Disallow binding to the self-provisioners ClusterRoleBinding: Restricts access to the self-provisioner role.
    • Disallow the use of the anyuid SecurityContextConstraint (SCC): Prevents pods from running with a declared UID instead of a random UID, enforcing stricter security.
    • Disallow non-HTTPS OpenShift Routes: Ensures all OpenShift Routes use HTTPS for secure communication.

  2. Capabilities of Kasten K10 Data Protection Guardrails

    main

    Kasten K10 DPG protects stateful applications by enforcing several data protection best practices and requirements:

    • Backup RPO Enforcement: Ensures backup schedules follow best practices (e.g., enforcing hourly or daily backups).
    • Immutability Verification: Checks K10 Location Profiles to ensure immutability is enabled, providing a defense against ransomware.
    • Retention Policy Management: Overrides minimum retention policies to balance storage cost optimization with data retention compliance.
    • 3-2-1 Strategy Support: Enables backup snapshots followed by exports to cloud object storage to satisfy the '3-2-1' backup rule.
    • Self-Service Data Protection: Assigns data protection via named K10 policies to automatically generate Kasten K10 Policy resources.

  3. What are Kasten K10 Data Protection Guardrails (DPG)?

    main
    Data Protection Guardrails (DPG) are a set of Kubernetes-native data protection policies implemented using Kyverno. They are designed to enforce data protection for stateful cloud-native applications against risks such as ransomware, natural or accidental disasters, and human error. DPG implements the principles outlined in the WG-Policy Management Whitepaper specifically within a data protection context.

  4. Configure ProcMountType feature flag for proc-mount policies

    main
    When using the proc-mount policy, be aware that the pod may execute with non-default values for securityContext.procMount. To support these values, you must ensure the ProcMountType feature flag is enabled in your environment.

  5. Browse and search Kyverno policies

    main

    You can find a simplified, searchable list of all Kyverno policies represented in this repository at the official Kyverno policies website. This interface allows for easy filtering by various attributes.

    https://kyverno.io/policies/

  6. Verify OpenShift policies using Kyverno CLI

    main

    To verify the integrity and correctness of the OpenShift policies in this repository, you can run tests using the Kyverno CLI and kubectl.

    Prerequisites:

    1. Install the Kyverno CLI.
    2. Ensure you have kubectl configured to access a cluster or a local environment.

    Steps:

    1. Clone this repository and navigate to the root directory.
    2. Execute the kyverno-kubectl test command against the current directory.
    # Clone the repo and enter the directory
git clone <repository-url>
cd kyverno-policies

# Run the tests
kyverno-kubectl test .

  7. Request a new Kyverno policy

    main

    If a policy you need does not exist, you can request one by opening a GitHub issue. To help maintainers, please include:

    1. A detailed explanation of your use case (why you need it).
    2. A description of what the policy should do and which resources it should target.
    3. Any previous attempts you made to craft the policy yourself and why they were unsuccessful.
    4. Prompt responses to follow-up questions from contributors or maintainers.

    You can also seek immediate assistance via the Kyverno Slack.

  8. Use Kubeops Policy Examples

    main

    The kubeops/ directory contains Kyverno policy examples designed to apply security or operational policies to tools curated by Kubeops.

    One specific use case provided is:

    • config-syncer-secret-generation-from-rancher-capi: This policy enables config-syncer (formerly kubed) for Rancher downstream clusters. It works by generating a kubeconfig Secret that contains the specific downstream cluster contexts where you intend to sync your ConfigMap or Secret objects.

  9. Guidelines for contributing Kyverno policies

    main

    When contributing new policies to the kyverno/policies repository, follow these standards to ensure they are effective and correctly indexed:

    • DCO Compliance: All contributors must sign off on git commits per CNCF DCO guidelines.
    • Metadata: Use Kyverno annotations to provide descriptive metadata. This is required for the filtering logic on the official policies page to function.
    • Naming: Use descriptive names for policies. Use dashes (-) instead of underscores (_) for both policy names and folder names.
    • Folder Structure: Each policy must reside in its own dedicated folder named identically to the policy (using dashes).
    • Validation: For validate rules, set validationFailureAction: Audit by default to prevent unintended blocking of resources in user environments.
    • Testing: Provide test resources so policies can be validated using the Kyverno CLI.
    • JMESPath Expressions: String values containing JMESPath expressions (e.g., {{request.operation}}) do not need quotes unless the field's value consists only of that expression, in which case it must be double-quoted.
    • Artifact Hub: Every new policy requires an artifacthub-pkg.yml file in its directory to support distribution via Artifact Hub.

  10. Implement Kubernetes Pod Security Standards with Kyverno

    main

    Kyverno provides collections of policies that implement the official Kubernetes Pod Security Standards. These policies allow you to enforce different levels of security across your cluster:

    • Baseline/Default profile: Minimally restrictive. It denies the most common vulnerabilities while allowing standard pod operations.
    • Restricted profile: Heavily restrictive. It enforces a much stricter set of security best practices for Pods.

    The preferred method for installing these policy collections is via Helm.

  11. Use KubeVirt policy examples

    main

    The kubevirt/ directory provides Kyverno policy examples specifically designed to manage and secure KubeVirt Virtual Machine Instances (VMIs). These examples demonstrate two primary Kyverno policy types:

    1. Generating Policies: Used to automate resource creation. For example, the add-services policy automatically creates a Service for every new VMI.
    2. Validating Policies: Used to enforce constraints. For example, the enforce-instancetype policy ensures that VMIs adhere to specific instance types and preferences.

  12. Configure artifacthub-pkg.yml for policy distribution

    main

    To make policies available on Artifact Hub, create an artifacthub-pkg.yml file in the policy's directory.

    Key Requirements:

    • name: Alphanumeric characters and dashes only.
    • description: This should match the value used in the policies.kyverno.io/description annotation.
    • install: Provide the kubectl apply command used to install the policy.
    • keywords: Must include kyverno and the value from the policies.kyverno.io/category annotation.
    • readme: Should contain the description from the annotation plus a static concluding sentence.
    • digest: A SHA256 hash of the policy. Note: This must be generated on a Linux system to ensure consistency with Kyverno's CI validation (Windows-generated digests may differ due to control characters).
    • Updating: When updating an existing policy, recalculate the SHA256 sum and update the digest field so Artifact Hub detects the change.
    ---
name: backup-all-volumes # The name of the package (only alphanum, no spaces, dashes allowed)
version: 1.0.0 # Version of the policy
displayName: Backup All Volumes  # Display name of the policy
createdAt: "2023-03-29T00:00:00.000Z" # The date this package was created (RFC3339 layout)
description: >-
# The description value should be taken from the relevant annotation policies.kyverno.io/description
      In order for Velero to backup volumes in a Pod using an opt-in approach, it
      requires an annotation on the Pod called `backup.velero.io/backup-volumes` with the
      value of a comma-separated list of the volumes mounted to that Pod. This policy
      automatically annotates Pods (and Pod controllers) which refer to a PVC so that
      all volumes are listed in the aforementioned annotation if a Namespace with the label
      `velero-backup-pvc=true`.
install: |- # The installation instructions for the package
    ```shell
    kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/velero/backup-all-volumes/backup-all-volumes.yaml
    ```   
keywords: # Keywords should always have "kyverno" and whatever the value of the policies.kyverno.io/category annotation. 
  - velero
  - kyverno
readme: | # readme should be same as policies.kyverno.io/description annotation plus the last sentence as a static value.
  In order for Velero to backup volumes in a Pod using an opt-in approach, it
  requires an annotation on the Pod called `backup.velero.io/backup-volumes` with the
  value of a comma-separated list of the volumes mounted to that Pod. This policy
  automatically annotates Pods (and Pod controllers) which refer to a PVC so that
  all volumes are listed in the aforementioned annotation if a Namespace with the label
  `velero-backup-pvc=true`.

  Refer to the documentation for more details on Kyverno annotations: https://artifacthub.io/docs/topics/annotations/kyverno/
annotations:
  kyverno/category: "Velero"
  kyverno/kubernetesVersion: "1.25"
  kyverno/subject: "Pod, Annotation"
digest: 795012387c2755c61fa802fea900011c45520c2cffb27238210933ebb9a7f2c0 # The SHA256 hash String that uniquely identifies this package version