Skip to main content

Policy Library Rules

Validating Policy Library Rules Documentation​

Audits: Require HTTPS​

Require HTTPS for dynamic audit webhook backends (AuditSink resources). Using HTTPS ensures network traffic is encrypted.

Parameters​

None

Encryption: Restrict Key Management Service Providers​

Allow only key management service (KMS) providers with approved names and corresponding endpoints.

Parameters​

  • Parameters:

    • approved_kms_configs

      • Type: object
      • Unique: false
  • Required Parameters: approved_kms_configs

Encryption: Require Secrets to be Encrypted​

Prohibit the identity provider from being used to store secret data.

Parameters​

None

Configmaps: Restrict nginx ingress configmap with snippet annotations allowed.​

Prevent Nginx Ingress configmaps with allow-snippet-annotations as true. In multi-tenant clusters, a custom snippet annotation can be used by people with limited permissions to retrieve clusterwide secrets.

Parameters​

None

Resources: Restrict Names​

Resource names must match one of the list of regular expressions. This rule does not apply to names inside of templates.

Parameters​

  • Parameters:

    • required

      • Type: array
      • Unique: true
  • Required Parameters: required

Resource Types​

Namespaces: Restrict Names​

Namespace names must match one of the specified regular expressions.

Parameters​

  • Parameters:

    • approved_names

      • Type: array
      • Unique: true
  • Required Parameters: approved_names

Resources: Require Annotations​

Resources must include specified annotations. This rule does not apply to annotations inside of templates.

Parameters​

  • Parameters:

    • required

      • Type: object
      • Unique: false
  • Required Parameters: required

Resource Types​

Resources: Require Labels​

Resources must include metadata labels specified as key-value pairs. This rule does not apply to labels in templates.

Parameters​

  • Parameters:

    • required

      • Type: object
      • Unique: false
  • Required Parameters: required

Resource Types​

Pods: Require Exclusive Use of Labels​

Require each pod to use one label from a mutually exclusive set of labels. For example, you might define priority: high and priority: low as mutually-exclusive labels.

Parameters​

None

Resources: Require Pod Labels​

All pods must include metadata labels specified as key-value pairs.

Parameters​

  • Parameters:

    • labels

      • Type: object
      • Unique: false
  • Required Parameters: labels

Resource Types​

Services: Prohibit IP Addresses​

Prevent any service’s clusterIP address from being defined within a prohibited IP range.

Parameters​

  • Parameters:

    * blacklist

    : Prohibited IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: blacklist

Services: Restrict IP Addresses​

Require every service’s clusterIP address to be included in the approved IP address range.

Parameters​

  • Parameters:

    * whitelist

    : Approved IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: whitelist

Ingresses: Deny custom snippet annotations.​

Prevent Ingress resources with a custom snippet annotation from being created or updated. In multi-tenant clusters, a custom snippet annotation can be used by people with limited permissions to retrieve clusterwide secrets.

Parameters​

None

Ingresses: Restrict Ingress with default Ingress-class.​

Ensure that every Ingress reource is created with an ingress-class other than the default eg. use annotation kubernetes.io/ingress.class: nginx-internal.

Parameters​

None

Loadbalancer: Prohibit loadBalancerSourceRanges​

Loadbalancer resources must not allow traffic from the provided IP ranges.

Parameters​

  • Parameters:

    * blacklist

    : Blacklisted IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: blacklist

Loadbalancer: Restrict loadBalancerSourceRanges​

Loadbalancer resources should only allow traffic from the provided IP ranges.

Parameters​

  • Parameters:

    * whitelist

    : Approved IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: whitelist

Invariant: Require Complete Network Policy Coverage​

Require all pods to be controlled by network policy and reject any changes to network policy, pods, and templated pods that violate the network policy.

Parameters​

None

Network: Require Complete Network Policy Coverage​

Require all pods to be controlled by network policy and reject NetworkingPolicy changes that leave pods without NetworkingPolicy coverage.

Parameters​

None

Container: Require Complete Network Policy Coverage for Pods​

Require all pods to be controlled by a NetworkPolicy and reject any pod that is not controlled by a NetworkPolicy.

Parameters​

None

Container: Require Complete Network Policy Coverage for Templated Pods​

Require all pods to be controlled by a NetworkPolicy and reject any template that produces a pod that is not controlled by a NetworkPolicy.

Parameters​

None

Egresses: Prohibit Namespace Selectors​

Prevent NetworkPolicy resources from defining any egress rules with prohibited namespace selectors.

Parameters​

  • Parameters:

    • prohibited_namespace_selectors

      • Type: object
      • Unique: false
  • Required Parameters: prohibited_namespace_selectors

Egresses: Prohibit Ports​

Prevent NetworkPolicy resources from defining any egress rules with prohibited ports.

Parameters​

  • Parameters:

    • prohibited_named_ports

      • Type: object
      • Unique: false

    • prohibited_ports

      • Type: object
      • Unique: false
  • Required Parameters: prohibited_ports, prohibited_named_ports

Egresses: Restrict Ports​

Expect every egress ports field to match the specified list of protocol-port pairs.

Parameters​

  • Parameters:

    • approved_named_ports

      • Type: object
      • Unique: false

    • approved_ports

      • Type: object
      • Unique: false
  • Required Parameters: approved_ports, approved_named_ports

Egresses: Restrict Selectors​

Require NetworkPolicy resources to define egress rules with approved namespace and pod selectors.

Parameters​

  • Parameters:

    • approved_namespace_selectors

      • Type: object
      • Unique: false

    • approved_pod_selectors

      • Type: object
      • Unique: false
  • Required Parameters: approved_namespace_selectors, approved_pod_selectors

Ingresses: Prohibit Namespace Selectors​

Prevent NetworkPolicy resources from defining any ingress rules with prohibited namespace selectors.

Parameters​

  • Parameters:

    • prohibited_namespace_selectors

      • Type: object
      • Unique: false
  • Required Parameters: prohibited_namespace_selectors

Ingresses: Prohibit Ports​

Prevent NetworkPolicy resources from defining any inbound (ingress) rules that use prohibited ports.

Parameters​

  • Parameters:

    • prohibited_named_ports

      • Type: object
      • Unique: false

    • prohibited_ports

      • Type: object
      • Unique: false
  • Required Parameters: prohibited_ports, prohibited_named_ports

Ingresses: Restrict Ports​

Require every ingress ports field to match the list of specified protocol-port pairs.

Parameters​

  • Parameters:

    • approved_named_ports

      • Type: object
      • Unique: false

    • approved_ports

      • Type: object
      • Unique: false
  • Required Parameters: approved_ports, approved_named_ports

Ingresses: Restrict Namespace and Pod Selectors​

Require NetworkPolicy resources define ingress rules that include approved namespace selectors and pod selectors.

Parameters​

  • Parameters:

    • approved_namespace_selectors

      • Type: object
      • Unique: false

    • approved_pod_selectors

      • Type: object
      • Unique: false
  • Required Parameters: approved_namespace_selectors, approved_pod_selectors

Services: Prohibit External Load Balancers​

Prevent services from creating cloud network load balancers.

Parameters​

None

Container: Restrict Ports​

Ensure containers listen only on allowed ports.

Parameters​

  • Parameters:

    • container_port_numbers

      • Type: array
      • Unique: true
  • Required Parameters: container_port_numbers

Service: Restrict Ports​

Ensure services listen only on allowed ports.

Parameters​

  • Parameters:

    • port_numbers

      • Type: array
      • Unique: true
  • Required Parameters: port_numbers

kubectl exec: Restrict Commands​

Allows users to whitelist commands that may be used with “kubectl exec”

Parameters​

  • Parameters:

    • allowed_commands

      • Type: array
      • Unique: true
  • Required Parameters: allowed_commands

Egresses: Prohibit IP Blocks​

Prevent NetworkPolicy resources from defining any egress rules within prohibited IP address ranges.

Parameters​

  • Parameters:

    * blacklist

    : Prohibited IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: blacklist

Egresses: Restrict IP Blocks​

Require that NetworkPolicy resources define egress rules only within approved IP address ranges.

Parameters​

  • Parameters:

    * whitelist

    : Approved IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: whitelist

Pod: Prohibit Containers From Sharing HostPID or HostIPC Namespace​

