> ## 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.

# Permisos de IAM

> Acciones de IAM de cuenta, nombres de recursos y salvaguardias para el acceso delegado de la organización.

Las acciones de IAM se aplican a roles de cuenta, cuentas de servicio, políticas y sesiones. Otorgarlos a través de políticas de cuenta. Las cuentas de la organización, las personas, los grupos y las directivas de la organización usan [Workspace actions](/es/workspace/permissions).

<a id="policy-role-and-group-crns-use-immutable-names" />

## Los CRN de directiva, rol y grupo usan nombres inmutables

Las funciones de cuenta, las directivas y las cuentas de servicio usan nombres inmutables en los CRN de recursos. Los grupos de espacios de trabajo y las directivas de organización también usan nombres inmutables, con su UUID de organización en la ruta:

```
crn:iam::production:role/deploy
crn:iam::production:policy/read-reports
crn:iam::production:service-account/deploy-bot
crn:iam:::policy/Administrator
crn:workspace:::group/report-readers
```

La ranura de cuenta vacía en una directiva del sistema es intencional. No es una cuenta llamada `platform`. Los parámetros de ruta como `{role_id}` siguen siendo UUIDs. Los CRN de los principales de la política de confianza son un uso separado: las identidades de máquina concretas están vinculadas a los UUID, por lo que un nombre recreado no hereda la confianza.

<a id="the-actions" />

## Las acciones

La referencia de API y esta tabla usan las acciones de autorización del servicio. `none` significa que se aplica otro mecanismo de autenticación, como se describe a continuación.

| Llamada de teléfono | Acción |
| - | - |
| `GET /v1/regions` | `none` |
| `GET /v1/service-accounts` | `iam:ListServiceAccounts` |
| `POST /v1/service-accounts` | `iam:CreateServiceAccount` |
| `GET /v1/service-accounts/{service_account_id}` | `iam:GetServiceAccount` |
| `PATCH /v1/service-accounts/{service_account_id}` | `iam:UpdateServiceAccount` |
| `DELETE /v1/service-accounts/{service_account_id}` | `iam:DeleteServiceAccount` |
| `GET /v1/service-accounts/{service_account_id}/credentials` | `iam:ListCredentials` |
| `POST /v1/service-accounts/{service_account_id}/credentials` | `iam:ManageCredentials` |
| `DELETE /v1/service-accounts/{service_account_id}/credentials/{credential_id}` | `iam:ManageCredentials` |
| `GET /v1/service-accounts/{service_account_id}/policies` | `iam:ListServiceAccountPolicies` |
| `POST /v1/service-accounts/{service_account_id}/policies` | `iam:AttachPolicy` |
| `DELETE /v1/service-accounts/{service_account_id}/policies/{policy_id}` | `iam:DetachPolicy` |
| `GET /v1/roles` | `iam:ListRoles` |
| `POST /v1/roles` | `iam:CreateRole` |
| `GET /v1/roles/{role_id}` | `iam:GetRole` |
| `PATCH /v1/roles/{role_id}` | `iam:UpdateRole` |
| `DELETE /v1/roles/{role_id}` | `iam:DeleteRole` |
| `GET /v1/roles/{role_id}/policies` | `iam:ListRolePolicies` |
| `POST /v1/roles/{role_id}/policies` | `iam:AttachPolicy` |
| `DELETE /v1/roles/{role_id}/policies/{policy_id}` | `iam:DetachPolicy` |
| `GET /v1/policies` | `iam:ListPolicies` |
| `POST /v1/policies` | `iam:CreatePolicy` |
| `GET /v1/policies/{policy_id}` | `iam:GetPolicy` |
| `PATCH /v1/policies/{policy_id}` | `iam:UpdatePolicy` |
| `DELETE /v1/policies/{policy_id}` | `iam:DeletePolicy` |
| `GET /v1/policies/{policy_id}/service-accounts` | `iam:GetPolicy` |
| `GET /v1/policies/{policy_id}/roles` | `iam:GetPolicy` |
| `POST /v1/assume-role` | `iam:AssumeRole` |
| `POST /v1/assume-role-with-web-identity` | `none` |
| `POST /v1/oauth/token` | `none` |
| `POST /v1/oauth/revoke` | `none` |
| `GET /v1/sts-sessions` | `iam:ListSTSSessions` |
| `GET /v1/sts-sessions/{session_id}` | `iam:GetSTSSession` |
| `DELETE /v1/sts-sessions/{session_id}` | `iam:RevokeSession` |
| `PUT /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:SetPermissionBoundary` |
| `GET /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:GetPermissionBoundary` |
| `DELETE /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:RemovePermissionBoundary` |
| `GET /v1/service-accounts/{service_account_id}/inline-policies` | `iam:ListInlinePolicies` |
| `PUT /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:PutInlinePolicy` |
| `GET /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:GetInlinePolicy` |
| `DELETE /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:DeleteInlinePolicy` |
| `PUT /v1/roles/{role_id}/permission-boundary` | `iam:SetPermissionBoundary` |
| `GET /v1/roles/{role_id}/permission-boundary` | `iam:GetPermissionBoundary` |
| `DELETE /v1/roles/{role_id}/permission-boundary` | `iam:RemovePermissionBoundary` |
| `GET /v1/roles/{role_id}/inline-policies` | `iam:ListInlinePolicies` |
| `PUT /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:PutInlinePolicy` |
| `GET /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:GetInlinePolicy` |
| `DELETE /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:DeleteInlinePolicy` |

