Usuarios, equipos y RBAC
Usuarios, equipos y RBAC
Apenas más de una persona usa Portainer, el control de acceso importa: querés que cada quien vea y toque solo lo suyo, sin dar admin a todos. Acá es donde más se separan CE y BE.
Usuarios
Users en el menú de administración lista las cuentas. Cada usuario tiene un nivel base:
- Administrator: control total de la instancia (entornos, settings, usuarios). Equivale a root sobre todo lo que Portainer gestiona.
- Standard user: solo accede a lo que se le otorgue explícitamente vía control de acceso.
Creás usuarios locales con contraseña, o los provisionás desde un proveedor externo (ver más abajo).
Equipos (teams)
Un team agrupa usuarios. En vez de dar permisos persona por persona, se los das al equipo y agregás/quitás miembros. Ejemplo: el equipo backend tiene acceso a los stacks y entornos de backend; al entrar alguien nuevo, lo sumás al equipo y hereda todo.
Los equipos pueden tener team leaders, que gestionan a sus miembros sin ser admins globales.
Control de acceso por recurso
Muchos recursos (stacks, contenedores, volúmenes, entornos) tienen una pestaña de access control donde definís su propietario y quién más puede usarlo:
- Administrators: solo admins.
- Restricted: los usuarios/equipos que elijas.
- Public: cualquier usuario del entorno.
Así, un stack creado por el equipo frontend queda restringido a ese equipo y es invisible para los demás standard users.
CE vs BE: el límite del RBAC
Acá está la diferencia más importante entre ediciones:
| CE | BE | |
|---|---|---|
| Roles | Admin / Standard user | Roles granulares (Operator, Helpdesk, Read-only, etc.) |
| Acceso por entorno | Sí (otorgar/denegar) | Sí, más fino |
| Roles por namespace K8s | Limitado | ✅ por namespace |
| Permisos a nivel de acción | No | ✅ (qué puede hacer cada rol) |
| Activity logs / auditoría | ❌ | ✅ |
En CE el modelo es esencialmente binario (admin o usuario con accesos otorgados). En BE definís roles que precisan qué operaciones puede hacer cada quien sobre cada entorno o namespace (ej. un rol “Helpdesk” que ve logs pero no borra nada). Si tu organización necesita separación de funciones real, ese es el principal motivo para BE.
Autenticación externa (BE)
Por defecto Portainer usa autenticación interna (usuarios locales). La Business Edition agrega integración con proveedores de identidad:
- OAuth / OIDC: Google, Microsoft Entra ID, Keycloak, etc.
- LDAP / Active Directory: usuarios y grupos del directorio corporativo, con mapeo de grupos LDAP a equipos de Portainer.
- SAML.
Con esto, el alta/baja de usuarios la gobierna tu IdP corporativo y Portainer respeta esas identidades y grupos. En CE la autenticación es interna únicamente.
flowchart TD
IdP["IdP corporativo<br/>(OAuth / LDAP / SAML)"] -->|"BE"| P["Portainer"]
P --> T["Teams ⇄ grupos del IdP"]
T --> AC["Access control por recurso"]Buenas prácticas
- Reservá la cuenta admin para administración real; trabajá día a día como usuario con permisos acotados.
- Modelá accesos por equipo, no por persona: escala mejor y reduce errores.
- En BE, mapeá grupos del directorio a equipos para que altas/bajas se reflejen solas.
- Revisá periódicamente quién tiene acceso a qué (en BE, con los activity logs).
Anterior → Capítulo 11: Edge · Siguiente → Capítulo 13: GitOps y webhooks