Política do IAM para separar ambientes do DynamoDB na mesma conta da AWS
Suponha que você tenha ambientes separados, onde cada ambiente mantém sua própria versão de uma tabela chamada ProductCatalog
. Se você criar duas tabelas ProductCatalog
na mesma conta da AWS, o trabalho realizado em um ambiente poderá afetar o outro ambiente devido à forma como as permissões são configuradas. Por exemplo, as cotas no número de operações simultâneas de ambiente de gerenciamento (como CreateTable
) são definidas por cada conta da AWS.
Como resultado, cada ação em um ambiente reduz o número de operações disponíveis no outro ambiente. Há também um risco do código em seu ambiente de teste poder acessar acidentalmente tabelas no ambiente de produção.
nota
Se preferir separar as workloads de produção e teste para ajudar a controlar o "raio de explosão" de um evento, a prática recomendada é criar contas da AWS separadas para workloads de teste e produção. Para obter mais informações, consulte Gerenciamento e separação de contas da AWS.
Suponha também que você tenha dois desenvolvedores, Amit e Alice, que estão testando a tabela ProductCatalog
. Em vez de cada desenvolvedor ter uma conta da AWS os desenvolvedores podem compartilhar a mesma conta de teste da AWS. Nesta conta de teste, você pode criar uma cópia da mesma tabela para cada desenvolvedor trabalhar, como Alice_ProductCatalog
e Amit_ProductCatalog
. Nesse caso, é possível criar os usuários Alice e Amit na conta da AWS que você criou para o ambiente de teste. Em seguida, você pode conceder permissões para esses usuários executarem ações do DynamoDB nas tabelas que eles possuem.
Para conceder essas permissões de usuário do IAM, você pode executar uma das seguintes ações:
-
Crie uma política separada para cada usuário e, em seguida, anexe cada política ao seu usuário separadamente. Por exemplo, você pode anexar a política a seguir ao usuário Alice para permitir que ela acesse todas as ações do DynamoDB na tabela
Alice_ProductCatalog
:{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllAPIActionsOnAliceTable", "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:DescribeContributorInsights", "dynamodb:RestoreTableToPointInTime", "dynamodb:ListTagsOfResource", "dynamodb:CreateTableReplica", "dynamodb:UpdateContributorInsights", "dynamodb:CreateBackup", "dynamodb:DeleteTable", "dynamodb:UpdateTableReplicaAutoScaling", "dynamodb:UpdateContinuousBackups", "dynamodb:TagResource", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:DescribeContinuousBackups", "dynamodb:BatchGetItem", "dynamodb:UpdateTimeToLive", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem", "dynamodb:UntagResource", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem", "dynamodb:DeleteTableReplica", "dynamodb:DescribeTimeToLive", "dynamodb:RestoreTableFromBackup", "dynamodb:UpdateTable", "dynamodb:DescribeTableReplicaAutoScaling", "dynamodb:GetShardIterator", "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:DescribeLimits", "dynamodb:ListStreams" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Alice_ProductCatalog/*" } ] }
Em seguida, você pode criar uma política semelhante com um recurso diferente (a tabela
Amit_ProductCatalog
) para o usuário Amit. -
Em vez de anexar políticas a usuários individuais, você pode usar variáveis de política do IAM para gravar uma única política e anexá-la a um grupo. Você precisa criar um grupo e, no caso deste exemplo, adicionar ambos os usuários Alice e Amit ao grupo. O exemplo a seguir concede permissões para executar todas as ações do DynamoDB na tabela
${aws:username}_ProductCatalog
. A variável de política${aws:username}
é substituída pelo nome de usuário do solicitante quando a política é avaliada. Por exemplo, se Alice envia uma solicitação para adicionar um item, a ação é permitida apenas se Alice estiver adicionando itens à tabelaAlice_ProductCatalog
.{ "Version": "2012-10-17", "Statement": [ { "Sid": "ActionsOnUserSpecificTable", "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_ProductCatalog" }, { "Sid": "AdditionalPrivileges", "Effect": "Allow", "Action": [ "dynamodb:ListTables", "dynamodb:DescribeTable", "dynamodb:DescribeContributorInsights" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/*" } ] }
nota
Ao usar variáveis de política do IAM, você deve especificar explicitamente a versão 2012-10-17
da linguagem da política do IAM na política. A versão padrão da linguagem da política do IAM (2008-10-17
) não é compatível com as variáveis da política.
Em vez de identificar uma tabela específica como um recurso, conforme normalmente faria, você pode usar um caractere curinga (*) para conceder permissões em todas as tabelas em que o nome da tabela tem como prefixo o usuário que está fazendo a solicitação, conforme mostrado a seguir.
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_*"