Política de IAM para separar los entornos de DynamoDB en la misma cuenta AWS - Amazon DynamoDB

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Política de IAM para separar los entornos de DynamoDB en la misma cuenta AWS

Supongamos que tiene entornos independientes, de tal forma que cada uno de ellos mantiene su propia versión de una tabla denominada ProductCatalog. Si crea dos ProductCatalog tablas en la misma AWS cuenta, el trabajo en un entorno podría afectar al otro debido a la forma en que están configurados los permisos. Por ejemplo, las cuotas del número de operaciones simultáneas del plano de control (por ejemploCreateTable) se establecen a nivel de AWS cuenta.

Por este motivo, cada acción que se realiza en un entorno reduce el número de operaciones disponibles en el otro entorno. Además, existe el riesgo de que el código en un entorno obtenga por error acceso a las talas del otro entorno.

nota

Si desea separar las cargas de trabajo de producción y de prueba para ayudar a controlar el potencial “radio de explosión” de un evento, la práctica recomendada es crear cuentas de AWS para las cargas de trabajo de pruebas y producción. Para obtener más información, consulteAdministración y separación de cuentas de AWS.

Supongamos, además, que tiene dos desarrolladores, Amit y Alice, que están realizando las pruebas de la tabla ProductCatalog. En lugar de que cada desarrollador necesite una AWS cuenta independiente, tus desarrolladores pueden compartir la misma AWS cuenta de prueba. En esta cuenta, puede crear una copia de la misma tabla para cada desarrollador; por ejemplo, Alice_ProductCatalog y Amit_ProductCatalog. En este caso, puede crear los usuarios Alice y Amit en la AWS cuenta que creó para el entorno de prueba. A continuación, puede conceder permisos a estos usuarios para que lleven a cabo acciones de DynamoDB en las tablas de su propiedad.

Para conceder permisos a estos usuarios IAM, puede realizar uno de los siguientes procedimientos:

  • Cree una política independiente para cada usuario y, a continuación, adjunte cada política a su usuario por separado. Por ejemplo, puede adjuntar la siguiente política al usuario Alice para permitirle acceso a todas las acciones de DynamoDB en la tabla 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/*" } ] }

    Después, puede crear una política distinta con un recurso diferente (la tabla Amit_ProductCatalog) para el usuario Amit.

  • En vez de adjuntar políticas a cada usuario, puede usar variables de políticas de IAM para escribir una sola política y adjuntársela a un grupo. Debe crear un grupo y, en el caso de este ejemplo, agregar a ese grupo a los dos usuarios, Alice y Amit. A continuación, se muestra un ejemplo en el que se conceden permisos para llevar a cabo todas las acciones de DynamoDB en la tabla ${aws:username}_ProductCatalog. Al evaluar la política, la variable ${aws:username} se reemplaza por el nombre de usuario del solicitante. Por ejemplo, si Alice envía una solicitud para que se agregue un elemento, la acción solamente se permite si Alice está agregando elementos a la tabla Alice_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

Cuando se usan variables de una política de IAM, es preciso especificar explícitamente la versión 2012-10-17 del lenguaje de la política de IAM en la política. La versión predeterminada del lenguaje de la política de IAM (2008-10-17) no admite variables de políticas.

En lugar de identificar una tabla específica como un recurso, puede utilizar un carácter comodín (*) para conceder permisos en todas las tablas cuyo nombre lleve antepuesto el nombre del usuario que realiza la solicitud, tal y como se muestra a continuación.

"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_*"