Как стать автором
Обновить

Комментарии 4

Однако для получения доступа в production (для диагностики какой-то проблемы) предусмотрена возможность запросить (через специальную консольную утилиту) временный токен, дающий им полные права на свои пространства имён.


Можно про это подробнее, как и где потом этот токен используется?
Вот с этого момента подробности рассказывают: youtu.be/z7TIzCAEo0M?t=1132

P.S. У выступающего не самый легкий для быстрого восприятия английский, поэтому маякните, пожалуйста, если будете рады краткому текстовому переводу на русский здесь в комментариях.
Будем рады )
В случаях, когда service owners требуется получить доступ к production, они пользуются внутренней консольной разработкой (под названием rkube) для инициации процесса аутентификации через OpenID Connect (см. также OpenID Connect Tokens в документации Kubernetes). По своей сути он очень похож на аналогичную реализацию в CLI-утилите gcloud для GCP (инженеры Reddit заимствовали всю идею оттуда).

После успешной аутентификации в локальный конфиг (.kube/config) на машине разработчика записывается JSON Web Token. Этот токен имеет ограниченное (небольшое) время жизни. В нём содержится подписанный payload, в котором указано имя пользователя и его членство в группах. В свою очередь политики, настроенные на стороне Kubernetes-кластера, ориентированы на выдачу прав по этим самым группам.

Поскольку для каждого сервиса создаётся своё пространство имён, дальнейшая задача — выдать service owner'ам полные права на нужные namespaces (т.е. соответствующие сервисам, которыми они владеют).

Итог: service owners могут получить права на свои сервисы и только их.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.