12 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Distinguir los tres tipos de cuenta y separar los derechos de capacidad (lo que un grupo puede hacer) de las concesiones de recursos (qué recursos puede modificar).
  • Aplicar el principio de privilegio mínimo en una plataforma cuyo modelo de acceso es de lectura implícita y no tiene regla de denegación, donde el privilegio mínimo significa simplemente no conceder permisos.
  • Explicar por qué la federación es solo autenticación, sin aprovisionamiento en el momento justo ni mapeo de proveedor de identidad a grupo, y diseñar el manual de procedimientos manual de incorporación, cambio y baja que esto implica.
  • Crear un grupo, delimitar una concesión de recursos y añadir un miembro en Data Center Designer, y emitir y delimitar un token de API que mantenga las credenciales personales fuera de la automatización.

Unidad 2.2: Identidad, RBAC y federación

Introducción

El control de acceso en IONOS CLOUD no se parece al IAM de lenguaje de políticas de los hiperscalers de Estados Unidos. No existe un documento de política JSON, ni un deniego explícito, ni condiciones finas por acción. El acceso es basado en grupos, con derechos de capacidad asignados a un grupo y recursos concedidos a ese mismo grupo, y el acceso de lectura es implícito en el momento en que se concede un recurso. Ese modelo es más simple, pero exige una disciplina particular: el privilegio mínimo se logra no concediendo, no escribiendo una regla restrictiva. Esta unidad establece esa disciplina, define dónde termina genuinamente la federación, y termina construyendo un grupo con alcance definido y un token de API con alcance definido en el Data Center Designer para FinCorp.

1. Tipos de cuenta, derechos de capacidad y concesiones de recursos

Existen tres tipos de cuenta dentro de un contrato. El propietario del contrato se crea automáticamente para la persona que se registró primero, tiene acceso completo a todos los recursos, puede crear y eliminar usuarios y asignar el rol de Administrador, y es la única cuenta que puede cambiar el método de pago del contrato; existe exactamente uno y no puede ser revocado. Un Administrador (ilimitado por contrato) tiene el mismo alcance que el propietario, excepto para el método de pago, puede asignar el rol de Administrador a otros y accede a todos los recursos contratados sin pertenecer a ningún grupo. Un Usuario es el tipo de cuenta básico: no tiene ningún acceso, excepto a través de la membresía de grupo y los privilegios asignados a esos grupos, y puede ser ascendido a Administrador.

Para los Usuarios, el acceso se construye a partir de dos capas independientes, y mantenerlas diferenciadas es el núcleo del modelo:

  • Los derechos de capacidad son capacidades a nivel de contrato asignadas a un grupo, que regulan qué tipo de acción pueden realizar sus miembros. Los derechos de grupo asignables incluyen: Create Data Center, Create Snapshots, Reserve IP Blocks, Create Internet Access, Use Object Storage, Create Backup Units, Create Kubernetes Clusters y Access Activity Log.
  • Las concesiones de recursos delimitan qué recursos específicos puede manipular un grupo, seleccionados de los tipos de recursos controlables: centros de datos virtuales, Snapshots, imágenes, bloques de IP, unidades de copia de seguridad y Kubernetes Clusters. Cada concesión lleva un nivel de autorización: Read (implícito en el momento en que se asigna un recurso a un grupo), Edit y Sharing.

Un grupo con el derecho Create Data Center pero sin ningún VDC concedido puede crear nuevos centros de datos, pero no puede ver ni tocar los existentes; un grupo al que se le concede un VDC específico a nivel Edit pero que carece del derecho Create Data Center puede modificar ese VDC, pero no puede crear nuevos. La capacidad y la concesión son ortogonales, y un usuario obtiene la intersección de ambas a través de todos los grupos a los que pertenece. Los Administradores están fuera de esto por completo: como acceden directamente a todos los recursos, no necesitan membresía de grupo, lo que hace que el rol de Administrador sea una asignación deliberadamente escasa en lugar de una comodidad.

2. Lectura implícita, ausencia de denegación y privilegio mínimo mediante la no concesión

La plataforma no cuenta con reglas de denegación. No es posible escribir una política que reste acceso; solo se pueden añadir derechos de capacidad y concesiones de recursos. Combinado con la lectura implícita (asignar un recurso a un grupo otorga automáticamente el permiso de lectura sobre dicho recurso), esto significa que el privilegio mínimo es una función de la contención en el momento de la concesión, no de una regla correctiva posterior. Por lo tanto, la postura de privilegio mínimo consiste en: crear grupos con un alcance estrecho, conceder a cada uno solo los recursos que realmente necesita en el nivel más bajo que funcione (preferir Read sobre Edit, y reservar Sharing de manera deliberada), y no recurrir nunca al rol Administrator como atajo.

