Аутентификация в Kubernetes с помощью GitHub OAuth и Dex

https://medium.com/preply-engineering/k8s-auth-a81f59d4dff6
  • Перевод
  • Tutorial
Представляю вашему вниманию туториал для генерации доступов к Kubernetes-кластеру с помощью Dex, dex-k8s-authenticator и GitHub.

image

Локальный мем из русскоязычного чата Kubernetes в Telegram

Введение


Мы используем Kubernetes для создания динамических окружений для команды разработчиков и QA. Таким образом, мы хотим предоставить им доступ к кластеру как для дашборда, так и для kubectl. В отличие от того же OpenShift, ванильный Kubernetes не имеет нативной аутентификации, поэтому мы используем для этого сторонние средства.

В данной конфигурации мы используем:

  • dex-k8s-authenticator  — веб-приложение для генерации конфига kubectl
  • Dex — провайдер OpenID Connect
  • GitHub — просто потому-что мы используем GitHub в нашей компании

Мы пытались использовать Google OIDC, но к сожалению нам не удалось завести их с группами, поэтому интеграция с GitHub нас вполне устроила. Без маппинга групп не удасться создать RBAC-политики основанные на группах.

Итак, как же работает наш процесс авторизации в Kubernetes в визуальном представлении:

image
Процесс авторизации

Немного подробнее и по пунктам:

  1. Пользователь входит в dex-k8s-authenticator (login.k8s.example.com)
  2. dex-k8s-authenticator перенаправляет запрос в Dex (dex.k8s.example.com)
  3. Dex перенаправляет на страницу авторизации в GitHub
  4. GitHub генерирует необходимую информацию об авторизации и возвращает ее в Dex
  5. Dex передает полученную информацию в dex-k8s-authenticator
  6. Пользователь получает OIDC token от GitHub
  7. dex-k8s-authenticator добавляет токен в kubeconfig
  8. kubectl передает токен в KubeAPIServer
  9. KubeAPIServer на основе переданного токена возвращает доступы в kubectl
  10. Пользователь получает доступы от kubectl

Подготовительные действия


Само собой у нас уже установлен Kubernetes-кластер (k8s.example.com), а также предустановлен HELM. Также у нас есть организация в GitHub (super-org).
Если у вас нет HELM, устанавливается он очень просто.

Сначала нам необходимо настроить GitHub.

