Attaching an AWS Config policy to an IAM group or to a user helps us to grant custom permission for AWS config users.

As a part of our Server Management Services, we help our Customers to AWS related errors regularly.

Let us today discuss the steps to grant custom permissions for AWS config users.

How to grant custom permission for AWS config users?

AWS Config policies grant permissions to users who work with AWS Config. We need to attach an AWS Config policy to an IAM group or to a user to grant different permissions to users.

Further, we can edit the policy to include or exclude specific permissions. We can also create our own custom policies.

Read-only access

The following example shows a AWS managed policy, AWSConfigUserAccess that grants read-only access to AWS Config.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"config:Get*",
"config:Describe*",
"config:Deliver*",
"config:List*",
"tag:GetResources",
"tag:GetTagKeys",
"cloudtrail:DescribeTrails",
"cloudtrail:GetTrailStatus",
"cloudtrail:LookupEvents"
],
"Resource": "*"
}
]
}

In the policy statements, the Effect element specifies whether the actions are allowed or denied. The Action element lists the specific actions that the user is allowed to perform.

The Resource element lists the AWS resources the user is allowed to perform those actions on.

For policies that control access to AWS Config actions, the Resource element is always set to *, a wildcard that means “all resources.”The values in the Action element correspond to the APIs that the services support.

The actions are preceded by config: to indicate that they refer to AWS Config actions. We can use the * wildcard character in the Action element, such as in the following examples:

• “Action”: [“config:*ConfigurationRecorder”]
  This allows all AWS Config actions that end with “ConfigurationRecorder” (StartConfigurationRecorder, StopConfigurationRecorder).
• “Action”: [“config:*”]
  This allows all AWS Config actions, but not actions for other AWS services.
• “Action”: [“*”]
  This allows all AWS actions. This permission is suitable for a user who acts as an AWS administrator for your account.

The read-only policy does not grant user permission for the actions such as StartConfigurationRecorder, StopConfigurationRecorder, and DeleteConfigurationRecorder.

Users with this policy cannot start configuration recorder, stop configuration recorder, or delete configuration recorder.

Full access

The following example shows a policy that grants full access to AWS Config. It grants users the permission to perform all AWS Config actions.

It also lets users manage files in Amazon S3 buckets and manage Amazon SNS topics in the account associated with the user.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sns:AddPermission",
"sns:CreateTopic",
"sns:DeleteTopic",
"sns:GetTopicAttributes",
"sns:ListPlatformApplications",
"sns:ListTopics",
"sns:SetTopicAttributes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetBucketNotification",
"s3:GetBucketPolicy",
"s3:GetBucketRequestPayment",
"s3:GetBucketVersioning",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:ListBucketVersions",
"s3:PutBucketPolicy"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:AttachRolePolicy",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion",
"iam:CreateServiceLinkedRole"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudtrail:DescribeTrails",
"cloudtrail:GetTrailStatus",
"cloudtrail:LookupEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"config:*",
"tag:Get*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeDocument",
"ssm:GetDocument",
"ssm:DescribeAutomationExecutions",
"ssm:GetAutomationExecution",
"ssm:ListDocuments",
"ssm:StartAutomationExecution"
],
"Resource": "*"
}

]
}

This policy grants broad permissions. Before granting full access, consider starting with a minimum set of permissions and granting additional permissions as necessary.

Doing so is better practice than starting with permissions that are too lenient and then trying to tighten them later.

Controlling user permissions for actions on multi-account multi-region data aggregation

We can use resource-level permissions to control a user’s ability to perform specific actions on multi-account multi-region data aggregation.

AWS Config multi-account multi-region data aggregation APIs support resource level permissions. With resource level permission can restrict to access/modify the resource data to specific users.

For example, if we want to restrict access to resource data to specific users. We can create two aggregators AccessibleAggregator and InAccessibleAggregator. Then attach an IAM policy that allows access to the AccessibleAggregator.

For the first policy, we allow the aggregator actions such as DescribeConfigurationAggregators and DeleteConfigurationAggregator actions for the config ARN that we specify.

