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

# Límites de permisos

> Limitar lo que se puede conceder a un principal, para que pueda delegar la administración de permisos de forma segura.

Un límite de permiso es una política adjunta a un principal que establece el **máximo dentro de su dominio de política** que se puede conceder. No otorga nada por sí mismo, es un techo, no un piso.

```
effective permissions  =  what the policies allow  ∩  what the boundary allows
```

Una acción tiene que ser permitida por **ambos**. Una política que concede algo fuera de la frontera no concede nada.

Las cuentas y roles de servicio de cuentas usan límites de directiva de cuentas. Los usuarios usan los límites de la directiva de organización de Workspace. Los límites de cuenta no limitan los permisos de organización delegados por separado; controlan aquellos con concesiones de directivas de organización y directivas de sesión aplicables.

<a id="why-they-exist" />

## Por qué existen

Sin límites, dejar que alguien administre permisos significa dejar que se conceda cualquier cosa. Un límite te permite delegar de forma segura: un líder de equipo puede crear cuentas de servicio y adjuntar políticas, y nada de lo que adjunte puede superar el límite que establezcas.

<Steps>
  <Step title="Escribir el techo">
    Una política que describe el conjunto más amplio de permisos que cualquier cosa en este equipo puede tener.

    ```json theme={null}
    {
      "version": "2024-01-01",
      "statements": [{
        "sid": "TeamCeiling",
        "effect": "allow",
        "actions": ["compute:*", "storage:*", "dns:*"],
        "resources": ["*"],
        "conditions": [
          { "operator": "equals", "key": "basalt:ResourceTag/team", "values": ["platform"] }
        ]
      }]
    }
    ```
  </Step>

  <Step title="Adjúntalo como un límite">
    <Tabs>
      <Tab title="Console">
        Abra el usuario, la cuenta de servicio o el rol y busque su tarjeta **Permission
        Boundary**. Elija **Set Boundary** y elija la política. Una vez que se establece uno, el botón dice **Change**, y al desmarcarlo se confirma con **Remove Permission Boundary**.

        Un grupo no tiene tal tarjeta, que es la tabla de abajo hecha visible.
      </Tab>

      <Tab title="API">
        ```bash theme={null}
        PUT /v1/service-accounts/{service_account_id}/permission-boundary
        { "policy": "..." }
        ```

        Los mismos métodos existen para los roles en IAM. Los límites de usuario usan `workspace.basaltic.sh/v1/users/{user_id}/permission-boundary` y una política de organización.
      </Tab>

      <Tab title="CLI">
        ```bash theme={null}
        basaltic iam service-account set-permission-boundary <service-account-id> \
          --policy <policy-id>
        ```

        `get-permission-boundary` y `remove-permission-boundary` son los otros dos, y `workspace user` y `iam role` llevan los mismos tres.
      </Tab>

      <Tab title="Go">
        ```go theme={null}
        err := iam.New(cfg).SetServiceAccountPermissionBoundary(ctx, serviceAccountID,
            &iam.SetBoundaryRequest{Policy: policyID})
        ```
      </Tab>
    </Tabs>
  </Step>

  <Step title="Delegar la gestión de políticas">
    Quien quiera que administre este principal ahora puede adjuntar las políticas que desee. Cualquier cosa fuera del techo no tiene efecto.
  </Step>
</Steps>

<a id="what-a-boundary-applies-to" />

## A qué se aplica un límite

| Principal | Delimitado en |
| - | - |
| Usuario registrado | Su propio límite de espacio de trabajo, para acciones de organización |
| Cuenta de servicio | Su límite de cuenta, para las acciones de cuenta |
| Papel asumido | El límite de cuenta del **rol**: la sesión hereda el límite de cuenta |
| Grupo de trabajo | — Los grupos llevan políticas, no fronteras |

<Note>
  Una sesión de rol asumido está limitada por el rol que asumió, no por quien lo asumió. El rol es la entidad limitada; una sesión no puede escapar del límite de su rol al ser creada desde un llamador no limitado.
</Note>

<Note>
  Los propietarios de la organización siguen la misma evaluación de la política que otros directores. No se puede adjuntar un límite duradero que elimine el acceso de administrador requerido del propietario. Transfiera la propiedad antes de restringir esas concesiones. Las restricciones temporales de sesión siguen aplicándose.