Expect hostPID and hostIPC to be set to false.

Parameters​

None

Resource Types​

Ingresses: Restrict Hostnames​

Require ingress hostnames to match one of the globs you specify.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Ingresses: Prohibit IP Blocks​

Prevent NetworkPolicy resources from defining any ingress rules that allow traffic on IP addresses in the prohibited ranges you specify.

Parameters​

  • Parameters:

    * blacklist

    : Prohibited IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: blacklist

Ingresses: Restrict IP Blocks​

Require NetworkPolicy resources to define ingress rules that only allow traffic within the IP address ranges you specify.

Parameters​

  • Parameters:

    * whitelist

    : Approved IP address ranges

        * **Type**: array
        * **Unique**: true
  • Required Parameters: whitelist

Pod: Restrict hostPorts​

Ensure containers access allowed hostPorts only.

Parameters​

  • Parameters:

    • host_port_ranges

      • Type: array
      • Unique: true
  • Required Parameters: host_port_ranges

Ingresses: Prohibit Host Conflicts​

Ensure that no two ingresses are configured to use the same hostname. This rule is not compatible with mock OPAs.

Parameters​

None

Ingresses: Prohibit Host Path Conflicts​

Ensure that no two ingresses are configured to use the same hostname and overlapping paths. Path conflicts are detected using prefix matching. This rule is not compatible with mock OPAs.

Parameters​

None

Ingresses: Require TLS​

Require all ingresses to have Transport Layer Security (TLS) configured.

Parameters​

None

Role-Based Access Control (RBAC): Restrict Roles to Protect OPA Webhook​

Allow an approved list of ClusterRoles with permissions of create, update, or delete validatingwebhookconfigurations, mutatingwebhookconfigurations kinds.

Parameters​

  • Parameters:

    • approved_roles

      • Type: array
      • Unique: true
  • Required Parameters: approved_roles

Service Accounts: Prohibit Namespaces​

Prevent service accounts from being created or updated in prohibited namespaces.

Parameters​

  • Parameters:

    • prohibited_namespaces

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_namespaces

Audits: Restrict Groups​

Allow dynamic audit webhook backends (AuditSink resources) to be created only by approved groups.

Parameters​

  • Parameters:

    • approved_groups

      • Type: array
      • Unique: true
  • Required Parameters: approved_groups

Audits: Restrict Users​

Allow dynamic audit webhook backends (AuditSink resources) to be created only by approved users.

Parameters​

  • Parameters:

    • approved_users

      • Type: array
      • Unique: true
  • Required Parameters: approved_users

Encryption: Restrict Configuration to Specific Groups​

Allow encryption to be configured only by approved groups.

Parameters​

  • Parameters:

    • approved_groups

      • Type: array
      • Unique: true
  • Required Parameters: approved_groups

Encryption: Restrict Configuration to Specific Users​

Allow encryption to be configured only by approved users.

Parameters​

  • Parameters:

    • approved_users

      • Type: array
      • Unique: true
  • Required Parameters: approved_users

Cluster Role Bindings: Prohibit Built-In Role Modifications​

Prevent privileged built-in roles, such as admin and cluster-admin, from being modified.

Parameters​

None

Cluster Roles: Prohibit Updates from Specified Users​

Prevent the specified users from creating or updating cluster roles.

Parameters​

  • Parameters:

    • prohibited_users

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_users

Cluster Roles: Restrict Updates to Approved Users​

Allow only the approved users to create or update cluster roles.

Parameters​

  • Parameters:

    • approved_users

      • Type: array
      • Unique: true
  • Required Parameters: approved_users

Cluster Roles: Prohibit Wildcard API Groups​

Require cluster roles to be granted access to specific API groups without using wildcards.

Parameters​

None

Cluster Roles: Prohibit Wildcard Resources​

Require cluster roles to be granted access to each resource without using wildcards.

Parameters​

None

Cluster Roles: Prohibit Wildcard Verbs​

Require cluster roles to be granted access to each API verb without using wildcards.

Parameters​

None

Cluster Role Bindings: Prohibit Cluster Roles​

Prevent cluster role bindings from using prohibited roles.

Parameters​

  • Parameters:

    • prohibited_roles

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_roles

Cluster Role Bindings: Prohibit Wildcard User/Group Names​

Require cluster roles to have each user and group assigned without using wildcards.

Parameters​

None

Roles: Prohibit Pod Shell Access​

Prohibit roles and cluster roles from being created with the capability to access pod shells.

Parameters​

None

Roles: Prohibit Wildcard API Groups​

Require roles to be granted access to specific API groups without using wildcards.

Parameters​

None

Roles: Prohibit Wildcard Resources​

Require roles to be granted access to each resource without using wildcards.

Parameters​

None

Roles: Prohibit Wildcard Verbs​

Require roles to be granted access to each API verb without using wildcards.

Parameters​

None

Cluster Roles: Prohibit Name Prefixes​

Prevent cluster roles from being created with specific name prefixes such as system.

Parameters​

  • Parameters:

    • prohibited_name_prefixes

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_name_prefixes

Role Bindings: Prohibit Cluster Roles​

Prevent role bindings from using prohibited ClusterRoles.

Parameters​

  • Parameters:

    • prohibited_roles

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_roles

NetworkPolicy: Restrict Operations to Specified Users​

Require that only specified users be allowed to perform specific operations.

Parameters​

  • Parameters:

    • approved_users

      • Type: object
      • Unique: false
  • Required Parameters: approved_users

Storage: Restrict Persistent Volume Storage Classes​

Require every persistent volume claim to use an approved storage class and (optionally) an approved access mode (ReadOnlyMany, ReadWriteMany, ReadWriteOnce).

Details​

Every persistent volume claim can specify a storage class and an access mode (ReadOnlyMany, ReadWriteMany, ReadWriteOnce). If no class is specified by the claim, the default storage class will be used.

Parameters​

  • Parameters:

    • classes

      • Type: object
      • Unique: false
  • Required Parameters: classes

Resource Types​

Storage: Require Persistent Volume Encryption​

Require persistent volume claims to request storage only from an encrypting storage class.

Parameters​

None

Resource Types​

Storage: Restrict Network File System (NFS) Mount Points​

Require every NFS mount to use an approved mount path.

Details​

Any NFS volume mounted into a pod may only use a mount point specified by a whitelist.

Parameters​

  • Parameters:

    • approved_mount_points

      • Type: object
      • Unique: false
  • Required Parameters: approved_mount_points

Resource Types​

Pod: Restrict FlexVolumes​

Ensure resources use FlexVolume drivers from an approved list.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Resource Types​

Pod: Restrict FsGroup​

Ensure resources use FsGroup from an approved whitelist.

Parameters​

  • Parameters:

    • fs_group_ranges

      • Type: array
      • Unique: true

    • fs_group_rule

      • Type: string
      • Unique: false
  • Required Parameters: fs_group_rule, fs_group_ranges

Pod: Restrict Types of Volumes​

Ensure resources use volume types from an approved list.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Resource Types​

Nodes: Prohibit Master Workloads​

Prevent workloads from being deployed to master nodes.

Parameters​

None

Resource Types​

Nodes: Prohibit nodeName-based Workload Assignment​

Prevent workloads from specifying nodeName to exploit direct scheduling

Parameters​

None

Resource Types​

Containers: Prohibit Images (Blocklist - Exact)​

Prohibit container images from specified registries (Host) and (optionally) from specified repository image paths.

Parameters​

  • Parameters:

    • blocklist

      • Type: object
      • Unique: false
  • Required Parameters: blocklist

Resource Types​

Containers: Prohibit Images (Blocklist - Globs)​

Prohibit container images from specified registries (Host) and repository paths specified as a path with optional wildcard globs.

Parameters​

  • Parameters:

    • blocklist

      • Type: object
      • Unique: false
  • Required Parameters: blocklist

Resource Types​

Pods: Prohibit Mounting of ConfigMap Resources​

Prevent pods from referencing ConfigMap resources that contain the restricted keys you specify.

Parameters​

  • Parameters:

    • prohibited_keys

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_keys

Containers: Deny workloads which are using default service account​

Ensure all containers must not use default service account.

Parameters​

None

Pods: Prohibit Specified Host Paths​

Prevent volumes from accessing prohibited paths on the host node’s file system.

