ProHoster > Blog > Pentadbiran > Kami mengikat kebenaran LDAP kepada Kubernetes

Kami mengikat kebenaran LDAP kepada Kubernetes

Kami mengikat kebenaran LDAP kepada Kubernetes

Tutorial kecil tentang cara menggunakan Keycloak untuk menyambungkan Kubernetes ke pelayan LDAP anda dan menyediakan import pengguna dan kumpulan. Ini akan membolehkan anda menyediakan RBAC untuk pengguna anda dan menggunakan proksi auth untuk melindungi Papan Pemuka Kubernetes dan aplikasi lain yang tidak tahu cara membenarkan diri mereka sendiri.

Pemasangan Keycloak

Katakan anda sudah mempunyai pelayan LDAP. Ia boleh menjadi Active Directory, FreeIPA, OpenLDAP atau apa sahaja. Jika anda tidak mempunyai pelayan LDAP, maka pada dasarnya anda boleh membuat pengguna secara langsung dalam antara muka Keycloak, atau menggunakan penyedia oidc awam (Google, Github, Gitlab), hasilnya akan hampir sama.

Pertama sekali, mari kita pasang Keycloak sendiri, pemasangan boleh dilakukan secara berasingan, atau terus ke gugusan Kubernetes, sebagai peraturan, jika anda mempunyai beberapa gugusan Kubernetes, lebih mudah untuk memasangnya secara berasingan. Sebaliknya, anda sentiasa boleh menggunakan carta helm rasmi dan pasang terus ke dalam kelompok anda.

Untuk menyimpan data Keycloak, anda memerlukan pangkalan data. Lalainya ialah h2 (semua data disimpan secara tempatan), tetapi ia juga boleh digunakan postgres, mysql atau mariadb.
Jika anda masih memutuskan untuk memasang Keycloak secara berasingan, anda boleh mendapatkan arahan yang lebih terperinci dalam dokumentasi rasmi.

Persediaan Persekutuan

Pertama sekali, mari kita cipta alam baharu. Alam adalah ruang permohonan kami. Setiap aplikasi boleh mempunyai alam sendiri dengan pengguna yang berbeza dan tetapan kebenaran. Alam induk digunakan oleh Keycloak sendiri dan menggunakannya untuk perkara lain adalah salah.

Tolak Tambah alam

Lebih Baik
nilai

Nama
kubernetes

Nama Paparan
Kubernetes

Nama Paparan HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes secara lalai menyemak sama ada e-mel pengguna disahkan atau tidak. Memandangkan kami menggunakan pelayan LDAP kami sendiri, semakan ini hampir selalu akan kembali false. Mari lumpuhkan perwakilan tetapan ini dalam Kubernetes:

Skop pelanggan -> E-mel -> Pemeta -> e-mel disahkan (Padam)

Sekarang mari kita tubuhkan persekutuan, untuk ini kita pergi ke:

Persekutuan pengguna -> Tambahkan pembekal… -> ldap

Berikut ialah contoh persediaan untuk FreeIPA:

Lebih Baik
nilai

Nama Paparan Konsol
freeipa.example.org

Penjual
Red Hat Directory Server

Atribut UUID LDAP
ipauniqueid

URL sambungan
ldaps://freeipa.example.org

DN pengguna
cn=users,cn=accounts,dc=example,dc=org

Bind DN
uid=keycloak-svc,cn=users,cn=accounts,dc=example,dc=org

Ikat Tauliah
<password>

Benarkan pengesahan Kerberos:
on

Alam Kerberos:
EXAMPLE.ORG

Pengetua Pelayan:
HTTP/[email protected]

tab kunci:
/etc/krb5.keytab

Pengguna keycloak-svc mesti dibuat terlebih dahulu pada pelayan LDAP kami.

Dalam kes Active Directory, hanya pilih Penjual: Active Directory dan tetapan yang diperlukan akan dimasukkan ke dalam borang secara automatik.

Tolak Jimat

Sekarang mari kita teruskan:

Persekutuan pengguna -> freeipa.example.org -> Pemeta -> Nama Awalan

Lebih Baik
nilai

Atribut Ldap
givenName

Sekarang dayakan pemetaan kumpulan:

Persekutuan pengguna -> freeipa.example.org -> Pemeta -> Buat

Lebih Baik
nilai

Nama
groups

Jenis Mapper
group-ldap-mapper

Kumpulan LDAP DN
cn=groups,cn=accounts,dc=example,dc=org

Strategi Dapatkan Kumpulan Pengguna
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Ini melengkapkan persediaan persekutuan, mari kita teruskan untuk menyediakan pelanggan.

Persediaan pelanggan

Mari buat klien baharu (aplikasi yang akan menerima pengguna daripada Keycloak). Mari pergi:

Pelanggan -> Buat

Lebih Baik
nilai

ID pelanggan
kubernetes

Jenis Akses
confidenrial

URL akar
http://kubernetes.example.org/

URI Ubah hala yang sah
http://kubernetes.example.org/*

URL Pentadbir
http://kubernetes.example.org/

Kami juga akan membuat skop untuk kumpulan:

Skop pelanggan -> Buat

Lebih Baik
nilai

Templat
No template

Nama
groups

Laluan kumpulan penuh
false

Dan sediakan pemeta untuk mereka:

Skop pelanggan -> kumpulan -> Pemeta -> Buat

Lebih Baik
nilai

Nama
groups

Jenis Pemeta
Group membership

Nama Tuntutan Token
groups

Kini kami perlu mendayakan pemetaan kumpulan dalam skop pelanggan kami:

Pelanggan -> Kubernetes -> Skop pelanggan -> Skop Pelanggan Lalai

pilih kumpulan Π² Skop Pelanggan Tersedia, tekan Tambah yang dipilih

