AWS Security Blog

A Primer on RDS Resource-Level Permissions

Previously, we blogged about how to use resource-level permissions for Amazon EC2 to control access to specific EC2 instances.  Resource-level permissions can now also be applied to Amazon Relational Database Service (Amazon RDS).  This week’s guest blogger, Chris Checkwitch, Software Development Manager on the RDS team, will explain how to tackle the commonly requested use case of controlling access to specific RDS instances.

Prior to resource-level permissions, IAM policies only enabled you to control RDS at the API level, e.g., granting or denying permission to create, modify, and delete RDS instances under your AWS account. Now that RDS supports resource-level permissions, you can also specify which IAM users or groups can take actions on specific RDS resources, extending your security policies to also control access to particular RDS instances. In this blog post, we will demonstrate how to use this new feature and include sample IAM policies that you can adapt to your own needs. For an introduction to RDS resource-level permissions, see the announcement in the AWS Blog.

Step 1: Categorize your resources

Just like when creating resource-level permissions with EC2 instances, we’re going to start the IAM policy creation process for RDS by categorizing and tagging our RDS resources. Grouping resources into categories such as “all testing instances” or “all databases owned by Dave’s group” makes it easier to manage if you have a large number of resources. Once you’ve categorized your resources, you can apply simple descriptive tags like “stage=testing” or “owner=Dave” to your RDS resources.  RDS supports tagging many different resource types, including instances, option groups, parameter groups, security groups, snapshot groups, and subnet groups.  For more information on tagging RDS resources, please see the RDS documentation. Let’s start by taking a look at how to add a tag to a database instance.

For example, the following CLI command will add a tag “stage=production” to a database instance called “master”:

rds-add-tags-to-resource arn:aws:rds:us-east-1:123456789012:db:master --key stage --value production

Note: in the sample above the database resides in US-East using AWS account 123456789012.  Make sure you use your account and your preferred region when issuing this command.

Step 2: Define how users access resources

Because IAM access control policies are based on least privilege, users will not be able to manage your RDS resources unless you explicitly give them permission to do so. IAM policies allow or deny access to API actions and also include the resource(s) that the user has access to.  For example, the following example policy allows the deletion of database instances in the “us-east-1” region, as long as the instances are not tagged with “stage=production”:

{
   "Version" : "2012-10-17",
   "Statement" : [{
      "Effect" : "Allow",
      "Action" : "rds:DeleteDBInstance",
      "Resource" : "arn:aws:rds:us-east-1:123456789012:db:*",
 "Condition" : { "strneq " : { "rds:db-tag/stage" : "production" } }
  }
 ]
}

Note that this level of specification is accomplished by adding a condition to the policy that tests for String Not Equal (streq) on the “stage” tag.

We recommend that you add an additional layer of security for users who manage specific resources, by requiring the use of multi-factor authentication (MFA).  You can construct this policy as follows:

{
  "Version" : "2012-10-17",
  "Statement" : [{
     "Effect" : "Allow",
     "Action" : [ "rds:CreateDBInstance", "rds:DeleteDBInstance",        
     "rds:RebootDBInstance" ],
     "Resource" : "*",
     "Condition" : { "Null" : { "aws:MultiFactorAuthAge" : "false" } },
     "Condition" : { "strneq" : { "rds:db-tag/stage" : "production" } }
  }
 ]
}

Remember that this policy will only grant the ability to manage resources that have the tag you specified, in this case “stage=production”. RDS instances that have different tags will not be affected by this policy. If you want to place restrictions on these other RDS instances, you will need to create additional policies that references these RDS instances to manage them.

In some cases, you may choose to explicitly deny access to a set of resources. Deny policies provide an additional layer of protection because the DENY command will take precedence even if other policies ‘ALLOW’. To explicitly deny a user the ability to manage a resource, construct the policy as follows:

{
   "Version" : "2012-10-17",
   "Statement" : [{
      "Effect" : "Deny",
      "Action" : "rds:*",
      "Resource" : "arn:aws:rds:us-east-1:123456789012:db:prod-db-ha"
  }
 ]
}

Step 3: Lock down your tags

When you use tags as a basis for setting permissions on instances, you will want to restrict which users have permissions to apply and remove tags. For RDS, the actions to restrict are “AddTagsToResource” and “RemoveTagsFromResource”.  The following policy accomplishes this:

{
    "Version" : "2012-10-17",
    "Statement" : [{
       "Effect" : "Deny",
       "Action" : [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" 
       ],
       "Resource" : "*"
  }
 ]
}

In addition, a policy can also be written to limit the set of tag keys and values that may be used to tag an instance.  For example, the following policy allows the addition of a tag with the key “stage” to be added to a resource with the values “test”, “qa” and “production”:

{
    "Version" : "2012-10-17",
    "Statement" : [{
       "Effect" : "Allow",
       "Action" : [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" 
       ],
       "Resource" : "*",
       "Condition" : { "streq" : { "rds:req-tag/stage" : [ "test", "qa", 
       "production" ] } }
  }
 ]
}

Step 4: Attach your policies to IAM users

The last step in the process is to attach the policies you created above to any IAM principal, such as IAM users, groups, or roles. The policies will only apply to the principals they are attached to, but you should still perform periodic audits to ensure that the policies have been deployed appropriately (e.g. that they’ve been attached to the correct principals). To learn more about how to attach or manage policies on IAM principals, please see theinstructions in the IAM user guide.

Additional Information

Below are some additional resources that you may find helpful as you create policies to manage RDS:

– Jim