Acceso a cuenta

Una cuenta es propietaria de los recursos y las identidades de IAM de la cuenta. Las funciones, las cuentas de servicio, las directivas de cuenta y las sesiones de STS pertenecen a una cuenta, aunque IAM tenga un extremo global. Al seleccionar otra región, la propiedad no cambia.

​

Crear una cuenta

Workspace crea cuentas en POST /v1/accounts. La respuesta incluye la nueva cuenta y su bootstrap_role_id y bootstrap_role_crn. Cada cuenta comienza con dos roles de sistema asignables: Estos roles no se pueden cambiar ni eliminar y no consumen la cuota de roles personalizados. Sus respuestas los identifican con builtin_kind: administrator o readonly. El propietario de la organización recibe una asignación de administrador. Un creador de cuenta humano también recibe esa asignación, y los campos de arranque identifican este rol. Ninguno de los roles otorga permisos de organización. Para un creador de máquina, la creación crea además un rol personalizado de AccountAdministrator confiado a la identidad inmutable del creador. La máquina todavía necesita permisos de fuente iam:AssumeRole. Este rol personalizado consume cuota y se puede cambiar o quitar normalmente.

​

Asignar personas a roles de cuenta

En la consola, abra Organization → Cuentas, seleccione la cuenta y, a continuación, abra Settings. La tarjeta Acceso a cuenta le permite Asignar rol a un usuario o grupo. Una asignación de grupo se aplica a sus miembros de usuario. Una asignación y la directiva de confianza del rol son requisitos independientes:

1. La asignación autoriza al humano a solicitar iam:AssumeRole para ese rol.
2. La directiva de confianza del rol debe aceptar el CRN principal de espacio de trabajo del usuario.
3. Después de la asunción, las solicitudes de cuenta usan los permisos del rol.

Los roles incorporados ya confían en los usuarios de la organización; las asignaciones controlan qué usuarios pueden asumirlos. La asignación de un rol personalizado nunca cambia silenciosamente su directiva de confianza. Abra el editor de Trust Policy del rol para permitir a los usuarios deseados. Un grupo no es un principal asume: use los CRN principales de los usuarios, o un patrón de usuario de ámbito de organización junto con asignaciones de roles controlados. La API de Workspace expone estas operaciones: Una asignación contiene principal_type (user o group), principal_id y role_id, todos resueltos dentro de la organización y la cuenta de destino. Las cuentas de servicio usan directivas de identidad y confianza, no asignaciones de roles humanos.

​

Uso de un rol de cuenta

Cada persona tiene un rol efectivo por cuenta. Las asignaciones directas y las pertenencias a grupos pueden otorgar el mismo rol a través de varias rutas. Un rol diferente se rechaza con 409 ACCOUNT_ROLE_CONFLICT, incluso cuando agregar a alguien a un grupo crearía ese conflicto. Combine los permisos requeridos en un rol o elimine las asignaciones en conflicto antes de asignar un reemplazo. La consola asume automáticamente su rol cuando se selecciona una cuenta. Todas las personas, incluidos los propietarios de la organización, usan un rol de cuenta asignado para los servicios de cuenta. No hay menú de selección de roles. La consola mantiene la sesión de organización personal separada de la sesión de rol de cuenta. Las páginas de organización usan tu sesión personal; las páginas de cuenta usan el rol asignado a la cuenta. Al cambiar de cuenta u organización se borra el contexto de rol anterior. Las sesiones de rol vencidas se renuevan desde su sesión personal, sujetas a las asignaciones y confianza actuales. Para las integraciones, use GET /v1/account-roles para descubrir las asignaciones de un humano, luego envíe el CRN de rol asignado de la cuenta de destino a POST /v1/assume-role de IAM. Verifique el account_id, account_handle y role_id devueltos antes de usar el token. Cambiar X-Account-Id no cambia la autoridad de cuenta de un token.

​

Eliminar acceso y eliminar cuentas

La eliminación de una asignación impide que se creen nuevas suposiciones a través de esa asignación. Revise y revoque las sesiones existentes al finalizar el acceso activo; no trate la eliminación de asignaciones como un sustituto de la revocación de sesiones. Una cuenta debe estar vacía antes de su eliminación. Los roles personalizados, las directivas, las cuentas de servicio y las sesiones de cuenta de servicio o de rol personalizado activas cuentan como recursos, junto con la infraestructura. Los dos roles integrados y sus sesiones no bloquean la eliminación; la eliminación de la cuenta hace que esas sesiones sean inutilizables. Para la limpieza automática de cuentas, conserva las credenciales originales de la organización. Quite los recursos mediante el rol de administrador de cuenta. Si se trata de un rol de arranque personalizado, elimínelo por último y luego elimine la cuenta con las credenciales de la organización. Al eliminar un rol personalizado también se eliminan sus sesiones.

​

Mantener el acceso del propietario

La propiedad en sí no otorga permisos. El propietario tiene una directiva de Administrador de organización explícita y una asignación de Administrador en cada cuenta activa. Los cambios de permiso que eliminarían este acceso fallan con 409 OWNER_ACCESS_REQUIRED, incluidas las restricciones indirectas a través de grupos o límites. Una sesión temporal restrictiva todavía limita las solicitudes del propietario. La transferencia de propiedad establece las concesiones requeridas del receptor atómicamente. Un destinatario con negaciones en conflicto o un límite restrictivo no puede convertirse en el propietario hasta que se resuelvan esas restricciones. Las concesiones explícitas del propietario anterior permanecen hasta que las revoque por separado. Transfiere la propiedad antes de quitar el acceso de administrador requerido del propietario actual.