-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Description
This issue was reported in the Kubernetes Security Audit Report
Description
Seccomp is disabled by default for containers configured by kubelet since 1.10.0. This allows configured containers to interact directly with the host kernel. Depending on container privileges, this could lead to extended access to the host beyond limited kernel access.
While there is a Pod security annotation to specify a particular seccomp profile, this does not apply a constrained profile by default. According to issue #20870 this is to avoid breaking backwards compatibility with previous Kubernetes versions, with the downside of exposing the underlying host.
Exploit Scenario
Alice schedules a Pod containing her web application to her Kubernetes cluster. Eve identifies a vulnerability in Alice’s web application and gains remote code execution within the container running Alice’s application. Unbeknownst to Alice, Eve is able to use a kernel exploit due to an unconfined seccomp profile of the container.
Recommendation
Short term, the default profile should be that of the underlying container runtime installation. While a constrained seccomp profile could break backwards compatibility, critical safety features should be opt-out, not opt-in.
Long term, migrate towards using a default profile. Perform validation across nodes to ensure consistent profile usage in a default state.
Anything else we need to know?:
See #81146 for current status of all issues created from these findings.
The vendor gave this issue an ID of TOB-K8S-002 and it was finding 7 of the report.
The vendor considers this issue Medium Severity.
To view the original finding, begin on page 32 of the Kubernetes Security Review Report
Environment:
- Kubernetes version: 1.13.4