Skip to main content
As ações do IAM se aplicam a funções de conta, contas de serviço, políticas e sessões. Conceda-os por meio de políticas de conta. Contas de organização, pessoas, grupos e políticas de organização usam Ações de espaço de trabalho.

Os CRNs de política, função e grupo usam nomes imutáveis

As funções de conta, políticas e contas de serviço usam nomes imutáveis em CRNs de recursos. Os grupos de workspace e as políticas organizacionais também usam nomes imutáveis, com o UUID da organização no caminho:
O slot de conta vazio em uma política de sistema é intencional. Não é uma conta chamada platform. Parâmetros de caminho como {role_id} permanecem UUIDs. CRNs de princípio de política de confiança são um uso separado: identidades de máquina concretas são vinculadas a UUIDs, de modo que um nome recriado não herda confiança.

As ações

A referência da API e esta tabela usam as ações de autorização do serviço. none significa que outro mecanismo de autenticação é aplicado, conforme descrito abaixo. iam:PassRole também é necessário ao atribuir uma função a uma instância ou a um pool de instâncias. A função deve pertencer à conta de destino.

Anexação e desassociação requerem ambos os recursos

iam:AttachPolicy e iam:DetachPolicy exigem a mesma ação na política de conta e na conta de função ou serviço de destino. Uma subvenção que abranja apenas políticas ou apenas identidades é insuficiente.
Uma política de sistema precisa de cobertura de seu próprio crn:iam:::policy/<Name> CRN também. Cada verificação de recurso usa as tags desse recurso. Os limites e as políticas de sessão devem permitir ambas as verificações. Negação explícita em qualquer recurso impede a alteração. Os anexos de políticas da organização usam rotas separadas do Workspace e uma verificação dupla diferente: consulte delegação da organização.

A listagem não pode ser restringida

As listas de nível superior autorizam um CRN de coleção, como crn:iam::production:role/*. Eles não autorizam cada linha retornada separadamente. Uma permissão em um CRN de função concreta, portanto, não concede acesso à lista. As listas de relacionamento autorizam seu pai, como uma função ao listar suas políticas de conta. Os filtros de consulta de nome e CRN escolhem linhas; eles não alteram a permissão necessária para listá-las.

Os sub-recursos são governados pelo seu pai

A autorização de política em linha usa o CRN da identidade principal mais /inline-policy/<name> ou /inline-policy/* para sua lista:
Operações de limite de conta usam crn:iam::production:permission-boundary/<principal-uuid>. A definição de um limite também requer permissão para ler a política selecionada. Os limites de usuário do espaço de trabalho usam sua própria forma de recurso de escopo organizacional. A política em linha e o gerenciamento de limites são permissões confidenciais. Alguém que pode substituir um limite pode aumentar seu limite máximo; não inclua essas ações em uma delegação destinada apenas a gerenciar políticas abaixo de um limite máximo fixo.

Proteger a delegação da organização

As permissões de administrador de conta não permitem que alguém adquira autoridade de organização indiretamente. Operações confidenciais em uma identidade que já tem concessões de organização também exigem autoridade de delegação de espaço de trabalho para essas concessões. Isso inclui passar uma função, alterar sua confiança, emitir credenciais de conta de serviço e alterar limites de identidade.

Sessões e autenticação

As leituras e revogações de sessão de conta autorizam crn:iam::<account-handle>:sts-session/<session-uuid>. A conta selecionada deve ser proprietária da sessão. As sessões de início de sessão pessoal não aparecem nesta coleção. O endpoint de revogação também lê a sessão para sua resposta, então conceda iam:GetSTSSession junto com iam:RevokeSession. O catálogo de regiões públicas não tem ação de política. A troca de token OAuth valida as credenciais e a revogação de token valida a sessão fornecida. A suposição de identidade da Web verifica a identidade externa e a confiança do alvo; não requer a permissão iam:AssumeRole de um chamador existente. Ordinary AssumeRole faz isso.