</Note>

<a id="how-it-combines-with-everything-else" />

## Cómo combina con todo lo demás

Un límite es el **último** de los tres pasos de estrechamiento, y cada uno solo puede restar:

```mermaid theme={null}
flowchart LR
    A[Identity policies] --> B[∩ session policy]
    B --> C[∩ permission boundary]
    C --> D[Effective permissions]
```

Una denegación explícita en el dominio de la política evaluada lo corta. Consulte [cómo se autoriza una solicitud](/es/iam#how-a-request-is-authorized).

<a id="failing-closed" />

## Falling closed

<Warning>
  Si se establece un límite pero el límite o su política **no se puede leer**, la solicitud se deniega. Un límite que existe pero es ilegible podría estar limitando esta misma acción, por lo que la respuesta segura es no.

  La consecuencia práctica: eliminar una política que se está utilizando como límite no amplía el acceso, lo elimina.
</Warning>

<a id="worked-example" />

## Ejemplo de trabajo

Delegar la administración de instancias a un equipo, de forma segura.

<AccordionGroup>
  <Accordion title="1. La frontera" icon="shield">
    Todo lo que este equipo pueda tocar: computación y almacenamiento, solo en recursos etiquetados como suyos, y nunca IAM.

    ```json theme={null}
    {
      "version": "2024-01-01",
      "statements": [
        {
          "sid": "Ceiling",
          "effect": "allow",
          "actions": ["compute:*", "storage:*"],
          "resources": ["*"],
          "conditions": [
            { "operator": "equals", "key": "basalt:ResourceTag/team", "values": ["platform"] }
          ]
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="2. Lo que el líder del equipo puede adjuntar" icon="user-cog">
    Una directiva de cuenta que permite la creación de cuentas de servicio y los datos adjuntos de directivas de cuenta seleccionadas. Las comprobaciones de archivos adjuntos requieren tanto CRN de identidad como de política:

    ```json theme={null}
    {
      "version": "2024-01-01",
      "statements": [{
        "sid": "ManageTeamServiceAccounts",
        "effect": "allow",
        "actions": [
          "iam:CreateServiceAccount",
          "iam:AttachPolicy",
          "iam:PutInlinePolicy"
        ],
        "resources": [
          "crn:iam::my-account:service-account/*",
          "crn:iam::my-account:policy/team-*",
          "crn:iam::my-account:service-account/*/inline-policy/*"
        ]
      }]
    }
    ```
  </Accordion>

  <Accordion title="3. Por qué esto es seguro" icon="check">
    Supongamos que el lead adjunta `{"effect": "allow", "actions": ["*"],
            "resources": ["*"]}` a una cuenta de servicio delimitada.

    Esa cuenta de servicio todavía no puede tocar IAM, no puede tocar un recurso etiquetado para otro equipo y no puede alcanzar ningún servicio fuera de computación y almacenamiento: el límite se cruza con todos ellos. La política general no se rechaza; simplemente no llega más allá del techo.

    <Note>
      Observe lo que este ejemplo **no** hace: no permite que el lead adjunte o elimine *límites*. Si pudieran, podrían elevar su propio techo. Conceda la gestión de los límites solo a quienes estén destinados a establecer el techo.
    </Note>
  </Accordion>
</AccordionGroup>

<a id="boundary-or-explicit-deny" />

## ¿Límite o negación explícita?

Ambos restringen, y no son intercambiables.

<Columns cols={2}>
  <Card title="Usar un límite" icon="shield">
    Para limitar **un principal** mientras deja que otra persona administre sus políticas. Es un límite máximo de delegación.
  </Card>

  <Card title="Usar una negación explícita" icon="ban">
    Rechazar las acciones de coincidencia incluso cuando otra política las permite. Un deny supera a cualquier allow en el mismo dominio de política.
  </Card>
</Columns>

<a id="next" />

## Siguiente

<CardGroup cols={2}>
  <Card title="Escribir políticas" icon="file-text" href="/es/iam/policies">
    El formato del documento que usa un límite — es una política ordinaria.
  </Card>

  <Card title="Roles y credenciales" icon="key-round" href="/es/iam/roles">
    Las directivas de sesión se restringen de la misma manera, por conjunto de credenciales.
  </Card>
</CardGroup>


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