Acesso à conta

Uma conta possui recursos e identidades de conta IAM. Funções, contas de serviço, políticas de conta e sessões STS pertencem a uma conta, mesmo que o IAM tenha um endpoint global. Selecionar outra região deixa essa propriedade inalterada.

​

Criar uma conta

O espaço de trabalho cria contas em POST /v1/accounts. A resposta inclui a nova conta e seu bootstrap_role_id e bootstrap_role_crn. Cada conta começa com duas funções de sistema atribuíveis: Essas funções não podem ser alteradas ou excluídas e não consomem cota de função personalizada. Suas respostas os identificam com builtin_kind: administrator ou readonly. O proprietário da organização recebe uma atribuição de Administrador. Um criador de conta humano também recebe essa atribuição, e os campos de inicialização identificam essa função. Nenhuma das funções concede permissões de organização. Para um criador de máquina, a criação cria adicionalmente uma função personalizada de AccountAdministrator confiada à identidade imutável do criador. A máquina ainda precisa de permissão iam:AssumeRole do lado do código-fonte. Essa função personalizada consome cota e pode ser alterada ou removida normalmente.

​

Atribuir pessoas a funções de conta

No console, abra Organization → Contas, selecione a conta e abra Settings. O cartão Acesso à conta permite que você Atribuir função a um usuário ou grupo. Uma atribuição de grupo se aplica aos seus membros de usuário. Uma atribuição e a política de confiança da função são requisitos separados:

1. A atribuição autoriza o humano a solicitar iam:AssumeRole para esse papel.
2. A política de confiança da função deve aceitar o CRN do principal de espaço de trabalho desse usuário.
3. Após a suposição, as solicitações de conta usam as permissões da função.

As funções internas já confiam nos usuários da organização; as atribuições controlam quais usuários podem assumi-las. A atribuição de uma função personalizada nunca altera silenciosamente a sua política de fidedignidade. Abra o editor Trust Policy da função para permitir os usuários pretendidos. Um grupo não é um principal assumido: use os CRNs principais dos usuários ou um padrão de usuário com escopo organizacional junto com atribuições de função controladas. A API de espaço de trabalho expõe essas operações: Uma atribuição contém principal_type (user ou group), principal_id e role_id, todos resolvidos dentro da organização e da conta de destino. As contas de serviço usam políticas de identidade e confiança, não atribuições de funções humanas.

​

Usando uma função de conta

Cada pessoa tem uma função efetiva por conta. Atribuições diretas e associações a grupos podem conceder a mesma função por vários caminhos. Uma função diferente é rejeitada com 409 ACCOUNT_ROLE_CONFLICT, incluindo quando adicionar alguém a um grupo criaria esse conflito. Combine as permissões necessárias em uma função ou remova as atribuições conflitantes antes de atribuir uma substituição. O console assume automaticamente sua função quando você seleciona uma conta. Todas as pessoas, incluindo os proprietários da organização, usam uma função de conta atribuída para serviços de conta. Não há menu de seleção de função. O console mantém sua sessão de organização pessoal separada da sessão de função de conta. As páginas da organização usam sua sessão pessoal; as páginas da conta usam a função atribuída à conta. Alterar a conta ou a organização limpa o contexto de função anterior. As sessões de função expiradas são renovadas a partir da sua sessão pessoal, sujeitas às atribuições e confiança atuais. Para integrações, use GET /v1/account-roles para descobrir as atribuições de um humano e, em seguida, envie o CRN de função atribuído da conta de destino para o POST /v1/assume-role do IAM. Verifique o account_id, account_handle e role_id retornados antes de usar o token. Alterar X-Account-Id não altera a autoridade de conta de um token.

​

Removendo acesso e excluindo contas

Remover uma atribuição impede novas suposições através dessa atribuição. Revise e revogue as sessões existentes ao encerrar o acesso ativo; não trate a remoção de atribuição como um substituto para a revogação de sessão. Uma conta deve estar vazia antes da exclusão. Funções personalizadas, políticas, contas de serviço e sessões ativas de função personalizada ou conta de serviço contam como recursos, juntamente com a infraestrutura. As duas funções internas e suas sessões não bloqueiam a exclusão; excluir a conta torna essas sessões inutilizáveis. Para a limpeza automatizada de contas, mantenha as credenciais da organização original. Remova recursos usando a função de administrador de conta. Se for uma função de inicialização personalizada, exclua-a por último e, em seguida, exclua a conta com a credencial da organização. A exclusão de uma função personalizada também remove suas sessões.

​

Mantendo o acesso do proprietário

A propriedade em si não concede permissões. O proprietário tem uma política de administrador da organização explícita e uma atribuição de administrador em cada conta ativa. As alterações de permissão que removeriam esse acesso falham com 409 OWNER_ACCESS_REQUIRED, incluindo restrições indiretas por meio de grupos ou limites. Uma sessão temporária restritiva ainda limita as solicitações do proprietário. A transferência de propriedade estabelece as concessões necessárias do destinatário atomicamente. Um destinatário com negações conflitantes ou um limite restritivo não pode se tornar o proprietário até que essas restrições sejam resolvidas. As concessões explícitas do proprietário anterior permanecem até que você as revogue separadamente. Transfira a propriedade antes de remover o acesso de administrador necessário do proprietário atual.