# Identity and access management for Amazon Aurora
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use Amazon RDS resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [
## Audience
](#security_iam_audience)
+ [
## Authenticating with identities
](#security_iam_authentication)
+ [
## Managing access using policies
](#security_iam_access-manage)
+ [
# How Amazon Aurora works with IAM
](security_iam_service-with-iam.md)
+ [
# Identity-based policy examples for Amazon Aurora
](security_iam_id-based-policy-examples.md)
+ [
# AWS managed policies for Amazon RDS
](rds-security-iam-awsmanpol.md)
+ [
# Amazon RDS updates to AWS managed policies
](rds-manpol-updates.md)
+ [
# Preventing cross-service confused deputy problems
](cross-service-confused-deputy-prevention.md)
+ [
# IAM database authentication
](UsingWithRDS.IAMDBAuth.md)
+ [
# Troubleshooting Amazon Aurora identity and access
](security_iam_troubleshoot.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs, depending on the work you do in Amazon Aurora.
**Service user** – If you use the Aurora service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more Aurora features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in Aurora, see [Troubleshooting Amazon Aurora identity and access](security_iam_troubleshoot.md).
**Service administrator** – If you're in charge of Aurora resources at your company, you probably have full access to Aurora. It's your job to determine which Aurora features and resources your employees should access. You must then submit requests to your administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with Aurora, see [How Amazon Aurora works with IAM](security_iam_service-with-iam.md).
**Administrator** – If you're an administrator, you might want to learn details about how you can write policies to manage access to Aurora. To view example Aurora identity-based policies that you can use in IAM, see [Identity-based policy examples for Amazon Aurora](security_iam_id-based-policy-examples.md).
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### Federated identity
As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.
A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.
For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.
### IAM users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
You can authenticate to your DB cluster using IAM database authentication.
IAM database authentication works with Aurora. For more information about authenticating to your DB cluster using IAM, see [IAM database authentication ](UsingWithRDS.IAMDBAuth.md).
### IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity within your AWS account that has specific permissions. It is similar to a user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*.
IAM roles with temporary credentials are useful in the following situations:
+ **Temporary user permissions** – A user can assume an IAM role to temporarily take on different permissions for a specific task.
+ **Federated user access** – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [ Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [ Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center User Guide*.
+ **Cross-account access** – You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy). To learn the difference between roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.
+ **Cross-service access** – Some AWS services use features in other AWS services. For example, when you make a call in a service, it's common for that service to run applications in Amazon EC2 or store objects in Amazon S3. A service might do this using the calling principal's permissions, using a service role, or using a service-linked role.
+ **Forward access sessions** – Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Service role** – A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
+ **Service-linked role** – A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
+ **Applications running on Amazon EC2** – You can use an IAM role to manage temporary credentials for applications that are running on an EC2 instance and making AWS CLI or AWS API requests. This is preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, you create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the EC2 instance to get temporary credentials. For more information, see [Use an IAM role to grant permissions to applications running on Amazon EC2 instances](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*.
To learn whether to use IAM roles, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to IAM identities or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an entity (root user, user, or IAM role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
An administrator can use policies to specify who has access to AWS resources, and what actions they can perform on those resources. Every IAM entity (permission set or role) starts with no permissions. In other words, by default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group that has the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions.
IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as a permission set or role. These policies control what actions that identity can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single permission set or role. Managed policies are standalone policies that you can attach to multiple permission sets and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*.
For information about AWS managed policies that are specific to Amazon Aurora, see [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md).
### Other policy types
AWS supports additional, less-common policy types. These policy types can set the maximum permissions granted to you by the more common policy types.
+ **Permissions boundaries** – A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity (permission set or role). You can set a permissions boundary for an entity. The resulting permissions are the intersection of entity's identity-based policies and its permissions boundaries. Resource-based policies that specify the permission set or role in the `Principal` field are not limited by the permissions boundary. An explicit deny in any of these policies overrides the allow. For more information about permissions boundaries, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations. AWS Organizations is a service for grouping and centrally managing multiple AWS accounts that your business owns. If you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of your accounts. The SCP limits permissions for entities in member accounts, including each AWS account root user. For more information about Organizations and SCPs, see [How SCPs work](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Session policies are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The resulting session's permissions are the intersection of the permission sets or role's identity-based policies and the session policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies overrides the allow. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How Amazon Aurora works with IAM
Before you use IAM to manage access to Amazon Aurora, you should understand what IAM features are available to use with Aurora.
The following table lists IAM features you can use with Amazon Aurora:
| IAM feature | Amazon Aurora support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes |
| [Policy condition keys (service-specific)](#UsingWithRDS.IAM.Conditions) | Yes |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [Attribute-based access control (ABAC) (tags in policies)](#security_iam_service-with-iam-tags) | Yes |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Forward access sessions](#security_iam_service-with-iam-principal-permissions) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service) | Yes |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | Yes |
To get a high-level view of how Amazon Aurora and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [
## Aurora identity-based policies
](#security_iam_service-with-iam-id-based-policies)
+ [
## Resource-based policies within Aurora
](#security_iam_service-with-iam-resource-based-policies)
+ [
## Policy actions for Aurora
](#security_iam_service-with-iam-id-based-policies-actions)
+ [
## Policy resources for Aurora
](#security_iam_service-with-iam-id-based-policies-resources)
+ [
## Policy condition keys for Aurora
](#UsingWithRDS.IAM.Conditions)
+ [
## Access control lists (ACLs) in Aurora
](#security_iam_service-with-iam-acls)
+ [
## Attribute-based access control (ABAC) in policies with Aurora tags
](#security_iam_service-with-iam-tags)
+ [
## Using temporary credentials with Aurora
](#security_iam_service-with-iam-roles-tempcreds)
+ [
## Forward access sessions for Aurora
](#security_iam_service-with-iam-principal-permissions)
+ [
## Service roles for Aurora
](#security_iam_service-with-iam-roles-service)
+ [
## Service-linked roles for Aurora
](#security_iam_service-with-iam-roles-service-linked)
## Aurora identity-based policies
**Supports identity-based policies:** Yes.
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Identity-based policy examples for Aurora
To view examples of Aurora identity-based policies, see [Identity-based policy examples for Amazon Aurora](security_iam_id-based-policy-examples.md).
## Resource-based policies within Aurora
**Supports resource-based policies:** No.
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Policy actions for Aurora
**Supports policy actions:** Yes.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
Policy actions in Aurora use the following prefix before the action: `rds:`. For example, to grant someone permission to describe DB instances with the Amazon RDS `DescribeDBInstances` API operation, you include the `rds:DescribeDBInstances` action in their policy. Policy statements must include either an `Action` or `NotAction` element. Aurora defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows.
```
"Action": [
"rds:action1",
"rds:action2"
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action.
```
"Action": "rds:Describe*"
```
To see a list of Aurora actions, see [Actions Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) in the *Service Authorization Reference*.
## Policy resources for Aurora
**Supports policy resources:** Yes.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
The DB instance resource has the following Amazon Resource Name (ARN).
```
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
```
For more information about the format of ARNs, see [Amazon Resource Names (ARNs) and AWS service namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
For example, to specify the `dbtest` DB instance in your statement, use the following ARN.
```
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
```
To specify all DB instances that belong to a specific account, use the wildcard (\$1).
```
"Resource": "arn:aws:rds:us-east-1:123456789012:db:*"
```
Some RDS API operations, such as those for creating resources, can't be performed on a specific resource. In those cases, use the wildcard (\$1).
```
"Resource": "*"
```
Many Amazon RDS API operations involve multiple resources. For example, `CreateDBInstance` creates a DB instance. You can specify that an user must use a specific security group and parameter group when creating a DB instance. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": [
"resource1",
"resource2"
```
To see a list of Aurora resource types and their ARNs, see [Resources Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Policy condition keys for Aurora
**Supports service-specific policy condition keys:** Yes.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
Aurora defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
All RDS API operations support the `aws:RequestedRegion` condition key.
To see a list of Aurora condition keys, see [Condition Keys for Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Access control lists (ACLs) in Aurora
**Supports access control lists (ACLs):** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## Attribute-based access control (ABAC) in policies with Aurora tags
**Supports attribute-based access control (ABAC) tags in policies:** Yes
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
For more information about tagging Aurora resources, see [Specifying conditions: Using custom tags](UsingWithRDS.IAM.SpecifyingCustomTags.md). To view an example identity-based policy for limiting access to a resource based on the tags on that resource, see [Grant permission for actions on a resource with a specific tag with two different values](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags).
## Using temporary credentials with Aurora
**Supports temporary credentials:** Yes.
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Forward access sessions for Aurora
**Supports forward access sessions:** Yes.
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for Aurora
**Supports service roles:** Yes.
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
**Warning**
Changing the permissions for a service role might break Aurora functionality. Edit service roles only when Aurora provides guidance to do so.
## Service-linked roles for Aurora
**Supports service-linked roles:** Yes.
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about using Aurora service-linked roles, see [Using service-linked roles for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
# Identity-based policy examples for Amazon Aurora
By default, permission sets and roles don't have permission to create or modify Aurora resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An administrator must create IAM policies that grant permission sets and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the permission sets or roles that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [
## Policy best practices
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Using the Aurora console
](#security_iam_id-based-policy-examples-console)
+ [
## Permissions required to use the console
](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [
## Allow users to view their own permissions
](#security_iam_id-based-policy-examples-view-own-permissions)
+ [
# Permission policies to create, modify and, delete resources in Aurora
](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [
# Example policies: Using condition keys
](UsingWithRDS.IAM.Conditions.Examples.md)
+ [
# Specifying conditions: Using custom tags
](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [
# Grant permission to tag Aurora resources during creation
](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Amazon RDS resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Using the Aurora console
To access the Amazon Aurora console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the Amazon Aurora resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you're trying to perform.
To ensure that those entities can still use the Aurora console, also attach the following AWS managed policy to the entities.
```
AmazonRDSReadOnlyAccess
```
For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
## Permissions required to use the console
For a user to work with the console, that user must have a minimum set of permissions. These permissions allow the user to describe the Amazon Aurora resources for their AWS account and to provide other related information, including Amazon EC2 security and network information.
If you create an IAM policy that is more restrictive than the minimum required permissions, the console doesn't function as intended for users with that IAM policy. To ensure that those users can still use the console, also attach the `AmazonRDSReadOnlyAccess` managed policy to the user, as described in [Managing access using policies](UsingWithRDS.IAM.md#security_iam_access-manage).
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the Amazon RDS API.
The following policy grants full access to all Amazon Aurora resources for the root AWS account:
```
AmazonRDSFullAccess
```
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Permission policies to create, modify and, delete resources in Aurora
The following sections present examples of permission policies that grant and restrict access to resources:
## Allow a user to create DB instances in an AWS account
The following is an example policy that allows the account with the ID `123456789012` to create DB instances for your AWS account. The policy requires that the name of the new DB instance begin with `test`. The new DB instance must also use the MySQL database engine and the `db.t2.micro` DB instance class. In addition, the new DB instance must use an option group and a DB parameter group that starts with `default`, and it must use the `default` subnet group.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDBInstanceOnly",
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:db:test*",
"arn:aws:rds:*:123456789012:og:default*",
"arn:aws:rds:*:123456789012:pg:default*",
"arn:aws:rds:*:123456789012:subgrp:default"
],
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql",
"rds:DatabaseClass": "db.t2.micro"
}
}
}
]
}
```
------
The policy includes a single statement that specifies the following permissions for the user:
+ The policy allows the account to create a DB instance using the [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API operation (this also applies to the [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI command and the AWS Management Console).
+ The `Resource` element specifies that the user can perform actions on or with resources. You specify resources using an Amazon Resources Name (ARN). This ARN includes the name of the service that the resource belongs to (`rds`), the AWS Region (`*` indicates any region in this example), the AWS account number (`123456789012` is the account number in this example), and the type of resource. For more information about creating ARNs, see [Amazon Resource Names (ARNs) in Amazon RDS](USER_Tagging.ARN.md).
The `Resource` element in the example specifies the following policy constraints on resources for the user:
+ The DB instance identifier for the new DB instance must begin with `test` (for example, `testCustomerData1`, `test-region2-data`).
+ The option group for the new DB instance must begin with `default`.
+ The DB parameter group for the new DB instance must begin with `default`.
+ The subnet group for the new DB instance must be the `default` subnet group.
+ The `Condition` element specifies that the DB engine must be MySQL and the DB instance class must be `db.t2.micro`. The `Condition` element specifies the conditions when a policy should take effect. You can add additional permissions or restrictions by using the `Condition` element. For more information about specifying conditions, see [Policy condition keys for Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions). This example specifies the `rds:DatabaseEngine` and `rds:DatabaseClass` conditions. For information about the valid condition values for `rds:DatabaseEngine`, see the list under the `Engine` parameter in [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). For information about the valid condition values for `rds:DatabaseClass`, see [Supported DB engines for DB instance classes](Concepts.DBInstanceClass.SupportAurora.md).
The policy doesn't specify the `Principal` element because in an identity-based policy you don't specify the principal who gets the permission. When you attach policy to a user, the user is the implicit principal. When you attach a permission policy to an IAM role, the principal identified in the role's trust policy gets the permissions.
To see a list of Aurora actions, see [Actions Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) in the *Service Authorization Reference*.
## 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. The wildcard character (\$1) in the `Resource` element indicates that the actions are allowed for all Amazon Aurora resources owned by the account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRDSDescribe",
"Effect": "Allow",
"Action": "rds:Describe*",
"Resource": "*"
}
]
}
```
------
## Allow a user to create a DB instance that uses the specified DB parameter group and subnet group
The following permissions policy grants permissions to allow a user to only create a DB instance that must use the `mydbpg` DB parameter group and the `mydbsubnetgroup` DB subnet group.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": [
"arn:aws:rds:*:*:pg:mydbpg",
"arn:aws:rds:*:*:subgrp:mydbsubnetgroup"
]
}
]
}
```
------
## Grant permission for actions on a resource with a specific tag with two different values
You can use conditions in your identity-based policy to control access to Aurora resources based on tags. The following policy allows permission to perform the `CreateDBSnapshot` API operation on DB instances with either the `stage` tag set to `development` or `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
The following policy allows permission to perform the `ModifyDBInstance` API operation on DB instances with either the `stage` tag set to `development` or `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
## Prevent a user from deleting a DB instance
The following permissions policy grants permissions to prevent a user from deleting a specific DB instance. For example, you might want to deny the ability to delete your production DB instances to any user that is not an administrator.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyDelete1",
"Effect": "Deny",
"Action": "rds:DeleteDBInstance",
"Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
```
------
## Deny all access to a resource
You can explicitly deny access to a resource. Deny policies take precedence over allow policies. The following policy explicitly denies a user the ability to manage a resource:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "rds:*",
"Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb"
}
]
}
```
------
# Example policies: Using condition keys
Following are examples of how you can use condition keys in Amazon Aurora IAM permissions policies.
## Example 1: Grant permission to create a DB instance that uses a specific DB engine and isn't MultiAZ
The following policy uses an RDS condition key and allows a user to create only DB instances that use the MySQL database engine and don't use MultiAZ. The `Condition` element indicates the requirement that the database engine is MySQL.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowMySQLCreate",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql"
},
"Bool": {
"rds:MultiAz": false
}
}
}
]
}
```
------
## 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 DB instance classes. 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.
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
## Example 3: Limit the set of tag keys and values that can be used to tag a resource
The following policy uses an RDS condition key and allows the addition of a tag with the key `stage` to be added to a resource with the values `test`, `qa`, and `production`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowTagEdits",
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource": "arn:aws:rds:us-east-1:123456789012:db:db-123456",
"Condition": {
"StringEquals": {
"rds:req-tag/stage": [
"test",
"qa",
"production"
]
}
}
}
]
}
```
------
# Specifying conditions: Using custom tags
Amazon Aurora supports specifying conditions in an IAM policy using custom tags.
For example, suppose that you add a tag named `environment` to your DB instances with values such as `beta`, `staging`, `production`, and so on. If you do, 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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html)
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 Aurora andAmazon RDS resources](USER_Tagging.md).
**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":"*"
}
]
}
```
To see a list of Aurora actions, see [Actions Defined by Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) in the *Service Authorization Reference*.
## Example policies: Using custom tags
Following are examples of how you can use custom tags in Amazon Aurora IAM permissions policies. For more information about adding tags to an Amazon Aurora resource, see [Amazon Resource Names (ARNs) in Amazon RDS](USER_Tagging.ARN.md).
**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 `CreateDBSnapshot` API operation on DB instances with either the `stage` tag set to `development` or `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
The following policy allows permission to perform the `ModifyDBInstance` API operation on DB instances with either the `stage` tag set to `development` or `test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"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. 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.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyProductionCreate",
"Effect":"Deny",
"Action":"rds:CreateDBInstance",
"Resource":"arn:aws:rds:*:123456789012:pg:*",
"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 Aurora resources, see [Amazon Resource Names (ARNs) in Amazon RDS](USER_Tagging.ARN.md).
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
# Grant permission to tag Aurora resources during creation
Some RDS API operations allow you to specify tags when you create the resource. You can use resource tags to implement attribute-based control (ABAC). For more information, see [What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) and [Controlling access to AWS resources using tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html).
To enable users to tag resources on creation, they must have permissions to use the action that creates the resource, such as `rds:CreateDBCluster`. If tags are specified in the create action, RDS performs additional authorization on the `rds:AddTagsToResource` action to verify if users have permissions to create tags. Therefore, users must also have explicit permissions to use the `rds:AddTagsToResource` action.
In the IAM policy definition for the `rds:AddTagsToResource` action, you can use the `aws:RequestTag` condition key to require tags in a request to tag a resource.
For example, the following policy allows users to create DB instances and apply tags during DB instance creation, but only with specific tag keys (`environment` or `project`):
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": ["production", "development"],
"aws:RequestTag/project": ["dataanalytics", "webapp"]
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment", "project"]
}
}
}
]
}
```
------
This policy denies any create DB instance request that includes tags other than the `environment` or `project` tags, or that doesn't specify either of these tags. Additionally, users must specify values for the tags that match the allowed values in the policy.
The following policy allows users to create DB clusters and apply any tags during creation except the `environment=prod` tag:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBCluster"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestTag/environment": "prod"
}
}
}
]
}
```
------
## Supported RDS API actions for tagging on creation
The following RDS API actions support tagging when you create a resource. For these actions, you can specify tags when you create the resource:
+ `CreateBlueGreenDeployment`
+ `CreateCustomDBEngineVersion`
+ `CreateDBCluster`
+ `CreateDBClusterEndpoint`
+ `CreateDBClusterParameterGroup`
+ `CreateDBClusterSnapshot`
+ `CreateDBInstance`
+ `CreateDBInstanceReadReplica`
+ `CreateDBParameterGroup`
+ `CreateDBProxy`
+ `CreateDBProxyEndpoint`
+ `CreateDBSecurityGroup`
+ `CreateDBShardGroup`
+ `CreateDBSnapshot`
+ `CreateDBSubnetGroup`
+ `CreateEventSubscription`
+ `CreateGlobalCluster`
+ `CreateIntegration`
+ `CreateOptionGroup`
+ `CreateTenantDatabase`
+ `CopyDBClusterParameterGroup`
+ `CopyDBClusterSnapshot`
+ `CopyDBParameterGroup`
+ `CopyDBSnapshot`
+ `CopyOptionGroup`
+ `RestoreDBClusterFromS3`
+ `RestoreDBClusterFromSnapshot`
+ `RestoreDBClusterToPointInTime`
+ `RestoreDBInstanceFromDBSnapshot`
+ `RestoreDBInstanceFromS3`
+ `RestoreDBInstanceToPointInTime`
+ `PurchaseReservedDBInstancesOffering`
If you use the AWS CLI or API to create a resource with tags, the `Tags` parameter is used to apply tags to resources during creation.
For these API actions, if tagging fails, the resource is not created, and the request fails with an error. This ensures that resources are either created with tags or not created at all, preventing resources from being created without the intended tags.
# AWS managed policies for Amazon RDS
To add permissions to permission sets and roles, it's easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (permission sets and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services don't remove permissions from an AWS managed policy, so policy updates don't break your existing permissions.
Additionally, AWS supports managed policies for job functions that span multiple services. For example, the `ReadOnlyAccess` AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
**Topics**
+ [
## AWS managed policy: AmazonRDSReadOnlyAccess
](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess)
+ [
## AWS managed policy: AmazonRDSFullAccess
](#rds-security-iam-awsmanpol-AmazonRDSFullAccess)
+ [
## AWS managed policy: AmazonRDSDataFullAccess
](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess)
+ [
## AWS managed policy: AmazonRDSEnhancedMonitoringRole
](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole)
+ [
## AWS managed policy: AmazonRDSPerformanceInsightsReadOnly
](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)
+ [
## AWS managed policy: AmazonRDSPerformanceInsightsFullAccess
](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)
+ [
## AWS managed policy: AmazonRDSDirectoryServiceAccess
](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess)
+ [
## AWS managed policy: AmazonRDSServiceRolePolicy
](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)
+ [
## AWS managed policy: AmazonRDSPreviewServiceRolePolicy
](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)
+ [
## AWS managed policy: AmazonRDSBetaServiceRolePolicy
](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)
## AWS managed policy: AmazonRDSReadOnlyAccess
This policy allows read-only access to Amazon RDS through the AWS Management Console.
**Permissions details**
This policy includes the following permissions:
+ `rds` – Allows principals to describe Amazon RDS resources and list the tags for Amazon RDS resources.
+ `cloudwatch` – Allows principals to get Amazon CloudWatch metric statistics.
+ `ec2` – Allows principals to describe Availability Zones and networking resources.
+ `logs` – Allows principals to describe CloudWatch Logs log streams of log groups, and get CloudWatch Logs log events.
+ `devops-guru` – Allows principals to describe resources that have Amazon DevOps Guru coverage, which is specified either by CloudFormation stack names or resource tags.
For more information about this policy, including the JSON policy document, see [AmazonRDSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSFullAccess
This policy provides full access to Amazon RDS through the AWS Management Console.
**Permissions details**
This policy includes the following permissions:
+ `rds` – Allows principals full access to Amazon RDS.
+ `application-autoscaling` – Allows principals describe and manage Application Auto Scaling scaling targets and policies.
+ `cloudwatch` – Allows principals get CloudWatch metric statics and manage CloudWatch alarms.
+ `ec2` – Allows principals to describe Availability Zones and networking resources.
+ `logs` – Allows principals to describe CloudWatch Logs log streams of log groups, and get CloudWatch Logs log events.
+ `outposts` – Allows principals to get AWS Outposts instance types.
+ `pi` – Allows principals to get Performance Insights metrics.
+ `sns` – Allows principals to Amazon Simple Notification Service (Amazon SNS) subscriptions and topics, and to publish Amazon SNS messages.
+ `devops-guru` – Allows principals to describe resources that have Amazon DevOps Guru coverage, which is specified either by CloudFormation stack names or resource tags.
For more information about this policy, including the JSON policy document, see [AmazonRDSFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSDataFullAccess
This policy allows full access to use the Data API and the query editor on Aurora Serverless clusters in a specific AWS account. This policy allows the AWS account to get the value of a secret from AWS Secrets Manager.
You can attach the `AmazonRDSDataFullAccess` policy to your IAM identities.
**Permissions details**
This policy includes the following permissions:
+ `dbqms` – Allows principals to access, create, delete, describe, and update queries. The Database Query Metadata Service (`dbqms`) is an internal-only service. It provides your recent and saved queries for the query editor on the AWS Management Console for multiple AWS services, including Amazon RDS.
+ `rds-data` – Allows principals to run SQL statements on Aurora Serverless databases.
+ `secretsmanager` – Allows principals to get the value of a secret from AWS Secrets Manager.
For more information about this policy, including the JSON policy document, see [AmazonRDSDataFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSEnhancedMonitoringRole
This policy provides access to Amazon CloudWatch Logs for Amazon RDS Enhanced Monitoring.
**Permissions details**
This policy includes the following permissions:
+ `logs` – Allows principals to create CloudWatch Logs log groups and retention policies, and to create and describe CloudWatch Logs log streams of log groups. It also allows principals to put and get CloudWatch Logs log events.
For more information about this policy, including the JSON policy document, see [AmazonRDSEnhancedMonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSPerformanceInsightsReadOnly
This policy provides read-only access to Amazon RDS Performance Insights for Amazon RDS DB instances and Amazon Aurora DB clusters.
This policy now includes `Sid` (statement ID) as an identifier for the policy statement.
**Permissions details**
This policy includes the following permissions:
+ `rds` – Allows principals to describe Amazon RDS DB instances and Amazon Aurora DB clusters.
+ `pi` – Allows principals make calls to the Amazon RDS Performance Insights API and access Performance Insights metrics.
For more information about this policy, including the JSON policy document, see [AmazonRDSPerformanceInsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSPerformanceInsightsFullAccess
This policy provides full access to Amazon RDS Performance Insights for Amazon RDS DB instances and Amazon Aurora DB clusters.
This policy now includes `Sid` (statement ID) as an identifier for the policy statement.
**Permissions details**
This policy includes the following permissions:
+ `rds` – Allows principals to describe Amazon RDS DB instances and Amazon Aurora DB clusters.
+ `pi` – Allows principals make calls to the Amazon RDS Performance Insights API, and create, view, and delete performance analysis reports.
+ `cloudwatch` – Allows principals to list all the Amazon CloudWatch metrics, and get metric data and statistics.
For more information about this policy, including the JSON policy document, see [AmazonRDSPerformanceInsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSDirectoryServiceAccess
This policy allows Amazon RDS to make calls to the Directory Service.
**Permissions details**
This policy includes the following permission:
+ `ds` – Allows principals to describe Directory Service directories and control authorization to Directory Service directories.
For more information about this policy, including the JSON policy document, see [AmazonRDSDirectoryServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSServiceRolePolicy
You can't attach the `AmazonRDSServiceRolePolicy` policy to your IAM entities. This policy is attached to a service-linked role that allows Amazon RDS to perform actions on your behalf. For more information, see [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions).
## AWS managed policy: AmazonRDSPreviewServiceRolePolicy
You shouldn't attach `AmazonRDSPreviewServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon RDS to call AWS services on behalf of your RDS DB resources. For more information, see [Service-linked role for Amazon RDS Preview](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview).
**Permissions details**
This policy includes the following permissions:
+ `ec2` ‐ Allows principals to describe Availability Zones and networking resources.
+ `secretsmanager` – Allows principals to get the value of a secret from AWS Secrets Manager.
+ `cloudwatch`, `logs` ‐ Allows Amazon RDS to upload DB instance metrics and logs to CloudWatch through CloudWatch agent.
For more information about this policy, including the JSON policy document, see [AmazonRDSPreviewServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html) in the *AWS Managed Policy Reference Guide*.
## AWS managed policy: AmazonRDSBetaServiceRolePolicy
You shouldn't attach `AmazonRDSBetaServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon RDS to call AWS services on behalf of your RDS DB resources. For more information, see [Service-linked role permissions for Amazon RDS Beta](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta).
**Permissions details**
This policy includes the following permissions:
+ `ec2` ‐ Allows Amazon RDS to perform backup operations on the DB instance that provides point-in-time restore capabilities.
+ `secretsmanager` ‐ Allows Amazon RDS to manage DB instance specific secrets created by Amazon RDS.
+ `cloudwatch`, `logs` ‐ Allows Amazon RDS to upload DB instance metrics and logs to CloudWatch through CloudWatch agent.
For more information about this policy, including the JSON policy document, see [AmazonRDSBetaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html) in the *AWS Managed Policy Reference Guide*.
# Amazon RDS updates to AWS managed policies
View details about updates to AWS managed policies for Amazon RDS since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the Amazon RDS [Document history](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html) page.
| Change | Description | Date |
| --- | --- | --- |
| [AWS managed policy: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy) – Update to existing policy | Amazon RDS removed `sns:Publish` permission from the `AmazonRDSPreviewServiceRolePolicy` of the `AWSServiceRoleForRDSPreview` service-linked role. For more information, see [AWS managed policy: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). | August 7, 2024 |
| [AWS managed policy: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy) – Update to existing policy | Amazon RDS removed `sns:Publish` permission from the `AmazonRDSBetaServiceRolePolicy` of the `AWSServiceRoleForRDSBeta` service-linked role. For more information, see [AWS managed policy: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). | August 7, 2024 |
| [AWS managed policy: AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy) – Update to existing policy | Amazon RDS removed `sns:Publish` permission from the `AmazonRDSServiceRolePolicy` of the ` AWSServiceRoleForRDS` service-linked role. For more information, see [AWS managed policy: AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy). | July 2, 2024 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – Update to existing policy | Amazon RDS added a new permission to the `AmazonRDSCustomServiceRolePolicy` of the `AWSServiceRoleForRDSCustom` service-linked role to allow RDS Custom for SQL Server to modify the underlying database host instance type. RDS also added the `ec2:DescribeInstanceTypes` permission to get instance type information for database host. For more information, see [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md). | April 8, 2024 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – New policy | Amazon RDS added a new managed policy named AmazonRDSCustomInstanceProfileRolePolicy to allow RDS Custom to perform automation actions and database management tasks through an EC2 instance profile. For more information, see [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md). | February 27, 2024 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added new statement IDs to the `AmazonRDSServiceRolePolicy` of the `AWSServiceRoleForRDS` service-linked role. For more information, see [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). | January 19, 2024 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – Update to existing policies | The `AmazonRDSPerformanceInsightsReadOnly` and `AmazonRDSPerformanceInsightsFullAccess` managed policies now includes `Sid` (statement ID) as an identifier in the policy statement. For more information, see [AWS managed policy: AmazonRDSPerformanceInsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) and [AWS managed policy: AmazonRDSPerformanceInsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess) | October 23, 2023 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – Update to existing policy | Amazon RDS added new permissions to `AmazonRDSFullAccess` managed policy. The permissions allow you to generate, view, and delete the performance analysis report for a time period. For more information about configuring access policies for Performance Insights, see [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md) | August 17, 2023 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – New policy and update to existing policy | Amazon RDS added new permissions to `AmazonRDSPerformanceInsightsReadOnly` managed policy and a new managed policy named `AmazonRDSPerformanceInsightsFullAccess`. These permissions allow you to analyse the Performance Insights for a time period, view the analysis results along with the recommendations, and delete the reports. For more information about configuring access policies for Performance Insights, see [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md) | August 16, 2023 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – Update to an existing policy | Amazon RDS added a new Amazon CloudWatch namespace `ListMetrics` to `AmazonRDSFullAccess` and `AmazonRDSReadOnlyAccess`. This namespace is required for Amazon RDS to list specific resource usage metrics. For more information, see [Overview of managing access permissions to your CloudWatch resources](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html) in the *Amazon CloudWatch User Guide*. | April 4, 2023 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added new permissions to the `AmazonRDSServiceRolePolicy` of the `AWSServiceRoleForRDS` service-linked role for integration with AWS Secrets Manager. RDS requires integration with Secrets Manager for managing master user passwords in Secrets Manager. The secret uses a reserved naming convention and restricts customer updates. For more information, see [Password management with Amazon Aurora and AWS Secrets Manager](rds-secrets-manager.md). | December 22, 2022 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – Update to existing policies | Amazon RDS added a new permission to the `AmazonRDSFullAccess` and `AmazonRDSReadOnlyAccess` managed policies to allow you to turn on Amazon DevOps Guru in the RDS console. This permission is required to check whether DevOps Guru is turned on. For more information, see [Configuring IAM access policies for DevOps Guru for RDS](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access). | December 19, 2022 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added a new Amazon CloudWatch namespace to `AmazonRDSPreviewServiceRolePolicy` for `PutMetricData`. This namespace is required for Amazon RDS to publish resource usage metrics. For more information, see [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) in the *Amazon CloudWatch User Guide*. | June 7, 2022 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added a new Amazon CloudWatch namespace to `AmazonRDSBetaServiceRolePolicy` for `PutMetricData`. This namespace is required for Amazon RDS to publish resource usage metrics. For more information, see [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) in the *Amazon CloudWatch User Guide*. | June 7, 2022 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added a new Amazon CloudWatch namespace to `AWSServiceRoleForRDS` for `PutMetricData`. This namespace is required for Amazon RDS to publish resource usage metrics. For more information, see [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) in the *Amazon CloudWatch User Guide*. | April 22, 2022 |
| [AWS managed policies for Amazon RDS](rds-security-iam-awsmanpol.md) – New policy | Amazon RDS added a new managed policy named `AmazonRDSPerformanceInsightsReadOnly` to allow Amazon RDS to call AWS services on behalf of your DB instances. For more information about configuring access policies for Performance Insights, see [Configuring access policies for Performance Insights](USER_PerfInsights.access-control.md) | March 10, 2022 |
| [Service-linked role permissions for Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Update to an existing policy | Amazon RDS added new Amazon CloudWatch namespaces to `AWSServiceRoleForRDS` for `PutMetricData`. These namespaces are required for Amazon DocumentDB (with MongoDB compatibility) and Amazon Neptune to publish CloudWatch metrics. For more information, see [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) in the *Amazon CloudWatch User Guide*. | March 4, 2022 |
| Amazon RDS started tracking changes | Amazon RDS started tracking changes for its AWS managed policies. | October 26, 2021 |
# Preventing cross-service confused deputy problems
The *confused deputy problem* is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem.
Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way that it shouldn't have permission to access. To prevent this, AWS provides tools that can help you protect your data for all services with service principals that have been given access to resources in your account. For more information, see [The confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) in the *IAM User Guide*.
To limit the permissions that Amazon RDS gives another service for a specific resource, we recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies.
In some cases, the `aws:SourceArn` value doesn't contain the account ID, for example when you use the Amazon Resource Name (ARN) for an Amazon S3 bucket. In these cases, make sure to use both global condition context keys to limit permissions. In some cases, you use both global condition context keys and the `aws:SourceArn` value contains the account ID. In these cases, make sure that the `aws:SourceAccount` value and the account in the `aws:SourceArn` use the same account ID when they're used in the same policy statement. If you want only one resource to be associated with the cross-service access, use `aws:SourceArn`. If you want to allow any resource in the specified AWS account to be associated with the cross-service use, use `aws:SourceAccount`.
Make sure that the value of `aws:SourceArn` is an ARN for an Amazon RDS resource type. For more information, see [Amazon Resource Names (ARNs) in Amazon RDS](USER_Tagging.ARN.md).
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. In some cases, you might not know the full ARN of the resource or you might be specifying multiple resources. In these cases, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. An example is `arn:aws:rds:*:123456789012:*`.
The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in Amazon RDS to prevent the confused deputy problem.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
For more examples of policies that use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys, see the following sections:
+ [Granting permissions to publish notifications to an Amazon SNS topic](USER_Events.GrantingPermissions.md)
+ [Setting up access to an Amazon S3 bucket](USER_PostgreSQL.S3Import.AccessPermission.md) (PostgreSQL import)
+ [Setting up access to an Amazon S3 bucket](postgresql-s3-export-access-bucket.md) (PostgreSQL export)
# IAM database authentication
You can authenticate to your DB cluster using AWS Identity and Access Management (IAM) database authentication. IAM database authentication works with Aurora MySQL, and Aurora PostgreSQL. With this authentication method, you don't need to use a password when you connect to a DB cluster. Instead, you use an authentication token.
An *authentication token* is a unique string of characters that Amazon Aurora generates on request. Authentication tokens are generated using AWS Signature Version 4. Each token has a lifetime of 15 minutes. You don't need to store user credentials in the database, because authentication is managed externally using IAM. You can also still use standard database authentication. The token is only used for authentication and doesn't affect the session after it is established.
IAM database authentication provides the following benefits:
+ Network traffic to and from the database is encrypted using Secure Socket Layer (SSL) or Transport Layer Security (TLS). For more information about using SSL/TLS with Amazon Aurora, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
+ You can use IAM to centrally manage access to your database resources, instead of managing access individually on each DB cluster.
+ For applications running on Amazon EC2, you can use profile credentials specific to your EC2 instance to access your database instead of a password, for greater security.
In general, consider using IAM database authentication when your applications create fewer than 200 connections per second, and you don't want to manage usernames and passwords directly in your application code.
The Amazon Web Services (AWS) JDBC Driver supports IAM database authentication. For more information, see [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) in the [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/aws/aws-advanced-jdbc-wrapper).
The Amazon Web Services (AWS) Python Driver supports IAM database authentication. For more information, see [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) in the [Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/aws/aws-advanced-python-wrapper).
Navigate through the following topics to learn the process to set IAM for DB authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Connecting to your DB cluster using IAM authentication](UsingWithRDS.IAMDBAuth.Connecting.md)
## Region and version availability
Feature availability and support varies across specific versions of each Aurora database engine, and across AWS Regions. For more information on version and Region availability with Aurora and IAM database authentication, see [Supported Regions and Aurora DB engines for IAM database authentication](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md).
For Aurora MySQL, all supported DB instance classes support IAM database authentication, except for db.t2.small and db.t3.small. For information about the supported DB instance classes, see [Supported DB engines for DB instance classes](Concepts.DBInstanceClass.SupportAurora.md).
## CLI and SDK support
IAM database authentication is available for the [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html) and for the following language-specific AWS SDKs:
+ [AWS SDK for .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html)
+ [AWS SDK for C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/latest/api/class_aws_1_1_r_d_s_1_1_r_d_s_client.html#ae134ffffed5d7672f6156d324e7bd392)
+ [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview)
+ [AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html)
+ [AWS SDK for JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html)
+ [AWS SDK for PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html)
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token)
+ [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html)
## Limitations for IAM database authentication
When using IAM database authentication, the following limitations apply:
+ Currently, IAM database authentication doesn't support all global condition context keys.
For more information about global condition context keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
+ For PostgreSQL, if the IAM role (`rds_iam`) is added to a user (including the RDS master user), IAM authentication takes precedence over password authentication, so the user must log in as an IAM user.
+ You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
+ CloudWatch and CloudTrail don't log IAM authentication. These services do not track `generate-db-auth-token` API calls that authorize the IAM role to enable database connection.
+ IAM DB authentication requires compute resources on the database cluster. You must have between 300 and 1000 MiB extra memory on your database for reliable connectivity. To see the memory needed for your workload, compare the RES column for RDS processes in the Enhanced Monitoring processlist before and after enabling IAM DB authentication. See [Viewing OS metrics in the RDS console](USER_Monitoring.OS.Viewing.md).
If you are using a burstable class instance, avoid running out of memory by reducing the memory used by other parameters like buffers and cache by the same amount.
+ For Aurora MySQL, you can't use password based authentication for a database user you configure with IAM authentication.
+ IAM DB authentication is not supported for RDS on Outposts for any engine.
## Recommendations for IAM database authentication
We recommend the following when using IAM database authentication:
+ Use IAM database authentication when your application requires fewer than 200 new IAM database authentication connections per second.
The database engines that work with Amazon Aurora don't impose any limits on authentication attempts per second. However, when you use IAM database authentication, your application must generate an authentication token. Your application then uses that token to connect to the DB cluster. If you exceed the limit of maximum new connections per second, then the extra overhead of IAM database authentication can cause connection throttling.
Consider using connection pooling in your applications to mitigate constant connection creation. This can reduce the overhead from IAM DB authentication and allow your applications to reuse existing connections. Alternatively, consider using RDS Proxy for these use cases. RDS Proxy has additional costs. See [RDS Proxy pricing](https://aws.amazon.com/rds/proxy/pricing/).
+ The size of an IAM database authentication token depends on many things including the number of IAM tags, IAM service policies, ARN lengths, as well as other IAM and database properties. The minimum size of this token is generally about 1 KB but can be larger. Since this token is used as the password in the connection string to the database using IAM authentication, you should ensure that your database driver (e.g., ODBC) and/or any tools do not limit or otherwise truncate this token due to its size. A truncated token will cause the authentication validation done by the database and IAM to fail.
+ If you are using temporary credentials when creating an IAM database authentication token, the temporary credentials must still be valid when using the IAM database authentication token to make a connection request.
## Unsupported AWS global condition context keys
IAM database authentication does not support the following subset of AWS global condition context keys.
+ `aws:Referer`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
For more information, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
# Enabling and disabling IAM database authentication
By default, IAM database authentication is disabled on DB clusters. You can enable or disable IAM database authentication using the AWS Management Console, AWS CLI, or the API.
You can enable IAM database authentication when you perform one of the following actions:
+ To create a new DB cluster with IAM database authentication enabled, see [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md).
+ To modify a DB cluster to enable IAM database authentication, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).
+ To restore a DB cluster from a snapshot with IAM database authentication enabled, see [Restoring from a DB cluster snapshot](aurora-restore-snapshot.md).
+ To restore a DB cluster to a point in time with IAM database authentication enabled, see [Restoring a DB cluster to a specified time](aurora-pitr.md).
## Console
Each creation or modification workflow has a **Database authentication** section, where you can enable or disable IAM database authentication. In that section, choose **Password and IAM database authentication** to enable IAM database authentication.
**To enable or disable IAM database authentication for an existing DB cluster**
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the DB cluster that you want to modify.
**Note**
You can only enable IAM authentication if all DB instances in the DB cluster are compatible with IAM. Check the compatibility requirements in [Region and version availability](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
1. Choose **Modify**.
1. In the **Database authentication** section, choose **IAM database authentication** to enable IAM database authentication. Choose **Password authentication** or **Password and Kerberos authentication** to disable IAM authentication.
1. You can also choose to enable publishing IAM DB authentication logs to CloudWatch Logs. Under **Log exports**, choose the **iam-db-auth-error log** option. Publishing your logs to CloudWatch Logs consumes storage and you incur charges for that storage. Be sure to delete any CloudWatch Logs that you no longer need.
1. Choose **Continue**.
1. To apply the changes immediately, choose **Immediately** in the **Scheduling of modifications** section.
1. Choose **Modify cluster**.
## AWS CLI
To create a new DB cluster with IAM authentication by using the AWS CLI, use the [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) command. Specify the `--enable-iam-database-authentication` option.
To update an existing DB cluster to have or not have IAM authentication, use the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Specify either the `--enable-iam-database-authentication` or `--no-enable-iam-database-authentication` option, as appropriate.
**Note**
You can only enable IAM authentication if all DB instances in the DB cluster are compatible with IAM. Check the compatibility requirements in [Region and version availability](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
By default, Aurora performs the modification during the next maintenance window. If you want to override this and enable IAM DB authentication as soon as possible, use the `--apply-immediately` parameter.
If you are restoring a DB cluster, use one of the following AWS CLI commands:
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)`
+ `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)`
The IAM database authentication setting defaults to that of the source snapshot. To change this setting, set the `--enable-iam-database-authentication` or `--no-enable-iam-database-authentication` option, as appropriate.
## RDS API
To create a new DB instance with IAM authentication by using the API, use the API operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Set the `EnableIAMDatabaseAuthentication` parameter to `true`.
To update an existing DB cluster to have IAM authentication, use the API operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Set the `EnableIAMDatabaseAuthentication` parameter to `true` to enable IAM authentication, or `false` to disable it.
**Note**
You can only enable IAM authentication if all DB instances in the DB cluster are compatible with IAM. Check the compatibility requirements in [Region and version availability](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
If you are restoring a DB cluster, use one of the following API operations:
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
The IAM database authentication setting defaults to that of the source snapshot. To change this setting, set the `EnableIAMDatabaseAuthentication` parameter to `true` to enable IAM authentication, or `false` to disable it.
# Creating and using an IAM policy for IAM database access
To allow a user or role to connect to your DB cluster, you must create an IAM policy. After that, you attach the policy to a permissions set or role.
**Note**
To learn more about IAM policies, see [Identity and access management for Amazon Aurora](UsingWithRDS.IAM.md).
The following example policy allows a user to connect to a DB cluster using IAM database authentication.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
```
------
**Important**
A user with administrator permissions can access DB clusters without explicit permissions in an IAM policy. If you want to restrict administrator access to DB clusters, you can create an IAM role with the appropriate, lesser privileged permissions and assign it to the administrator.
**Note**
Don't confuse the `rds-db:` prefix with other RDS API operation prefixes that begin with `rds:`. You use the `rds-db:` prefix and the `rds-db:connect` action only for IAM database authentication. They aren't valid in any other context.
The example policy includes a single statement with the following elements:
+ `Effect` – Specify `Allow` to grant access to the DB cluster. If you don't explicitly allow access, then access is denied by default.
+ `Action` – Specify `rds-db:connect` to allow connections to the DB cluster.
+ `Resource` – Specify an Amazon Resource Name (ARN) that describes one database account in one DB cluster. The ARN format is as follows.
```
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
```
In this format, replace the following:
+ `region` is the AWS Region for the DB cluster. In the example policy, the AWS Region is `us-east-2`.
+ `account-id` is the AWS account number for the DB cluster. In the example policy, the account number is `1234567890`. The user must be in the same account as the account for the DB cluster.
To perform cross-account access, create an IAM role with the policy shown above in the account for the DB cluster and allow your other account to assume the role.
+ `DbClusterResourceId` is the identifier for the DB cluster. This identifier is unique to an AWS Region and never changes. In the example policy, the identifier is `cluster-ABCDEFGHIJKL01234`.
To find a DB cluster resource ID in the AWS Management Console for Amazon Aurora, choose the DB cluster to see its details. Then choose the **Configuration** tab. The **Resource ID** is shown in the **Configuration** section.
Alternatively, you can use the AWS CLI command to list the identifiers and resource IDs for all of your DB cluster in the current AWS Region, as shown following.
```
aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]"
```
**Note**
If you are connecting to a database through RDS Proxy, specify the proxy resource ID, such as `prx-ABCDEFGHIJKL01234`. For information about using IAM database authentication with RDS Proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
+ `db-user-name` is the name of the database account to associate with IAM authentication. In the example policy, the database account is `db_user`.
You can construct other ARNs to support various access patterns. The following policy allows access to two different database accounts in a DB cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe"
]
}
]
}
```
------
The following policy uses the "\$1" character to match all DB clusters and database accounts for a particular AWS account and AWS Region.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*"
]
}
]
}
```
------
The following policy matches all of the DB clusters for a particular AWS account and AWS Region. However, the policy only grants access to DB clusters that have a `jane_doe` database account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
```
------
The user or role has access to only those databases that the database user does. For example, suppose that your DB cluster has a database named *dev*, and another database named *test*. If the database user `jane_doe` has access only to *dev*, any users or roles that access that DB cluster with the `jane_doe` user also have access only to *dev*. This access restriction is also true for other database objects, such as tables, views, and so on.
An administrator must create IAM policies that grant entities permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the permission sets or roles that require those permissions. For examples of policies, see [Identity-based policy examples for Amazon Aurora](security_iam_id-based-policy-examples.md).
## Attaching an IAM policy to a permission set or role
After you create an IAM policy to allow database authentication, you need to attach the policy to a permission set or role. For a tutorial on this topic, see [ Create and attach your first customer managed policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) in the *IAM User Guide*.
As you work through the tutorial, you can use one of the policy examples shown in this section as a starting point and tailor it to your needs. At the end of the tutorial, you have a permission set with an attached policy that can make use of the `rds-db:connect` action.
**Note**
You can map multiple permission sets or roles to the same database user account. For example, suppose that your IAM policy specified the following resource ARN.
```
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
If you attach the policy to *Jane*, *Bob*, and *Diego*, then each of those users can connect to the specified DB cluster using the `jane_doe` database account.
# Creating a database account using IAM authentication
With IAM database authentication, you don't need to assign database passwords to the user accounts you create. If you remove a user that is mapped to a database account, you should also remove the database account with the `DROP USER` statement.
**Note**
The user name used for IAM authentication must match the case of the user name in the database.
**Topics**
+ [
## Using IAM authentication with Aurora MySQL
](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [
## Using IAM authentication with AuroraPostgreSQL
](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## Using IAM authentication with Aurora MySQL
With Aurora MySQL, authentication is handled by `AWSAuthenticationPlugin`—an AWS-provided plugin that works seamlessly with IAM to authenticate your users. Connect to the DB cluster as the master user or a different user who can create users and grant privileges. After connecting, issue the `CREATE USER` statement, as shown in the following example.
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
The `IDENTIFIED WITH` clause allows Aurora MySQL to use the `AWSAuthenticationPlugin` to authenticate the database account (`jane_doe`). The `AS 'RDS'` clause refers to the authentication method. Make sure the specified database user name is the same as a resource in the IAM policy for IAM database access. For more information, see [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
**Note**
If you see the following message, it means that the AWS-provided plugin is not available for the current DB cluster.
`ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded`
To troubleshoot this error, verify that you are using a supported configuration and that you have enabled IAM database authentication on your DB cluster. For more information, see [Region and version availability](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) and [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md).
After you create an account using `AWSAuthenticationPlugin`, you manage it in the same way as other database accounts. For example, you can modify account privileges with `GRANT` and `REVOKE` statements, or modify various account attributes with the `ALTER USER` statement.
Database network traffic is encrypted using SSL/TLS when using IAM. To allow SSL connections, modify the user account with the following command.
```
ALTER USER 'jane_doe'@'%' REQUIRE SSL;
```
## Using IAM authentication with AuroraPostgreSQL
To use IAM authentication with Aurora PostgreSQL, connect to the DB cluster as the master user or a different user who can create users and grant privileges. After connecting, create database users and then grant them the `rds_iam` role as shown in the following example.
```
CREATE USER db_userx;
GRANT rds_iam TO db_userx;
```
Make sure the specified database user name is the same as a resource in the IAM policy for IAM database access. For more information, see [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md). You must grant the `rds_iam` role to use IAM authentication. You can use nested memberships or indirect grants of the role as well.
Note that a PostgreSQL database user can use either IAM or Kerberos authentication but not both, so this user can't also have the `rds_ad` role. This also applies to nested memberships. For more information, see [Step 7: Create PostgreSQL users for your Kerberos principals](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
# Connecting to your DB cluster using IAM authentication
With IAM database authentication, you use an authentication token when you connect to your DB cluster. An *authentication token* is a string of characters that you use instead of a password. After you generate an authentication token, it's valid for 15 minutes before it expires. If you try to connect using an expired token, the connection request is denied.
Every authentication token must be accompanied by a valid signature, using AWS signature version 4. (For more information, see [Signature Version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the* AWS General Reference.*) The AWS CLI and an AWS SDK, such as the AWS SDK for Java or AWS SDK for Python (Boto3), can automatically sign each token you create.
You can use an authentication token when you connect to Amazon Aurora from another AWS service, such as AWS Lambda. By using a token, you can avoid placing a password in your code. Alternatively, you can use an AWS SDK to programmatically create and programmatically sign an authentication token.
After you have a signed IAM authentication token, you can connect to an Aurora DB cluster. Following, you can find out how to do this using either a command line tool or an AWS SDK, such as the AWS SDK for Java or AWS SDK for Python (Boto3).
For more information, see the following blog posts:
+ [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/)
+ [Using IAM authentication to connect with pgAdmin Amazon Aurora PostgreSQL or Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/)
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Topics**
+ [
# Connecting to your DB cluster using IAM authentication with the AWS drivers
](IAMDBAuth.Connecting.Drivers.md)
+ [
# Connecting to your DB cluster using IAM authentication from the command line: AWS CLI and mysql client
](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md)
+ [
# Connecting to your DB cluster using IAM authentication from the command line: AWS CLI and psql client
](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md)
+ [
# Connecting to your DB cluster using IAM authentication and the AWS SDK for .NET
](UsingWithRDS.IAMDBAuth.Connecting.NET.md)
+ [
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Go
](UsingWithRDS.IAMDBAuth.Connecting.Go.md)
+ [
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Java
](UsingWithRDS.IAMDBAuth.Connecting.Java.md)
+ [
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Python (Boto3)
](UsingWithRDS.IAMDBAuth.Connecting.Python.md)
# Connecting to your DB cluster using IAM authentication with the AWS drivers
The AWS suite of drivers has been designed to provide support for faster switchover and failover times, and authentication with AWS Secrets Manager, AWS Identity and Access Management (IAM), and Federated Identity. The AWS drivers rely on monitoring DB cluster status and being aware of the cluster topology to determine the new writer. This approach reduces switchover and failover times to single-digit seconds, compared to tens of seconds for open-source drivers.
For more information on the AWS drivers, see the corresponding language driver for your [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) or [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities) DB cluster.
# Connecting to your DB cluster using IAM authentication from the command line: AWS CLI and mysql client
You can connect from the command line to an Aurora DB cluster with the AWS CLI and `mysql` command line tool as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Note**
For information about connecting to your database using SQL Workbench/J with IAM authentication, see the blog post [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/).
**Topics**
+ [
## Generating an IAM authentication token
](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken)
+ [
## Connecting to a DB cluster
](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect)
## Generating an IAM authentication token
The following example shows how to get a signed authentication token using the AWS CLI.
```
aws rds generate-db-auth-token \
--hostname rdsmysql.123456789012.us-west-2.rds.amazonaws.com \
--port 3306 \
--region us-west-2 \
--username jane_doe
```
In the example, the parameters are as follows:
+ `--hostname` – The host name of the DB cluster that you want to access
+ `--port` – The port number used for connecting to your DB cluster
+ `--region` – The AWS Region where the DB cluster is running
+ `--username` – The database account that you want to access
The first several characters of the token look like the following.
```
rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
## Connecting to a DB cluster
The general format for connecting is shown following.
```
mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken
```
The parameters are as follows:
+ `--host` – The host name of the DB cluster that you want to access
+ `--port` – The port number used for connecting to your DB cluster
+ `--ssl-ca` – The full path to the SSL certificate file that contains the public key
For more information, see [TLS connections to Aurora MySQL DB clusters](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
To download an SSL certificate, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
+ `--enable-cleartext-plugin` – A value that specifies that `AWSAuthenticationPlugin` must be used for this connection
If you are using a MariaDB client, the `--enable-cleartext-plugin` option isn't required.
+ `--user` – The database account that you want to access
+ `--password` – A signed IAM authentication token
The authentication token consists of several hundred characters. It can be unwieldy on the command line. One way to work around this is to save the token to an environment variable, and then use that variable when you connect. The following example shows one way to perform this workaround. In the example, */sample\$1dir/* is the full path to the SSL certificate file that contains the public key.
```
RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN
```
When you connect using `AWSAuthenticationPlugin`, the connection is secured using SSL. To verify this, type the following at the `mysql>` command prompt.
```
show status like 'Ssl%';
```
The following lines in the output show more details.
```
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA |
| ... | ...
| Ssl_version | TLSv1.1 |
| ... | ...
+-----------------------------+
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connecting to your DB cluster using IAM authentication from the command line: AWS CLI and psql client
You can connect from the command line to an Aurora PostgreSQL DB cluster with the AWS CLI and psql command line tool as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Note**
For information about connecting to your database using pgAdmin with IAM authentication, see the blog post [Using IAM authentication to connect with pgAdmin Amazon Aurora PostgreSQL or Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/).
**Topics**
+ [
## Generating an IAM authentication token
](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL)
+ [
## Connecting to an Aurora PostgreSQL cluster
](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## Generating an IAM authentication token
The authentication token consists of several hundred characters so it can be unwieldy on the command line. One way to work around this is to save the token to an environment variable, and then use that variable when you connect. The following example shows how to use the AWS CLI to get a signed authentication token using the `generate-db-auth-token` command, and store it in a `PGPASSWORD` environment variable.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
```
In the example, the parameters to the `generate-db-auth-token` command are as follows:
+ `--hostname` – The host name of the DB cluster (cluster endpoint) that you want to access
+ `--port` – The port number used for connecting to your DB cluster
+ `--region` – The AWS Region where the DB cluster is running
+ `--username` – The database account that you want to access
The first several characters of the generated token look like the following.
```
mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
## Connecting to an Aurora PostgreSQL cluster
The general format for using psql to connect is shown following.
```
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken"
```
The parameters are as follows:
+ `host` – The host name of the DB cluster (cluster endpoint) that you want to access
+ `port` – The port number used for connecting to your DB cluster
+ `sslmode` – The SSL mode to use
When you use `sslmode=verify-full`, the SSL connection verifies the DB cluster endpoint against the endpoint in the SSL certificate.
+ `sslrootcert` – The full path to the SSL certificate file that contains the public key
For more information, see [Securing Aurora PostgreSQL data with SSL/TLS](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL).
To download an SSL certificate, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
+ `dbname` – The database that you want to access
+ `user` – The database account that you want to access
+ `password` – A signed IAM authentication token
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
The following example shows using psql to connect. In the example, psql uses the environment variable `RDSHOST` for the host and the environment variable `PGPASSWORD` for the generated token. Also, */sample\$1dir/* is the full path to the SSL certificate file that contains the public key.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD"
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connecting to your DB cluster using IAM authentication and the AWS SDK for .NET
You can connect to an Aurora MySQL or Aurora PostgreSQL DB cluster with the AWS SDK for .NET as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Examples**
The following code examples show how to generate an authentication token, and then use it to connect to a DB cluster.
To run this code example, you need the [AWS SDK for .NET](http://aws.amazon.com/sdk-for-net/), found on the AWS site. The `AWSSDK.CORE` and the `AWSSDK.RDS` packages are required. To connect to a DB cluster, use the .NET database connector for the DB engine, such as MySqlConnector for MariaDB or MySQL, or Npgsql for PostgreSQL.
This code connects to an Aurora MySQL DB cluster. Modify the values of the following variables as needed:
+ `server` – The endpoint of the DB cluster that you want to access
+ `user` – The database account that you want to access
+ `database` – The database that you want to access
+ `port` – The port number used for connecting to your DB cluster
+ `SslMode` – The SSL mode to use
When you use `SslMode=Required`, the SSL connection verifies the DB cluster endpoint against the endpoint in the SSL certificate.
+ `SslCa` – The full path to the SSL certificate for Amazon Aurora
To download a certificate, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
```
using System;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
using Amazon;
namespace ubuntu
{
class Program
{
static void Main(string[] args)
{
var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate");
conn.Open();
// Define a query
MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn);
// Execute a query
MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader();
// Read all rows and output the first column in each row
while (mysqlDataRdr.Read())
Console.WriteLine(mysqlDataRdr[0]);
mysqlDataRdr.Close();
// Close connection
conn.Close();
}
}
}
```
This code connects to an Aurora PostgreSQL DB cluster.
Modify the values of the following variables as needed:
+ `Server` – The endpoint of the DB cluster that you want to access
+ `User ID` – The database account that you want to access
+ `Database` – The database that you want to access
+ `Port` – The port number used for connecting to your DB cluster
+ `SSL Mode` – The SSL mode to use
When you use `SSL Mode=Required`, the SSL connection verifies the DB cluster endpoint against the endpoint in the SSL certificate.
+ `Root Certificate` – The full path to the SSL certificate for Amazon Aurora
To download a certificate, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
```
using System;
using Npgsql;
using Amazon.RDS.Util;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate");
conn.Open();
// Define a query
NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn);
// Execute a query
NpgsqlDataReader dr = cmd.ExecuteReader();
// Read all rows and output the first column in each row
while (dr.Read())
Console.Write("{0}\n", dr[0]);
// Close connection
conn.Close();
}
}
}
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Go
You can connect to an Aurora MySQL or Aurora PostgreSQL DB cluster with the AWS SDK for Go as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Examples**
To run these code examples, you need the [AWS SDK for Go](http://aws.amazon.com/sdk-for-go/), found on the AWS site.
Modify the values of the following variables as needed:
+ `dbName` – The database that you want to access
+ `dbUser` – The database account that you want to access
+ `dbHost` – The endpoint of the DB cluster that you want to access
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
+ `dbPort` – The port number used for connecting to your DB cluster
+ `region` – The AWS Region where the DB cluster is running
In addition, make sure the imported libraries in the sample code exist on your system.
**Important**
The examples in this section use the following code to provide credentials that access a database from a local environment:
`creds := credentials.NewEnvCredentials()`
If you are accessing a database from an AWS service, such as Amazon EC2 or Amazon ECS, you can replace the code with the following code:
`sess := session.Must(session.NewSession())`
`creds := sess.Config.Credentials`
If you make this change, make sure you add the following import:
`"github.com/aws/aws-sdk-go/aws/session"`
**Topics**
+ [
## Connecting using IAM authentication and the AWS SDK for Go V2
](#UsingWithRDS.IAMDBAuth.Connecting.GoV2)
+ [
## Connecting using IAM authentication and the AWS SDK for Go V1.
](#UsingWithRDS.IAMDBAuth.Connecting.GoV1)
## Connecting using IAM authentication and the AWS SDK for Go V2
You can connect to a DB cluster using IAM authentication and the AWS SDK for Go V2.
The following code examples show how to generate an authentication token, and then use it to connect to a DB cluster.
This code connects to an Aurora MySQL DB cluster.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 3306
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
This code connects to an Aurora PostgreSQL DB cluster.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/lib/pq"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 5432
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authenticationToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
## Connecting using IAM authentication and the AWS SDK for Go V1.
You can connect to a DB cluster using IAM authentication and the AWS SDK for Go V1
The following code examples show how to generate an authentication token, and then use it to connect to a DB cluster.
This code connects to an Aurora MySQL DB cluster.
```
package main
import (
"database/sql"
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/go-sql-driver/mysql"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 3306
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
This code connects to an Aurora PostgreSQL DB cluster.
```
package main
import (
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/lib/pq"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 5432
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Java
You can connect to an Aurora MySQL or Aurora PostgreSQL DB cluster with the AWS SDK for Java as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Set up the AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html)
For examples on how to use the SDK for Java 2.x, see [Amazon RDS examples using SDK for Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html). You can also use the AWS Advanced JDBC Wrapper, see [AWS Advanced JDBC Wrapper documentation](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md).
**Topics**
+ [
## Generating an IAM authentication token
](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken)
+ [
## Manually constructing an IAM authentication token
](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2)
+ [
## Connecting to a DB cluster
](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect)
## Generating an IAM authentication token
If you are writing programs using the AWS SDK for Java, you can get a signed authentication token using the `RdsIamAuthTokenGenerator` class. Using this class requires that you provide AWS credentials. To do this, you create an instance of the `DefaultAWSCredentialsProviderChain` class. `DefaultAWSCredentialsProviderChain` uses the first AWS access key and secret key that it finds in the [default credential provider chain](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). For more information about AWS access keys, see [Managing access keys for users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
After you create an instance of `RdsIamAuthTokenGenerator`, you can call the `getAuthToken` method to obtain a signed token. Provide the AWS Region, host name, port number, and user name. The following code example illustrates how to do this.
```
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
public class GenerateRDSAuthToken {
public static void main(String[] args) {
String region = "us-west-2";
String hostname = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
System.out.println(generateAuthToken(region, hostname, port, username));
}
static String generateAuthToken(String region, String hostName, String port, String username) {
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new DefaultAWSCredentialsProviderChain())
.region(region)
.build();
String authToken = generator.getAuthToken(
GetIamAuthTokenRequest.builder()
.hostname(hostName)
.port(Integer.parseInt(port))
.userName(username)
.build());
return authToken;
}
}
```
## Manually constructing an IAM authentication token
In Java, the easiest way to generate an authentication token is to use `RdsIamAuthTokenGenerator`. This class creates an authentication token for you, and then signs it using AWS signature version 4. For more information, see [Signature version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *AWS General Reference.*
However, you can also construct and sign an authentication token manually, as shown in the following code example.
```
package com.amazonaws.codesamples;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.SigningAlgorithm;
import com.amazonaws.util.BinaryUtils;
import org.apache.commons.lang3.StringUtils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.Charset;
import java.security.MessageDigest;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.SortedMap;
import java.util.TreeMap;
import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR;
import static com.amazonaws.util.StringUtils.UTF8;
public class CreateRDSAuthTokenManually {
public static String httpMethod = "GET";
public static String action = "connect";
public static String canonicalURIParameter = "/";
public static SortedMap canonicalQueryParameters = new TreeMap();
public static String payload = StringUtils.EMPTY;
public static String signedHeader = "host";
public static String algorithm = "AWS4-HMAC-SHA256";
public static String serviceName = "rds-db";
public static String requestWithoutSignature;
public static void main(String[] args) throws Exception {
String region = "us-west-2";
String instanceName = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
Date now = new Date();
String date = new SimpleDateFormat("yyyyMMdd").format(now);
String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'").format(now);
DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
String awsAccessKey = creds.getCredentials().getAWSAccessKeyId();
String awsSecretKey = creds.getCredentials().getAWSSecretKey();
String expiryMinutes = "900";
System.out.println("Step 1: Create a canonical request:");
String canonicalString = createCanonicalString(username, awsAccessKey, date, dateTimeStamp, region, expiryMinutes, instanceName, port);
System.out.println(canonicalString);
System.out.println();
System.out.println("Step 2: Create a string to sign:");
String stringToSign = createStringToSign(dateTimeStamp, canonicalString, awsAccessKey, date, region);
System.out.println(stringToSign);
System.out.println();
System.out.println("Step 3: Calculate the signature:");
String signature = BinaryUtils.toHex(calculateSignature(stringToSign, newSigningKey(awsSecretKey, date, region, serviceName)));
System.out.println(signature);
System.out.println();
System.out.println("Step 4: Add the signing info to the request");
System.out.println(appendSignature(signature));
System.out.println();
}
//Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime should be in format YYYYMMDDTHHMMSSZ
public static String createCanonicalString(String user, String accessKey, String date, String dateTime, String region, String expiryPeriod, String hostName, String port) throws Exception {
canonicalQueryParameters.put("Action", action);
canonicalQueryParameters.put("DBUser", user);
canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256");
canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" + region + "%2F" + serviceName + "%2Faws4_request");
canonicalQueryParameters.put("X-Amz-Date", dateTime);
canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod);
canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader);
String canonicalQueryString = "";
while(!canonicalQueryParameters.isEmpty()) {
String currentQueryParameter = canonicalQueryParameters.firstKey();
String currentQueryParameterValue = canonicalQueryParameters.remove(currentQueryParameter);
canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" + currentQueryParameterValue;
if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) {
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
String hashedPayload = BinaryUtils.toHex(hash(payload));
return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString + '\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload;
}
//Step 2: Create a string to sign using sig v4
public static String createStringToSign(String dateTime, String canonicalRequest, String accessKey, String date, String region) throws Exception {
String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request";
return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' + BinaryUtils.toHex(hash(canonicalRequest));
}
//Step 3: Calculate signature
/**
* Step 3 of the &AWS; Signature version 4 calculation. It involves deriving
* the signing key and computing the signature. Refer to
* http://docs.aws.amazon
* .com/general/latest/gr/sigv4-calculate-signature.html
*/
public static byte[] calculateSignature(String stringToSign,
byte[] signingKey) {
return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey,
SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(byte[] data, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
Mac mac = algorithm.getMac();
mac.init(new SecretKeySpec(key, algorithm.toString()));
return mac.doFinal(data);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
public static byte[] newSigningKey(String secretKey,
String dateStamp, String regionName, String serviceName) {
byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8"));
byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256);
byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256);
byte[] kService = sign(serviceName, kRegion,
SigningAlgorithm.HmacSHA256);
return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(String stringData, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
byte[] data = stringData.getBytes(UTF8);
return sign(data, key, algorithm);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
//Step 4: append the signature
public static String appendSignature(String signature) {
return requestWithoutSignature + "&X-Amz-Signature=" + signature;
}
public static byte[] hash(String s) throws Exception {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(s.getBytes(UTF8));
return md.digest();
} catch (Exception e) {
throw new SdkClientException(
"Unable to compute hash while signing request: "
+ e.getMessage(), e);
}
}
}
```
## Connecting to a DB cluster
The following code example shows how to generate an authentication token, and then use it to connect to a cluster running Aurora MySQL.
To run this code example, you need the [AWS SDK for Java](http://aws.amazon.com/sdk-for-java/), found on the AWS site. In addition, you need the following:
+ MySQL Connector/J. This code example was tested with `mysql-connector-java-5.1.33-bin.jar`.
+ An intermediate certificate for Amazon Aurora that is specific to an AWS Region. (For more information, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).) At runtime, the class loader looks for the certificate in the same directory as this Java code example, so that the class loader can find it.
+ Modify the values of the following variables as needed:
+ `RDS_INSTANCE_HOSTNAME` – The host name of the DB cluster that you want to access.
+ `RDS_INSTANCE_PORT` – The port number used for connecting to your PostgreSQL DB cluster.
+ `REGION_NAME` – The AWS Region where the DB cluster is running.
+ `DB_USER` – The database account that you want to access.
+ `SSL_CERTIFICATE` – An SSL certificate for Amazon Aurora that is specific to an AWS Region.
To download a certificate for your AWS Region, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md). Place the SSL certificate in the same directory as this Java program file, so that the class loader can find the certificate at runtime.
This code example obtains AWS credentials from the [default credential provider chain](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default).
**Note**
Specify a password for `DEFAULT_KEY_STORE_PASSWORD` other than the prompt shown here as a security best practice.
```
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import java.net.URL;
public class IAMDatabaseAuthenticationTester {
//&AWS; Credentials of the IAM user with policy enabling IAM Database Authenticated access to the db by the db user.
private static final DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
private static final String AWS_ACCESS_KEY = creds.getCredentials().getAWSAccessKeyId();
private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey();
//Configuration parameters for the generation of the IAM Database Authentication token
private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
private static final int RDS_INSTANCE_PORT = 3306;
private static final String REGION_NAME = "us-west-2";
private static final String DB_USER = "jane_doe";
private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" + RDS_INSTANCE_PORT;
private static final String SSL_CERTIFICATE = "rds-ca-2019-us-west-2.pem";
private static final String KEY_STORE_TYPE = "JKS";
private static final String KEY_STORE_PROVIDER = "SUN";
private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts";
private static final String KEY_STORE_FILE_SUFFIX = ".jks";
private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit";
public static void main(String[] args) throws Exception {
//get the connection
Connection connection = getDBConnectionUsingIam();
//verify the connection is successful
Statement stmt= connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;");
while (rs.next()) {
String id = rs.getString(1);
System.out.println(id); //Should print "Success!"
}
//close the connection
stmt.close();
connection.close();
clearSslProperties();
}
/**
* This method returns a connection to the db instance authenticated using IAM Database Authentication
* @return
* @throws Exception
*/
private static Connection getDBConnectionUsingIam() throws Exception {
setSslProperties();
return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties());
}
/**
* This method sets the mysql connection properties which includes the IAM Database Authentication token
* as the password. It also specifies that SSL verification is required.
* @return
*/
private static Properties setMySqlConnectionProperties() {
Properties mysqlConnectionProperties = new Properties();
mysqlConnectionProperties.setProperty("verifyServerCertificate","true");
mysqlConnectionProperties.setProperty("useSSL", "true");
mysqlConnectionProperties.setProperty("user",DB_USER);
mysqlConnectionProperties.setProperty("password",generateAuthToken());
return mysqlConnectionProperties;
}
/**
* This method generates the IAM Auth Token.
* An example IAM Auth Token would look like follows:
* btusi123---cmz7kenwo2ye---rds---cn-north-1.amazonaws.com.rproxy.goskope.com.cn:3306/?Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b
* @return
*/
private static String generateAuthToken() {
BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build();
return generator.getAuthToken(GetIamAuthTokenRequest.builder()
.hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build());
}
/**
* This method sets the SSL properties which specify the key store file, its type and password:
* @throws Exception
*/
private static void setSslProperties() throws Exception {
System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile());
System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE);
System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD);
}
/**
* This method returns the path of the Key Store File needed for the SSL verification during the IAM Database Authentication to
* the db instance.
* @return
* @throws Exception
*/
private static String createKeyStoreFile() throws Exception {
return createKeyStoreFile(createCertificate()).getPath();
}
/**
* This method generates the SSL certificate
* @return
* @throws Exception
*/
private static X509Certificate createCertificate() throws Exception {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
URL url = new File(SSL_CERTIFICATE).toURI().toURL();
if (url == null) {
throw new Exception();
}
try (InputStream certInputStream = url.openStream()) {
return (X509Certificate) certFactory.generateCertificate(certInputStream);
}
}
/**
* This method creates the Key Store File
* @param rootX509Certificate - the SSL certificate to be stored in the KeyStore
* @return
* @throws Exception
*/
private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws Exception {
File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX, KEY_STORE_FILE_SUFFIX);
try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) {
KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER);
ks.load(null);
ks.setCertificateEntry("rootCaCertificate", rootX509Certificate);
ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray());
}
return keyStoreFile;
}
/**
* This method clears the SSL properties.
* @throws Exception
*/
private static void clearSslProperties() throws Exception {
System.clearProperty("javax.net.ssl.trustStore");
System.clearProperty("javax.net.ssl.trustStoreType");
System.clearProperty("javax.net.ssl.trustStorePassword");
}
}
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connecting to your DB cluster using IAM authentication and the AWS SDK for Python (Boto3)
You can connect to an Aurora MySQL or Aurora PostgreSQL DB cluster with the AWS SDK for Python (Boto3) as described following.
**Prerequisites**
The following are prerequisites for connecting to your DB cluster using IAM authentication:
+ [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Creating a database account using IAM authentication](UsingWithRDS.IAMDBAuth.DBAccounts.md)
In addition, make sure the imported libraries in the sample code exist on your system.
**Examples**
The code examples use profiles for shared credentials. For information about the specifying credentials, see [Credentials](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html) in the AWS SDK for Python (Boto3) documentation.
The following code examples show how to generate an authentication token, and then use it to connect to a DB cluster.
To run this code example, you need the [AWS SDK for Python (Boto3)](http://aws.amazon.com/sdk-for-python/), found on the AWS site.
Modify the values of the following variables as needed:
+ `ENDPOINT` – The endpoint of the DB cluster that you want to access
+ `PORT` – The port number used for connecting to your DB cluster
+ `USER` – The database account that you want to access
+ `REGION` – The AWS Region where the DB cluster is running
+ `DBNAME` – The database that you want to access
+ `SSLCERTIFICATE` – The full path to the SSL certificate for Amazon Aurora
For `ssl_ca`, specify an SSL certificate. To download an SSL certificate, see [Using SSL/TLS to encrypt a connection to a DB cluster](UsingWithRDS.SSL.md).
**Note**
You cannot use a custom Route 53 DNS record instead of the DB cluster endpoint to generate the authentication token.
This code connects to an Aurora MySQL DB cluster.
Before running this code, install the PyMySQL driver by following the instructions in the [ Python Package Index](https://pypi.org/project/PyMySQL/).
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="3306"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1'
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='default')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True)
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
This code connects to an Aurora PostgreSQL DB cluster.
Before running this code, install `psycopg2` by following the instructions in [Psycopg documentation](https://pypi.org/project/psycopg2/).
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="5432"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='RDSCreds')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE")
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
If you want to connect to a DB cluster through a proxy, see [Connecting to a database using IAM authentication](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Troubleshooting for IAM DB authentication
Following, you can find troubleshooting ideas for some common IAM DB authentication issues and information on CloudWatch logs and metrics for IAM DB authentication.
## Exporting IAM DB authentication error logs to CloudWatch Logs
IAM DB authentication error logs are stored on the database host, and you can export these logs your CloudWatch Logs account. Use the logs and remediation methods in this page to troubleshoot IAM DB authentication issues.
You can enable log exports to CloudWatch Logs from the console, AWS CLI, and RDS API. For console instructions, see [Publishing database logs to Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
To export your IAM DB authentication error logs to CloudWatch Logs when creating a DB cluster from the AWS CLI, use the following command:
```
aws rds create-db-cluster --db-cluster-identifier mydbinstance \
--region us-east-1 \
--engine postgres \
--engine-version 16 \
--master-username master \
--master-user-password password \
--publicly-accessible \
--enable-iam-database-authentication \
--enable-cloudwatch-logs-exports=iam-db-auth-error
```
To export your IAM DB authentication error logs to CloudWatch Logs when modifying a DB clusterfrom the AWS CLI, use the following command:
```
aws rds modify-db-cluster --db-cluster-identifier mydbcluster \
--region us-east-1 \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}'
```
To verify if your DB cluster is exporting IAM DB authentication logs to CloudWatch Logs, check if the `EnabledCloudwatchLogsExports` parameter is set to `iam-db-auth-error` in the output for the `describe-db-instances` command.
```
aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## IAM DB authentication CloudWatch metrics
Amazon Aurora delivers near-real time metrics about IAM DB authentication to your Amazon CloudWatch account. The following table lists the IAM DB authentication metrics available using CloudWatch:
| Metric | Description |
| --- | --- |
| `IamDbAuthConnectionRequests` | Total number of connection requests made with IAM DB authentication. |
| `IamDbAuthConnectionSuccess` | Total number of successful IAM DB authentication requests. |
| `IamDbAuthConnectionFailure` | Total number of failed IAM DB authentication requests. |
| `IamDbAuthConnectionFailureInvalidToken` | Total number of failed IAM DB authentication requests due to invalid token. |
| `IamDbAuthConnectionFailureInsufficientPermissions` | Total number of failed IAM DB authentication requests due to incorrect policies or permissions. |
| `IamDbAuthConnectionFailureThrottling` | Total number of failed IAM DB authentication requests due to IAM DB authentication throttling. |
| `IamDbAuthConnectionFailureServerError` | Total number of failed IAM DB authentication requests due to an internal server error in the IAM DB authentication feature. |
## Common issues and solutions
You might encounter the following issues when using IAM DB authention. Use the remediation steps in the table to solve the issues:
| Error | Metric(s) | Cause | Solution |
| --- | --- | --- | --- |
| `[ERROR] Failed to authenticate the connection request for user db_user because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | The IAM DB authentiation token in the connection request is either not a valid SigV4a token, or it is not formatted correctly. | Check your token generation strategy in your application. In some cases, make sure you are passing the token with valid formatting. Truncating the token (or incorrect string formatting) will make the token invalid. |
| `[ERROR] Failed to authenticate the connection request for user db_user because the token age is longer than 15 minutes. (Status Code: 400, Error Code:ExpiredToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | The IAM DB authentication token has expired. Tokens are only valid for 15 minutes. | Check your token caching and/or token re-use logic in your application. You should not re-use tokens that are older than 15 minutes. |
| `[ERROR] Failed to authorize the connection request for user db_user because the IAM policy assumed by the caller 'arn:aws:sts::123456789012:assumed-role/ / ' is not authorized to perform `rds-db:connect` on the DB instance. (Status Code: 403, Error Code:NotAuthorized)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInsufficientPermissions` | This error might be due to the following reasons: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | Verify that the IAM role and/or policy you are assuming in your application. Make sure you assume the same policy to generate the token as to connect to the DB. |
| `[ERROR] Failed to authorize the connection request for user db_user due to IAM DB authentication throttling. (Status Code: 429, Error Code: ThrottlingException)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | You are making too many connection requests to your DB in a short amount of time. IAM DB authentication throttling limit is 200 connections per second. | Reduce the rate of establishing new connections with IAM authentication. Consider implementing connection pooling using RDS Proxy in order to reuse established connections in your application. |
| `[ERROR] Failed to authorize the connection request for user db_user due to an internal IAM DB authentication error. (Status Code: 500, Error Code: InternalError)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | There was an internal error while authorizing the DB conneciton with IAM DB authentication. | Reach out to https://aws.amazon.com/premiumsupport/ to investigate the issue. |
# Troubleshooting Amazon Aurora identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Aurora and IAM.
**Topics**
+ [
## I'm not authorized to perform an action in Aurora
](#security_iam_troubleshoot-no-permissions)
+ [
## I'm not authorized to perform iam:PassRole
](#security_iam_troubleshoot-passrole)
+ [
## I want to allow people outside of my AWS account to access my Aurora resources
](#security_iam_troubleshoot-cross-account-access)
## I'm not authorized to perform an action in Aurora
If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your sign-in credentials.
The following example error occurs when the `mateojackson` user tries to use the console to view details about a *widget* but does not have `rds:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `rds:GetWidget` action.
## I'm not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your sign-in credentials. Ask that person to update your policies to allow you to pass a role to Aurora.
Some AWS services allow you to pass an existing role to that service, instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when a user named `marymajor` tries to use the console to perform an action in Aurora. However, the action requires the service to have permissions granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary asks her administrator to update her policies to allow her to perform the `iam:PassRole` action.
## I want to allow people outside of my AWS account to access my Aurora resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether Aurora supports these features, see [How Amazon Aurora works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.