Implementando autorización LDAP en Kubernetes

Implementando autorización LDAP en Kubernetes

Pequeña guía sobre cómo utilizar Keycloak para vincular Kubernetes con su servidor LDAP y configurar la importación de usuarios y grupos. Esto permitirá configurar RBAC para sus usuarios y utilizar auth-proxy para proteger el panel de control de Kubernetes y otras aplicaciones que no pueden realizar la autorización por sí mismas.

Instalación de Keycloak

Supongamos que ya tiene un servidor LDAP. Puede ser Active Directory, FreeIPA, OpenLDAP o cualquier otro. Si no tiene un servidor LDAP, puede crear usuarios directamente en la interfaz de Keycloak, o usar proveedores oidc públicos (Google, GitHub, GitLab), el resultado será casi el mismo.

Primero instalaremos Keycloak, la instalación se puede realizar de forma independiente o directamente en el clúster de Kubernetes; por lo general, si tiene varios clústeres de Kubernetes, sería más sencillo instalarlo de forma independiente. Por otro lado, siempre puede utilizar el chart helm oficial y instalarlo directamente en su clúster.

Para almacenar los datos de Keycloak necesitará una base de datos. Por defecto, se utiliza h2 (todos los datos se almacenan localmente), pero también es posible utilizar postgres, mysql o mariadb.
Si finalmente ha decidido instalar Keycloak de forma independiente, encontrará instrucciones más detalladas en documentación oficial.

Configuración de la federación

Primero crearemos un nuevo realm. Un realm es el espacio de nuestra aplicación. Cada aplicación puede tener su propio realm con diferentes usuarios y configuraciones de autorización. El realm principal es utilizado por Keycloak mismo y no es correcto usarlo para nada más.

Hacemos clic en Añadir reino

Opción
Value

Nombre
kubernetes

Nombre para mostrar
Kubernetes

Nombre de visualización HTML
<img src="https://kubernetes.io/images/nav_logo.svg" width="400" >

Kubernetes verifica por defecto si el email del usuario está confirmado o no. Dado que usamos nuestro propio servidor LDAP, esta verificación casi siempre devolverá false. Vamos a desactivar la visualización de este parámetro en Kubernetes:

Ámbitos de cliente —> Correo Electrónico —> Mapeadores —> Email verificado (Eliminar)

Ahora configuraremos la federación, para ello vayamos a:

Federación de usuarios —> Agregar proveedor… —> ldap

Daré un ejemplo de configuración para FreeIPA:

Opción
Value

Nombre de visualización en consola
freeipa.ejemplo.org

Proveedor
Red Hat Directory Server

Atributo UUID LDAP
ipauniqueid

URL de conexión
ldaps://freeipa.example.org

DN de usuarios
cn=users,cn=accounts,dc=ejemplo,dc=org

DN de enlace
uid=keycloak-svc,cn=users,cn=accounts,dc=ejemplo,dc=org

Credencial de enlace
<contraseña>

Permitir autenticación Kerberos:
on

Reino Kerberos:
EJEMPLO.ORG

Principal del servidor:
HTTP/freeipa.ejemplo.org@EJEMPLO.ORG

KeyTab:
/etc/krb5.keytab

El usuario keycloak-svc debe ser creado previamente en nuestro servidor LDAP.

En el caso de Active Directory, simplemente seleccione Proveedor: Active Directory y la configuración necesaria se completará automáticamente en el formulario.

Hacemos clic en Guardar

Ahora vayamos a:

Federación de usuarios —> freeipa.ejemplo.org —> Mapeadores —> Nombre

Opción
Value

atributo Ldap
givenName

Ahora activaremos el mapeo de grupos:

Federación de usuarios —> freeipa.ejemplo.org —> Mapeadores —> Crear

Opción
Value

Nombre
groups

Tipo de mapeador
mapeador-grupo-ldap

DN de grupos LDAP
cn=groups,cn=accounts,dc=example,dc=org

Estrategia de recuperación de grupos de usuarios
OBTENER_GRUPOS_DEL_ATTRIBUTO_MEMBEROF_DEL_USUARIO

