About workload configuration scanning

Stay organized with collections Save and categorize content based on your preferences.

This page show you how to detect security common security configuration concerns in your workloads across your Google Kubernetes Engine (GKE) clusters by using workload configuration scanning in the security posture dashboard. GKE returns scored, actionable results to improve your security posture.

For instructions to enable and use workload configuration scanning, refer to Automatically scan workloads for configuration issues.

Why use workload configuration scanning

The workloads that you deploy on GKE should ideally have a hardened configuration that limits their attack surface. Checking workloads across clusters for configuration issues can be difficult to do manually at scale. You can use the security posture dashboard to automatically scan the configuration of all your running workloads across multiple clusters and return actionable, scored results and opinionated recommendations to improve your security posture.

Workload configuration scanning checks each deployed workload against a subset of policies in the Pod Security Standards. Workload configuration scanning happens on Google's infrastructure and doesn't use compute resources on your nodes.

Benefits of workload configuration scanning

  • Automate detection of known configuration concerns across all workloads.
  • Get actionable recommendations to improve security posture.
  • Use the Google Cloud console to get a high-level view of configuration concerns.
  • Use Logging to get an auditable trail of concerns for better reporting and observability.


Workload configuration scanning is offered at no extra charge in GKE.

Entries added to Cloud Logging are subject to Cloud Logging pricing.

How workload configuration scanning works

For each eligible deployed workload, GKE continuously scans the workload's specification and compares the fields and values to the controls defined in the underlying security policy. For example, a Pod with spec.containers.securityContext.privileged=true violates the Baseline Pod Security Standard, and a Pod with the spec.securityContext.runAsNonRoot field set to false violates the Restricted standard. For a list of the security policies that GKE checks, refer to What does workload configuration scanning check?.

After scanning and discovering concerns, GKE rates the severity of discovered configuration issues based on the built-in security hardening measures. GKE assigns a severity rating that can inform the speed with which you respond to the concern. The Google Cloud console displays the results and recommended actions you can take to fix the concerns. GKE also adds entries to Cloud Logging for tracing and auditing.

What does workload configuration scanning check?

Concern Fields Allowed values Severity

Host namespaces

Pods that share host namespaces allow Pod processes to communicate with host processes and gather host information, which could lead to a container escape.

  • spec.hostNetwork
  • spec.hostIPC
  • spec.hostPID
  • Undefined or nil
  • false

Privileged containers

Privileged containers allow nearly unrestricted host access. They share namespaces with the host, and lack control group, seccomp, AppArmor, and capability restrictions.

  • spec.containers[*].securityContext.privileged
  • spec.initContainers[*].securityContext.privileged
  • spec.ephemeralContainers[*].securityContext.privileged
  • Undefined or nil
  • false

Host port access

Exposing a host port to a container potentially allows the container to intercept network traffic to a host service using that port or to bypass network access control rules, such as the rules in a NetworkPolicy.

  • spec.containers[*].ports[*].hostPort
  • spec.initContainers[*].ports[*].hostPort
  • spec.ephemeralContainers[*].ports[*].hostPort
  • Undefined or nil
  • 0

Non-default capabilities

A container has assigned capabilities that could allow a container escape.

  • spec.containers[*].securityContext.capabilities.add
  • spec.initContainers[*].securityContext.capabilities.add
  • spec.ephemeralContainers[*].securityContext.capabilities.add
  • Undefined or nil
  • KILL

Mounting host path volumes

hostPath volumes mount files or directories from the host. These volumes present security risks that could lead to container escape.

spec.volumes[*].hostPath Undefined or nil Medium

Non-default /proc mask

The default /proc mount type masks certain paths in /proc to avoid exposure of paths that could lead to information leakage or container escape. Using a non-default type increases these risks.

  • spec.containers[*].securityContext.procMount
  • spec.initContainers[*].securityContext.procMount
  • spec.ephemeralContainers[*].securityContext.procMount
  • Undefined or nil
  • Default

Unsafe sysctls mask

A Pod can be configured to allow modification of unsafe kernel parameters using the /proc/sys virtual file system. Unsafe parameters don't support namespacing, don't properly isolate their effect between Pods, could harm the node's health, or might allow the Pod to gain resources beyond its limits.

  • Undefined or nil
  • kernel.shm_rmid_forced
  • net.ipv4.ip_local_port_range
  • net.ipv4.ip_unprivileged_port_start
  • net.ipv4.tcp_syncookies
  • net.ipv4.ping_group_range

Running as non-root

You can explicitly allow a container to run as the root user if the runAsUser or the USER directive in the image specifies the root user. The lack of preventive security controls when running as the root user increases the risk of container escape.

  • spec.securityContext.runAsNonRoot
  • spec.containers[*].securityContext.runAsNonRoot
  • spec.initContainers[*].securityContext.runAsNonRoot
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot
true Medium

Privilege escalation

A container can be explicitly configured to allow privilege escalation on execution. This permits a process created within the container by executing a set-user-id, set-group-id, or file capability executable to gain the privileges specified by the executable. The lack of preventive security control increases the risk of container escape.

  • spec.containers[*].securityContext.allowPrivilegeEscalation
  • spec.initContainers[*].securityContext.allowPrivilegeEscalation
  • spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
false Medium

Unconfined AppArmor profile

A container can be explicitly configured to be unconfined by AppArmor. This ensures that no AppArmor profile is applied to the container and is thus not constrained by them. The disabled preventive security control increases the risk of container escape.

metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"] false Low

What's next