Skip to content

Kyverno Policy Overview📜

The following tables describe the Kyverno Policies implemented in this repo.

References:

Name Type Scope Category Background Description CIS 1.6 Ref Notes
clone-configs Generate ConfigMap; Secret Helper Configuration held in ConfigMaps or Secrets, like registry credentials, often need to exist in multiple Namespaces so Pods there have access. Manually duplicating these is time consuming and error prone. Copies ConfigMaps or Secrets to new Namespaces when they are created. Will also push updates should the source be changed.
disallow-annotations Validate Pod Best Practices Some annotations control functionality driven by other cluster-wide tools and are not normally set by some class of users. Prevents the use of annotations contained in the specified list. Ensures users either don’t set reserved annotations or use a newer version of annotations.
disallow-auto-mount-service-account-token Validate Pod; ServiceAccount Best Practices Automouting of Kubernetes API credentials is not ideal in all circumstances. Prevents the use of Pods and Service Accounts that automount kubernetes api credentials.
disallow-deprecated-apis Validate Various Best Practices Kubernetes APIs are sometimes deprecated and removed after a few releases. As a best practice, older API versions should be replaced with newer versions. Validates API are not deprecated. Should be run as audit
disallow-host-namespaces Validate Pod Pod Security Standards (Baseline) Host namespaces (Process ID, Inter-Process Communication, and network) allow access to shared information and can be used to elevate privileges. Pods should not be allowed access to host namespaces. Ensures fields (hostPID, hostIPC, and hostNetwork) which make use of these host namespaces are set to false. 5.2.2, 5.2.3, 5.2.4
disallow-image-tags Validate Pod Best Practices Mutable tags, like ‘latest’, can lead to unexpected errors if the image changes. A best practice is to use an immutable tag that maps to a specific version of an application Pod. Validates that the image tag is defined and is not in the disallowed list
disallow-istio-injection-bypass Validate Pod Best Practices (Security) The Istio service mesh uses a sidecar to encrypt traffic. Unless an application is managing its own encrypted traffic, Istio should be used. Validates that pods do not have the sidecar.istio.io/inject label set to false.
disallow-labels Validate Pod Best Practices Some labels control functionality driven by other cluster-wide tools and are not normally set by some class of users. Prevents the use of labels contained in the specified list. Ensures users either don’t set reserved labels or use a newer version of labels.
disallow-namespaces Validate Pod Best Practices (Security) Kubernetes Namespaces are an optional feature that provide a way to segment and isolate cluster resources across multiple applications and users. As a best practice, workloads should be isolated with Namespaces. Namespaces should be required and the default (empty) Namespace should not be used. Validates that Pods specify a namespace that is not in the disallow list. 5.7.1, 5.7.4
disallow-nodeport-services Validate Service Best Practices (Security) A Kubernetes Service of type NodePort uses a host port to receive traffic from any source. A NetworkPolicy cannot be used to control traffic to host ports. Although NodePort Services can be useful, their use must be limited to Services with additional upstream security checks. Validates that any new Services do not use the NodePort type.
disallow-pod-exec Validate Pod Best Practices (Security) The exec and attach command may be used to gain shell access, or run other commands, in a container. While this can be useful for troubleshooting purposes, it could represent an attack vector and is discouraged. Only allows Pod exec and attach commands to Pods in the specified list of namespaces.
disallow-privilege-escalation Validate Pod Pod Security Standards (Restricted) Privilege escalation, such as via set-user-ID or set-group-ID file mode, should not be allowed. Ensures allowPrivilegeEscalation is either undefined or set to false. 5.2.5
disallow-privileged-containers Validate Pod Pod Security Standards (Baseline) Privileged mode disables most security mechanisms and must not be allowed. Ensures Pods do not call for privileged mode (privileged must be undefined or false). 5.2.1
disallow-rbac-on-default-serviceaccounts Validate RoleBinding; ClusterRoleBinding Best Practices (Security) By default, pods are run using the automatically created default ServiceAccount in the pod’s namespace. The default service account has no permissions other than those of an unauthenticated user. To enforce the least privilege best practice, additional permissions should not be allowed on the default service account. Blocks role binding to default service accounts. 5.1.5
disallow-selinux-options Validate Pod Pod Security Standards (Baseline) SELinux options can be used to escalate privileges. Ensures that the seLinuxOptions used are not in the disallowed list. Should be paired with restrict-selinux-type
disallow-tolerations Validate Pod; RuntimeClass Best Practices (Security) Taints and tolerations provide one mechanism to allow fine-grained control of the placement of pods on a specific set of nodes. To permit the Kubernetes scheduler to place a pod on a node with a taint, you can add a toleration to the pod’s specification. If a taint is used to restrict a node to critical pods only, tolerations that match the taint should not be allowed in unauthorized pods. Block pods with tolerations, including global, that match the specified list of taints
exception-require-non-root-group Validate Pod; Containers Helper There are certain processes that require root group priveledges to perform tasks that non-root groups cannot. Allow the listed resources to run as root-group.
exception-require-non-root-user Validate Pod; Containers Helper There are certain processes that require root user priveledges to perform tasks that non-root users cannot. Allow the listed resources to run as root-user.
require-annotations Validate Pod Best Practices Some annotations control functionality that is needed for cluster-wide tools to function. Requires the use of annotations and values contained in the specified list.
require-cpu-limit Validate Pod Best Practices (Security) As application workloads share cluster resources, it is important to limit CPU resources in containers to prevent resource exhaustion and denial-of-service. Validates that all containers have CPU limits defined and the value is in the specified range.
require-drop-all-capabilities Validate Pod Pod Security Standards (Restricted) Capabilities permit privileged actions without giving full root access. All capabilities should be dropped from a Pod, with only those required added back. Ensures that all containers explicitly specify drop: ["ALL"]. 5.2.7, 5.2.9 Use with restrict-capabilities
require-image-signature VerifyImage Pod Best Practices (Security) Using the Cosign project, OCI images may be signed to ensure supply chain security is maintained. Those signatures can be verified before pulling into a cluster. Checks the signature to ensure it has been signed by verifying its signature against the public key.
require-istio-on-namespaces Validate Namespace Best Practices (Security) The Istio service mesh uses a sidecar to encrypt traffic. Unless an application is managing its own encrypted traffic, Istio should be used. Validates that the istio-injection label is set to enabled on namespace resources.
require-labels Validate Pod Best Practices A common set of labels on resources allows tools to work interoperably, describing objects in a common manner that all tools can understand and query. Validates that the labels and values specified in the required list are present.
require-memory-limit Validate Pod Best Practices (Security) As application workloads share cluster resources, it is important to limit memory resources in containers to prevent resource exhaustion and denial-of-service. Validates that all containers have memory limits defined and the value is within the specified range.
require-non-root-group Pod Validate Pod Security Standards (Restricted) Following the least privilege principle, access to the root group ID should be forbidden in containers Ensures containers are running with groups (runAsGroup, fsGroup, and supplementalGroups) > 0.
require-non-root-user Pod Validate Pod Security Standards (Restricted) Following the least privilege principle, containers should not be run as root Ensures containers have runAsNonRoot set to true and runAsUser > 0. 5.2.6
require-probes Validate Pod Best Practices Liveness and readiness probes need to be configured to correctly manage a Pod’s lifecycle during deployments, restarts, and upgrades. For each Pod, a periodic livenessProbe is performed by the kubelet to determine if the Pod’s containers are running or need to be restarted. A readinessProbe is used by Services and Deployments to determine if the Pod is ready to receive network traffic. Validates that all containers have liveness and readiness probes by ensuring the periodSeconds field is greater than zero.
require-requests-equal-limits Validate Pod Best Practices Pods which have limits equal to requests are given a Guaranteed quality of service class which is the highest schedulable class. The Kubernetes scheduler assigns Guaranteed pods only to nodes which have enough resources to fulfil their CPU and memory requests. In addition, Guaranteed pods are the last to be evicted when a node is running low on resources. Checks that all containers have memory requests equal to limits to get a Guaranteed QoS class. Should only be assigned to critical resources.
require-ro-rootfs Validate Pod Best Practices (Security) A read-only root file system helps to enforce an immutable infrastructure strategy. Containers should only need to write to mounted volumes that persist state or cache data. An immutable root filesystem can also prevent malicious binaries from writing to the host system. Validates that containers define a securityContext with readOnlyRootFilesystem: true.
restrict-apparmor Validate Pod Pod Security Standards (Baseline) AppArmor is used as an access control framework. AppArmor uses the runtime/default profile by default. Ensures Pods do not override the AppArmor profile with values outside of the specified list Applies to Debian Linux distros only.
restrict-capabilities Validate Pod Pod Security Standards (Restricted) Capabilities permit privileged actions without giving full root access. Adding capabilities beyond the default set must not be allowed. Ensures users cannot add additional capabilities beyond the specified list to a Pod. 5.2.7, 5.2.8, 5.2.9 Use with require-drop-all-capabilities
restrict-external-ips Validate Service Vulnerability Service externalIPs can be used for a MITM attack. Restricts externalIPs to a specified list. CVE-2020-8554
restrict-external-names Validate Service Vulnerability Service external names can be used for a MITM attack. External names can be used by an attacker to point back to localhost or internal IP addresses for exploitation. Restricts services using external names to a specified list. CVE-2020-8554
restrict-group-id Validate Pod Best Practices (Security) Processes inside a pod can be given group permissions by setting runAsGroup or supplementalGroups. Volume mounts can be mounted as a specific group using fsGroup. Group IDs below 1000 are generally reserved for system accounts, services, and special accounts. Restricts group IDs to the specified list of values Use with require-non-root-group to validate runAsGroup is defined.
restrict-host-path-mount Validate Pod Best Practices (Security) hostPath volumes consume the underlying node’s file system. If hostPath volumes are not universally disabled, they should be restricted to specific host paths to prevent access to sensitive information. Ensures that hostPath volume paths are in the specified list. Strongly recommended to pair this with another to require readOnly on hostPath volumes.
restrict-host-path-mount-pv Validate PersistentVolume Best Practices (Security) PV using hostPath consume the underlying node’s file system. If not universally disabled,they should be restricted to specific host paths to prevent access to sensitive information. Ensures that PV hostPath volume paths are in the specified list. Strongly recommended to pair this with another to require readOnly on hostPath volumes.
restrict-host-path-write Validate Pod Best Practices (Security) hostPath volumes consume the underlying node’s file system. If hostPath volumes are not universally disabled, they should be required to be read-only. Pods which are allowed to mount hostPath volumes in read/write mode pose a security risk even if confined to a “safe” file system on the host and may escape those confines. Checks containers for hostPath volumes and validates they are explicitly mounted in readOnly mode. Strongly recommended to pair this with another to restrict the path of hostPath volumes to a known list.
restrict-host-ports Validate Pod Pod Security Standards (Baseline) Access to host ports allows potential snooping of network traffic and should not be allowed, or at minimum restricted to a known list. Ensures only approved ports are defined in container’s hostPort field
restrict-image-registries Validate Pod Best Practices (Security) Images from unknown, public registries can be of dubious quality and may not be scanned and secured, representing a high degree of risk. Requiring use of known, approved registries helps reduce threat exposure by ensuring image pulls only come from them. Validates that all images originate from a registry in the approved list
restrict-proc-mount Validate Pod Pod Security Standards (Baseline) The default /proc masks are set up to reduce the attack surface and should be required. Ensures nothing but the specified procMount values can be used.
restrict-seccomp Validate Pod Pod Security Standards (Baseline) The SecComp profile should not be explicitly set to Unconfined. Ensures that the seccompProfile.Type is undefined or restricted to the values in the specified list. 5.7.2
restrict-selinux-type Validate Pod Pod Security Standards (Baseline) SELinux options can be used to escalate privileges. Ensures that the seLinuxOptions type field is undefined or restricted to the specified list. Should be paired with disallow-selinux-options.
restrict-sysctls Validate Pod Pod Security Standards (Baseline) Sysctl can disable security mechanisms or affect all containers on a host, and should be restricted to a specified “safe” subset. A sysctl is considered safe if it is namespaced and is isolated from other Pods and processes on the same Node. Ensures that all sysctls used are in the specified list.
restrict-user-id Validate Pod Best Practices (Security) Processes inside a pod can be made to run with a specific user ID by setting runAsUser. User IDs below 1000 are generally reserved for system accounts, services, and special accounts. Restricts user IDs to the specified list of values.
restrict-volume-types Validate Pod Pod Security Standards (Restricted) Volume types, beyond the core set, should be restricted to limit exposure to potential vulnerabilities in Container Storage Interface (CSI) drivers. In addition, HostPath volumes should not be allowed because host directories could be exploited to access shared data or escalate privileges. Restricts use of volume types to the specified list.
update-automountserviceaccounttokens-default Mutate ServiceAccount Best Practices (Security) Kubernetes automatically mounts API credentials in each Pod using the service account. Under the least privilege best practice, the default service account should not have access to the Kuberenetes API. This helps to prevent exploitation of API vulnerabilities. Adds configuration to pods so that the service account token is not automatically mounted. (automountServiceAccountToken: false) 5.1.6
update-automountserviceaccounttokens Mutate ServiceAccount; Pod Best Practices (Security) When an application does not need to access the service account directly, Kubernetes administrators should ensure that Pod specifications disable the secret token being mounted. This policy contains three rules, one that applies to the serviceaccount to disable automounting the token and another two rules that apply to the pod that will override the serviceaccount setting because the pod truly needs or doesn’t need access to the API. NOTE The default serviceaccount is not included here and must mutated differently 5.1.6
update-image-pull-policy mutate Pod Helper If mutable tags (e.g. latest) are used for images, it may be desirable to to have the imagePullPolicy set to Always to ensure that future pulls will get the latest image. Adds or modifies the imagePullPolicy to set it to the desired value on all tagged images. Images using digests are ignored.
update-image-registry Mutate Pod Helper It is common practice to pull images from a local proxy or approved registry. Will mutate existing image registries so pulls are directed to desired registries.

Default settings📜

The following criteria were used to determine if a policy should be enabled, and if enabled, should be enforcing.

  1. All vulnerability policies will be enabled and enforcing
  2. All Pod Security Standard policies will be enabled and enforcing
  3. Validation policies for security or cluster stability (e.g. deprecated APIs) best practices will be enabled and auditing.
  4. Other best practice policies will be disabled.
  5. Helper policies will be disabled.

These are the default settings for this Helm chart. This list is not a recommendation on how to set the policies. Each policy should be evaluated and used appropriately if it has value.

Last update: 2024-02-20 by Bulat Khamitov