Conceder permissões autogerenciadas - AWS CloudFormation

Conceder permissões autogerenciadas

Este tópico fornece instruções sobre como criar os perfis de serviço do IAM requeridos pelo StackSets para a implantação em contas e em Regiões da AWS com permissões autogerenciadas. Essas funções são necessárias para estabelecer um relacionamento confiável entre a conta na qual você está administrando o conjunto de pilhas e a conta na qual você está implantando instâncias de pilha. Usando esse modelo de permissões, o StackSets pode implantar em qualquer Conta da AWS na qual você tenha permissões para criar um perfil do IAM.

Para usar permissões gerenciadas pelo serviço, consulte Ativar o acesso confiável com AWS Organizations.

Visão geral das permissões autogerenciadas

Antes de criar um conjunto de pilhas com permissões autogerenciadas, é necessário ter criado perfis de serviço do IAM em cada conta.

As etapas básicas são:

  1. Determine qual conta da AWS é a conta do administrador.

    Os conjuntos de pilha serão criados nessa conta de administrador. Uma conta de destino é a conta na qual você cria as pilhas individuais que pertencem a um conjunto de pilhas.

  2. Determine como você deseja estruturar as permissões para os conjuntos de pilha.

    A configuração de permissões mais simples (e mais permissiva) é oferecer a todos os usuários e grupos na conta de administrador a capacidade de criar e atualizar todos os conjuntos de pilhas gerenciados por meio daquela conta. Se precisar de um controle mais refinado, defina permissões para especificar:

    • Quais usuários e grupos podem executar operações do conjunto de pilhas em quais contas de destino.

    • Quais recursos os usuários e grupos podem incluir em seus conjuntos de pilhas.

    • Quais operações do conjunto de pilhas os usuários e grupos específicos podem realizar.

  3. Crie as funções de serviço do IAM necessárias nas contas de administrador e de destino para definir as permissões desejadas.

    Especificamente, os dois perfis necessários são:

    • AWSCloudFormationStackSetAdministrationRole: este perfil é implantado na conta do administrador.

    • AWSCloudFormationStackSetExecutionRole: este perfil é implantado em todas as contas nas quais você cria instâncias de pilha.

Concessão de permissões para o gerenciamento de pilhas em todas as contas de destino a todos os usuários da conta do administrador

Esta seção mostra como configurar permissões para permitir que todos os usuários e os grupos da conta do administrador executem operações de conjunto de pilhas em todas as contas de destino. A seção orientará você na criação dos perfis de serviço do IAM necessários nas contas de administrador e de destino. Qualquer pessoa que usa a conta do administrador pode criar, atualizar ou excluir pilhas em qualquer uma das contas de destino.

Ao estruturar as permissões dessa maneira, os usuários não transferem um perfil de administração ao criar ou ao atualizar conjuntos de pilhas.

Configure uma relação de confiança entre a conta do administrador e as contas de destino. Assim, qualquer usuário na conta de administrador poderá criar um conjunto de pilhas.
Administrator account

Na conta do administrador, crie uma função do IAM denominada AWSCloudFormationStackSetAdministrationRole.

É possível fazer isso ao criar uma pilha usando o modelo do CloudFormation disponível em https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml.

exemplo Exemplo de política de permissões

O perfil de administração criado pelo modelo disponibilizado anteriormente inclui a política de permissões apresentada a seguir.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole" ], "Effect": "Allow" } ] }
exemplo Exemplo de política de confiança 1

O modelo disponibilizado anteriormente também inclui a política de confiança, apresentada a seguir, que concede ao serviço a permissão para usar o perfil de administração e as permissões anexadas ao perfil.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
exemplo Exemplo de política de confiança 2

Para implantar instâncias de pilha em uma conta de destino que reside em uma região desabilitada por padrão, você também deverá incluir a entidade principal de serviço regional para essa região. Cada região desabilitada por padrão terá sua própria entidade principal de serviço regional.

