Kubernetes Privileged Pod Created
editKubernetes Privileged Pod Created
editThis rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node’s resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.
Rule type: query
Rule indices:
- logs-kubernetes.*
Severity: medium
Risk score: 47
Runs every: 5 minutes
Searches indices from: now-6m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Elastic
- Kubernetes
- Continuous Monitoring
- Execution
- Privilege Escalation Added (Elastic Stack release): 8.4.0
Last modified (Elastic Stack release): 8.4.0
Rule authors: Elastic
Rule license: Elastic License v2
Potential false positives
editBy 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. An administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster.
Investigation guide
editRule query
editkubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:create and kubernetes.audit.requestObject.spec .containers.securityContext.privileged:true
Threat mapping
editFramework: MITRE ATT&CKTM
-
Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
-
Technique:
- Name: Escape to Host
- ID: T1611
- Reference URL: https://attack.mitre.org/techniques/T1611/