В чем разница между настройкой привилегий в Docker и в Kubernetes?

И Docker, и Kubernetes управляют привилегиями контейнеров, но делают это на разных уровнях абстракции и с разными механизмами контроля.

Docker (уровень отдельной ноды):

• Управление через флаги CLI (--privileged, --cap-add, --user).
• Фокус на изоляцию контейнера от хостовой ОС.
• Политики безопасности задаются вручную при запуске или в Docker Compose.

Kubernetes (уровень кластера):

• Управление через securityContext в манифестах Pod/Deployment.
• Фокус на безопасность в многопользовательском кластере.
• Есть встроенные механизмы для принудительного применения политик: Pod Security Admission (PSA) или (в старых версиях) PodSecurityPolicy (PSP).

Пример манифеста Kubernetes с ограничениями:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: # Контекст для всего Pod
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: nginx
    securityContext: # Контекст для конкретного контейнера
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"] # Удаляем ВСЕ capabilities
        add: ["NET_BIND_SERVICE"] # Добавляем только одну нужную

Ключевое отличие для DevOps-инженера: В Kubernetes безопасность — это декларативная политика на уровне кластера. Вместо того чтобы надеяться, что все разработчики используют правильные флаги Docker, вы настраиваете Namespace с профилем PSA (например, restricted), который автоматически запрещает привилегированные контейнеры, монтирование hostPath и запуск от root.