Kasten RBAC Multi-Tenant Multi-Cluster Keycloak – 1

En este post, veremos la configuración de Role Based Access Control (RBAC) en conjunto con Kasten K10 para el acceso a uno o múltiples clusters protegidos por Kasten, esta dirigido tanto a clientes que manejen 1 o más clusters de cualquier distribución de kubernetes soportado por K10, como también a proveedores de servicios (SP o MSP) que ofrezcan el respaldo de contenedores de kubernetes con Kasten K10, con el objetivo de brindar un acceso controlado a los usuarios / clientes de acuerdo a los roles granulares necesarios por cada cluster u operación. Ademas utilizaremos una solución de Single Sign-On (SSO) usando OpenID en este caso, Keycloak, para la gestión centralizada de las credenciales de acceso ya sea para usuarios o grupos.

Pasos Iniciales

La idea de esta serie es explicar como generar los grupos, roles, clusterroles y demás recursos asociados a RBAC, sin la necesidad de estar modificando directamente en el cluster de kubernetes durante el tiempo, así toda la gestión de creación de usuario, grupos, asignación de grupos se realiza en Keycloak.

Como es de costumbre en este blog, siempre debemos recurrir a la documentación oficial de lo que vamos a instalar / configurar o aplicar, ya que debemos mantenernos lo más cercano a las buenas practicas o directrices de los creadores de las soluciones que utilizaremos.

Keycloak https://www.keycloak.org/documentation

Kasten K10 https://docs.kasten.io/latest/

RBAC Kasten K10 https://docs.kasten.io/latest/access/rbac.html

RBAC Kasten K10 Multi-Cluster Manager https://docs.kasten.io/latest/multicluster/rbac.html

Instalación de K10 y Multi-Cluster

No entraremos en profundidad en la instalación de los productos en este post, ya que en los siguiente links tienes paso a paso la instalación de Kasten K10 y Kasten Multi-Cluster Manager:

Kasten K10 https://24xsiempre.com/veeam-kasten/

Kasten K10 Multi-Cluster Manager https://24xsiempre.com/instalar-kasten-multi-cluster-manager/

Y con respecto a la instalación de Keycloak, es muy sencillo desde helm o puedes usar una de las tantas guías en internet para instalarlo como contenedor o como una aplicativo en un servidor. (Deja un comentario si necesitas una guía paso a paso)

Ahora pasaremos a revisar un resumen de los roles y clusterroles existentes para la creacion de los permisos granulares.

Kasten K10 RBAC

Cuando revisamos la documentación, observamos que existe RBAC para la instalación individual de kasten k10, manteniendo los estándares de kubernetes así como también tenemos RBAC para instalaciones en múltiples cluster usando Multi-Cluster Manager.

En este caso revisaremos la aplicación de Roles, RoleBinding, ClusterRole, ClusterRoleBindings sobre kasten k10 para conseguir una acceso granular a nuestra implementación de k10 de acuerdo a la necesidad de la operación. Por tanto, al revisar la documentación nos encontraremos con los ClusterRoles por defecto que se crean al instalar K10, los cuales son 3:

  • k10-admin / Acceso total a la implementación de Kasten K10
  • k10-basic / Acceso operacional a usuarios en recursos específicos
  • k10-config-view / Acceso a la configuración sin permisos para crear o modificar

Los puedes listar con el siguiente comando:

kubectl get clusterrole | grep k10

De hecho si se revisa en detalle los permisos consultando cada clusterrole como por ejemplo:

kubectl describe clusterrole k10-admin

Se observan todos los permisos, recursos y verbs (lo que puede hacer) de cada uno de los clusterroles, los cuales son la base para la creación de permisos granulares de acceso a K10. Es posible utilizarlos como base para luego crear clusterrolebinding asociado a usuarios o grupos de usuarios que accederán vía OpenID.

Uno de los roles importantes que también existen dentro de la instalación de K10 es el rol k10-ns-admin el cual provee acceso a los secrets y también para ver el estado de los servicios directamente desde la consola de K10, para listar el rol, se debe incluir el namespace kasten-io

