Что такое 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-уровня.