# Data protection in MemoryDB
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in . As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Data security in MemoryDB
To help keep your data secure, MemoryDB and Amazon EC2 provide mechanisms to guard against unauthorized access of your data on the server.
MemoryDB also provides encryption features for data on clusters:
+ In-transit encryption encrypts your data whenever it is moving from one place to another, such as between nodes in your cluster or between your cluster and your application.
+ At-rest encryption encrypts the transaction log and your on-disk data during snapshot operations.
You can also use [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md) to control user access to your clusters.
**Topics**
+ [Data security in MemoryDB](encryption.md)
+ [At-Rest Encryption in MemoryDB](at-rest-encryption.md)
+ [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
+ [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md)
+ [Authenticating with IAM](auth-iam.md)
# At-Rest Encryption in MemoryDB
To help keep your data secure, MemoryDB and Amazon S3 provide different ways to restrict access to data in your clusters. For more information, see [MemoryDB and Amazon VPC](vpcs.md) and [Identity and access management in MemoryDB](iam.md).
MemoryDB at-rest encryption is always enabled to increase data security by encrypting persistent data. It encrypts the following aspects:
+ Data in the transaction log
+ Disk during sync, snapshot and swap operations
+ Snapshots stored in Amazon S3
MemoryDB offers default (service managed) encryption at rest, as well as ability to use your own symmetric customer managed customer root keys in [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Data stored on SSDs (solid-state drives) in data-tiering enabled clusters is always encrypted by default.
For information on encryption in transit, see [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
**Topics**
+ [Using Customer Managed Keys from AWS KMS](#using-customer-managed-keys-for-memorydb-security)
+ [See Also](#at-rest-encryption-see-also)
## Using Customer Managed Keys from AWS KMS
MemoryDB supports symmetric customer managed root keys (KMS key) for encryption at rest. Customer-managed KMS keys are encryption keys that you create, own and manage in your AWS account. For more information, see [Customer Root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) in the *AWS Key Management Service Developer Guide*. The keys must be created in AWS KMS before they can be used with MemoryDB.
To learn how to create AWS KMS root keys, see [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
MemoryDB allows you to integrate with AWS KMS. For more information, see [Using Grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide*. No customer action is needed to enable MemoryDB integration with AWS KMS.
The `kms:ViaService` condition key limits use of an AWS KMS key to requests from specified AWS services. To use `kms:ViaService` with MemoryDB, include both ViaService names in the condition key value: `memorydb.amazon_region.amazonaws.com`. For more information, see [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
You can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) to track the requests that MemoryDB sends to AWS Key Management Service on your behalf. All API calls to AWS Key Management Service related to customer managed keys have corresponding CloudTrail logs. You can also see the grants that MemoryDB creates by calling the [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) KMS API call.
Once a cluster is encrypted using a customer managed key, all snapshots for the cluster are encrypted as follows:
+ Automatic daily snapshots are encrypted using the customer managed key associated with the cluster.
+ Final snapshot created when cluster is deleted, is also encrypted using the customer managed key associated with the cluster.
+ Manually created snapshots are encrypted by default to use the KMS key associated with the cluster. You may override this by choosing another customer managed key.
+ Copying a snapshot defaults to using customer managed key associated with the source snapshot. You may override this by choosing another customer managed key.
**Note**
Customer managed keys cannot be used when exporting snapshots to your selected Amazon S3 bucket. However, all snapshots exported to Amazon S3 are encrypted using [Server side encryption.](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) You may choose to copy the snapshot file to a new S3 object and encrypt using a customer managed KMS key, copy the file to another S3 bucket that is set up with default encryption using a KMS key or change an encryption option in the file itself.
You can also use customer managed keys to encrypt manually-created snapshots that do not use customer managed keys for encryption. With this option, the snapshot file stored in Amazon S3 is encrypted using a KMS key, even though the data is not encrypted on the original cluster.
Restoring from a snapshot allows you to choose from available encryption options, similar to encryption choices available when creating a new cluster.
+ If you delete the key or [disable](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) the key and [revoke grants](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) for the key that you used to encrypt a cluster, the cluster becomes irrecoverable. In other words, it cannot be modified or recovered after a hardware failure. AWS KMS deletes root keys only after a waiting period of at least seven days. After the key is deleted, you can use a different customer managed key to create a snapshot for archival purposes.
+ Automatic key rotation preserves the properties of your AWS KMS root keys, so the rotation has no effect on your ability to access your MemoryDB data. Encrypted MemoryDB clusters don't support manual key rotation, which involves creating a new root key and updating any references to the old key. To learn more, see [Rotating Customer root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in the *AWS Key Management Service Developer Guide*.
+ Encrypting a MemoryDB cluster using KMS key requires one grant per cluster. This grant is used throughout the lifespan of the cluster. Additionally, one grant per snapshot is used during snapshot creation. This grant is retired once the snapshot is created.
+ For more information on AWS KMS grants and limits, see [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) in the *AWS Key Management Service Developer Guide*.
## See Also
+ [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
+ [MemoryDB and Amazon VPC](vpcs.md)
+ [Identity and access management in MemoryDB](iam.md)
# In-transit encryption (TLS) in MemoryDB
To help keep your data secure, MemoryDB and Amazon EC2 provide mechanisms to guard against unauthorized access of your data on the server. By providing in-transit encryption capability, MemoryDB gives you a tool you can use to help protect your data when it is moving from one location to another. For example, you might move data from a primary node to a read replica node within a cluster, or between your cluster and your application.
**Topics**
+ [In-transit encryption overview](#in-transit-encryption-overview)
+ [See also](#in-transit-encryption-see-also)
## In-transit encryption overview
MemoryDB in-transit encryption is a feature that increases the security of your data at its most vulnerable points—when it is in transit from one location to another.
MemoryDB in-transit encryption implements the following features:
+ **Encrypted connections**—both the server and client connections are Transport Layer Security (TLS) encrypted.
+ **Encrypted replication—**data moving between a primary node and replica nodes is encrypted.
+ **Server authentication**—clients can authenticate that they are connecting to the right server.
From 07/20/2023, TLS 1.2 is the minimum supported version for new and existing clusters. Use this [link](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) to learn more about TLS 1.2 at AWS.
For more information on connecting to MemoryDB clusters, see [Connecting to MemoryDB nodes using redis-cli](getting-started.md#connect-tls).
## See also
+ [At-Rest Encryption in MemoryDB](at-rest-encryption.md)
+ [Authenticating Users with Access Control Lists (ACLs)](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB and Amazon VPC](vpcs.md)
+ [Identity and access management in MemoryDB](iam.md)
# Authenticating users with Access Control Lists (ACLs)
You can authenticate users with Access control lists (ACLs).
ACLs enable you to control cluster access by grouping users. These Access control lists are designed as a way to organize access to clusters.
With ACLs, you create users and assign them specific permissions by using an access string, as described in the next section. You assign the users to Access control lists aligned with a specific role (administrators, human resources) that are then deployed to one or more MemoryDB clusters. By doing this, you can establish security boundaries between clients using the same MemoryDB cluster or clusters and prevent clients from accessing each other’s data.
ACLs are designed to support the introduction of [ACL](https://valkey.io/docs/topics/acl/) in Redis OSS 6. When you use ACLs with your MemoryDB cluster, there are some limitations:
+ You can't specify passwords in an access string. You set passwords with [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) or [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) calls.
+ For user rights, you pass `on` and `off` as a part of the access string. If neither is specified in the access string, the user is assigned `off` and doesn't have access rights to the cluster.
+ You can't use forbidden commands. If you specify a forbidden command, an exception will be thrown. For a list of those commands, see [Restricted commands](restrictedcommands.md).
+ You can't use the `reset` command as a part of an access string. You specify passwords with API parameters, and MemoryDB manages passwords. Thus, you can't use `reset` because it would remove all passwords for a user.
+ Redis OSS 6 introduces the [ACL LIST](https://valkey.io/commands/acl-list) command. This command returns a list of users along with the ACL rules applied to each user. MemoryDB supports the `ACL LIST` command, but does not include support for password hashes as Redis OSS does. With MemoryDB, you can use the [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) operation to get similar information, including the rules contained within the access string. However, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) doesn't retrieve a user password.
Other read-only commands supported by MemoryDB include [ACL WHOAMI](https://valkey.io/commands/acl-whoami), [ACL USERS](https://valkey.io/commands/acl-users), and [ACL CAT](https://valkey.io/commands/acl-cat). MemoryDB doesn't support any other write-based ACL commands.
Using ACLs with MemoryDB is described in more detail following.
**Topics**
+ [Specifying Permissions Using an Access String](#access-string)
+ [Vector search capabilities](#access-vss)
+ [Applying ACLs to a cluster for MemoryDB](#rbac-using)
## Specifying Permissions Using an Access String
To specify permissions to a MemoryDB cluster, you create an access string and assign it to a user, using either the AWS CLI or AWS Management Console.
Access strings are defined as a list of space-delimited rules which are applied on the user. They define which commands a user can execute and which keys a user can operate on. In order to execute a command, a user must have access to the command being executed and all keys being accessed by the command. Rules are applied from left to right cumulatively, and a simpler string may be used instead of the one provided if there is redundancies in the string provided.
For information about the syntax of the ACL rules, see [ACL](https://valkey.io/topics/acl).
In the following example, the access string represents an active user with access to all available keys and commands.
`on ~* &* +@all`
The access string syntax is broken down as follows:
+ `on` – The user is an active user.
+ `~*` – Access is given to all available keys.
+ `&*` – Access is given to all pubsub channels.
+ `+@all` – Access is given to all available commands.
The preceding settings are the least restrictive. You can modify these settings to make them more secure.
In the following example, the access string represents a user with access restricted to read access on keys that start with “app::” keyspace
`on ~app::* -@all +@read`
You can refine these permissions further by listing commands the user has access to:
`+command1` – The user's access to commands is limited to *`command1`*.
`+@category` – The user's access is limited to a category of commands.
For information on assigning an access string to a user, see [Creating Users and Access Control Lists with the Console and CLI](#users-management).
If you are migrating an existing workload to MemoryDB, you can retrieve the access string by calling `ACL LIST`, excluding the user and any password hashes.
## Vector search capabilities
For [Vector search](vector-search.md), all search commands belong to the `@search` category and existing categories `@read`, `@write`, `@fast` and `@slow` are updated to include search commands. If a user does not have access to a category, then the user does not have access to any commands within the category. For example, if the user does not have access to `@search`, then the user cannot execute any search related command.
The following table indicates the mapping of search commands to the appropriate categories.
| VSS Commands | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | Y | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | Y | |
## Applying ACLs to a cluster for MemoryDB
To use MemoryDB ACLs, you take the following steps:
1. Create one or more users.
1. Create an ACL and add users to the list.
1. Assign the ACL to a cluster.
These steps are described in detail following.
**Topics**
+ [Creating Users and Access Control Lists with the Console and CLI](#users-management)
+ [Managing Access Control Lists with the Console and CLI](#user-groups)
+ [Assigning Access control lists to clusters](#users-groups-to-clusterss)
### Creating Users and Access Control Lists with the Console and CLI
The user information for ACLs users is a user name, and optionally a password and an access string. The access string provides the permission level on keys and commands. The name is unique to the user and is what is passed to the engine.
Make sure that the user permissions you provide make sense with the intended purpose of the ACL. For example, if you create an ACL called `Administrators`, any user you add to that group should have its access string set to full access to keys and commands. For users in an `e-commerce` ACL, you might set their access strings to read-only access.
MemoryDB automatically configures a default user per account with a user name `"default"`. It will not be associated with any cluster unless explicity added to an ACL. You can't modify or delete this user. This user is intended for compatibility with the default behavior of previous Redis OSS versions and has an access string that permits it to call all commands and access all keys.
An immutable “open-access” ACL will be created for every account which contains the default user. This is the only ACL the default user can be a member of. When you create a cluster, you must select an ACL to associate with the cluster. While you do have the option to apply the "open-access" ACL with the default user, we highly recommend creating an ACL with users that have permissions restricted to their business needs.
Clusters that do not have TLS enabled must use the "open-access" ACL to provide open authentication.
ACLs can be created with no users. An empty ACL would have no access to a cluster and can only be associated with TLS-enabled clusters.
When creating a user, you can set up to two passwords. When you modify a password, any existing connections to clusters are maintained.
In particular, be aware of these user password constraints when using ACLs for MemoryDB:
+ Passwords must be 16–128 printable characters.
+ The following nonalphanumeric characters are not allowed: `,` `""` `/` `@`.
#### Managing Users with the Console and CLI
##### Creating a user (Console)
**To create users on the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On the left navigation pane, choose **Users**.
1. Choose **Create user**
1. On the **Create user** page, enter a **Name**.
Cluster naming constraints are as follows:
+ Must contain 1–40 alphanumeric characters or hyphens.
+ Must begin with a letter.
+ Can't contain two consecutive hyphens.
+ Can't end with a hyphen.
1. Under **Passwords**, you can enter up to two passwords.
1. Under **Access string**, enter an access string. The access string sets the permission level for what keys and commands the user is allowed.
1. For **Tags**, you can optionally apply tags to search and filter your users or track your AWS costs.
1. Choose **Create**.
##### Creating a user using the AWS CLI
**To create a user by using the CLI**
+ Use the [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) command to create a user.
For Linux, macOS, or Unix:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
For Windows:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modifying a user (Console)
**To modify users on the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On the left navigation pane, choose **Users**.
1. Choose the radio button next to the user you want to modify and then choose **Actions**->**Modify**
1. If you want to modify a password, choose the **Modify passwords** radio button. Note that if you have two passwords, you must enter both when modifying one of them.
1. If you are updating the access string, enter the new one.
1. Choose **Modify**.
##### Modifying a user using AWS CLI
**To modify a user by using the CLI**
1. Use the [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) command to modify a user.
1. When a user is modified, the Access control lists associated with the user are updated, along with any clusters associated with the ACL. All existing connections are maintained. The following are examples.
For Linux, macOS, or Unix:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
For Windows:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Viewing user details (Console)
**To view user details on the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On the left navigation pane, choose **Users**.
1. Choose the user under **User name** or use the search box to find the user.
1. Under **User settings** you can review the user's access string, password count, status and Amazon Resource Name (ARN).
1. Under **Access control lists (ACL)** you can review the ACL the user belongs to.
1. Under **Tags** you can review any tags associated with the user.
##### Viewing user details using the AWS CLI
Use the [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) command to view details of a user.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Deleting a user (Console)
**To delete users on the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On the left navigation pane, choose **Users**.
1. Choose the radio button next to the user you want to modify and then choose **Actions**->**Delete**
1. To confirm, enter `delete` in the confirmation text box and then choose **Delete**.
1. To cancel, choose **Cancel**.
##### Deleting a user using the AWS CLI
**To delete a user by using the CLI**
+ Use the [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) command to delete a user.
The account is deleted and removed from any Access control lists to which it belongs. The following is an example.
For Linux, macOS, or Unix:
```
aws memorydb delete-user \
--user-name user-name-2
```
For Windows:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Managing Access Control Lists with the Console and CLI
You can create Access control lists to organize and control access of users to one or more clusters, as shown following.
Use the following procedure to manage Access control lists using the console.
#### Creating an Access Control List (ACL) (Console)
**To create an Access control list using the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose **Create ACL**.
1. On the **Create access control list (ACL)** page, enter an ACL name.
Cluster naming constraints are as follows:
+ Must contain 1–40 alphanumeric characters or hyphens.
+ Must begin with a letter.
+ Can't contain two consecutive hyphens.
+ Can't end with a hyphen.
1. Under **Selected users** do one of the following:
1. Create a new user by choosing **Create user**
1. Add users by choosing **Manage** and then selecting users from the **Manage users** dialog and then selecting **Choose**.
1. For **Tags**, you can optionally apply tags to search and filter your ACLs or track your AWS costs.
1. Choose **Create**.
#### Creating an Access Control List (ACL) using the AWS CLI
Use the following procedures to create an Access control list using the CLI.
**To create a new ACL and add a user by using the CLI**
+ Use the [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) command to create an ACL.
For Linux, macOS, or Unix:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
For Windows:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modifying an Access Control List (ACL) (console)
**To modify an Access control lists using the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL you wish to modify and then choose **Modify**
1. On the **Modify** page, under **Selected users** do one of the following:
1. Create a new user by choosing **Create user** to add to the ACL.
1. Add or remove users by choosing **Manage** and then selecting or de-selecting users from the **Manage users** dialog and then selecting **Choose**.
1. On the **Create access control list (ACL)** page, enter an ACL name.
Cluster naming constraints are as follows:
+ Must contain 1–40 alphanumeric characters or hyphens.
+ Must begin with a letter.
+ Can't contain two consecutive hyphens.
+ Can't end with a hyphen.
1. Under **Selected users** do one of the following:
1. Create a new user by choosing **Create user**
1. Add users by choosing **Manage** and then selecting users from the **Manage users** dialog and then selecting **Choose**.
1. Choose **Modify** to save your changes or **Cancel** to discard them.
#### Modifying an Access Control List (ACL) using the AWS CLI
**To modify a ACL by adding new users or removing current members by using the CLI**
+ Use the [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) command to modfy an ACL.
For Linux, macOS, or Unix:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
For Windows:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**Note**
Any open connections belonging to a user removed from an ACL are ended by this command.
#### Viewing Access Control List (ACL) details (Console)
**To view ACL details on the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On the left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL under **ACL name** or use the search box to find the ACL.
1. Under **Users** you can review list of users associated with the ACL.
1. Under **Associated clusters** you can review the cluster the ACL belongs to.
1. Under **Tags** you can review any tags associated with the ACL.
#### Viewing Access Control Lists (ACL) using the AWS CLI
Use the [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) command to view details of an ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Deleting an Access Control List (ACL) (console)
**To delete Access control lists using the console**
1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/).
1. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL you wish to modify and then choose **Delete**
1. On the **Delete** page, enter `delete` in the confirmation box and choose **Delete** or **Cancel** to avoid deleting the ACL.
The ACL itself, not the users belonging to the group, is deleted.
#### Deleting an Access Control List (ACL) using the AWS CLI
**To delete an ACL by using the CLI**
+ Use the [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) command to delete an ACL.
For Linux, macOS, or Unix:
```
aws memorydb delete-acl /
--acl-name
```
For Windows:
```
aws memorydb delete-acl ^
--acl-name
```
The preceding examples return the following response.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Assigning Access control lists to clusters
After you have created an ACL and added users, the final step in implementing ACLs is assigning the ACL to a cluster.
#### Assigning Access control lists to clusters Using the Console
To add an ACL to a cluster using the AWS Management Console, see [Creating a MemoryDB cluster](getting-started.md#clusters.create).
#### Assigning Access control lists to clusters Using the AWS CLI
The following AWS CLI operation creates a cluster with encryption in transit (TLS) enabled and the **acl-name** parameter with the value `my-acl-name`. Replace the subnet group `subnet-group` with a subnet group that exists.
**Key Parameters**
+ **--engine-version** – Must be 6.2.
+ **--tls-enabled** – Used for authentication and for associating an ACL.
+ **--acl-name** – This value provides Access control lists comprised of users with specified access permissions for the cluster.
For Linux, macOS, or Unix:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
For Windows:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
The following AWS CLI operation modifies a cluster with encryption in transit (TLS) enabled and the **acl-name** parameter with the value `new-acl-2`.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Authenticating with IAM
**Topics**
+ [Overview](#auth-iam-overview)
+ [Limitations](#auth-iam-limits)
+ [Setup](#auth-iam-setup)
+ [Connecting](#auth-iam-Connecting)
## Overview
With IAM Authentication you can authenticate a connection to MemoryDB using AWS IAM identities, when your cluster is configured to use Valkey or Redis OSS version 7 or above. This allows you to strengthen your security model and simplify many administrative security tasks. With IAM Authentication you can configure fine-grained access control for each individual MemoryDB cluster and MemoryDB user and follow least-privilege permissions principles. IAM Authentication for MemoryDB works by providing a short-lived IAM authentication token instead of a long-lived MemoryDB user password in the `AUTH` or `HELLO` command. For more information about the IAM authentication token, refer to the [Signature Version 4 signing process](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) in the the AWS General Reference Guide and the code example below.
You can use IAM identities and their associated policies to further restrict Valkey or Redis OSS access. You can also grant access to users from their federated Identity providers directly to MemoryDB clusters.
To use AWS IAM with MemoryDB, you first need to create a MemoryDB user with authentication mode set to IAM, then you can create or reuse an IAM identity. The IAM identity needs an associated policy to grant the `memorydb:Connect` action to the MemoryDB cluster and MemoryDB user. Once configured, you can create an IAM authentication token using the AWS credentials of the IAM user or role. Finally you need to provide the short-lived IAM authentication token as a password in your Valkey or Redis OSS client when connecting to your MemoryDB cluster node. A client with support for credentials provider can auto-generate the temporary credentials automatically for each new connection. MemoryDB will perform IAM authentication for connection requests of IAM-enabled MemoryDB users and will validate the connection requests with IAM.
## Limitations
When using IAM authentication, the following limitations apply:
+ IAM authentication is available when using Valkey or Redis OSS engine version 7.0 or above.
+ The IAM authentication token is valid for 15 minutes. For long-lived connections, we recommend using a Redis OSS client that supports a credentials provider interface.
+ An IAM authenticated connection to MemoryDB will automatically be disconnected after 12 hours. The connection can be prolonged for 12 hours by sending an `AUTH` or `HELLO` command with a new IAM authentication token.
+ IAM authentication is not supported in `MULTI EXEC` commands.
+ Currently, IAM 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.
## Setup
To setup IAM authentication:
1. Create a cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Create an IAM trust policy document, as shown below, for your role that allows your account to assume the new role. Save the policy to a file named *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Create an IAM policy document, as shown below. Save the policy to a file named *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Create an IAM role.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Create the IAM policy.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Attach the IAM policy to the role.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Create a new IAM-enabled user.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Create an ACL and attach the user.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Connecting
**Connect with token as password**
You first need to generate the short-lived IAM authentication token using an [AWS SigV4 pre-signed request](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). After that you provide the IAM authentication token as a password when connecting to a MemoryDB cluster, as shown in the example below.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Below is the definition for `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Connect with credentials provider**
The code below shows how to authenticate with MemoryDB using the IAM authentication credentials provider.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Below is an example of a Lettuce cluster client that wraps the IAMAuthTokenRequest in a credentials provider to auto-generate temporary credentials when needed.
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```