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. Esses perfis são necessários para estabelecer um relacionamento confiável entre a conta em que você está administrando o StackSet e a conta em que 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.
Visão geral das permissões autogerenciadas
Antes de criar um StackSet com permissões autogerenciadas, é necessário ter criado perfis de serviço do IAM em cada conta.
As etapas básicas são:
-
Determine qual Conta da AWS é a conta do administrador.
Os StackSets serão criados nessa conta de administrador. Uma conta de destino é a conta em que você cria as pilhas individuais que pertencem a um StackSet.
-
Determine como você deseja estruturar as permissões para o StackSet.
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 StackSets gerenciados por meio da conta. Se precisar de um controle mais refinado, defina permissões para especificar:
-
Quais usuários e grupos podem executar operações do StackSet em quais contas de destino.
-
Quais recursos os usuários e grupos podem incluir em seus StackSets.
-
Quais operações do StackSet os usuários e grupos específicos podem executar.
-
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 do StackSet 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 permissões dessa maneira, os usuários não passam um perfil de administração ao criar ou atualizar um StackSet.
- 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 obter mais informações, consulte Preparar-se para realizar de operações de StackSets em Regiões da AWS desabilitadas por padrão. Para obter uma lista de códigos de região, consulte Regional endpoints no Referência geral da AWS Guide.
- 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.
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 StackSets
Se precisar de um controle mais refinado sobre os StackSets que os usuários e os grupos criam por meio de uma única conta de administrador, use perfis do IAM para especificar:
-
Quais usuários e grupos podem executar operações do StackSet em quais contas de destino.
-
Quais recursos os usuários e grupos podem incluir em seus StackSets.
-
Quais operações do StackSet os usuários e grupos específicos podem executar.
Controlar quais usuários podem executar operações de StackSets 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 StackSets em diferentes contas de destino. Você pode querer controlar quais usuários da conta de administrador podem executar as operações de StackSets em quais 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. Você então ativa usuários e grupos específicos para usar o perfil de administração personalizado ao executar operações de StackSets 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.
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 passar o perfil de administração personalizado ao executar as operações de StackSets.
Em geral, uma vez que você já tenha as permissões necessárias, é desta forma que funciona: ao criar um StackSet, 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 StackSet. O CloudFormation cria o StackSet e associa o perfil de administração personalizado a ele. Ao atualizar um StackSet, 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 StackSet. 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 StackSet, 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 StackSet. Se você especificar um nome de perfil personalizado, os usuários deverão fornecer o nome do perfil de execução ao criar um StackSet.
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 obter mais informações, consulte Preparar-se para realizar de operações de StackSets em Regiões da AWS 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 passe o perfil de administração personalizado ao executar operações de StackSets. 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 StackSet. Se você especificar um nome de perfil personalizado, os usuários deverão fornecer o nome do perfil de execução ao criar um StackSet.
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"
}
]
}
Controlar os recursos que os usuários podem incluir em StackSets específicos
Use perfis de execução personalizados para controlar quais recursos de pilha os usuários e grupos podem incluir em seus StackSets. Por exemplo, você pode querer configurar um grupo que só pode incluir recursos relacionados ao Amazon S3 nos StackSets 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. O perfil de execução personalizado define quais recursos de pilha podem ser inclusos nos StackSets. O perfil de administração personalizado reside na conta do administrador, enquanto o perfil de execução personalizado reside em cada conta de destino em que você deseja criar StackSets usando os recursos definidos. Você então ativa usuários e grupos específicos para usar o perfil de administração personalizado ao executar operações de StackSets.
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 o Perfil A podem criar StackSets que contêm os recursos de pilha especificamente listados no perfil de execução personalizado X, mas não aqueles nos perfis Y ou Z, ou os recursos não incluídos em qualquer perfil de execução.
Ao atualizar um StackSet, 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 StackSet. 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 StackSet.
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 StackSet, desde que o usuário tenha as permissões para executar operações nesse StackSet.
- Administrator account
-
Crie um perfil de administração personalizado em sua conta de administrador, conforme detalhado em Controlar quais usuários podem executar operações de StackSets 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 seus StackSets, crie um perfil de execução personalizado que conceda permissões aos serviços e recursos que você deseja que os usuários e grupos possam incluir nos StackSets.
exemplo Exemplo de política de permissões
O exemplo a seguir fornece as permissões mínimas para StackSets, 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 StackSets
Além disso, você pode definir permissões para quais usuários e grupos podem executar operações específicas do StackSet, como criação, atualização ou exclusão de StackSets ou instâncias de pilha. Para obter mais informações, consulte Actions, resources, and condition keys for CloudFormation na Service Authorization Reference.
Configurar chaves globais para atenuar problemas de confused deputy
“Confused deputy” é um problema de segurança no qual uma entidade sem permissão para executar uma ação pode coagir uma entidade mais privilegiada a executá-la. Na AWS, a personificação entre serviços pode resultar no problema do ‘confused deputy’. A personificaçã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, a 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 especificar 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",
]
}
}
}
]
}