Переходим на страницу настроек организации, (https://github.com/organizations/super-org/settings/applications) и создаем новое приложение (Authorized OAuth App):
image
Создание нового приложения в GitHub

Заполняем поля необходимыми URL, например:

  • Homepage URL: https://dex.k8s.example.com
  • Authorization callback URL: https://dex.k8s.example.com/callback

Будьте внимательны с ссылками, важно не потерять слеши.

В ответ на заполненную форму, GitHub сгенерирует Client ID и Client secret, сохраните их в надежном месте, они нам пригодятся (мы например используем Vault для хранения секретов):

Client ID: 1ab2c3d4e5f6g7h8
Client secret: 98z76y54x32w1

Подготовьте DNS-записи для субдоменов login.k8s.example.com и dex.k8s.example.com, а также SSL-сертификаты для ингрессов.

Создадим SSL-сертификаты:

cat <<EOF | kubectl create -f -
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: cert-auth-dex
  namespace: kube-system
spec:
  secretName: cert-auth-dex
  dnsNames:
    - dex.k8s.example.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - dex.k8s.example.com
  issuerRef:
    name: le-clusterissuer
    kind: ClusterIssuer
---
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: cert-auth-login
  namespace: kube-system
spec:
  secretName: cert-auth-login
  dnsNames:
    - login.k8s.example.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - login.k8s.example.com
  issuerRef:
    name: le-clusterissuer
    kind: ClusterIssuer
EOF
kubectl describe certificates cert-auth-dex -n kube-system
kubectl describe certificates cert-auth-login -n kube-system

ClusterIssuer с названием le-clusterissuer уже должен существовать, если же нет — создадим его с помощью HELM:

helm install --namespace kube-system -n cert-manager stable/cert-manager
cat << EOF | kubectl create -f -
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: le-clusterissuer
  namespace: kube-system
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: k8s-admin@example.com
    privateKeySecretRef:
      name: le-clusterissuer
    http01: {}
EOF

Конфигурация KubeAPIServer


Для работы kubeAPIServer необходимо сконфигурировать OIDC и обновить кластер:

kops edit cluster
...
  kubeAPIServer:
    anonymousAuth: false
    authorizationMode: RBAC
    oidcClientID: dex-k8s-authenticator
    oidcGroupsClaim: groups
    oidcIssuerURL: https://dex.k8s.example.com/
    oidcUsernameClaim: email
kops update cluster --yes
kops rolling-update cluster --yes

Мы используем kops для разворачивания кластеров, но это аналогично работает и для других менеджеров кластеров.

Конфигурация Dex и dex-k8s-authenticator


Для работы Dex необходимо иметь сертификат и ключ с Kubernetes-мастера, вытащим его оттуда:

sudo cat /srv/kubernetes/ca.{crt,key}
-----BEGIN CERTIFICATE-----
AAAAAAAAAAABBBBBBBBBBCCCCCC
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
DDDDDDDDDDDEEEEEEEEEEFFFFFF
-----END RSA PRIVATE KEY-----

Склонируем репозиторий dex-k8s-authenticator:

git clone git@github.com:mintel/dex-k8s-authenticator.git
cd dex-k8s-authenticator/

С помощью values-файлов мы можем гибко настраивать переменные для наших HELM-чартов.

Опишем конфигурацию для Dex:

cat << \EOF > values-dex.yml
global:
  deployEnv: prod
tls:
  certificate: |-
    -----BEGIN CERTIFICATE-----
    AAAAAAAAAAABBBBBBBBBBCCCCCC
    -----END CERTIFICATE-----
  key: |-
    -----BEGIN RSA PRIVATE KEY-----
    DDDDDDDDDDDEEEEEEEEEEFFFFFF
    -----END RSA PRIVATE KEY-----
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
  path: /
  hosts:
    - dex.k8s.example.com
  tls:
    - secretName: cert-auth-dex
    hosts:
      - dex.k8s.example.com
serviceAccount:
  create: true
  name: dex-auth-sa
config: |
  issuer: https://dex.k8s.example.com/
  storage: # https://github.com/dexidp/dex/issues/798
    type: sqlite3
    config:
      file: /var/dex.db
  web:
    http: 0.0.0.0:5556
  frontend:
    theme: "coreos"
     issuer: "Example Co"
     issuerUrl: "https://example.com"
     logoUrl: https://example.com/images/logo-250x25.png
  expiry:
    signingKeys: "6h"
    idTokens: "24h"
  logger:
    level: debug
    format: json
  oauth2:
    responseTypes: ["code", "token", "id_token"]
    skipApprovalScreen: true
  connectors:
  - type: github
    id: github
    name: GitHub
    config:
      clientID: $GITHUB_CLIENT_ID
      clientSecret: $GITHUB_CLIENT_SECRET
      redirectURI: https://dex.k8s.example.com/callback
      orgs:
      - name: super-org
        teams:
        - team-red
  staticClients:
  - id: dex-k8s-authenticator
    name: dex-k8s-authenticator
    secret: generatedLongRandomPhrase
  redirectURIs:
    - https://login.k8s.example.com/callback/
envSecrets:
  GITHUB_CLIENT_ID: "1ab2c3d4e5f6g7h8"
  GITHUB_CLIENT_SECRET: "98z76y54x32w1"
EOF

И для dex-k8s-authenticator:
cat << EOF > values-auth.yml
global:
  deployEnv: prod
dexK8sAuthenticator:
  clusters:
  - name: k8s.example.com
    short_description: "k8s cluster"
    description: "Kubernetes cluster"
    issuer: https://dex.k8s.example.com/
    k8s_master_uri: https://api.k8s.example.com
    client_id: dex-k8s-authenticator
    client_secret: generatedLongRandomPhrase
    redirect_uri: https://login.k8s.example.com/callback/
    k8s_ca_pem: |
    -----BEGIN CERTIFICATE-----
    AAAAAAAAAAABBBBBBBBBBCCCCCC
    -----END CERTIFICATE-----
ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
  path: /
  hosts:
    - login.k8s.example.com
  tls:
    - secretName: cert-auth-login
      hosts:
        - login.k8s.example.com
EOF

Установим Dex и dex-k8s-authenticator:

helm install -n dex --namespace kube-system --values values-dex.yml charts/dex
helm install -n dex-auth --namespace kube-system --values values-auth.yml charts/dex-k8s-authenticator

Проверим работоспособность сервисов (Dex должен вернуть код 400, а dex-k8s-authenticator — код 200):

curl -sI https://dex.k8s.example.com/callback | head -1
HTTP/2 400
curl -sI https://login.k8s.example.com/ | head -1
HTTP/2 200

RBAC-конфигурация


Создаем ClusterRole для группы, в нашем случае с read-only доступами:

cat << EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-read-all
rules:
  -
    apiGroups:
      - ""
      - apps
      - autoscaling
      - batch
      - extensions
      - policy
      - rbac.authorization.k8s.io
      - storage.k8s.io
    resources:
      - componentstatuses
      - configmaps
      - cronjobs
      - daemonsets
      - deployments
      - events
      - endpoints
      - horizontalpodautoscalers
      - ingress
      - ingresses
      - jobs
      - limitranges
      - namespaces
      - nodes
      - pods
      - pods/log
      - pods/exec
      - persistentvolumes
      - persistentvolumeclaims
      - resourcequotas
      - replicasets
      - replicationcontrollers
      - serviceaccounts
      - services
      - statefulsets
      - storageclasses
      - clusterroles
      - roles
    verbs:
      - get
      - watch
      - list
  - nonResourceURLs: ["*"]
    verbs:
      - get
      - watch
      - list
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
EOF

Создадим конфигурацию для ClusterRoleBinding:

cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: dex-cluster-auth
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-read-all
subjects:
  - kind: Group
  name: "super-org:team-red"
EOF

Теперь мы готовы к тестированию.

Тесты


Переходим на страницу логина (https://login.k8s.example.com) и авторизуемся с помощью GitHub-аккаунта:

image
Страница авторизации

image
Страница авторизации перенаправленная на GitHub

image
 Следуем сгенерированной инструкции для получения доступов

После копипасты с веб-страницы мы можем использовать kubectl для управления ресурсами нашего кластера:

kubectl get po
NAME                READY   STATUS    RESTARTS   AGE
mypod               1/1     Running   0          3d

kubectl delete po mypod
Error from server (Forbidden): pods "mypod" is forbidden: User "amet@example.com" cannot delete pods in the namespace "default"

И это работает, все пользователи GitHub в нашей организации могут видеть ресурсы и входить в поды, однако они не имеют прав на их изменение.
Поделиться публикацией

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

    +1
    Спасибо за статью, как раз возникла необходимость настроить авторизацию используя oauth2.
    Возможно задавались вопросом как с помощью dex сделать возможным добавление ingress oauth2 с минимальными затратами?
    Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.
      0
      Вам нужна именно авторизация (не аутентификация)?
      Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.

      Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.

      Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
        0
        В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups. Немного контекста: занимаюсь настройкой dev площадки, планируется использование kube для динамического создания окружений, плюс там же нужен мониторинг этих окружений. Разграничение которое хотелось бы иметь это возможность давать доступ к мониторингу пользователям из групп dev/devops, к окружениям для тестирования — всем кто прошел авторизацию, но думаю если учесть сложность реализации такого решения и получаемой выгоды необходимость этого выглядит сомнительно.

        Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).

        Не хотелось этого делать во избежания дублирования одинаковых приложений и экономии ресурсов, но это не принципиально. Для избежания дублирования возможно использовать FQDN сервиса авторизации в аннотации к ingress(решение отсюда) что решает проблему.
          0
          В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups.

          Dex это умеет для групп (организации и команды в GitHub, группы в Microsoft accounts), для каждой группы будет своя RBAC-политика. Мы хотели сделать такое с гуглом, но не заработало. Хотели отказаться от basic auth и закрыть все с белым листов айпишников, но нужно в вайтлист добавлять много айпишников и создавать internal LB.

          Кейс у Вас в принципе похож с нашим.
          По ссылке отличное решение, но у нас немного по-другому, у нас на приложение стоит basic auth, которое конфиг-сниппетом отключается его для офисных адресов и VPN.
            0
            C basic auth и white-list была идея написать небольшой контроллер, который бы дописывал нужные аннотации к dev ingress'ам чтобы избежать опять же ручной работы, но пока это все на стадии идеи:)
            Спасибо Вам за советы!
        0
        можно обойтись одним oauth2_proxy и ингрессами с Auth Request. смотрите сюда
        thenewstack.io/single-sign-on-for-kubernetes-dashboard-experience
        github.com/pusher/oauth2_proxy/tree/whitelist-domains
        пример ингресса:
        apiVersion: extensions/v1beta1
        kind: Ingress
        metadata:
          annotations:
            nginx.ingress.kubernetes.io/auth-url: "https://OAUTH2_PROXY_ADDRESS/oauth2/auth"
            nginx.ingress.kubernetes.io/auth-signin: "https://OAUTH2_PROXY_ADDRESS/oauth2/start?rd=https://$host$request_uri$is_args$args"
            nginx.ingress.kubernetes.io/configuration-snippet: |
               auth_request_set $token $upstream_http_authorization;
               proxy_set_header Authorization $token;
          name: dashboard 
          namespace: kube-system
        spec:
          rules:
          - host: ADDRESS
            http:
              paths:
              - backend:
                  serviceName: kubernetes-dashboard
                  servicePort: 80
                path: /
          tls:
          - secretName: SECRET
            hosts:
              - ADDRESS


        со стороны oauth2_proxy:
                args:
                - --email-domain=example.com
                - --upstream=file:///dev/null
                - --http-address=0.0.0.0:8080
                - --redirect-url=https://OAUTH2_PROXY_ADDRESS/oauth2/callback
                - --provider=oidc
                - --oidc-issuer-url=https://DEX_ADDRESS
                - --cookie-domain=.example.com
                - --whitelist-domain=.example.com
                - --pass-authorization-header=true
                - --set-authorization-header=true
                - --pass-basic-auth=false
                - --pass-access-token=false
        

        правда я смержил whitelist-domains с мастером и сбилдил свой имэдж что бы были и --pass-authorization-header с --set-authorization-header и --whitelist-domain
          0
          Мы используем такую же схему для Dashboard, для kubectl такое сделать не получится.
            0
            почему не получится? у нас сейчас реализовано именно так. oauth2_proxy и dex находятся в одном месте, так же как и dexK8sAuthenticator. Дkя дашбордов ингрессы в один auth2_proxy. на всех кластерах прописан oidc один dex. в dexK8sAuthenticator в configmap добавлены несколько кластеров для генерации всего в одном месте
              0
              Да, я неправильно понял кейс. У Вас же несколько кластеров.
        0
        storage наверное лучше сделать kubernetes а не локальный sqlite
          0
          У нас с local storage не работало, там баг был вроде, а с sqlite заработало.

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

        Самое читаемое