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)?