TOB-K8S-002: Seccomp is disabled by default

[cji]

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

[liggitt]

/sig auth
/sig node
/assign @tallclair

[tallclair]

Previous discussion: #39845

I would love to see this happen, but previous efforts to make this change have resulted in requests to:

1. Make seccomp GA (KEP for promoting seccomp to GA enhancements#1148)
2. Define the default profile in Kubernetes (requires profile representation in k8s)
3. Implement a "complain mode" so issues can be detected before enabling

(1) is likely to happen in k8s 1.17. (2) Is a good follow up to that. (3) would be very useful, but also seems like the hardest change to make, and no one seems interested in investing significantly into seccomp right now.

[pjbgf]

1. Make seccomp GA (kubernetes/enhancements#1148)
2. Define the default profile in Kubernetes (requires profile representation in k8s)
3. Implement a "complain mode" so issues can be detected before enabling

@tallclair I would be keen to help us achieve that. Is there any of those 3 points that help is wanted?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cji]

/remove-lifecycle stale

[tallclair]

/lifecycle frozen

[pjbgf]

Linked two PRs that enable seccomp by default for pod sandbox.

[michelgokan]

how to completely disable seccomp? Asking for profiling scenarios with perf in non-production environments.

[tallclair]

@michelgokan for a given pod / container? Or globally for the cluster? Or disabling for the kernel?

[michelgokan]

@michelgokan for a given pod / container? Or globally for the cluster? Or disabling for the kernel?

As a simple workaround, I used following dummy seccomp configuration to enable all syscalls:

{
  "defaultAction": "SCMP_ACT_ALLOW"
}

[cynepco3hahue]

@cji Does the PR #101943 is enough to fix the issue?

[cji]

Fantastic! Yes I believe that does resolve this.