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

Authentication and Access Control for Amazon RDS

Access to Amazon RDS requires credentials that AWS can use to authenticate your requests. Those credentials must have permissions to access AWS resources. This section provides details on how you can use AWS Identity and Access Management (IAM) and Amazon RDS to help secure your resources by controlling who can access them.

Authentication

When you sign up for AWS, you provide an email address and password that are associated with your AWS account. These are your root credentials and they provide complete access to all of your AWS resources.

When you create your AWS account, for security reasons we recommend that you use these root credentials for the first time only to create an administrator user with full permissions to your AWS account. For instructions, see Creating an Administrators Group in the IAM User Guide. You can then use this administrator user to create other IAM users and roles with limited permissions.

An IAM user is simply an identity within your AWS account that you create in the IAM service that has specific custom permissions (for example, to upload objects to an Amazon S3 bucket, read items from a specific DynamoDB table, or create an Amazon RDS database instance). You can use an IAM user name and password to sign in to secure AWS webpages like the AWS Management Console, AWS Discussion Forums, and the AWS Support Center.

You can also generate access keys for each user that can be used to authenticate requests when accessing AWS services programmatically either through one of the several SDKs or by using the AWS Command Line Interface (CLI). Using the access keys you provide, the SDK and CLI tools cryptographically sign your request. If you don’t use the AWS tools, you must sign the request yourself. Amazon RDS supports Signature Version 4, a protocol for authenticating inbound API requests. For more information about authenticating requests, see Signature Version 4 Signing Process in the Amazon Web Services General Reference.

Instead of creating an IAM user, you can also use pre-existing user identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are referred to as federated users. Federated users access AWS services and resources through an IAM role, which is similar to an IAM user, but is not associated with a specific person. Instead, a role is assigned to a federated user dynamically when the user requests access through an identity provider. Note that IAM roles can also be used for other purposes, such as granting other AWS accounts permissions to access your account’s resources. A federated user is associated with an IAM role that enables the user to obtain temporary access keys, which the user uses to authenticate requests. For more information about federated users, see Federated Users and Roles in the IAM User Guide.

Access Control

Amazon RDS supports identity-based permissions policies, where you attach a permissions policy to an IAM identity (that is, a user, a group, or an IAM role). For more information about permissions policies, see Overview of AWS IAM Permissions in the IAM User Guide.

Note

Other services, such as Amazon S3, also support resource-based permissions policies. For example, you can attach a policy to an S3 bucket to manage access permissions to that bucket. Amazon RDS does not support resource-based policies.

Users and roles can get valid credentials, but they don’t have any permissions by default. You need to grant permissions by creating permissions policies and attaching them to a user, a group, or an IAM role. A policy determines which AWS API actions a user can perform on which AWS resources.

You can create a permissions policy to grant resource access permissions to users in your account or cross-account permissions. For example, the administrator in Account A can create a role that has permissions to access Account A’s resources, and specify Account B as a principal in the role’s trust policy. Then, the administrator in Account B can delegate the permissions to assume the role to any of the users in Account B. What the Account B principal entity can do by assuming this role is limited by the permissions policy associated with the role. You can also grant permissions to other AWS services. For more information about using IAM to delegate permissions, see Access Management in the IAM User Guide. A complete tutorial is available at Walkthrough: Delegating Access Across AWS Accounts For Accounts You Own Using IAM Roles.

Understanding Resource Ownership

A resource owner is the AWS account that created a resource. That is, the resource owner is the AWS account of the principal entity (the root account, an IAM user, or an IAM role) that authenticates the request that creates the resource. The following examples illustrate how this works:

  • If you use the root account credentials of your AWS account to create an RDS resource, such as a DB instance, then your AWS account is the owner of the RDS resource.

  • If you create an IAM user in your AWS account and grant permissions to create RDS resources to that user, the user can create RDS resources. However, your AWS account, to which the user belongs, owns the RDS resources.

  • If you create an IAM role in your AWS account with permissions to create RDS resources, anyone who can assume the role can create RDS resources. Again, your AWS account, to which the role belongs, owns the RDS resources.

Managing Access

To create or access resources, an IAM user or role must be granted permissions through a permissions policy. For example, to grant a user permissions to create a DB instance, you use a permissions policy that is associated that user.

