Gymterview
middle

Что такое Security Context в Kubernetes?

Security Context – это набор параметров безопасности в манифесте Kubernetes, определяющих привилегии и контроль доступа для пода или отдельного контейнера. Это основной механизм настройки безопасности на уровне рабочей нагрузки.

Security Context задаётся на двух уровнях:

  • Pod-level (spec.securityContext) – применяется ко всем контейнерам в поде.
  • Container-level (spec.containers[].securityContext) – применяется к конкретному контейнеру и переопределяет pod-level настройки при конфликте.

Полный пример Security Context

Манифест с полным Security Context на обоих уровнях
apiVersion: v1
kind: Pod
metadata:
  name: secure-banking-pod
spec:
  # Pod-level security context
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    fsGroupChangePolicy: OnRootMismatch
    seccompProfile:
      type: RuntimeDefault
    supplementalGroups: [2000]

  containers:
  - name: banking-app
    image: registry.bank.local/banking-service:1.0.0

    # Container-level security context
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      privileged: false
      capabilities:
        drop:
          - ALL
      procMount: Default

Linux Capabilities

Capabilities дробят монолитные root-привилегии на отдельные единицы. Вместо полного root контейнер получает только необходимое:

Пример
securityContext:
  capabilities:
    drop:
      - ALL           # Удалить ВСЕ capabilities
    add:
      - NET_BIND_SERVICE  # Привязка к портам < 1024 (если нужно)
Capability Описание Нужна ли типичному Java-приложению?
NET_BIND_SERVICE Привязка к портам < 1024 Редко (используйте порты > 1024)
NET_RAW Raw sockets (ping) Нет
SYS_ADMIN Широкие admin-привилегии Никогда
SYS_PTRACE Трассировка процессов Нет (только для отладки)
CHOWN Изменение владельца файлов Нет

Seccomp (Secure Computing)

Seccomp ограничивает набор системных вызовов (syscalls), доступных процессу в контейнере:

Пример
securityContext:
  seccompProfile:
    type: RuntimeDefault  # Профиль container runtime (containerd/CRI-O)
    # Или кастомный профиль:
    # type: Localhost
    # localhostProfile: profiles/banking-app.json
Пример кастомного seccomp-профиля
{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": [
        "read", "write", "open", "close", "stat", "fstat",
        "mmap", "mprotect", "munmap", "brk",
        "socket", "connect", "accept", "bind", "listen",
        "clone", "execve", "exit_group",
        "futex", "epoll_wait", "epoll_ctl"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

AppArmor

AppArmor ограничивает доступ контейнера к файлам и операциям на уровне LSM (Linux Security Module):

Пример
metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/banking-app: runtime/default

SELinux

Пример
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"
    type: "container_t"

Рекомендуемый минимальный Security Context для production

Пример
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  privileged: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Вывод

Security Context – центральный механизм безопасности в Kubernetes. Минимальный набор для production: runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities.drop: ALL, seccompProfile: RuntimeDefault. Дополнительные уровни защиты (AppArmor, SELinux, кастомный seccomp) применяются для высокочувствительных сервисов.

На собеседовании: перечислите ключевые параметры Security Context, объясните разницу между pod-level и container-level. Упомяните capabilities (drop ALL – золотое правило) и seccomp. Если знаете AppArmor/SELinux – это бонус для senior-уровня.