Dex#

Dex — это служба идентификации, которая использует OpenID Connect для аутентификации других приложений.

Dex действует как портал для других поставщиков удостоверений через «Connectors». Это позволяет Dex осуществлять аутентификацию на серверах LDAP, поставщиках SAML или установленных поставщиках удостоверений, таких как GitHub и Active Directory.

Позволяет написать логику аутентификации один раз, чтобы общаться с Dex, затем Dex обрабатывает протоколы для всех перечисленных поставщиков удостоверений./etc/ssl/certs

Когда пользователь входит в систему через Dex, его личность обычно сохраняется в другой системе управления пользователями: каталоге LDAP, организации GitHub и т. д. Dex действует в качестве промежуточного слоя между клиентским приложением и вышестоящим поставщиком удостоверений. Клиенту достаточно понимать OpenID Connect, чтобы запрашивать Dex, тогда как Dex реализует массив протоколов для запроса других систем управления пользователями.

Connectors - это стратегия, используемая Dex для аутентификации пользователя у другого поставщика удостоверений. Dex реализует соединители, предназначенные для конкретных платформ, это может быть GitHub, а также для установленных протоколов, таких как LDAP и SAML.

В зависимости от ограничений соединителей в протоколах Dex может помешать выдаче токенов обновления или возврату утверждений о членстве в группе. Например, поскольку SAML не предоставляет неинтерактивного способа обновления утверждений, если пользователь входит в систему через соединитель SAML, Dex не выдаст токен обновления своему клиенту. Поддержка токена обновления необходима для клиентов, которым требуется автономный доступ, например kubectl.

Ответы токенов от поставщиков OpenID Connect включают подписанный JSON Web Token (JWT), называемый токеном идентификатора. Токены идентификатора содержат имена, адреса электронной почты, уникальные идентификаторы и в случае Dex набор групп, которые можно использовать для идентификации пользователя. Поставщики OpenID Connect, такие как Dex, публикуют открытые ключи. Сервер API kubernetes понимает, как использовать их для проверки токенов идентификатора.

Поток аутентификации с использованием Dex:

  • клиент OAuth2 регистрирует пользователя через Dex;

  • этот клиент использует возвращенный токен идентификатора в качестве токена-носителя при общении с API kubernetes;

  • kubernetes использует открытые ключи Dex для проверки идентификатора токена;

  • последовательность символов, обозначенная как имя пользователя (и, возможно, информация о группе), будет связана с этим запросом;

  • информацию об имени пользователя и группе можно комбинировать с плагинами авторизации kubernetes. Например, управление доступом на основе ролей (RBAC) для обеспечения соблюдения политики.

Сценарии использования Dex#

Аутентификация kubernetes через Dex#

В сценарии описана настройка плагина аутентификации токена kubernetes OpenID Connect с Dex. Содержит пример, показывающий, как сервер Dex можно развернуть в DropApp.

Настройка сервера API для использования плагина аутентификации OpenID Connect требует:

  • развертывания сервера API с определенными флагами;

  • HTTPS;

  • доступность пользовательских файлов для сервера API;

  • доступ Dex к браузеру и серверу(ам) API kubernetes.

Используйте следующие флаги, чтобы указать параметры серверу(ам) API:

--oidc-issuer-url=https://dex.example.com:32000
--oidc-client-id=example-app
--oidc-ca-file=/etc/ssl/certs/openid-ca.pem
--oidc-username-claim=email
--oidc-groups-claim=groups

Примечание

Замените dex. dex.example.com на любое DNS-имя или IP-адрес, под которым работает dex.

Сценарий запуска Dex в DropApp#

Для запуска Dex с включенным HTTPS требуется действительный сертификат SSL, а сервер API должен доверять сертификату подписывающего центра сертификации, используя флаг --oidc-ca-file.

  1. В текущем примере использования ресурсы TLS можно создать с помощью следующей команды:

    cd examples/k8s
./gencert.sh

    Это создаст несколько файлов в ssl-каталоге, наиболее важными из которых являются cert.pem. Сгенерированный сертификат SSL предназначен для dex.example.com, измените его, отредактировав .key.pemca.pemgencert.sh.

  2. В приведенном ниже примере манифеста pod предполагается, что файл CA скопирован в формат /etc/ssl/certs. При необходимости внесите изменения:

    spec:
  containers:

    [...]

    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: etc-ssl-certs
      readOnly: true

    [...]

  volumes:
  - name: ca-certs
    hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate

    Файл CA, который использовался для подписи сертификатов SSL для Dex, необходимо скопировать в место, где сервер API сможет его прочитать и настроить поиск с флагом --oidc-ca-file.

  3. Используйте kubectl, чтобы добавить сертификаты обслуживания в качестве secrets:

    kubectl -n dex create secret tls dex.example.com.tls --cert=ssl/cert.pem --key=ssl/key.pem

  4. Создайте secret для клиента GitHub OAuth2:

    kubectl -n dex create secret \