You can use IAM roles in cross-account scenarios. For example, Account A can create an IAM role that allows Account B to access resources in Account A. Then, Account B can assume that role and access resources in Account A. However, what the Account B principal entity can do by assuming the role is limited by the permissions policy associated with the role.

For more information about users, groups, roles, and permissions, see Identities (Users, Groups, and Roles), IAM Roles, and Access Management in the IAM User Guide.

The following shows an example of a permissions policy.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowMySQLTestCreate",
         "Effect":"Allow",
         "Action":"rds:CreateDBInstance",
         "Resource":"arn:aws:rds:us-west-2:123456789012:db:test*",
         "Condition":{
            "StringEquals":{
               "rds:DatabaseEngine":"mysql",
               "rds:DatabaseClass":"db.t1.micro"
            }
         }
      }
   ]
}

The preceding IAM policy example shows a simple policy statement that allows a user to create a DB instance for your AWS account that is limited to the following:

  • The DB instance identifier must begin with test (for example, testCustomerData1, test-region2-data).

    To specify which resources the user can perform the actions on or with, you use the Resource element. You specify resources using an Amazon Resources Name (ARN) that includes the name of the service that the resource belongs to (rds), the region (us-west-2 in this case), the account number, and the type of resource (a DB instance). For more information about creating ARNs, see Constructing an Amazon RDS Amazon Resource Name (ARN).

  • The DB engine must be MySQL and the DB instance class must be db.t1.micro.

    You can add additional permissions or restrictions by using the Condition element, which specifies the conditions when a policy should take effect. For more information about specifying conditions, see Using IAM Policy Conditions for Fine-Grained Access Control.

When creating your custom IAM policy for RDS, you must include the minimum required permissions for an RDS user in your policy. If your users need console access, they require additional permissions to gather AWS account information and other information used by RDS. For details about the minimum required permissions to use with the RDS console, see Permissions Required to Use the Amazon RDS Console.

Specifying Actions and Resources

In Amazon RDS, a DB instance is the primary resource. Amazon RDS supports allowing other resources to configure the primary resource. We can think of these other resources as subresources that don't exist unless they are associated with a DB instance. The following table shows each type of resource in Amazon RDS with the ARN format.

Resource Type ARN Format

DB instance, Read Replica, and Reserved DB instance

arn:aws:rds:region:account-id:db:db-instance-name

DB cluster

arn:aws:rds:region:account-id:cluster:db-cluster-name

DB snapshot

arn:aws:rds:region:account-id:snapshot:snapshot-name

DB cluster snapshot

arn:aws:rds:region:account-id:cluster-snapshot:cluster-snapshot-name

DB option group

arn:aws:rds:region:account-id:og:option-group-name

DB parameter group

arn:aws:rds:region:account-id:pg:parameter-group-name

DB cluster parameter group

arn:aws:rds:region:account-id:cluster-pg:cluster-parameter-group-name

DB security group

arn:aws:rds:region:account-id:secgrp:security-group-name

DB subnet group

arn:aws:rds:region:account-id:subgrp:subnet-group-name

Event subscription

arn:aws:rds:region:account-id:es:subscription-name

To grant permissions for specific API operations, such as creating a DB instance, Amazon RDS defines a set of actions that you can specify in a permissions policy. An API operation can require permissions for more than one action. For a table showing all of the Amazon RDS API operations, the corresponding actions for which permissions are required, the AWS resources for which you can grant the permissions to perform the action, and the condition keys for tag-based permissions, see RDS API Permissions: Actions, Resources, and Conditions Reference. For details on condition keys, see Using IAM Policy Conditions for Fine-Grained Access Control.

Specifying Conditions in a Policy

When you grant permissions, you can use the access policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in an access policy language, see Condition in the IAM User Guide.

To identify conditions where a permissions policy applies, include a Condition element in your IAM permissions policy. For example, you can create a policy that permits a user to create a DB instance using the rds:CreateDBInstance action, and you can add a Condition element to restrict that user to only create a DB instance using the MySQL database engine. RDS provides predefined condition keys and condition tags that apply to a specific resource. For details, see Using IAM Policy Conditions for Fine-Grained Access Control. For a list showing all of the predefined and tag-based condition key values and the RDS actions and resources that they apply to, see RDS API Permissions: Actions, Resources, and Conditions Reference.

Permissions Required to Use the Amazon RDS Console

To use the Amazon RDS console, you need to grant permissions for additional actions as shown in the following permissions policy:

