Skip to main content

Kubernetes 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: true
  • 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: 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: 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: true
  • 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: true
  • 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: true
  • 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: 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: 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: 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: 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: true
  • 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
      • Required: true
    • prohibited_ports

      • Type: object
      • Unique: false
      • Required: true
  • Required Parameters: prohibited_named_ports, prohibited_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
      • Required: true
    • approved_ports

      • Type: object
      • Unique: false
      • Required: true
  • Required Parameters: approved_named_ports, approved_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
      • Required: true
    • approved_pod_selectors

      • Type: object
      • Unique: false
      • Required: true
  • 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: true
  • 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
      • Required: true
    • prohibited_ports

      • Type: object
      • Unique: false
      • Required: true
  • Required Parameters: prohibited_named_ports, prohibited_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
      • Required: true
    • approved_ports

      • Type: object
      • Unique: false
      • Required: true
  • Required Parameters: approved_named_ports, approved_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
      • Required: true
    • approved_pod_selectors

      • Type: object
      • Unique: false
      • Required: true
  • 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: 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: 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: 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: 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: 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: 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: 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: true
  • Required Parameters: whitelist


Pod: Restrict hostPorts

Ensure containers access allowed hostPorts only.

Parameters

  • Parameters:

    • host_port_ranges

      • Type: array
      • Unique: true
      • Required: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: true
  • 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: true
  • 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: true
  • 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: 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
      • Required: true
    • fs_group_rule

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


Pod: Restrict Types of Volumes

Ensure resources use volume types from an approved list.

Parameters

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
      • Required: 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: true
  • 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: true
  • 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: 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: 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: 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
      • Required: true
    • min: Minimum priority value allowed

      • Type: number
      • Unique: false
      • Required: true
  • 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
      • Required: true
    • selectors

      • Type: object
      • Unique: false
      • Required: true
  • 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: true
  • Required Parameters: prohibited_keys


Containers: Require CPU Limits

Ensure all containers specify CPU limits.

Parameters

  • Parameters:

    • maximum_cpu_limit

      • Type: string
      • Unique: false
      • Required: true
    • minimum_cpu_limit

      • Type: string
      • Unique: false
      • Required: true
  • Required Parameters: maximum_cpu_limit, minimum_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
      • Required: true
    • minimum_memory_limit

      • Type: string
      • Unique: false
      • Required: true
  • Required Parameters: maximum_memory_limit, minimum_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

  • Parameters:
    • CPULimit

      • Type: object
      • Unique: false

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


Containers: -EXPERIMENTAL- Validate Image Signature with Sigstore Cosign

DO NOT USE IN PRODUCTION. Validate Image Signatures with Cosign. See docs.styra.com/das/systems/kubernetes/cosign for more details.

Details

Prevents deployment of containers that do not have a valid cosign signature. See docs.styra.com/das/systems/kubernetes/cosign for more details.

Parameters

  • Parameters:
    • verification_config

      • Type: string
      • Unique: false

Resource Types


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: true
  • 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
      • Required: 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: 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: true
  • Required Parameters: reclaim_policy


Pod: Restrict sysctls used

Ensure every container uses only allowed sysctls.

Parameters

  • Parameters:

    • allowed_unsafe_sysctls

      • Type: array
      • Unique: true
      • Required: true
    • forbidden_sysctls

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


Pod: Restrict Approved AppArmor Profiles

Ensure resources use AppArmor profiles from an approved list.

Parameters

  • Parameters:

    • whitelist

      • Type: array
      • Unique: true
      • Required: 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
      • Required: true
    • run_as_group_rule

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


Pod: Restrict User IDs

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

Parameters

  • Parameters:

    • user_id_ranges

      • Type: array
      • Unique: true
      • Required: 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: 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: true
  • Required Parameters: whitelist

Resource Types


Pod: Restrict SeLinuxOptions

Ensure resources use only approved SeLinuxOptions.

Parameters

  • Parameters:

    • level

      • Type: string
      • Unique: false
      • Required: true
    • role

      • Type: string
      • Unique: false
      • Required: true
    • type

      • Type: string
      • Unique: false
      • Required: true
    • user

      • Type: string
      • Unique: false
      • Required: true
  • 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: true
  • 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: true
  • 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: true
  • 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: true
  • Required Parameters: labels


Inject OPA & Envoy sidecars into pod

Injects an OPA sidecar to a Pod/Deployment template for objects labeled with the specified label/value. Will default to using the "opa:latest-envoy-rootless" image unless channel overrides are included in the mutation policy file.

Parameters

  • Parameters:
    • channel: Channel

      • Type: string
      • Unique: false
    • config: ConfigMap for OPA

      • Type: string
      • Unique: false
    • config-envoy: ConfigMap for Envoy

      • Type: string
      • Unique: false
    • label: Label to check

      • Type: string
      • Unique: false
    • label-value: Label value to check for

      • Type: string
      • Unique: false
    • use-socket: Use Socket

      • Type: string
      • Unique: false

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

Inject OPA sidecar to Istio pod

Injects an OPA sidecar to a Pod/Deployment template for objects labeled with the specified label/value. Will default to using the "opa:latest-envoy-rootless" image unless channel overrides are included in the mutation policy file.

Parameters

  • Parameters:
    • channel: Channel

      • Type: string
      • Unique: false
    • config: ConfigMap for OPA

      • Type: string
      • Unique: false
    • label: Label to check

      • Type: string
      • Unique: false
    • label-value: Label value to check for

      • Type: string
      • Unique: false

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