Roles y credenciales

Las funciones y las cuentas de servicio pertenecen a una cuenta. Una cuenta de servicio intercambia su clave de acceso por un token al portador. Un usuario, una cuenta de servicio, una carga de trabajo o una sesión de rol de confianza puede asumir un rol para recibir credenciales temporales para su cuenta.

Cuentas de servicio

Teclas de acceso de larga duración para scripts e IC.

Roles

Permisos que otra cosa toma prestados, controlados por una política de confianza.

Credenciales temporales

Asumir un rol, opcionalmente con un alcance más reducido.

Identidad de instancia

Una máquina virtual que obtiene credenciales sin secreto para implementar.

Cuentas de servicio

Una cuenta de servicio es una identidad no humana que contiene claves de acceso. Cree uno, déle permisos y luego cree una credencial en él:

Console
API
CLI
Go

Vaya a Identity & access → Service accounts y elija Create Service Account. En Service Account Details, dale un Name (letras minúsculas, números y guiones, comenzando con una letra) y opcionalmente una Description.En la propia cuenta de servicio, la tarjeta Credentials tiene Create Credential: un Name y un Expires At que puede dejar en blanco para una credencial que no caduca.El secreto aparece en un cuadro de diálogo Credential Created, con Copy access key ID y Copy secret access key. Ese diálogo es el único lugar donde se muestra.

POST /v1/service-accounts
{ "name": "deploy-bot" }

POST /v1/service-accounts/{service_account_id}/credentials
{ "name": "ci-key" }

basaltic iam service-account create --name deploy-bot
basaltic iam service-account create-credential <service-account-id> \
  --name ci-key

--expires-at en la credencial toma una marca de tiempo RFC 3339.

c := iam.New(cfg)
sa, err := c.CreateServiceAccount(ctx, &iam.ServiceAccountCreateRequest{
    Name: "deploy-bot",
})
cred, err := c.CreateServiceAccountCredential(ctx, sa.ID,
    &iam.CredentialCreateRequest{Name: "ci-key"})

El secreto está en esta respuesta y en ningún otro lugar.

La respuesta lleva access_key_id y secret_access_key.

El secreto se devuelve una vez, en la creación, y no se almacena en un formulario que la API pueda mostrar de nuevo. Si la pierde, elimine la credencial y cree otra.

Una cuenta de servicio comienza sin permisos. Adjunte las directivas de cuenta directamente; las cuentas de servicio no se unen a grupos. Use la tabla de directivas de organización independiente solo cuando necesite acceso de la organización, como leer el uso de facturación.

Console
API
CLI
Go

En la pestaña Policies de la cuenta de servicio, elija Attach account policy en Account policies. Las concesiones de organización usan Attach organization policy en la tabla separada Organization policies.

POST https://iam.basaltic.sh/v1/service-accounts/{service_account_id}/policies
{ "policy": "<account-policy>" }

Las concesiones de organización usan la misma ruta en workspace.basaltic.sh, con { "policy_id": "<organization-policy-uuid>" }.

basaltic iam service-account attach-policy <service-account-id> \
  --policy <policy-id>

err := iam.New(cfg).AttachServiceAccountPolicy(ctx, serviceAccountID,
    &iam.PolicyAttachRequest{Policy: policyID})

La delegación de la organización requiere autoridad en ambos ámbitos. Consulte Permisos de espacio de trabajo.

Roles

Un rol es un conjunto de permisos con sin credenciales propias. Algo más lo asume y obtiene credenciales temporales que autorizan como el rol. Un rol tiene dos mitades:

Políticas de permisos

Lo que el rol puede hacer en su cuenta, además de cualquier directiva de organización delegada por separado.

Política de confianza

Quién está autorizado a asumirlo. Sin esto, nadie puede.

En la consola, abra Identity & access → Roles → Crear rol. El editor Trust Policy admite la edición visual y JSON. Un rol guardado tiene tablas separadas de Account policies y Organization policies.

Políticas de confianza

La directiva de confianza enumera los patrones de CRN que coinciden con el CRN del propio llamador:

{
  "principals": [
    "crn:iam::automation:service-account/deploy-bot",
    "crn:compute:*:my-account:instance/*"
  ],
  "conditions": [
    { "operator": "ip_address", "key": "basalt:SourceIp", "values": ["10.0.0.0/8"] }
  ]
}