Parameters​

  • Parameters:

    * prohibited_host_paths

    : Use glob patterns to specify the host paths that cannot be accessed.

        * **Type**: array
        * **Unique**: true
  • Required Parameters: prohibited_host_paths

Containers: Prohibit windowsOptions HostProcess​

Restrict containers which contains windowsOptions HostProcess.

Parameters​

None

Resource Types​

Resources: Require Valid Replicas​

Expect Resources to specify a minimum valid replica count (default: 1). The default minimum count can be changed by specifying it in the parameter.

Parameters​

  • Parameters:

    * replica_count

    : Value (Example: 2)

        * **Type**: number
        * **Unique**: false

Resource Types​

Namespace: Prohibit Namespace Changes​

Prevent changes from being made to a list of specified namespaces.

Parameters​

  • Parameters:

    • prohibited_namespaces

      • Type: array
      • Unique: true
  • Required Parameters: prohibited_namespaces

Pods: Restrict Priority​

Ensure pods use approved minimum and maximum priority values.

Parameters​

  • Parameters:

    * max

    : Maximum priority value allowed

        * **Type**: number
        * **Unique**: false

    * min

    : Minimum priority value allowed

        * **Type**: number
        * **Unique**: false
  • Required Parameters: max, min

Pods: Require Node Selectors​

Ensure a pod specifies node selectors that match an approved list.

Parameters​

  • Parameters:

    • pod

      • Type: string
      • Unique: false

    • selectors

      • Type: object
      • Unique: false
  • Required Parameters: pod, selectors

Storage Classes: Prohibit Retain Reclaim Policy​

Prevent storage classes from using Retain as a reclaim policy.

Parameters​

None

Containers: Deny workloads which are mounting service account token​

Ensure all containers must not mount 'service account token'.

Parameters​

None

Nodes: Prohibit Toleration Keys (Exact)​

Prevent workloads with blacklisted toleration keys from being deployed to specific dedicated nodes.

Parameters​

  • Parameters:

    * prohibited_keys

    : Prohibited toleration keys

        * **Type**: array
        * **Unique**: true
  • Required Parameters: prohibited_keys

Containers: Require CPU Limits​

Ensure all containers specify CPU limits.

Parameters​

  • Parameters:

    • maximum_cpu_limit

      • Type: string
      • Unique: false

    • minimum_cpu_limit

      • Type: string
      • Unique: false
  • Required Parameters: minimum_cpu_limit, maximum_cpu_limit

Containers: Require Memory Limits​

Ensure all containers specify memory limits. Note: Memory limits are specified in units from bytes (example: 512) to exabytes (example: 1.2E or 1.2Ei).

Parameters​

  • Parameters:

    • maximum_memory_limit

      • Type: string
      • Unique: false

    • minimum_memory_limit

      • Type: string
      • Unique: false
  • Required Parameters: minimum_memory_limit, maximum_memory_limit

Containers: Check For Liveness Probe​

Ensure every container sets a liveness probe.

Parameters​

  • Parameters:

    * periodSecondsMin

    : Minimum value of how often (in seconds) to perform the probe

        * **Type**: number
        * **Unique**: false

Containers: Prohibit Running as root​

Prevent all containers from running as root (user ID 0).

Parameters​

  • Parameters:

    • exclude

      • Type: object
      • Unique: false

Containers: Check For readiness Probe​

Ensure every container sets a readiness probe.

Parameters​

  • Parameters:

    * periodSecondsMin

    : Minimum value of how often (in seconds) to perform the probe

        * **Type**: number
        * **Unique**: false

Containers: Require Resource Limits​

Ensure all containers specify both CPU and memory limits.

Parameters​

None

Containers: Verify CPU and Memory Requirements​

Ensure all containers specify both CPU and memory requirements.

Details​

Ensures that containers specify at least one of resources.requests (minimum guaranteed) or resources.limits (maximum allowed) for both cpu and memory. A container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than its limit. For more information, see Specify a memory request and a memory limit page.

Parameters​

None

Service: Prohibit NodePort Setting​

Prevents exposing a NodePort (Node IP addresses) for a service.

Parameters​

None

Pod: Restrict Bare Pods​

Prohibit pods without a controller.

Details​

Requires that the pod must belong to one of the controllers like Deployment, ReplicaSet, Job, CronJob, DaemonSet, StatefulSet

Parameters​

None

Containers: Restrict Images (Globs)​

Restrict container images to images pulled from specified registries (Host) and repository paths specified as a path with optional wildcard globs.

Parameters​

  • Parameters:

    • whitelist

      • Type: object
      • Unique: false
  • Required Parameters: whitelist

Resource Types​

Containers: Require Liveness Probe​

Ensure every container sets a liveness probe.

Parameters​

  • Parameters:

    * min_period_seconds

    : Minimum interval in seconds to perform probe

        * **Type**: number
        * **Unique**: false

Containers: Require Readiness Probe​

Ensure every container sets a readiness probe.

Parameters​

  • Parameters:

    * min_period_seconds

    : Minimum interval in seconds to perform probe

        * **Type**: number
        * **Unique**: false

Deployment: Require Update Strategy​

Ensure that an approved update strategy is specified for every deployment.

Parameters​

  • Parameters:

    * max_surge_min

    : Specify the minimum number of Pods that can be created during an update (above the number of Pods required during normal operation).

        * **Type**: string
        * **Unique**: false

    * max_unavailable_min

        * **Type**: string
        * **Unique**: false

    * update_strategy

        * **Type**: string
        * **Unique**: false

Containers: Prohibit :latest Image Tag​

Prohibit container images that use the :latest tag.

Details​

Prevents deployment of containers that use the :latest tag to ensure you can determine the version of the image currently running and can roll back properly, if needed.

Parameters​

None

Resource Types​

Containers: Prohibit Privileged Mode​

Prevent containers from running in privileged mode.

Parameters​

None

Containers: Prohibit Privileged Mode for Init Containers​

Prevent init containers from running in privileged mode.

Parameters​

None

Containers: Prohibit Privileged Mode for Regular Containers​

Prevent Regular containers from running in privileged mode.

Parameters​

None

Containers: Always Pull Images​

Ensure every container sets its imagePullPolicy to Always.

Parameters​

None

Pods: Prohibit All Host Paths​

Ensure pods don't have access on the host node’s file system.

Parameters​

None

Containers: Prohibit Insecure Baseline Profile Capabilities​

Restrict unauthorized capabilities set in the securityContext.capabilities.add section.

Parameters​

None

Resource Types​

Containers: Prohibit Insecure Capabilities​

Ensure that unauthorized capabilities aren’t set in any container’s securityContext.capabilities.add section and are set in the corresponding drop section.

Parameters​

  • Parameters:

    • capabilities

      • Type: array
      • Unique: true

    • exclude

      • Type: object
      • Unique: false
  • Required Parameters: capabilities

Containers: Require Non-default Namespace​

Ensure that a container cannot be started in the Kubernetes default namespace.

Parameters​

None

Pods: Prohibit Host Network Access​

Prevent pods from accessing the host network, including the host loopback device.

Parameters​

None

Containers: Restrict Host Paths​

Ensure every container’s volumeMounts.mountPath property includes only an approved host path.

Parameters​

  • Parameters:

    • allowed

      • Type: array
      • Unique: true
  • Required Parameters: allowed

Containers: Disallow privilege escalation​

Expect allowPrivilegeEscalation to be set to false

Parameters​

None

Containers: Prohibit Insecure Capabilities (Restricted Profile)​

Ensure containers drop 'ALL' capabilities and only add the 'NET_BIND_SERVICE' capability in the securityContext.capabilities.add and securityContext.capabilities.drop sections.

Parameters​

None

Resource Types​

Containers: Restrict Unapproved Seccomp Profiles​

Ensure that no resources are set to unapproved Seccomp Profiles

Parameters​

None

Resource Types​

Containers: Restrict Reclaim Policies​

Ensure containers requesting persistent storage do so with an approved reclaim policy.

Details​

To handle containers with persistent volume claims but without an explicitly-set storage class request, the DefaultStorageClass admission plugin has to run before the ValidatingAdmissionWebhook.

Parameters​

  • Parameters:

    • reclaim_policy

      • Type: string
      • Unique: false
  • Required Parameters: reclaim_policy

Pod: Restrict sysctls used​

