⚙️ Безопасный дебаг прода в Kubernetes

Типичная картина во время инцидента — инженер получает широкий доступ: cluster-admin, общий jump-бокс или долгоживущий SSH-ключ.

У этого подхода два системных последствия: аудит теряет смысл, потому что непонятно, кто и что делал, а временные исключения тихо становятся постоянной нормой.

Три принципа

1. Минимальные права через RBAC

Вместо cluster-admin выдавать роль с конкретным набором действий, которые нужны дежурному.

Привязывается к группе, а не к конкретному пользователю:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oncall-debug
  namespace: payments
rules:
  - apiGroups: [""]
    resources: ["pods", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["pods/exec", "pods/portforward"]
    verbs: ["create"]
  - apiGroups: [""]
    resources: ["pods/ephemeralcontainers"]
    verbs: ["update"]

RBAC умеет ограничивать, может ли пользователь запустить pods/exec, но не может ограничить, какие команды он выполнит внутри сессии. Это задача для отдельного слоя поверх RBAC.

2. Краткосрочные учётные данные, привязанные к личности

Статичные kubeconfig с долгоживущими токенами — классический вектор компрометации. Цель: каждая сессия дебаггинга должна иметь учётные данные, которые истекают через 15-30 минут и однозначно идентифицируют конкретного человека.

Два способа реализации.

Вариант А — короткоживущие OIDC-токены. Большинство managed-кластеров это уже поддерживает. Достаточно настроить kubeconfig так, чтобы токен обновлялся автоматически, а не копировался вручную в конфиг:

users:
- name: oncall
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      command: cred-helper
      args: ["--cluster=prod", "--ttl=30m"]

Вариант Б — короткоживущие X.509-сертификаты. Если API-сервер доверяет клиентскому CA, можно выдавать временные сертификаты через CertificateSigningRequest API. Приватный ключ остаётся на машине инженера, в идеале в аппаратном токене.

openssl genpkey -algorithm Ed25519 -out oncall.key

openssl req -new -key oncall.key -out oncall.csr \
  -subj "/CN=user/O=oncall-payments"

После подписания CSR используем вместе с приватным ключом в kubectl. Через 30 минут сертификат протухает автоматически.

3. Just-in-time access gateway

Это точка входа, которую разворачивают в кластере по запросу — на время сессии. Работает по SSH-протоколу. Инженер запрашивает доступ, получает короткоживущий OpenSSH user certificate, подключается.

Gateway аутентифицирует пользователя, применяет политики и от его имени делает вызовы Kubernetes API. Сессия пишется в лог. После завершения гейт удаляется.

RBAC для такого сценария выглядит так:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: jit-debug
  namespace: payments
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jit-debug
  namespace: payments
subjects:
  - kind: Group
    name: jit:oncall:payments
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: jit-debug
  apiGroup: rbac.authorization.k8s.io

Имя группы jit:oncall:payments берётся из короткоживущего сертификата или OIDC-токена — так в логах всегда видно, кто именно и к чему имел доступ.

Три принципа работают как слои: RBAC определяет, что разрешено; краткосрочные учётные данные убирают риск утечки; JIT gateway даёт полный аудит каждой сессии. Каждый из них можно внедрить отдельно, не переписывая всё сразу.

➡️ Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера