Аутентификация в Kubernetes через Gitlab’овские JWT токены

Введение

Зачем?

Представим ситуацию, что мы деплоим по push-модели. В качестве платформы для запуска деплоя у нас используется Gitlab: в нём настроен пайплайн и джобы, разворачивающие приложения в разные окружения в Kubernetes

Какой бы инструмент мы не использовали (kubectl, helm), для манипуляций с ресурсами API нам в любом случае будет необходимо аутентифицироваться при выполнении запросов к Kubernetes. Для этого в запросе надо передать данные для аутентификации, будь то токен или сертификат. И тут возникает несколько вопросов:

1. Где хранить эти креды?

   Хранить креды от кластера можно, например, в Gitlab CI/CD Variables и подставлять в джобу деплоя, но тогда потенциально все пользователи будут деплоить с одними и теми же доступами

2. Как сделать так, чтобы у каждого пользователя были свои данные для доступа в кластер?

   Можно было бы вручную запускать джобы деплоя и в параметры каждый раз подставлять свои аутентификационные данные, но, очевидно, такой подход неудобен и подходит далеко не всем

А что если сделать так, чтобы в качестве провайдера аутентификационных данных для Kubernetes выступал сам Gitlab? Тогда не надо было бы нигде хранить креды, и каждый пользователь мог бы аутентифицироваться в кубере под своей учёткой при запуске деплоя

Знакомьтесь. Gitlab ID Tokens

В версии Gitlab 15.7 появилась возможность прямо в джобе динамически создавать короткоживущие JWT токены, выпускаемые на имя того, кто запустил джобу

Всё, что нужно сделать — это дать название переменной с токеном и описать в поле aud (audience) имя потенциального получателя токена (сервиса, которому токен будет отправляться)

job_with_id_tokens-job:   id_tokens:     MY_JWT_TOKEN:       aud: https://vault.example.com   script:     - echo $($MY_JWT_TOKEN | base64 -w0) 

Пример полученного токена

{   "namespace_id": "72",   "namespace_path": "my-group",   "project_id": "20",   "project_path": "my-group/my-project",   "user_id": "1",   "user_login": "sample-user",   "user_email": "sample-user@example.com",   "user_identities": [       {"provider": "github", "extern_uid": "2435223452345"},       {"provider": "bitbucket", "extern_uid": "john.smith"},   ],   "pipeline_id": "574",   "pipeline_source": "push",   "job_id": "302",   "ref": "feature-branch-1",   "ref_type": "branch",   "ref_path": "refs/heads/feature-branch-1",   "ref_protected": "false",   "environment": "test-environment2",   "environment_protected": "false",   "deployment_tier": "testing",   "environment_action": "start",   "runner_id": 1,   "runner_environment": "self-hosted",   "sha": "714a629c0b401fdce83e847fc9589983fc6f46bc",   "project_visibility": "public",   "ci_config_ref_uri": "gitlab.example.com/my-group/my-project//.gitlab-ci.yml@refs/heads/main",   "ci_config_sha": "714a629c0b401fdce83e847fc9589983fc6f46bc",   "jti": "235b3a54-b797-45c7-ae9a-f72d7bc6ef5b",   "iss": "https://gitlab.example.com",   "iat": 1681395193,   "nbf": 1681395188,   "exp": 1681398793,   "sub": "project_path:my-group/my-project:ref_type:branch:ref:feature-branch-1",   "aud": "https://vault.example.com" } 

Сам токен содержит множество полей, но нас в первую очередь интересует некий уникальный идентификатор, по которому можно однозначно определить пользователя. Для этого отлично подходит поле user_email, которое содержит, как это не удивительно, пользовательский email

Отлично. Теперь что с этим можно сделать на стороне Kubernetes?

Доступ в Kubernetes через OIDC токены

Официальная документация k8s говорит нам о том, что кубовый API Server умеет работать со сторонними JWT токенами, а именно: проверять их подпись и вытаскивать из определённых полей имя пользователя и названия групп для того, чтобы матчить их с subjects, заданными в RBAC, для дальнейшей авторизации

Всё, что для этого нужно, это передать бинарнику kube-api-server дополнительные параметры при запуске, в которых мы укажем

• URL того, кто будет выпускать токены (и откуда забирать публичные ключи для проверки подписи)

• ID того, кто является получателем токена (тот самый aud)

• Из какого поля (claim) вытаскивать имя пользователя и названия групп

• Дополнительные параметры, типа уникального префикса для имени пользователя (чтобы не перемешивать с пользователями, аутентифицирующимися другими способами) и CA файла self-hosted инстанса Gitlab

Что же, пришло время проверить, как это всё будет работать на практике

Аутентифицируемся в Kubernetes через Gitlab’овские JWT токены

Чисто для теста в рамках этой статьи представим, что у нас используется:

• Gitlab.com и его бесплатные шаренные раннеры

• Свой Kubernetes кластер с публичным белым IP и с открытым всему миру 6443 портом kube-api-server

Нам необходимо сделать так, чтобы:

1. Можно было аутентифицироваться в кластере по пользовательскому JWT токену, полученному от Gitlab

2. Доступы к ресурсам были те, которые прописаны в RBAC для пользователя

Настройка OIDC на kube-api-server

Тут всё просто. Передаём kube-api-server следующие параметры запуска

--oidc-issuer-url="https://gitlab.com" --oidc-client-id="a-k8s-01" --oidc-username-claim="user_email" --oidc-username-prefix="oidc:" 

• Токены выпускает https://gitlab.com (поле iss в токене)

• Токены предназначены для a-k8s-01 (поле aud)

• Имя пользователя берём из поля user_email

• В RBAC мы будем использовать префикс oidc: перед именем пользователя

Создание RBAC

Проверять будем на кластерной роли с какими-нибудь простыми разрешениями (получение списка неймспейсов)

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:   name: maintainer rules: - apiGroups:   - ''   resources:   - 'namespaces'   verbs:   - 'get'   - 'list' --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:   name: maintainer roleRef:   apiGroup: rbac.authorization.k8s.io   kind: ClusterRole   name: maintainer subjects: - apiGroup: rbac.authorization.k8s.io   kind: User   name: oidc:user@example.com 

Создание тестовой джобы в Gitlab

Тут тоже всё просто:

• Зададим ID Token GITLAB_K8S_JWT_TOKEN с получателем (aud) a-k8s-01

• Для kubectl создадим конфиг, в который, в том числе, будет добавлен наш динамически создаваемый GITLAB_K8S_JWT_TOKEN

• Попробуем произвести какие-нибудь манипуляции с ресурсами кластера

stages:   - deploy  kubectl_deploy:   stage: deploy   id_tokens:     GITLAB_K8S_JWT_TOKEN:       aud: a-k8s-01   image:     name: bitnami/kubectl:1.28     entrypoint:       - ""   script:     - |       cat << EOF > /tmp/ca.pem       <CA_CERTIFICATE_CONTENT>       EOF     - API_SERVER="<api_server_url>"     - |       kubectl config set-cluster cluster --server="${API_SERVER}" --certificate-authority=/tmp/ca.pem       kubectl config set-credentials user --token="${GITLAB_K8S_JWT_TOKEN}"       kubectl config set-context context --cluster=cluster --user=user       kubectl config use-context context     - kubectl get ns     - kubectl get svc 

Три. Два. Один. Запуск

Как и ожидалось: неймспейсы получены, к сервисам доступа нет, а значит всё сработало точно так, как нам нужно

Теперь можно продумывать ролевую модель, нарезать доступы по неймспейсам, ограничивать деплои в прод только для ответственных инженеров и прочее, но это уже другая история…