Ensure every container uses only allowed sysctls.

Parameters​

  • Parameters:

    • allowed_unsafe_sysctls

      • Type: array
      • Unique: true

    • forbidden_sysctls

      • Type: array
      • Unique: true
  • Required Parameters: forbidden_sysctls, allowed_unsafe_sysctls

Pod: Restrict Approved AppArmor Profiles​

Ensure resources use AppArmor profiles from an approved list.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Resource Types​

Containers: Must run as non-root​

Ensure containers must not run as root (MustRunAsNonRoot).

Details​

Requires that the pod be run with runAsNonRoot assigned true or with runAsUser assigned a non-zero value. When neither runAsUser nor runAsNonRoot are specified, the request will be denied.

Parameters​

None

Resource Types​

Pod: Restrict Group IDs​

Ensure containers run with an approved group ID or, if run_as_group_rule is MayRunAs, no group ID.

Parameters​

  • Parameters:

    • group_id_ranges

      • Type: array
      • Unique: true

    • run_as_group_rule

      • Type: string
      • Unique: false
  • Required Parameters: run_as_group_rule, group_id_ranges

Pod: Restrict User IDs​

Ensure containers run with an approved user ID (MustRunAs).

Parameters​

  • Parameters:

    • user_id_ranges

      • Type: array
      • Unique: true
  • Required Parameters: user_id_ranges

Containers: Restrict Approved ProcMount Type​

Ensure containers use an approved procMount type.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Resource Types​

Pod: Restrict Seccomp Profiles​

Ensure resources use Seccomp profiles from an approved list.

Parameters​

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
  • Required Parameters: whitelist

Resource Types​

Pod: Restrict SeLinuxOptions​

Ensure resources use only approved SeLinuxOptions.

Parameters​

  • Parameters:

    • level

      • Type: string
      • Unique: false

    • role

      • Type: string
      • Unique: false

    • type

      • Type: string
      • Unique: false

    • user

      • Type: string
      • Unique: false
  • Required Parameters: level, role, type, user

Resource Types​

Containers: Require Resource Requests​

Ensure all containers specify both CPU and memory requests.

Details​

Ensures that containers specify the resources.requests (minimum guaranteed) configuration setting for both cpu and memory.

Parameters​

None

Containers: Require Read-Only File Systems​

Ensure every container’s root file system is read-only.

Details​

This policy covers both cases in which (1) readOnlyRootFilesystem is not defined and (2) readOnlyRootFilesystem is false.

Parameters​

None

Containers: Restrict Images (Exact)​

Restrict container images to images pulled from specified registries (Host) and (optionally) from specified repository image paths.

Parameters​

  • Parameters:

    • whitelist

      • Type: object
      • Unique: false
  • Required Parameters: whitelist

Resource Types​

Mutating Policy Library Rules Documentation​

Containers: Add Default CPU Limit​

Ensures that the container memory limit is set to a default value unless otherwise specified.

Parameters​

  • Parameters:

    • cpu_limit

      • Type: string
      • Unique: false
  • Required Parameters: cpu_limit

Containers: Add Default Memory Limit​

Ensures that the container memory limit is set to a default value unless otherwise specified.

Parameters​

  • Parameters:

    • memory_limit

      • Type: string
      • Unique: false
  • Required Parameters: memory_limit

Inject Missing Labels​

Ensures that the named set of labels exist; any missing label will be added with its corresponding default value.

Parameters​

  • Parameters:

    • labels

      • Type: object
      • Unique: false
  • Required Parameters: labels

Resources: Add Namespace Labels to Resource​

Ensures that the designated namespace labels are copied to all resources.

Parameters​

  • Parameters:

    • labels_to_add

      • Type: array
      • Unique: true

    • labels_to_override

      • Type: array
      • Unique: true

Always Pull Images if Latest​

If container image uses :latest tag, ensure its imagePullPolicy is set to Always.

Parameters​

None

Compliance Packs Policy Library Rules Documentation​

Best Practices​

Parameters​

None

1.1​

Avoid using the :latest tag when deploying containers because it is difficult to determine which version of the image is running and it is difficult to roll back properly.

Policies applicable:​

  • block_latest_image_tag

1.2​

Select container capabilities to reduce root user privileges thereby decreasing risk of exploits. Linux typically allows the root user (or any process running with user ID 0) to bypass all kernel permission checks. Modern Linux kernels (starting with version 2.2) divide such privileged access into distinct units known as “capabilities” so that they can be selectively enabled and disabled.

Policies applicable:​

  • deny_capabilities_in_blacklist

1.3​

Don’t allow containers to enable privileged mode. A privileged container has nearly the same access as a process running directly on a host node, which means that the container can access the host’s filesystem, manipulate its network stack, load kernel modules, and otherwise subtly control the host node.

Policies applicable:​

  • block_privileged_mode

1.4​

Require containers to specify the CPU and memory resources they need. Containers that don’t specify their resource requirements run with unbounded limits. This results in a single pod which may be scheduled on a node with insufficient resources and other pods may be throttled unexpectedly.

Policies applicable:​

  • expect_container_resource_requests

1.5​

Only allow pods to mount known directories and files from the host filesystem. Otherwise, you risk a container reading or modifying privileged files.

Policies applicable:​

  • deny_host_path_not_in_whitelist

1.6​

Only allow containers to use images you trust. Because of the vast supply of publicly accessible container images, it is extremely easy to deploy all kinds of software. However, not all images are created with equal accuracy and safety. Therefore, it is important to know (a) which images satisfy your requirements (functional, security, and legal) and (b) guarantee that containers run only those images you have vetted.

Policies applicable:​

  • repository_unsafe_exact

1.7​

Control how container state is handled after your containers exit.

Policies applicable:​

  • deny_unexpected_reclaim_policy

2.1​

Restrict inbound and outbound traffic to only what is necessary for your application, and specifically deny all other traffic. Communication between trusted and untrusted environments should be limited to prevent malicious or unwitting individuals from compromising sensitive applications, confidential data, or both.

Policies applicable:​

  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist
  • deny_ingress_ip_block_not_in_whitelist
  • deny_ingress_ip_block_in_blacklist

3.1​

Don’t allow conflicting ingress routes. Conflicting routes typically arise when two or more teams who share the same Kubernetes cluster create Ingress resources that define overlapping hosts, paths, or both. Since the Kubernetes Ingress API doesn’t define how to handle conflicts, the resulting behavior is unpredictable and may result in outages or other service issues.

Policies applicable:​

  • ingress_host_conflict
  • ingress_hostpath_conflict

3.2​

Secure ingress containers. Specifying TLS parameters ensures that Ingress controllers secure communication so that it is private and protected against threats such as a man-in-the-middle attack.

Policies applicable:​

  • ingress_missing_tls

3.3​

Only allow services to use approved hostnames to define ingress routes. Domain Name system(DNS) is hard enough to configure correctly without worrying about incremental changes. Guaranteeing that ingress routes use a hostname from a verified list mitigates chances for misconfiguration.

Policies applicable:​

  • deny_ingress_hostname_not_in_whitelist

CIS Benchmarks​

Parameters​

None

1.2.12 AlwaysPullImages​

Ensure that all pods have AlwaysPullImages set to true.

Policies applicable:​

  • check_image_pull_policy

1.2.16 Privileged​

Ensure that no container in any pod can enable privileged mode. By default, a container is not allowed to access any devices on the host, but a privileged container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. This is useful for containers that want to use Linux capabilities like manipulating the network stack and accessing devices.

Policies applicable:​

  • block_privileged_mode

1.2.16 HostNetwork​

Ensure pods may not use the node network namespace. Using the node network namespace gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node.

Policies applicable:​

  • deny_host_network

1.2.16 HostPorts​

Explicitly restrict the ranges of allowable ports in the host network namespace. Restricting access to known ports limits the containers networking capabilities outside of its known function. This rule requires the list of approved host ports that may be used. An empty list means there is no restriction on host ports used.

Policies applicable:​

  • enforce_pod_hostports_whitelist

1.2.16 AllowedHostPaths​

Explicitly restrict the paths on a host that may be mounted into a pod. Mounting paths on a host gives the pod access to the underlying file system and the data contained therein. Restricting which paths can be mounted protects the data and in the filesystem and therefore the other containers running on that host. This rule requires the list of approved host paths that may be mounted as volumes. An empty list means there is no restriction on host paths used.

