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

Представям на вашето внимание тук туториал за генериране на достъпи до Kubernetes-кластер с помощта на Dex, dex-k8s-authenticator и GitHub.

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

Въведение

Ние използваме Kubernetes за създаване на динамични среди за екипа от разработчици и QA. По този начин, искаме да им предоставим достъп до клъстера както за таблото, така и за kubectl. За разлика от OpenShift, ваниловият Kubernetes няма нативна аутентикация, затова използваме външни средства за това.

В тази конфигурация използваме:

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

Опитахме се да използваме Google OIDC, но за съжаление не успяхме да го настроим с групи, затова интеграцията с GitHub ни удовлетвори. Без мапиране на групи не можем да създадем RBAC-политики, основани на групи. И така, как всъщност работи нашият процес на авторизация в Kubernetes визуално:

Процес на авторизация

Няколко подробности и по точки:

Потребителят влиза в dex-k8s-authenticator (

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

Разбира се, имаме вече инсталиран Kubernetes-кластер (

k8s.example.com), както и предварително инсталиран HELM. Също така, имаме организация в GitHub (super-org).Ако нямате HELM, инсталацията е
много лесна Първо, трябва да настроим GitHub..

Отиваме на страницата с настройки на организацията, (

) и създаваме ново приложение (Authorized OAuth App):https://github.com/organizations/super-org/settings/applicationsСъздаване на ново приложение в GitHub

Попълваме полетата с необходимите URL, например:

Homepage URL:

• Authorization callback URL: https://dex.k8s.example.com
• Внимавайте със ссылките, важно е да не загубите слешовете. https://dex.k8s.example.com/callback

В отговор на попълнената форма, GitHub ще генерира

Client ID Client secret и , запазете ги на безопасно място, те ще ни трябват (например, ние използвамеVault за съхранение на тайни): Client ID: 1ab2c3d4e5f6g7h8 Client secret: 98z76y54x32w1

Подгответе DNS-записи за поддомейните

Подгответе DNS записи за подсайтове dex-k8s-authenticator пренасочва заявката към Dex ( и Dex пренасочва към страницата за авторизация в GitHub, както и 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 < 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 < 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 акаунта си:

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

Страница за авторизация, пренасочена към GitHub

 Следваме генерираните инструкции за получаване на достъп

След като копираме от уеб страницата, можем да използваме 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 в нашата организация могат да виждат ресурсите и да влизат в подовете, но нямат права за тяхната промяна.

Източник: habr.com