Con esto, la configuración de federación ha terminado, pasemos a la configuración del cliente.

Configuración del cliente

Crearemos un nuevo cliente (una aplicación que recibirá usuarios de Keycloak). Vamos a:

Clientes —> Crear

Opción
Value

Client ID
kubernetes

Tipo de acceso
confidencial

URL raíz
http://kubernetes.example.org/

URI de redirección válidas
http://kubernetes.example.org/*

URL de administración
http://kubernetes.example.org/

También crearemos un scope para grupos:

Alcances del cliente —> Crear

Opción
Value

Plantilla
Sin plantilla

Nombre
groups

Ruta completa del grupo
false

Y configuraremos un mapeador para ellos:

Alcances del cliente —> groups —> Mapeadores —> Crear

Opción
Value

Nombre
groups

Tipo de mapeador
Membresía de grupo

Nombre de reclamo del token
groups

Ahora necesitamos habilitar el mapeo de grupos en nuestro scope de cliente:

Clientes —> kubernetes —> Alcances del cliente —> Alcances de cliente predeterminados

Seleccionamos groups en Client Scopes Disponibles, hacemos clic en Añadir seleccionados

Ahora configuraremos la autenticación de nuestra aplicación, vamos a:

Clientes —> kubernetes

Opción
Value

Autorización habilitada
las vistas materializadas no pueden tener tablas detalle remotas.

Haremos clic en guardar y con esto la configuración del cliente ha terminado, ahora en la pestaña

Clientes —> kubernetes —> Credenciales

podrá obtener Secret que utilizaremos más adelante.

Configuración de Kubernetes

La configuración de Kubernetes para la autorización OIDC es bastante trivial y no es nada muy complicado. Todo lo que necesita hacer es colocar el certificado CA de su servidor OIDC en /etc/kubernetes/pki/oidc-ca.pem y añadir las opciones necesarias para kube-apiserver.
Para esto, actualice /etc/kubernetes/manifests/kube-apiserver.yaml en todos sus maestros:

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

Y también actualice la configuración de kubeadm en el clúster para no perder estos ajustes al actualizar:

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

Con esto, la configuración de Kubernetes ha terminado. Puede repetir estas acciones en todos sus clústeres de Kubernetes.

Autorización inicial

Después de estas acciones, ya tendrá un clúster de Kubernetes con la autorización OIDC configurada. La única cuestión es que sus usuarios aún no tienen un cliente configurado ni su propio kubeconfig. Para resolver este problema, es necesario configurar la emisión automática de kubeconfig a los usuarios después de la autorización exitosa.

Para esto, se pueden utilizar aplicaciones web especiales que permiten autenticar al usuario y luego descargar el kubeconfig preparado. Una de las más convenientes es Kuberos, que permite describir todos los clústeres de Kubernetes en una sola configuración y cambiar fácilmente entre ellos.

Para configurar Kuberos, simplemente describa la plantilla para kubeconfig y ejecute con los siguientes parámetros:

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

Para más información detallada, consulte Uso en Github.

También es posible usar kubelogin si desea realizar la autenticación directamente en la computadora del usuario. En este caso, se abrirá un navegador con el formulario de autenticación en localhost.

El kubeconfig obtenido se puede verificar en el sitio jwt.io. Simplemente copie el valor users[].user.auth-provider.config.id-token de su kubeconfig en el formulario del sitio y obtendrá la interpretación de inmediato.

Configuración de RBAC

Al configurar RBAC, se puede hacer referencia tanto al nombre de usuario (campo name en el token jwt), como al grupo de usuarios (campo groups en el token jwt). Aquí hay un ejemplo de configuración de permisos para el grupo 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

Más ejemplos de RBAC se pueden encontrar en la documentación oficial de Kubernetes

Configuración del auth-proxy

Hay un proyecto excelente keycloak-gatekeeper, que permite proteger cualquier aplicación, brindando al usuario la posibilidad de autenticarse en el servidor OIDC. Mostraré cómo configurarlo usando el ejemplo de 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

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster