Colleghiamo l'autenticazione LDAP a Kubernetes.

Una breve guida su come utilizzare Keycloak per collegare Kubernetes al vostro server LDAP e configurare l'importazione di utenti e gruppi. Questo permetterà di impostare RBAC per i vostri utenti e utilizzare l'auth-proxy per proteggere il Kubernetes Dashboard e altre applicazioni che non possono gestire l'autenticazione da sole.

Installazione di Keycloak

Supponiamo che abbiate già un server LDAP. Può essere Active Directory, FreeIPA, OpenLDAP o altro. Se non avete un server LDAP, in effetti potete creare utenti direttamente nell'interfaccia di Keycloak, oppure utilizzare provider oidc pubblici (Google, Github, Gitlab), il risultato sarà praticamente lo stesso.

Per prima cosa installiamo Keycloak. L'installazione può essere eseguita separatamente o direttamente nel cluster Kubernetes. In genere, se avete più cluster Kubernetes, sarebbe più semplice installarlo separatamente. D'altra parte, potete sempre utilizzare il chart helm ufficiale e installarlo direttamente nel vostro cluster.

Per memorizzare i dati di Keycloak avrete bisogno di un database. Di default viene utilizzato h2 (tutti i dati sono memorizzati localmente), ma è possibile utilizzare anche postgres, mysql o mariadb.
Se hai deciso di installare Keycloak separatamente, troverai istruzioni più dettagliate in documentazione ufficiale.

Configurazione della federazione

Per prima cosa, creiamo un nuovo realm. Un realm è uno spazio della nostra applicazione. Ogni applicazione può avere il proprio realm con diversi utenti e impostazioni di autorizzazione. Il realm master è utilizzato da Keycloak stesso e non è corretto utilizzarlo per altro.

Clicchiamo su Aggiungi realm

Opzione
Valore

Name
kubernetes

Nome visualizzato
Kubernetes

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

Kubernetes per impostazione predefinita verifica se l'email dell'utente è stata confermata o meno. Poiché stiamo usando un server LDAP proprietario, questa verifica restituirà quasi sempre false. Disattiviamo la visualizzazione di questo parametro in Kubernetes:

Client scopes —> Email —> Mappers —> Email verificata (Elimina)

Ora configuriamo la federazione, quindi andiamo a:

Federazione utenti —> Aggiungi fornitore… —> ldap

Ecco un esempio di configurazione per FreeIPA:

Opzione
Valore

Nome visualizzato della console
freeipa.example.org

Fornitore
Red Hat Directory Server

Attributo UUID LDAP
ipauniqueid

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

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

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

Credenziale di bind
<password>

Consenti l'autenticazione Kerberos:
on

Realm Kerberos:
EXAMPLE.ORG

Server Principal:
HTTP/freeipa.example.org@EXAMPLE.ORG

KeyTab:
/etc/krb5.keytab

L'utente keycloak-svc deve essere creato in anticipo sul nostro server LDAP.

Nel caso di Active Directory, è sufficiente selezionare Fornitore: Active Directory e le impostazioni necessarie verranno automaticamente inserite nel modulo.

Clicchiamo su Salva

Ora passiamo a:

Federazione utenti —> freeipa.example.org —> Mappers —> Nome

Opzione
Valore

Attributo LDAP
givenName

Ora abilitiamo il mapping dei gruppi:

Federazione utenti —> freeipa.example.org —> Mappers —> Crea

Opzione
Valore

Name
groups

Tipo di mapper
group-ldap-mapper

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

Strategia di recupero dei gruppi utente
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE

Questa è la conclusione della configurazione della federazione, passiamo alla configurazione del client.

Configurazione del client

Creeremo un nuovo client (l'applicazione che riceverà utenti da Keycloak). Passiamo a:

Clienti —> Crea

Opzione
Valore

ID del Client
kubernetes

Tipo di accesso
confidenziale

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

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

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

Creeremo anche uno scope per i gruppi:

Scope del client —> Crea

Opzione
Valore

Template
Nessun modello

Name
groups

Percorso completo del gruppo
false

E configureremo il mapper per essi:

Scope del client —> groups —> Mappers —> Crea

Opzione
Valore

Name
groups

Tipo di mapper
Appartenenza al gruppo

Nome di reclamo del token
groups

Ora dobbiamo abilitare il mapping dei gruppi nel nostro client scope:

Clienti —> kubernetes —> Scope del client —> Scope client predefiniti

Selezioniamo groups in Scope client disponibili, facciamo clic su Aggiungi selezionati

Ora configuriamo l'autenticazione della nostra applicazione, passiamo a:

Clienti —> kubernetes

Opzione
Valore

Autorizzazione abilitata
ON

Facciamo clic su salva e con questo la configurazione del client è completata, ora nella scheda

Clienti —> kubernetes —> Credenziali

potrete ottenere Secret che utilizzeremo in seguito.

Configurazione di Kubernetes

La configurazione di Kubernetes per l'autenticazione OIDC è piuttosto semplice e non presenta nulla di complesso. tutto ciò di cui avete bisogno è posizionare il certificato CA del vostro server OIDC in /etc/kubernetes/pki/oidc-ca.pem e aggiungere le opzioni necessarie per kube-apiserver.
Per fare ciò, aggiornate /etc/kubernetes/manifests/kube-apiserver.yaml su tutti i vostri nodi 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
...

Inoltre, aggiornate il file di configurazione 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
...

A questo punto la configurazione di Kubernetes è completata. Potete ripetere queste azioni in tutti i vostri cluster Kubernetes.

Autenticazione iniziale

Dopo queste operazioni avrete un cluster Kubernetes con l'autenticazione OIDC configurata. L'unico problema è che i vostri utenti non hanno ancora un client configurato né un proprio kubeconfig. Per risolvere questo problema, dovete impostare la generazione automatica del kubeconfig per gli utenti dopo l'autenticazione riuscita.

A questo scopo è possibile utilizzare applicazioni web speciali che consentono di autenticare l'utente e poi scaricare il kubeconfig pronto. Una delle più comode è Kuberos, 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 e avviarlo con i seguenti parametri:

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

Per informazioni più dettagliate, consulta Utilizzo GitHub.

È anche possibile utilizzare kubelogin se desideri eseguire l'autenticazione direttamente sul computer dell'utente. In questo caso, si aprirà un browser con un modulo di autenticazione su localhost.

Il kubeconfig ottenuto può essere controllato sul sito jwt.io. Basta copiare il valore users[].user.auth-provider.config.id-token dal tuo kubeconfig nel modulo sul sito e ottenere immediatamente la decodifica.

Configurazione RBAC

Durante la configurazione di RBAC, puoi fare riferimento sia al nome utente (campo name nel token jwt), sia al gruppo di utenti (campo groups nel token jwt). Ecco un esempio di configurazione dei diritti per il 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

Ulteriori esempi per RBAC possono essere trovati in documentazione ufficiale di Kubernetes

Configurazione auth-proxy

C'è un ottimo progetto keycloak-gatekeeper, che consente di proteggere qualsiasi applicazione, offrendo all'utente la possibilità di autenticarsi su un server OIDC. Mostrerò come configurarlo utilizzando l'esempio di Kubernetes Dashboard:

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