Skip to main content
IAM administra roles, cuentas de servicio, directivas de cuenta y sesiones temporales. Cada uno pertenece a una cuenta. La API es global en iam.basaltic.sh: la misma identidad de cuenta puede funcionar en diferentes regiones, dentro de sus permisos. Workspace administra organizaciones, personas, grupos y directivas de organización. Un extremo global no significa un recurso de toda la organización.

Roles y credenciales

Claves de acceso, directivas de confianza, roles asumidos e identidades de instancia.

Escribir políticas

El formato del documento, las condiciones y los ejemplos de trabajo.

Límites de permisos

Limitar los permisos de cuenta que puede recibir una cuenta de rol o de servicio.

Permisos

Acciones de IAM y los recursos que autorizan.

Acceso a cuentas para personas

Asignaciones de usuarios y grupos, seguidas de una asunción explícita de rol.

Solución de problemas de acceso

Compruebe el alcance de la cuenta, el alcance de la política, la confianza y los límites de sesión.

​
El modelo de identidad

Los grupos pertenecen a la organización y contienen solo usuarios. Las políticas de su organización se aplican a los miembros. Las asignaciones de roles de cuenta permiten a los miembros solicitar esos roles, sujetos a confianza. Las cuentas de servicio nunca se unen a grupos. Una sesión de rol utiliza los permisos del rol de destino. No combina los permisos del usuario de origen, la cuenta de servicio o el rol anterior con ellos.

​
Nombres de recursos

Las políticas identifican recursos con CRNs:
La región está vacía de servicios globales. Los CRN de IAM de cuenta contienen el identificador de cuenta. Los recursos de organización de espacio de trabajo dejan la ranura de cuenta vacía e incluyen el UUID de organización en la ruta de acceso al recurso. Las políticas de cuenta de sistema compartido usan crn:iam:::policy/<Name>. * es el único comodín. El diseño de dos puntos y barra se corresponde literalmente. Vea resource references para nombres, UUIDs y filtros de lista exactos.

​
Cómo se autoriza una solicitud

La credencial vincula primero al llamador a una organización y, para las credenciales de máquina y rol, a una cuenta. Un X-Account-Id diferente no puede mover una identidad a otra cuenta. Usa AssumeRole para una transición explícita de cuenta. La acción elige el dominio de la política:
  • workspace:*, billing:*, quota:* y audit:* usan políticas de organización.
  • Las acciones de servicio de cuenta usan las directivas de cuenta de la cuenta de rol o de servicio.
  • La asignación de un rol de cuenta humano permite el intercambio de AssumeRole; las operaciones ordinarias de cuenta requieren la sesión de rol resultante.
Dentro de ese dominio, una negación explícita gana. De lo contrario, se requiere un permiso. Una directiva de sesión opcional solo puede restringir el resultado. Los límites de permisos de cuenta limitan los permisos de la cuenta; el límite del espacio de trabajo de un usuario limita los permisos de su organización. Las directivas y los límites de cuenta no pueden conceder ni restringir una directiva de organización delegada por separado. Los propietarios de la organización usan concesiones explícitas de administrador de espacio de trabajo y roles de administrador de cuenta asignados. La propiedad nunca pasa por alto la evaluación de políticas. Los cambios de permisos deben preservar el acceso de administrador requerido del propietario; consulte access_account.
Una directiva de cuenta que permite * sigue siendo una directiva de cuenta. No puede conceder facturación, administración de la organización u otras acciones de la organización. Delegarlos por separado a través de Workspace.

​
Falling closed

Vale la pena conocer dos comportamientos porque son deliberados y no accidentales:
Si se establece un límite de permisos pero no se puede cargar el límite o su directiva, se deniega la solicitud. Un límite que existe pero no se puede leer podría estar limitando esta misma acción, por lo que la respuesta segura es no.
Un operador de condición no reconocido nunca coincide. En una sentencia allow que significa que la sentencia se salta. En una sentencia deny se trata como una denegación dura cuando la acción y el recurso coinciden — de lo contrario, un error tipográfico en una barandilla la deshabilitaría silenciosamente.

​
Siguiente

Escribir políticas

Declaraciones, acciones, recursos, condiciones y un conjunto de ejemplos para empezar.

Roles y credenciales

Cómo un programa obtiene credenciales en primer lugar.