3

I'm building my own CSI driver with CSI standards and I'm wondering about the Security Context to be set for the CSI sidecar containers.

I'm going to use:

  • Node Driver Registrar
  • CSI provisioner
  • CSI attacher
  • CSI liveness probe.

Some of them need to run as root and I'm wondering about the configuration in the Security Context to assign them the minimum Linux capabilities and to be sure that root capabilities are provided for the minimum time.

Am I forced to set the security context as follows? Is there any way to restrict it furthermore?

securityContext:
  allowPrivilegeEscalation: true
  privileged: false
  runAsNonRoot: true
  capabilities:
    drop:
    - all
    add:
    - SYS_ADMIN

Thanks in advance, Antonio

Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
Anto74
  • 33
  • 3
  • Welcome to the community! Are you following any tutorial or documentation? I'm referring to the manifest snippet you added – moonkotte Sep 14 '21 at 17:51
  • 1
    Hi moonkotte, I'm following the Security Context's field description: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#securitycontext-v1-core Thanks! Antonio – Anto74 Sep 16 '21 at 14:42

1 Answers1

0

Based on research about kubernetes and linux capabilities, that looks you've already found the least possible privileges.

Your example contains minimum needed capability - CAP_SYS_ADMIN which is used primarily for mounting and unmounting filesystems.

In more details CAP_SYS_ADMIN is used for:

  • Perform a range of system administration operations including: quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2), and setdomainname(2);

  • use ioprio_set(2) to assign IOPRIO_CLASS_RT and (before Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes;

  • exceed /proc/sys/fs/file-max, the system-wide limit on the number of open files, in system calls that open files (e.g., accept(2), execve(2), open(2), pipe(2));

  • call setns(2) (requires CAP_SYS_ADMIN in the target namespace);

  • employ the TIOCSTI ioctl(2) to insert characters into the input queue of a terminal other than the caller's controlling terminal;

  • employ the obsolete nfsservctl(2) system call;

  • employ the obsolete bdflush(2) system call;

  • perform various privileged block-device ioctl(2) operations;

  • perform various privileged filesystem ioctl(2) operations;

  • perform privileged ioctl(2) operations on the /dev/random device (see random(4));

  • perform administrative operations on many device drivers;

Source - capabilities(7) — Linux manual page

Also there is a very good article with many details about docker images and security aspects can be found here - Towards unprivileged container builds

One more article explains linux capabilities and its appliance with examples may be helpful - HackTricks - Linux Capabilities

moonkotte
  • 3,661
  • 2
  • 10
  • 25