Menu
Amazon Relational Database Service
User Guide (API Version 2014-10-31)

Using IAM Policy Conditions for Fine-Grained Access Control

When you grant permissions in Amazon RDS, you can specify conditions that determine how a permissions policy takes effect.

Overview

In Amazon RDS, you have the option to specify conditions when granting permissions using an IAM policy (see Access Control). For example, you can:

  • Allow users to create a DB instance only if they specify a particular database engine.

  • Allow users to modify RDS resources that are tagged with a particular tag name and tag value.

There are two ways to specify conditions in an IAM policy for Amazon RDS:

Specifying Conditions: Using Condition Keys

AWS provides a set of predefined condition keys (AWS-wide condition keys) for all AWS services that support IAM for access control. For example, you can use the aws:userid condition key to require a specific AWS ID when requesting an action. For more information and a list of the AWS-wide condition keys, see Available Keys for Conditions in the IAM User Guide.

Note

Condition keys are case sensitive.

In addition Amazon RDS also provides its own condition keys that you can include in Condition elements in an IAM permissions policy. The following table shows the RDS condition keys that apply to RDS resources.

RDS Condition Key Description Value Type
rds:DatabaseClass A type of DB instance class.String
rds:DatabaseEngine A database engine, such as MySQL.String
rds:DatabaseName The user-defined name of the database on the DB instance.String
rds:MultiAz A value that specifies whether the DB instance runs in multiple Availability Zones. To indicate that the DB instance is using Multi-AZ, specify 1.Integer
rds:Piops A value that contains the number of Provisioned IOPS (PIOPS) that the instance supports. To indicate a DB instance that does not have PIOPS enabled, specify 0.Integer
rds:StorageSize The storage volume size (in GB).Integer
rds:Vpc A value that specifies whether the DB instance runs in an Amazon Virtual Private Cloud (Amazon VPC). To indicate that the DB instance runs in an Amazon VPC, specify 1.Boolean

For example, the following Condition element uses a condition key and specifies the MySQL database engine. You could apply this to an IAM policy that allows permission to the rds:CreateDBInstance action to enable users to only create DB instances with the MySQL database engine. For an example of an IAM policy that uses this condition, see Example Policies: Using Condition Keys.

"Condition":{"StringEquals":{"rds:DatabaseEngine": "mysql" } }

For a list of all of the RDS condition key identifiers and the RDS actions and resources that they apply to, see Amazon RDS API Permissions: Actions, Resources, and Conditions Reference.

Example Policies: Using Condition Keys

Following are examples of how you can use condition keys in Amazon RDS IAM permissions policies.

Example 1: Grant Permission to Create a DB Instance that Uses a Specific DB Engine

The following policy uses an RDS condition key and allows a user to create only DB instances that use the MySQL database engine. The Condition element indicates the requirement that the database engine is MySQL.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowMySQLCreate",
         "Effect":"Allow",
         "Action":"rds:CreateDBInstance",
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "rds:DatabaseEngine":"mysql"
            }
         }
      }
   ]
}

Example 2: Explicitly Deny Permission to Create DB Instances for Certain DB Instance Classes and Create DB Instances that Use Provisioned IOPS

The following policy explicitly denies permission to create DB instances that use the DB instance classes r3.8xlarge and m4.10xlarge, which are the largest and most expensive instances. This policy also prevents users from creating DB instances that use Provisioned IOPS, which incurs an additional cost.

Explicitly denying permission supersedes any other permissions granted. This ensures that identities to not accidentally get permission that you never want to grant.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"DenyLargeCreate",
         "Effect":"Deny",
         "Action":"rds:CreateDBInstance",
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "rds:DatabaseClass":[
                  "db.r3.8xlarge",
                  "db.m4.10xlarge"
               ]
            }
         }
      },
      {
         "Sid":"DenyPIOPSCreate",
         "Effect":"Deny",
         "Action":"rds:CreateDBInstance",
         "Resource":"*",
         "Condition":{
            "NumericNotEquals":{
               "rds:Piops":"0"
            }
         }
      }
   ]
}

