Excelente tema estamos revisando, en el post anterior revisamos todo lo relacionado a la configuración de Keycloak para la administración de usuarios de forma centralizada a través de OpenID dejándolo preparado para la integración con Kasten K10 y Kasten K10 Multi-Cluster Manager. Por tanto en este post veremos paso a paso la configuración de los Clusterroles, Roles y grupos necesarios para gestión vía RBAC de Kasten K10.

Configuración Kasten Keycloak

*** 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 los permisos de usuario durante el tiempo, así toda la gestión de creación de usuario, grupos, asignación de grupos se realiza en Keycloak. ***

Debemos conectarnos al cluster primario de Kubernetes donde se encuentra instalado Kasten K10 y procederemos a la configuración de autenticación con Keycloak, pero antes, necesitamos extraer el “Secret” desde nuestro “Client” kasten en el menú “Credentials” reemplazando en la variable “auth.oidcAuth.clientSecret”, (reemplazar SuperDuperClientSecret) y por supuesto reemplazando los valores por tus datos de DNS o IP, ejecutando el siguiente comando (por seguridad elimine parte del secret):

helm upgrade k10 kasten/k10 --namespace=kasten-io --set auth.oidcAuth.enabled=true --set auth.oidcAuth.providerURL="https://auth.24xsiempre.com/auth/realms/kasten" --set auth.oidcAuth.redirectURL="https://kasten.24xsiempre.com/" --set auth.oidcAuth.scopes="groups profile email" --set auth.oidcAuth.groupClaim="groups" --set auth.oidcAuth.prompt="login" --set auth.oidcAuth.clientID="kasten" --set auth.oidcAuth.clientSecret="SuperDuperClientSecret" --set auth.oidcAuth.usernameClaim="email" --reuse-values --set externalGateway.create=true

Ahora veremos que significa cada uno de estas variables:

• –set auth.oidcAuth.enabled=true / Habilitamos autenticación OpenID
• –set auth.oidcAuth.providerURL=”https://auth.24xsiempre.com/auth/realms/kasten” / Url para Autenticarse
• –set auth.oidcAuth.redirectURL=”https://kasten.24xsiempre.com/” / Url de aplicacion K10
• –set auth.oidcAuth.scopes=”groups profile email” / Client Scopes para validar
• –set auth.oidcAuth.groupClaim=”groups” / Nombre del grupo de Client Scope
• –set auth.oidcAuth.prompt=”login” / Mensaje de Login
• –set auth.oidcAuth.clientID=”kasten” / Nombre del Cliente en el Realm creado.
• –set auth.oidcAuth.clientSecret=”SuperDuperClientSecret” / Secret del cliente
• –set auth.oidcAuth.usernameClaim=”email” / En caso de autenticacion de email
• –reuse-values / Reusa valores ya configurados
• –set externalGateway.create=true / Reconfigura servicio gateway en K10 para acceder remoto

Un dato importante si ya tienes configurado un método de autenticación para Kasten, es mejor desactivarlo y luego ejecutar el comando anterior en caso de error.

Acceso Usuarios

Como ya tenemos todo configurado, la creación del usuario que realizamos en el post anterior, solo nos queda ingresar a la interfaz web de Kasten, recordemos el detalle del usuario:

• Usuario: kastenadmin
• Password: SuperDuperPassword o la que se haya aplicado
• Grupo: k10:admins

Ahora solo ingresaremos a la Url de Kasten en mi caso https://kasten.24xsiempre.com/k10/#/ y nos redirigirá a el formulario de ingreso de Keycloak en el realm de Kasten, ingresamos las credenciales:

Y podremos observar que tenemos un ingreso exitoso y con todos los permisos ya que pertenecemos al grupo “k10:admins” y no tuvimos que editar ningún ClusterRole o Roles.

Para confirmar los permisos, es posible validarlos gráficamente ya sea viendo “permissions” “unrestricted” o entrando al cluster primario, luego “Cluster Settings” , después “Support” y por ultimo clic en “View Current User Details” y podrás visualizar todos los permisos de ese usuario y al grupo que pertenece:

Hasta aquí todo bien, pero que pasa si al usuario “kastenadmin” lo cambiamos de grupo? Entraremos nuevamente a Keycloak y cambiamos el grupo “k10:admins” por “k10:basic”

E ingresamos nuevamente a Kasten veremos lo siguiente:

El usuario “kastenadmin” ya no pertenece a “k10:admins” y ahora pertenece a “k10:basic” el cual no se encuentra configurado con su respectivo ClusterRoleBinding, RoleBinding asociado a algún ClusterRole o Role.

Creación de Roles de Acceso en Kasten K10

Como vimos anteriormente, tenemos configurado el cluster primario de Kasten K10 como también kasten Multi-Cluster Manager, comenzaremos revisando el acceso sólo al cluster primario sin la necesidad de acceder a los roles del Multi-Cluster.

Usuario Administrador

