Введение
kubectl exec сам по себе почти не отвечает на вопрос “что именно делали внутри контейнера”. В Kubernetes-аудите вы видите факт обращения к subresource pods/exec, но не содержимое интерактивной сессии. kubectl-rexec (плагин от Adyen) решает эту проблему: он проксирует exec через свой endpoint и публикует аудируемые события, чтобы у вас появился след действий “внутри”.
GitHub репозиторий: https://github.com/Adyen/kubectl-rexec
Когда kubectl-rexec особенно полезен
- Compliance и расследования: нужно понимать, какие действия выполнялись в поде во время инцидента (а не только “кто зашёл в shell”).
- Привилегированный доступ: вы разрешаете exec только ограниченному кругу людей, но хотите прозрачность действий.
- Change management: “ручные правки в проде” должны оставлять след (например, изменение конфигов, ручной рестарт сервиса внутри контейнера).
Как работает kubectl-rexec
Архитектура состоит из двух частей:
- ValidatingWebhookConfiguration — запрещает обычный pods/exec, если запрос не пришёл через rexec endpoint (или если пользователь не имеет права обхода).
- APIService (rexec) — принимает запросы от kubectl-плагина, преобразует их обратно в обычный exec и проксирует в kube-apiserver, параллельно создавая аудит-события. Проксирование делается через impersonation, потому что kube-apiserver не передаёт исходные креды дальше по цепочке.
Требования и ограничения
- Проект ориентирован на кластеры, где exec работает через websocket. В README указано: Kubernetes 1.30 (feature gate включён по умолчанию) или Kubernetes 1.29 с включённым TranslateStreamCloseWebsocketRequests=true. Версии ниже 1.29 не поддерживаются.
Установка
Установка делится на две части: proxy-компонент в кластер + kubectl-плагин локально.
1) Установить proxy в кластер
В quick start из репозитория предлагается применить манифесты через kustomize (обычно в kube-system). Команда также добавляет webhook, который отключает обычный kubectl exec.
kustomize build manifests/ | kubectl -n kube-system apply -f -2) Установить kubectl-плагин
Быстрый вариант из Getting started — поставить плагин через go install и убедиться, что каталог с бинарями в PATH.
go install github.com/adyen/kubectl-rexec@latest3) Проверить, что события пишутся
Для проверки можно посмотреть логи proxy-компонента (в дальнейшем их обычно отправляют в централизованное лог-хранилище).
kubectl -n kube-system logs -l app=rexec -fИспользование
Плагин повторяет параметры обычного kubectl exec, но вызывается через kubectl rexec exec ....
Пример 1: интерактивная сессия bash
kubectl rexec exec -ti some-pod -- bashПример 2: выполнить одну команду без TTY
kubectl rexec exec some-pod -- sh -c "id && uname -a"Пример 3: выбрать namespace и контейнер
kubectl -n production rexec exec -ti pod-name -c app -- shПримеры применения в реальных процессах
- “Break-glass” доступ: выдаёте право на rexec ограниченной группе, а обычный exec блокируете webhook’ом.
- Инциденты: во время расследования вы видите не только “кто заходил”, но и события/след от exec, и можете сопоставить это с логами приложения.
- Операционные изменения: если команда вынуждена делать ручные правки (hotfix), вы сохраняете аудит-трейл и снижаете “чёрную магию в проде”.
Где это удобно развернуть и как не потерять аудит
kubectl-rexec особенно полезен в self-managed Kubernetes, когда вы поднимаете кластер на виртуальных машинах и отвечаете за безопасность и аудит сами. В Serverspace.uz можно быстро развернуть облачные серверы под control plane/worker-ноды, а аудит-логи rexec проксировать в вашу систему логирования (например, Loki/ELK), чтобы след exec-сессий не терялся даже при пересоздании нод.
Cloud Servers: https://serverspace.uz/services/cloud-servers/
FAQ
kubectl-rexec полностью заменяет Kubernetes Audit Logs?
Нет. Kubernetes audit по-прежнему нужен для фактов обращений к API (кто/когда/к чему). kubectl-rexec добавляет недостающую часть вокруг exec-потока за счёт проксирования и аудируемых событий на своём уровне.
Почему нельзя просто смотреть audit logs pods/exec?
Обычный аудит фиксирует сам факт exec-запроса, но не даёт прозрачной картины “что делали внутри интерактивной сессии”. Это и есть проблема, которую проект пытается закрыть.
Какая минимальная версия Kubernetes нужна?
В README указано: поддерживаются кластеры, где exec работает по websocket: Kubernetes 1.30 (по умолчанию) или 1.29 с включённым TranslateStreamCloseWebsocketRequests=true; ниже 1.29 — не поддерживается.
Где смотреть “аудит-события” rexec?
В quick start предлагается начать с логов proxy (kubectl -n kube-system logs -l app=rexec -f) и затем настроить централизованную доставку логов.
Шпаргалка: основные команды kubectl
| Задача | Команда | Комментарий |
|---|---|---|
| Проверить текущий контекст | kubectl config current-context | Показывает, с каким кластером вы сейчас работаете |
| Посмотреть все контексты | kubectl config get-contexts | Удобно, если у вас несколько кластеров/окружений |
| Переключить контекст | kubectl config use-context <context> | Будьте аккуратны: легко “попасть не туда” |
| Список namespace | kubectl get ns | Быстрый обзор окружений |
| Поды в namespace | kubectl -n <ns> get pods | Добавьте -o wide, чтобы увидеть ноды и IP |
| Основные ресурсы в namespace | kubectl -n <ns> get pods,svc,deploy | Самый быстрый “health-check” по окружению |
| Описание пода (события/детали) | kubectl -n <ns> describe pod <pod> | Полезно при CrashLoopBackOff и проблемах с образом/секретами |
| Логи контейнера | kubectl -n <ns> logs <pod> -c <container> | Добавьте -f (follow) и --tail=200 для удобства |
| Логи предыдущего контейнера | kubectl -n <ns> logs <pod> -c <container> --previous | Очень полезно, когда контейнер быстро падает |
| Exec (обычный) | kubectl -n <ns> exec -ti <pod> -- sh | Может быть заблокирован webhook’ом rexec |
| Exec (аудируемый через rexec) | kubectl -n <ns> rexec exec -ti <pod> -- sh | Рекомендуемый вариант при включённом kubectl-rexec |
| Port-forward на сервис | kubectl -n <ns> port-forward svc/<svc> 8080:80 | Быстро открыть доступ локально без Ingress |
| Port-forward на под | kubectl -n <ns> port-forward pod/<pod> 8080:8080 | Полезно для дебага конкретного экземпляра |
| Применить манифест | kubectl apply -f file.yaml | Создать/обновить ресурсы |
| Diff перед apply | kubectl diff -f file.yaml | Понять, что изменится |
| Rollout статус деплоя | kubectl -n <ns> rollout status deploy/<name> | Контроль выката |
| Откат деплоя | kubectl -n <ns> rollout undo deploy/<name> | Вернуть предыдущую ревизию |
| События в namespace | kubectl -n <ns> get events --sort-by=.lastTimestamp | Быстро найти причины Pending/Failed |
| Проверить права (RBAC) | kubectl auth can-i create pods/exec -n <ns> | Понять, кто может делать exec |
Вывод
kubectl-rexec — практичный способ добавить аудит вокруг kubectl exec там, где одного Kubernetes audit недостаточно. Он строится на блокировке “обычного” exec через validating webhook и проксировании exec через APIService, где можно формировать аудит-события. Для быстрого старта достаточно поставить proxy в кластер (kustomize → kube-system), установить kubectl-плагин и настроить сбор логов proxy в централизованное хранилище.
