2

As per the documentation here, there is a service linked role for dynamodb auto scaling - AWSServiceRoleForApplicationAutoScaling_DynamoDBTable. The role permissions policy allows Application Auto Scaling to complete the following actions on all resources:

Action: dynamodb:DescribeTable
Action: dynamodb:UpdateTable
Action: cloudwatch:DeleteAlarms
Action: cloudwatch:DescribeAlarms
Action: cloudwatch:PutMetricAlarm

which translates to (from here),

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
              "dynamodb:DescribeTable",
              "dynamodb:UpdateTable",
              "cloudwatch:DeleteAlarms",
              "cloudwatch:DescribeAlarms",
              "cloudwatch:PutMetricAlarm"
            ],
            "Resource": "*"
        }
    ]
}

So for example, when the policy is used like below,

  TableLiveProductsReadScalableTarget:
    Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
    Properties:
      MaxCapacity: !Ref TableLiveProductsReadMaxCap
      MinCapacity: !Ref TableLiveProductsReadMinCap
      ResourceId: !Sub "table/${TableLiveProducts}"
      RoleARN: !Sub  arn:aws:iam::${AWS::AccountId}:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable
      ScalableDimension: 'dynamodb:table:ReadCapacityUnits'
      ServiceNamespace: dynamodb

from a security perspective is it okay to assume that, since the role can only be assumed by dynamodb.application-autoscaling.amazonaws.com no problem giving permission to update ALL the tables, delete ALL the alarms etc.?

What is the rationale behind asking for such a wildcard permission here (as well as in many AWS built service linked roles)?

Jimson James
  • 2,937
  • 6
  • 43
  • 78

1 Answers1

1

They are meant to be most generic for your account. So one role covers every table for you. Since principle is dynamodb.application-autoscaling.amazonaws.com no other service nor IAM user/role can use these permissions.

You can provide your own role instead, with more granual setup. So to limit permissions to only one table you can do:

  MyDynamoDBRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'               
        Statement:
          - Effect: Allow
            Principal: {'Service': ['dynamodb.application-autoscaling.amazonaws.com']}
            Action: ['sts:AssumeRole']  
      Path: '/'  
      Policies:
        - PolicyName: DynamoDBScaling
          PolicyDocument: !Sub |
            {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Allow",
                        "Action": [
                            "dynamodb:DescribeTable",
                            "dynamodb:UpdateTable"
                        ],
                        "Resource": "${TableLiveProducts.Arn}"
                    },
                    {
                        "Effect": "Allow",
                        "Action": [
                            "cloudwatch:PutMetricAlarm",
                            "cloudwatch:DescribeAlarms",
                            "cloudwatch:DeleteAlarms"
                        ],
                        "Resource": "*"
                    }
                ]
            }        


  TableLiveProductsReadScalableTarget:
    Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
    Properties:
      MaxCapacity: !Ref TableLiveProductsReadMaxCap
      MinCapacity: !Ref TableLiveProductsReadMinCap
      ResourceId: !Sub "table/${TableLiveProducts}"
      RoleARN: !GetAtt MyDynamoDBRole.Arn
      ScalableDimension: 'dynamodb:table:ReadCapacityUnits'
      ServiceNamespace: dynamodb

Marcin
  • 215,873
  • 14
  • 235
  • 294