O exemplo de política de confiança apresentado a seguir concede ao serviço a permissão para usar o perfil de administração na região Ásia-Pacífico (Hong Kong) (ap-east-1), uma região que está desabilitada por padrão.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "cloudformation.amazonaws.com", "cloudformation.ap-east-1.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

Para ter mais informações, consulte Execução de operações de conjunto de pilhas envolvendo regiões desabilitadas por padrão. Para obter uma lista de códigos de região, consulte Regional endpoints no Guia de referência geral da AWS.

Target accounts

Em cada conta de destino, crie uma função de serviço chamada AWSCloudFormationStackSetExecutionRole que confie na conta do administrador. Essa função deve ter esse nome exato. É possível fazer isso ao criar uma pilha usando o modelo do CloudFormation disponível em https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml. Ao usar este modelo, você será solicitado a fornecer o ID da conta do administrador com a qual sua conta de destino deve ter uma relação de confiança.

Importante

Lembre-se de que este modelo concede acesso de administrador. Depois de usar o modelo para criar uma função de execução da conta de destino, você deve definir o escopo das permissões na declaração de política para os tipos de recursos que você criará usando o StackSets.

O perfil de serviço da conta de destino requer permissões para executar quaisquer operações especificadas no modelo do CloudFormation. Por exemplo, se o seu modelo estiver criando um bucket do S3, então você precisará de permissões para criar novos objetos para o S3. A conta de destino sempre precisa da concessão de permissões totais por parte do CloudFormation, que incluem permissões para criar, atualizar, excluir e descrever pilhas.

exemplo Exemplo 1 de política de permissões

A função criada por este modelo habilita a seguinte política em uma conta de destino.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
exemplo Exemplo 2 de política de permissões

O exemplo a seguir mostra uma declaração de política com as permissões mínimas para que o StackSets funcione. Para criar pilhas em contas de destino que usam recursos de serviços que são diferentes dos recursos usados pelo CloudFormation, é necessário adicionar essas ações e esses recursos de serviço à instrução de política AWSCloudFormationStackSetExecutionRole para cada conta de destino.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
exemplo Exemplo de política de confiança

A seguinte relação de confiança é criada pelo modelo. O ID da conta do administrador é mostrado como admin_account_id.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:root" }, "Action": "sts:AssumeRole" } ] }

Você pode configurar a relação de confiança de uma função de execução da conta de destino existente para confiar em uma função específica na conta do administrador. Se você excluir a função na conta de administrador e criar uma nova para substituí-la, deve configurar suas relações de confiança da conta de destino com a função da nova conta de administrador, representada por admin_account_id no exemplo anterior.

Definir opções de permissões avançadas para operações de conjuntos de pilhas

Se precisar de um controle mais refinado sobre os conjuntos de pilhas que os usuários e os grupos criam por meio de uma única conta de administrador, use funções do IAM para especificar:

  • Quais usuários e grupos podem executar operações do conjunto de pilhas em quais contas de destino.

  • Quais recursos os usuários e grupos podem incluir em seus conjuntos de pilhas.

  • Quais operações do conjunto de pilhas os usuários e grupos específicos podem realizar.

Como controlar quais usuários podem executar operações de conjunto de pilhas em contas de destino específicas

Use os perfis de administração personalizados para controlar quais usuários e grupos podem executar operações de conjunto de pilhas em diferentes contas de destino. Você pode controlar quais usuários da conta de administrador podem executar as operações de conjunto de pilhas em que contas de destino. Para fazer isso, crie uma relação de confiança entre cada conta de destino e uma função de administração personalizada específica, em vez de criar a função de serviço AWSCloudFormationStackSetAdministrationRole na própria conta de administrador. Em seguida, ative usuários e grupos específicos para usar a função de administração personalizada apropriada ao executar operações de conjunto de pilhas em uma determinada conta de destino.

Por exemplo, você pode criar uma função A e uma função B na sua conta de administrador. Você pode conceder à função A permissões para acessar as contas de destino de 1 a 8. Você pode conceder à função B permissões para acessar as contas de destino de 9 a 16.