kubectl get roles -n kasten-io

K10 Multi-Cluster Manager RBAC

Al igual que lo anterior cuando se configura K10 Multi-Cluster Manager desde el cluster primario, se generan 2 clusterroles por defecto y ademas clusterroles específicos de k10:

  • k10-mc-admin / Permite acceso total a la administración de múltiples clusters y recursos
  • k10-mc-user / Permite acceso al cluster pero no a los recursos de administración
kubectl get clusterrole | grep k10-mc

Clusterroles específicos de K10 para la gestión de RBAC dentro de K10 Multi-Cluster

  • k10-multi-cluster-admin / Permite acceso total a la administración de múltiples clusters y recursos
  • k10-multi-cluster-basic / Permite acceso al cluster pero no a los recursos de administración
  • k10-multi-cluster-config-view / Permite acceso al cluster y a la visualización de configuración
kubectl get k10clusterrole -n kasten-io-mc

Por que tienen dos tipos de clusterroles? los primeros roles son asociados a los recursos y clusters de kubernetes y los k10clusterroles son asociado a la gestión interna del Multi-Cluster Manager con el objetivo de brindar acceso vía RBAC dentro de K10.

En esta guia configuraremos clusterroles y roles específicos de acuerdo a la necesidad de acceso y operación utilizando los recursos que nos provee Kasten K10, pero antes pasaremos a la configuracion de Keycloak

Configuración Keycloak

Después de la instalación de Keycloak, es posible acceder al dominio o realm “master” vía web con el usuario que hayan configurado, por ejemplo, en mi caso utilizo auth.24xsiempre.com e ingreso a la consola de administración:

Puedes mantener las configuraciones por defecto o habilitar al menos la detecion de fuerza bruta en el menú de “Security Defenses”.

Ahora, crearemos un nuevo Realm exclusivo para Kasten K10, por tanto seleccionaremos el en menu principal el realm “master” y haremos clic en “Add Realm”, luego ingresamos el nombre del nuevo realm y por ultimo clic en “create”:

Dentro de “Realm Settings” existen varias configuraciones como se observan en el menú de Keycloak, para este caso habilitaremos en “Security Defenses” la detección de fuerza bruta (opcional, pero recomendado) y lo mas importante en el menú “Login” las siguientes opciones:

De preferencia utilizar estas opciones, para el caso de “forgot password” y “Verify Email” es necesario tener configurado SMTP en Keycloak donde es muy fácil ingresar dirección, usuario y contraseña del servidor SMTP en el menú “Email” .

Configuración Cliente Keycloak

Ya tenemos lo básico de Keycloak, ahora entraremos de lleno a la configuración de un cliente en Keycloak para la utilización de OpenID en conjunto con K10. Clic en “Clients” y luego en “Create” para ingresar el nombre del “Client ID” (en este caso kasten) asegurándonos que el “Client Protocol” es “openid-connect”:

Para luego ingresar al nuevo cliente desde el menu “Clients”.

Ahora configuraremos en detalle el cliente para que utilice OpenID y permita acceder a los usuarios o grupos, por tanto las configuraciones que se deben aplicar son las siguientes:

A continuación explicaré cada uno de los campos configurados:

  • Enabled = Habilita el cliente de Keycloak
  • Always Display in Console = Para ver las sesiones en la consola de Keycloak
  • Login Theme = Tipo de interfaz gráfica
  • Client Protocol = Habilita el protocolo openid-connect que utilizaremos con K10
  • Access Type = Exige que se utilize una credencial para usar el cliente de Keycloak
  • Standard Flow Enabled = Habilita las re-direcciones de OpenID para autenticación y autorización.
  • Direct Access Grants Enabled = Acceso al usuario y contraseña e intercambio con Keycloak
  • Service Accounts Enabled = En caso de usar cuentas de servicio
  • OAuth 2.0 Device Authorization Grant Enabled = Soporte OAuth 2.0
  • Authorization Enabled = Autorizacion Granular habilitada
  • Valid Redirect URIs = Las URI validas que se utilizan para ingreso y salida de la aplicación
  • Web Origins = Configuracion de origenes CORS
  • Backchannel Logout URL = Url de logout del cliente
  • Backchannel Logout Session Required = Validar si el id de la sesion esta incluida en el logout
  • Backchannel Logout Revoke Offline Sessions = Revoca acceso offline
  • Browser Flow = Utilizará autenticacion con el browser
  • Direct Grant Flow = Entregará directamente la sesion

