В чём разница между выдачей пользователю/сервису полных административных прав «на всякий случай» и ролью с правом только на чтение (read-only), и как это решение влияет на риски?

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

Административные права дают возможность изменять и удалять любые ресурсы, что при ошибке или компрометации аккаунта приводит к максимально возможному ущербу; роль read-only ограничивает субъекта просмотром данных без возможности их изменить, резко снижая потенциальный ущерб даже при компрометации.

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

уровень прав определяет «блаcт-радиус» — что именно может сделать скомпрометированный или ошибочно действующий субъект. Административная роль обычно включает действия create/update/delete над широким набором ресурсов, тогда как read-only ограничивается get/list/describe и не позволяет вносить изменения.

Пример кода

security-example-452.yamlКопировать

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

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

• Практика. для большинства задач мониторинга, дежурств первой линии, аналитики достаточно read-only доступа; административные права выдают точечно и временно (например, через запрос доступа с ограничением по времени — just-in-time access) только тем, кому они действительно нужны для конкретной задачи.
• Проверка. Ожидаемое поведение: пользователь с биндингом на роль pod-reader сможет выполнить kubectl get pods и kubectl logs, но получит Forbidden при попытке kubectl delete pod или kubectl edit deployment — это проверяется прямой попыткой выполнить запрещённое действие и получением ошибки авторизации.

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

• Ошибка. выдавать admin-доступ новым сотрудникам «чтобы не блокировать работу в первые недели»; не разделять роли для дежурных инженеров (на дежурстве нужно чуть больше прав, чем в обычной работе) и постоянных ролей; не отзывать временно повышенные права после завершения задачи.