About GKE threat detection

This page describes GKE threat detection, which lets you scan your eligible GKE clusters for active threats in the GKE security posture dashboard. The GKE security posture dashboard lets you enable various scanning and auditing capabilities in eligible GKE clusters and displays actionable recommendations to help you resolve security issues.

How it works

GKE threat detection is an advanced GKE security posture dashboard capability that's available to GKE Enterprise users. When your GKE clusters are registered in a fleet, GKE threat detection evaluates your GKE audit logs in Cloud Logging against a set of predefined rules for cluster and workload threats. If a threat is found, you see a finding in the GKE security posture dashboard with a description of the threat, the potential impact, and recommended actions to mitigate the threat.

All enrolled GKE clusters across your fleet are continuously scanned for active threats. We classify detected threats using MITRE ATT&CK® tactics.

GKE threat detection is powered by the Security Command Center Event Threat Detection service. In the GKE security posture dashboard, only the subset of rules that apply to GKE are evaluated.

Included GKE security posture features

GKE threat detection is bundled with the advanced tier of Kubernetes security posture scanning. When you activate GKE threat detection in a cluster, you also activate the following scanning features:

Usage as part of a broad security strategy

GKE threat detection is one of various security observability products that you should use in your environment. We strongly recommend that you use other features of the GKE security posture dashboard, like vulnerability scanning, to ensure that you're monitoring your clusters for a range of security issues. For more information, see About the security posture dashboard in the GKE documentation.

We also recommend that you implement as many security measures from Harden your cluster security as you can in your clusters and workloads.

Pricing

GKE threat detection is offered at no extra cost through GKE Enterprise.

GKE threat detection predefined rules

The following table describes the evaluation rules against which GKE threat detection evaluates your GKE audit logs:

Display name API name Log source types Description
Defense Evasion: Breakglass Workload Deployment Created (Preview) BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_CREATE Cloud Audit Logs:
Admin Activity logs 		Detects the deployment of workloads that are deployed by using the break-glass flag to override Binary Authorization controls.
Defense Evasion: Breakglass Workload Deployment Updated (Preview) BINARY_AUTHORIZATION_BREAKGLASS_WORKLOAD_UPDATE Cloud Audit Logs:
Admin Activity logs 		Detects when workloads are updated by using the break-glass flag to override Binary Authorization controls.
Discovery: Can get sensitive Kubernetes object check GKE_CONTROL_PLANE_CAN_GET_SENSITIVE_OBJECT Cloud Audit Logs:
GKE Data Access logs

A potentially malicious actor attempted to determine what sensitive objects in GKE they can query for, by using the kubectl auth can-i get command. Specifically, the rule detects whether the actor checked for API access on the following objects:

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects GKE_CONTROL_PLANE_EDIT_SENSITIVE_RBAC_OBJECT Cloud Audit Logs:
GKE Admin Activity logs 		To escalate privilege, a potentially malicious actor attempted to modify a ClusterRole, RoleBinding, or ClusterRoleBinding role-based access control (RBAC) object of the sensitive cluster-admin role by using a PUT or PATCH request.
Privilege Escalation: Create Kubernetes CSR for master cert GKE_CONTROL_PLANE_CSR_FOR_MASTER_CERT Cloud Audit Logs:
GKE Admin Activity logs 		A potentially malicious actor created a Kubernetes master certificate signing request (CSR), which gives them cluster-admin access.
Privilege Escalation: Creation of sensitive Kubernetes bindings GKE_CONTROL_PLANE_CREATE_SENSITIVE_BINDING Cloud Audit Logs:
IAM Admin Activity audit logs 		To escalate privilege, a potentially malicious actor attempted to create a new RoleBinding or ClusterRoleBinding object for the cluster-admin role.
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials GKE_CONTROL_PLANE_GET_CSR_WITH_COMPROMISED_BOOTSTRAP_CREDENTIALS Cloud Audit Logs:
GKE Data Access logs 		A potentially malicious actor queried for a certificate signing request (CSR), with the kubectl command, using compromised bootstrap credentials.
Privilege Escalation: Launch of privileged Kubernetes container GKE_CONTROL_PLANE_LAUNCH_PRIVILEGED_CONTAINER Cloud Audit Logs:
GKE Admin Activity logs

A potentially malicious actor created a Pod that contains privileged containers or containers with privilege escalation capabilities.

A privileged container has the privileged field set to true. A container with privilege escalation capabilities has the allowPrivilegeEscalation field set to true. For more information, see the SecurityContext v1 core API reference in the Kubernetes documentation.

Credential Access: Secrets Accessed In Kubernetes Namespace SECRETS_ACCESSED_IN_KUBERNETES_NAMESPACE Cloud Audit Logs:
GKE Data Access logs 		Detects when secrets or service account tokens are accessed by a service account in the current Kubernetes namespace.
Initial Access: Anonymous GKE Resource Created from the Internet (Preview) GKE_RESOURCE_CREATED_ANONYMOUSLY_FROM_INTERNET Cloud Audit Logs:
GKE Admin Activity logs 		Detects resource creation events from effectively anonymous internet users.
Initial Access: GKE Resource Modified Anonymously from the Internet (Preview) GKE_RESOURCE_MODIFIED_ANONYMOUSLY_FROM_INTERNET Cloud Audit Logs:
GKE Admin Activity logs 		Detects resource manipulation events from effectively anonymous internet users.
Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access (Preview) GKE_ANONYMOUS_USERS_GRANTED_ACCESS Cloud Audit Logs:
GKE Admin Activity logs

Someone created an RBAC binding that references one of the following users or groups:

  • system:anonymous
  • system:unauthenticated
  • system:authenticated