principals puertas quién; conditions puertas bajo qué circunstancias. Ambos deben sostenerse. Los titulares de cuentas de rol y de servicio incluyen su identificador de cuenta propietaria. Cuando guardas un principal de IAM con nombre concreto, se vincula al UUID inmutable de esa identidad. Eliminar una identidad y volver a crear su nombre no hereda su confianza. La confianza humana acepta un nombre de usuario específico o crn:workspace:::user/* para todos los usuarios de la organización seleccionada. Los ID de usuario numéricos siguen siendo válidos durante la selección inicial del nombre de usuario.

Llamada	Principal CRN
Cuenta de servicio	`crn:iam::<account-handle>:service-account/<service-account-uuid>`
Papel asumido	`crn:iam::<account-handle>:role/<role-uuid>`
Usuario registrado	`crn:workspace:::user/<username>`
Instancia de cálculo	`crn:compute:<region>:<account-handle>:instance/<instance-id>`

Los grupos no son los principales que pueden asumir un papel. Utilice la confianza del usuario junto con una asignación de rol de grupo. La confianza solo se aplica dentro de la organización del rol; no se admite la asunción de rol entre organizaciones.

* es el único comodín y el diseño de dos puntos/barra diagonal se compara literalmente. Un patrón escrito en cualquier otra forma no coincide con nada — no falla en voz alta, simplemente nunca coincide, así que compruebe la forma cuando una política de confianza parece ser ignorada.

Asumir un rol

AssumeRole tiene dos puertas independientes: la fuente debe estar autorizada a ejecutar iam:AssumeRole en el rol de destino, y la directiva de confianza del destino debe aceptar la fuente. Para los humanos, una asignación de rol de cuenta proporciona lo que la fuente permite. Para las cuentas de servicio y las sesiones de rol, conceda la acción de origen en una directiva de cuenta. Usa el CRN de rol completo de la cuenta de destino para el acceso entre cuentas dentro de tu organización. Una directiva de origen puede nombrar ese rol aunque esté en una cuenta diferente. Cambiar X-Account-Id por sí solo nunca concede ese acceso. La consola asume automáticamente el rol único asignado cuando se selecciona una cuenta. Las asignaciones directas y de grupo pueden otorgar el mismo rol; los roles distintos en conflicto en una cuenta se rechazan. Para las integraciones, POST /v1/assume-role de IAM acepta role, opcional duration_seconds, y una sesión opcional policy. Utilice un CRN de rol calificado como crn:iam::production:role/deploy. La respuesta incluye access_token, expiration, account_id, account_handle, y role_id. Verifique el enlace de destino antes de usar Authorization: Bearer <access_token> para solicitudes de API de cuentas. Los atributos access_key_id, secret_access_key y session_token que acompañan a este valor son para la versión 4 de S3 Signature. Consulte autenticación. La sesión de rol se autoriza como el rol de destino. No hereda ni fusiona los permisos del principal de origen.

900–43200, default 3600

15 minutos a 12 horas, también delimitado por la duración máxima de sesión del rol.

Reducir el alcance de una sesión

policy en la llamada assume-role adjunta una política de sesión a las credenciales que se están creando:

{
  "role": "crn:iam::production:role/deploy",
  "policy": {
    "version": "2024-01-01",
    "statements": [{
      "effect": "allow",
      "actions": ["storage:GetObject"],
      "resources": ["crn:storage:sa-saopaulo-1:my-account:bucket/reports/*"]
    }]
  }
}

Una directiva de sesión no concede nada. Todas las solicitudes realizadas con las credenciales resultantes deben estar permitidas por las propias directivas del rol y por la directiva de sesión. Es una intersección, por lo que solo puede estrecharse.Las declaraciones de directiva de sesión tienen la misma forma que las directivas administradas, pero llevan Sin condiciones — una política de sesión se limita a acciones y recursos solamente.

Una política de sesión no válida falla la llamada con INVALID_INPUT en lugar de ser ignorada.

Sesiones de observación

Abra Identity & access → Sesiones STS para la cuenta seleccionada. Las sesiones muestran la cuenta y el rol de destino, la fecha de vencimiento, el tipo de concesión y la procedencia del principal de origen. Las sesiones antiguas pueden tener campos de origen que faltan. Los puntos finales de IAM correspondientes son GET /v1/sts-sessions, GET /v1/sts-sessions/{session_id}, y DELETE /v1/sts-sessions/{session_id}. Al eliminar una sesión, se revoca. La autorización vuelve a comprobar la expiración y revocación. Las sesiones de inicio de sesión personal se administran a través de los extremos de autenticación, no de esta lista de recursos de cuenta.

Darle una identidad a una instancia

El rol y la instancia deben pertenecer a la misma cuenta. El llamador que lo adjunta necesita iam:PassRole así como la acción compute. Si el rol tiene concesiones de directiva de organización, para aprobarlo también se requiere autoridad de delegación de organización; la administración de cuentas por sí sola no puede transferir esas concesiones. Esta es la razón por la que vale la pena configurar roles: una instancia puede contener credenciales sin que se le implemente ningún secreto.

Escribir una directiva de confianza que acepte instancias

{ "principals": ["crn:compute:*:my-account:instance/*"] }

Restringirlo a un id de instancia específica si se puede.

Adjuntar directivas de permisos al rol

Cualquier cosa que la carga de trabajo realmente necesite, y nada más, ya que cualquier cosa que se ejecute en la instancia puede acceder a estas credenciales.

Inicie la instancia con el rol

Console
API
CLI
Go

En Compute → Instances → Create instance, la tarjeta IAM role tiene una selección Role. El valor predeterminado es No role.

POST /v1/instances
{ "name": "web-1", "iam_role": "7c9e6679-7425-40de-944b-e07fc1f90ae7", ... }

basaltic compute instance create --name web-01 \
  --flavor s1.small --image debian-13 \
  --iam-role crn:iam::my-account:role/web \
  --networks '[{"subnet":"c1d2e3f4-a5b6-4c7d-8e9f-0a1b2c3d4e5f"}]'

_, err := compute.New(cfg).CreateInstance(ctx, &compute.InstanceCreateRequest{
    Name: "web-01", Flavor: "s1.small",
    Image: basaltic.String("debian-13"),
    IAMRole: basaltic.String("crn:iam::my-account:role/web"),
    Networks: []*compute.NetworkConfig{{Subnet: subnetID}},
})

Leer credenciales desde dentro de la VM

El servicio de metadatos de instancia en 169.254.169.254 mints y sirve credenciales temporales para el rol adjunto. Rotan antes de expirar, por lo que un proceso que los vuelve a leer sigue funcionando indefinidamente.

Nunca se escribe nada secreto en la instancia. El servicio de metadatos identifica al llamador por qué instancia es, crea una sesión contra el rol adjunto y devuelve credenciales que caducan por sí solas.

La directiva de confianza del rol debe permitir crn:compute:*:*:instance/*, o el CRN de la instancia específica. Una instancia lanzada con iam_role establecido pero una directiva de confianza que no lo acepta no obtiene credenciales.

Qué identidad usar

Pipeline de CI

Una cuenta de servicio con una clave de acceso, almacenada en el almacén secreto de CI. Ampliar el ámbito a la cuenta y las acciones que necesita el embudo. Si la canalización hace varias cosas no relacionadas, prefiera varias cuentas de servicio en lugar de una clave amplia.

Software que se ejecuta en una instancia

Un rol de instancia. No se implementa ningún secreto, las credenciales rotan por sí solas y la revocación del acceso es un cambio en el rol en lugar de una reimplementación.

Una persona que realiza trabajos operativos

Su inicio de sesión personal y un rol de cuenta asignado. Usar credenciales de rol temporales para las operaciones de cuenta; mantener el trabajo de la organización en su sesión personal de Workspace.

Concesión de acceso elevado temporal

Un rol con una política de confianza y permiso de origen o asignación humana, más un corto duration_seconds. La suposición se registra como una sesión STS, por lo que la elevación es visible y revocable en lugar de implícita.

Escribir políticas

Qué poner en las directivas de permisos de un rol.

Límites de permisos

El límite de un rol también limita sus sesiones.

Primeros pasos

Productos

Plataforma

Ayuda

Roles y credenciales

Cuentas de servicio

Roles

Credenciales temporales

Identidad de instancia

Cuentas de servicio

Roles

Políticas de permisos

Política de confianza

Políticas de confianza

Asumir un rol

Reducir el alcance de una sesión

Sesiones de observación

Darle una identidad a una instancia

Qué identidad usar

Siguiente

Escribir políticas

Límites de permisos

Cuentas de servicio

Roles

Credenciales temporales

Identidad de instancia

​Cuentas de servicio

​Roles

Políticas de permisos

Política de confianza

​Políticas de confianza

​Asumir un rol

​Reducir el alcance de una sesión

​Sesiones de observación

​Darle una identidad a una instancia

​Qué identidad usar

​Siguiente

Escribir políticas

Límites de permisos

Cuentas de servicio

Roles

Políticas de confianza

Asumir un rol

Reducir el alcance de una sesión

Sesiones de observación

Darle una identidad a una instancia

Qué identidad usar

Siguiente