Fissiamo l'autorizzazione LDAP a Kubernetes

Fissiamo l'autorizzazione LDAP a Kubernetes

Un piccolo tutorial su come utilizzare Keycloak per connettere Kubernetes al tuo server LDAP e impostare l'importazione di utenti e gruppi. Ciò ti consentirà di configurare RBAC per i tuoi utenti e utilizzare auth-proxy per proteggere Kubernetes Dashboard e altre applicazioni che non sanno come autorizzarsi.

Installazione del portachiavi

Supponiamo che tu abbia già un server LDAP. Potrebbe essere Active Directory, FreeIPA, OpenLDAP o qualsiasi altra cosa. Se non disponi di un server LDAP, in linea di principio puoi creare utenti direttamente nell'interfaccia Keycloak o utilizzare provider oidc pubblici (Google, Github, Gitlab), il risultato sarà quasi lo stesso.

Prima di tutto, installiamo Keycloak stesso, l'installazione può essere eseguita separatamente o direttamente sul cluster Kubernetes, di norma, se disponi di più cluster Kubernetes, sarebbe più semplice installarlo separatamente. D'altra parte, puoi sempre usare carta ufficiale del timone e installalo direttamente nel tuo cluster.

Per archiviare i dati di Keycloak, avrai bisogno di un database. L'impostazione predefinita è h2 (tutti i dati sono archiviati localmente), ma è anche possibile utilizzarli postgres, mysql o mariadb.
Se decidi comunque di installare Keycloak separatamente, puoi trovare istruzioni più dettagliate in documentazione ufficiale.

Configurazione della federazione

Prima di tutto, creiamo un nuovo regno. Il regno è lo spazio della nostra applicazione. Ogni applicazione può avere il proprio ambito con utenti e impostazioni di autorizzazione diversi. Il regno principale viene utilizzato dallo stesso Keycloak e utilizzarlo per qualsiasi altra cosa è sbagliato.

Clicca qui Aggiungi regno

Opzione
Valore

Nome
kubernetes

Display Nome
Kubernetes

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

Kubernetes controlla per impostazione predefinita se l'e-mail dell'utente è confermata o meno. Poiché utilizziamo il nostro server LDAP, questo controllo verrà quasi sempre restituito false. Disabilitiamo la rappresentazione di questa impostazione in Kubernetes:

Ambiti del cliente -> E-mail -> Mappatori -> email verificata (Elimina)

Ora impostiamo la federazione, per questo andiamo a:

Federazione degli utenti -> Aggiungi fornitore... -> ldap

Ecco un esempio di configurazione per FreeIPA:

Opzione
Valore

Nome visualizzato della console
freeipa.example.org

Venditore
Red Hat Directory Server

Attributo LDAP UUID
ipauniqueid

URL di connessione
ldaps://freeipa.example.org

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

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

Associa credenziali
<password>

Consenti l'autenticazione Kerberos:
on

Regno di Kerberos:
EXAMPLE.ORG

Principale server:
HTTP/[email protected]

scheda chiave:
/etc/krb5.keytab

Utilizzatore keycloak-svc deve essere creato in anticipo sul nostro server LDAP.

Nel caso di Active Directory, seleziona semplicemente Fornitore: Active Directory e le impostazioni necessarie verranno inserite automaticamente nel modulo.

Clicca qui Risparmi

Adesso andiamo avanti:

Federazione degli utenti -> freeipa.esempio.org -> Mappatori -> Nome

Opzione
Valore

Attributi LDAP
givenName

Ora abilita la mappatura del gruppo:

Federazione degli utenti -> freeipa.esempio.org -> Mappatori -> Creare

Opzione
Valore

Nome
groups

Tipo di mappatore
group-ldap-mapper

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

Strategia di recupero del gruppo di utenti
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Questo completa la configurazione della federazione, passiamo alla configurazione del client.

Configurazione del cliente