These users and groups are effectively anonymous and should be avoided when creating role bindings or cluster role bindings to any RBAC roles. Review the binding to ensure that it is necessary. If the binding isn't necessary, remove it.

Execution: Suspicious Exec or Attach to a System Pod (Preview) GKE_SUSPICIOUS_EXEC_ATTACH Cloud Audit Logs:
GKE Admin Activity logs 		Someone used the exec or attach commands to get a shell or execute a command on a container running in the kube-system namespace. These methods are sometimes used for legitimate debugging purposes. However, the kube-system namespace is intended for system objects created by Kubernetes, and unexpected command execution or shell creation should be reviewed.
Privilege Escalation: Workload Created with a Sensitive Host Path Mount (Preview) GKE_SENSITIVE_HOSTPATH Cloud Audit Logs:
GKE Admin Activity logs 		Someone created a workload that contains a hostPath volume mount to a sensitive path on the host node's file system. Access to these paths on the host filesystem can be used to access privileged or sensitive information on the node and for container escapes. If possible, don't allow any hostPath volumes in your cluster.
Privilege Escalation: Workload with shareProcessNamespace enabled (Preview) GKE_SHAREPROCESSNAMESPACE_POD Cloud Audit Logs:
GKE Admin Activity logs 		Someone deployed a workload with the shareProcessNamespace option set to true, allowing all containers to share the same Linux process namespace. This could allow an untrusted or compromised container to escalate privileges by accessing and controlling environment variables, memory, and other sensitive data from processes running in other containers.
Privilege Escalation: ClusterRole with Privileged Verbs (Preview) GKE_CLUSTERROLE_PRIVILEGED_VERBS Cloud Audit Logs:
GKE Admin Activity logs 		Someone created an RBAC ClusterRole that contains the bind, escalate, or impersonate verbs. A subject that's bound to a role with these verbs can impersonate other users with higher privileges, bind to additional Roles or ClusterRoles that contain additional permissions, or modify their own ClusterRole permissions. This might lead to those subjects gaining cluster-admin privileges.
Privilege Escalation: ClusterRoleBinding to Privileged Role (Preview) GKE_CRB_CLUSTERROLE_AGGREGATION_CONTROLLER Cloud Audit Logs:
GKE Admin Activity logs 		Someone created an RBAC ClusterRoleBinding that references the default system:controller:clusterrole-aggregation-controller ClusterRole. This default ClusterRole has the escalate verb, which allows subjects to modify the privileges of their own roles, allowing for privilege escalation.
Defense Evasion: Manually Deleted Certificate Signing Request (CSR) (Preview) GKE_MANUALLY_DELETED_CSR Cloud Audit Logs:
GKE Admin Activity logs 		Someone manually deleted a certificate signing request (CSR). CSRs are automatically removed by a garbage collection controller, but malicious actors might manually delete them to evade detection. If the deleted CSR was for an approved and issued certificate, the potentially malicious actor now has an additional authentication method to access the cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged. Kubernetes does not support certificate revocation.
Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR) (Preview) GKE_APPROVE_CSR_FORBIDDEN Cloud Audit Logs:
GKE Admin Activity logs 		Someone attempted to manually approve a certificate signing request (CSR) but the action failed. Creating a certificate for cluster authentication is a common method for attackers to create persistent access to a compromised cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged.
Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR) (Preview) GKE_CSR_APPROVED Cloud Audit Logs:
GKE Admin Activity logs 		Someone manually approved a certificate signing request (CSR). Creating a certificate for cluster authentication is a common method for attackers to create persistent access to a compromised cluster. The permissions associated with the certificate vary depending on which subject they included, but can be highly privileged.
Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments (Preview) GKE_REVERSE_SHELL_POD Cloud Audit Logs:
GKE Admin Activity logs 		Someone created a Pod that contains commands or arguments commonly associated with a reverse shell. Attackers use reverse shells to expand or maintain their initial access to a cluster and to execute arbitrary commands.
Defense Evasion: Potential Kubernetes Pod Masquerading (Preview) GKE_POD_MASQUERADING Cloud Audit Logs:
GKE Admin Activity logs 		Someone deployed a Pod with a naming convention similar to the default workloads that GKE creates for regular cluster operation. This technique is called masquerading.
Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape (Preview) GKE_SUSPICIOUS_EXPLOIT_POD Cloud Audit Logs:
GKE Admin Activity logs 		Someone deployed a Pod with a naming convention similar to common tools used for container escapes or to execute other attacks on the cluster.
Impact: Suspicious Kubernetes Container Names - Coin Mining (Preview) GKE_SUSPICIOUS_CRYPTOMINING_POD Cloud Audit Logs:
GKE Admin Activity logs 		Someone deployed a Pod with a naming convention similar to common cryptocurrency coin miners. This may be an attempt by an attacker who has achieved initial access to the cluster to use the cluster's resources for cryptocurrency mining.

How to enable GKE threat detection

To enable GKE threat detection, you enroll an eligible cluster in the advanced tier of Kubernetes security posture scanning. This also activates all of the capabilities included in the Kubernetes security posture scanning basic tier, like workload configuration auditing and security bulletin surfacing.

To learn more, see Find threats in clusters using GKE threat detection.

Limitations

The following limitations apply to GKE threat detection:

  • Only available in GKE Enterprise
  • Only available for projects in organizations
  • Doesn't support Security Command Center options like configuring data residency
  • Only shows results for clusters that are registered to a fleet
  • GKE retains threat findings that no longer have any associated affected resources for up to 180 days
  • Only shows results for existing clusters. If you delete a cluster, GKE threat detection no longer shows the finding in the GKE security posture dashboard.

What's next