Seccomp та Kubernetes

Seccomp (secure computing mode) — це функція ядра Linux, яка існує з версії 2.6.12. Її можна використовувати для обмеження привілеїв процесу шляхом ізоляції, обмежуючи системні виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Поля Seccomp

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.19 [stable]

Існує чотири способи вказати профіль seccomp для Podʼа:

pods/security/seccomp/fields.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  securityContext:
    seccompProfile:
      type: Unconfined
  ephemeralContainers:
  - name: ephemeral-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  initContainers:
  - name: init-container
    image: debian
    securityContext:
      seccompProfile:
        type: RuntimeDefault
  containers:
  - name: container
    image: docker.io/library/debian:stable
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: my-profile.json

Pod у прикладі вище працює як Unconfined, тоді як ephemeral-container та init-container конкретно визначають RuntimeDefault. Якби ефемерний або init-контейнер не встановили явно поле securityContext.seccompProfile, тоді значення успадковується від Pod. Це ж стосується і контейнера, який використовує локальний профіль my-profile.json.

Загалом, поля контейнерів (включаючи ефемерні) мають вищий пріоритет, ніж значення на рівні Pod, а контейнери, які не задають поле seccomp, успадковують профіль від Pod.

Наступні значення можливі для поля seccompProfile.type:

Unconfined
Навантаження працює без будь-яких обмежень seccomp.
RuntimeDefault
Застосовується стандартний профіль seccomp, визначений середовищем виконання контейнерів. Стандартні профілі прагнуть забезпечити надійний набір параметрів безпеки, зберігаючи функціональність навантаження. Можливо, що стандартні профілі відрізняються між різними середовищами виконання контейнерів та їх версіями, наприклад, порівнюючи профілі CRI-O та containerd.
Localhost
Застосовується localhostProfile, який має бути доступний на диску вузла (у Linux це /var/lib/kubelet/seccomp). Доступність профілю seccomp перевіряється середовищем виконання контейнерів під час створення контейнера. Якщо профіль не існує, то створення контейнера завершиться з помилкою CreateContainerError.

Профілі Localhost

Профілі Seccomp — це JSON-файли, що відповідають схемі, визначеній специфікацією середовища виконання OCI. Профіль, як правило, визначає дії на основі відповідних системних викликів, але також дозволяє передавати конкретні значення як аргументи до системних викликів. Наприклад:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 38,
  "syscalls": [
    {
      "names": [
        "adjtimex",
        "alarm",
        "bind",
        "waitid",
        "waitpid",
        "write",
        "writev"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

defaultAction у профілі вище визначено як SCMP_ACT_ERRNO і буде повернуто як резервне для дій, визначених у syscalls. Помилка визначена як код 38 через поле 'defaultErrnoRet'.

Наступні дії зазвичай можливі:

SCMP_ACT_ERRNO
Повернення вказаного коду помилки.
SCMP_ACT_ALLOW
Дозвіл на виконання системного виклику.
SCMP_ACT_KILL_PROCESS
Завершення процесу.
SCMP_ACT_KILL_THREAD і SCMP_ACT_KILL
Завершення тільки потоку.
SCMP_ACT_TRAP
Генерація сигналу SIGSYS.
SCMP_ACT_NOTIFY і SECCOMP_RET_USER_NOTIF
Сповіщення простору користувача.
SCMP_ACT_TRACE
Сповіщення процесу трасування з вказаним значенням.
SCMP_ACT_LOG
Дозвіл на виконання системного виклику після того, як дія була зареєстрована в syslog або auditd.

Деякі дії, такі як SCMP_ACT_NOTIFY або SECCOMP_RET_USER_NOTIF, можуть бути не підтримувані залежно від середовища виконання контейнера, середовища виконання OCI або версії ядра Linux. Можуть бути також додаткові обмеження, наприклад, що SCMP_ACT_NOTIFY не може використовуватися як defaultAction або для певних системних викликів, таких як write. Усі ці обмеження визначаються або середовищем виконання OCI (runc, crun) або libseccomp.

Масив JSON syscalls містить список об’єктів, що посилаються на системні виклики за їхніми відповідними names. Наприклад, дія SCMP_ACT_ALLOW може бути використана для створення білого списку дозволених системних викликів, як показано у прикладі вище. Також можна визначити інший список, використовуючи дію SCMP_ACT_ERRNO, але з іншим значенням повернення (errnoRet).

Також можливо вказати аргументи (args), що передаються до певних системних викликів. Більше інформації про ці розширені випадки використання можна знайти в специфікації середовища виконання OCI та документації ядра Linux щодо Seccomp.

Додаткове читання

Змінено October 14, 2024 at 10:39 PM PST: upstream sync (2238d2576e)