Skip to content

Latest commit

 

History

History
146 lines (97 loc) · 9.52 KB

0004-do-not-run-containers-with-privilege-flag.md

File metadata and controls

146 lines (97 loc) · 9.52 KB

CBPP-0004: Do not run containers with the privilege flag

Release Signoff Checklist

Items marked with (R) are required for the proposed best practice to be included in a release.

  • (R) CBPP approvers have approved the CBPP status as implementable
  • (R) CBPP summary, motivation and best practice details are appropriately documented
  • (R) Test plan is in place, giving consideration to CNF Test Suite input
  • (R) Scoring has been determined
  • "Implementation History" section is up-to-date
  • Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes

Summary

Privileged containers can potentially get unrestricted access to host's resources. Therefore, if the privileged container is compromised, an attacker would have full access to the server. Containers should be run with the privilege flag set to false to securely restrict the access to the host resources.

Motivation

This best practice benefits the CNF consumer / operator (e.g. a Communication Service Provider [CSP]) by limiting the exposure to the host system and other workloads available to a compromised or misbehaving CNF.

Validating that a CNF is following this best practice can be verified by CNF operators as an acceptance test.

SE-Linux based environments will require dropping root privileges. Example: OpenShift

Goals

  • Improve the security and behaviour of applications.
  • Add to the defense in depth strategy against external compromises.
  • Avoid compromised applications from causing more damage.
  • Restricting the Pod access to the host’s resources (e.g. memory, CPU, network)
  • Limiting access to other workloads running on the host

Non-Goals

  • Denying access to the host entirely
  • Fine-grained access control to the host

Proposal

When creating the Pod definition, the privilege flag policy should be set to false. This tells the container runtime to disable privilege mode for the containers on that Pod when it runs.

The privileged policy is defined by an absence of restrictions. This type of policy is typically aimed at system- and infrastructure- level workloads managed by privileged, trusted users.

Privileged containers are defined as any container where the container uid 0 is mapped to the host's uid 0. A process within a privileged container can get unrestricted host access. Without proper settings, a process can also gain privileges from its parent. Application containers should not be allowed to execute in privileged mode and privilege escalation should not be allowed.

Running a pod in a privileged mode means that the pod can access the host's resources and kernel capabilities.

https://kubernetes.io/docs/concepts/workloads/pods/#privileged-mode-for-containers

For example, a potential issue can be an RCE (Remote Code Execution) Vulnerability in one of your third-party dependencies or even in your own code. Using this vulnerability, an attacker might gain access to the running container, and assuming the pod is privileged, the attacker can continue directly to the host.

In a virtual machine or a bare-metal server, you avoid running your applications with the root user for a simple reason: if the application is compromised, an attacker would have full access to the server. For the same reason, avoid using privileged containers. A privileged container is a container that has access to all the devices of the host machine, bypassing almost all the security features of containers.

Workload Context

All non-system pod types should implement this best practice.

User Stories

Supply chain attack user stories

Supply chain attacks are a risk at any point in the supply chain. ‘Defence in depth’ says that we should (a) defend against supply chain attacks but also (b) add mitigations in the case that supply chain attacks happen.

Examples include

In all of these examples, the CNFs using a non-root user for their container processes, have limited the scope of damage a compromised process may cause.

See main defense in depth for supply chain attacks document for more information.

Notes/Constraints/Caveats

If your deployment workload resource definition (eg. helm) pulls in external upstream container images during runtime, those images may have Pod definitions with the privilege flag policy set to true for one or more their Pods. It is recommended that the CNF developer audits and cleans up any upstream images to respect this rule ensuring the privilege flag is set to false when following this best practice.

Some Pods may need privileges to provide required functionality. For example kube-proxy or the Envoy side-car.

It is the responsibility of the CNF developer to communicate the privileges needed by their CNF.

The CNF developer needs to be aware of how privileges of a container can be escalated, see https://kubernetes.io/docs/tasks/configure-pod-container/security-context/.

References

Alternatives

Role-based access control provides fine-grained policy management for user access to resources, such as access to namespaces.

Testing Objectives

An application which follows this best practice will not have any privileged containers running. This CBPP will be tested by the CNF Test Suite.

Scoring

This best practice results in a pass/fail.

Static or runtime analysis (all items checked for a pass) - CNF developers (testing before delivery) or CNF operators (testing what is delivered):

The Pod definition or any running container manifest has the privilege flag policy set to false.

Implementation History

First version: Feb 2023