Все самое полезное для девопсера в одном канале.
Наши курсы: https://clc.to/ZJ7Z1w
По рекламе: @tproger_sales_bot
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/6798b4e4509aba56522d1787
Post #4669
923
⚙️ Безопасный дебаг прода в Kubernetes
Типичная картина во время инцидента — инженер получает широкий доступ:
У этого подхода два системных последствия: аудит теряет смысл, потому что непонятно, кто и что делал, а временные исключения тихо становятся постоянной нормой.
Три принципа
1. Минимальные права через RBAC
Вместо
Привязывается к группе, а не к конкретному пользователю:
RBAC умеет ограничивать, может ли пользователь запустить
2. Краткосрочные учётные данные, привязанные к личности
Статичные kubeconfig с долгоживущими токенами — классический вектор компрометации. Цель: каждая сессия дебаггинга должна иметь учётные данные, которые истекают через 15-30 минут и однозначно идентифицируют конкретного человека.
Два способа реализации.
Вариант А — короткоживущие OIDC-токены. Большинство managed-кластеров это уже поддерживает. Достаточно настроить
Вариант Б — короткоживущие X.509-сертификаты. Если API-сервер доверяет клиентскому CA, можно выдавать временные сертификаты через
После подписания CSR используем вместе с приватным ключом в
3. Just-in-time access gateway
Это точка входа, которую разворачивают в кластере по запросу — на время сессии. Работает по SSH-протоколу. Инженер запрашивает доступ, получает короткоживущий OpenSSH user certificate, подключается.
Gateway аутентифицирует пользователя, применяет политики и от его имени делает вызовы Kubernetes API. Сессия пишется в лог. После завершения гейт удаляется.
RBAC для такого сценария выглядит так:
Имя группы
Три принципа работают как слои: RBAC определяет, что разрешено; краткосрочные учётные данные убирают риск утечки; JIT gateway даёт полный аудит каждой сессии. Каждый из них можно внедрить отдельно, не переписывая всё сразу.
➡️ Блог разработчиков
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#арсенал_инженера
Типичная картина во время инцидента — инженер получает широкий доступ:
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
#арсенал_инженера
- ❤ 2
