Какие ключевые настройки securityContext стоит применять к Pod/контейнеру на практике, и зачем нужен runAsNonRoot?

Короткий ответ

Базовый набор для большинства приложений: runAsNonRoot: true (запрещает запуск процесса от root внутри контейнера), readOnlyRootFilesystem: true (файловая система контейнера доступна только для чтения, кроме явно смонтированных writable volume), и allowPrivilegeEscalation: false — вместе они существенно снижают ущерб от компрометации приложения внутри контейнера.

Как это работает подробнее

runAsNonRoot не запускает процесс от конкретного пользователя сам по себе — он лишь запрещает Kubernetes стартовать контейнер, если итоговый UID процесса (из образа или из runAsUser) равен 0; поэтому его обычно комбинируют с явным runAsUser: <non-zero>. readOnlyRootFilesystem предотвращает запись вредоносного или случайного кода в файловую систему контейнера во время выполнения, вынуждая явно объявлять нужные для записи volume (например, /tmp).

Пример кода

manifest.yamlКопировать

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
volumes:
  - name: tmp
    emptyDir: {}
volumeMounts:
  - { name: tmp, mountPath: /tmp }

Что использовать на практике

• Практика. эти настройки снижают поверхность атаки при эксплуатации уязвимости в приложении — если злоумышленник получит RCE, но процесс работает не от root и файловая система доступна только на чтение, возможности закрепления и дальнейшего продвижения существенно ограничены. Для кластерного применения единых правил используют Pod Security Admission (стандарты baseline/restricted) или сторонние политики (Kyverno/OPA Gatekeeper), которые в принудительном порядке требуют такие настройки для всех подов namespace.

Подводные камни

• Риски. настраивать runAsNonRoot: true без проверки, что образ приложения вообще поддерживает работу не от root (многие базовые образы по умолчанию root) — под просто не запустится с ошибкой CreateContainerConfigError; включать readOnlyRootFilesystem без добавления необходимых writable volume для временных файлов приложения, что ломает его работу в рантайме.