generic github-client \
--from-literal=client-id=$GITHUB_CLIENT_ID \
--from-literal=client-secret=$GITHUB_CLIENT_SECRET

  5. Создайте службу развертывания Dex, configmap и порт node. Это также создаст привязки RBAC, позволяющие Dex управлять CRD в DropApp:

    kubectl create -f dex.yaml

  6. Используйте example-app для входа в кластер и получения токена идентификатора. Чтобы создать приложение, выполните следующие команды:

    cd examples/example-app
go install .

  7. Соберите тестовое приложение:

    example-app --issuer https://dex.example.com:32000 --issuer-root-ca examples/k8s/ssl/ca.pem

    Примечание

    Для сборки example-app требуется версия Go не ниже 1.7.

    Обратите внимание, что example-app будет прослушивать http://127.0.0.1:5555 и его можно изменить с помощью флага --listen.

  8. После запуска примера приложения откройте браузер и перейдите по адресу http://127.0.0.1:5555.

    Появится страница с такими полями, как scope и client-id. Для целей тестирования функций заполнение полей не требуется, поэтому оставьте форму пустой. Нажмите login.

  9. На следующей странице выберите вариант GitHub и предоставьте доступ к Dex для просмотра профиля.

  10. Замените URI перенаправления по умолчанию — http://127.0.0.1:5555/callback, с помощью флага --redirect-uri, убедитесь, что он соответствует configmap.

    Обратите внимание, что URI перенаправления отличается от того, который указан при создании GitHub OAuth2 client credentials. Когда осуществляется вход в систему, GitHub сначала перенаправляет на Dex (https://dex.example.com:32000/callback), затем Dex перенаправляет на URI example-app.

  11. Используйте «ID-токен» в качестве токена-носителя для аутентификации на сервере API:

    token='(id token)'
curl -H "Authorization: Bearer $token" -k https://( API server host ):443/api/v1/nodes

  12. Создайте файл kubeconfig ~/.kube/config, используйте следующий формат:

users:
- name: (USERNAME)
  user:
    token: (ID-TOKEN)

Добавление пользователя OpenID Connect в config DropApp#

  1. Настройте аутентификацию через OpenID Connect в кластере DropApp, используя указанные параметры:

    ./kubectl config set-credentials oidc \
    --exec-api-version=client.authentication.k8s.io/v1beta1 \
    --exec-command=kubectl \
    --exec-arg=oidc-login \
    --exec-arg=get-token \
    --exec-arg=--oidc-issuer-url=https://<repoexample.ru> \ # Укажите актуальный путь до локального репозитория
    --exec-arg=--oidc-client-id=kubelogin-app \
    --exec-arg=--oidc-client-secret=ZXhhbXBsZS1hcHAtc2VjcmV0 \
    --exec-arg=--oidc-extra-scope=profile \
    --exec-arg=--oidc-extra-scope=groups \
    --exec-arg=--certificate-authority=/Users/20254535/dex_c02/ssl/ca.pem

    Результат выполнения:

    "User "oidc" set."

Проверка пользователя: доступ только к pods в стандартном namespace. Запрос ресурсов из всех namespace#

  1. Получите список nodes во всех namespace, используя аутентификацию через OpenID Connect:

    export KUBECONFIG=~/demo/dapp-infra-ansible-2/config
./kubectl --user=oidc get nodes -A

    Результат выполнения:

    "User "oidc" set."

    Откроется страница в браузере с Dex.

  2. Введите логин и пароль:

    • логин: admin@example.com;

    • пароль: password.

    Результат выполнения:

    # В браузере:
  Authenticated
  You have logged in to the cluster. You can close this window.

# В консоли:
  Error from server (Forbidden): nodes is forbidden: User "https://dex.c02.<repoexample.ru>#admin" cannot list resource "nodes" in API group "" at the cluster scope
  # Укажите актуальный путь до локального репозитория

Создание тестового pod в стандартном namespace, запрос pod пользователем OpenID Connect#

Создайте новый тестовый pod и запросите список pods в стандартном namespace, используя аутентификацию OpenID Connect:

./kubectl run test-pod --image docker.io/hurt/echoip -n default
./kubectl --user=oidc get po -n default

Результат выполнения: пользователь с правами просмотра pods в стандартном namespace получит записи:

NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          20s

Интеграция Dex c Secret Management System#

В стандартной текущей реализации Dex учетные данные берутся из стандартных Kubernetes Secrets. Для получения информации о пользователях из LDAP необходимо подключение под ТУЗ.

В данной версии Dex реализовано получение данных из Secret Management System (SecMan) без sidecar, как делают другие компоненты управления DropApp.