# Security in Amazon Keyspaces (for Apache Cassandra)
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Amazon Keyspaces, see [AWS Services in scope by compliance program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations.
This documentation will help you understand how to apply the shared responsibility model when using Amazon Keyspaces. The following topics show you how to configure Amazon Keyspaces to meet your security and compliance objectives. You'll also learn how to use other AWS services that can help you to monitor and secure your Amazon Keyspaces resources.
**Topics**
+ [
# Data protection in Amazon Keyspaces
](data-protection.md)
+ [
# AWS Identity and Access Management for Amazon Keyspaces
](security-iam.md)
+ [
# Compliance validation for Amazon Keyspaces (for Apache Cassandra)
](Keyspaces-compliance.md)
+ [
# Resilience and disaster recovery in Amazon Keyspaces
](disaster-recovery-resiliency.md)
+ [
# Infrastructure security in Amazon Keyspaces
](infrastructure-security.md)
+ [
# Configuration and vulnerability analysis for Amazon Keyspaces
](configuration-vulnerability.md)
+ [
# Security best practices for Amazon Keyspaces
](best-practices-security.md)
# Data protection in Amazon Keyspaces
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Keyspaces (for Apache Cassandra). 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 Amazon Keyspaces 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.
**Topics**
+ [
# Encryption at rest in Amazon Keyspaces
](EncryptionAtRest.md)
+ [
# Encryption in transit in Amazon Keyspaces
](encryption-in-transit.md)
+ [
# Internetwork traffic privacy in Amazon Keyspaces
](inter-network-traffic-privacy.md)
# Encryption at rest in Amazon Keyspaces
Amazon Keyspaces (for Apache Cassandra) *encryption at rest* provides enhanced security by encrypting all your data at rest using encryption keys stored in [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/). This functionality helps reduce the operational burden and complexity involved in protecting sensitive data. With encryption at rest, you can build security-sensitive applications that meet strict compliance and regulatory requirements for data protection.
Amazon Keyspaces encryption at rest encrypts your data using 256-bit Advanced Encryption Standard (AES-256). This helps secure your data from unauthorized access to the underlying storage.
Amazon Keyspaces encrypts and decrypts the data in tables and streams transparently. Amazon Keyspaces uses envelope encryption and a key hierarchy to protect data encryption keys. It integrates with AWS KMS for storing and managing the root encryption key. For more information about the encryption key hierarchy, see [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md). For more information about AWS KMS concepts like envelope encryption, see [AWS KMS management service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) in the *AWS Key Management Service Developer Guide*.
When creating a new table, you can choose one of the following *AWS KMS keys (KMS keys)*:
+ AWS owned key – This is the default encryption type. The key is owned by Amazon Keyspaces (no additional charge).
+ Customer managed key – This key is stored in your account and is created, owned, and managed by you. You have full control over the customer managed key (AWS KMS charges apply).
Amazon Keyspaces automatically encrypts change data capture (CDC) streams with the same key as the underlying table. For more information about CDC, see [Working with change data capture (CDC) streams in Amazon Keyspaces](cdc.md).
You can switch between the AWS owned key and the customer managed key at any given time. You can specify a customer managed key when you create a new table or change the KMS key of an existing table by using the console or programmatically using CQL statements. To learn how, see [Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces](encryption.customermanaged.md).
Encryption at rest using the default option of AWS owned keys is offered at no additional charge. However, AWS KMS charges apply for customer managed keys. For more information about pricing, see [AWS KMS pricing](https://aws.amazon.com/kms/pricing).
Amazon Keyspaces encryption at rest is available in all AWS Regions, including the AWS China (Beijing) and AWS China (Ningxia) Regions. For more information, see [Encryption at rest: How it works in Amazon Keyspaces](encryption.howitworks.md).
**Topics**
+ [
# Encryption at rest: How it works in Amazon Keyspaces
](encryption.howitworks.md)
+ [
# Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces
](encryption.customermanaged.md)
# Encryption at rest: How it works in Amazon Keyspaces
Amazon Keyspaces (for Apache Cassandra) *encryption at rest* encrypts your data using the 256-bit Advanced Encryption Standard (AES-256). This helps secure your data from unauthorized access to the underlying storage. All customer data in Amazon Keyspaces tables is encrypted at rest by default, and server-side encryption is transparent, which means that changes to applications aren't required.
Encryption at rest integrates with AWS Key Management Service (AWS KMS) for managing the encryption key that is used to encrypt your tables. When creating a new table or updating an existing table, you can choose one of the following *AWS KMS key* options:
+ AWS owned key – This is the default encryption type. The key is owned by Amazon Keyspaces (no additional charge).
+ Customer managed key – This key is stored in your account and is created, owned, and managed by you. You have full control over the customer managed key (AWS KMS charges apply).
**AWS KMS key (KMS key)**
Encryption at rest protects all your Amazon Keyspaces data with a AWS KMS key. By default, Amazon Keyspaces uses an [AWS owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), a multi-tenant encryption key that is created and managed in an Amazon Keyspaces service account.
However, you can encrypt your Amazon Keyspaces tables using a [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in your AWS account. You can select a different KMS key for each table in a keyspace. The KMS key you select for a table is also used to encrypt all its metadata and restorable backups.
You select the KMS key for a table when you create or update the table. You can change the KMS key for a table at any time, either in the Amazon Keyspaces console or by using the [ALTER TABLE](cql.ddl.keyspace.md#cql.ddl.keyspace.alter) statement. The process of switching KMS keys is seamless, and doesn't require downtime or cause service degradation.
**Key hierarchy**
Amazon Keyspaces uses a key hierarchy to encrypt data. In this key hierarchy, the KMS key is the root key. It's used to encrypt and decrypt the Amazon Keyspaces table encryption key. The table encryption key is used to encrypt the encryption keys used internally by Amazon Keyspaces to encrypt and decrypt data when performing read and write operations.
With the encryption key hierarchy, you can make changes to the KMS key without having to reencrypt data or impacting applications and ongoing data operations.
![\[Key hierarchy showing the root key, the table encryption key, and the data encryption key used for encryption at rest.\]](http://docs.aws.amazon.com/keyspaces/latest/devguide/images/keyspaces_encryption.png)
**Table key**
The Amazon Keyspaces table key is used as a key encryption key. Amazon Keyspaces uses the table key to protect the internal data encryption keys that are used to encrypt the data stored in tables, log files, and restorable backups. Amazon Keyspaces generates a unique data encryption key for each underlying structure in a table. However, multiple table rows might be protected by the same data encryption key.
When you first set the KMS key to a customer managed key, AWS KMS generates a *data key*. The AWS KMS data key refers to the table key in Amazon Keyspaces.
When you access an encrypted table, Amazon Keyspaces sends a request to AWS KMS to use the KMS key to decrypt the table key. Then, it uses the plaintext table key to decrypt the Amazon Keyspaces data encryption keys, and it uses the plaintext data encryption keys to decrypt table data.
Amazon Keyspaces uses and stores the table key and data encryption keys outside of AWS KMS. It protects all keys with [Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) (AES) encryption and 256-bit encryption keys. Then, it stores the encrypted keys with the encrypted data so that they're available to decrypt the table data on demand.
**Table key caching**
To avoid calling AWS KMS for every Amazon Keyspaces operation, Amazon Keyspaces caches the plaintext table keys for each connection in memory. If Amazon Keyspaces gets a request for the cached table key after five minutes of inactivity, it sends a new request to AWS KMS to decrypt the table key. This call captures any changes made to the access policies of the KMS key in AWS KMS or AWS Identity and Access Management (IAM) since the last request to decrypt the table key.
**Envelope encryption**
If you change the customer managed key for your table, Amazon Keyspaces generates a new table key. Then, it uses the new table key to reencrypt the data encryption keys. It also uses the new table key to encrypt previous table keys that are used to protect restorable backups. This process is called envelope encryption. This ensures that you can access restorable backups even if you rotate the customer managed key. For more information about envelope encryption, see [Envelope Encryption](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) in the *AWS Key Management Service Developer Guide*.
**Topics**
+ [
## AWS owned keys
](#keyspaces-owned)
+ [
## Customer managed keys
](#customer-managed)
+ [
## Encryption at rest usage notes
](#encryption.usagenotes)
## AWS owned keys
AWS owned keys aren't stored in your AWS account. They are part of a collection of KMS keys that AWS owns and manages for use in multiple AWS accounts. AWS services can use AWS owned keys to protect your data.
You can't view, manage, or use AWS owned keys, or audit their use. However, you don't need to do any work or change any programs to protect the keys that encrypt your data.
You aren't charged a monthly fee or a usage fee for use of AWS owned keys, and they don't count against AWS KMS quotas for your account.
## Customer managed keys
Customer managed keys are keys in your AWS account that you create, own, and manage. You have full control over these KMS keys.
Use a customer managed key to get the following features:
+ You create and manage the customer managed key, including setting and maintaining the [key policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html), [IAM policies](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html), and [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) to control access to the customer managed key. You can [enable and disable](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) the customer managed key, enable and disable [automatic key rotation](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html), and [schedule the customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html) for deletion when it is no longer in use. You can create tags and aliases for the customer managed keys you manage.
+ You can use a customer managed key with [imported key material](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html) or a customer managed key in a [custom key store](https://docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html) that you own and manage.
+ You can use AWS CloudTrail and Amazon CloudWatch Logs to track the requests that Amazon Keyspaces sends to AWS KMS on your behalf. For more information, see [Step 6: Configure monitoring with AWS CloudTrail](encryption.customermanaged.md#encryption-cmk-trail).
Customer managed keys [incur a charge](https://aws.amazon.com/kms/pricing/) for each API call, and AWS KMS quotas apply to these KMS keys. For more information, see [AWS KMS resource or request quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html).
When you specify a customer managed key as the root encryption key for a table, restorable backups are encrypted with the same encryption key that is specified for the table at the time the backup is created. If the KMS key for the table is rotated, key enveloping ensures that the latest KMS key has access to all restorable backups.
Amazon Keyspaces must have access to your customer managed key to provide you access to your table data. If the state of the encryption key is set to disabled or it's scheduled for deletion, Amazon Keyspaces is unable to encrypt or decrypt data. As a result, you are not able to perform read and write operations on the table. As soon as the service detects that your encryption key is inaccessible, Amazon Keyspaces sends an email notification to alert you.
You must restore access to your encryption key within seven days or Amazon Keyspaces deletes your table automatically. As a precaution, Amazon Keyspaces creates a restorable backup of your table data before deleting the table. Amazon Keyspaces maintains the restorable backup for 35 days. After 35 days, you can no longer restore your table data. You aren't billed for the restorable backup, but standard [restore charges apply](https://aws.amazon.com/keyspaces/pricing).
You can use this restorable backup to restore your data to a new table. To initiate the restore, the last customer managed key used for the table must be enabled, and Amazon Keyspaces must have access to it.
**Note**
When you're creating a table that's encrypted using a customer managed key that's inaccessible or scheduled for deletion before the creation process completes, an error occurs. The create table operation fails, and you're sent an email notification.
## Encryption at rest usage notes
Consider the following when you're using encryption at rest in Amazon Keyspaces.
+ Server-side encryption at rest is enabled on all Amazon Keyspaces tables and can't be disabled. The entire table is encrypted at rest, you can't select specific columns or rows for encryption.
+ By default, Amazon Keyspaces uses a single-service default key (AWS owned key) for encrypting all of your tables. If this key doesn’t exist, it's created for you. Service default keys can't be disabled.
+ Encryption at rest only encrypts data while it's static (at rest) on a persistent storage media. If data security is a concern for data in transit or data in use, you must take additional measures:
+ Data in transit: All your data in Amazon Keyspaces is encrypted in transit. By default, communications to and from Amazon Keyspaces are protected by using Secure Sockets Layer (SSL)/Transport Layer Security (TLS) encryption.
+ Data in use: Protect your data before sending it to Amazon Keyspaces by using client-side encryption.
+ Customer managed keys: Data at rest in your tables is always encrypted using your customer managed keys. However operations that perform atomic updates of multiple rows encrypt data temporarily using AWS owned keys during processing. This includes range delete operations and operations that simultaneously access static and non-static data.
+ A single customer managed key can have up to 50,000 [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html). Every Amazon Keyspaces table associated with a customer managed key consumes 2 grants. One grant is released when the table is deleted. The second grant is used to create an automatic snapshot of the table to protect from data loss in case Amazon Keyspaces lost access to the customer managed key unintentionally. This grant is released 42 days after deletion of the table.
# Encryption at rest: How to use customer managed keys to encrypt tables in Amazon Keyspaces
You can use the console or CQL statements to specify the AWS KMS key for new tables and update the encryption keys of existing tables in Amazon Keyspaces. The following topic outlines how to implement customer managed keys for new and existing tables.
**Topics**
+ [
## Prerequisites: Create a customer managed key using AWS KMS and grant permissions to Amazon Keyspaces
](#encryption.createCMKMS)
+ [
## Step 3: Specify a customer managed key for a new table
](#encryption.tutorial-creating)
+ [
## Step 4: Update the encryption key of an existing table
](#encryption.tutorial-update)
+ [
## Step 5: Use the Amazon Keyspaces encryption context in logs
](#encryption-context)
+ [
## Step 6: Configure monitoring with AWS CloudTrail
](#encryption-cmk-trail)
## Prerequisites: Create a customer managed key using AWS KMS and grant permissions to Amazon Keyspaces
Before you can protect an Amazon Keyspaces table with a [customer managed key](encryption.howitworks.md#customer-managed), you must first create the key in AWS Key Management Service (AWS KMS) and then authorize Amazon Keyspaces to use that key.
### Step 1: Create a customer managed key using AWS KMS
To create a customer managed key to be used to protect an Amazon Keyspaces table, you can follow the steps in [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) using the console or the AWS API.
### Step 2: Authorize the use of your customer managed key
Before you can choose a [customer managed key](encryption.howitworks.md#customer-managed) to protect an Amazon Keyspaces table, the policies on that customer managed key must give Amazon Keyspaces permission to use it on your behalf. You have full control over the policies and grants on the customer managed key. You can provide these permissions in a [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html), an [IAM policy](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html), or a [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html).
Amazon Keyspaces doesn't need additional authorization to use the default [AWS owned key](encryption.howitworks.md#keyspaces-owned) to protect the Amazon Keyspaces tables in your AWS account.
The following topics show how to configure the required permissions using IAM policies and grants that allow Amazon Keyspaces tables to use a customer managed key.
**Topics**
+ [
#### Key policy for customer managed keys
](#encryption-customer-managed-policy)
+ [
#### Example key policy
](#encryption-customer-managed-policy-sample)
+ [
#### Using grants to authorize Amazon Keyspaces
](#encryption-grants)
#### Key policy for customer managed keys
When you select a [customer managed key](encryption.howitworks.md#customer-managed) to protect an Amazon Keyspaces table, Amazon Keyspaces gets permission to use the customer managed key on behalf of the principal who makes the selection. That principal, a user or role, must have the permissions on the customer managed key that Amazon Keyspaces requires.
At a minimum, Amazon Keyspaces requires the following permissions on a customer managed key:
+ [kms:Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html)
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
+ [kms:ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html)\$1 (for kms:ReEncryptFrom and kms:ReEncryptTo)
+ kms:GenerateDataKey\$1 (for [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [kms:GenerateDataKeyWithoutPlaintext](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext.html))
+ [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)
+ [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)
#### Example key policy
For example, the following example key policy provides only the required permissions. The policy has the following effects:
+ Allows Amazon Keyspaces to use the customer managed key in cryptographic operations and create grants—but only when it's acting on behalf of principals in the account who have permission to use Amazon Keyspaces. If the principals specified in the policy statement don't have permission to use Amazon Keyspaces, the call fails, even when it comes from the Amazon Keyspaces service.
+ The [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) condition key allows the permissions only when the request comes from Amazon Keyspaces on behalf of the principals listed in the policy statement. These principals can't call these operations directly. Note that the `kms:ViaService` value, `cassandra.*.amazonaws.com`, has an asterisk (\$1) in the Region position. Amazon Keyspaces requires the permission to be independent of any particular AWS Region.
+ Gives the customer managed key administrators (users who can assume the `db-team` role) read-only access to the customer managed key and permission to revoke grants, including the [grants that Amazon Keyspaces requires](#encryption-grants) to protect the table.
+ Gives Amazon Keyspaces read-only access to the customer managed key. In this case, Amazon Keyspaces can call these operations directly. It doesn't have to act on behalf of an account principal.
Before using an example key policy, replace the example principals with actual principals from your AWS account.
```
{
"Id": "key-policy-cassandra",
"Version":"2012-10-17",
"Statement": [
{
"Sid" : "Allow access through Amazon Keyspaces for all principals in the account that are authorized to use Amazon Keyspaces",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:user/db-lead"},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService" : "cassandra.*.amazonaws.com"
}
}
},
{
"Sid": "Allow administrators to view the customer managed key and revoke grants",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/db-team"
},
"Action": [
"kms:Describe*",
"kms:Get*",
"kms:List*",
"kms:RevokeGrant"
],
"Resource": "*"
}
]
}
```
#### Using grants to authorize Amazon Keyspaces
In addition to key policies, Amazon Keyspaces uses grants to set permissions on a customer managed key. To view the grants on a customer managed key in your account, use the [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) operation. Amazon Keyspaces doesn't need grants, or any additional permissions, to use the [AWS owned key](encryption.howitworks.md#keyspaces-owned) to protect your table.
Amazon Keyspaces uses the grant permissions when it performs background system maintenance and continuous data protection tasks. It also uses grants to generate table keys.
Each grant is specific to a table. If the account includes multiple tables encrypted under the same customer managed key, there is a grant of each type for each table. The grant is constrained by the [Amazon Keyspaces encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/encryption-context.html), which includes the table name and the AWS account ID. The grant includes permission to [retire the grant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) if it's no longer needed.
To create the grants, Amazon Keyspaces must have permission to call `CreateGrant` on behalf of the user who created the encrypted table.
The key policy can also allow the account to [revoke the grant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) on the customer managed key. However, if you revoke the grant on an active encrypted table, Amazon Keyspaces will not be able to protect and maintain the table.
## Step 3: Specify a customer managed key for a new table
Follow these steps to specify the customer managed key on a new table using the Amazon Keyspaces console or CQL.
### Create an encrypted table using a customer managed key (console)
1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home).
1. In the navigation pane, choose **Tables**, and then choose **Create table**.
1. On the **Create table** page in the **Table details** section, select a keyspace and provide a name for the new table.
1. In the **Schema** section, create the schema for your table.
1. In the **Table settings** section, choose **Customize settings**.
1. Continue to **Encryption settings**.
In this step, you select the encryption settings for the table.
In the **Encryption at rest** section under **Choose an AWS KMS key**, choose the option **Choose a different KMS key (advanced)**, and in the search field, choose an AWS KMS key or enter an Amazon Resource Name (ARN).
**Note**
If the key you selected is not accessible or is missing the required permissions, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide.
1. Choose **Create** to create the encrypted table.
### Create a new table using a customer managed key for encryption at rest (CQL)
To create a new table that uses a customer managed key for encryption at rest, you can use the `CREATE TABLE` statement as shown in the following example. Make sure to replace the key ARN with an ARN for a valid key with permissions granted to Amazon Keyspaces.
```
CREATE TABLE my_keyspace.my_table(id bigint, name text, place text STATIC, PRIMARY KEY(id, name)) WITH CUSTOM_PROPERTIES = {
'encryption_specification':{
'encryption_type': 'CUSTOMER_MANAGED_KMS_KEY',
'kms_key_identifier':'arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111'
}
};
```
If you receive an `Invalid Request Exception`, you need to confirm that the customer managed key is valid and Amazon Keyspaces has the required permissions. To confirm that the key has been configured correctly, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide.
## Step 4: Update the encryption key of an existing table
You can also use the Amazon Keyspaces console or CQL to change the encryption keys of an existing table between an AWS owned key and a customer managed KMS key at any time.
### Update an existing table with the new customer managed key (console)
1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home).
1. In the navigation pane, choose **Tables**.
1. Choose the table that you want to update, and then choose the **Additional settings** tab.
1. In the **Encryption at rest** section, choose **Manage Encryption** to edit the encryption settings for the table.
Under **Choose an AWS KMS key**, choose the option **Choose a different KMS key (advanced)**, and in the search field, choose an AWS KMS key or enter an Amazon Resource Name (ARN).
**Note**
If the key you selected is not valid, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide.
Alternatively, you can choose an AWS owned key for a table that is encrypted with a customer managed key.
1. Choose **Save changes** to save your changes to the table.
### Update the encryption key used for an existing table
To change the encryption key of an existing table, you use the `ALTER TABLE` statement to specify a customer managed key for encryption at rest. Make sure to replace the key ARN with an ARN for a valid key with permissions granted to Amazon Keyspaces.
```
ALTER TABLE my_keyspace.my_table WITH CUSTOM_PROPERTIES = {
'encryption_specification':{
'encryption_type': 'CUSTOMER_MANAGED_KMS_KEY',
'kms_key_identifier':'arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111'
}
};
```
If you receive an `Invalid Request Exception`, you need to confirm that the customer managed key is valid and Amazon Keyspaces has the required permissions. To confirm that the key has been configured correctly, see [Troubleshooting key access](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html) in the AWS Key Management Service Developer Guide.
To change the encryption key back to the default encryption at rest option with AWS owned keys, you can use the `ALTER TABLE` statement as shown in the following example.
```
ALTER TABLE my_keyspace.my_table WITH CUSTOM_PROPERTIES = {
'encryption_specification':{
'encryption_type' : 'AWS_OWNED_KMS_KEY'
}
};
```
## Step 5: Use the Amazon Keyspaces encryption context in logs
An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/encrypt_context.html) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context.
Amazon Keyspaces uses the same encryption context in all AWS KMS cryptographic operations. If you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces table, you can use the encryption context to identify the use of the customer managed key in audit records and logs. It also appears in plaintext in logs, such as in logs for [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
In its requests to AWS KMS, Amazon Keyspaces uses an encryption context with three key–value pairs.
```
"encryptionContextSubset": {
"aws:cassandra:keyspaceName": "my_keyspace",
"aws:cassandra:tableName": "mytable"
"aws:cassandra:subscriberId": "111122223333"
}
```
+ **Keyspace** – The first key–value pair identifies the keyspace that includes the table that Amazon Keyspaces is encrypting. The key is `aws:cassandra:keyspaceName`. The value is the name of the keyspace.
```
"aws:cassandra:keyspaceName": ""
```
For example:
```
"aws:cassandra:keyspaceName": "my_keyspace"
```
+ **Table** – The second key–value pair identifies the table that Amazon Keyspaces is encrypting. The key is `aws:cassandra:tableName`. The value is the name of the table.
```
"aws:cassandra:tableName": ""
```
For example:
```
"aws:cassandra:tableName": "my_table"
```
+ **Account** – The third key–value pair identifies the AWS account. The key is `aws:cassandra:subscriberId`. The value is the account ID.
```
"aws:cassandra:subscriberId": ""
```
For example:
```
"aws:cassandra:subscriberId": "111122223333"
```
## Step 6: Configure monitoring with AWS CloudTrail
If you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces tables, you can use AWS CloudTrail logs to track the requests that Amazon Keyspaces sends to AWS KMS on your behalf.
The `GenerateDataKey`, `DescribeKey`, `Decrypt`, and `CreateGrant` requests are discussed in this section. In addition, Amazon Keyspaces uses a [RetireGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) operation to remove a grant when you delete a table.
**Note**
When you work with Amazon Keyspaces, some operations may generate CloudTrail events with an `invokedBy` field of `dynamodb.amazonaws.com`. This is expected and occurs because Amazon Keyspaces integrates with Amazon DynamoDB to provide its service.
**GenerateDataKey**
Amazon Keyspaces creates a unique table key to encrypt data at rest. It sends a *[GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)* request to AWS KMS that specifies the KMS key for the table.
The event that records the `GenerateDataKey` operation is similar to the following example event. The user is the Amazon Keyspaces service account. The parameters include the Amazon Resource Name (ARN) of the customer managed key, a key specifier that requires a 256-bit key, and the [encryption context](#encryption-context) that identifies the keyspace, the table, and the AWS account.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2021-04-16T04:56:05Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": {
"keySpec": "AES_256",
"encryptionContext": {
"aws:cassandra:keyspaceName": "my_keyspace",
"aws:cassandra:tableName": "my_table",
"aws:cassandra:subscriberId": "123SAMPLE012"
},
"keyId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
},
"responseElements": null,
"requestID": "5e8e9cb5-9194-4334-aacc-9dd7d50fe246",
"eventID": "49fccab9-2448-4b97-a89d-7d5c39318d6f",
"readOnly": true,
"resources": [
{
"accountId": "123SAMPLE012",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "123SAMPLE012",
"sharedEventID": "84fbaaf0-9641-4e32-9147-57d2cb08792e"
}
```
**DescribeKey**
Amazon Keyspaces uses a [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) operation to determine whether the KMS key you selected exists in the account and Region.
The event that records the `DescribeKey` operation is similar to the following example event. The user is the Amazon Keyspaces service account. The parameters include the ARN of the customer managed key and a key specifier that requires a 256-bit key.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAZ3FNIIVIZZ6H7CFQG",
"arn": "arn:aws:iam::123SAMPLE012:user/admin",
"accountId": "123SAMPLE012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "admin",
"sessionContext": {
"sessionIssuer": {},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-04-16T04:55:42Z"
}
},
"invokedBy": "AWS Internal"
},
"eventTime": "2021-04-16T04:55:58Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
},
"responseElements": null,
"requestID": "c25a8105-050b-4f52-8358-6e872fb03a6c",
"eventID": "0d96420e-707e-41b9-9118-56585a669658",
"readOnly": true,
"resources": [
{
"accountId": "123SAMPLE012",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "123SAMPLE012"
}
```
**Decrypt**
When you access an Amazon Keyspaces table, Amazon Keyspaces needs to decrypt the table key so that it can decrypt the keys below it in the hierarchy. It then decrypts the data in the table. To decrypt the table key, Amazon Keyspaces sends a [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request to AWS KMS that specifies the KMS key for the table.
The event that records the `Decrypt` operation is similar to the following example event. The user is the principal in your AWS account who is accessing the table. The parameters include the encrypted table key (as a ciphertext blob) and the [encryption context](#encryption-context) that identifies the table and the AWS account. AWS KMS derives the ID of the customer managed key from the ciphertext.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2021-04-16T05:29:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": {
"encryptionContext": {
"aws:cassandra:keyspaceName": "my_keyspace",
"aws:cassandra:tableName": "my_table",
"aws:cassandra:subscriberId": "123SAMPLE012"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "50e80373-83c9-4034-8226-5439e1c9b259",
"eventID": "8db9788f-04a5-4ae2-90c9-15c79c411b6b",
"readOnly": true,
"resources": [
{
"accountId": "123SAMPLE012",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "123SAMPLE012",
"sharedEventID": "7ed99e2d-910a-4708-a4e3-0180d8dbb68e"
}
```
**CreateGrant**
When you use a [customer managed key](encryption.howitworks.md#customer-managed) to protect your Amazon Keyspaces table, Amazon Keyspaces uses [grants](#encryption-grants) to allow the service to perform continuous data protection and maintenance and durability tasks. These grants aren't required on [AWS owned keys](encryption.howitworks.md#keyspaces-owned).
The grants that Amazon Keyspaces creates are specific to a table. The principal in the [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) request is the user who created the table.
The event that records the `CreateGrant` operation is similar to the following example event. The parameters include the ARN of the customer managed key for the table, the grantee principal and retiring principal (the Amazon Keyspaces service), and the operations that the grant covers. It also includes a constraint that requires all encryption operations use the specified [encryption context](#encryption-context).
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAZ3FNIIVIZZ6H7CFQG",
"arn": "arn:aws:iam::arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111:user/admin",
"accountId": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111",
"accessKeyId": "AKIAI44QH8DHBEXAMPLE",
"userName": "admin",
"sessionContext": {
"sessionIssuer": {},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-04-16T04:55:42Z"
}
},
"invokedBy": "AWS Internal"
},
"eventTime": "2021-04-16T05:11:10Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": {
"keyId": "a7d328af-215e-4661-9a69-88c858909f20",
"operations": [
"DescribeKey",
"GenerateDataKey",
"Decrypt",
"Encrypt",
"ReEncryptFrom",
"ReEncryptTo",
"RetireGrant"
],
"constraints": {
"encryptionContextSubset": {
"aws:cassandra:keyspaceName": "my_keyspace",
"aws:cassandra:tableName": "my_table",
"aws:cassandra:subscriberId": "123SAMPLE012"
}
},
"retiringPrincipal": "cassandratest.us-east-1.amazonaws.com",
"granteePrincipal": "cassandratest.us-east-1.amazonaws.com"
},
"responseElements": {
"grantId": "18e4235f1b07f289762a31a1886cb5efd225f069280d4f76cd83b9b9b5501013"
},
"requestID": "b379a767-1f9b-48c3-b731-fb23e865e7f7",
"eventID": "29ee1fd4-28f2-416f-a419-551910d20291",
"readOnly": false,
"resources": [
{
"accountId": "123SAMPLE012",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:5555555555555:key/11111111-1111-111-1111-111111111111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "123SAMPLE012"
}
```
# Encryption in transit in Amazon Keyspaces
Amazon Keyspaces only accepts secure connections using Transport Layer Security (TLS). Encryption in transit provides an additional layer of data protection by encrypting your data as it travels to and from Amazon Keyspaces. Organizational policies, industry or government regulations, and compliance requirements often require the use of encryption in transit to increase the data security of your applications when they transmit data over the network.
To learn how to encrypt `cqlsh` connections to Amazon Keyspaces using TLS, see [How to manually configure `cqlsh` connections for TLS](programmatic.cqlsh.md#encrypt_using_tls). To learn how to use TLS encryption with client drivers, see [Using a Cassandra client driver to access Amazon Keyspaces programmatically](programmatic.drivers.md).
# Internetwork traffic privacy in Amazon Keyspaces
This topic describes how Amazon Keyspaces (for Apache Cassandra) secures connections from on-premises applications to Amazon Keyspaces and between Amazon Keyspaces and other AWS resources within the same AWS Region.
## Traffic between service and on-premises clients and applications
You have two connectivity options between your private network and AWS:
+ An AWS Site-to-Site VPN connection. For more information, see [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) in the *AWS Site-to-Site VPN User Guide*.
+ An Direct Connect connection. For more information, see [What is Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) in the *Direct Connect User Guide*.
As a managed service, Amazon Keyspaces (for Apache Cassandra) is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access Amazon Keyspaces through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Amazon Keyspaces supports two methods of authenticating client requests. The first method uses service-specific credentials, which are password based credentials generated for a specific IAM user. You can create and manage the password using the IAM console, the AWS CLI, or the AWS API. For more information, see [Using IAM with Amazon Keyspaces](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mcs.html).
The second method uses an authentication plugin for the open-source DataStax Java Driver for Cassandra. This plugin enables [IAM users, roles, and federated identities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) to add authentication information to Amazon Keyspaces (for Apache Cassandra) API requests using the [AWS Signature Version 4 process (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html). For more information, see [Create and configure AWS credentials for Amazon Keyspaces](access.credentials.md).
## Traffic between AWS resources in the same Region
Interface VPC endpoints enable private communication between your virtual private cloud (VPC) running in Amazon VPC and Amazon Keyspaces. Interface VPC endpoints are powered by AWS PrivateLink, which is an AWS service that enables private communication between VPCs and AWS services. AWS PrivateLink enables this by using an elastic network interface with private IPs in your VPC so that network traffic does not leave the Amazon network. Interface VPC endpoints don't require an internet gateway, NAT device, VPN connection, or Direct Connect connection. For more information, see [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) and [Interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html). For example policies, see [Using interface VPC endpoints for Amazon Keyspaces](vpc-endpoints.md#using-interface-vpc-endpoints).
# AWS Identity and Access Management for Amazon Keyspaces
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 Keyspaces 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 Keyspaces works with IAM
](security_iam_service-with-iam.md)
+ [
# Amazon Keyspaces identity-based policy examples
](security_iam_id-based-policy-examples.md)
+ [
# AWS managed policies for Amazon Keyspaces
](security-iam-awsmanpol.md)
+ [
# Troubleshooting Amazon Keyspaces identity and access
](security_iam_troubleshoot.md)
+ [
# Using service-linked roles for Amazon Keyspaces
](using-service-linked-roles.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting Amazon Keyspaces identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How Amazon Keyspaces works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [Amazon Keyspaces identity-based policy examples](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*.
### 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*.
### IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.
IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. 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*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about 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*.
Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities 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*.
Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.
### Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource. Examples include 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. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.
Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.
### Access control lists (ACLs)
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.
Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.
### Other policy types
AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, 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)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. 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 Keyspaces works with IAM
Before you use IAM to manage access to Amazon Keyspaces, you should understand what IAM features are available to use with Amazon Keyspaces. To get a high-level view of how Amazon Keyspaces 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**
+ [
## Amazon Keyspaces identity-based policies
](#security_iam_service-with-iam-id-based-policies)
+ [
## Amazon Keyspaces resource-based policies
](#security_iam_service-with-iam-resource-based-policies)
+ [
## Authorization based on Amazon Keyspaces tags
](#security_iam_service-with-iam-tags)
+ [
## Amazon Keyspaces IAM roles
](#security_iam_service-with-iam-roles)
## Amazon Keyspaces identity-based policies
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. Amazon Keyspaces supports specific actions and resources, and condition keys. To learn about all of the elements that you 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*.
To see the Amazon Keyspaces service-specific resources and actions, and condition context keys that can be used for IAM permissions policies, see the [Actions, resources, and condition keys for Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html) in the *Service Authorization Reference*.
### Actions
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 Amazon Keyspaces use the following prefix before the action: `cassandra:`. For example, to grant someone permission to create an Amazon Keyspaces keyspace with the Amazon Keyspaces `CREATE` CQL statement, you include the `cassandra:Create` action in their policy. Policy statements must include either an `Action` or `NotAction` element. Amazon Keyspaces 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": [
"cassandra:CREATE",
"cassandra:MODIFY"
]
```
To see a list of Amazon Keyspaces actions, see [Actions Defined by Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html#amazonkeyspacesforapachecassandra-actions-as-permissions) in the *Service Authorization Reference*.
### Resources
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": "*"
```
In Amazon Keyspaces, keyspaces, tables, and streams can be used in the `Resource` element of IAM permissions.
**Note**
To access user keyspaces and tables in Amazon Keyspaces, your IAM policy must include `cassandra:Select` permissions on system tables:
```
arn:${Partition}:cassandra:${Region}:${Account}:/keyspace/system*
```
This applies to the following scenarios:
AWS Management Console access
SDK resource operations, for example `GetKeyspace`, `GetTable`, `ListKeyspaces`, and `ListTables`
Standard Apache Cassandra client driver connections, because drivers automatically read system tables during connection initialization
System tables are read-only and cannot be modified.
The Amazon Keyspaces keyspace resource has the following ARN:
```
arn:${Partition}:cassandra:${Region}:${Account}:/keyspace/${keyspaceName}/
```
The Amazon Keyspaces table resource has the following ARN:
```
arn:${Partition}:cassandra:${Region}:${Account}:/keyspace/${keyspaceName}/table/${tableName}
```
The Amazon Keyspaces stream resource has the following ARN:
```
arn:${Partition}:cassandra:{Region}:${Account}:/keyspace/${keyspaceName}/table/${tableName}/stream/${streamLabel}
```
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 `mykeyspace` keyspace in your statement, use the following ARN:
```
"Resource": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/"
```
To specify all keyspaces that belong to a specific account, use the wildcard (\$1):
```
"Resource": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/*"
```
Some Amazon Keyspaces actions, such as those for creating resources, cannot be performed on a specific resource. In those cases, you must use the wildcard (\$1).
```
"Resource": "*"
```
For example, to grant `SELECT` permissions to an IAM principal for `mytable` in `mykeyspace`, the principal must have permissions to read both, `mytable` and `keyspace/system*`. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
```
To see a list of Amazon Keyspaces resource types and their ARNs, see [Resources Defined by Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html#amazonkeyspacesforapachecassandra-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 Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html#amazonkeyspacesforapachecassandra-actions-as-permissions).
### Condition keys
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*.
Amazon Keyspaces 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 Amazon Keyspaces actions support the `aws:RequestTag/${TagKey}`, the `aws:ResourceTag/${TagKey}`, and the `aws:TagKeys` condition keys. For more information, see [Amazon Keyspaces resource access based on tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-tags).
To see a list of Amazon Keyspaces condition keys, see [Condition Keys for Amazon Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html#amazonkeyspacesforapachecassandra-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 Keyspaces (for Apache Cassandra)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html#amazonkeyspacesforapachecassandra-actions-as-permissions).
### Examples
To view examples of Amazon Keyspaces identity-based policies, see [Amazon Keyspaces identity-based policy examples](security_iam_id-based-policy-examples.md).
## Amazon Keyspaces resource-based policies
Amazon Keyspaces does not support resource-based policies. To view an example of a detailed resource-based policy page, see [https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html).
## Authorization based on Amazon Keyspaces tags
You can manage access to your Amazon Keyspaces resources by using tags. To manage resource 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 `cassandra:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. For more information about tagging Amazon Keyspaces resources, see [Working with tags and labels for Amazon Keyspaces resources](tagging-keyspaces.md).
To view example identity-based policies for limiting access to a resource based on the tags on that resource, see [Amazon Keyspaces resource access based on tags](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-tags).
## Amazon Keyspaces IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity within your AWS account that has specific permissions.
### Using temporary credentials with Amazon Keyspaces
You can use temporary credentials to sign in with federation, to assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon Keyspaces supports using temporary credentials with the AWS Signature Version 4 (SigV4) authentication plugin available from the Github repo for the following languages:
+ Java: [https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin).
+ Node.js: [https://github.com/aws/aws-sigv4-auth-cassandra-nodejs-driver-plugin](https://github.com/aws/aws-sigv4-auth-cassandra-nodejs-driver-plugin).
+ Python: [https://github.com/aws/aws-sigv4-auth-cassandra-python-driver-plugin](https://github.com/aws/aws-sigv4-auth-cassandra-python-driver-plugin).
+ Go: [https://github.com/aws/aws-sigv4-auth-cassandra-gocql-driver-plugin](https://github.com/aws/aws-sigv4-auth-cassandra-gocql-driver-plugin).
For examples and tutorials that implement the authentication plugin to access Amazon Keyspaces programmatically, see [Using a Cassandra client driver to access Amazon Keyspaces programmatically](programmatic.drivers.md).
### Service-linked roles
[Service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view but not edit the permissions for service-linked roles.
For details about creating or managing Amazon Keyspaces service-linked roles, see **[Using service-linked roles for Amazon Keyspaces](using-service-linked-roles.md)**.
### Service roles
Amazon Keyspaces does not support service roles.
# Amazon Keyspaces identity-based policy examples
By default, IAM users and roles don't have permission to create or modify Amazon Keyspaces resources. They also can't perform tasks using the console, CQLSH, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups 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 Amazon Keyspaces console
](#security_iam_id-based-policy-examples-console)
+ [
## Allow users to view their own permissions
](#security_iam_id-based-policy-examples-view-own-permissions)
+ [
## Accessing Amazon Keyspaces tables
](#security_iam_id-based-policy-examples-access-one-table)
+ [
## Amazon Keyspaces resource access based on tags
](#security_iam_id-based-policy-examples-tags)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete Amazon Keyspaces 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 Amazon Keyspaces console
Amazon Keyspaces doesn't require specific permissions to access the Amazon Keyspaces console. You need at least read-only permissions to list and view details about the Amazon Keyspaces 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 (IAM users or roles) with that policy.
Two AWS managed policies are available to the entities for Amazon Keyspaces console access.
+ [AmazonKeyspacesReadOnlyAccess\$1v2](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesReadOnlyAccess_v2.html) – This policy grants read-only access to Amazon Keyspaces.
+ [AmazonKeyspacesFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesFullAccess.html) – This policy grants permissions to use Amazon Keyspaces with full access to all features.
For more information about Amazon Keyspaces managed policies, see [AWS managed policies for Amazon Keyspaces](security-iam-awsmanpol.md).
## 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": "*"
}
]
}
```
## Accessing Amazon Keyspaces tables
**Note**
To access user keyspaces and tables in Amazon Keyspaces, your IAM policy must include `cassandra:Select` permissions on system tables:
```
arn:${Partition}:cassandra:${Region}:${Account}:/keyspace/system*
```
This applies to the following scenarios:
AWS Management Console access
SDK resource operations, for example `GetKeyspace`, `GetTable`, `ListKeyspaces`, and `ListTables`
Standard Apache Cassandra client driver connections, because drivers automatically read system tables during connection initialization
System tables are read-only and cannot be modified.
The following is a sample policy that grants read-only (`SELECT`) access to the Amazon Keyspaces system tables. For all samples, replace the Region and account ID in the Amazon Resource Name (ARN) with your own.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
The following sample policy adds read-only access to the user table `mytable` in the keyspace `mykeyspace`.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
The following sample policy assigns read/write access to a user table and read access to the system tables.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Select",
"cassandra:Modify"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
The following sample policy allows a user to create tables in keyspace `mykeyspace`.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"cassandra:Create",
"cassandra:Select"
],
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/*",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
The following sample policy assigns read access to the system tables, but restricts `SELECT` (read) and `MODIFY` (write) access to the user table `mytable`.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cassandra:Select"
],
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
},
{
"Effect": "Deny",
"Action": [
"cassandra:Select",
"cassandra:Modify"
],
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable"
]
}
]
}
```
## Amazon Keyspaces resource access based on tags
You can use conditions in your identity-based policy to control access to Amazon Keyspaces resources based on tags. These policies control visibility of the keyspaces and tables in the account. Note that tag-based permissions for system tables behave differently when requests are made using the AWS SDK compared to Cassandra Query Language (CQL) API calls via Cassandra drivers and developer tools.
+ To make `List` and `Get` resource requests with the AWS SDK when using tag-based access, the caller needs to have read access to system tables. For example, `Select` action permissions are required to read data from system tables via the `GetTable` operation. If the caller has only tag-based access to a specific table, an operation that requires additional access to a system table will fail.
+ For compatibility with established Cassandra driver behavior, tag-based authorization policies are not enforced when performing operations on system tables using Cassandra Query Language (CQL) API calls via Cassandra drivers and developer tools.
The following example shows how you can create a policy that grants permissions to a user to view a table if the table's `Owner` contains the value of that user's user name. In this example you also give read access to the system tables.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ReadOnlyAccessTaggedTables",
"Effect":"Allow",
"Action":"cassandra:Select",
"Resource":[
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/*",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
],
"Condition":{
"StringEquals":{
"aws:ResourceTag/Owner":"${aws:username}"
}
}
}
]
}
```
You can attach this policy to the IAM users in your account. If a user named `richard-roe` attempts to view an Amazon Keyspaces table, the table must be tagged `Owner=richard-roe` or `owner=richard-roe`. Otherwise, he is denied access. The condition tag key `Owner` matches both `Owner` and `owner` because condition key names are not case-sensitive. 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*.
The following policy grants permissions to a user to create tables with tags if the table's `Owner` contains the value of that user's user name.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CreateTagTableUser",
"Effect": "Allow",
"Action": [
"cassandra:Create",
"cassandra:TagResource"
],
"Resource": "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/*",
"Condition":{
"StringEquals":{
"aws:RequestTag/Owner":"${aws:username}"
}
}
}
]
}
```
# AWS managed policies for Amazon Keyspaces
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, 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 managed policy: AmazonKeyspacesReadOnlyAccess\$1v2
You can attach the `AmazonKeyspacesReadOnlyAccess_v2` policy to your IAM identities.
This policy grants read-only access to Amazon Keyspaces and includes the required permissions when connecting through private VPC endpoints.
**Permissions details**
This policy includes the following permissions.
+ `Amazon Keyspaces` – Provides read-only access to Amazon Keyspaces.
+ `Amazon Keyspaces CDC streams` – Allows principals to view Amazon Keyspaces CDC streams.
+ `Application Auto Scaling` – Allows principals to view configurations from Application Auto Scaling. This is required so that users can view automatic scaling policies that are attached to a table.
+ `CloudWatch` – Allows principals to view metric data and alarms configured in CloudWatch. This is required so users can view the billable table size and CloudWatch alarms that have been configured for a table.
+ `AWS KMS` – Allows principals to view keys configured in AWS KMS. This is required so users can view AWS KMS keys that they create and manage in their account to confirm that the key assigned to Amazon Keyspaces is a symmetric encryption key that is enabled.
+ `Amazon EC2` – Allows principals connecting to Amazon Keyspaces through VPC endpoints to query the VPC on your Amazon EC2 instance for endpoint and network interface information. This read-only access to the Amazon EC2 instance is required so Amazon Keyspaces can look up and store available interface VPC endpoints in the `system.peers` table used for connection load balancing.
To review the policy in `JSON` format, see [AmazonKeyspacesReadOnlyAccess\$1v2](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesReadOnlyAccess_v2.html).
## AWS managed policy: AmazonKeyspacesReadOnlyAccess
You can attach the `AmazonKeyspacesReadOnlyAccess` policy to your IAM identities.
This policy grants read-only access to Amazon Keyspaces.
**Permissions details**
This policy includes the following permissions.
+ `Amazon Keyspaces` – Provides read-only access to Amazon Keyspaces.
+ `Amazon Keyspaces CDC streams` – Allows principals to view Amazon Keyspaces CDC streams.
+ `Application Auto Scaling` – Allows principals to view configurations from Application Auto Scaling. This is required so that users can view automatic scaling policies that are attached to a table.
+ `CloudWatch` – Allows principals to view metric data and alarms configured in CloudWatch. This is required so users can view the billable table size and CloudWatch alarms that have been configured for a table.
+ `AWS KMS` – Allows principals to view keys configured in AWS KMS. This is required so users can view AWS KMS keys that they create and manage in their account to confirm that the key assigned to Amazon Keyspaces is a symmetric encryption key that is enabled.
To review the policy in `JSON` format, see [AmazonKeyspacesReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesReadOnlyAccess.html).
## AWS managed policy: AmazonKeyspacesFullAccess
You can attach the `AmazonKeyspacesFullAccess` policy to your IAM identities.
This policy grants administrative permissions that allow your administrators unrestricted access to Amazon Keyspaces.
**Permissions details**
This policy includes the following permissions.
+ `Amazon Keyspaces` – Allows principals to access any Amazon Keyspaces resource and perform all actions.
+ `Application Auto Scaling` – Allows principals to create, view, and delete automatic scaling policies for Amazon Keyspaces tables. This is required so that administrators can manage automatic scaling policies for Amazon Keyspaces tables.
+ `CloudWatch` – Allows principals to see the billable table size as well as create, view, and delete CloudWatch alarms for Amazon Keyspaces automatic scaling policies. This is required so that administrators can view the billable table size and create a CloudWatch dashboard.
+ `IAM` – Allows Amazon Keyspaces to create service-linked roles with IAM automatically when the following features are turned on:
+ `Amazon Keyspaces CDC streams` – When an administrator enables a stream for a table, Amazon Keyspaces creates the service-linked role [AWSServiceRoleForAmazonKeyspacesCDC](using-service-linked-roles-CDC-streams.md#service-linked-role-permissions-CDC-streams) to publish CloudWatch metrics into your account on your behalf.
+ `Application Auto Scaling` – When an administrator enables Application Auto Scaling for a table, Amazon Keyspaces creates the service-linked role [AWSServiceRoleForApplicationAutoScaling\$1CassandraTable](using-service-linked-roles-app-auto-scaling.md#service-linked-role-permissions-app-auto-scaling) to perform automatic scaling actions on your behalf.
+ `Amazon Keyspaces multi-Region replication` – When an administrator creates a new multi-Region keyspace, or adds a new AWS Region to an existing single-Region keyspace, Amazon Keyspaces creates the service-linked role [AWSServiceRoleForAmazonKeyspacesReplication](using-service-linked-roles-multi-region-replication.md#service-linked-role-permissions-multi-region-replication) to perform replication of tables, data, and metadata to the selected Regions on your behalf.
+ `AWS KMS` – Allows principals to view keys configured in AWS KMS. This is required so that users can view AWS KMS keys that they create and manage in their account to confirm that the key assigned to Amazon Keyspaces is a symmetric encryption key that is enabled.
+ `Amazon EC2` – Allows principals connecting to Amazon Keyspaces through VPC endpoints to query the VPC on your Amazon EC2 instance for endpoint and network interface information. This read-only access to the Amazon EC2 instance is required so Amazon Keyspaces can look up and store available interface VPC endpoints in the `system.peers` table used for connection load balancing.
To review the policy in `JSON` format, see [AmazonKeyspacesFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonKeyspacesFullAccess.html).
## AWS managed policy: KeyspacesCDCServiceRolePolicy
You can't attach `KeyspacesCDCServiceRolePolicy` to your IAM entities. This policy is attached to a service-linked role that allows Amazon Keyspaces to perform actions on your behalf. For more information, see [Using roles for Amazon Keyspaces CDC streams](using-service-linked-roles-CDC-streams.md).
This policy grants the required permissions to the service-linked role `AWSServiceRoleForAmazonKeyspacesCDC` to publish Amazon Keyspaces CDC stream metrics data to CloudWatch on your behalf.
**Permissions details**
This policy includes the following permissions.
+ `CloudWatch` – Allows the service-linked-role [AWSServiceRoleForAmazonKeyspacesCDC](using-service-linked-roles-CDC-streams.md#service-linked-role-permissions-CDC-streams) to publish metric data from Amazon Keyspaces CDC streams into the `"cloudwatch:namespace": "AWS/Cassandra"` in your CloudWatch account on your behalf.
To review the policy in `JSON` format, see [KeyspacesCDCServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KeyspacesCDCServiceRolePolicy.html).
## Amazon Keyspaces updates to AWS managed policies
View details about updates to AWS managed policies for Amazon Keyspaces since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the [Document history for Amazon Keyspaces (for Apache Cassandra)](doc-history.md) page.
| Change | Description | Date |
| --- | --- | --- |
| [KeyspacesCDCServiceRolePolicy](#security-iam-awsmanpol-KeyspacesCDCServiceRolePolicy) – New policy | Amazon Keyspaces added a new managed policy `KeyspacesCDCServiceRolePolicy` which grants the required permissions to the service-linked role `AWSServiceRoleForAmazonKeyspacesCDC` to publish Amazon Keyspaces CDC stream metrics data to CloudWatch on your behalf. For more information, see [Using roles for Amazon Keyspaces CDC streams](using-service-linked-roles-CDC-streams.md). | July 02, 2025 |
| [AmazonKeyspacesReadOnlyAccess\$1v2](#security-iam-awsmanpol-AmazonKeyspacesReadOnlyAccess_v2) – Update to an existing policy | Amazon Keyspaces added new permissions to allow IAM principals to view Amazon Keyspaces CDC streams. For more information, see [View CDC streams in Amazon Keyspaces](keyspaces-view-cdc.md). | July 02, 2025 |
| [AmazonKeyspacesReadOnlyAccess](#security-iam-awsmanpol-AmazonKeyspacesReadOnlyAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow IAM principals to view Amazon Keyspaces CDC streams. For more information, see [View CDC streams in Amazon Keyspaces](keyspaces-view-cdc.md). | July 02, 2025 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces created the `KeyspacesCDCServiceRolePolicy` managed policy for the service linked role [AWSServiceRoleForAmazonKeyspacesCDC](using-service-linked-roles-CDC-streams.md#service-linked-role-permissions-CDC-streams) to add the permissions that are required when an administrator enables a stream for a table. Amazon Keyspaces uses the service-linked role `AWSServiceRoleForAmazonKeyspacesCDC` to publish CloudWatch metrics into your account on your behalf. For more information, see [Using roles for Amazon Keyspaces CDC streams](using-service-linked-roles-CDC-streams.md). | July 02, 2025 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces updated the `KeyspacesReplicationServiceRolePolicy` of the service linked role [AWSServiceRoleForAmazonKeyspacesReplication](using-service-linked-roles-multi-region-replication.md#service-linked-role-permissions-multi-region-replication) to add the permissions that are required when an administrator adds a new AWS Region to a single or multi-Region keyspace. Amazon Keyspaces uses the service-linked role `AWSServiceRoleForAmazonKeyspacesReplication` to replicate tables, their settings, and data on your behalf. For more information, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). | November 19, 2024 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow Amazon Keyspaces to create a service-linked role when an administrator adds a new Region to a single or multi-Region keyspace. Amazon Keyspaces uses the service-linked role to perform data replication tasks on your behalf. For more information, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). | October 3, 2023 |
| [AmazonKeyspacesReadOnlyAccess\$1v2](#security-iam-awsmanpol-AmazonKeyspacesReadOnlyAccess) – New policy | Amazon Keyspaces created a new policy to add read-only permissions for clients connecting to Amazon Keyspaces through interface VPC endpoints to access the Amazon EC2 instance to look up network information. Amazon Keyspaces stores available interface VPC endpoints in the `system.peers` table for connection load balancing. For more information, see [Using Amazon Keyspaces with interface VPC endpoints](vpc-endpoints.md). | September 12, 2023 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow Amazon Keyspaces to create a service-linked role when an administrator creates a multi-Region keyspace. Amazon Keyspaces uses the service-linked role `AWSServiceRoleForAmazonKeyspacesReplication` to perform data replication tasks on your behalf. For more information, see [Using roles for Amazon Keyspaces Multi-Region Replication](using-service-linked-roles-multi-region-replication.md). | June 5, 2023 |
| [AmazonKeyspacesReadOnlyAccess](#security-iam-awsmanpol-AmazonKeyspacesReadOnlyAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow users to view the billable size of a table using CloudWatch. Amazon Keyspaces integrates with Amazon CloudWatch to allow you to monitor the billable table size. For more information, see [Amazon Keyspaces metrics](metrics-dimensions.md#keyspaces-metrics-dimensions). | July 7, 2022 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow users to view the billable size of a table using CloudWatch. Amazon Keyspaces integrates with Amazon CloudWatch to allow you to monitor the billable table size. For more information, see [Amazon Keyspaces metrics](metrics-dimensions.md#keyspaces-metrics-dimensions). | July 7, 2022 |
| [AmazonKeyspacesReadOnlyAccess](#security-iam-awsmanpol-AmazonKeyspacesReadOnlyAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow users to view AWS KMS keys that have been configured for Amazon Keyspaces encryption at rest. Amazon Keyspaces encryption at rest integrates with AWS KMS for protecting and managing the encryption keys used to encrypt data at rest. To view the AWS KMS key configured for Amazon Keyspaces, read-only permissions have been added. | June 1, 2021 |
| [AmazonKeyspacesFullAccess](#security-iam-awsmanpol-AmazonKeyspacesFullAccess) – Update to an existing policy | Amazon Keyspaces added new permissions to allow users to view AWS KMS keys that have been configured for Amazon Keyspaces encryption at rest. Amazon Keyspaces encryption at rest integrates with AWS KMS for protecting and managing the encryption keys used to encrypt data at rest. To view the AWS KMS key configured for Amazon Keyspaces, read-only permissions have been added. | June 1, 2021 |
| Amazon Keyspaces started tracking changes | Amazon Keyspaces started tracking changes for its AWS managed policies. | June 1, 2021 |
# Troubleshooting Amazon Keyspaces identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with Amazon Keyspaces and IAM.
**Topics**
+ [
## I'm not authorized to perform an action in Amazon Keyspaces
](#security_iam_troubleshoot-no-permissions)
+ [
## I modified an IAM user or role and the changes did not take effect immediately
](#security_iam_troubleshoot-effect)
+ [
## I can't restore a table using Amazon Keyspaces point-in-time recovery (PITR)
](#security_iam_troubleshoot-pitr)
+ [
## I'm not authorized to perform iam:PassRole
](#security_iam_troubleshoot-passrole)
+ [
## I'm an administrator and want to allow others to access Amazon Keyspaces
](#security_iam_troubleshoot-admin-delegate)
+ [
## I want to allow people outside of my AWS account to access my Amazon Keyspaces resources
](#security_iam_troubleshoot-cross-account-access)
## I'm not authorized to perform an action in Amazon Keyspaces
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 user name and password.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a *table* but does not have `cassandra:Select` permissions for the table.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: cassandra:Select on resource: mytable
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `mytable` resource using the `cassandra:Select` action.
## I modified an IAM user or role and the changes did not take effect immediately
IAM policy changes may take up to 10 minutes to take effect for applications with existing, established connections to Amazon Keyspaces. IAM policy changes take effect immediately when applications establish a new connection. If you have made modifications to an existing IAM user or role, and it has not taken immediate effect, either wait for 10 minutes or disconnect and reconnect to Amazon Keyspaces.
## I can't restore a table using Amazon Keyspaces point-in-time recovery (PITR)
If you are trying to restore an Amazon Keyspaces table with point-in-time recovery (PITR), and you see the restore process begin, but not complete successfully, you might not have configured all of the required permissions that are needed by the restore process. You must contact your administrator for assistance and ask that person to update your policies to allow you to restore a table in Amazon Keyspaces.
In addition to user permissions, Amazon Keyspaces may require permissions to perform actions during the restore process on your principal's behalf. This is the case if the table is encrypted with a customer-managed key, or if you are using IAM policies that restrict incoming traffic. For example, if you are using condition keys in your IAM policy to restrict source traffic to specific endpoints or IP ranges, the restore operation fails. To allow Amazon Keyspaces to perform the table restore operation on your principal's behalf, you must add an `aws:ViaAWSService` global condition key in the IAM policy.
For more information about permissions to restore tables, see [Configure restore table IAM permissions for Amazon Keyspaces PITR](howitworks_restore_permissions.md).
## I'm not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to Amazon Keyspaces.
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 an IAM user named `marymajor` tries to use the console to perform an action in Amazon Keyspaces. However, the action requires the service to have permissions that are 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's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I'm an administrator and want to allow others to access Amazon Keyspaces
To allow others to access Amazon Keyspaces, you must grant permission to the people or applications that need access. If you are using AWS IAM Identity Center to manage people and applications, you assign permission sets to users or groups to define their level of access. Permission sets automatically create and assign IAM policies to IAM roles that are associated with the person or application. For more information, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center User Guide*.
If you are not using IAM Identity Center, you must create IAM entities (users or roles) for the people or applications that need access. You must then attach a policy to the entity that grants them the correct permissions in Amazon Keyspaces. After the permissions are granted, provide the credentials to the user or application developer. They will use those credentials to access AWS. To learn more about creating IAM users, groups, policies, and permissions, see [IAM Identities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) and [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
## I want to allow people outside of my AWS account to access my Amazon Keyspaces 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 Amazon Keyspaces supports these features, see [How Amazon Keyspaces 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 [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*.
# Using service-linked roles for Amazon Keyspaces
Amazon Keyspaces (for Apache Cassandra) uses AWS Identity and Access Management (IAM) [ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon Keyspaces. Service-linked roles are predefined by Amazon Keyspaces and include all the permissions that the service requires to call other AWS services on your behalf.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
**Topics**
+ [
# Using roles for Amazon Keyspaces application auto scaling
](using-service-linked-roles-app-auto-scaling.md)
+ [
# Using roles for Amazon Keyspaces Multi-Region Replication
](using-service-linked-roles-multi-region-replication.md)
+ [
# Using roles for Amazon Keyspaces CDC streams
](using-service-linked-roles-CDC-streams.md)
# Using roles for Amazon Keyspaces application auto scaling
Amazon Keyspaces (for Apache Cassandra) uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon Keyspaces. Service-linked roles are predefined by Amazon Keyspaces and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon Keyspaces easier because you don’t have to manually add the necessary permissions. Amazon Keyspaces defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon Keyspaces can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting its related resources. This protects your Amazon Keyspaces resources because you can't inadvertently remove permission to access the resources.
## Service-linked role permissions for Amazon Keyspaces
Amazon Keyspaces uses the service-linked role named **AWSServiceRoleForApplicationAutoScaling\$1CassandraTable** to allow Application Auto Scaling to call Amazon Keyspaces and Amazon CloudWatch on your behalf.
The AWSServiceRoleForApplicationAutoScaling\$1CassandraTable service-linked role trusts the following services to assume the role:
+ `cassandra.application-autoscaling.amazonaws.com`
The role permissions policy allows Application Auto Scaling to complete the following actions on the specified Amazon Keyspaces resources:
+ Action: `cassandra:Select` on `arn:*:cassandra:*:*:/keyspace/system/table/*`
+ Action: `cassandra:Select` on the resource `arn:*:cassandra:*:*:/keyspace/system_schema/table/*`
+ Action: `cassandra:Select` on the resource `arn:*:cassandra:*:*:/keyspace/system_schema_mcs/table/*`
+ Action: `cassandra:Alter` on the resource `arn:*:cassandra:*:*:"*"`
## Creating a service-linked role for Amazon Keyspaces
You don't need to manually create a service-linked role for Amazon Keyspaces automatic scaling. When you enable Amazon Keyspaces auto scaling on a table with the AWS Management Console, CQL, the AWS CLI, or the AWS API, Application Auto Scaling creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you enable Amazon Keyspaces auto scaling for a table, Application Auto Scaling creates the service-linked role for you again.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. To learn more, see [A new role appeared in my AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
## Editing a service-linked role for Amazon Keyspaces
Amazon Keyspaces does not allow you to edit the AWSServiceRoleForApplicationAutoScaling\$1CassandraTable service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon Keyspaces
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that isn't actively monitored or maintained. However, you must first disable automatic scaling on all tables in the account across all AWS Regions before you can delete the service-linked role manually. To disable automatic scaling on Amazon Keyspaces tables, see [Turn off Amazon Keyspaces auto scaling for a table](autoscaling.turnoff.md).
**Note**
If Amazon Keyspaces automatic scaling is using the role when you try to modify the resources, then the deregistration might fail. If that happens, wait for a few minutes and try the operation again.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForApplicationAutoScaling\$1CassandraTable service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
**Note**
To delete the service-linked role used by Amazon Keyspaces automatic scaling, you must first disable automatic scaling on all tables in the account.
## Supported Regions for Amazon Keyspaces service-linked roles
Amazon Keyspaces supports using service-linked roles in all of the Regions where the service is available. For more information, see [Service endpoints for Amazon Keyspaces](https://docs.aws.amazon.com/keyspaces/latest/devguide/programmatic.endpoints.html).
# Using roles for Amazon Keyspaces Multi-Region Replication
Amazon Keyspaces (for Apache Cassandra) uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon Keyspaces. Service-linked roles are predefined by Amazon Keyspaces and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon Keyspaces easier because you don’t have to manually add the necessary permissions. Amazon Keyspaces defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon Keyspaces can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting its related resources. This protects your Amazon Keyspaces resources because you can't inadvertently remove permission to access the resources.
## Service-linked role permissions for Amazon Keyspaces
Amazon Keyspaces uses the service-linked role named **AWSServiceRoleForAmazonKeyspacesReplication** to allow Amazon Keyspaces to add new AWS Regions to a keyspace on your behalf, and replicate tables and all their data and settings to the new Region. The role also allows Amazon Keyspaces to replicate writes to tables in all Regions on your behalf.
The AWSServiceRoleForAmazonKeyspacesReplication service-linked role trusts the following services to assume the role:
+ `replication.cassandra.amazonaws.com`
The role permissions policy named KeyspacesReplicationServiceRolePolicy allows Amazon Keyspaces to complete the following actions:
+ Action: `cassandra:Select`
+ Action: `cassandra:SelectMultiRegionResource`
+ Action: `cassandra:Modify`
+ Action: `cassandra:ModifyMultiRegionResource`
+ Action: `cassandra:AlterMultiRegionResource`
+ Action: `application-autoscaling:RegisterScalableTarget` – Amazon Keyspaces uses the application auto scaling permissions when you add a replica to a single Region table in provisioned mode with auto scaling enabled.
+ Action: `application-autoscaling:DeregisterScalableTarget`
+ Action: `application-autoscaling:DescribeScalableTargets`
+ Action: `application-autoscaling:PutScalingPolicy`
+ Action: `application-autoscaling:DescribeScalingPolicies`
+ Action: `cassandra:Alter`
+ Action: `cloudwatch:DeleteAlarms`
+ Action: `cloudwatch:DescribeAlarms`
+ Action: `cloudwatch:PutMetricAlarm`
Although the Amazon Keyspaces service-linked role AWSServiceRoleForAmazonKeyspacesReplication provides the permissions: "Action:" for the specified Amazon Resource Name (ARN) "arn:\$1" in the policy, Amazon Keyspaces supplies the ARN of your account.
Permissions to create the service-linked role AWSServiceRoleForAmazonKeyspacesReplication are included in the `AmazonKeyspacesFullAccess` managed policy. For more information, see [AWS managed policy: AmazonKeyspacesFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonKeyspacesFullAccess).
You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for Amazon Keyspaces
You can't manually create a service-linked role. When you create a multi-Region keyspace in the AWS Management Console, the AWS CLI, or the AWS API, Amazon Keyspaces creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a multi-Region keyspace, Amazon Keyspaces creates the service-linked role for you again.
## Editing a service-linked role for Amazon Keyspaces
Amazon Keyspaces does not allow you to edit the AWSServiceRoleForAmazonKeyspacesReplication service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for Amazon Keyspaces
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must first delete all multi-Region keyspaces in the account across all AWS Regions before you can delete the service-linked role manually.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any multi-Region keyspaces and tables used by the role.
**Note**
If the Amazon Keyspaces service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
**To delete Amazon Keyspaces resources used by the AWSServiceRoleForAmazonKeyspacesReplication (console)**
1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at [https://console.aws.amazon.com/keyspaces/home](https://console.aws.amazon.com/keyspaces/home).
1. Choose **Keyspaces** from the left-side panel.
1. Select all multi-Region keyspaces from the list.
1. Choose **Delete** confirm the deletion and choose **Delete keyspaces**.
You can also delete multi-Region keyspaces programmatically using any of the following methods.
+ The Cassandra Query Language (CQL) [DROP KEYSPACE](cql.ddl.keyspace.md#cql.ddl.keyspace.drop) statement.
+ The [delete-keyspace](https://docs.aws.amazon.com/cli/latest/reference/keyspaces/delete-keyspace.html) operation of the AWS CLI.
+ The [DeleteKeyspace](https://docs.aws.amazon.com/keyspaces/latest/APIReference/API_DeleteKeyspace.html) operation of the Amazon Keyspaces API.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAmazonKeyspacesReplication service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported Regions for Amazon Keyspaces service-linked roles
Amazon Keyspaces does not support using service-linked roles in every Region where the service is available. You can use the AWSServiceRoleForAmazonKeyspacesReplication role in the following Regions.
****
| Region name | Region identity | Support in Amazon Keyspaces |
| --- | --- | --- |
| US East (N. Virginia) | us-east-1 | Yes |
| US East (Ohio) | us-east-2 | Yes |
| US West (N. California) | us-west-1 | Yes |
| US West (Oregon) | us-west-2 | Yes |
| Asia Pacific (Mumbai) | ap-south-1 | Yes |
| Asia Pacific (Osaka) | ap-northeast-3 | Yes |
| Asia Pacific (Seoul) | ap-northeast-2 | Yes |
| Asia Pacific (Singapore) | ap-southeast-1 | Yes |
| Asia Pacific (Sydney) | ap-southeast-2 | Yes |
| Asia Pacific (Tokyo) | ap-northeast-1 | Yes |
| Canada (Central) | ca-central-1 | Yes |
| Europe (Frankfurt) | eu-central-1 | Yes |
| Europe (Ireland) | eu-west-1 | Yes |
| Europe (London) | eu-west-2 | Yes |
| Europe (Paris) | eu-west-3 | Yes |
| Africa (Cape Town) | af-south-1 | Yes |
| South America (São Paulo) | sa-east-1 | Yes |
| AWS GovCloud (US-East) | us-gov-east-1 | No |
| AWS GovCloud (US-West) | us-gov-west-1 | No |
# Using roles for Amazon Keyspaces CDC streams
Amazon Keyspaces (for Apache Cassandra) uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to Amazon Keyspaces. Service-linked roles are predefined by Amazon Keyspaces and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up Amazon Keyspaces easier because you don’t have to manually add the necessary permissions. Amazon Keyspaces defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon Keyspaces can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can't delete the service-linked role.
## Service-linked role permissions for Amazon Keyspaces
Amazon Keyspaces uses the service-linked role named **AWSServiceRoleForAmazonKeyspacesCDC** to allow Amazon Keyspaces CDC streams to publish CloudWatch metrics into your account on your behalf.
The AWSServiceRoleForAmazonKeyspacesCDC service-linked role trusts the following service to assume the role:
+ `cassandra-streams.amazonaws.com`
The role permissions policy named [KeyspacesCDCServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KeyspacesCDCServiceRolePolicy.html) allows Amazon Keyspaces to complete the following action on resources in the CloudWatch namespace `AWS/Cassandra`:
+ Action: `cloudwatch:PutMetricData` on `*`
The AWSServiceRoleForAmazonKeyspacesCDC provides the permissions: Action: cloudwatch:PutMetricData on all resources that match the following condition: `"cloudwatch:namespace": "AWS/Cassandra"`.
For more information about KeyspacesCDCServiceRolePolicy, see [AWS managed policy: KeyspacesCDCServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-KeyspacesCDCServiceRolePolicy).
To enable CDC streams for a table, which automatically creates the service-linked role AWSServiceRoleForAmazonKeyspacesCDC, the IAM principal needs the following permissions.
```
{
"Sid": "KeyspacesCDCServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/cassandra-streams.amazonaws.com/AWSServiceRoleForAmazonKeyspacesCDC",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "cassandra-streams.amazonaws.com"
}
}
```
Permissions to create the service-linked role AWSServiceRoleForAmazonKeyspacesCDC are included in the `AmazonKeyspacesFullAccess` managed policy. For more information, see [AWS managed policy: AmazonKeyspacesFullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonKeyspacesFullAccess).
## Creating a service-linked role for Amazon Keyspaces
You don't need to manually create a service-linked role for Amazon Keyspaces CDC streams. When you enable Amazon Keyspaces CDC streams on a table with the AWS Management Console, CQL, the AWS CLI, or the AWS API, Amazon Keyspaces creates the service-linked role for you.
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you enable Amazon Keyspaces CDC streams for a table, Amazon Keyspaces creates the service-linked role for you again.
## Editing a service-linked role for Amazon Keyspaces
Amazon Keyspaces doesn’t allow you to edit the AWSServiceRoleForAmazonKeyspacesCDC service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Supported Regions for Amazon Keyspaces service-linked roles
Amazon Keyspaces supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Compliance validation for Amazon Keyspaces (for Apache Cassandra)
Third-party auditors assess the security and compliance of Amazon Keyspaces (for Apache Cassandra) as part of multiple AWS compliance programs. These include:
+ ISO/IEC 27001:2013, 27017:2015, 27018:2019, and ISO/IEC 9001:2015. For more information, see [AWS ISO and CSA STAR certifications and services](https://aws.amazon.com/compliance/iso-certified/).
+ System and Organization Controls (SOC)
+ Payment Card Industry (PCI)
+ Federal Risk and Authorization Management Program (FedRAMP) High
+ Health Insurance Portability and Accountability Act (HIPAA)
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).
# Resilience and disaster recovery in Amazon Keyspaces
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
Amazon Keyspaces replicates data automatically three times in multiple AWS Availability Zones within the same AWS Region for durability and high availability.
For more information about AWS Regions and Availability Zones, see [AWS global infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
In addition to the AWS global infrastructure, Amazon Keyspaces offers several features to help support your data resiliency and backup needs.
**multi-Region replication**
Amazon Keyspaces provides multi-Region replication if you need to replicate your data or applications over greater geographic distances. You can replicate your Amazon Keyspaces tables across different AWS Regions of your choice. For more information, see [Multi-Region replication for Amazon Keyspaces (for Apache Cassandra)](multiRegion-replication.md).
**Point-in-time recovery (PITR)**
PITR helps protect your Amazon Keyspaces tables from accidental write or delete operations by providing you continuous backups of your table data. For more information, see [Point-in-time recovery for Amazon Keyspaces](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html).
# Infrastructure security in Amazon Keyspaces
As a managed service, Amazon Keyspaces (for Apache Cassandra) is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access Amazon Keyspaces through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
Amazon Keyspaces supports two methods of authenticating client requests. The first method uses service-specific credentials, which are password based credentials generated for a specific IAM user. You can create and manage the password using the IAM console, the AWS CLI, or the AWS API. For more information, see [Using IAM with Amazon Keyspaces](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mcs.html).
The second method uses an authentication plugin for the open-source DataStax Java Driver for Cassandra. This plugin enables [IAM users, roles, and federated identities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) to add authentication information to Amazon Keyspaces (for Apache Cassandra) API requests using the [AWS Signature Version 4 process (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html). For more information, see [Create and configure AWS credentials for Amazon Keyspaces](access.credentials.md).
You can call these API operations from any network location, but Amazon Keyspaces does support resource-based access policies, which can include restrictions based on the source IP address. You can also use Amazon Keyspaces policies to control access from specific Amazon Virtual Private Cloud (Amazon VPC) endpoints or specific VPCs. Effectively, this isolates network access to a given Amazon Keyspaces resource from only the specific VPC within the AWS network.
You can use an interface VPC endpoint to keep traffic between your Amazon VPC and Amazon Keyspaces from leaving the Amazon network. Interface VPC endpoints are powered by AWS PrivateLink, an AWS technology that enables private communication between AWS services using an elastic network interface with private IPs in your Amazon VPC. For more information, see [Using Amazon Keyspaces with interface VPC endpoints](vpc-endpoints.md).
# Using Amazon Keyspaces with interface VPC endpoints
Interface VPC endpoints enable private communication between your virtual private cloud (VPC) running in Amazon VPC and Amazon Keyspaces. Interface VPC endpoints are powered by AWS PrivateLink, which is an AWS service that enables private communication between VPCs and AWS services.
AWS PrivateLink enables this by using an elastic network interface with private IP addresses in your VPC so that network traffic does not leave the Amazon network. Interface VPC endpoints don't require an internet gateway, NAT device, VPN connection, or Direct Connect connection. For more information, see [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) and [Interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html).
**Topics**
+ [
## Using interface VPC endpoints for Amazon Keyspaces
](#using-interface-vpc-endpoints)
+ [
## Populating `system.peers` table entries with interface VPC endpoint information
](#system_peers)
+ [
## Controlling access to interface VPC endpoints for Amazon Keyspaces
](#interface-vpc-endpoints-policies)
+ [
## Availability
](#availability)
+ [
## VPC endpoint policies and Amazon Keyspaces point-in-time recovery (PITR)
](#VPC_PITR_restore)
+ [
## Common errors and warnings
](#vpc_troubleshooting)
## Using interface VPC endpoints for Amazon Keyspaces
You can create an interface VPC endpoint so that traffic between Amazon Keyspaces and your Amazon VPC resources starts flowing through the interface VPC endpoint. To get started, follow the steps to [create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint). Next, edit the security group associated with the endpoint that you created in the previous step, and configure an inbound rule for port 9142. For more information, see [Adding, removing, and updating rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules).
For a step-by-step tutorial to configure a connection to Amazon Keyspaces through a VPC endpoint, see [Tutorial: Connect to Amazon Keyspaces using an interface VPC endpoint](vpc-endpoints-tutorial.md). To learn how to configure cross-account access for Amazon Keyspaces resources separated from applications in different AWS accounts in a VPC, see [Configure cross-account access to Amazon Keyspaces with VPC endpoints](access.cross-account.md).
## Populating `system.peers` table entries with interface VPC endpoint information
Apache Cassandra drivers use the `system.peers` table to query for node information about the cluster. Cassandra drivers use the node information to load balance connections and retry operations. Amazon Keyspaces populates nine entries in the `system.peers` table automatically for clients connecting through the public endpoint.
To provide clients connecting through interface VPC endpoints with similar functionality, Amazon Keyspaces populates the `system.peers` table in your account with an entry for each Availability Zone where a VPC endpoint is available. To look up and store available interface VPC endpoints in the `system.peers` table, Amazon Keyspaces requires that you grant the IAM entity used to connect to Amazon Keyspaces access permissions to query your VPC for the endpoint and network interface information.
**Important**
Populating the `system.peers` table with your available interface VPC endpoints improves load balancing and increases read/write throughput. It is recommended for all clients accessing Amazon Keyspaces using interface VPC endpoints and is required for Apache Spark.
To grant the IAM entity used to connect to Amazon Keyspaces permissions to look up the necessary interface VPC endpoint information, you can update your existing IAM role or user policy, or create a new IAM policy as shown in the following example.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ListVPCEndpoints",
"Effect":"Allow",
"Action":[
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcEndpoints"
],
"Resource":"*"
}
]
}
```
**Note**
The managed policies `AmazonKeyspacesReadOnlyAccess_v2` and `AmazonKeyspacesFullAccess` include the required permissions to let Amazon Keyspaces access the Amazon EC2 instance to read information about available interface VPC endpoints.
To confirm that the policy has been set up correctly, query the `system.peers` table to see networking information. If the `system.peers` table is empty, it could indicate that the policy hasn't been configured successfully or that you have exceeded the request rate quota for `DescribeNetworkInterfaces` and `DescribeVPCEndpoints` API actions. `DescribeVPCEndpoints` falls into the `Describe*` category and is considered a *non-mutating action*. `DescribeNetworkInterfaces` falls into the subset of *unfiltered and unpaginated non-mutating actions*, and different quotas apply. For more information, see [Request token bucket sizes and refill rates](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html#throttling-limits-rate-based) in the Amazon EC2 API Reference.
If you do see an empty table, try again a few minutes later to rule out request rate quota issues. To verify that you have configured the VPC endpoints correctly, see [My VPC endpoint connection doesn't work properly](troubleshooting.connecting.md#troubleshooting.connection.vpce). If your query returns results from the table, your policy has been configured correctly.
## Controlling access to interface VPC endpoints for Amazon Keyspaces
With VPC endpoint policies, you can control access to resources in two ways:
+ **IAM policy** – You can control the requests, users, or groups that are allowed to access Amazon Keyspaces through a specific VPC endpoint. You can do this by using a [condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the policy that is attached to an IAM user, group, or role.
+ **VPC policy** – You can control which VPC endpoints have access to your Amazon Keyspaces resources by attaching policies to them. To restrict access to a specific keyspace or table to only allow traffic coming through a specific VPC endpoint, edit the existing IAM policy that restricts resource access and add that VPC endpoint.
The following are example endpoint policies for accessing Amazon Keyspaces resources.
+ **IAM policy example: Restrict all access to a specific Amazon Keyspaces table unless traffic comes from the specified VPC endpoint** – This sample policy can be attached to an IAM user, role, or group. It restricts access to a specified Amazon Keyspaces table unless incoming traffic originates from a specified VPC endpoint.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserOrRolePolicyToDenyAccess",
"Action": "cassandra:*",
"Effect": "Deny",
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
],
"Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-abc123" } }
}
]
}
```
**Note**
To restrict access to a specific table, you must also include access to the system tables. System tables are read-only.
+ **VPC policy example: Read-only access** – This sample policy can be attached to a VPC endpoint. (For more information, see [Controlling access to Amazon VPC resources](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html#vpc-endpoint-policies)). It restricts actions to read-only access to Amazon Keyspaces resources through the VPC endpoint that it's attached to.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnly",
"Principal": "*",
"Action": [
"cassandra:Select"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
+ **VPC policy example: Restrict access to a specific Amazon Keyspaces table** – This sample policy can be attached to a VPC endpoint. It restricts access to a specific table through the VPC endpoint that it's attached to.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToTable",
"Principal": "*",
"Action": "cassandra:*",
"Effect": "Allow",
"Resource": [
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable",
"arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
]
}
]
}
```
**Note**
To restrict access to a specific table, you must also include access to the system tables. System tables are read-only.
## Availability
Amazon Keyspaces supports using interface VPC endpoints in all of the AWS Regions where the service is available. For more information, see [Service endpoints for Amazon Keyspaces](programmatic.endpoints.md).
## VPC endpoint policies and Amazon Keyspaces point-in-time recovery (PITR)
If you are using IAM policies with [condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) to restrict incoming traffic, the table restore operation may fail. For example, if you restrict source traffic to specific VPC endpoints using `aws:SourceVpce` condition keys, the table restore operation fails. To allow Amazon Keyspaces to perform a restore operation on your principal's behalf, you must add an `aws:ViaAWSService` condition key to your IAM policy. The `aws:ViaAWSService` condition key allows access when any AWS service makes a request using the principal's credentials. For more information, see [IAM JSON policy elements: Condition key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*. The following policy is an example of this.
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CassandraAccessForVPCE",
"Effect":"Allow",
"Action":"cassandra:*",
"Resource":"*",
"Condition":{
"Bool":{
"aws:ViaAWSService":"false"
},
"StringEquals":{
"aws:SourceVpce":[
"vpce-12345678901234567"
]
}
}
},
{
"Sid":"CassandraAccessForAwsService",
"Effect":"Allow",
"Action":"cassandra:*",
"Resource":"*",
"Condition":{
"Bool":{
"aws:ViaAWSService":"true"
}
}
}
]
}
```
## Common errors and warnings
**If you're using Amazon Virtual Private Cloud and you connect to Amazon Keyspaces, you might see the following warning.**
```
Control node cassandra.us-east-1.amazonaws.com/1.111.111.111:9142 has an entry for itself in system.peers: this entry will be ignored. This is likely due to a misconfiguration;
please verify your rpc_address configuration in cassandra.yaml on all nodes in your cluster.
```
This warning occurs because the `system.peers` table contains entries for all of the Amazon VPC endpoints that Amazon Keyspaces has permissions to view, including the Amazon VPC endpoint that you're connected through. You can safely ignore this warning.
For other errors, see [My VPC endpoint connection doesn't work properly](troubleshooting.connecting.md#troubleshooting.connection.vpce).
# Using Amazon Keyspaces CDC streams with interface VPC endpoints
Interface VPC endpoints enable private communication between your virtual private cloud (VPC) running in Amazon VPC and Amazon Keyspaces. Interface VPC endpoints are powered by AWS PrivateLink, which is an AWS service that enables private communication between VPCs and AWS services.
AWS PrivateLink enables this by using an elastic network interface with private IP addresses in your VPC so that network traffic does not leave the Amazon network. Interface VPC endpoints don't require an internet gateway, NAT device, VPN connection, or Direct Connect connection. For more information, see [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) and [Interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html).
**Topics**
+ [
## Using interface VPC endpoints for Amazon Keyspaces CDC streams
](#using-interface-vpc-endpoints-streams)
+ [
## Amazon Keyspaces CDC streams interface VPC endpoints
](#interface-vpc-endpoints-streams-types)
+ [
## Create Amazon Keyspaces CDC streams interface VPC endpoint
](#create-interface-vpc-endpoints-streams)
+ [
## Update an Amazon Keyspaces CDC streams interface VPC endpoint
](#update-interface-vpc-endpoints-streams)
+ [
## List streams using an Amazon Keyspaces CDC streams interface VPC endpoint
](#list-interface-vpc-endpoints-streams)
+ [
## Create a policy for an Amazon Keyspaces CDC streams interface VPC endpoint
](#interface-vpc-endpoints-streams-policy)
## Using interface VPC endpoints for Amazon Keyspaces CDC streams
You can use an interface VPC endpoint so that traffic between Amazon Keyspaces CDC streams and your Amazon VPC resources starts flowing through the interface VPC endpoint. You can use VPC endpoint policies to restrict access to your CDC streams.
For more information about Amazon Keyspaces CDC streams, see [Working with change data capture (CDC) streams in Amazon Keyspaces](cdc.md).
## Amazon Keyspaces CDC streams interface VPC endpoints
When you create an interface endpoint, Amazon Keyspaces CDC streams generates two types of endpoint-specific DNS name for the stream: *Regional* and *Zonal*.
**Regional**
The Regional DNS name includes the following information:
+ a unique Amazon VPC endpoint ID
+ a service identifier
+ the AWS Region
+ the `vpce.amazonaws.com` suffix
For an Amazon VPC endpoint with the ID `vpce-1a2b3c4d`, the generated DNS name might be look similar to the following example: `vpce-1a2b3c4d-5e6f.cassandra-streams.us-east-1.vpce.amazonaws.com`.
**Zonal**
The Zonal DNS name includes the [Availability Zone](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) in addition to the information in the Regional DNS name. The generated DNS name for the Amazon VPC endpoint with the ID `vpce-1a2b3c4d` would look like in the following example, note that the AWS Region now includes the Availability Zone: `vpce-1a2b3c4d-5e6f-us-east-1a.cassandra-streams.us-east-1.vpce.amazonaws.com`
You can use this option if your architecture isolates Availability Zones. For example, you could use it for fault containment or to reduce Regional data transfer costs.
To achieve optimal reliability, we recommend deploying your service across a minimum of three Availability Zones.
## Create Amazon Keyspaces CDC streams interface VPC endpoint
You can use the AWS CLI or the AWS SDK to access Amazon Keyspaces CDC Streams API operations through Amazon Keyspaces CDC Streams interface endpoints. For a complete listing of all available API operations, see [https://docs.aws.amazon.com/keyspaces/latest/StreamsAPIReference/Welcome.html](https://docs.aws.amazon.com/keyspaces/latest/StreamsAPIReference/Welcome.html).
For more information about how to create VPC endpoints, see [create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) in the Amazon VPC User Guide.
To create a VPC endpoint, you can use the syntax in the following example.
```
aws ec2 create-vpc-endpoint \
--region us-east-1 \
--service-name api.aws.us-east-1.cassandra-streams \
--vpc-id client-vpc-id \
--subnet-ids client-subnet-id \
--vpc-endpoint-type Interface \
--security-group-ids client-sg-id
```
## Update an Amazon Keyspaces CDC streams interface VPC endpoint
To update a VPC endpoint, you can use the syntax in the following example.
```
aws ec2 modify-vpc-endpoint \
--region us-east-1 \
--vpc-endpoint-id client-vpc-id \
--policy-document policy-document \ #example optional parameter
--add-security-group-ids security-group-ids \ #example optional parameter
```
## List streams using an Amazon Keyspaces CDC streams interface VPC endpoint
To list the streams that are using a VPC endpoint, you can use the syntax in the following example. Make sure to replace the Region and the DNS name of the VPC endpoint ID with your own information.
```
aws keyspacesstreams \
--endpoint https://vpce-1a2b3c4d-5e6f.cassandra-streams.us-east-1.vpce.amazonaws.com \
--region us-east-1 \
list-streams
```
## Create a policy for an Amazon Keyspaces CDC streams interface VPC endpoint
You can attach an endpoint policy to your Amazon VPC endpoint that controls access to Amazon Keyspaces CDC streams. The policy specifies the following information:
+ The AWS Identity and Access Management (IAM) principal that can perform actions
+ The actions that can be performed
+ The resources on which actions can be performed
To restrict access to specific Amazon Keyspaces CDC streams to only allow specific AWS services in your Amazon VPC access, you can use the following example.
The following stream policy grants access to any IAM principal for the actions `cassandra:GetStream` and `cassandra:GetRecords` for the specified stream `2025-02-20T11:22:33.444` attached to the resource `/keyspace/mykeyspace/table/mytable/` belonging to account `123456788901`. To use this endpoint policy, make sure to replace the Region, account ID, and resource with stream label.
```
{
"Version": "2012-10-17",
"Id": "Policy1216114807515",
"Statement": [
{ "Sid": "Access-to-specific-stream-only",
"Principal": "*",
"Action": [
"cassandra:GetStream",
"cassandra:GetRecords"
],
"Effect": "Allow",
"Resource": ["arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/table/mytable/stream/2025-02-20T11:22:33.444"]
}
]
}
```
**Note**
Amazon Keyspaces doesn't support Gateway endpoints for CDC streams.
# Configuration and vulnerability analysis for Amazon Keyspaces
AWS handles basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery. These procedures have been reviewed and certified by the appropriate third parties. For more details, see the following resources:
+ [Shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services: Overview of security processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)(whitepaper)
# Security best practices for Amazon Keyspaces
Amazon Keyspaces (for Apache Cassandra) provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
**Topics**
+ [
# Preventative security best practices for Amazon Keyspaces
](best-practices-security-preventative.md)
+ [
# Detective security best practices for Amazon Keyspaces
](best-practices-security-detective.md)
# Preventative security best practices for Amazon Keyspaces
The following security best practices are considered preventative because they can help you anticipate and prevent security incidents in Amazon Keyspaces.
**Use encryption at rest**
Amazon Keyspaces encrypts at rest all user data that's stored in tables by using encryption keys stored in [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/). This provides an additional layer of data protection by securing your data from unauthorized access to the underlying storage.
By default, Amazon Keyspaces uses an AWS owned key for encrypting all of your tables. If this key doesn’t exist, it's created for you. Service default keys can't be disabled.
Alternatively, you can use a [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for encryption at rest. For more information, see [Amazon Keyspaces Encryption at Rest](https://docs.aws.amazon.com/keyspaces/latest/devguide/EncryptionAtRest.html).
**Use IAM roles to authenticate access to Amazon Keyspaces**
For users, applications, and other AWS services to access Amazon Keyspaces, they must include valid AWS credentials in their AWS API requests. You should not store AWS credentials directly in the application or EC2 instance. These are long-term credentials that are not automatically rotated, and therefore could have significant business impact if they are compromised. An IAM role enables you to obtain temporary access keys that can be used to access AWS services and resources.
For more information, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html).
**Use IAM policies for Amazon Keyspaces base authorization**
When granting permissions, you decide who is getting them, which Amazon Keyspaces APIs they are getting permissions for, and the specific actions you want to allow on those resources. Implementing least privilege is key in reducing security risks and the impact that can result from errors or malicious intent.
Attach permissions policies to IAM identities (that is, users, groups, and roles) and thereby grant permissions to perform operations on Amazon Keyspaces resources.
You can do this by using the following:
+ [AWS managed (predefined) policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)
+ [Customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)
**Use IAM policy conditions for fine-grained access control**
When you grant permissions in Amazon Keyspaces, you can specify conditions that determine how a permissions policy takes effect. Implementing least privilege is key in reducing security risks and the impact that can result from errors or malicious intent.
You can specify conditions when granting permissions using an IAM policy. For example, you can do the following:
+ Grant permissions to allow users read-only access to specific keyspaces or tables.
+ Grant permissions to allow a user write access to a certain table, based upon the identity of that user.
For more information, see [Identity-Based Policy Examples](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html).
**Consider client-side encryption**
If you store sensitive or confidential data in Amazon Keyspaces, you might want to encrypt that data as close as possible to its origin so that your data is protected throughout its lifecycle. Encrypting your sensitive data in transit and at rest helps ensure that your plaintext data isn’t available to any third party.
# Detective security best practices for Amazon Keyspaces
The following security best practices are considered detective because they can help you detect potential security weaknesses and incidents.
**Use AWS CloudTrail to monitor AWS Key Management Service (AWS KMS) AWS KMS key usage**
If you're using a [customer managed AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for encryption at rest, usage of this key is logged into AWS CloudTrail. CloudTrail provides visibility into user activity by recording actions taken on your account. CloudTrail records important information about each action, including who made the request, the services used, the actions performed, parameters for the actions, and the response elements returned by the AWS service. This information helps you track changes made to your AWS resources and troubleshoot operational issues. CloudTrail makes it easier to ensure compliance with internal policies and regulatory standards.
You can use CloudTrail to audit key usage. CloudTrail creates log files that contain a history of AWS API calls and related events for your account. These log files include all AWS KMS API requests that were made using the console, AWS SDKs, and command line tools, in addition to those made through integrated AWS services. You can use these log files to get information about when the AWS KMS key was used, the operation that was requested, the identity of the requester, the IP address that the request came from, and so on. For more information, see [Logging AWS Key Management Service API Calls with AWS CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) and the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
**Use CloudTrail to monitor Amazon Keyspaces data definition language (DDL) operations**
CloudTrail provides visibility into user activity by recording actions taken on your account. CloudTrail records important information about each action, including who made the request, the services used, the actions performed, parameters for the actions, and the response elements returned by the AWS service. This information helps you to track changes made to your AWS resources and to troubleshoot operational issues. CloudTrail makes it easier to ensure compliance with internal policies and regulatory standards.
All Amazon Keyspaces [DDL operations](cql.ddl.md) are logged in CloudTrail automatically. DDL operations let you create and manage Amazon Keyspaces keyspaces and tables.
When activity occurs in Amazon Keyspaces, that activity is recorded in a CloudTrail event along with other AWS service events in the event history. For more information, see [Logging Amazon Keyspaces operations by using AWS CloudTrail](https://docs.aws.amazon.com/keyspaces/latest/devguide/logging-using-cloudtrail.html). You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in the *AWS CloudTrail User Guide*.
For an ongoing record of events in your AWS account, including events for Amazon Keyspaces, create a [trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html). A trail enables CloudTrail to deliver log files to an Amazon Simple Storage Service (Amazon S3) bucket. By default, when you create a trail on the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs.
**Tag your Amazon Keyspaces resources for identification and automation**
You can assign metadata to your AWS resources in the form of tags. Each tag is a simple label that consists of a customer-defined key and an optional value that can make it easier to manage, search for, and filter resources.
Tagging allows for grouped controls to be implemented. Although there are no inherent types of tags, they enable you to categorize resources by purpose, owner, environment, or other criteria. The following are some examples:
+ Access – Used to control access to Amazon Keyspaces resources based on tags. For more information, see [Authorization based on Amazon Keyspaces tags](security_iam_service-with-iam.md#security_iam_service-with-iam-tags).
+ Security – Used to determine requirements such as data protection settings.
+ Confidentiality – An identifier for the specific data-confidentiality level that a resource supports.
+ Environment – Used to distinguish between development, test, and production infrastructure.
For more information, see [AWS tagging strategies](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) and [Adding tags and labels to resources](https://docs.aws.amazon.com/keyspaces/latest/devguide/tagging-keyspaces.html).