Configuração de uma relação de confiança entre um perfil de administração personalizado e as contas de destino. Em seguida, o usuário passará essa função ao criar o conjunto de pilhas.

A configuração das permissões necessárias envolve a definição de um perfil de administração personalizado, a criação de um perfil de serviço para a conta de destino e a concessão de permissão aos usuários para a transferência do perfil de administração personalizado ao executar as operações de conjunto de pilhas.

Em geral, uma vez que você já tenha as permissões necessárias, é desta forma que funciona: ao criar um conjunto de pilhas, o usuário deve especificar um perfil de administração personalizado. O usuário deve ter a permissão para transferir o perfil para o CloudFormation. Além disso, o perfil de administração personalizado deve ter uma relação de confiança com as contas de destino especificadas para o conjunto de pilhas. O CloudFormation cria o conjunto de pilhas e associa o perfil de administração personalizado a ele. Ao atualizar um conjunto de pilhas, o usuário deve especificar um perfil de administração personalizado de forma explícita, mesmo que seja o mesmo perfil de administração personalizado usado anteriormente com esse conjunto de pilhas. O CloudFormation usa esse perfil para atualizar a pilha, de acordo com os requisitos apresentados acima.

Administrator account
exemplo Exemplo de política de permissões

Para cada conjunto de pilhas, crie um perfil de administração personalizado com permissões para assumir o perfil de execução da conta de destino.

O nome do perfil de execução da conta de destino deve ser semelhante para todas as contas de destino. Se o nome do perfil for AWSCloudFormationStackSetExecutionRole, o StackSets o usará automaticamente ao criar um conjunto de pilhas. Se você especificar um nome de perfil personalizado, os usuários deverão fornecer o nome do perfil de execução ao criar um conjunto de pilhas.

Crie um perfil de serviço do IAM com um nome personalizado e a política de permissões apresentada a seguir. Nos exemplos abaixo, custom_execution_role refere-se ao perfil de execução nas contas de destino.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target_account_id:role/custom_execution_role" ], "Effect": "Allow" } ] }

Para especificar diversas contas em uma única instrução, separe-as usando vírgulas.

"Resource": [ "arn:aws:iam::target_account_id_1:role/custom_execution_role", "arn:aws:iam::target_account_id_2:role/custom_execution_role" ]

É possível especificar todas as contas de destino ao usar um caractere curinga (*) em vez de um ID da conta.

"Resource": [ "arn:aws:iam::*:role/custom_execution_role" ]
exemplo Exemplo de política de confiança 1

Você deve fornecer uma política de confiança para o perfil de serviço com a finalidade de definir quais entidades principais do IAM podem assumir o perfil.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
exemplo Exemplo de política de confiança 2

Para implantar instâncias de pilha em uma conta de destino que reside em uma região desabilitada por padrão, você também deverá incluir a entidade principal de serviço regional para essa região. Cada região desabilitada por padrão terá sua própria entidade principal de serviço regional.

O exemplo de política de confiança apresentado a seguir concede ao serviço a permissão para usar o perfil de administração na região Ásia-Pacífico (Hong Kong) (ap-east-1), uma região que está desabilitada por padrão.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "cloudformation.amazonaws.com", "cloudformation.ap-east-1.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

Para ter mais informações, consulte Execução de operações de conjunto de pilhas envolvendo regiões desabilitadas por padrão. Para obter uma lista de códigos de região, consulte Regional endpoints no Guia de referência geral da AWS.

exemplo Exemplo de política para transferência do perfil

Você também precisa de uma política de permissões do IAM para os usuários do IAM que permita que o usuário transfira o perfil de administração personalizado ao executar operações de conjunto de pilhas. Para obter mais informações, consulte Conceder a um usuário permissões para transmitir uma função a um produto da AWS.

No exemplo abaixo, customized_admin_role refere-se ao perfil de administração que o usuário precisa transferir.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/customized_admin_role" } ] }
Target accounts