Policies applicable:​

  • deny_host_path_not_in_whitelist

1.2.16 ReadOnlyRootFilesystem​

Ensures that the containers run with a read-only root filesystem. A read-only root filesystem prevents an attacker from tampering with the local filesystem or writing malicious binaries to disk.

Policies applicable:​

  • missing_read_only_filesystem

1.2.16 AllowPrivilegeEscalation​

Prohibit a container to create a child process with more privileges than its parent. Escalated privileges would allow a container to perform more sensitive tasks than would be permitted by the configuration of the container itself, leading to a host of potential security problems.

Policies applicable:​

  • deny_privilege_escalation

1.2.16 AllowedFlexVolumes​

Ensure that workloads only use an approved FlexVolume driver. This rule requires the list of approved flex volume drivers. An empty list means there is no restriction.

Policies applicable:​

  • enforce_pod_flex_volume_drivers_whitelist

1.2.16 Volumes​

Ensures that workloads can be created only with an approved volume type. This rule requires the list of approved volume types. An empty list means there is no restriction.

Policies applicable:​

  • enforce_pod_volume_type_whitelist

1.2.16 denyHostNamespaceSharing​

Ensure pods may not share the host namespace. Sharing the host namespace allows the processes running in a container to communicate with other processes running on the host. This reduces isolation and processes in container can perform tasks as if these are running natively on the host.

Policies applicable:​

  • deny_host_namespace_sharing

1.2.16 AllowedProcMountTypes​

Ensures that containers can be created with approved Proc Mount types only.

Policies applicable:​

  • enforce_proc_mount_type_whitelist

1.2.16 RequiredDropCapabilities​

Ensure pods drop all the linux capabilities that are not required. Linux Capabilities provide a fine grained breakdown of privileges traditionally associated with root user. Some of the capabilities can be used to escalate privileges or for container breakout. All capabilities that are not required must be dropped from a pod.

Policies applicable:​

  • deny_capabilities_in_blacklist

RestrictSysctls​

Ensures that no resource (pod, deployment, replicaset) can be created with forbidden and unsafe Sysctl. Sysctl is used to modify kernel parameters at runtime. Sysctl can be used to disable security mechanisms or interfere with other containers on a host. All sysctls should be disabled except for a safe subset.

Policies applicable:​

  • deny_unsafe_and_forbidden_sysctls

1.2.16 MustRunAsNonRoot​

Ensures that containers can not be run as root (MustRunAsNonRoot). Running a container as root may allow a non-root user to gain elevated access to the host.

Policies applicable:​

  • enforce_container_mustrunasnonroot

1.2.16 SeccompProfiles​

Ensures that containers can be created with approved seccomp profiles only. Seccomp can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel.

Policies applicable:​

  • enforce_seccomp_profile_whitelist

1.2.16 AppArmorProfiles​

Ensures that containers can be created with approved AppArmor profiles only. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions and so on.

Policies applicable:​

  • enforce_app_armor_profile_whitelist

1.2.16 RunAsUser​

Ensures that containers can be run with an approved runAsUser only. This allows the administrator to better control the privileges granted to a user in container.

Policies applicable:​

  • enforce_pod_runas_userid_rule_whitelist

1.2.16 RunAsGroup​

Ensures that containers can be run with an approved runAsGroup only. This allows the administrator to better control the privileges granted to a user in a container.

Policies applicable:​

  • enforce_pod_runas_groupid_rule_whitelist

1.2.16 FsGroupRule​

Ensures that pods can be created with an approved FSGroup only.

Policies applicable:​

  • enforce_pod_fsgroup_rule_whitelist

1.2.16 SeLinuxOptions​

Ensures that containers can be created with approved SeLinuxOptions. SELinux defines access controls for the applications, processes, and files on a system. It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to enforce the access allowed by a policy.

Policies applicable:​

  • enforce_selinux_options_whitelist

5.1.5 DenyDefaultServiceAccount​

Ensure that a container does not use a default service account.

Policies applicable:​

  • deny_default_service_account

5.1.6 DenyMountServiceAccountToken​

Ensure that a container must not mount service account token. Mounting service account tokens inside pods can provide an avenue for privilege escalation attacks where an attacker is able to compromise a single pod in the cluster.

Policies applicable:​

  • deny_service_account_token_mount

5.7.4 NoDefaultNamespace​

Ensure that a container cannot be started in the Kubernetes default namespace. Using a specific namespace allows for better isolation through fine tuned network policies, resource quotas and service accounts.

Policies applicable:​

  • deny_default_namespace

MITRE ATT&CK​

Parameters​

None

T1190 Exploit Public-Facing Application​

Adversaries may attempt to take advantage of weaknesses in a public facing website. Mitigate the risk by properly isolating the application, using least privilege principle and network segmentation by separating externally facing services from rest of the network.

Policies applicable:​

  • block_privileged_mode
  • enforce_container_mustrunasnonroot
  • deny_privilege_escalation
  • missing_label
  • restrict_external_lbs
  • invalid_naming_convention_namespace
  • netpol_ingress_label_selector_whitelist
  • ingress_host_conflict
  • ingress_hostpath_conflict
  • netpol_ingress_entity_src_namespace_not_in_blacklist
  • netpol_ingress_entity_src_port_whitelist
  • netpol_ingress_entity_src_port_blacklist
  • deny_ingress_ip_block_not_in_whitelist
  • deny_ingress_ip_block_in_blacklist
  • netpol_egress_label_selector_whitelist
  • netpol_egress_entity_src_namespace_not_in_blacklist
  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist
  • deny_default_namespace
  • ingress_missing_tls

T1199 Trusted Relationship​

Adversaries may breach or otherwise leverage valid accounts used by a trusted third party to access internal network systems. Mitigate the risk by restricting the permissions for a user account or service account to minimum necessary (For example, no wildcards in roles, restric pod exec)

Policies applicable:​

  • block_privileged_mode
  • enforce_container_mustrunasnonroot
  • deny_privilege_escalation
  • deny_clusterrole_create_wildcard_verbs
  • deny_clusterrole_create_non_whitelist_userinfo
  • deny_clusterrolebinding_create_deny_subject_wildcard
  • deny_cluster_role_binding_sensitive_roles
  • enforce_pod_runas_userid_rule_whitelist
  • enforce_pod_runas_groupid_rule_whitelist

T1525 Implant Internal Image​

Adversaries may implant cloud container images with malicious code to establish persistence. Mitigate the risk by ensuring all images are scanned for vulnerabilities and come from a trusted container registry always.

Policies applicable:​

  • block_repository_glob
  • block_repository_exact
  • block_latest_image_tag
  • check_image_pull_policy

T1562 Impair Defenses​

Adversaries may maliciously modify components of a victim environment in order to hinder or disable defensive mechanisms. Mitigate the risk by ensuring proper file permissions are in place to prevent adversaries from disabling or interfering with security or logging services.

Policies applicable:​

  • deny_host_path_not_in_whitelist
  • missing_read_only_filesystem

T1578 Modify Cloud Compute Infrastructure​

Adversaries may attempt to modify cloud compute service infrastructure to evade defenses. Mitigate the risk by limiting containers interaction with underlying host to its known functions.

Policies applicable:​

  • deny_unsafe_and_forbidden_sysctls
  • deny_capabilities_in_blacklist

T1580 Cloud Infrastructure Discovery​

Adversaries may attempt to discover resources that are available within an platform. This may include instances, storage and so on of other services running on the platform. Mitigate the risk by limiting containers network activity within its known function.

Policies applicable:​

  • deny_host_namespace_sharing
  • deny_host_network
  • enforce_pod_hostports_whitelist

T1046 Network Service Scanning​

Adversaries may attempt to discover services running on other cloud hosts by running port scans. Mitigate this risk by restricting containers network activities to its known functions.

Policies applicable:​

  • deny_host_namespace_sharing
  • deny_host_network
  • enforce_pod_hostports_whitelist
  • deny_default_namespace

T1498 Network Denial of Service​

Adversaries may perform Network Denial of Service(DoS) attack to degrade or block availability of targetted resources to users. Network Denial of Service(DoS) can be performed by exhausting the network bandwidth services rely on. Mitigate the risk by filtering the network traffic.