Asi en caso de no necesitar Multi-Cluster Manager es posible administrar los usuarios con Keycloak. Por tanto crearemos un grupo en Keycloak para acceder al cluster de nombre “k10:solo” y lo asociaremos al usuario “kastenadmin”

Y ahora vía SSH listaremos los ClusterRoles:

kubectl get clusterrole | grep k10

Generaremos un archivo yaml con el siguiente contenido:

nano k10solo.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-solo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:solo

Y luego lo aplicamos con el comando:

kubectl apply -f k10solo.yaml

Confirmaremos la creación del ClusterRoleBinding listando con el comando:

kubectl get clusterrolebindings | grep k10

Y si nuevamente ingresamos a Kasten K10 podremos validar que solo tenemos acceso al cluster de producción como administrador, ahora por que tengo acceso como administrador? en la linea 5 del archivo yaml que generamos se encuentra la referencia al ClusterRole “k10-admin” lo cual nos garantiza el rol. Al acceder veremos que tenemos acceso a todo, excepto por el siguiente error:

Lo que nos esta diciendo Kasten K10 es que no tiene permisos sobre el namespace “kasten-io” para consultar o listar los deployments y saber el estado de los servicios, para ellos debemos agregar el grupo “k10:solo” en el Role “k10-ns-admin” que se encuentra en dicho namespace. Para listar el rol:

kubectl get roles -n kasten-io

Siempre existen varias formas de editar estos roles, puedes editarlo directamente con el comando “kubectl edit roles k10-ns-admin -n kasten-io” o hacerlo con el siguiente yaml:

nano ns-admin-k10solo.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k10-k10-ns-solo
  namespace: kasten-io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:solo

kubectl apply -f ns-admin-k10solo.yaml

Confirmaremos la creación del RoleBinding listando con el comando

kubectl get rolebindings -n kasten-io

Y ahora validamos nuevamente los permisos y que no aparezca el error de los estados de servicios de Kasten K10:

Y ya tenemos todo de un excelente color :). Ahora que pasa si quiero un usuario que pueda ejecutar pero que no pueda modificar las configuraciones?

Usuario Operador

Como ya hemos visto anteriormente, vamos a crear un grupo en keycloak de nombre “k10:operador” y lo asignamos como un único grupo nuevamente al usuario “kastenadmin”.

Que es lo que necesita un operador, por ejemplo, que pueda ver todas las aplicaciones, pueda ver todos las políticas de respaldo como también los reportes generados automáticamente, a su vez, que tenga acceso para la creación, edición de política de respaldo pero que NO pueda eliminar algún recurso o editar alguna configuración.

Por tanto, vamos a crear un ClusterRole que nos permita tener los permisos necesarios para el rol de “Operador”, Crearemos el archivo con su respectivo contenido:

nano k10operadorclusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: k10-operador
rules:
- apiGroups:
  - actions.kio.kasten.io
  - apps.kio.kasten.io
  - config.kio.kasten.io
  - reporting.kio.kasten.io
  - vault.kio.kasten.io
  resources:
  - '*'
  verbs:
  - get
  - list
  - patch
  - update
  - watch
  - create
- apiGroups:
  - cr.kanister.io
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - create
  - get
  - list

Y aplicamos el archivo:

kubectl apply -f k10operadorclusterrole.yaml

Como podemos ver en el archivo, el usuario clusterrole de operador no tiene permisos de eliminación, validamos la creación del clusterrole:

kubectl get clusterrole | grep k10

Ahora generamos el clusterrolebinding para asociarlo con nuestro grupo de usuarios “k10:operador”

nano k10operadorbind.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: k10-k10-operador
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: k10-operador
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:operador

Y aplicamos el archivo:

kubectl apply -f k10operadorbind.yaml

Validamos:

kubectl get clusterrolebindings | grep k10

Y por último, como va a poder acceder pero no eliminar, también lo agregaremos al “ns-admin”:

nano k10operadornsadmin.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: k10-k10-ns-operador
  namespace: kasten-io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: k10-ns-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k10:operador

Validamos la creación:

kubectl get rolebinding -n kasten-io

Validamos acceso a Kasten K10:

Por ejemplo si el usuario desea eliminar una Política de Respaldo tendrá el siguiente mensaje:

Pero si desea crear una política de respaldo si podrá realizarlo:

O si quisiera borrar un “Location Profile” no podrá ya que no tiene el permiso para ello y el botón de eliminar se encuentra deshabilitado

Con esto queda demostrado que puedes generar los recursos de RBAC asociados a grupos administrando los usuarios directamente desde Keycloak, sin la necesidad de estar creando usuarios locales o editando los clusterroles / clusterrolebindings cada vez que un usuario necesite acceso a la plataforma de Kasten. Pero aun no hemos terminado, nos falta revisar el RBAC de Kasten Multi-Cluster Manager, que lo veremos en el siguiente post, Clic Aqui!