workspace.basaltic.sh. Conceder workspace:* acciones en las políticas de la organización. Las acciones de facturación, cuota y auditoría también se evalúan en el dominio de directiva de organización. Las políticas de IAM de cuenta nunca conceden estas acciones, incluso con un comodín de acción.
Los usuarios heredan las directivas de la organización directamente y a través de grupos de usuarios. Las funciones y las cuentas de servicio reciben solo las directivas de organización que se les han delegado explícitamente. Una sesión de rol utiliza las concesiones del rol, no las de su origen.
Nombres de recursos
/inline-policy/<name> al CRN principal. El límite de permisos de un usuario añade /permission-boundary/default. Establecer ese límite también requiere workspace:GetPolicy en la política elegida.
Las acciones
La tabla incluye las acciones principales. A continuación se describen comprobaciones adicionales de la cuenta de destino para la delegación de la organización y la asignación de roles.
Los miembros humanos pueden leer su propia organización a través de la membresía. Las identidades de máquina necesitan
workspace:GetOrganization. La lista de organizaciones devuelve las membresías de los humanos. El inicio de sesión personal, la aceptación de invitaciones y el cambio de la organización activa siguen siendo flujos de autenticación de IAM.
Adjuntar directivas de organización a personas
workspace:AttachPolicy y workspace:DetachPolicy requieren autorización tanto en la política de la organización como en el usuario o grupo de destino. Utilice los CRN concretos de ambos recursos; las directivas del sistema tienen su propio espacio de nombres CRN del sistema.
Delegación de directivas de organización
Una cuenta de rol o servicio puede tener permisos de organización para recopiladores de facturación, trabajos de incorporación u otra automatización. Su ficha de directiva de consola tiene tablas separadas de Account policies y Organization policies. Los extremos de los archivos adjuntos de la organización están en Workspace, no en IAM:
POST acepta
policy_id, el UUID de la política de la organización. DELETE añade ese UUID a la ruta. GET muestra los archivos adjuntos de la política de la organización. El UUID del destino se resuelve dentro de la organización actual y su cuenta propietaria; no mueve la identidad del llamador a esa cuenta.
La delegación está autorizada por las subvenciones de espacio de trabajo:
Utilice una subvención de espacio de trabajo que cubra tanto la política como su destinatario previsto. Un rol de Administrador de cuentas por sí solo no puede delegar autoridad de organización. La consola usa su sesión personal de Workspace para estas subvenciones de la organización.
Los cambios sensibles que transfieren la autoridad de una identidad ya delegada también requieren permiso de delegación de espacio de trabajo. La administración de directivas de cuentas por sí sola no puede obtener acceso de la organización al pasar un rol o emitir una nueva credencial.
Asignaciones de rol de cuenta
Las asignaciones de rol vinculan a un usuario o grupo de la organización a un rol en una cuenta. Suministran el permiso de origen para el intercambio AssumeRole de un humano. La confianza de destino sigue siendo necesaria y la creación de asignaciones nunca cambia la confianza. La creación de una asignación requiereworkspace:AssignAccountRole en la cuenta. El rol de destino debe pertenecer a esa cuenta y organización. La lista y la eliminación de asignaciones utilizan workspace:ListAccountRoleAssignments y workspace:RemoveAccountRoleAssignment.
El humano actual puede descubrir sus asignaciones efectivas a través de
GET /v1/account-rolesEsto es distinto de la lista de cuentas administrativas; un usuario no necesita recibir workspace:ListAccounts Simplemente escoja un rol asignado. Vea Acceso a cuenta.