Note

If you create an IAM policy that is more restrictive than these required permissions, the console doesn't function as intended for users attached to that IAM policy. Users must have these minimum required permissions for the console to function as designed. IAM policies that set permissions that are more restrictive than these required permissions are best for users that are making calls only to the AWS CLI or the API.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"RDSConsoleFullAccess",
         "Action":[
            "rds:*",
            "cloudwatch:DescribeAlarms",
            "cloudwatch:GetMetricStatistics",
            "ec2:DescribeAccountAttributes",
            "ec2:DescribeAvailabilityZones",
            "ec2:DescribeSecurityGroups",
            "ec2:DescribeSubnets",
            "ec2:DescribeVpcs",
            "sns:ListSubscriptions",
            "sns:ListTopics"
         ],
         "Effect":"Allow",
         "Resource":"*"
      }
   ]
}

You might want to restrict certain users to have read-only access to the Amazon RDS console. The following IAM policy grants the minimum required permissions to access the RDS console and read-only permissions to all of the RDS resources for your AWS account:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"RDSConsoleReadOnlyAccess1",
         "Action":[
            "rds:Describe*",
            "rds:ListTagsForResource",
            "ec2:DescribeAccountAttributes",
            "ec2:DescribeAvailabilityZones",
            "ec2:DescribeSecurityGroups",
            "ec2:DescribeVpcs"
         ],
         "Effect":"Allow",
         "Resource":"*"
      },
      {
         "Sid":"RDSConsoleReadOnlyAccess2",
         "Action":[
            "cloudwatch:GetMetricStatistics"
         ],
         "Effect":"Allow",
         "Resource":"*"
      }
   ]
}

AWS Managed Policies for Amazon RDS

AWS addresses many common use cases for IAM policies by providing AWS managed policies. An AWS managed policy is a standalone policy that is created and administered by AWS. These policies are designed to provide permissions for many common use cases. For more information about AWS managed policies, see Managed Policies and Inline Policies in the IAM User Guide. The following AWS managed policies are specific to Amazon RDS and are provided in the IAM console.

  • AmazonRDSReadOnlyAccess – Grants read-only access to all Amazon RDS resources for the root AWS account.

  • AmazonRDSFullAccess – Grants full access to all Amazon RDS resources for the root AWS account.

You can also create custom IAM policies that allow users to access the required Amazon RDS API actions and resources, and then attach the policies to the IAM users or groups that require those permissions, as described in Specifying Actions and Resources. For more information, see Example Policies: Creating Your Own Permissions Policies.

Example Policies: Creating Your Own Permissions Policies

In this section, you can find example user policies that grant permissions for various Amazon RDS actions. These policies work when you are using the RDS APIs, AWS SDKs, or the AWS CLI. When you are using the console, you need to grant additional permissions specific to the console, which is discussed in Permissions Required to Use the Amazon RDS Console.

Note

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

Example 1: Grant Permissions to Allow a User to Perform Any Describe Action on Any RDS Resource

The following permissions policy grants permissions to a user to run all of the actions that begin with Describe. These actions show information about an RDS resource, such as a DB instance. Note that the wildcard character (*) in the Resource element indicates that the actions are allowed for all Amazon RDS resources owned by the account.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowRDSDescribe",
         "Effect":"Allow",
         "Action":"rds:Describe*",
         "Resource":"*"
      }
   ]
}

Example 2: Grant Permissions to Allow a User to Create a DB Instance that Uses the Specified DB Parameter and Security Groups

The following permissions policy grants permissions to allow a user to only create a DB instance that must use the mysql-production DB parameter group and the db-production DB security group.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"AllowMySQLProductionCreate",
         "Effect":"Allow",
         "Action":"rds:CreateDBInstance",
         "Resource":[
            "arn:aws:rds:us-west-2:123456789012:pg:mysql-production",
            "arn:aws:rds:us-west-2:123456789012:secgrp:db-production"
         ]
      }
   ]
}

Example 3: Grant Permissions to Prevent a User from Deleting a DB Instance

The following permissions policy grants permissions to prevents a user from deleting a specific DB instance. For example, you might want to deny the ability to delete your production instances to any user that is not an administrator.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"DenyDelete1",
         "Effect":"Deny",
         "Action":"rds:DeleteDBInstance",
         "Resource":"arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
      }
   ]
}