Creiamo un nuovo client (un'applicazione che riceverà gli utenti da Keycloak). Andiamo:

Clienti -> Creare

Opzione
Valore

ID cliente
kubernetes

Tipo di accesso
confidenrial

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

URI di reindirizzamento validi
http://kubernetes.example.org/*

URL di amministrazione
http://kubernetes.example.org/

Creeremo anche un ambito per i gruppi:

Ambiti cliente -> Creare

Opzione
Valore

Modello
No template

Nome
groups

Percorso completo di gruppo
false

E imposta un mappatore per loro:

Ambiti cliente -> gruppi -> Mappatori -> Creare

Opzione
Valore

Nome
groups

Tipo di mappatore
Group membership

Nome richiesta token
groups

Ora dobbiamo abilitare la mappatura dei gruppi nel nostro ambito client:

Clienti -> kubernetes -> Ambiti cliente -> Ambiti client predefiniti

selezionare gruppi в Ambiti client disponibili, stampa Aggiungi selezionato

Ora impostiamo l'autenticazione della nostra applicazione, andiamo su:

Clienti -> kubernetes

Opzione
Valore

Autorizzazione abilitata
ON

Spingiamo salvare e questo completa la configurazione del client, ora nella scheda

Clienti -> kubernetes -> Credenziali

Puoi prendere Segreto che utilizzeremo in seguito.

Configurazione di Kubernetes

Configurare Kubernetes per l'autorizzazione OIDC è abbastanza banale e non molto complicato. Tutto quello che devi fare è inserire il certificato CA del tuo server OIDC /etc/kubernetes/pki/oidc-ca.pem e aggiungi le opzioni necessarie per kube-apiserver.
Per fare ciò, aggiorna /etc/kubernetes/manifests/kube-apiserver.yaml su tutti i tuoi master:

...
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
...

E aggiorna anche la configurazione di kubeadm nel cluster per non perdere queste impostazioni durante l'aggiornamento:

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
...

Questo completa la configurazione di Kubernetes. Puoi ripetere questi passaggi su tutti i tuoi cluster Kubernetes.

Autorizzazione iniziale

Dopo questi passaggi, avrai già configurato un cluster Kubernetes con l'autorizzazione OIDC. L'unico punto è che i tuoi utenti non hanno ancora un client configurato, così come il proprio kubeconfig. Per risolvere questo problema, è necessario configurare l'emissione automatica di kubeconfig agli utenti dopo aver effettuato con successo l'autorizzazione.

Per fare ciò è possibile utilizzare apposite applicazioni web che consentono di autenticare l'utente e quindi scaricare il kubeconfig finito. Uno dei più convenienti è Kuberos, ti consente di descrivere tutti i cluster Kubernetes in un'unica configurazione e di passare facilmente da uno all'altro.

Per configurare Kuberos è sufficiente descrivere il template per kubeconfig ed eseguirlo con i seguenti parametri:

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

Per maggiori dettagli vedere Impiego su Github.

È anche possibile utilizzare kubelogin se vuoi autorizzare direttamente sul computer dell'utente. In questo caso l'utente aprirà un browser con un modulo di autorizzazione su localhost.

Il kubeconfig risultante può essere controllato sul sito jwt.io. Basta copiare il valore users[].user.auth-provider.config.id-token dal tuo kubeconfig a un modulo sul sito e ottieni subito la trascrizione.

Configurazione dell'RBAC

Durante la configurazione di RBAC è possibile fare riferimento sia al nome utente (campo name nel token jwt) e per un gruppo di utenti (field groups nel token jwt). Ecco un esempio di impostazione delle autorizzazioni per un gruppo 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

Altri esempi di RBAC possono essere trovati in documentazione ufficiale di Kubernetes

Impostazione del proxy di autenticazione

C'è un progetto meraviglioso custode del mantello delle chiavi, che consente di proteggere qualsiasi applicazione consentendo all'utente di autenticarsi sul server OIDC. Ti mostrerò come configurarlo utilizzando la dashboard Kubernetes come esempio:

dashboard-proxy.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

Fonte: habr.com

Aggiungi un commento