# Managing access to an Amazon MWAA environment
Amazon Managed Workflows for Apache Airflow needs to be permitted to use other AWS services and resources used by an environment. You also need to be granted permission to access an Amazon MWAA environment and your Apache Airflow UI in AWS Identity and Access Management (IAM). This section describes the execution role used to grant access to the AWS resources for your environment and how to add permissions, and the AWS account permissions you need to access your Amazon MWAA environment and Apache Airflow UI.
**Topics**
+ [Accessing an Amazon MWAA environment](access-policies.md)
+ [Service-linked role for Amazon MWAA](mwaa-slr.md)
+ [Amazon MWAA execution role](mwaa-create-role.md)
+ [Cross-service confused deputy prevention](cross-service-confused-deputy-prevention.md)
+ [Apache Airflow access modes](configuring-networking.md)
# Accessing an Amazon MWAA environment
To use Amazon Managed Workflows for Apache Airflow, you must use an account and IAM entities with the necessary permissions. This topic describes the access policies you can attach to your Apache Airflow development team and Apache Airflow users for your Amazon Managed Workflows for Apache Airflow environment.
We recommend using temporary credentials and configuring federated identities with groups and roles to access your Amazon MWAA resources. As a best practice, avoid attaching policies directly to your IAM users. Instead, define groups or roles to provide temporary access to AWS resources.
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user in that it is an AWS identity with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [ Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [ Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center User Guide*.
You can use an IAM role in your account to grant another AWS account permissions to access your account's resources. For an example, see [IAM tutorial: Delegate access across AWS accounts using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) in the *IAM User Guide*.
**Topics**
+ [How it works](#access-policies-how)
+ [Full console access policy: AmazonMWAAFullConsoleAccess](#console-full-access)
+ [Full API and console access policy: AmazonMWAAFullApiAccess](#full-access-policy)
+ [Read-only console access policy: AmazonMWAAReadOnlyAccess](#mwaa-read-only)
+ [Apache Airflow UI access policy: AmazonMWAAWebServerAccess](#web-ui-access)
+ [Apache Airflow Rest API access policy: AmazonMWAARestAPIAccess](#rest-api-access)
+ [Apache Airflow CLI policy: AmazonMWAAAirflowCliAccess](#cli-access)
+ [Creating a JSON policy](#access-policy-iam-console-create)
+ [Example use case to attach policies to a developer group](#access-policy-use-case)
+ [What's next?](#access-policy-next-up)
## How it works
The resources and services used in an Amazon MWAA environment are not accessible to all AWS Identity and Access Management (IAM) entities. You must create a policy that grants Apache Airflow users permission to access these resources. For example, you need to grant access to your Apache Airflow development team.
Amazon MWAA uses these policies to validate whether a user has the permissions needed to perform an action on the AWS console or through the APIs used by an environment.
You can use the JSON policies in this topic to create a policy for your Apache Airflow users in IAM, and then attach the policy to a user, group, or role in IAM.
+ [AmazonMWAAFullConsoleAccess](#console-full-access) – Use this policy to grant permission to configure an environment on the Amazon MWAA console.
+ [AmazonMWAAFullApiAccess](#full-access-policy) – Use this policy to grant access to all Amazon MWAA APIs used to manage an environment.
+ [AmazonMWAAReadOnlyAccess](#mwaa-read-only) – Use this policy to grant access to the resources used by an environment on the Amazon MWAA console.
+ [AmazonMWAAWebServerAccess](#web-ui-access) – Use this policy to grant access to the Apache Airflow webserver.
+ [AmazonMWAAAirflowCliAccess](#cli-access) – Use this policy to grant access to run Apache Airflow CLI commands.
To provide access, add permissions to your users, groups, or roles:
+ Users and groups in AWS IAM Identity Center:
Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*.
+ Users managed in IAM through an identity provider:
Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*.
+ IAM users:
+ Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
+ (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
## Full console access policy: AmazonMWAAFullConsoleAccess
A user might need access to the `AmazonMWAAFullConsoleAccess` permissions policy if they need to configure an environment on the Amazon MWAA console.
**Note**
Your full console access policy must include permissions to perform `iam:PassRole`. This allows the user to pass [service-linked roles](mwaa-slr.md), and [execution roles](mwaa-create-role.md), to Amazon MWAA. Amazon MWAA assumes each role to call other AWS services on your behalf. The following example uses the `iam:PassedToService` condition key to specify the Amazon MWAA service principal (`airflow.amazonaws.com`) as the service to which a role can be passed.
For more information about `iam:PassRole`, refer to [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*.
Use the following policy if you want to create, and manage, your Amazon MWAA environments using an [AWS owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) for [encryption at-rest](encryption.md#encryption-at-rest).
### Using an AWS owned key
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "airflow:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:PassedToService": "airflow.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy"
],
"Resource": "arn:aws:iam::111122223333:policy/service-role/MWAA-Execution-Policy*"
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AmazonMWAA*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/airflow.amazonaws.com/AWSServiceRoleForAmazonMWAA"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"s3:ListBucketVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutObject",
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeRouteTables"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup"
],
"Resource": "arn:aws:ec2:*:*:security-group/airflow-security-group-*"
},
{
"Effect": "Allow",
"Action": [
"kms:ListAliases"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateVpcEndpoint",
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
Use the following policy if you want to create, and manage, your Amazon MWAA environments using a [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for encryption at-rest. To use a customer managed key, the IAM principal must have permission to access AWS KMS resources using the key stored in your account.
### Using a customer managed key
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "airflow:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:PassedToService": "airflow.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreatePolicy"
],
"Resource": "arn:aws:iam::111122223333:policy/service-role/MWAA-Execution-Policy*"
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AmazonMWAA*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/airflow.amazonaws.com/AWSServiceRoleForAmazonMWAA"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"s3:ListBucketVersions"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutObject",
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeRouteTables"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup"
],
"Resource": "arn:aws:ec2:*:*:security-group/airflow-security-group-*"
},
{
"Effect": "Allow",
"Action": [
"kms:ListAliases"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:ListGrants",
"kms:CreateGrant",
"kms:RevokeGrant",
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey*",
"kms:ReEncrypt*"
],
"Resource": "arn:aws:kms:*:111122223333:key/YOUR_KMS_ID"
},
{
"Effect": "Allow",
"Action": "ec2:CreateVpcEndpoint",
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
## Full API and console access policy: AmazonMWAAFullApiAccess
A user might need access to the `AmazonMWAAFullApiAccess` permissions policy if they need access to all Amazon MWAA APIs used to manage an environment. It does not grant permissions to access the Apache Airflow UI.
**Note**
A full API access policy must include permissions to perform `iam:PassRole`. This allows the user to pass [service-linked roles](mwaa-slr.md), and [execution roles](mwaa-create-role.md), to Amazon MWAA. Amazon MWAA assumes each role to call other AWS services on your behalf. The following example uses the `iam:PassedToService` condition key to specify the Amazon MWAA service principal (`airflow.amazonaws.com`) as the service to which a role can be passed.
For more information about `iam:PassRole`, refer to [Granting a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*.
Use the following policy if you want to create, and manage, your Amazon MWAA environments using an AWS owned key for encryption at-rest.
### Using an AWS owned key
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"airflow:*",
"Resource":"*"
},
{
"Effect":"Allow",
"Action":[
"iam:PassRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:PassedToService":"airflow.amazonaws.com"
}
}
},
{
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"arn:aws:iam::*:role/aws-service-role/airflow.amazonaws.com/AWSServiceRoleForAmazonMWAA"
},
{
"Effect":"Allow",
"Action":[
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeRouteTables"
],
"Resource":"*"
},
{
"Effect":"Allow",
"Action":[
"s3:GetEncryptionConfiguration"
],
"Resource":"arn:aws:s3:::*"
},
{
"Effect":"Allow",
"Action":"ec2:CreateVpcEndpoint",
"Resource":[
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect":"Allow",
"Action":[
"ec2:CreateNetworkInterface"
],
"Resource":[
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
Use the following policy if you want to create, and manage, your Amazon MWAA environments using a customer managed key for encryption at-rest. To use a customer managed key, the IAM principal must have permission to access AWS KMS resources using the key stored in your account.
### Using a customer managed key
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "airflow:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:PassedToService": "airflow.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/airflow.amazonaws.com/AWSServiceRoleForAmazonMWAA"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeRouteTables"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:ListGrants",
"kms:CreateGrant",
"kms:RevokeGrant",
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey*",
"kms:ReEncrypt*"
],
"Resource": "arn:aws:kms:*:111122223333:key/YOUR_KMS_ID"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateVpcEndpoint",
"Resource": [
"arn:aws:ec2:*:*:vpc-endpoint/*",
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
------
## Read-only console access policy: AmazonMWAAReadOnlyAccess
A user might need access to the `AmazonMWAAReadOnlyAccess` permissions policy if they need to access the resources used by an environment on the Amazon MWAA console environment details page. It doesn't allow a user to create new environments, edit existing environments, or allow a user to access the Apache Airflow UI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"airflow:ListEnvironments",
"airflow:GetEnvironment",
"airflow:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
## Apache Airflow UI access policy: AmazonMWAAWebServerAccess
A user might need access to the `AmazonMWAAWebServerAccess` permissions policy if they need to access the Apache Airflow UI. It does not allow the user to access environments on the Amazon MWAA console or use the Amazon MWAA APIs to perform any actions. Specify the `Admin`, `Op`, `User`, `Viewer` or the `Public` role in `{airflow-role}` to customize the level of access for the user of the web token. For more information, refer to [Default Roles](https://airflow.apache.org/docs/apache-airflow/1.10.6/security.html?highlight=ldap#default-roles) in the *Apache Airflow reference guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "airflow:CreateWebLoginToken",
"Resource": [
"arn:aws:airflow:us-east-1:111122223333:role/{your-environment-name}/{airflow-role}"
]
}
]
}
```
------
**Note**
Amazon MWAA provides IAM integration with the five [default Apache Airflow role-based access control (RBAC) roles](https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html?highlight=roles). For more information about working with custom Apache Airflow roles, refer to [Tutorial: Restricting an Amazon MWAA user's access to a subset of DAGs](limit-access-to-dags.md).
The `Resource` field in this policy can be used to specify the Apache Airflow role-based access control roles for the Amazon MWAA environment. However, it does not support the Amazon MWAA environment ARN (Amazon Resource Name) in the `Resource` field of the policy.
## Apache Airflow Rest API access policy: AmazonMWAARestAPIAccess
To access the Apache Airflow REST API, you must grant the `airflow:InvokeRestApi` permission in your IAM policy. In the following policy sample, specify the `Admin`, `Op`, `User`, `Viewer` or the `Public` role in `{airflow-role}` to customize the level of user access. For more information, refer to [Default Roles](https://airflow.apache.org/docs/apache-airflow/1.10.6/security.html?highlight=ldap#default-roles) in the *Apache Airflow reference guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowMwaaRestApiAccess",
"Effect": "Allow",
"Action": "airflow:InvokeRestApi",
"Resource": [
"arn:aws:airflow:us-east-1:111122223333:role/{your-environment-name}/{airflow-role}"
]
}
]
}
```
------
**Note**
While configuring a private webserver, the `InvokeRestApi` action cannot be invoked from outside of a Virtual Private Cloud (VPC). You can use the `aws:SourceVpc` key to apply more granular access control for this operation. For more information, refer to [aws:SourceVpc](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc)
The `Resource` field in this policy can be used to specify the Apache Airflow role-based access control roles for the Amazon MWAA environment. However, it does not support the Amazon MWAA environment ARN (Amazon Resource Name) in the `Resource` field of the policy.
## Apache Airflow CLI policy: AmazonMWAAAirflowCliAccess
A user might need access to the `AmazonMWAAAirflowCliAccess` permissions policy if they need to run Apache Airflow CLI commands (such as `trigger_dag`). It does not allow the user to access environments on the Amazon MWAA console or use the Amazon MWAA APIs to perform any actions.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"airflow:CreateCliToken"
],
"Resource": "arn:aws:airflow:us-east-1:111122223333:environment/${EnvironmentName}"
}
]
}
```
------
## Creating a JSON policy
You can create the JSON policy, and attach the policy to your user, role, or group on the IAM console. The following steps describe how to create a JSON policy in IAM.
**To create the JSON policy**
1. Open the [Policies page](https://console.aws.amazon.com/iam/home#/policies) on the IAM console.
1. Choose **Create policy**.
1. Choose the **JSON** tab.
1. Add your JSON policy.
1. Choose **Review policy**.
1. Enter a value in the text field for **Name** and **Description** (optional).
For example, you can name the policy `AmazonMWAAReadOnlyAccess`.
1. Choose **Create policy**.
## Example use case to attach policies to a developer group
Let's say you're using a group in IAM named `AirflowDevelopmentGroup` to apply permissions to all of the developers on your Apache Airflow development team. These users need access to the `AmazonMWAAFullConsoleAccess`, `AmazonMWAAAirflowCliAccess`, and `AmazonMWAAWebServerAccess` permission policies. This section describes how to create a group in IAM, create and attach these policies, and associate the group to an IAM user. The steps assume you're using an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk).
**To create the AmazonMWAAFullConsoleAccess policy**
1. Download the [AmazonMWAAFullConsoleAccess access policy](./samples/AmazonMWAAFullConsoleAccess.zip).
1. Open the [Policies page](https://console.aws.amazon.com/iam/home#/policies) on the IAM console.
1. Choose **Create policy**.
1. Choose the **JSON** tab.
1. Paste the JSON policy for `AmazonMWAAFullConsoleAccess`.
1. Substitute the following values:
1. *123456789012* – Your AWS account ID (such as `0123456789`)
1. *\$1your-kms-id\$1* – The unique identifer for a customer managed key, applicable only if you use a customer managed key for encryption at-rest.
1. Choose the **Review policy**.
1. Type `AmazonMWAAFullConsoleAccess` in **Name**.
1. Choose **Create policy**.
**To create the AmazonMWAAWebServerAccess policy**
1. Download the [AmazonMWAAWebServerAccess access policy](./samples/AmazonMWAAWebServerAccess.zip).
1. Open the [Policies page](https://console.aws.amazon.com/iam/home#/policies) on the IAM console.
1. Choose **Create policy**.
1. Choose the **JSON** tab.
1. Paste the JSON policy for `AmazonMWAAWebServerAccess`.
1. Substitute the following values:
1. *us-east-1* – the region of your Amazon MWAA environment (such as `us-east-1`)
1. *123456789012* – your AWS account ID (such as `0123456789`)
1. *\$1your-environment-name\$1* – your Amazon MWAA environment name (such as `MyAirflowEnvironment`)
1. *\$1airflow-role\$1* – the `Admin` Apache Airflow [Default Role](https://airflow.apache.org/docs/apache-airflow/1.10.6/security.html?highlight=ldap#default-roles)
1. Choose **Review policy**.
1. Type `AmazonMWAAWebServerAccess` in **Name**.
1. Choose **Create policy**.
**To create the AmazonMWAAAirflowCliAccess policy**
1. Download the [AmazonMWAAAirflowCliAccess access policy](./samples/AmazonMWAAAirflowCliAccess.zip).
1. Open the [Policies page](https://console.aws.amazon.com/iam/home#/policies) on the IAM console.
1. Choose **Create policy**.
1. Choose the **JSON** tab.
1. Paste the JSON policy for `AmazonMWAAAirflowCliAccess`.
1. Choose the **Review policy**.
1. Type `AmazonMWAAAirflowCliAccess` in **Name**.
1. Choose **Create policy**.
**To create the group**
1. Open the [Groups page](https://console.aws.amazon.com/iam/home#/groups) on the IAM console.
1. Enter a name of `AirflowDevelopmentGroup`.
1. Choose **Next Step**.
1. Type `AmazonMWAA` to filter results in **Filter**.
1. Select the three policies you created.
1. Choose **Next Step**.
1. Choose **Create Group**.
**To associate to a user**
1. Open the [Users page](https://console.aws.amazon.com/iam/home#/users) on the IAM console.
1. Choose a user.
1. Choose **Groups**.
1. Choose **Add user to groups**.
1. Select the **AirflowDevelopmentGroup**.
1. Choose **Add to Groups**.
## What's next?
+ Learn how to generate a token to access the Apache Airflow UI in [Accessing Apache Airflow](access-airflow-ui.md).
+ Learn more about creating IAM policies in [Creating IAM policies](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html).
# Service-linked role for Amazon MWAA
Amazon Managed Workflows for Apache Airflow 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 MWAA. Service-linked roles are predefined by Amazon MWAA 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 MWAA easier because you do not need to manually add the necessary permissions. Amazon MWAA defines the permissions of its service-linked roles, and unless defined otherwise, only Amazon MWAA 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 their related resources. This protects your Amazon MWAA resources because you can't inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, refer to [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and search for the services that have **Yes **in the **Service-linked roles** column. Choose a **Yes** with a link to access the service-linked role documentation for that service.
## Service-linked role permissions for Amazon MWAA
Amazon MWAA uses the service-linked role named `AWSServiceRoleForAmazonMWAA` – The service-linked role created in your account grants Amazon MWAA access to the following AWS services:
+ Amazon CloudWatch Logs (CloudWatch Logs) – To create log groups for Apache Airflow logs.
+ Amazon CloudWatch (CloudWatch) – To publish metrics related to your environment and its underlying components to your account.
+ Amazon Elastic Compute Cloud (Amazon EC2) – To create the following resources:
+ An Amazon VPC endpoint in your VPC for an AWS-managed Amazon Aurora PostgreSQL database cluster to be used by the Apache Airflow scheduler and worker.
+ An additional Amazon VPC endpoint to enable network access to the webserver if you choose the [private network](configuring-networking.md) option for your Apache Airflow webserver.
+ [Elastic Network Interfaces (ENIs)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) in your Amazon VPC to enable network access to AWS resources hosted in your Amazon VPC.
The following trust policy allows the service principal to assume the service-linked role. The service principal for Amazon MWAA is `airflow.amazonaws.com` as demonstrated by the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "airflow.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
The role permissions policy named `AmazonMWAAServiceRolePolicy` allows Amazon MWAA to complete the following actions on the specified resources:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:DescribeLogGroups"
],
"Resource": "arn:aws:logs:*:*:log-group:airflow-*:*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AttachNetworkInterface",
"ec2:CreateNetworkInterface",
"ec2:CreateNetworkInterfacePermission",
"ec2:DeleteNetworkInterface",
"ec2:DeleteNetworkInterfacePermission",
"ec2:DescribeDhcpOptions",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs",
"ec2:DetachNetworkInterface"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateVpcEndpoint",
"Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": "AmazonMWAAManaged"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifyVpcEndpoint",
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
"Condition": {
"Null": {
"aws:ResourceTag/AmazonMWAAManaged": false
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint",
"ec2:ModifyVpcEndpoint"
],
"Resource": [
"arn:aws:ec2:*:*:vpc/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:subnet/*"
]
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "AmazonMWAAManaged"
}
}
},
{
"Effect": "Allow",
"Action": "cloudwatch:PutMetricData",
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": [
"AWS/MWAA"
]
}
}
}
]
}
```
------
You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, refer to [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 MWAA
You don't need to manually create a service-linked role. When you create a new Amazon MWAA environment using the AWS Management Console, the AWS CLI, or the AWS API, Amazon MWAA 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 another environment, Amazon MWAA creates the service-linked role for you again.
## Editing a service-linked role for Amazon MWAA
Amazon MWAA does not permit editing the AWSServiceRoleForAmazonMWAA 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, refer to [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 MWAA
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.
When you delete an Amazon MWAA environment, Amazon MWAA deletes all the associated resources it uses as a part of the service. However, you must wait before Amazon MWAA completes deleting your environment, before attempting to delete the service-linked role. If you delete the service-linked role before Amazon MWAA deletes the environment, Amazon MWAA might be unable to delete all of the environment's associated resources.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForAmazonMWAA service-linked role. For more information, refer to [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 MWAA service-linked roles
Amazon MWAA supports using service-linked roles in all of the regions where the service is available. For more information, refer to [Amazon Managed Workflows for Apache Airflow endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/mwaa.html).
## Policy updates
| Change | Description | Date |
| --- | --- | --- |
| Amazon MWAA update its service-linked role permission policy | [`AmazonMWAAServiceRolePolicy`](#mwaa-slr-iam-policy) – Amazon MWAA updates the permission policy for its service-linked role to grant Amazon MWAA permission to publish additional metrics related to the service's underlying resources to customer accounts. These new metrics are published in the `AWS/MWAA` | November 18, 2022 |
| Amazon MWAA started tracking changes | Amazon MWAA started tracking changes for its AWS-managed service-linked role permission policy. | November 18, 2022 |
# Amazon MWAA execution role
An execution role is an AWS Identity and Access Management (IAM) role with a permissions policy that grants Amazon Managed Workflows for Apache Airflow permission to invoke the resources of other AWS services on your behalf. This can include resources such as your Amazon S3 bucket, [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), and CloudWatch Logs. Amazon MWAA environments need one execution role per environment. This topic describes how to use and configure the execution role for your environment to allow Amazon MWAA to access other AWS resources used by your environment.
**Contents**
+ [Execution role overview](#mwaa-create-role-how)
+ [Permissions attached by default](#mwaa-create-role-how-create-role)
+ [How to add permission to use other AWS services](#mwaa-create-role-how-adding)
+ [How to associate a new execution role](#mwaa-create-role-how-associating)
+ [Create a new role](#mwaa-create-role-mwaa-onconsole)
+ [Access and update an execution role policy](#mwaa-create-role-update)
+ [Attach a JSON policy to use other AWS services](#mwaa-create-role-attach-json-policy)
+ [Grant access to Amazon S3 bucket with account-level public access block](#mwaa-create-role-s3-publicaccessblock)
+ [Use Apache Airflow connections](#mwaa-create-role-airflow-connections)
+ [Sample JSON policies for an execution role](#mwaa-create-role-json)
+ [Sample policy for a customer-managed key](#mwaa-create-role-cmk)
+ [Sample policy for an AWS-owned key](#mwaa-create-role-aocmk)
+ [What's next?](#mwaa-create-role-next-up)
## Execution role overview
Permission for Amazon MWAA to use other AWS services used by your environment comes from the execution role. An Amazon MWAA execution role needs permission to the following AWS services used by an environment:
+ Amazon CloudWatch (CloudWatch) – to send Apache Airflow metrics and logs.
+ Amazon Simple Storage Service (Amazon S3) – to parse your environment's DAG code and supporting files (such as a `requirements.txt`).
+ Amazon Simple Queue Service (Amazon SQS) – to queue your environment's Apache Airflow tasks in an Amazon SQS queue owned by Amazon MWAA.
+ AWS Key Management Service (AWS KMS) – for your environment's data encryption (using either an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) or your [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)).
**Note**
If you have elected for Amazon MWAA to use an AWS owned KMS key to encrypt your data, then you must define permissions in a policy attached to your Amazon MWAA execution role that grant access to arbitrary KMS keys stored outside of your account through Amazon SQS. The following two conditions are required in order for your environment's execution role to access arbitrary KMS keys:
A KMS key in a third-party account needs to allow this cross account access through its resource policy.
Your DAG code needs to access an Amazon SQS queue that starts with `airflow-celery-` in the third-party account and uses the same KMS key for encryption.
To mitigate the risks associated with cross-account access to resources, we recommend reviewing the code placed in your DAGs to ensure that your workflows are not accessing arbitrary Amazon SQS queues outside your account. Furthermore, you can use a customer-managed KMS key stored in your own account to manage encryption on Amazon MWAA. This limits your environment's execution role to access only the KMS key in your account.
Keep in mind that after you choose an encryption option, you cannot change your selection for an existing environment.
An execution role also needs permission to the following IAM actions:
+ `airflow:PublishMetrics` – to allow Amazon MWAA to monitor the health of an environment.
### Permissions attached by default
You can use the default options on the Amazon MWAA console to create an execution role and an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), then use the steps on this page to add permission policies to your execution role.
+ When you choose the **Create new role** option on the console, Amazon MWAA attaches the minimal permissions needed by an environment to your execution role.
+ In some cases, Amazon MWAA attaches the maximum permissions. For example, we recommend choosing the option on the Amazon MWAA console to create an execution role when you create an environment. Amazon MWAA adds the permissions policies for all CloudWatch Logs groups automatically by using the regex pattern in the execution role as `"arn:aws:logs:us-east-1:111122223333:log-group:airflow-your-environment-name-*"`.
### How to add permission to use other AWS services
Amazon MWAA can't add or edit permission policies to an existing execution role after an environment is created. You must update your execution role with additional permission policies needed by your environment. For example, if your DAG requires access to AWS Glue, Amazon MWAA can't automatically detect these permissions are required by your environment, or add the permissions to your execution role.
You can add permissions to an execution role in two ways:
+ By modifying the JSON policy for your execution role inline. You can use the sample [JSON policy documents](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html) on this page to either add to or replace the JSON policy of your execution role on the IAM console.
+ By creating a JSON policy for an AWS service and attaching it to your execution role. You can use the steps on this page to associate a new JSON policy document for an AWS service to your execution role on the IAM console.
Assuming the execution role is already associated to your environment, Amazon MWAA can start using the added permission policies immediately. This also means if you remove any required permissions from an execution role, your DAGs might fail.
### How to associate a new execution role
You can change the execution role for your environment at any time. If a new execution role is not already associated with your environment, use the steps on this page to create a new execution role policy, and associate the role to your environment.
## Create a new role
By default, Amazon MWAA creates an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) for data encryption and an execution role on your behalf. You can choose the default options on the Amazon MWAA console when you create an environment. The following image displays the default option to create an execution role for an environment.
![\[This is an image with the default option to create a new role.\]](http://docs.aws.amazon.com/mwaa/latest/userguide/images/mwaa-console-permissions.png)
**Important**
When you create a new execution role, do not reuse the name of a deleted execution role. Unique names can help prevent conflicts and ensure proper resource management.
## Access and update an execution role policy
You can access the execution role for your environment on the Amazon MWAA console, and update the JSON policy for the role on the IAM console.
**To update an execution role policy**
1. Open the [Environments](https://console.aws.amazon.com/mwaa/home#/environments) page on the Amazon MWAA console.
1. Choose an environment.
1. Choose the execution role on the **Permissions** pane to open the permissions page in IAM.
1. Choose the execution role name to open the permissions policy.
1. Choose **Edit policy**.
1. Choose the **JSON** tab.
1. Update your JSON policy.
1. Choose **Review policy**.
1. Choose **Save changes**.
### Attach a JSON policy to use other AWS services
You can create a JSON policy for an AWS service and attach it to your execution role. For example, you can attach the following JSON policy to grant read-only access to all resources in AWS Secrets Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"secretsmanager:GetResourcePolicy",
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecretVersionIds"
],
"Resource":[
"*"
]
}
]
}
```
------
**To attach a policy to your execution role**
1. Open the [Environments](https://console.aws.amazon.com/mwaa/home#/environments) page on the Amazon MWAA console.
1. Choose an environment.
1. Choose your execution role on the **Permissions** pane.
1. Choose **Attach policies**.
1. Choose **Create policy**.
1. Choose **JSON**.
1. Paste the JSON policy.
1. Choose **Next: Tags**, **Next: Review**.
1. Enter a descriptive name (such as `SecretsManagerReadPolicy`) and a description for the policy.
1. Choose **Create policy**.
## Grant access to Amazon S3 bucket with account-level public access block
You might want to block access to all buckets in your account by using the [https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutPublicAccessBlock.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_control_PutPublicAccessBlock.html) Amazon S3 operation. When you block access to all buckets in your account, your environment execution role must include the `s3:GetAccountPublicAccessBlock` action in a permission policy.
The following example demonstrates the policy you must attach to your execution role when blocking access to all Amazon S3 buckets in your account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetAccountPublicAccessBlock",
"Resource": "*"
}
]
}
```
------
For more information about restricting access to your Amazon S3 buckets, refer to [Blocking public access to your Amazon S3 storage](https://docs.aws.amazon.com/) in the *Amazon Simple Storage Service User Guide*.
## Use Apache Airflow connections
You can also create an Apache Airflow connection and specify your execution role and its ARN in your Apache Airflow connection object. To learn more, refer to [Managing connections to Apache Airflow](manage-connections.md).
## Sample JSON policies for an execution role
You can use the two sample permission policies in this section to replace the permissions policy used for your existing execution role, or to create a new execution role and use for your environment. These policies contain [Resource ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) placeholders for Apache Airflow log groups, an [Amazon S3 bucket](mwaa-s3-bucket.md), and an [Amazon MWAA environment](create-environment.md).
We recommend copying the example policy, replacing the sample ARNs or placeholders, then using the JSON policy to create or update an execution role.
### Sample policy for a customer-managed key
The following example presents an execution role policy you can use for an [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:ListAllMyBuckets",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:GetBucket*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:GetLogRecord",
"logs:GetLogGroupFields",
"logs:GetQueryResults"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:airflow-your-environment-name:*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": "cloudwatch:PutMetricData",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:us-east-1:*:airflow-celery-*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey*",
"kms:Encrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/your-kms-cmk-id",
"Condition": {
"StringLike": {
"kms:ViaService": [
"sqs.us-east-1.amazonaws.com",
"s3.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
Next, you need to allow Amazon MWAA to assume this role to perform actions on your behalf. This can be done by adding `"airflow.amazonaws.com"` and `"airflow-env.amazonaws.com"` service principals to the list of trusted entities for this execution role [using the IAM console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html#roles-creatingrole-service-console), or by placing these service principals in the assume role policy document for this execution role through the IAM [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) command using the AWS CLI. Refer to the following sample assume role policy document:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": ["airflow.amazonaws.com","airflow-env.amazonaws.com"]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Then attach the following JSON policy to your [Customer-managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk). This policy uses the [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context) condition key prefix to permit access to your Apache Airflow logs group in CloudWatch Logs.
```
{
"Sid": "Allow logs access",
"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:111122223333:*"
}
}
}
```
### Sample policy for an AWS-owned key
The following example presents an execution role policy you can use for an [AWS-owned key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "airflow:PublishMetrics",
"Resource": "arn:aws:airflow:us-east-1:111122223333:environment/{your-environment-name}"
},
{
"Effect": "Deny",
"Action": "s3:ListAllMyBuckets",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:GetBucket*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:PutLogEvents",
"logs:GetLogEvents",
"logs:GetLogRecord",
"logs:GetLogGroupFields",
"logs:GetQueryResults"
],
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:airflow-{your-environment-name}-*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetAccountPublicAccessBlock"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": "cloudwatch:PutMetricData",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:GetQueueUrl",
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "arn:aws:sqs:us-east-1:*:airflow-celery-*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey*",
"kms:Encrypt"
],
"NotResource": "arn:aws:kms:*:111122223333:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"sqs.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## What's next?
+ Learn about the required permissions you and your Apache Airflow users need to access your environment in [Accessing an Amazon MWAA environment](access-policies.md).
+ Learn about [Using customer-managed keys for encryption](custom-keys-certs.md).
+ Explore more [Customer-managed policy examples](https://docs.aws.amazon.com/kms/latest/developerguide/customer-managed-policies.html).
# Cross-service confused deputy prevention
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it does not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.
We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in your environment's execution role to limit the permissions that Amazon MWAA gives another service to access the resource. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use.
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcard characters (`*`) for the unknown portions of the ARN. For example, `arn:aws:airflow:*:123456789012:environment/*`.
The value of `aws:SourceArn` must be your Amazon MWAA environment ARN, for which you are creating an execution role.
Use the following example to apply the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in your environment's execution role trust policy to prevent the confused deputy problem. You can use the following trust policy when you create a new execution role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"airflow.amazonaws.com",
"airflow-env.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:airflow:us-east-1:123456789012:environment/your-environment-name"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
------
# Apache Airflow access modes
The Amazon Managed Workflows for Apache Airflow console contains built-in options to configure private or public routing to the Apache Airflow webserver on your environment. This guide describes the access modes available for the Apache Airflow webserver on your Amazon Managed Workflows for Apache Airflow environment, and the additional resources you'll need to configure in your Amazon VPC if you choose the private network option.
**Contents**
+ [Apache Airflow access modes](#configuring-networking-onconsole)
+ [Public network](#webserver-options-public-network-onconsole)
+ [Private network](#webserver-options-private-network)
+ [Access modes overview](#configuring-networking-access-overview)
+ [Public network access mode](#access-overview-public)
+ [Private network access mode](#access-overview-private)
+ [Setup for private and public access modes](#access-network-choose)
+ [Setup for public network](#access-network-public)
+ [Setup for private network](#access-network-private)
+ [Accessing the VPC endpoint for your Apache Airflow webserver (private network access)](#configuring-access-vpce)
## Apache Airflow access modes
You can choose private or public routing for your Apache Airflow webserver. To enable private routing, choose **Private network**. This limits user access to an Apache Airflow webserver within an Amazon VPC. To enable public routing, choose **Public network**. This allows users to access the Apache Airflow webserver over the internet.
### Public network
The following architectural diagram depicts an Amazon MWAA environment with a public webserver.
![\[This image displays the architecture for an Amazon MWAA environment with a private webserver.\]](http://docs.aws.amazon.com/mwaa/latest/userguide/images/mwaa-public-web-server.png)
The public network access mode allows the Apache Airflow UI to be accessed over the internet by users granted access to the [IAM policy for your environment](access-policies.md).
The following image depicts where to find the **Public network** option on the Amazon MWAA console.
![\[This image depicts where to find the Public network option on the Amazon MWAA console.\]](http://docs.aws.amazon.com/mwaa/latest/userguide/images/mwaa-console-public-network.png)
### Private network
The following architectural diagram depicts an Amazon MWAA environment with a private webserver.
![\[This image displays the architecture for an Amazon MWAA environment with a private webserver.\]](http://docs.aws.amazon.com/mwaa/latest/userguide/images/mwaa-private-web-server.png)
The private network access mode limits access to the Apache Airflow UI to users *within your Amazon VPC* that have been granted access to the [IAM policy for your environment](access-policies.md).
When you create an environment with private webserver access, you must package all of your dependencies in a Python wheel archive (`.whl`), then reference the `.whl` in your `requirements.txt`. For instructions on packaging and installing your dependencies using wheel, refer to [Managing dependencies using Python wheel](best-practices-dependencies.md#best-practices-dependencies-python-wheels).
The following image depicts where to find the **Private network** option on the Amazon MWAA console.
![\[This image depicts where to find the Private network option on the Amazon MWAA console.\]](http://docs.aws.amazon.com/mwaa/latest/userguide/images/mwaa-console-private-network.png)
## Access modes overview
This section describes the VPC endpoints (AWS PrivateLink) created in your Amazon VPC when you choose the **Public network** or **Private network** access mode.
### Public network access mode
If you chose the **Public network** access mode for your Apache Airflow webserver, network traffic is publicly routed over the internet.
+ Amazon MWAA creates a VPC interface endpoint for your Amazon Aurora PostgreSQL metadata database. The endpoint is created in the Availability Zones mapped to your private subnets and is independent from other AWS accounts.
+ Amazon MWAA then binds an IP address from your private subnets to the interface endpoints. This is designed to support the best practice of binding a single IP from each Availability Zone of the Amazon VPC.
### Private network access mode
If you chose the **Private network** access mode for your Apache Airflow webserver, network traffic is privately routed *within your Amazon VPC*.
+ Amazon MWAA creates a VPC interface endpoint for your Apache Airflow webserver, and an interface endpoint for your Amazon Aurora PostgreSQL metadata database. The endpoints are created in the Availability Zones mapped to your private subnets and is independent from other AWS accounts.
+ Amazon MWAA then binds an IP address from your private subnets to the interface endpoints. This is designed to support the best practice of binding a single IP from each Availability Zone of the Amazon VPC.
To learn more, refer to [Example use cases for an Amazon VPC and Apache Airflow access mode](networking-about.md#networking-about-network-usecase).
## Setup for private and public access modes
The following section describes the additional setup and configurations you'll need based on the Apache Airflow access mode you've chosen for your environment.
### Setup for public network
If you choose the **Public network** option for your Apache Airflow webserver, you can begin using the Apache Airflow UI after you create your environment.
You'll need to take the following steps to configure access for your users, and permission for your environment to use other AWS services.
1. **Add permissions**. Amazon MWAA needs permission to use other AWS services. When you create an environment, Amazon MWAA creates a [service-linked role](mwaa-slr.md) that allows it to use certain IAM actions for Amazon Elastic Container Registry (Amazon ECR), CloudWatch Logs, and Amazon EC2.
You can add permission to use additional actions for these services, or to use other AWS services by adding permissions to your execution role. To learn more, refer to [Amazon MWAA execution role](mwaa-create-role.md).
1. **Create user policies**. You might need to create multiple IAM policies for your users to configure access to your environment and Apache Airflow UI. To learn more, refer to [Accessing an Amazon MWAA environment](access-policies.md).
### Setup for private network
If you choose the **Private network** option for your Apache Airflow webserver, you'll need to configure access for your users, permission for your environment to use other AWS services, and create a mechanism to access the resources in your Amazon VPC from your computer.
1. **Add permissions**. Amazon MWAA needs permission to use other AWS services. When you create an environment, Amazon MWAA creates a [service-linked role](mwaa-slr.md) that allows it to use certain IAM actions for Amazon Elastic Container Registry (Amazon ECR), CloudWatch Logs, and Amazon EC2.
You can add permission to use additional actions for these services, or to use other AWS services by adding permissions to your execution role. To learn more, refer to [Amazon MWAA execution role](mwaa-create-role.md).
1. **Create user policies**. You might need to create multiple IAM policies for your users to configure access to your environment and Apache Airflow UI. To learn more, refer to [Accessing an Amazon MWAA environment](access-policies.md).
1. **Enable network access**. You'll need to create a mechanism in your Amazon VPC to connect to the VPC endpoint (AWS PrivateLink) for your Apache Airflow webserver. For example, by creating a VPN tunnel from your computer using an AWS Client VPN.
## Accessing the VPC endpoint for your Apache Airflow webserver (private network access)
If you've chosen the **Private network** option, you'll need to create a mechanism in your Amazon VPC to access the VPC endpoint (AWS PrivateLink) for your Apache Airflow webserver. We recommend using the same Amazon VPC, VPC security group, and private subnets as your Amazon MWAA environment for these resources.
To learn more, refer to [Managing access for VPC endpoints](https://docs.aws.amazon.com/mwaa/latest/userguide/vpc-vpe-access.html).