Specifying Conditions: Using Custom Tags

RDS supports specifying conditions in an IAM policy using custom tags.

For example, if you add a tag named environment to your DB instances with values such as beta, staging, production, and so on, you can create a policy that restricts certain users to DB instances based on the environment tag value.

Note

Custom tag identifiers are case-sensitive.

The following table lists the RDS tag identifiers that you can use in a Condition element.

RDS Tag Identifier Applies To
db-tagDB instances, including Read Replicas
snapshot-tagDB snapshots
ri-tagReserved DB instances
secgrp-tagDB security groups
og-tagDB option groups
pg-tagDB parameter groups
subgrp-tagDB subnet groups
es-tagEvent subscriptions
cluster-tagDB clusters
cluster-pg-tagDB cluster parameter groups
cluster-snapshot-tagDB cluster snapshots

The syntax for a custom tag condition is as follows:

"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }

For example, the following Condition element applies to DB instances with a tag named environment and a tag value of production.

"Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} }

For information about creating tags, see Tagging Amazon RDS Resources.

Important

If you manage access to your RDS resources using tagging, we recommend that you secure access to the tags for your RDS resources. You can manage access to tags by creating policies for the AddTagsToResource and RemoveTagsFromResource actions. For example, the following policy denies users the ability to add or remove tags for all resources. You can then create policies to allow specific users to add or remove tags.

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

For a list of all of the condition key values, and the RDS actions and resources that they apply to, see Amazon RDS API Permissions: Actions, Resources, and Conditions Reference.

Example Policies: Using Custom Tags

Following are examples of how you can use custom tags in Amazon RDS IAM permissions policies. For more information about adding tags to an Amazon RDS resource, see Working with Amazon Resource Names (ARNs) in Amazon RDS.

Note

All examples use the us-west-2 region and contain fictitious account IDs.

Example 1: Grant Permission for Actions on a Resource with a Specific Tag with Two Different Values

The following policy allows permission to perform the ModifyDBInstance and CreateDBSnapshot APIs on instances with either the stage tag set to development or test.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowDevTestCreate",
         "Effect":"Allow",
         "Action":[
            "rds:ModifyDBInstance",
            "rds:CreateDBSnapshot"
         ],
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "rds:db-tag/stage":[
                  "development",
                  "test"
               ]
            }
         }
      }
   ]
}

Example 2: Explicitly Deny Permission to Create a DB Instance that Uses Specified DB Parameter Groups

The following policy explicitly denies permission to create a DB instance that uses DB parameter groups with specific tag values. You might apply this policy if you require that a specific customer-created DB parameter group always be used when creating DB instances. Note that policies that use Deny are most often used to restrict access that was granted by a broader policy.

Explicitly denying permission supersedes any other permissions granted. This ensures that identities to not accidentally get permission that you never want to grant.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"DenyProductionCreate",
         "Effect":"Deny",
         "Action":"rds:CreateDBInstance",
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "rds:pg-tag/usage":"prod"
            }
         }
      }
   ]
}

Example 3: Grant Permission for Actions on a DB Instance with an Instance Name that is Prefixed with a User Name

The following policy allows permission to call any API (except to AddTagsToResource or RemoveTagsFromResource) on a DB instance that has a DB instance name that is prefixed with the user's name and that has a tag called stage equal to devo or that has no tag called stage.

The Resource line in the policy identifies a resource by its Amazon Resource Name (ARN). For more information about using ARNs with Amazon RDS resources, see Working with Amazon Resource Names (ARNs) in Amazon RDS.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowFullDevAccessNoTags",
         "Effect":"Allow",
         "NotAction":[
            "rds:AddTagsToResource",
            "rds:RemoveTagsFromResource"
         ],
         "Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
         "Condition":{
            "StringEqualsIfExists":{
               "rds:db-tag/stage":"devo"
            }
         }
      }
   ]
}