Sekarang mari kita sediakan pengesahan aplikasi kita, pergi ke:

Pelanggan -> Kubernetes

Lebih Baik
nilai

Keizinan Didayakan
ON

Jom tolak menyelamatkan dan ini melengkapkan persediaan pelanggan, kini pada tab

Pelanggan -> Kubernetes -> Bukti kelayakan

anda boleh dapatkan Rahsia yang akan kami gunakan nanti.

Mengkonfigurasi Kubernetes

Menyediakan Kubernetes untuk kebenaran OIDC agak remeh dan bukan sesuatu yang sangat rumit. Apa yang anda perlu lakukan ialah meletakkan sijil CA pelayan OIDC anda /etc/kubernetes/pki/oidc-ca.pem dan tambahkan pilihan yang diperlukan untuk kube-apiserver.
Untuk melakukan ini, kemas kini /etc/kubernetes/manifests/kube-apiserver.yaml pada semua tuanmu:

...
spec:
  containers:
  - command:
    - kube-apiserver
...
    - --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.pem
    - --oidc-client-id=kubernetes
    - --oidc-groups-claim=groups
    - --oidc-issuer-url=https://keycloak.example.org/auth/realms/kubernetes
    - --oidc-username-claim=email
...

Dan juga kemas kini konfigurasi kubeadm dalam kluster supaya tidak kehilangan tetapan ini semasa kemas kini:

kubectl edit -n kube-system configmaps kubeadm-config

...
data:
  ClusterConfiguration: |
    apiServer:
      extraArgs:
        oidc-ca-file: /etc/kubernetes/pki/oidc-ca.pem
        oidc-client-id: kubernetes
        oidc-groups-claim: groups
        oidc-issuer-url: https://keycloak.example.org/auth/realms/kubernetes
        oidc-username-claim: email
...

Ini melengkapkan persediaan Kubernetes. Anda boleh mengulangi langkah ini merentas semua kluster Kubernetes anda.

Keizinan Awal

Selepas langkah ini, anda akan mempunyai gugusan Kubernetes dengan keizinan OIDC dikonfigurasikan. Satu-satunya perkara ialah pengguna anda belum mempunyai pelanggan yang dikonfigurasikan, serta kubeconfig mereka sendiri. Untuk menyelesaikan masalah ini, anda perlu mengkonfigurasi pengeluaran automatik kubeconfig kepada pengguna selepas kebenaran berjaya.

Untuk melakukan ini, anda boleh menggunakan aplikasi web khas yang membolehkan anda mengesahkan pengguna dan kemudian memuat turun kubeconfig yang telah siap. Salah satu yang paling mudah ialah Kuberos, ia membolehkan anda menerangkan semua gugusan Kubernetes dalam satu konfigurasi dan menukar antara mereka dengan mudah.

Untuk mengkonfigurasi Kuberos, cukup untuk menerangkan templat untuk kubeconfig dan menjalankannya dengan parameter berikut:

kuberos https://keycloak.example.org/auth/realms/kubernetes kubernetes /cfg/secret /cfg/template

Untuk butiran lanjut lihat Penggunaan pada Github.

Ia juga boleh digunakan kubelogin jika anda ingin memberi kebenaran terus pada komputer pengguna. Dalam kes ini, pengguna akan membuka pelayar dengan borang kebenaran pada localhost.

Kubeconfig yang terhasil boleh disemak di tapak jwt.io. Salin sahaja nilainya users[].user.auth-provider.config.id-token daripada kubeconfig anda kepada borang di tapak dan dapatkan transkrip dengan segera.

Persediaan RBAC

Apabila mengkonfigurasi RBAC, anda boleh merujuk kepada kedua-dua nama pengguna (medan name dalam token jwt) dan untuk sekumpulan pengguna (field groups dalam token jwt). Berikut ialah contoh menetapkan kebenaran untuk kumpulan kubernetes-default-namespace-admins:

kubernetes-default-namespace-admins.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: default-admins
  namespace: default
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-default-namespace-admins
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: default-admins
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: kubernetes-default-namespace-admins

Lebih banyak contoh untuk RBAC boleh didapati dalam dokumentasi rasmi Kubernetes

Menetapkan proksi pengesahan

Terdapat projek yang indah penjaga pintu kunci, yang membolehkan anda melindungi mana-mana aplikasi dengan membenarkan pengguna untuk mengesahkan ke pelayan OIDC. Saya akan menunjukkan kepada anda cara anda boleh menyediakannya menggunakan Papan Pemuka Kubernetes sebagai contoh:

papan pemuka-proksi.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: kubernetes-dashboard-proxy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kubernetes-dashboard-proxy
    spec:
      containers:
      - args:
        - --listen=0.0.0.0:80
        - --discovery-url=https://keycloak.example.org/auth/realms/kubernetes
        - --client-id=kubernetes
        - --client-secret=<your-client-secret-here>
        - --redirection-url=https://kubernetes-dashboard.example.org
        - --enable-refresh-tokens=true
        - --encryption-key=ooTh6Chei1eefooyovai5ohwienuquoh
        - --upstream-url=https://kubernetes-dashboard.kube-system
        - --resources=uri=/*
        image: keycloak/keycloak-gatekeeper
        name: kubernetes-dashboard-proxy
        ports:
        - containerPort: 80
          livenessProbe:
            httpGet:
              path: /oauth/health
              port: 80
            initialDelaySeconds: 3
            timeoutSeconds: 2
          readinessProbe:
            httpGet:
              path: /oauth/health
              port: 80
            initialDelaySeconds: 3
            timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard-proxy
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: kubernetes-dashboard-proxy
  type: ClusterIP

Sumber: www.habr.com

Tambah komen