> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Roles y credenciales > Acceda a claves, roles y directivas de confianza, credenciales temporales y atribuya una identidad a una instancia. 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. Teclas de acceso de larga duración para scripts e IC. Permisos que otra cosa toma prestados, controlados por una política de confianza. Asumir un rol, opcionalmente con un alcance más reducido. 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: 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. ```bash theme={null} POST /v1/service-accounts { "name": "deploy-bot" } POST /v1/service-accounts/{service_account_id}/credentials { "name": "ci-key" } ``` ```bash theme={null} basaltic iam service-account create --name deploy-bot basaltic iam service-account create-credential \ --name ci-key ``` `--expires-at` en la credencial toma una marca de tiempo RFC 3339. ```go theme={null} 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. 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**. ```bash theme={null} POST https://iam.basaltic.sh/v1/service-accounts/{service_account_id}/policies { "policy": "" } ``` Las concesiones de organización usan la misma ruta en `workspace.basaltic.sh`, con `{ "policy_id": "" }`. ```bash theme={null} basaltic iam service-account attach-policy \ --policy ``` ```go theme={null} 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](/es/workspace/permissions#delegating-organization-policies). ## 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: Lo que el rol puede hacer en su cuenta, además de cualquier directiva de organización delegada por separado. 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**: ```json theme={null} { "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:::service-account/` | | Papel asumido | `crn:iam:::role/` | | Usuario registrado | `crn:workspace:::user/` | | Instancia de cálculo | `crn:compute:::instance/` | 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 ` 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](/es/authentication). La sesión de rol se autoriza como el rol de destino. No hereda ni fusiona los permisos del principal de origen. 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: ```json theme={null} { "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. ```json theme={null} { "principals": ["crn:compute:*:my-account:instance/*"] } ``` Restringirlo a un id de instancia específica si se puede. 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. En **Compute → Instances → Create instance**, la tarjeta **IAM role** tiene una selección **Role**. El valor predeterminado es **No role**. ```bash theme={null} POST /v1/instances { "name": "web-1", "iam_role": "7c9e6679-7425-40de-944b-e07fc1f90ae7", ... } ``` ```bash theme={null} 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"}]' ``` ```go theme={null} _, 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}}, }) ``` 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 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. 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. 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. 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.