Policies applicable:​

  • deny_loadbalancersourceranges_in_blacklist
  • deny_loadbalancersourceranges_not_in_whitelist

T1530 Data from Cloud Storage Object​

Adversaries may access data objects from improperly secured cloud storage. Mitigate the risk by using encrypted storage and using appropriate reclaim policy.

Policies applicable:​

  • enforce_encrypt
  • deny_unexpected_reclaim_policy

NIST Container Security​

Parameters​

None

4.4.3 AllowedFlexVolumes​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards.

Policies applicable:​

  • enforce_pod_flex_volume_drivers_whitelist

4.4.3 AppArmorProfiles​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards.

Policies applicable:​

  • enforce_app_armor_profile_whitelist

4.4.3 DenyHostNamespaceSharing​

Ensure pods may not share the host namespace. Sharing the host namespace allows the processes running in a container to communicate with other processes running on the host. Namespace isolation ensures that apps and processes inside a container only access the physical and virtual resources allocated to that container.

Policies applicable:​

  • deny_host_namespace_sharing

4.4.3 HostNetwork​

Ensure pods may not use the node network namespace. Using the node network namespace gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on the network activity of other pods on the same node.

Policies applicable:​

  • deny_host_network

4.4.3 HostPorts​

Provides a whitelist of ranges of allowable ports in the host network namespace. This rule requires the list of approved host ports that may be used. An empty list means there is no restriction on host ports used.

Policies applicable:​

  • enforce_pod_hostports_whitelist

4.4.3 MustRunAsNonRoot​

Ensure containers can not be run as root (MustRunAsNonRoot). Running a container as root may allow a non-root user to gain elevated access to the host.

Policies applicable:​

  • enforce_container_mustrunasnonroot

4.4.3 Privileged​

Ensure to validate and enforce compliance that shows suspicious behaviors such as sensitive mounts, unexpected inbound/outbound activity. By default, a container is not allowed to access any devices on the host, but a privileged container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host.

Policies applicable:​

  • block_privileged_mode

4.4.3 RunAsGroup​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards. Validate and enforce compliance that shows suspicious behaviors such as sensitive mounts, unexpected inbound/outbound activity, and the modification of system binaries.

Policies applicable:​

  • enforce_pod_runas_groupid_rule_whitelist

4.4.3 RunAsUser​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards. Validate and enforce compliance that shows suspicious behaviors such as sensitive mounts, unexpected inbound/outbound activity, and the modification of system binaries.

Policies applicable:​

  • enforce_pod_runas_userid_rule_whitelist

4.4.3 SeccompProfiles​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards.

Policies applicable:​

  • enforce_seccomp_profile_whitelist

4.4.3 SeLinuxOptions​

Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps and automate compliance with container runtime configuration standards.

Policies applicable:​

  • enforce_selinux_options_whitelist

4.4.4 RequiredDropCapabilities​

Ensure pods drop all Linux capabilities that are not required. Linux Capabilities provide a fine-grained breakdown of privileges traditionally associated with the root user. Some of the capabilities can be used to escalate privileges or for container breakout. All capabilities that are not required must be dropped from a pod. Ensure containers are run with the default profiles provided by their runtime and should consider using additional profiles for high-risk apps.

Policies applicable:​

  • deny_capabilities_in_blacklist

4.5.3 RestrictSysctls​

Ensure no resource (pod, deployment, replicaset) can be created with forbidden and unsafe 'Sysctl'. Sysctl is used to modify kernel parameters at runtime. 'Sysctl' can be used to disable security mechanisms or interfere with other containers on a host. All 'sysctls' should be disabled except for a safe subset.

Policies applicable:​

  • deny_unsafe_and_forbidden_sysctls

4.5.4 AllowPrivilegeEscalation​

Ensure all authentication to the OS is audited, login anomalies are monitored, and any escalation to performed privileged operations is logged. This makes it possible to identify anomalous access patterns. Validate and enforce compliance that shows suspicious behaviors such as sensitive mounts, unexpected inbound/outbound activity, and the modification of system binaries.

Policies applicable:​

  • deny_privilege_escalation

4.5.5 AllowedHostPaths​

Ensure containers are run with the minimal set of file system permissions required. Very rarely should containers mount local file systems on a host. This rule specifies a whitelist of host paths that are allowed to be used by hostPath volumes. An empty list means there is no restriction on host paths used.

Policies applicable:​

  • deny_host_path_not_in_whitelist

4.5.5 AllowedProcMountTypes​

Ensure containers are run with the minimal set of file system permissions required. Very rarely should containers mount local file systems on a host.

Policies applicable:​

  • enforce_proc_mount_type_whitelist

4.5.5 FsGroupRule​

Ensure containers are run with the minimal set of file system permissions required. Very rarely should containers mount local file systems on a host.

Policies applicable:​

  • enforce_pod_fsgroup_rule_whitelist

4.5.5 ReadOnlyRootFilesystem​

Containers should run in read-only mode and also need to detect and prevent attacks within containers from events such as Malware storage and Invalid or unexpected process execution and system calls. Ensure containers are run with the minimal set of file system permissions required. Very rarely should containers mount local file systems on a host.

Policies applicable:​

  • missing_read_only_filesystem

4.5.5 Volumes​

Ensure containers are run with the minimal set of file system permissions required. Very rarely should containers mount local file systems on a host.

Policies applicable:​

  • enforce_pod_volume_type_whitelist

PCI DSS v3.2​

Parameters​

None

1.1.1​

A formal process for approving and testing all network connections and changes to the firewall and router configurations.

Details​

NetworkPolicy changes should only be allowed by a whitelist of authorized users.

Policies applicable:​

  • whitelist_resource_owner_networkpolicy

1.1.4​

Requirements for a firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.

Details​

Use namespaces and labels in NetworkPolicy selectors to separate and isolate traffic between the public facing internet, DMZ web and API pods, internal applications, and highly sensitive card holder databases.

Policies applicable:​

  • missing_label
  • restrict_external_lbs

1.1.6​

Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

Details​

Use naming conventions, annotations and labels on pods and in corresponding NetworkPolicy selectors to explicitly identify and control network communication for specific business purposes.

Policies applicable:​

  • invalid_naming_convention
  • missing_label
  • missing_annotation
  • invalid_naming_convention_namespace

1.1.7​

Requirement to review firewall and router rule sets at least every six months.

Details​

Use annotations in NetworkPolicy selectors to explicitly record review status of each NetworkPolicy resource.

Policies applicable:​

  • missing_annotation

1.2​

Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

Details​

Use IP whitelists and blacklists to control network placement. Control ingress resources.

Policies applicable:​

  • deny_cluster_ip_in_blacklist
  • deny_cluster_ip_not_in_whitelist
  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist
  • deny_ingress_hostname_not_in_whitelist

1.2.1​

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Details​

Control ingress resources and use namespaces together with ingress and egress selectors in NetworkPolicies to restrict traffic.

Policies applicable:​

  • ingress_host_conflict
  • ingress_hostpath_conflict
  • netpol_ingress_label_selector_whitelist
  • netpol_ingress_entity_src_namespace_not_in_blacklist
  • netpol_ingress_entity_src_port_whitelist
  • netpol_ingress_entity_src_port_blacklist
  • deny_ingress_ip_block_not_in_whitelist
  • deny_ingress_ip_block_in_blacklist
  • netpol_egress_label_selector_whitelist
  • netpol_egress_entity_src_port_whitelist
  • netpol_egress_entity_src_port_blacklist
  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist

1.3.1​

Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

Details​

Use Service namespaces and labels to apply specific DMZ NetworkPolicies.

Policies applicable:​

  • invalid_naming_convention_namespace
  • missing_label
  • netpol_ingress_label_selector_whitelist

1.3.2​

Limit inbound Internet traffic to IP addresses within the DMZ.

Details​

Use Service namespaces and labels to apply specific DMZ NetworkPolicies.

Policies applicable:​

  • ingress_host_conflict
  • ingress_hostpath_conflict
  • netpol_ingress_label_selector_whitelist
  • netpol_ingress_entity_src_namespace_not_in_blacklist
  • netpol_ingress_entity_src_port_whitelist
  • netpol_ingress_entity_src_port_blacklist
  • deny_ingress_ip_block_not_in_whitelist
  • deny_ingress_ip_block_in_blacklist

