Skip to content

Latest commit

 

History

History
111 lines (77 loc) · 4.3 KB

security-model.md

File metadata and controls

111 lines (77 loc) · 4.3 KB
Raw

Security Model

This security model aims to clarify the project's current security position against industry recommendations and general security best practices. The information provided here should make it easier for security teams from highly regulated sectors to assess and use SPO for their workloads.

The SPO project strives to maintain the least privilege principle, by trying to run with the bare minimum privileges for the least amount of time possible. This approach decreases the attack surface and the window of opportunity in which it can be abused.

Note that this is an on-going effort, and may change over time as new features are developed.

Host Isolation (a.k.a. Pod Security / Security Context)

Details the security requirements to run SPO from a host isolation perspective.

Initialisation

Seccomp leverages an init container to setup an initial symlink as root, so it can then operate as a non-root user.

During initialisation it also uses the capabilities:

  • CHOWN
  • FOWNER
  • FSETID
  • DAC_OVERRIDE

Running Mode

The running permissions for the three core technologies supported:

Seccomp SELinux AppArmor
Requires root user No Yes Yes
Requires HostPID No No Yes
Requires "privileged container" No No Yes
Requires SSH Access to nodes No No No
Access to host's mount namespace No Yes On Demand
AppArmor Profile default default default
SELinux type spc_t spc_t spc_t
Seccomp Profile unconfined unconfined unconfined

Host Paths

Throughout their operation they require read and write permissions into host paths:

  • /var/lib/kubelet/seccomp
  • /etc/selinux.d
  • /etc/apparmor.d

Profile Generation Mode (auto-generating security profiles)

Profile generation features are optional and are not indented to be executed at production environments. Ideally such features would be used as part of your software development lifecycle, so you can detect and respond to change in profiles, which can later be enforced once deployed in production.

During the execution in profile generation mode, the observed applications may run less restricted than it would otherwise, to allow for their operations to be observed and recorded. Keep this in mind when using it against workloads you may not trust.

Seccomp SELinux AppArmor
Requires root user Yes Yes Yes
Requires HostPID Yes Yes Yes
Requires "privileged container" No Yes Yes
Requires SSH Access to nodes No No No
AppArmor Profile default default default
SELinux type spc_t spc_t spc_t
Seccomp Profile unconfined unconfined unconfined

Control Plane RBAC

The project's RBAC requirements are managed in an automated manner based on +kubebuilder:rbac: tags. To map what code requires which permissions, search this repo for it.

At control plane level the least privilege principle should also be observed. A high-level summary of object types accessed outside the security-profiles-operator namespace:

security-profiles-operator

  • daemonsets
  • daemonsets/finalizers
  • deployments
  • configmaps
  • events
  • pods
  • servicemonitors

spod

  • daemonsets
  • subjectaccessreviews
  • tokenreviews
  • subjectaccessreviews
  • events
  • nodes
  • pods

spo-webhook

  • events
  • pods

For the most up-to-date rbac requirements refer to the materialised role.yaml file.