Acceso y permisos

Coexisten dos conceptos distintos:

• Acceso a apps — quién puede usar una aplicación desplegada (conectarse a Digdash BI, a Hop…);
• Permisos internos — quién puede administrar qué en el propio Control Panel.

Acceso a apps

La página Acceso a apps (o el botón Gestionar acceso de una tarjeta, no disponible para PostgreSQL) muestra, para cada aplicación con autenticación OIDC, todos los usuarios de la plataforma repartidos en dos secciones, Con acceso / Sin acceso, con búsqueda y selección múltiple para actuar sobre varios usuarios a la vez.

Dos mecanismos según la plantilla, mostrados automáticamente por la página:

• Perfiles (la mayoría de las plantillas, p. ej. Digdash BI): conceder el acceso consiste en asignar uno o varios perfiles (roles de la aplicación) al usuario — un usuario sin perfil no tiene acceso. El botón Añadir perfiles abre la selección, individualmente o en bloque sobre la selección actual.
• Conceder / revocar directo (solo Apache Hop GUI): una simple concesión binaria, sin noción de perfil — botones Conceder / Revocar, también disponibles en bloque.

Permisos internos

Los roles del Control Panel se otorgan por namespace (el usuario actúa sobre todo el namespace, desde la pestaña Namespaces) o por aplicación (alcance limitado a una sola aplicación, desde esta página). La página Permisos internos reutiliza la misma interfaz que Acceso a apps (búsqueda, secciones Con/Sin permiso, selección múltiple para las acciones en bloque), pero solo muestra y modifica los permisos definidos directamente en la aplicación: los roles heredados del namespace no aparecen aquí — un recordatorio que la propia pantalla muestra, junto con la tabla de derechos siguiente. Aparecen todas las aplicaciones del namespace, incluidas las que no tienen conexión Keycloak (PostgreSQL, Apache Iceberg, Nginx, Spark Connect…), ausentes de la página Acceso a apps por no haber ningún acceso que otorgar.

Rol	Lo que permite
viewer	Ver las aplicaciones, volúmenes y buckets del ámbito
operator	+ iniciar/detener/reiniciar, actualizar una aplicación, configurar, resincronizar
admin	+ desplegar y eliminar, gestionar el acceso y los permisos del ámbito

A esto se suma el estado de administrador de plataforma, transversal: gestión de usuarios, grupos, namespaces y cuotas, de los ajustes del clúster, de la instancia Git y de la autenticación por relé.

Derecho de creación de namespaces

Crear un namespace ya no requiere ser administrador de plataforma. El derecho Creación de namespaces puede concederse:

• a un usuario, en su ficha (Usuarios → Modificar el usuario), al crearlo, o mediante la columna creation_namespaces de la importación masiva;
• a un grupo: todos sus miembros lo reciben mientras formen parte de él.

Quien crea un namespace pasa a ser su administrador (admin), solo de ese. El derecho no da nada más: ni eliminar un namespace, que sigue reservado al administrador de plataforma, ni gestionar grupos o ajustes del clúster. Como cualquier administrador de namespace, puede crear cuentas de usuario, pero no modificarlas ni eliminarlas. Solo un administrador de plataforma puede concederlo.

En la lista de Usuarios, una etiqueta señala a quienes tienen el derecho; al pasar el ratón, indica si proviene de un grupo. Un administrador de plataforma lo tiene de oficio.

Grupos

Reservado a los administradores de plataforma.

Un grupo es un conjunto de usuarios. Todo lo que se concede al grupo se aplica a cada uno de sus miembros mientras sean miembros: salir del grupo retira lo que el grupo aportaba, y solo eso.

Lo que puede llevar un grupo

Elemento	Lo que reciben los miembros	Aplicación
Acceso a una aplicación (y sus perfiles, para Digdash BI y NiFi)	El derecho a iniciar sesión en la aplicación, con esos perfiles	Enviado a Keycloak
Rol en un namespace	viewer, operator o admin en todo el namespace	Inmediata
Rol en una aplicación	Un rol limitado a esa aplicación	Inmediata
Creación de namespaces	El derecho a crear namespaces	Inmediata

Los roles y el derecho de creación se calculan en cada acción: un cambio es efectivo al instante. El acceso a las aplicaciones, en cambio, debe inscribirse en Keycloak (véase Cuándo se aplican los cambios).

Cómo se combinan los derechos

Un usuario puede recibir derechos de varias fuentes: directamente y mediante uno o varios grupos. Nada se sobrescribe:

• Roles: prevalece el más alto. Un rol asignado a una aplicación prevalece sobre el rol del namespace que la contiene.
• Accesos y perfiles: se suman. Un miembro de dos grupos recibe la unión de sus perfiles, más los que tiene asignados directamente. Un acceso se mantiene mientras al menos una fuente lo justifique: retirar a alguien de un grupo no le quita un acceso que también tiene directamente o por otro grupo.

Cuándo se aplican los cambios

• Añadir o retirar un miembro: sus accesos se actualizan de inmediato.
• Asociar o disociar una aplicación, cambiar sus perfiles, eliminar el grupo: el cambio se registra al instante y después se aplica a todos los miembros mediante una tarea en segundo plano, cuyo progreso se muestra en la página. En un grupo de varios miles de miembros tarda unos minutos. Tras un fallo parcial, el botón Resincronizar vuelve a enviar el acceso y los perfiles a todos los miembros.
• Reconciliación periódica: la tarea de sistema de reconciliación restablece en Keycloak los accesos que los grupos justifican pero que faltarían. Nunca retira nada: varios Control Panel pueden compartir el mismo Keycloak, y un acceso sin justificación aquí puede tenerla en otro lugar.

Accesos a aplicaciones y perfiles

Solo se proponen las aplicaciones iniciadas: no se podría aplicar nada a una aplicación detenida. Para Digdash BI y Apache NiFi, el botón Perfiles de una aplicación asociada permite elegir los perfiles que el grupo confiere; las demás aplicaciones conservan un acceso simple.

Lo que viene de un grupo aparece en gris

En la página Acceso a apps, los perfiles heredados de un grupo se muestran en gris, con el nombre del grupo al pasar el ratón, y una etiqueta «vía grupo» señala a los usuarios afectados. En Modificar los perfiles, aparecen marcados pero no se pueden desmarcar: quitarlos ahí no tendría efecto, el grupo los volvería a otorgar. Del mismo modo, Revocar está desactivado para un usuario cuyo acceso solo proviene de un grupo. Estos accesos se retiran desde la página Grupos.

Nombres de grupo

Un nombre de grupo es único sin distinguir mayúsculas: «Negocio» y «negocio» son el mismo grupo. La importación masiva vincula por tanto a un usuario con el grupo existente sea cual sea la capitalización, y solo crea un grupo si realmente no existe.

Note

Los permisos del Control Panel son independientes de los roles internos de cada aplicación: otorgar operator en un namespace no concede, por ejemplo, derechos de administración dentro de la propia Digdash BI.