As I see growing use of Cloud infrastructure for multiple deployments this way it becomes more difficult to administer access to AWS resources, I have also come across requirements where customers need a more refined access control over AWS resources.
For instance consider a customer would like to restrict to number of RDS instance a user can access of make changes however with AWS this can be done but in a twisted manner.
Lets take a usecase to understand this much better.. Let say a customer like Netflix, I know they have moved out of AWS but still.. want to restrict access RDS instances so that their testing team are able to access 2 RDS instance and not other RDS instance just to make sure they by mistake change any parameter from parameter group. So in this case what would you do to restrict access?
Unfortunately AWS does give us a feature through which we can hide the other RDS instances, then the only way is to create a boring IAM policy, but still IAM is not the only thing which will help us do this efficiently.. Reason: AWS gives you policy as per resources not as per number of resource.
In this case what I will suggest is to use a very simple feature of AWS which is “tags”. Yes! tags.. I know everyone including me found tags as boring thing to configure. right?
We will use Tags and AWS Policy together to get the test team access on those those 2 RDS instances.
Step 1. Create an IAM user (as per usecase above we will use test team users).
Step 2. Attaching an IAM policy to this user. By default, all IAM users start with no permission unless you specify explicitly. Here is one example:
In this policy, I define this IAM user is able to list all RDS resources (DefaultActionBlock) and can only delete, reboot and modify the DB instances which are with tag Department = “database-services” string. (ActionOnInstance). You will need to consult AWS Policy Generator Actions part for explicit Actions you need, e.g. DeleteDBSnapshot, DescribeAccountAttributes, .etc.
Your policy should look something like this :
------------------------------
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DefaultActionBlock",
"Action": [
"rds:Describe*",
"rds:List*"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "ActionOnInstance",
"Action": [
"rds:DeleteDBInstance",
"rds:RebootDBInstance",
"rds:ModifyDBInstance"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"rds:db-tag/Department": "database-services"
}
}
}
]
}
Apologies for a bad formatted code, please visit my github for a better view https://github.com/bhargavamin/iam-policy-aws.git
Note:
1. There are different permission levels, like Action-level permissions, Resource-level permissions,.etc. If an API does not support this level permissions then that statement in the policy must use * in the Resource element.
2. IAM starts with no permission, unless you defined explicitly, this IAM user will not be able to see other resources, like EC2.
3. Tagging Amazon RDS Resources: You will need to tag your RDS resources, so they can be used with IAM policies. For what Amazon RDS resources can be tagged.
4. For any users work with the Amazon RDS console, that user must have a minimum set of permissions which is AmazonRDSReadOnlyAccess managed policy. So far it’s a limitation to hide those DB instances from RDS console even if they are tagged with different labels. There is a public AWS document talking about this minimum permissions for RDS console
There are plenty of Example Policies for Administering AWS Resources you find them here .
Hope this helps!
-Bhargav
References :
[1] https://awspolicygen.s3.amazonaws.com/policygen.html
[3] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-iam-actions-resources.html
[4] http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Tagging.html
Social Profiles