Dado que no existe denegación, una concesión demasiado amplia no puede corregirse mediante una excepción; debe eliminarse y redefinirse su alcance. La disciplina operativa que se deriva de esto es modelar los grupos en torno a roles (un grupo de operaciones de base de datos, un grupo de red, un grupo de auditor con solo lectura) y mantener el conjunto de recursos concedidos a cada grupo tan restrictivo como el rol permita. Para FinCorp bajo la supervisión de BSI, a un grupo de auditor se le concede el derecho Access Activity Log y concesiones a nivel de lectura sobre los VDCs relevantes, y nada más, de modo que el auditor pueda revisar sin ninguna capacidad de modificar la infraestructura.

3. La federación es solo autenticación

FinCorp ya opera un proveedor de identidades corporativo, por lo que el instinto es federar y permitir que el IdP controle todo. La plataforma admite la federación con proveedores de identidad SAML 2.0 y OpenID Connect (OIDC), pero su alcance actual es solo de autenticación. Esa frase conlleva tres consecuencias estrictas que deben tenerse en cuenta en el diseño:

  • No hay aprovisionamiento just-in-time. Un inicio de sesión federado no crea una cuenta de IONOS CLOUD al vuelo. El usuario debe existir previamente como usuario de IONOS CLOUD antes de poder autenticarse a través del IdP; el vinculado de cuentas requiere un usuario existente.
  • No hay mapeo de proveedor de identidades a grupos. El IdP no controla la membresía de grupos en IONOS CLOUD. La federación autentica a la persona; no asigna sus derechos de capacidad ni sus concesiones de recursos. El mapeo de accesos desde los atributos del IdP a los grupos de IONOS CLOUD está en la hoja de ruta, pero no está disponible hoy.
  • Autenticación, no autorización. La federación responde a la pregunta "¿es esta la persona correcta?"; el modelo de grupos y concesiones sigue respondiendo a la pregunta "¿qué puede hacer?", y ese modelo se administra dentro de IONOS CLOUD, independientemente del IdP.

El patrón que esto impone es un manual de procedimientos (runbook) explícito y manual para los procesos de alta, cambio y baja de usuarios. Cuando alguien se incorpora, un administrador crea el usuario de IONOS CLOUD y asigna los grupos correctos antes de que el inicio de sesión federado sea útil. Cuando alguien cambia de rol (cambio), un administrador ajusta su membresía de grupo manualmente. Cuando alguien se retira (baja), deshabilitarlo en el IdP detiene los nuevos inicios de sesión, pero el usuario de IONOS CLOUD y sus concesiones deben eliminarse por separado, porque el IdP nunca poseyó el acceso del lado de IONOS CLOUD. Tratar la federación como si aprovisionara y desaprovisionara cuentas es una interpretación peligrosa; no hace ninguna de las dos cosas. El patrón nativo es mantener un manual de procedimientos documentado y auditar la lista de usuarios de IONOS CLOUD contra el sistema de RR. HH. de forma programada, ya que nada los concilia automáticamente.

Guía de implementación de DCD

Creará un grupo FinCorp con ámbito definido, le otorgará un único recurso, agregará un miembro y, a continuación, emitirá un token de API con un ámbito estrecho. Solo los propietarios de contratos y los administradores pueden gestionar usuarios. El objetivo de la arquitectura es un grupo con privilegios mínimos cuyo acceso se limite exactamente a los recursos que se le han otorgado, más una credencial de automatización que no sea la iniciación de sesión personal de ninguna persona.

Objetivo de la construcción: Crear un grupo, definir el ámbito de la concesión de un recurso, agregar un miembro; emitir un token de API y definir su ámbito.

Pasos (en Data Center Designer):

  1. Abra el User Manager (Usuarios y grupos). En la pestaña Groups, seleccione Create, introduzca un nombre de grupo (por ejemplo, fincorp-db-ops) y seleccione Create para confirmar. El grupo ahora aparece en la lista de grupos sin derechos ni recursos.
  2. Con el grupo seleccionado, asigne sus derechos de capacidad activando solo los privilegios que el rol necesita (por ejemplo, Create Kubernetes Clusters, o Access Activity Log para un grupo de auditores). Desactive todos los demás derechos; lo que no esté marcado equivale a denegación.
  3. Abra la pestaña Resources of Group, haga clic en Grant Access y seleccione el recurso específico (por ejemplo, el VDC fincorp-prod-de) desde el menú desplegable. Otorgar un recurso habilita implícitamente el permiso de lectura sobre él; eleve el permiso a edición solo si el rol requiere realizar cambios.
  4. Abra la pestaña Members y agregue el usuario desde el menú desplegable Add User. El usuario ahora hereda exactamente los derechos y concesiones de este grupo, y nada más. (No agregue administradores a grupos; ya tienen acceso a todo.)
  5. Para la automatización, vaya a Menu > Management > Token Manager y genere un token de autenticación. Seleccione un TTL entre los valores permitidos (1 hora, 4 horas, 1 día, 7 días, 30 días, 60 días, 90 días, 180 días, 365 días), eligiendo el más corto que se ajuste a la tarea. Los permisos del token son los permisos del usuario bajo el cual se genera, por lo que debe generarse bajo un usuario de servicio creado para ese fin que pertenezca únicamente al grupo de ámbito estrecho, nunca bajo una cuenta de administrador personal.
  6. Copie el valor del token de inmediato. Se muestra exactamente una vez al generarse y no es recuperable después; guárdelo en su gestor de secretos antes de salir de la pantalla.

