# Data Protection in Amazon Managed Workflows for Apache Airflow
Data Protection

The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Managed Workflows for Apache Airflow. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You're responsible for maintaining control over your content hosted on this infrastructure. This content includes the security configuration and management tasks for the AWS services you use. For more information about data privacy, refer to the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, refer to 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 user accounts with 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 recommend TLS 1.2 or later.
+ Set up API and user activity logging with AWS CloudTrail.
+ 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 personal data that is stored in Amazon S3.

We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form fields such as a **Name** field. This includes when you work with Amazon MWAA or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form fields used for names can 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.

# Encryption on Amazon MWAA
Encryption

The following topics describe how Amazon MWAA protects your data at rest, and in transit. Use this information to learn how Amazon MWAA integrates with AWS KMS to encrypt data at rest, and how data is encrypted using Transport Layer Security (TLS) protocol in transit.

**Topics**
+ [

## Encryption at rest
](#encryption-at-rest)
+ [

## Encryption in transit
](#encryption-in-transit)

## Encryption at rest


On Amazon MWAA, data *at rest* is data that the service saves to persistent media.

You can use an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) for data at rest encryption, or optionally provide a [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for additional encryption when you create an environment. If you choose to use a customer-managed KMS key, it must be in the same account as the other AWS resources and services you are using with your environment.

To use a customer-managed KMS key, you must attach the required policy statement for CloudWatch access to your key policy. When you use a customer-managed KMS key for your environment, Amazon MWAA attaches four [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) on your behalf. For more information about the grants Amazon MWAA attaches to a customer-managed KMS key, refer to [Customer-managed keys for data encryption](custom-keys-certs.md).

If you do not specify a customer-managed KMS key, by default, Amazon MWAA uses an AWS owned KMS key for to encrypt and decrypt your data. We recommend using an AWS owned KMS key to manage data encryption on Amazon MWAA.

**Note**  
You pay for the storage and use of AWS owned, or customer-managed KMS keys on Amazon MWAA. For more information, refer to [AWS KMS Pricing](https://aws.amazon.com/kms/pricing/).

### Encryption artifacts


You specify the encryption artifacts used for at rest encryption by specifying an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) or [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) when you create your Amazon MWAA environment. Amazon MWAA adds the [grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) needed to your specified key.

**Amazon S3** – Amazon S3 data is encrypted at the object-level using Server-Side Encryption (SSE). Amazon S3 encryption and decryption takes place on the Amazon S3 bucket where your DAG code and supporting files are stored. Objects are encrypted when they are uploaded to Amazon S3 and decrypted when they are downloaded to your Amazon MWAA environment. By default, if you are using a customer-managed KMS key, Amazon MWAA uses it to read and decrypt the data on your Amazon S3 bucket.

**CloudWatch Logs** – If you are using an AWS owned KMS key, Apache Airflow logs sent to CloudWatch Logs are encrypted using SSE with CloudWatch Logs's AWS owned KMS key. If you are using a customer-managed KMS key, you must add a [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) to your KMS key to allow CloudWatch Logs to use your key.

**Amazon SQS** – Amazon MWAA creates one Amazon SQS queue for your environment. Amazon MWAA handles encrypting data passed to and from the queue using SSE with either an AWS owned KMS key, or a customer-managed KMS key that you specify. You must add Amazon SQS permissions to your execution role regardless of whether you are using an AWS owned or customer-managed KMS key.

**Aurora PostgreSQL** – Amazon MWAA creates one PostgreSQL cluster for your environment. Aurora PostgreSQL encrypts the content with either an AWS owned or customer-managed KMS key using SSE. If you are using a customer-managed KMS key, Amazon RDS adds at least two grants to the key: one for the cluster and one for the database instance. Amazon RDS can create additional grants if you choose to use your customer-managed KMS key on multiple environments. For more information, refer to [Data protection in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/DataDurability.html).

## Encryption in transit


Data in transit is referred to as data that can be intercepted as it travels the network.

Transport Layer Security (TLS) encrypts the Amazon MWAA objects in transit between your environment's Apache Airflow components and other AWS services that integrate with Amazon MWAA, such as Amazon S3. For more information about Amazon S3 encryption, refer to [Protecting data using encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html).

# Using customer-managed keys for encryption
Using customer-managed keys

You can optionally provide a [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for data encryption on your environment. You must create the customer-managed KMS key in the same Region as your Amazon MWAA environment instance and your Amazon S3 bucket where you store resources for your workflows. If the customer-managed KMS key that you specify is in a different account from the one you use to configure an environment, you must specify the key using its ARN for cross-account access. For more information about creating keys, refer to [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.

## What's supported



| AWS KMS feature | Supported | 
| --- | --- | 
|  An [AWS KMS key ID or ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html).  |  Yes  | 
|  An [AWS KMS key alias](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html).  |  No  | 
|  An [AWS KMS multi-region key](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html).  |  No  | 

## Using Grants for Encryption


This topic describes the grants Amazon MWAA attaches to a customer-managed KMS key on your behalf to encrypt and decrypt your data.

### How it works


There are two resource-based access control mechanisms supported by AWS KMS for customer-managed KMS key: a [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) and [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html).

A key policy is used when the permission is mostly static and used in synchronous service mode. A grant is used when more dynamic and granular permissions are required, such as when a service needs to define different access permissions for itself or other accounts.

Amazon MWAA uses and attaches four grant policies to your customer-managed KMS key. This is due to the granular permissions required for an environment to encrypt data at rest from CloudWatch Logs, Amazon SQS queue, Aurora PostgreSQL database database, Secrets Manager secrets, Amazon S3 bucket and DynamoDB tables.

When you create an Amazon MWAA environment and specify a customer-managed KMS key, Amazon MWAA attaches the grant policies to your customer-managed KMS key. These policies allow Amazon MWAA in `airflow.us-east-1.amazonaws.com` to use your customer-managed KMS key to encrypt resources on your behalf that are owned by Amazon MWAA.

Amazon MWAA creates, and attaches, additional grants to a specified KMS key on your behalf. This includes policies to retire a grant if you delete your environment, to use your customer-managed KMS key for Client-Side Encryption (CSE), and for the AWS Fargate execution role that needs to access secrets protected by your customer-managed key in Secrets Manager.

## Grant policies


Amazon MWAA adds the following [resource based policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) grants on your behalf to a customer-managed KMS key. These policies allow the grantee and the principal (Amazon MWAA) to perform actions defined in the policy.

### Grant 1: used to create data plane resources


```
{
  "Name": "mwaa-grant-for-env-mgmt-role-environment name",
  "GranteePrincipal": "airflow.us-east-1.amazonaws.com",
  "RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
  "Operations": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:RetireGrant"
  ]
}
```

### Grant 2: used for `ControllerLambdaExecutionRole` access


```
{
  "Name": "mwaa-grant-for-lambda-exec-environment name",
  "GranteePrincipal": "airflow.us-east-1.amazonaws.com",
  "RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
  "Operations": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey",
    "kms:RetireGrant"
  ]
}
```

### Grant 3: used for `CfnManagementLambdaExecutionRole` access


```
{
  "Name": " mwaa-grant-for-cfn-mgmt-environment name",
  "GranteePrincipal": "airflow.us-east-1.amazonaws.com",
  "RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
  "Operations": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ]
}
```

### Grant 4: used for Fargate execution role to access backend secrets


```
{
  "Name": "mwaa-fargate-access-for-environment name",
  "GranteePrincipal": "airflow.us-east-1.amazonaws.com",
  "RetiringPrincipal": "airflow.us-east-1.amazonaws.com",
  "Operations": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey",
    "kms:RetireGrant"
  ]
}
```

## Attaching key policies to a customer-managed key
Attach key policy

If you choose to use your own customer-managed KMS key with Amazon MWAA, you must attach the following policy to the key to allow Amazon MWAA to use it to encrypt your data.

If the customer-managed KMS key you used for your Amazon MWAA environment is not already configured to work with CloudWatch, you must update the [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) to allow for encrypted CloudWatch Logs. For more information, refer to the [Encrypt log data in CloudWatch using AWS Key Management Service service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html).

The following example represents a key policy for CloudWatch Logs. Substitute the sample values provided for the region.

```
{
  "Effect": "Allow",
  "Principal": {
    "Service": "logs.us-east-1.amazonaws.com"
  },
  "Action": [
    "kms:Encrypt*",
    "kms:Decrypt*",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:Describe*"
  ],
  "Resource": "*",
  "Condition": {
    "ArnLike": {
      "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:us-east-1:*:*"
    }
  }
}
```