In the following example, the config ARN is arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-mocpsqhs.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConfigReadOnly",
"Effect": "Allow",
"Action": [
"config:PutConfigurationAggregator",
"config:DescribePendingAggregationRequests",
"config:DeletePendingAggregationRequest",
"config:GetAggregateConfigRuleComplianceSummary",
"config:DescribeAggregateComplianceByConfigRules",
"config:GetAggregateComplianceDetailsByConfigRule",
"config:DescribeConfigurationAggregators",
"config:DescribeConfigurationAggregatorSourcesStatus",
"config:DeleteConfigurationAggregator"
],
"Resource": "arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-mocpsqhs"
}
]
}

For the second policy, we deny the aggregator actions for the config ARN that you specify. In the following example, the config ARN is arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-pokxzldx.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConfigReadOnly",
"Effect": "Deny",
"Action": [
"config:PutConfigurationAggregator",
"config:DescribePendingAggregationRequests",
"config:DeletePendingAggregationRequest",
"config:GetAggregateConfigRuleComplianceSummary",
"config:DescribeAggregateComplianceByConfigRules",
"config:GetAggregateComplianceDetailsByConfigRule",
"config:DescribeConfigurationAggregators",
"config:DescribeConfigurationAggregatorSourcesStatus",
"config:DeleteConfigurationAggregator"
],
"Resource": "arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-pokxzldx"
}
]
}

If a user of the developer group tries to describe or delete configuration aggregators on the config that you specified in the second policy, that user gets an access denied exception.

The following AWS CLI examples show that the user creates two aggregators, AccessibleAggregator and InAccessibleAggregator.

aws configservice describe-configuration-aggregators

The command complete successfully:

{
"ConfigurationAggregators": [
{
"ConfigurationAggregatorArn": "arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-mocpsqhs",
"CreationTime": 1517942461.442,
"ConfigurationAggregatorName": "AccessibleAggregator",
"AccountAggregationSources": [
{
"AllAwsRegions": true,
"AccountIds": [
"AccountID1",
"AccountID2",
"AccountID3"
]
}
],
"LastUpdatedTime": 1517942461.455
}
]
}

{
"ConfigurationAggregators": [
{
"ConfigurationAggregatorArn": "arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-pokxzldx",
"CreationTime": 1517942461.442,
"ConfigurationAggregatorName": "InAccessibleAggregator",
"AccountAggregationSources": [
{
"AllAwsRegions": true,
"AccountIds": [
"AccountID1",
"AccountID2",
"AccountID3"
]
}
],
"LastUpdatedTime": 1517942461.455
}
]
}

The user then creates an IAM policy that denies access to InAccessibleAggregator.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConfigReadOnly",
"Effect": "Deny",
"Action": [
"config:PutConfigurationAggregator",
"config:DescribePendingAggregationRequests",
"config:DeletePendingAggregationRequest",
"config:GetAggregateConfigRuleComplianceSummary",
"config:DescribeAggregateComplianceByConfigRules",
"config:GetAggregateComplianceDetailsByConfigRule",
"config:DescribeConfigurationAggregators",
"config:DescribeConfigurationAggregatorSourcesStatus",
"config:DeleteConfigurationAggregator"
],
"Resource": "arn:aws:config:ap-northeast-1:AccountID:config-aggregator/config-aggregator-pokxzldx"
}
]
}

Next, the user confirms that IAM policy works for restricting access to specific aggregator and rules.

aws configservice get-aggregate-compliance-details-by-config-rule --configuration-aggregator-name InAccessibleAggregator --config-rule-name rule name --account-id AccountID --aws-region AwsRegion

The command returns an access denied exception:

An error occurred (AccessDeniedException) when calling the GetAggregateComplianceDetailsByConfigRule operation: User: arn:aws:iam::AccountID:user/ is not
authorized to perform: config:GetAggregateComplianceDetailsByConfigRule on resource: arn:aws:config:AwsRegion-1:AccountID:config-aggregator/config-aggregator-pokxzldx

With resource-level permissions, we can grant or deny access to perform specific actions on multi-account multi-region data aggregation.

[Need any further assistance with AWS related errors? – We’re available 24*7]

Conclusion

In short, attaching a AWS Config policy to an IAM group or to a user helps us to grant custom permission for AWS config users. Today, we saw how our Support Engineers perform this.