Em cada conta de destino, crie um perfil de serviço que tenha uma relação de confiança com o perfil de administração personalizado que você deseja usar com essa conta.

O perfil da conta de destino requer permissões para executar quaisquer operações especificadas no modelo do CloudFormation. Por exemplo, se o seu modelo estiver criando um bucket do S3, você precisará de permissões para criar novos objetos no S3. A conta de destino sempre precisa da concessão de permissões totais por parte do CloudFormation, que incluem permissões para criar, atualizar, excluir e descrever pilhas.

O nome do perfil da conta de destino deve ser semelhante para todas as contas de destino. Se o nome do perfil for AWSCloudFormationStackSetExecutionRole, o StackSets o usará automaticamente ao criar um conjunto de pilhas. Se você especificar um nome de perfil personalizado, os usuários deverão fornecer o nome do perfil de execução ao criar um conjunto de pilhas.

exemplo Exemplo de política de permissões

O exemplo a seguir mostra uma declaração de política com as permissões mínimas para que o StackSets funcione. Para criar pilhas em contas de destino que usam recursos de serviços que são diferentes dos recursos usados pelo CloudFormation, é necessário adicionar essas ações e esses recursos de serviço à política de permissões.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
exemplo Exemplo de política de confiança

Você deve fornecer a política de confiança apresentada a seguir ao criar o perfil para definir a relação de confiança.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

Como controlar os recursos que os usuários podem incluir em conjuntos de pilhas específicos

Use funções de execução personalizadas para controlar quais recursos de pilha os usuários e grupos podem incluir em seus conjuntos de pilhas. Por exemplo, é possível configurar um grupo que só pode incluir recursos relacionados ao Amazon S3 nos conjuntos de pilhas criados, enquanto outra equipe só pode incluir recursos do DynamoDB. Para fazer isso, você cria uma relação de confiança entre o perfil de administração personalizado para cada grupo e um perfil de execução personalizado para cada conjunto de recursos. A função de execução personalizada define quais recursos de pilha podem ser inclusos no conjuntos de pilhas. O perfil de administração personalizado é estabelecido na conta do administrador, enquanto o perfil de execução personalizado é estabelecido em cada conta de destino na qual você deseja criar conjuntos de pilhas usando os recursos definidos. Em seguida, ative usuários e grupos específicos para usar a função de administração personalizada apropriada ao executar operações de conjunto de pilhas.

Por exemplo, é possível criar os perfis de administração personalizados A, B e C na conta do administrador. Usuários e grupos com permissão para usar Função A podem criar conjuntos de pilhas que contém os recursos de pilha especificamente listados na função de execução personalizada X, mas não aqueles nas funções Y ou Z, ou recursos não incluídos em qualquer função de execução.

Configuração de uma relação de confiança entre um perfil de administração personalizado e um perfil de execução personalizado nas contas de destino. Em seguida, o usuário envia essas funções ao criar o conjunto de pilhas.

Ao atualizar um conjunto de pilhas, o usuário deve especificar um perfil de administração personalizado de forma explícita, mesmo que seja o mesmo perfil de administração personalizado usado anteriormente com esse conjunto de pilhas. O CloudFormation executa a atualização usando o perfil de administração personalizado especificado, desde que o usuário tenha as permissões para executar operações nesse conjunto de pilhas.

Da mesma forma, o usuário também pode especificar uma função de execução personalizada. Se um perfil de execução personalizado for especificado, o CloudFormation usará esse perfil para atualizar a pilha, de acordo com os requisitos apresentados acima. Se o usuário não especificar um perfil de execução personalizado, o CloudFormation realizará a atualização usando o perfil de execução personalizado anteriormente associado ao conjunto de pilhas, desde que o usuário tenha as permissões para executar operações nesse conjunto de pilhas.

Administrator account

Crie um perfil de administração personalizado em sua conta de administrador, conforme detalhado em Como controlar quais usuários podem executar operações de conjunto de pilhas em contas de destino específicas. Inclua uma relação de confiança entre o perfil de administração personalizado e os perfis de execução personalizados que você deseja usar.