Ahora agregaremos un rol, para que este asociado a k10, ingresaremos en “Roles” dentro del mismo “Client” que ya configuramos y agregamos un nuevo rol de nombre “k10”:

Ahora ingresas en el rol recién creado luego en “Composite Roles” hacemos clic en “Client Roles” seleccionamos “kasten” y asignamos el nuevo rol “k10” en “Associated Roles”

Y por ultimo agregaremos por defecto el nuevo rol, clic en “Roles” y luego en el menú “Default Roles”, seleccionamos “kasten” en “Client Roles” y agregamos el nuevo rol “k10” a los roles por defecto:

Configuración Grupos Keycloak

Keycloak por defecto no tiene configurado los grupos en “Client Scopes”, es decir si configuramos la autenticación asociada a grupos, éste no funcionará, ya que kasten o la aplicación no podrá leer los grupos creados en Keycloak. Por tanto haremos clic en “Client Scopes” para luego hacer clic en “Create” e ingresamos el nombre “groups”, asegurándonos de usar el protocolo “openid-connect” y guardamos:

Ingresaremos en el reciente “Client Scope” creado “groups” y luego haremos clic en “Mappers” pare crear una nueva asociación clic en “Create”, ingresaremos el nombre “groups”, luego seleccionamos el “Mapper Type” que debe ser “Group Membership”, luego en “Token Claim Name” ingresamos “groups” y desactivamos “Full group path” para dejar las demás opciones activadas y guardamos:

Luego hacemos clic en “Scope”, seleccionamos el “Client Roles” que es “kasten” para agregar el rol asignado “k10”:

Y por ultimo necesitamos agregar el nuevo “Client Scope” por defecto para que pueda ser leído por Kasten. En “Clients Scopes” seleccionar el menú “Default Client Scopes” y movemos “groups” a los scopes asignados por defecto:

Creación de Grupos en Keycloak

Una excelente forma de administración de usuarios, es asociarlos a grupos que tengan ya los permisos o roles asociados para hacer mucho mas expedita la administración de éstos. Por tanto, una buena practica es utilizar la misma nomenclatura de Kasten para la creación de grupos. Haremos clic en “Groups” y luego en “New” para agregar el nombre del grupo, por ejemplo, “k10:admins” y guardamos.

Luego seleccionamos y editamos el grupo, para seleccionar el menú “Role Mappings” y en “Client Roles” seleccionaremos “kasten” para luego asignar el rol “k10” como podemos ver en la siguiente imagen:

Se pueden generar los grupos que sean necesarios y asignarle el rol anterior a cada uno de ellos como lo realizamos anteriormente.

Creación de Usuarios en Keycloak

Ahora crearemos un usuario de administración para la gestión de Kasten K10 ya sea un solo cluster o utilizando Multi-Cluster Manager, por tanto, entraremos al menú “Users” e ingresamos la información solicitada y el grupo asociado, en este caso “k10:admins”, recuerda que en el caso de verificación de email debes tener configurado el servidor SMTP. De lo contrario solo lo habilitas:

Algo importante, opcionalmente, puedes solicitar al cliente que configure MFA para una mejor seguridad, solo debes agregarlo en “Required User Action”. Ahora asignaremos una contraseña al usuario, clic en “Credentials”, ingresamos la “password” necesaria, desactivamos la opción “Temporary” y clic en “Set Password”:

Estamos en condiciones de comenzar a configurar la autenticación de Kasten K10 con Keycloak. En el siguiente post (Clic Aquí) revisaremos el paso a paso.