1.3.3​

Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.

Details​

NOTE: May be CNI specific Restrict CAP_NET_ADMIN and CAP_NET_RAW capabilities in pods.

Policies applicable:​

  • deny_capabilities_in_blacklist

1.3.4​

Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Details​

Use egress selectors in NetworkPolicies to restrict traffic.

Policies applicable:​

  • netpol_egress_label_selector_whitelist
  • netpol_egress_entity_src_namespace_not_in_blacklist
  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist

1.3.6​

Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

Details​

Use IP address whitelists and blacklists to control network placement. Use ingress whitelists.

Policies applicable:​

  • deny_cluster_ip_in_blacklist
  • deny_cluster_ip_not_in_whitelist
  • deny_egress_ip_block_not_in_whitelist
  • deny_egress_ip_block_in_blacklist
  • deny_ingress_hostname_not_in_whitelist

2.1​

Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

Details​

Implement CIS Benchmark and NIST 800-59 recommendations to harden Kubernetes.

Policies applicable:​

  • blacklist_namespace_serviceaccounts
  • deny_clusterrole_create_wildcard_verbs
  • deny_clusterrole_create_non_whitelist_userinfo
  • deny_clusterrolebinding_create_deny_subject_wildcard
  • deny_clusterrolebinding_create_blacklist_rolename
  • repository_unsafe_exact
  • block_latest_image_tag
  • deny_capabilities_in_blacklist
  • block_privileged_mode
  • deny_namespace_in_blacklist
  • deny_host_path_not_in_whitelist
  • deny_host_path_in_blacklist
  • deny_host_network
  • expect_no_nodeport
  • deny_configmap_items_in_blacklist
  • expect_container_resource_requirements
  • invalid_naming_convention
  • missing_annotation
  • missing_label

2.2.1​

Implement only one primary function per virtual system component.

Details​

Require labels for function with respect to system components that are in scope for PCI DSS, for example: Role/ClusterRole, RoleBinding/ClusterRoleBinding, Deployment, Service, Ingress, ServiceAccount, ConfigMap, Volume, PersistentVolume and so on.

Policies applicable:​

  • missing_label

2.2.2​

Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

Details​

Specify a trusted repository for all images, and specify specific image names corresponding to specific functions of the system, with the minimum necessary services, protocols, daemons, etc. Also restrict mounting paths that are sensitive.

Policies applicable:​

  • repository_unsafe_exact
  • deny_host_path_not_in_whitelist

2.2.3​

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.

Details​

Secure all Ingress resources by specifying a Secret that contains a TLS private key and certificates.

Policies applicable:​

2.2.4​

Configure system security parameters to prevent misuse.

Details​

Require effective PodSecurityPolicies to prevent misuse and lateral movement of attackers.

Policies applicable:​

2.2.5​

Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Details​

Specify trusted repositories and hardened images. Prevent pulling the "latest" from the repository since that can include newly added features that require thoughtful consideration and testing, undesired services and
capabilities that have not been hardened. Only reviewed and tested images should be pulled.

Policies applicable:​

  • repository_unsafe_exact
  • block_latest_image_tag

3.1​

Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes.

Details​

Control how container state is handled after your containers exit. Enforce storage class configuration that supports correct delete functionality. Ensure all containers specify both CPU and memory requirements.

Policies applicable:​

  • expect_container_resource_requirements
  • deny_unexpected_reclaim_policy
  • deny_retain_policy

3.5​

Implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.

Details​

Only allow key management service (KMS) providers with approved names and corresponding endpoints.

Policies applicable:​

  • check_kms_encryptionconfig

3.5.2​

Restrict access to cryptographic keys to the fewest number of custodians necessary.

Details​

Prohibit unencrypted (identity) secret data storage.

Policies applicable:​

  • deny_identity_provider

3.6.1​

Generation of strong cryptographic keys.

Details​

Use annotations to include the algorithms and properties so that strong encryption is enforced.

Policies applicable:​

  • missing_annotation

3.6.3​

Secure cryptographic key storage.

Details​

Only allow key management service (KMS) providers with approved names and corresponding endpoints. Prohibit unencrypted (identity) secret data storage.

Policies applicable:​

  • check_kms_encryptionconfig
  • deny_identity_provider

3.6.5​

Key retirement or replacement.

Details​

Rotation of keys should be performed at defined frequencies. Currently this is a manual process in Kubernetes.
Use Annotations on EncryptionConfigurations and Secrets to clearly identify when keys were last rotated and then monitor for rotation or replacement at specified intervals.

Policies applicable:​

  • missing_annotation

3.6.7​

Prevention of unauthorized substitution of cryptographic keys.

Details​

Only allow encryption configurations to be created by approved users and groups.

Policies applicable:​

  • check_encryptionconfig_user
  • check_encryptionconfig_group

4.1.1​

Ensure networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission.

Details​

Ensure all ingresses have TLS configured.

Policies applicable:​

  • ingress_missing_tls

5.1.1​

Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

Details​

Require the use of trusted and secure repositories and only allow images that have been appropriately scanned for viruses or malware. Also do not pull the latest unscanned image.

Policies applicable:​

  • repository_unsafe_exact
  • block_latest_image_tag

5.2​

Ensure that all anti-virus mechanisms are maintained.

Details​

Require the use of trusted and secure repositories and only allow images that have been appropriately scanned for viruses or malware. Also do not pull the latest unscanned image. Write all malware and antivirus configuration and signature files to read only filesystems.

Policies applicable:​

  • missing_read_only_filesystem
  • repository_unsafe_exact
  • check_image_pull_policy

5.3​

Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users.

Details​

Write all malware and antivirus configuration and signature files to read only filesystems.

Policies applicable:​

  • missing_read_only_filesystem

6.2​

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches.

Details​

Require the use of trusted and secure repositories and only allow images that have been appropriately scanned for vulnerabilities and have the lates security patches.
Also do not pull the latest unscanned image.

Policies applicable:​

  • repository_unsafe_exact
  • block_latest_image_tag

6.3.1​

Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

Details​

Require the use of trusted and secure repositories and only allow images that have been appropriately configured without shared or test user IDs or passwords. Restrict ServiceAccounts in reserved Namespaces. Restrict ClusterRoles with wildcards. Restrict which users and roles can create ClusterRoles. Restrict the storage of usernames or passwords in ConfigMaps.

Policies applicable:​

  • repository_unsafe_exact
  • blacklist_namespace_serviceaccounts
  • deny_clusterrole_create_wildcard_verbs
  • deny_clusterrole_create_non_whitelist_userinfo
  • deny_clusterrolebinding_create_deny_subject_wildcard
  • deny_clusterrolebinding_create_blacklist_rolename
  • deny_configmap_items_in_blacklist

6.4.1​

Separate development/test environments from production environments, and enforce the separation with access controls.

Details​

Use node selectors and tolerations to enforce separation of development and test nodes from production nodes.

Policies applicable:​

  • deny_pod_without_required_node_selectors
  • block_master_toleration
  • deny_toleration_keys_in_blacklist

6.4.2​

Separation of duties between development/test and production environments.

Details​

Enforce labels that identify the function as development, test, or production for all workloads and resources, ie. Pods/StatefulSets/Deployments, Services, Ingresses, Volumes, ConfigMaps, and Secrets. Use these labels for RBAC enforcement.

Policies applicable:​

  • missing_label

6.4.3​

Production data (live PANs) are not used for testing or development

Details​

Enforce labels that identify the function as test or production for all data resources, ie. require labels on PersistentVolumes, PersistentVolumeClaims, Pod/Deployment/StatefulSet. Use these labels to prevent test volumes from being mounted in production workloads.

Policies applicable:​

  • missing_label

6.4.4​

Removal of test data and accounts from system components before the system becomes active / goes into production.

Details​

Enforce labels that identify the function as test or production for all data resources, ie. require labels on PersistentVolumes, PersistentVolumeClaims, Pod/Deployment/StatefulSet. Use these labels to prevent test volumes from being mounted in production workloads. Enforce labels that identify the function as development, test, or production for all workloads and resources, ie. Pods/StatefulSets/Deployments, Services, Ingresses, Volumes, ConfigMaps, and Secrets. Use these labels for RBAC enforcement.

Policies applicable:​

  • missing_label

