Policy Library
Curated Kyverno policies for Kubernetes security, compliance, and best practices — maintained by Nirmata.
Disallow Capabilities
Adding additional capabilities beyond those listed below must be disallowed. Restricted Fields...
Disallow Host Namespaces
Host namespaces (Process ID namespace, Inter-Process Communication namespace, and network namespace) allow access to shared...
Disallow Host Path
HostPath volumes let Pods use host directories and volumes in containers. Using host resources can be used to access shared data...
Disallow Host Ports
Access to host ports allows potential snooping of network traffic and should not be allowed, or at minimum restricted to a known...
Disallow Host Process
Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged...
Disallow Privileged Containers
Privileged mode disables most security mechanisms and must not be allowed. This control ensures Pods do not call for privileged...
Disallow Proc Mount
The default /proc masks are set up to reduce attack surface, and should be required. This security control ensures nothing but the...
Disallow SELinux
Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden. Restricted Fields for...
Restrict Apparmor Profiles
On supported hosts, the runtime/default AppArmor profile is applied by default. The baseline policy should prevent overriding or...
Restrict Seccomp
Seccomp, stands for ‘Secure Computing Mode,’ and is a security mechanism within the Linux kernel. It functions by...
Restrict Sysctls
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed...
Disallow Capabilities Strict
Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability. This is Linux only...
Disallow Privilege Escalation
Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed. This is Linux only policy in...
Require Run As Non-root
Containers must be required to run as non-root users. Restricted Fields spec.securityContext.runAsNonRoot...
Require Run As Non-root User
Containers must not set runAsUser to 0. Restricted Fields spec.securityContext.runAsUser...
Restrict Seccomp Strict
Seccomp profile must be explicitly set to one of the allowed values. Both the Unconfined profile and the absence of a profile are...
Restrict Volume Types
In addition to restricting HostPath volumes, the restricted pod security profile limits usage of non-core volume types to those...
Disable Automount SA Token
A new ServiceAccount called default is created whenever a new Namespace is created. Pods spawned in that Namespace, unless...
Restrict Automount SA Token
Kubernetes automatically mounts ServiceAccount credentials in each Pod. The ServiceAccount may be assigned roles allowing Pods to...
Restrict Binding System Groups
Certain system groups exist in Kubernetes which grant permissions that are used for certain system-level functions yet typically...
Restrict ClusterRole Nodesproxy
A ClusterRole with nodes/proxy resource access allows a user to perform anything the kubelet API allows. It also allows users to...
Restrict Escalation Verbs Roles
The verbs impersonate, bind, and escalate may all potentially lead to privilege escalation and should be tightly controlled. This...
Restrict Wildcard Resources
Wildcards (*) in resources grant access to all of the resources referenced by the given API group and does not follow the...
Check Unauthentication
The usage of --allow-unauthenticated flag in a Dockerfile is generally not recommended because it disables the validation of...
Check Certificate Validation Curl
The --insecure option with the curl command tells curl to bypass SSL certificate verification. This includes the risk of...
Check Certificate Validation Nodejs-env-var
NODE_TLS_REJECT_UNAUTHORIZED is an environment variable used in Node.js to control TLS certificate verification behavior. This...
Check Certificate Validation pip3
In pip3, the --trusted-host flag allows you to mark a specific host as trusted, even if it’s not included in the list of...
Check Certificate Validation Python-env-var
The PYTHONHTTPSVERIFY environment variable is used in Python to control certificate verification when making HTTPS requests. This...
Check Certificate Validation Wget
When the --no-check-certificate option is used with wget, wget gets instructed to ignore SSL certificate verification while making...
Check Last User
The last USER instruction in the Dockerfile is what determines the default user for the container when it starts. This policy...
Check Missing Signature Options
–nodigest, –nosignature, –noverify, –nofiledigest options are flags that can used with the rpm command to alter its behavior...
Check Nogpgcheck
GPG signature checking is a security feature that verifies the authenticity and integrity of packages before they are installed on...
Check NPM Config Strict SSL
The NPM_CONFIG_STRICT_SSL environment variable is used to control strict SSL certificate validation behavior in npm. This policy...
Check Untrust Flag
The use of --allow-untrusted flag in a Dockerfile is generally not recommended. Allowing untrusted packages can introduce security...
Detect Multiple Instructions
This policy is implemented to ensure that container images are built with minimal cached layers. It specifically focuses on...
Disallow Sudo Operations
The usage of sudo within a Dockerfile is generally not preferred due to several reasons, primarily to avoid potential security...
Prefer Copy Over Add
This policy ensures that container images are built using commands that result in known outcomes. Specifically, it advocates for...
Validate Base Image Tag
Ensuring the use of version tags and digests instead of the latest image tag in a Dockerfile is crucial for maintaining control,...
Validate Expose Port 22
Exposing port 22 in a Dockerfile can pose security risks by potentially allowing unauthorized access to the containerized system....
Validate Healthcheck Instruction
Ensuring the presence and proper configuration of the HEALTHCHECK instruction in a Dockerfile is crucial for maintaining the...
Validate User Instruction
Ensuring the presence and proper configuration of the USER instruction in a Dockerfile is essential for enhancing the security...
Compliance
Policy packs mapped to CIS Benchmarks, NIST 800-53, ISO 27001, NSA/CISA Kubernetes Hardening Guidance, SOC 2, and PCI-DSS....
Terraform
Kyverno JSON policies for Terraform plans, configurations, and state files. Enforce infrastructure-as-code security and compliance...
GitHub Actions
Policies for securing GitHub Actions workflows. Enforce pinned action versions, restrict permissions, prevent secret exposure, and...
AI Policies
Kyverno policies for governing AI agents and workflows. Includes prompt safety rules, AI skill authorization policies, and the AI...
Image Verification
Policies for enforcing container image signing and provenance. Require Cosign or Notary signatures, verify image attestations, and...
Cost Management
Policies for controlling Kubernetes resource costs. Enforce resource requests and limits, restrict expensive instance types,...
Multitenancy
Policies for enforcing namespace isolation and multi-tenant Kubernetes cluster standards. Require resource quotas, network...
Workload Security
Runtime security policies for Kubernetes workloads. Enforce security contexts, restrict dangerous capabilities, control volume...
Cloud / EKS
Policies for cloud-managed Kubernetes clusters. Covers AWS EKS best practices, cloud controller configuration, and cloud-specific...
Best Practices
General Kubernetes best practice policies. Enforce labels, probes, image tags, anti-affinity rules, and other operational...
Nirmata provides curated Policy Sets that map to various industry standards for running Kubernetes clusters following best practices.
All policies are available at https://github.com/nirmata/kyverno-policies and are licensed under the GNU Affero General Public License v3.0 (AGPL-3.0). See the Licensing page for details.
Writing Custom Policies
Refer to the official documentation to learn the policy constructs and syntax.
Policy Conventions
The Nirmata Control Hub relies heavily on policy annotations to display relevant information to users and to support certain workflows, such as displaying Remediation Suggestions and diffs. To ensure custom policies integrate seamlessly with Nirmata Control Hub, adhere to the following conventions.
Display Policy Category
policies.kyverno.io/category
Use this annotation to display the Category in the Policy Reports page. Example,
policies.kyverno.io/category: Pod Security Standards (Baseline)
Sample policy: disallow-host-namespaces.yaml
Display Findings Description
policies.kyverno.io/description
Use this annotation to display more info about the policy in the findings details page. Example,
policies.kyverno.io/description: >-
Host namespaces (Process ID namespace, Inter-Process Communication namespace, and
network namespace) allow access to shared information and can be used to elevate
privileges. Pods should not be allowed access to host namespaces. This policy ensures
fields which make use of these host namespaces are unset or set to `false`.
Sample policy: disallow-host-namespaces.yaml
Display Findings Severity
policies.kyverno.io/severity
Use this annotation to display the severity of a finding. Example,
policies.kyverno.io/severity:medium
Sample policy: disallow-host-namespaces.yaml
Display Fix Recommendations
policies.nirmata.io/remediation-docs
Use this annotation to link to external/internal web pages that contain more information on the policy, its impact, and how to fix in case of violations. Example,
policies.nirmata.io/remediation-docs: "https://docs.nirmata.io/policysets/podsecurity/baseline/disallow-host-namespaces/"
Sample policy: disallow-host-namespaces.yaml
Provide Remediation Suggestion (Diff)
policies.nirmata.io/remediation
Use this annotation to link to a Kyverno mutate policy that is used for computing remediation diffs for violations. Example,
policies.nirmata.io/remediation: "https://github.com/nirmata/kyverno-policies/tree/main/pod-security/baseline/disallow-host-namespaces/remediate-disallow-host-namespaces.yaml"
Sample policy: disallow-host-namespaces.yaml
Adding Analyzer Binding to Kyverno JSON Policy
Add this binding to the match block: $analyzer.resource.type
Use the analyzer binding to let NCTL know what the policy is for. Example,
($analyzer.resource.type): terraform-config
Similarly, if the policy is for a terraform plan, terraform state, or dockerfile, the analyzer is terraform-plan, terraform-state, or dockerfile respectively.
Sample policy: enable-kms-encryption.yaml