Permissions validation for Application Auto Scaling API calls on target resources
Making authorized requests to Application Auto Scaling API actions requires that the API caller has permissions to access AWS resources in the target service and in CloudWatch. Application Auto Scaling validates permissions for requests associated with both the target service and CloudWatch before proceeding with the request. To accomplish this, we issue a series of calls to validate the IAM permissions on target resources. When a response is returned, it is read by Application Auto Scaling. If the IAM permissions do not allow a given action, Application Auto Scaling fails the request and returns an error to the user containing information about the missing permission. This ensures that the scaling configuration that the user wants to deploy functions as intended, and that a useful error is returned if the request fails.
As an example of how this works, the following information provides details about how Application Auto Scaling performs permissions validations with Aurora and CloudWatch.
When a user calls the RegisterScalableTarget
API against an Aurora DB cluster,
Application Auto Scaling performs all of the following checks to verify that the user has the required
permissions (in bold).
-
rds:CreateDBInstance: To determine whether the user has this permission, we send a request to the
CreateDBInstance
API operation, attempting to create a DB instance with invalid parameters (empty instance ID) in the Aurora DB cluster that the user specified. For an authorized user, the API returns anInvalidParameterValue
error code response after it audits the request. However, for an unauthorized user, we get anAccessDenied
error and fail the Application Auto Scaling request with aValidationException
error to the user that lists the missing permissions. -
rds:DeleteDBInstance: We send an empty instance ID to the
DeleteDBInstance
API operation. For an authorized user, this request results in anInvalidParameterValue
error. For an unauthorized user, it results inAccessDenied
and sends a validation exception to the user (same treatment as described in the first bullet point). -
rds:AddTagsToResource: Because the
AddTagsToResource
API operation requires an Amazon Resource Name (ARN), it is necessary to specify a "dummy" resource using an invalid account ID (12345) and dummy instance ID (non-existing-db) to construct the ARN (arn:aws:rds:us-east-1:12345:db:non-existing-db
). For an authorized user, this request results in anInvalidParameterValue
error. For an unauthorized user, it results inAccessDenied
and sends a validation exception to the user. -
rds:DescribeDBClusters: We describe the cluster name for the resource being registered for auto scaling. For an authorized user, we get a valid describe result. For an unauthorized user, it results in
AccessDenied
and sends a validation exception to the user. -
rds:DescribeDBInstances: We call the
DescribeDBInstances
API with adb-cluster-id
filter that filters on the cluster name that was provided by the user to register the scalable target. For an authorized user, we are permitted to describe all of the DB instances in the DB cluster. For an unauthorized user, this call results inAccessDenied
and sends a validation exception to the user. -
cloudwatch:PutMetricAlarm: We call the
PutMetricAlarm
API without any parameters. Because alarm name is missing, the request results inValidationError
for an authorized user. For an unauthorized user, it results inAccessDenied
and sends a validation exception to the user. -
cloudwatch:DescribeAlarms: We call the
DescribeAlarms
API with the maximum number of records value set to 1. For an authorized user, we expect information on one alarm in the response. For an unauthorized user, this call results inAccessDenied
and sends a validation exception to the user. -
cloudwatch:DeleteAlarms: Similar to
PutMetricAlarm
above, we provide no parameters toDeleteAlarms
request. Because an alarm name is missing from the request, this call fails withValidationError
for an authorized user. For an unauthorized user, it results inAccessDenied
and sends a validation exception to the user.
Whenever any one of these validation exceptions occur, it is logged. You can take steps to manually identify which calls failed validation by using AWS CloudTrail. For more information, see the AWS CloudTrail User Guide.
Note
If you receive alerts for Application Auto Scaling events using CloudTrail, these alerts will include the
Application Auto Scaling calls to validate user permissions by default. To filter out these alerts, use the
invokedBy
field, which will contain
application-autoscaling.amazonaws.com
for these validation checks.