7.1.2​

Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.

Details​

Require labels on Roles/ClusterRoles for each job responsibility. Minimize privileges assigned to roles (e.g. no wildcards). Restrict reserved or sensitive patterns/prefixes on Roles/ClusterRoles, e.g. "system:". Prohibit roles and cluster roles from being created with the capability to access pod shells.

Policies applicable:​

  • missing_label
  • deny_clusterrole_create_wildcard_verbs
  • deny_role_name_blacklist_prefix
  • deny_role_create_exec_pods

7.1.3​

Assign access based on individual personnel’s job classification and function.

Details​

Require labels on RoleBindings/ClusterRoleBindings for each job responsibility. Deny a ClusterRoleBinding to special "bootstrap" users or other sensitive users, e.g. cluster-admin user.

Policies applicable:​

  • missing_label
  • deny_cluster_role_binding_sensitive_roles

7.2.2​

Assignment of privileges to individuals based on job classification and function.

Details​

Require labels on RoleBindings/ClusterRoleBindings for each job responsibility. Deny a ClusterRoleBinding to special "bootstrap" users or other sensitive users, e.g. cluster-admin user.

Policies applicable:​

  • missing_label
  • deny_cluster_role_binding_sensitive_roles

10.4​

Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

Details​

Require the use of trusted and secure repositories and only allow images that have appropriately configured NTP clients.

Policies applicable:​

  • repository_unsafe_exact

10.5.1​

Limit viewing of assessment trails to those with a job-related need.

Details​

Require the use of trusted and secure repositories and only allow images that have appropriately configured NTP clients.

Policies applicable:​

  • check_audit_sink_user
  • check_audit_sink_group

10.5.2​

Protect assessment trail files from unauthorized modifications.

Details​

Require the use of an off cluster audit sink sending data encrypted via TLS.

Policies applicable:​

  • require_auditsink

Pod Security v2​

Parameters​

None

PrivilegedContainers​

Determines if a container in a pod can enable privileged mode. By default a container is not allowed to access any devices on the host, but a privileged container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. This is useful for containers which need to use linux capabilities like manipulating the network stack and accessing devices. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • block_privileged_mode

ProcMountTypes​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved Proc Mount type. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • enforce_proc_mount_type_whitelist

AppArmorProfiles​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved AppArmor profiles. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • enforce_app_armor_profile_whitelist

BaselineCapabilities​

Ensures no resource (Pod, Deployment, ReplicaSet) are set to insecure capabilities. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_baseline_capabilities

HostNamespaceSharing​

Ensures no resource created (Pod, Deployment, ReplicaSet) can share host namespace. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_host_namespace_sharing

HostNetworkNamespaceSharing​

Controls whether the pod may use the node network namespace. Doing so gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_host_network

HostPorts​

Provides a whitelist of ranges of allowable ports in the host network namespace. Defined as a list of approved ports. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • enforce_pod_hostports_whitelist

HostPathVolumes​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved HostPath Volumes. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_all_host_paths

HostProcess​

Ensures no resource (Pod, Deployment, ReplicaSet, Job) can be created with an unapproved WindowsOption HostProcess. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_host_process

RequiredDropCapabilities​

Ensures containers must not use and must drop user-defined insecure capabilities. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_capabilities_in_blacklist

RestrictSysctls​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with forbidden and unsafe sysctls. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • deny_unsafe_and_forbidden_sysctls

BaselineSeccompProfiles​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved seccomp profiles. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • enforce_seccomp_profile_whitelist

SeLinuxOptions​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with an unapproved seLinuxOptions type. This rule maps to the Pod Security Standards 'Baseline' profile.

Policies applicable:​

  • enforce_selinux_options_whitelist

AllowedFlexVolumes​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved FlexVolume driver. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_pod_flex_volume_drivers_whitelist

PrivilegeEscalation​

Ensures no child process of a container can gain more privileges than its parent. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • deny_privilege_escalation

FsGroupRule​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved FsGroup Rule. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_pod_fsgroup_rule_whitelist

RunAsNonRoot​

Ensures containers can not be run as root (runAsNonRoot). This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_container_mustrunasnonroot

ReadOnlyRootFilesystem​

Requires containers must run with a read-only root filesystem (i.e. no writable layer). This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • missing_read_only_filesystem

RestrictedCapabilities​

Ensures containers drop 'ALL' capabilities and only add the 'NET_BIND_SERVICE' capability. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • deny_restricted_capabilities

RestrictedSeccompProfiles​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with Restricted seccomp profiles. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • deny_seccomp_profiles

RunAsGroup​

Ensures no containers can be run with an unapproved runAsGroup. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_pod_runas_groupid_rule_whitelist

RunAsUser​

Ensures no containers can be run with an unapproved runAsUser. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_pod_runas_userid_rule_whitelist

VolumesTypes​

Ensures no resource (Pod, Deployment, ReplicaSet) can be created with unapproved Volume Types. This rule maps to the Pod Security Standards 'Restricted' profile.

Policies applicable:​

  • enforce_pod_volume_type_whitelist

Pod Security Policies​

Parameters​

None

Privileged​

Determines if any container in a pod can enable privileged mode. By default a container is not allowed to access any devices on the host, but a “privileged” container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices.

Policies applicable:​

  • block_privileged_mode

HostNetwork​

Controls whether the pod may use the node network namespace. Doing so gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node.

Policies applicable:​

  • deny_host_network

HostPorts​

Provides a whitelist of ranges of allowable ports in the host network namespace. Defined as a list of approved ports.

Policies applicable:​

  • enforce_pod_hostports_whitelist

AllowedHostPaths​

This specifies a whitelist of host paths that are allowed to be used by hostPath volumes. An empty list means there is no restriction on host paths used.

Policies applicable:​

  • deny_host_path_not_in_whitelist

ReadOnlyRootFilesystem​

Requires that containers must run with a read-only root filesystem (i.e. no writable layer).

Policies applicable:​

  • missing_read_only_filesystem

AllowPrivilegeEscalation​

Ensures that no child process of a container can gain more privileges than its parent.

Policies applicable:​

  • deny_privilege_escalation

AllowedFlexVolumes​

Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with unapproved FlexVolume driver.

Policies applicable:​

  • enforce_pod_flex_volume_drivers_whitelist

Volumes​

Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with unapproved Volume Types.

Policies applicable:​

  • enforce_pod_volume_type_whitelist

denyHostNamespaceSharing​

Ensures that no containers created (Pod, Deployment, ReplicaSet) can share host namespace.

Policies applicable:​

  • deny_host_namespace_sharing

AllowedProcMountTypes​

Ensures that no container (Pod, Deployment, ReplicaSet) can be created with unapproved Proc Mount type.

Policies applicable:​

  • enforce_proc_mount_type_whitelist

RequiredDropCapabilities​

Requires that containers must not use insecure capabilities and must drop those.

Policies applicable:​

  • deny_capabilities_in_blacklist

RestrictSysctls​

Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with forbidden and unsafe sysctls.

Policies applicable:​

  • deny_unsafe_and_forbidden_sysctls

MustRunAsNonRoot​

Ensures that containers can not be run as root (MustRunAsNonRoot)

Policies applicable:​

  • enforce_container_mustrunasnonroot

SeccompProfiles​

Ensures that no containers (Pod, Deployment, ReplicaSet) can be created with unapproved seccomp profiles.

Policies applicable:​

  • enforce_seccomp_profile_whitelist

AppArmorProfiles​

Ensures that no containers (Pod, Deployment, ReplicaSet) can be created with unapproved AppArmor profiles.

Policies applicable:​

  • enforce_app_armor_profile_whitelist

RunAsUser​

Ensures that no containers can be run with an unapproved runAsUser

Policies applicable:​

  • enforce_pod_runas_userid_rule_whitelist

RunAsGroup​

Ensures that no containers can be run with an unapproved runAsGroup

Policies applicable:​

  • enforce_pod_runas_groupid_rule_whitelist

FsGroupRule​

Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with unapproved FsGroup Rule.

Policies applicable:​

  • enforce_pod_fsgroup_rule_whitelist

SeLinuxOptions​

Ensures that no resource (Pod, Deployment, ReplicaSet) can be created with unapproved SeLinuxOptions Rule.

Policies applicable:​

  • enforce_selinux_options_whitelist