Errores comunes:

  • Otorgar un recurso con permiso de edición cuando la lectura es suficiente. No existe una regla de denegación para revertirlo; una concesión demasiado amplia debe eliminarse y volver a definirse en su ámbito.
  • Emitir tokens de API bajo una cuenta personal o de administrador. El token hereda todo el alcance de esa cuenta; emítalo en su lugar bajo un usuario de servicio dedicado y de ámbito estrecho.
  • Suponer que un token puede pausarse. Desactivar un token equivale a eliminarlo; la eliminación es inmediata y permanente, y el valor no puede recuperarse, por lo que planifique la rotación como eliminación y reemisión.
  • Esperar que la federación cree o elimine cuentas. Solo autentica; el ciclo de vida de incorporación, traslado y salida es un procedimiento manual en el lado de IONOS CLOUD.
  • Tratar la visualización única del token como recuperable. Captúrela al generarse; no hay una segunda oportunidad para leerla.

Una breve ilustración del límite de la credencial: la programación contra la API utiliza el token como credencial de portador, nunca un nombre de usuario y una contraseña, que es exactamente la razón por la cual el token debe portar únicamente el ámbito mínimo del usuario de servicio.

curl --location \
  --request GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  --header 'Authorization: Bearer <SERVICE_USER_TOKEN>'

El punto arquitectónico está en la cabecera: el token es la identidad. Lo que el usuario del servicio puede hacer, el script también puede hacerlo, por lo que el control reside en delimitar el alcance del usuario, no del script.

Resumen

El control de acceso de IONOS CLOUD se basa en grupos, con los derechos de capacidad y las concesiones de recursos mantenidos por separado, lectura implícita y sin regla de denegación, por lo que el principio de privilegio mínimo se logra otorgando permisos de forma restringida en lugar de escribir políticas restrictivas. La federación con SAML u OIDC es solo autenticación, sin aprovisionamiento en el momento justo y sin mapeo de IdP a grupos, lo que obliga a un procedimiento manual de alta, cambio y baja. Los tokens de API heredan los permisos del usuario emisor y se muestran una sola vez, por lo que deben pertenecer a usuarios de servicio con alcance limitado y se rotan mediante eliminación y reemisión.

Puntos clave:

  • Tres tipos de cuenta: un propietario de contrato no revocable, un número ilimitado de Administrators (alcance completo menos método de pago, sin necesidad de grupo) y Users que obtienen acceso solo a través de grupos.
  • Los derechos de capacidad (lo que un grupo puede hacer) y las concesiones de recursos (qué recursos, en nivel Read/Edit/Sharing) son ortogonales; un usuario obtiene la intersección a través de sus grupos.
  • No hay regla de denegación y la lectura es implícita, por lo que el privilegio mínimo significa no otorgar; una concesión demasiado amplia se elimina y se reasigna, no se corrige.
  • La federación es solo autenticación: el usuario debe existir previamente (sin JIT), el IdP no se mapea a grupos y el procedimiento de alta, cambio y baja es manual.
  • Los tokens de API heredan los permisos del usuario emisor, permiten hasta 100 por usuario, se muestran una sola vez y no son recuperables, y se eliminan (no se desactivan) para revocarlos; emítalos bajo usuarios de servicio con alcance limitado.

Terminología importante:

  • Derecho de capacidad: Un privilegio de grupo a nivel de contrato que gobierna qué tipo de acción pueden realizar los miembros (por ejemplo, Create Kubernetes Clusters).
  • Concesión de recurso: Una asignación de un recurso específico a un grupo en nivel Read, Edit o Sharing; otorgar habilita implícitamente Read.
  • Federación: Confianza de autenticación SAML 2.0 / OIDC; solo verifica la identidad y no aprovisiona cuentas ni asigna grupos.
  • Token de API: Una credencial de portador que hereda los permisos del usuario emisor, se muestra una sola vez al generarse y se revoca mediante eliminación.