exemplo Exemplo de política de permissões

O exemplo apresentado a seguir corresponde a uma política de permissões para AWSCloudFormationStackSetExecutionRole definido para a conta de destino, além de um perfil de execução personalizado.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1487980684000", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole", "arn:aws:iam::*:role/custom_execution_role" ] } ] }
Target accounts

Nas contas de destino em que deseja criar os conjuntos de pilhas, crie uma função de execução personalizada que concede permissões aos serviços e recursos que deseja que os usuários e grupos possam incluir nos conjuntos de pilhas.

exemplo Exemplo de política de permissões

O exemplo a seguir fornece as permissões mínimas para conjuntos de pilhas, junto com a permissão para criar tabelas do Amazon DynamoDB.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamoDb:createTable" ], "Resource": "*" } ] }
exemplo Exemplo de política de confiança

Você deve fornecer a política de confiança apresentada a seguir ao criar o perfil para definir a relação de confiança.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

Definir permissões para operações específicas de conjuntos de pilhas

Além disso, você pode definir permissões para quais usuários e grupos podem executar operações específicas do conjunto de pilhas, como criação, atualização ou exclusão de conjuntos de pilhas ou instâncias de pilha. Para obter mais informações, consulte Actions, resources, and condition keys for CloudFormation no Guia do usuário do IAM.

Configurar chaves globais para atenuar problemas de confused deputy

O problema “confused deputy” é um problema de segurança em que uma entidade que não tem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Em AWS, a personificação entre serviços pode resultar no problema do "substituto confuso". A imitação entre serviços pode ocorrer quando um serviço (o serviço de chamada) chama outro serviço (o serviço chamado). O serviço de chamada pode ser manipulado de modo a usar suas permissões para atuar nos recursos de outro cliente de uma forma na qual ele não deveria ter permissão para acessar. Para evitar isso, o AWS fornece ferramentas que ajudam você a proteger seus dados para todos os serviços com entidades principais de serviço que receberam acesso aos recursos em sua conta.

Recomendamos usar chaves de contexto de condição global aws:SourceArn e aws:SourceAccount nas políticas de recursos para limitar as permissões que o AWS CloudFormation StackSets concede a outro serviço para o recurso. Se você utilizar ambas as chaves de contexto de condição global, o valor aws:SourceAccount e a conta aws:SourceArn no valor deverão utilizar o mesmo ID de conta quando utilizados na mesma instrução de política.

A maneira mais eficaz de se proteger do problema ‘confused deputy’ é usar a chave de contexto de condição global aws:SourceArn com o ARN completo do recurso. Se você não souber o ARN completo do recurso ou se estiver especificando vários recursos, use a chave de condição de contexto global aws:SourceArn com curingas (*) para as partes desconhecidas do ARN. Por exemplo, arn:aws:cloudformation::123456789012:*. Sempre que possível, use aws:SourceArn, pois ela é mais específica. Use aws:SourceAccount apenas quando não puder determinar o ARN ou padrão de ARN correto.

Quando o StackSets assume a função de Administração na sua conta de administrador, ele preenche o ID dessa conta de administrador e nome do recurso da Amazon (ARN) do StackSets. Portanto, é possível definir condições para chaves globais aws:SourceAccount e aws:SourceArn nas relações de confiança para evitar problemas de confused deputy. O exemplo a seguir mostra como é possível usar as chaves de contexto de condição globais aws:SourceArn e aws:SourceAccount em StackSets para evitar o problema “confused deputy”.

Administrator account
exemplo Chaves globais para aws:SourceAccount e aws:SourceArn

Ao usar o StackSets, defina as chaves globais aws:SourceAccount e aws:SourceArn na política de confiança AWSCloudFormationStackSetAdministrationRole para evitar problemas de confused deputy.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "StringLike": { "aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*" } } } ] }
exemplo ARNs de StackSets

Especifique seus ARNs de StackSets associados para um controle mais definido.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333", "aws:SourceArn": [ "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-1", "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-2", ] } } } ] }