`iam:PassRole` también es necesario cuando se asigna un rol a una instancia o a un grupo de instancias. El rol debe pertenecer a la cuenta de destino.

<a id="attaching-and-detaching-require-both-resources" />

## La conexión y la desconexión requieren ambos recursos

`iam:AttachPolicy` y `iam:DetachPolicy` requieren la misma acción en la directiva de cuenta y en la cuenta de rol o servicio de destino. Una subvención que cubra solo las políticas o solo las identidades es insuficiente.

```json theme={null}
{
  "version": "2024-01-01",
  "statements": [{
    "effect": "allow",
    "actions": ["iam:AttachPolicy", "iam:DetachPolicy"],
    "resources": [
      "crn:iam::production:policy/read-reports",
      "crn:iam::production:role/reports"
    ]
  }]
}
```

Una política del sistema necesita cobertura de su propio `crn:iam:::policy/<Name>` CRN también. Cada comprobación de recursos utiliza las etiquetas de ese recurso. Las directivas de límites y de sesión deben permitir ambas comprobaciones. La denegación explícita en cualquier recurso impide el cambio.

Los archivos adjuntos de las políticas de organización usan rutas de espacio de trabajo separadas y una comprobación doble diferente: consulta [delegación de organización](/es/workspace/permissions#delegating-organization-policies).

<a id="listing-cannot-be-narrowed" />

## El listado no se puede restringir

Las listas de nivel superior autorizan un CRN de colección, como `crn:iam::production:role/*`. No autorizan cada fila devuelta por separado. Un permiso en un rol concreto CRN por lo tanto no concede acceso a la lista. Las listas de relaciones autorizan a su padre en su lugar, como un rol al listar sus directivas de cuenta. Los filtros de consulta de nombre y CRN eligen filas; no cambian el permiso requerido para enumerarlas.

<a id="sub-resources-are-governed-by-their-parent" />

## Los subrecursos se rigen por su recurso principal

La autorización de directiva en línea utiliza el CRN de la identidad principal más `/inline-policy/<name>` o `/inline-policy/*` para su lista:

```
crn:iam::production:role/deploy/inline-policy/read-artifacts
```

Las operaciones de límite de cuenta usan `crn:iam::production:permission-boundary/<principal-uuid>`. Para establecer un límite también se requiere permiso para leer la directiva seleccionada. Los límites de usuario del espacio de trabajo usan su propia forma de recurso de ámbito de organización.

La política en línea y la administración de límites son permisos sensibles. Alguien que puede reemplazar un límite puede elevar su techo; no incluya esas acciones en una delegación destinada solo a administrar políticas por debajo de un techo fijo.

<a id="protecting-organization-delegation" />

## Protección de la delegación de la organización

Los permisos de administrador de cuenta no permiten que alguien adquiera autoridad de la organización de forma indirecta. Las operaciones confidenciales en una identidad que ya tiene concesiones de organización también requieren autoridad de delegación de espacio de trabajo para esas concesiones. Estos incluyen pasar un rol, cambiar su confianza, emitir credenciales de cuenta de servicio y cambiar los límites de identidad.

<a id="sessions-and-authentication" />

## Sesiones y autenticación

Las lecturas de sesión de cuenta y la revocación autorizan `crn:iam::<account-handle>:sts-session/<session-uuid>`. La cuenta seleccionada debe ser propietaria de la sesión. Las sesiones de inicio de sesión personal no aparecen en esta colección.

El punto final de revocación también lee la sesión para su respuesta, por lo que concede `iam:GetSTSSession` junto con `iam:RevokeSession`.

El catálogo de regiones públicas no tiene ninguna acción de directiva. El intercambio de tokens OAuth valida las credenciales y la revocación de tokens valida la sesión suministrada. La suposición de identidad web verifica la identidad externa y la confianza de destino; no requiere el permiso `iam:AssumeRole` de un llamador existente. Ordinary AssumeRole sí lo hace.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.