Límites de permisos

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.

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.

Escribir el techo

Una política que describe el conjunto más amplio de permisos que cualquier cosa en este equipo puede tener.

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

Adjúntalo como un límite

Console
API
CLI
Go

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.

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.

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.

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

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.

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

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.

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.

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: Una denegación explícita en el dominio de la política evaluada lo corta. Consulte cómo se autoriza una solicitud.

Falling closed

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.

Ejemplo de trabajo

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

1. La frontera

Todo lo que este equipo pueda tocar: computación y almacenamiento, solo en recursos etiquetados como suyos, y nunca IAM.

{
  "version": "2024-01-01",
  "statements": [
    {
      "sid": "Ceiling",
      "effect": "allow",
      "actions": ["compute:*", "storage:*"],
      "resources": ["*"],
      "conditions": [
        { "operator": "equals", "key": "basalt:ResourceTag/team", "values": ["platform"] }
      ]
    }
  ]
}

2. Lo que el líder del equipo puede adjuntar

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:

{
  "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/*"
    ]
  }]
}

3. Por qué esto es seguro

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.

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.

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

Ambos restringen, y no son intercambiables.

Usar un límite

Para limitar un principal mientras deja que otra persona administre sus políticas. Es un límite máximo de delegación.

Usar una negación explícita

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.

Escribir políticas

El formato del documento que usa un límite — es una política ordinaria.

Roles y credenciales

Las directivas de sesión se restringen de la misma manera, por conjunto de credenciales.

Primeros pasos

Productos

Plataforma

Ayuda

Límites de permisos

Por qué existen

A qué se aplica un límite

Cómo combina con todo lo demás

Falling closed

Ejemplo de trabajo

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

Usar un límite

Usar una negación explícita

Siguiente

Escribir políticas

Roles y credenciales

​Por qué existen

​A qué se aplica un límite

​Cómo combina con todo lo demás

​Falling closed

​Ejemplo de trabajo

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

Usar un límite

Usar una negación explícita

​Siguiente

Escribir políticas

Roles y credenciales

Por qué existen

A qué se aplica un límite

Cómo combina con todo lo demás

Falling closed

Ejemplo de trabajo

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

Siguiente