# Identity and access management for AWS Glue
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 AWS Glue resources. IAM is an AWS service that you can use with no additional charge.
**Note**
You can grant access to your data in the AWS Glue Data Catalog using either AWS Glue methods or AWS Lake Formation grants. You can use AWS Identity and Access Management (IAM) policies to set fine-grained access control with AWS Glue methods. Lake Formation uses a simpler `GRANT/REVOKE` permissions model that is similar to the `GRANT/REVOKE` commands in a relational database system.
This section includes information about how to use the AWS Glue methods. For information about using Lake Formation grants, see [Granting Lake Formation permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/lake-formation-permissions.html) in the *AWS Lake Formation Developer Guide*.
**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How AWS Glue works with IAM](security_iam_service-with-iam.md)
+ [Configuring IAM permissions for AWS Glue](configure-iam-for-glue.md)
+ [AWS Glue access control policy examples](glue-policy-examples.md)
+ [Granting AWS managed policies for AWS Glue](security-iam-awsmanpol.md)
+ [Granting dynamically scoped policies for job execution](dynamically-scoped-policies.md)
+ [Specifying AWS Glue resource ARNs](glue-specifying-resource-arns.md)
+ [Granting cross-account access](cross-account-access.md)
+ [Troubleshooting AWS Glue identity and access](security_iam_troubleshoot.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 AWS Glue identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How AWS Glue works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [Identity-based policy examples for AWS Glue](security_iam_id-based-policy-examples.md))
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### Federated identity
As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.
A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.
For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.
### IAM users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
### 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.
### 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 AWS Glue works with IAM
Before you use IAM to manage access to AWS Glue, learn what IAM features are available to use with AWS Glue.
**IAM features you can use with AWS Glue**
| IAM feature | AWS Glue support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | Partial |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes |
| [Policy condition keys (service-specific)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes |
| [ACLs](#security_iam_service-with-iam-acls) | No |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Partial |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions) | No |
| [Service roles](#security_iam_service-with-iam-roles-service) | Yes |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | No |
To get a high-level view of how AWS Glue and other AWS services work with most IAM features, 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*.
## Identity-based policies for AWS Glue
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
AWS Glue supports identity-based policies (IAM policies) for all AWS Glue operations. By attaching a policy, you can grant permissions to create, access, or modify an AWS Glue resource, such as a table in the AWS Glue Data Catalog.
### Identity-based policy examples for AWS Glue
To view examples of AWS Glue identity-based policies, see [Identity-based policy examples for AWS Glue](security_iam_id-based-policy-examples.md).
## Resource-based policies within AWS Glue
**Supports resource-based policies:** Partial
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
**Note**
You can only use an AWS Glue resource policy to manage permissions for Data Catalog resources. You can't attach it to any other AWS Glue resources such as jobs, triggers, development endpoints, crawlers, or classifiers.
Only *one* resource policy is allowed per catalog, and its size is limited to 10 KB.
In AWS Glue, a resource policy is attached to a *catalog*, which is a virtual container for all the kinds of Data Catalog resources mentioned previously. Each AWS account owns a single catalog in an AWS Region whose catalog ID is the same as the AWS account ID. You cannot delete or modify a catalog.
A resource policy is evaluated for all API calls to the catalog where the caller principal is included in the `"Principal"` block of the policy document.
To view examples of AWS Glue resource-based policies, see [Resource-based policy examples for AWS Glue](security_iam_resource-based-policy-examples.md).
## Policy actions for AWS Glue
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of AWS Glue actions, see [Actions defined by AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in AWS Glue use the following prefix before the action:
```
glue
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"glue:action1",
"glue:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Get`, include the following action:
```
"Action": "glue:Get*"
```
To view example policies, see [AWS Glue access control policy examples](glue-policy-examples.md).
## Policy resources for AWS Glue
**Supports policy resources:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
For more information about how to control access to AWS Glue resources using ARNs, see [Specifying AWS Glue resource ARNs](glue-specifying-resource-arns.md).
To see a list of AWS Glue resource types and their ARNs, see [Resources defined by AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-resources-for-iam-policies) in the *Service Authorization Reference*. To learn which actions you can use to specify the ARN of each resource, see [Actions defined by AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-actions-as-permissions).
## Policy condition keys for AWS Glue
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To see a list of AWS Glue condition keys, see [Condition keys for AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-policy-keys) in the *Service Authorization Reference*. To learn which actions and resources you can use a condition key with, see [Actions defined by AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-actions-as-permissions).
To view example policies, see [Control settings using condition keys or context keys](security_iam_id-based-policy-examples.md#glue-identity-based-policy-condition-keys).
## ACLs in AWS Glue
**Supports ACLs:** No
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## ABAC with AWS Glue
**Supports ABAC (tags in policies):** Partial
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
**Important**
The condition context keys apply only to AWS Glue API actions on crawlers, jobs, triggers, and development endpoints. For more information about which API operations are affected, see [Condition keys for AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html#awsglue-policy-keys).
The AWS Glue Data Catalog API operations don't currently support the `aws:referer` and `aws:UserAgent` global condition context keys.
To view an example identity-based policy for limiting access to a resource based on the tags on that resource, see [Grant access using tags](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-allow).
## Using temporary credentials with AWS Glue
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for AWS Glue
**Supports forward access sessions (FAS):** No
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for AWS Glue
**Supports service roles:** Yes
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
**Warning**
Changing the permissions for a service role might break AWS Glue functionality. Edit service roles only when AWS Glue provides guidance to do so.
For detailed instructions on creating a service role for AWS Glue, see [Step 1: Create an IAM policy for the AWS Glue service](create-service-policy.md) and [Step 2: Create an IAM role for AWS Glue](create-an-iam-role.md).
## Service-linked roles for AWS Glue
**Supports service-linked roles:** No
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about creating or managing 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). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# Configuring IAM permissions for AWS Glue
You use AWS Identity and Access Management (IAM) to define policies and roles that AWS Glue uses to access resources. The following steps lead you through various options for setting up the permissions for AWS Glue. Depending on your business needs, you might have to add or reduce access to your resources.
**Note**
To get started with basic IAM permissions for AWS Glue instead, see [Setting up IAM permissions for AWS Glue](set-up-iam.md).
1. [Create an IAM policy for the AWS Glue service](create-service-policy.md): Create a service policy that allows access to AWS Glue resources.
1. [Create an IAM role for AWS Glue](create-an-iam-role.md): Create an IAM role, and attach the AWS Glue service policy and a policy for your Amazon Simple Storage Service (Amazon S3) resources that are used by AWS Glue.
1. [Attach a policy to users or groups that access AWS Glue](attach-policy-iam-user.md): Attach policies to any users or groups that sign in to the AWS Glue console.
1. [Create an IAM policy for notebooks](create-notebook-policy.md): Create a notebook server policy to use in the creation of notebook servers on development endpoints.
1. [Create an IAM role for notebooks](create-an-iam-role-notebook.md): Create an IAM role and attach the notebook server policy.
1. [Create an IAM policy for Amazon SageMaker AI notebooks](create-sagemaker-notebook-policy.md): Create an IAM policy to use when creating Amazon SageMaker AI notebooks on development endpoints.
1. [Create an IAM role for Amazon SageMaker AI notebooks](create-an-iam-role-sagemaker-notebook.md): Create an IAM role and attach the policy to grant permissions when creating Amazon SageMaker AI notebooks on development endpoints.
# Step 1: Create an IAM policy for the AWS Glue service
For any operation that accesses data on another AWS resource, such as accessing your objects in Amazon S3, AWS Glue needs permission to access the resource on your behalf. You provide those permissions by using AWS Identity and Access Management (IAM).
**Note**
You can skip this step if you use the AWS managed policy `AWSGlueServiceRole`.
In this step, you create a policy that is similar to `AWSGlueServiceRole`. You can find the most current version of `AWSGlueServiceRole` on the IAM console.
**To create an IAM policy for AWS Glue**
This policy grants permission for some Amazon S3 actions to manage resources in your account that are needed by AWS Glue when it assumes the role using this policy. Some of the resources that are specified in this policy refer to default names that are used by AWS Glue for Amazon S3 buckets, Amazon S3 ETL scripts, CloudWatch Logs, and Amazon EC2 resources. For simplicity, AWS Glue writes some Amazon S3 objects into buckets in your account prefixed with `aws-glue-*` by default.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Policies**.
1. Choose **Create Policy**.
1. On the **Create Policy** screen, navigate to a tab to edit JSON. Create a policy document with the following JSON statements, and then choose **Review policy**.
**Note**
Add any permissions needed for Amazon S3 resources. You might want to scope the resources section of your access policy to only those resources that are required.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:*",
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:ListAllMyBuckets",
"s3:GetBucketAcl",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeRouteTables",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcAttribute",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"cloudwatch:PutMetricData"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketPublicAccessBlock"
],
"Resource": [
"arn:aws:s3:::aws-glue-*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::aws-glue-*/*",
"arn:aws:s3:::*/*aws-glue-*/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::crawler-public*",
"arn:aws:s3:::aws-glue-*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:AssociateKmsKey"
],
"Resource": [
"arn:aws:logs:*:*:log-group:/aws-glue/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"aws-glue-service-resource"
]
}
},
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
]
}
]
}
```
------
The following table describes the permissions granted by this policy.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/glue/latest/dg/create-service-policy.html)
1. On the **Review Policy** screen, enter your **Policy Name**, for example **GlueServiceRolePolicy**. Enter an optional description, and when you're satisfied with the policy, choose **Create policy**.
# Step 2: Create an IAM role for AWS Glue
You need to grant your IAM role permissions that AWS Glue can assume when calling other services on your behalf. This includes access to Amazon S3 for any sources, targets, scripts, and temporary directories that you use with AWS Glue. Permission is needed by crawlers, jobs, and development endpoints.
You provide those permissions by using AWS Identity and Access Management (IAM). Add a policy to the IAM role that you pass to AWS Glue.
****To create an IAM role within the job editor****
1. When you create a job in the AWS Glue console, locate the role section.
1. Choose **Create new role**.
1. An inline role creation form opens, allowing you to:
+ Specify **Role name**; for example, `AWSGlueServiceRoleDefault`.
+ The managed policy `AWSGlueServiceRole` is automatically selected.
+ Review the trust policy to assume the role.
+ Add optional tags for metadata.
1. Choose **Create role**.
1. The newly created role is automatically selected for your job.
Alternatively, you can use the IAM console to create the role:
****To create an IAM role for AWS Glue using the IAM console****
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Roles**.
1. Choose **Create role**.
1. Choose **AWS service** as the trusted entity type. Then, for service or use case, find and choose **AWS Glue**. Choose **Next**.
1. On the **Add permissions** page, choose the policies that contain the required permissions; for example, the AWS managed policy `AWSGlueServiceRole` for general AWS Glue permissions and the AWS managed policy **AmazonS3FullAccess** for access to Amazon S3 resources. Then choose **Next**.
**Note**
Ensure that one of the policies in this role grants permissions to your Amazon S3 sources and targets. You might want to provide your own policy for access to specific Amazon S3 resources. Data sources require `s3:ListBucket` and `s3:GetObject` permissions. Data targets require `s3:ListBucket`, `s3:PutObject`, and `s3:DeleteObject` permissions. For more information about creating an Amazon S3 policy for your resources, see [Specifying Resources in a Policy](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-arn-format.html). For an example Amazon S3 policy, see [ Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/).
If you plan to access Amazon S3 sources and targets that are encrypted with SSE-KMS, attach a policy that allows AWS Glue crawlers, jobs, and development endpoints to decrypt the data. For more information, see [Protecting Data Using Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html).
The following is an example.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:111122223333:key/key-id"
]
}
]
}
```
1. Name your role and add a description (optional), then review the trust policy and permissions. For **Role name**, enter a name for your role; for example, `AWSGlueServiceRoleDefault`. Create the role with the name prefixed with the string `AWSGlueServiceRole` to allow the role to be passed from console users to the service. AWS Glue provided policies expect IAM service roles to begin with `AWSGlueServiceRole`. Otherwise, you must add a policy to allow your users the `iam:PassRole` permission for IAM roles to match your naming convention. Choose **Create Role**.
**Note**
When you create a notebook with a role, that role is then passed to interactive sessions so that the same role can be used in both places. As such, the `iam:PassRole` permission needs to be part of the role's policy.
Create a new policy for your role using the following example. Replace the account number with your own and the role name.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::090000000210:role/"
}
]
}
```
1. Add tags to your role (optional). Tags are key-value pairs that you can add to AWS resources to help identify, organize, or search for resources. Then, choose **Create role**.
# Step 3: Attach a policy to users or groups that access AWS Glue
The administrator must assign permissions to any users, groups, or roles using the AWS Glue console or AWS Command Line Interface (AWS CLI). You provide those permissions by using AWS Identity and Access Management (IAM), through policies. This step describes assigning permissions to users or groups.
When you finish this step, your user or group has the following policies attached:
+ The AWS managed policy `AWSGlueConsoleFullAccess` or the custom policy **GlueConsoleAccessPolicy**
+ **`AWSGlueConsoleSageMakerNotebookFullAccess`**
+ **`CloudWatchLogsReadOnlyAccess`**
+ **`AWSCloudFormationReadOnlyAccess`**
+ **`AmazonAthenaFullAccess`**
**To attach an inline policy and embed it in a user or group**
You can attach an AWS managed policy or an inline policy to a user or group to access the AWS Glue console. Some of the resources specified in this policy refer to default names that are used by AWS Glue for Amazon S3 buckets, Amazon S3 ETL scripts, CloudWatch Logs, CloudFormation, and Amazon EC2 resources. For simplicity, AWS Glue writes some Amazon S3 objects into buckets in your account prefixed with `aws-glue-*` by default.
**Note**
You can skip this step if you use the AWS managed policy **`AWSGlueConsoleFullAccess`**.
**Important**
AWS Glue needs permission to assume a role that is used to perform work on your behalf. **To accomplish this, you add the `iam:PassRole` permissions to your AWS Glue users or groups.** This policy grants permission to roles that begin with `AWSGlueServiceRole` for AWS Glue service roles, and `AWSGlueServiceNotebookRole` for roles that are required when you create a notebook server. You can also create your own policy for `iam:PassRole` permissions that follows your naming convention.
Per security best practices, it is recommended to restrict access by tightening policies to further restrict access to Amazon S3 bucket and Amazon CloudWatch log groups. For an example Amazon S3 policy, see [Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/).
In this step, you create a policy that is similar to `AWSGlueConsoleFullAccess`. You can find the most current version of `AWSGlueConsoleFullAccess` on the IAM console.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Users** or **User groups**.
1. In the list, choose the name of the user or group to embed a policy in.
1. Choose the **Permissions** tab and, if necessary, expand the **Permissions policies** section.
1. Choose the **Add Inline policy** link.
1. On the **Create Policy** screen, navigate to a tab to edit JSON. Create a policy document with the following JSON statements, and then choose **Review policy**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:*",
"redshift:DescribeClusters",
"redshift:DescribeClusterSubnetGroups",
"iam:ListRoles",
"iam:ListUsers",
"iam:ListGroups",
"iam:ListRolePolicies",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcAttribute",
"ec2:DescribeKeyPairs",
"ec2:DescribeInstances",
"rds:DescribeDBInstances",
"rds:DescribeDBClusters",
"rds:DescribeDBSubnetGroups",
"s3:ListAllMyBuckets",
"s3:ListBucket",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"cloudformation:DescribeStacks",
"cloudformation:GetTemplateSummary",
"dynamodb:ListTables",
"kms:ListAliases",
"kms:DescribeKey",
"cloudwatch:GetMetricData",
"cloudwatch:ListDashboards"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::*/*aws-glue-*/*",
"arn:aws:s3:::aws-glue-*"
]
},
{
"Effect": "Allow",
"Action": [
"tag:GetResources"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketPublicAccessBlock"
],
"Resource": [
"arn:aws:s3:::aws-glue-*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:GetLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:/aws-glue/*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:DeleteStack"
],
"Resource": "arn:aws:cloudformation:*:*:stack/aws-glue*/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:image/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:volume/*"
]
},
{
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/AWSGlueServiceRole*",
"Condition": {
"StringLike": {
"iam:PassedToService": [
"glue.amazonaws.com"
]
}
}
},
{
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/AWSGlueServiceNotebookRole*",
"Condition": {
"StringLike": {
"iam:PassedToService": [
"ec2.amazonaws.com"
]
}
}
},
{
"Action": [
"iam:PassRole"
],
"Effect": "Allow",
"Resource": [
"arn:aws:iam::*:role/service-role/AWSGlueServiceRole*"
],
"Condition": {
"StringLike": {
"iam:PassedToService": [
"glue.amazonaws.com"
]
}
}
}
]
}
```
------
The following table describes the permissions granted by this policy.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/glue/latest/dg/attach-policy-iam-user.html)
1. On the **Review policy** screen, enter a name for the policy, for example **GlueConsoleAccessPolicy**. When you're satisfied with the policy, choose **Create policy**. Ensure that no errors appear in a red box at the top of the screen. Correct any that are reported.
**Note**
If **Use autoformatting** is selected, the policy is reformatted whenever you open a policy or choose **Validate Policy**.
**To attach the AWSGlueConsoleFullAccess managed policy**
You can attach the `AWSGlueConsoleFullAccess` policy to provide permissions that are required by the AWS Glue console user.
**Note**
You can skip this step if you created your own policy for AWS Glue console access.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**.
1. In the list of policies, select the check box next to the **AWSGlueConsoleFullAccess**. You can use the **Filter** menu and the search box to filter the list of policies.
1. Choose **Policy actions**, and then choose **Attach**.
1. Choose the user to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities. After choosing the user to attach the policy to, choose **Attach policy**.
**To attach the `AWSGlueConsoleSageMakerNotebookFullAccess` managed policy**
You can attach the `AWSGlueConsoleSageMakerNotebookFullAccess` policy to a user to manage SageMaker AI notebooks created on the AWS Glue console. In addition to other required AWS Glue console permissions, this policy grants access to resources needed to manage SageMaker AI notebooks.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**.
1. In the list of policies, select the check box next to the **AWSGlueConsoleSageMakerNotebookFullAccess**. You can use the **Filter** menu and the search box to filter the list of policies.
1. Choose **Policy actions**, and then choose **Attach**.
1. Choose the user to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities. After choosing the user to attach the policy to, choose **Attach policy**.
**To attach the CloudWatchLogsReadOnlyAccess managed policy**
You can attach the **CloudWatchLogsReadOnlyAccess** policy to a user to view the logs created by AWS Glue on the CloudWatch Logs console.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**.
1. In the list of policies, select the check box next to the **CloudWatchLogsReadOnlyAccess**. You can use the **Filter** menu and the search box to filter the list of policies.
1. Choose **Policy actions**, and then choose **Attach**.
1. Choose the user to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities. After choosing the user to attach the policy to, choose **Attach policy**.
**To attach the AWSCloudFormationReadOnlyAccess managed policy**
You can attach the **AWSCloudFormationReadOnlyAccess** policy to a user to view the CloudFormation stacks used by AWS Glue on the CloudFormation console.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**.
1. In the list of policies, select the check box next to **AWSCloudFormationReadOnlyAccess**. You can use the **Filter** menu and the search box to filter the list of policies.
1. Choose **Policy actions**, and then choose **Attach**.
1. Choose the user to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities. After choosing the user to attach the policy to, choose **Attach policy**.
**To attach the AmazonAthenaFullAccess managed policy**
You can attach the **AmazonAthenaFullAccess** policy to a user to view Amazon S3 data in the Athena console.
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the navigation pane, choose **Policies**.
1. In the list of policies, select the check box next to the **AmazonAthenaFullAccess**. You can use the **Filter** menu and the search box to filter the list of policies.
1. Choose **Policy actions**, and then choose **Attach**.
1. Choose the user to attach the policy to. You can use the **Filter** menu and the search box to filter the list of principal entities. After choosing the user to attach the policy to, choose **Attach policy**.
# Step 4: Create an IAM policy for notebook servers
If you plan to use notebooks with development endpoints, you must specify permissions when you create the notebook server. You provide those permissions by using AWS Identity and Access Management (IAM).
This policy grants permission for some Amazon S3 actions to manage resources in your account that are needed by AWS Glue when it assumes the role using this policy. Some of the resources that are specified in this policy refer to default names used by AWS Glue for Amazon S3 buckets, Amazon S3 ETL scripts, and Amazon EC2 resources. For simplicity, AWS Glue defaults writing some Amazon S3 objects into buckets in your account prefixed with `aws-glue-*`.
**Note**
You can skip this step if you use the AWS managed policy **`AWSGlueServiceNotebookRole`**.
In this step, you create a policy that is similar to `AWSGlueServiceNotebookRole`. You can find the most current version of `AWSGlueServiceNotebookRole` on the IAM console.
**To create an IAM policy for notebooks**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Policies**.
1. Choose **Create Policy**.
1. On the **Create Policy** screen, navigate to a tab to edit JSON. Create a policy document with the following JSON statements, and then choose **Review policy**.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateDatabase",
"glue:CreatePartition",
"glue:CreateTable",
"glue:DeleteDatabase",
"glue:DeletePartition",
"glue:DeleteTable",
"glue:GetDatabase",
"glue:GetDatabases",
"glue:GetPartition",
"glue:GetPartitions",
"glue:GetTable",
"glue:GetTableVersions",
"glue:GetTables",
"glue:UpdateDatabase",
"glue:UpdatePartition",
"glue:UpdateTable",
"glue:GetJobBookmark",
"glue:ResetJobBookmark",
"glue:CreateConnection",
"glue:CreateJob",
"glue:DeleteConnection",
"glue:DeleteJob",
"glue:GetConnection",
"glue:GetConnections",
"glue:GetDevEndpoint",
"glue:GetDevEndpoints",
"glue:GetJob",
"glue:GetJobs",
"glue:UpdateJob",
"glue:BatchDeleteConnection",
"glue:UpdateConnection",
"glue:GetUserDefinedFunction",
"glue:UpdateUserDefinedFunction",
"glue:GetUserDefinedFunctions",
"glue:DeleteUserDefinedFunction",
"glue:CreateUserDefinedFunction",
"glue:BatchGetPartition",
"glue:BatchDeletePartition",
"glue:BatchCreatePartition",
"glue:BatchDeleteTable",
"glue:UpdateDevEndpoint",
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:ListAllMyBuckets",
"s3:GetBucketAcl"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::crawler-public*",
"arn:aws:s3:::aws-glue*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::aws-glue*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags"
],
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"aws-glue-service-resource"
]
}
},
"Resource": [
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:security-group/*",
"arn:aws:ec2:*:*:instance/*"
]
}
]
}
```
------
The following table describes the permissions granted by this policy.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/glue/latest/dg/create-notebook-policy.html)
1. On the **Review Policy** screen, enter your **Policy Name**, for example **GlueServiceNotebookPolicyDefault**. Enter an optional description, and when you're satisfied with the policy, choose **Create policy**.
# Step 5: Create an IAM role for notebook servers
If you plan to use notebooks with development endpoints, you need to grant the IAM role permissions. You provide those permissions by using AWS Identity and Access Management IAM, through an IAM role.
**Note**
When you create an IAM role using the IAM console, the console creates an instance profile automatically and gives it the same name as the role to which it corresponds.
**To create an IAM role for notebooks**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Roles**.
1. Choose **Create role**.
1. For role type, choose **AWS Service**, find and choose **EC2**, and choose the **EC2** use case, then choose **Next: Permissions**.
1. On the **Attach permissions policy** page, choose the policies that contain the required permissions; for example, **AWSGlueServiceNotebookRole** for general AWS Glue permissions and the AWS managed policy **AmazonS3FullAccess** for access to Amazon S3 resources. Then choose **Next: Review**.
**Note**
Ensure that one of the policies in this role grants permissions to your Amazon S3 sources and targets. Also confirm that your policy allows full access to the location where you store your notebook when you create a notebook server. You might want to provide your own policy for access to specific Amazon S3 resources. For more information about creating an Amazon S3 policy for your resources, see [Specifying Resources in a Policy](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-arn-format.html).
If you plan to access Amazon S3 sources and targets that are encrypted with SSE-KMS, attach a policy that allows notebooks to decrypt the data. For more information, see [Protecting Data Using Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html).
The following is an example.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:111122223333:key/key-id"
]
}
]
}
```
1. For **Role name**, enter a name for your role. Create the role with the name prefixed with the string `AWSGlueServiceNotebookRole` to allow the role to be passed from console users to the notebook server. AWS Glue provided policies expect IAM service roles to begin with `AWSGlueServiceNotebookRole`. Otherwise you must add a policy to your users to allow the `iam:PassRole` permission for IAM roles to match your naming convention. For example, enter `AWSGlueServiceNotebookRoleDefault`. Then choose **Create role**.
# Step 6: Create an IAM policy for SageMaker AI notebooks
If you plan to use SageMaker AI notebooks with development endpoints, you must specify permissions when you create the notebook. You provide those permissions by using AWS Identity and Access Management (IAM).
**To create an IAM policy for SageMaker AI notebooks**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Policies**.
1. Choose **Create Policy**.
1. On the **Create Policy** page, navigate to a tab to edit the JSON. Create a policy document with the following JSON statements. Edit *bucket-name*, *region-code*, and *account-id* for your environment.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
]
},
{
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket*"
]
},
{
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:PutLogEvents",
"logs:CreateLogGroup"
],
"Effect": "Allow",
"Resource": [
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/*",
"arn:aws:logs:us-east-1:111122223333:log-group:/aws/sagemaker/*:log-stream:aws-glue-*"
]
},
{
"Action": [
"glue:UpdateDevEndpoint",
"glue:GetDevEndpoint",
"glue:GetDevEndpoints"
],
"Effect": "Allow",
"Resource": [
"arn:aws:glue:us-east-1:111122223333:devEndpoint/*"
]
},
{
"Action": [
"sagemaker:ListTags"
],
"Effect": "Allow",
"Resource": [
"arn:aws:sagemaker:us-east-1:111122223333:notebook-instance/*"
]
}
]
}
```
------
Then choose **Review policy**.
The following table describes the permissions granted by this policy.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/glue/latest/dg/create-sagemaker-notebook-policy.html)
1. On the **Review Policy** screen, enter your **Policy Name**, for example `AWSGlueSageMakerNotebook`. Enter an optional description, and when you're satisfied with the policy, choose **Create policy**.
# Step 7: Create an IAM role for SageMaker AI notebooks
If you plan to use SageMaker AI notebooks with development endpoints, you need to grant the IAM role permissions. You provide those permissions by using AWS Identity and Access Management (IAM), through an IAM role.
**To create an IAM role for SageMaker AI notebooks**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane, choose **Roles**.
1. Choose **Create role**.
1. For role type, choose **AWS Service**, find and choose **SageMaker**, and then choose the **SageMaker - Execution** use case. Then choose **Next: Permissions**.
1. On the **Attach permissions policy** page, choose the policies that contain the required permissions; for example, **AmazonSageMakerFullAccess**. Choose **Next: Review**.
If you plan to access Amazon S3 sources and targets that are encrypted with SSE-KMS, attach a policy that allows notebooks to decrypt the data, as shown in the following example. For more information, see [Protecting Data Using Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:*:111122223333:key/key-id"
]
}
]
}
```
------
1. For **Role name**, enter a name for your role. To allow the role to be passed from console users to SageMaker AI, use a name that is prefixed with the string `AWSGlueServiceSageMakerNotebookRole`. AWS Glue provided policies expect IAM roles to begin with `AWSGlueServiceSageMakerNotebookRole`. Otherwise you must add a policy to your users to allow the `iam:PassRole` permission for IAM roles to match your naming convention.
For example, enter `AWSGlueServiceSageMakerNotebookRole-Default`, and then choose **Create role**.
1. After you create the role, attach the policy that allows additional permissions required to create SageMaker AI notebooks from AWS Glue.
Open the role that you just created, `AWSGlueServiceSageMakerNotebookRole-Default`, and choose **Attach policies**. Attach the policy that you created named `AWSGlueSageMakerNotebook` to the role.
# AWS Glue access control policy examples
This section contains examples of both identity-based (IAM) access control policies and AWS Glue resource policies.
**Contents**
+ [Identity-based policy examples for AWS Glue](security_iam_id-based-policy-examples.md)
+ [Policy best practices](security_iam_id-based-policy-examples.md#security_iam_service-with-iam-policy-best-practices)
+ [Resource-level permissions only apply to specific AWS Glue objects](security_iam_id-based-policy-examples.md#glue-identity-based-policy-limitations)
+ [Using the AWS Glue console](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-view-own-permissions)
+ [Grant read-only permission to a table](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filter tables by GetTables permission](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-filter-tables)
+ [Grant full access to a table and all partitions](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Control access by name prefix and explicit denial](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Grant access using tags](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-allow)
+ [Deny access using tags](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-deny)
+ [Use tags with list and batch API operations](security_iam_id-based-policy-examples.md#tags-control-access-example-triggers-list-batch)
+ [Control settings using condition keys or context keys](security_iam_id-based-policy-examples.md#glue-identity-based-policy-condition-keys)
+ [Control policies that control settings using condition keys](security_iam_id-based-policy-examples.md#glue-identity-based-policy-condition-key-vpc)
+ [Control policies that control settings using context keys](security_iam_id-based-policy-examples.md#glue-identity-based-policy-context-key-glue)
+ [Deny an identity the ability to create data preview sessions](security_iam_id-based-policy-examples.md#deny-data-preview-sessions-per-identity)
+ [Resource-based policy examples for AWS Glue](security_iam_resource-based-policy-examples.md)
+ [Considerations for using resource-based policies with AWS Glue](security_iam_resource-based-policy-examples.md#security_iam_resource-based-policy-examples-considerations)
+ [Use a resource policy to control access in the same account](security_iam_resource-based-policy-examples.md#glue-policy-resource-policies-example-same-account)
# Identity-based policy examples for AWS Glue
By default, users and roles don't have permission to create or modify AWS Glue resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.
To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.
For details about actions and resource types defined by AWS Glue, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for AWS Glue](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsglue.html) in the *Service Authorization Reference*.
**Note**
The examples provided in this section all use the `us-west-2` Region. You can replace this with the AWS Region that you want to use.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices)
+ [Resource-level permissions only apply to specific AWS Glue objects](#glue-identity-based-policy-limitations)
+ [Using the AWS Glue console](#security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Grant read-only permission to a table](#security_iam_id-based-policy-examples-read-only-table-access)
+ [Filter tables by GetTables permission](#security_iam_id-based-policy-examples-filter-tables)
+ [Grant full access to a table and all partitions](#security_iam_id-based-policy-examples-full-access-tables-partitions)
+ [Control access by name prefix and explicit denial](#security_iam_id-based-policy-examples-deny-by-name-prefix)
+ [Grant access using tags](#tags-control-access-example-triggers-allow)
+ [Deny access using tags](#tags-control-access-example-triggers-deny)
+ [Use tags with list and batch API operations](#tags-control-access-example-triggers-list-batch)
+ [Control settings using condition keys or context keys](#glue-identity-based-policy-condition-keys)
+ [Deny an identity the ability to create data preview sessions](#deny-data-preview-sessions-per-identity)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete AWS Glue 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*.
## Resource-level permissions only apply to specific AWS Glue objects
You can only define fine-grained control for specific objects in AWS Glue. Therefore you must write your client's IAM policy so that API operations that allow Amazon Resource Names (ARNs) for the `Resource` statement are not mixed with API operations that don't allow ARNs.
For example, the following IAM policy allows API operations for `GetClassifier` and `GetJobRun`. It defines the `Resource` as `*` because AWS Glue doesn't allow ARNs for classifiers and job runs. Because ARNs are allowed for specific API operations such as `GetDatabase` and `GetTable`, ARNs can be specified in the second half of the policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetClassifier*",
"glue:GetJobRun*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:Get*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/default",
"arn:aws:glue:us-east-1:111122223333:table/default/e*1*",
"arn:aws:glue:us-east-1:111122223333:connection/connection2"
]
}
]
}
```
------
For a list of AWS Glue objects that allow ARNs, see [Specifying AWS Glue Resource ARNs](glue-specifying-resource-arns.md).
## Using the AWS Glue console
To access the AWS Glue console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS Glue resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.
To ensure that users and roles can still use the AWS Glue console, also attach the AWS Glue `ConsoleAccess` or `ReadOnly` AWS managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
For a user to work with the AWS Glue console, that user must have a minimum set of permissions that allows them to work with the AWS Glue resources for their AWS account. In addition to these AWS Glue permissions, the console requires permissions from the following services:
+ Amazon CloudWatch Logs permissions to display logs.
+ AWS Identity and Access Management (IAM) permissions to list and pass roles.
+ AWS CloudFormation permissions to work with stacks.
+ Amazon Elastic Compute Cloud (Amazon EC2) permissions to list VPCs, subnets, security groups, instances, and other objects.
+ Amazon Simple Storage Service (Amazon S3) permissions to list buckets and objects, and to retrieve and save scripts.
+ Amazon Redshift permissions to work with clusters.
+ Amazon Relational Database Service (Amazon RDS) permissions to list instances.
For more information about the permissions that users require to view and work with the AWS Glue console, see [Step 3: Attach a policy to users or groups that access AWS Glue](attach-policy-iam-user.md).
If you create an IAM policy that is more restrictive than the minimum required permissions, the console won't function as intended for users with that IAM policy. To ensure that those users can still use the AWS Glue console, also attach the `AWSGlueConsoleFullAccess` managed policy as described in [AWS managed (predefined) policies for AWS Glue](security-iam-awsmanpol.md#access-policy-examples-aws-managed).
## 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": "*"
}
]
}
```
## Grant read-only permission to a table
The following policy grants read-only permission to a `books` table in database `db1`. For more information about resource Amazon Resource Names (ARNs), see [Data Catalog ARNs](glue-specifying-resource-arns.md#data-catalog-resource-arns).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesActionOnBooks",
"Effect": "Allow",
"Action": [
"glue:GetTables",
"glue:GetTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
This policy grants read-only permission to a table named `books` in the database named `db1`. To grant `Get` permission to a table, permission to the catalog and database resources is also required.
The following policy grants the minimum necessary permissions to create table `tb1` in database `db1`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:CreateTable"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:table/db1/tbl1",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:catalog"
]
}
]
}
```
------
## Filter tables by GetTables permission
Assume that there are three tables—`customers`, `stores`, and `store_sales`—in database `db1`. The following policy grants `GetTables` permission to `stores` and `store_sales`, but not to `customers`. When you call `GetTables` with this policy, the result contains only the two authorized tables (the `customers` table is not returned).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store_sales",
"arn:aws:glue:us-east-1:111122223333:table/db1/stores"
]
}
]
}
```
------
You can simplify the preceding policy by using `store*` to match any table names that start with `store`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesExample2",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/store*"
]
}
]
}
```
------
Similarly, using `/db1/*` to match all tables in `db1`, the following policy grants `GetTables` access to all the tables in `db1`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesReturnAll",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
If no table ARN is provided, a call to `GetTables` succeeds, but it returns an empty list.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesEmptyResults",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
If the database ARN is missing in the policy, a call to `GetTables` fails with an `AccessDeniedException`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "GetTablesAccessDeny",
"Effect": "Allow",
"Action": [
"glue:GetTables"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:table/db1/*"
]
}
]
}
```
------
## Grant full access to a table and all partitions
The following policy grants all permissions on a table named `books` in database `db1`. This includes read and write permissions on the table itself, on archived versions of it, and on all its partitions.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:CreateTable",
"glue:GetTable",
"glue:GetTables",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:BatchDeleteTable",
"glue:GetTableVersion",
"glue:GetTableVersions",
"glue:DeleteTableVersion",
"glue:BatchDeleteTableVersion",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetPartition",
"glue:GetPartitions",
"glue:BatchGetPartition",
"glue:UpdatePartition",
"glue:DeletePartition",
"glue:BatchDeletePartition"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
The preceding policy can be simplified in practice.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessOnTable",
"Effect": "Allow",
"Action": [
"glue:*Table*",
"glue:*Partition*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1",
"arn:aws:glue:us-east-1:111122223333:table/db1/books"
]
}
]
}
```
------
Notice that the minimum granularity of fine-grained access control is at the table level. This means that you can't grant a user access to some partitions in a table but not others, or to some table columns but not to others. A user either has access to all of a table, or to none of it.
## Control access by name prefix and explicit denial
In this example, suppose that the databases and tables in your AWS Glue Data Catalog are organized using name prefixes. The databases in the development stage have the name prefix `dev-`, and those in production have the name prefix `prod-`. You can use the following policy to grant developers full access to all databases, tables, UDFs, and so on, that have the `dev-` prefix. But you grant read-only access to everything with the `prod-` prefix.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DevAndProdFullAccess",
"Effect": "Allow",
"Action": [
"glue:*Database*",
"glue:*Table*",
"glue:*Partition*",
"glue:*UserDefinedFunction*",
"glue:*Connection*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/dev-*",
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/dev-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/dev-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/dev-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
},
{
"Sid": "ProdWriteDeny",
"Effect": "Deny",
"Action": [
"glue:*Create*",
"glue:*Update*",
"glue:*Delete*"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:database/prod-*",
"arn:aws:glue:us-east-1:111122223333:table/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:table/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/prod-*/*",
"arn:aws:glue:us-east-1:111122223333:userDefinedFunction/*/prod-*",
"arn:aws:glue:us-east-1:111122223333:connection/prod-*"
]
}
]
}
```
------
The second statement in the preceding policy uses explicit `deny`. You can use explicit `deny` to overwrite any `allow` permissions that are granted to the principal. This lets you lock down access to critical resources and prevent another policy from accidentally granting access to them.
In the preceding example, even though the first statement grants full access to `prod-` resources, the second statement explicitly revokes write access to them, leaving only read access to `prod-` resources.
## Grant access using tags
For example, suppose that you want to limit access to a trigger `t2` to a specific user named `Tom` in your account. All other users, including `Sam`, have access to trigger `t1`. The triggers `t1` and `t2` have the following properties.
```
aws glue get-triggers
{
"Triggers": [
{
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t1",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
},
{
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
]
}
```
The AWS Glue administrator attached a tag value `Tom` (`aws:ResourceTag/Name": "Tom"`) to trigger `t2`. The AWS Glue administrator also gave Tom an IAM policy with a condition statement based on the tag. As a result, Tom can only use an AWS Glue operation that acts on resources with the tag value `Tom`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
When Tom tries to access the trigger `t1`, he receives an access denied message. Meanwhile, he can successfully retrieve trigger `t2`.
```
aws glue get-trigger --name t1
An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1
aws glue get-trigger --name t2
{
"Trigger": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j1"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
```
Tom can't use the plural `GetTriggers` API operation to list triggers because this operation doesn't support filtering on tags.
To give Tom access to `GetTriggers`, the AWS Glue administrator creates a policy that splits the permissions into two sections. One section allows Tom access to all triggers with the `GetTriggers` API operation. The second section allows Tom access to API operations that are tagged with the value `Tom`. With this policy, Tom is allowed both `GetTriggers` and `GetTrigger` access to trigger `t2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "glue:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
## Deny access using tags
Another resource policy approach is to explicitly deny access to resources.
**Important**
An explicit denial policy does not work for plural API operations such as `GetTriggers`.
In the following example policy, all AWS Glue job operations are allowed. However, the second `Effect` statement *explicitly* denies access to jobs tagged with the `Team` key and `Special` value.
When an administrator attaches the following policy to an identity, the identity can access all jobs *except* those tagged with the `Team` key and `Special` value.
## Use tags with list and batch API operations
A third approach to writing a resource policy is to allow access to resources using a `List` API operation to list out resources for a tag value. Then, use the corresponding `Batch` API operation to allow access to details of specific resources. With this approach, the administrator doesn't need to allow access to the plural `GetCrawlers`, `GetDevEndpoints`, `GetJobs`, or `GetTriggers` API operations. Instead, you can allow the ability to list the resources with the following API operations:
+ `ListCrawlers`
+ `ListDevEndpoints`
+ `ListJobs`
+ `ListTriggers`
And, you can allow the ability to get details about individual resources with the following API operations:
+ `BatchGetCrawlers`
+ `BatchGetDevEndpoints`
+ `BatchGetJobs`
+ `BatchGetTriggers`
As an administrator, to use this approach, you can do the following:
1. Add tags to your crawlers, development endpoints, jobs, and triggers.
1. Deny user access to `Get` API operations such as `GetCrawlers`, `GetDevEndponts`, `GetJobs`, and `GetTriggers`.
1. To enable users to find out which tagged resources they have access to, allow user access to `List` API operations such as `ListCrawlers`, `ListDevEndponts`, `ListJobs`, and `ListTriggers`.
1. Deny user access to AWS Glue tagging APIs, such as `TagResource` and `UntagResource`.
1. Allow user access to resource details with `BatchGet` API operations such as `BatchGetCrawlers`, `BatchGetDevEndponts`, `BatchGetJobs`, and `BatchGetTriggers`.
For example, when calling the `ListCrawlers` operation, provide a tag value to match the user name. Then the result is a list of crawlers that match the provided tag values. Provide the list of names to `BatchGetCrawlers` to get details about each crawler with the given tag.
For example, if Tom should only be able to retrieve details of triggers that are tagged with `Tom`, the administrator can add tags to triggers for `Tom`, deny access to the `GetTriggers` API operation to all users, and allow access to all users to `ListTriggers` and `BatchGetTriggers`.
The following is the resource policy that the AWS Glue administrator grants to Tom. In the first section of the policy, AWS Glue API operations are denied for `GetTriggers`. In the second section of the policy, `ListTriggers` is allowed for all resources. However, in the third section, those resources tagged with `Tom` are allowed access with the `BatchGetTriggers` access.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "glue:GetTriggers",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"glue:ListTriggers"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"glue:BatchGetTriggers"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Name": "Tom"
}
}
}
]
}
```
------
Using the same triggers as the previous example, Tom can access trigger `t2`, but not trigger `t1`. The following example shows the results when Tom tries to access `t1` and `t2` with `BatchGetTriggers`.
```
aws glue batch-get-triggers --trigger-names t2
{
"Triggers": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j2"
}
],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
aws glue batch-get-triggers --trigger-names t1
An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.
```
The following example shows the results when Tom tries to access both trigger `t2` and trigger `t3` (which does not exist) in the same `BatchGetTriggers` call. Notice that because Tom has access to trigger `t2` and it exists, only `t2` is returned. Although Tom is allowed to access trigger `t3`, trigger `t3` does not exist, so `t3` is returned in the response in a list of `"TriggersNotFound": []`.
```
aws glue batch-get-triggers --trigger-names t2 t3
{
"Triggers": {
"State": "CREATED",
"Type": "SCHEDULED",
"Name": "t2",
"Actions": [
{
"JobName": "j2"
}
],
"TriggersNotFound": ["t3"],
"Schedule": "cron(0 0/1 * * ? *)"
}
}
```
## Control settings using condition keys or context keys
You can use condition keys or context keys when granting permissions to create and update jobs. These sections discuss the keys:
+ [Control policies that control settings using condition keys](#glue-identity-based-policy-condition-key-vpc)
+ [Control policies that control settings using context keys](#glue-identity-based-policy-context-key-glue)
### Control policies that control settings using condition keys
AWS Glue provides three IAM condition keys `glue:VpcIds`, `glue:SubnetIds`, and `glue:SecurityGroupIds`. You can use the condition keys in IAM policies when granting permissions to create and update jobs. You can use this setting to ensure that jobs or sessions are not created (or updated to) to run outside of a desired VPC environment. The VPC setting information is not a direct input from the `CreateJob` request, but inferred from the job "connections" field that points to an AWS Glue connection.
**Example usage**
Create an AWS Glue network type connection named "traffic-monitored-connection" with the desired VpcId "vpc-id1234", SubnetIds, and SecurityGroupIds.
Specify the condition keys condition for the `CreateJob` and `UpdateJob` action in the IAM policy.
```
{
"Effect": "Allow",
"Action": [
"glue:CreateJob",
"glue:UpdateJob"
],
"Resource": [
"*"
],
"Condition": {
"ForAnyValue:StringLike": {
"glue:VpcIds": [
"vpc-id1234"
]
}
}
}
```
You can create a similar IAM policy to prohibit creating an AWS Glue job without specifying connection information.
**Restricting sessions on VPCs**
To enforce created sessions to run within a specified VPC, you restrict role permission by adding a `Deny` effect on the `glue:CreateSession` action with the condition that the glue:vpc-id not equal to vpc-<123>. For example:
```
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]}
}
```
You also can enforce created sessions to run within a VPC by adding a `Deny` effect on the `glue:CreateSession` action with the condition that the `glue:vpc-id` is null. For example:
```
{
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Condition": {
"Null": {"glue:VpcIds": true}
}
},
{
"Effect": "Allow",
"Action": [
"glue:CreateSession"
],
"Resource": ["*"]
}
```
### Control policies that control settings using context keys
AWS Glue provides a context key (`glue:CredentialIssuingService= glue.amazonaws.com`) to each role session that AWS Glue makes available to the job and developer endpoint. This allows you to implement security controls for the actions taken by AWS Glue scripts. AWS Glue provides another context key (`glue:RoleAssumedBy=glue.amazonaws.com`) to each role session where AWS Glue makes a call to another AWS service on the customer's behalf (not by a job/dev endpoint, but directly by the AWS Glue service).
**Example usage**
Specify the conditional permission in an IAM policy and attach it to the role to be used by an AWS Glue job. This ensures certain actions are allowed/denied based on whether the role session is used for an AWS Glue job runtime environment.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"glue:CredentialIssuingService": "glue.amazonaws.com"
}
}
}
```
## Deny an identity the ability to create data preview sessions
This section contains an IAM policy example used to deny an identity the ability to create data preview sessions. Attach this policy to the identity, which is separate from the role used by the data preview session during its run.
```
{
"Sid": "DatapreviewDeny",
"Effect": "Deny",
"Action": [
"glue:CreateSession"
],
"Resource": [
"arn:aws:glue:*:*:session/glue-studio-datapreview*"
]
}
```
# Resource-based policy examples for AWS Glue
This section contains example resource-based policies, including policies that grant cross-account access.
The examples use the AWS Command Line Interface (AWS CLI) to interact with AWS Glue service API operations. You can perform the same operations on the AWS Glue console or using one of the AWS SDKs.
**Important**
By changing an AWS Glue resource policy, you might accidentally revoke permissions for existing AWS Glue users in your account and cause unexpected disruptions. Try these examples only in development or test accounts, and ensure that they don't break any existing workflows before you make the changes.
**Topics**
+ [Considerations for using resource-based policies with AWS Glue](#security_iam_resource-based-policy-examples-considerations)
+ [Use a resource policy to control access in the same account](#glue-policy-resource-policies-example-same-account)
## Considerations for using resource-based policies with AWS Glue
**Note**
Both IAM policies and an AWS Glue resource policy take a few seconds to propagate. After you attach a new policy, you might notice that the old policy is still in effect until the new policy has propagated through the system.
You use a policy document written in JSON format to create or modify a resource policy. The policy syntax is the same as for an identity-based IAM policy (see [IAM JSON policy reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)), with the following exceptions:
+ A `"Principal"` or `"NotPrincipal"` block is required for each policy statement.
+ The `"Principal"` or `"NotPrincipal"` must identify valid existing principals. Wildcard patterns (like `arn:aws:iam::account-id:user/*`) are not allowed.
+ The `"Resource"` block in the policy requires all resource ARNs to match the following regular expression syntax (where the first `%s` is the *region*, and the second `%s` is the *account-id*):
```
*arn:aws:glue:%s:%s:(\*|[a-zA-Z\*]+\/?.*)
```
For example, both `arn:aws:glue:us-west-2:account-id:*` and `arn:aws:glue:us-west-2:account-id:database/default` are allowed, but `*` is not allowed.
+ Unlike identity-based policies, an AWS Glue resource policy must only contain Amazon Resource Names (ARNs) of resources that belong to the catalog that the policy is attached to. Such ARNs always start with `arn:aws:glue:`.
+ A policy cannot cause the identity that creates it to be locked out of further policy creation or modification.
+ A resource-policy JSON document cannot exceed 10 KB in size.
## Use a resource policy to control access in the same account
In this example, an admin user in Account A creates a resource policy that grants IAM user `Alice` in Account A full access to the catalog. Alice has no IAM policy attached.
To do this, the admin user runs the following AWS CLI command.
```
# Run as admin of Account A
$ aws glue put-resource-policy --profile administrator-name --region us-west-2 --policy-in-json '{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": [
"arn:aws:iam::account-A-id:user/Alice"
]
},
"Effect": "Allow",
"Action": [
"glue:*"
],
"Resource": [
"arn:aws:glue:us-west-2:account-A-id:*"
]
}
]
}'
```
Instead of entering the JSON policy document as a part of your AWS CLI command, you can save a policy document in a file and reference the file path in the AWS CLI command, prefixed by `file://`. The following is an example of how you might do that.
```
$ echo '{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": [
"arn:aws:iam::account-A-id:user/Alice"
]
},
"Effect": "Allow",
"Action": [
"glue:*"
],
"Resource": [
"arn:aws:glue:us-west-2:account-A-id:*"
]
}
]
}' > /temp/policy.json
$ aws glue put-resource-policy --profile admin1 \
--region us-west-2 --policy-in-json file:///temp/policy.json
```
After this resource policy has propagated, Alice can access all AWS Glue resources in Account A, as follows.
```
# Run as user Alice
$ aws glue create-database --profile alice --region us-west-2 --database-input '{
"Name": "new_database",
"Description": "A new database created by Alice",
"LocationUri": "s3://amzn-s3-demo-bucket"
}'
$ aws glue get-table --profile alice --region us-west-2 --database-name "default" --table-name "tbl1"}
```
In response to Alice's `get-table` call, the AWS Glue service returns the following.
```
{
"Table": {
"Name": "tbl1",
"PartitionKeys": [],
"StorageDescriptor": {
......
},
......
}
}
```
# Granting AWS managed policies for AWS Glue
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 (predefined) policies for AWS Glue
AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. These AWS managed policies grant necessary permissions for common use cases so that you can avoid having to investigate what permissions are needed. 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*.
The following AWS managed policies, which you can attach to identities in your account, are specific to AWS Glue and are grouped by use case scenario:
+ [AWSGlueConsoleFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueConsoleFullAccess) – Grants full access to AWS Glue resources when an identity that the policy is attached to uses the AWS Management Console. If you follow the naming convention for resources specified in this policy, users have full console capabilities. This policy is typically attached to users of the AWS Glue console.
+ [AWSGlueServiceRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSGlueServiceRole) – Grants access to resources that various AWS Glue processes require to run on your behalf. These resources include AWS Glue, Amazon S3, IAM, CloudWatch Logs, and Amazon EC2. If you follow the naming convention for resources specified in this policy, AWS Glue processes have the required permissions. This policy is typically attached to roles specified when defining crawlers, jobs, and development endpoints.
+ [AwsGlueSessionUserRestrictedServiceRole](https://console.aws.amazon.com/iam/home#policies/details/arn:aws:iam::aws:policy%2Fservice-role%2FAwsGlueSessionUserRestrictedServiceRole) – Provides full access to all AWS Glue resources except for sessions. It allows users to create and use only the interactive sessions that are associated with the user. This policy includes other permissions needed by AWS Glue to manage AWS Glue resources in other AWS services. The policy also allows adding tags to AWS Glue resources in other AWS services.
**Note**
To achieve the full security benefits, do not grant this policy to a user that was assigned the `AWSGlueServiceRole`, `AWSGlueConsoleFullAccess`, or `AWSGlueConsoleSageMakerNotebookFullAccess` policy.
+ [AwsGlueSessionUserRestrictedPolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AwsGlueSessionUserRestrictedPolicy) – Provides access to create AWS Glue interactive sessions using the `CreateSession` API operation only if a tag key “owner” and value that match the assignee's AWS user ID are provided. This identity policy is attached to the IAM user that invokes the `CreateSession` API operation. This policy also permits the assignee to interact with the AWS Glue interactive session resources that were created with an “owner” tag and value that match their AWS user ID. This policy denies permission to change or remove "owner" tags from an AWS Glue session resource after the session is created.
**Note**
To achieve the full security benefits, do not grant this policy to a user that was assigned the `AWSGlueServiceRole`, `AWSGlueConsoleFullAccess`, or `AWSGlueConsoleSageMakerNotebookFullAccess` policy.
+ [AwsGlueSessionUserRestrictedNotebookServiceRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AwsGlueSessionUserRestrictedNotebookServiceRole) – Provides sufficient access to the AWS Glue Studio notebook session to interact with specific AWS Glue interactive session resources. These are resources that are created with the “owner” tag value that matches the AWS user ID of the principal (IAM user or role) that creates the notebook. For more information about these tags, see the [Principal key values](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infotouse) chart in the *IAM User Guide*.
This service-role policy is attached to the role that is specified with a magic command within the notebook or is passed as a role to the `CreateSession` API operation. This policy also permits the principal to create an AWS Glue interactive session from the AWS Glue Studio notebook interface only if a tag key “owner” and value match the AWS user ID of the principal. This policy denies permission to change or remove "owner" tags from an AWS Glue session resource after the session is created. This policy also includes permissions for writing and reading from Amazon S3 buckets, writing CloudWatch logs, and creating and deleting tags for Amazon EC2 resources used by AWS Glue.
**Note**
To achieve the full security benefits, do not grant this policy to a role that was assigned the `AWSGlueServiceRole`, `AWSGlueConsoleFullAccess`, or `AWSGlueConsoleSageMakerNotebookFullAccess` policy.
+ [AwsGlueSessionUserRestrictedNotebookPolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AwsGlueSessionUserRestrictedNotebookPolicy) – Provides access to create an AWS Glue interactive session from the AWS Glue Studio notebook interface only if there is a tag key “owner” and value that match the AWS user IDof the principal (IAM user or role) that creates the notebook. For more information about these tags, see the [Principal key values](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infotouse) chart in the *IAM User Guide*.
This policy is attached to the principal (IAM user or role) that creates sessions from the AWS Glue Studio notebook interface. This policy also permits sufficient access to the AWS Glue Studio notebook to interact with specific AWS Glue interactive session resources. These are resources that are created with the “owner” tag value that matches the AWS user ID of the principal. This policy denies permission to change or remove "owner" tags from an AWS Glue session resource after the session is created.
+ [AWSGlueServiceNotebookRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSGlueServiceNotebookRole) – Grants access to AWS Glue sessions started in an AWS Glue Studio notebook. This policy allows listing and getting session information for all sessions, but only permits users to create and use the sessions tagged with their AWS user ID. This policy denies permission to change or remove “owner” tags from AWS Glue session resources tagged with their AWS ID.
Assign this policy to the AWS user who creates jobs using the notebook interface in AWS Glue Studio.
+ [AWSGlueConsoleSageMakerNotebookFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueConsoleSageMakerNotebookFullAccess) – Grants full access to AWS Glue and SageMaker AI resources when the identity that the policy is attached to uses the AWS Management Console. If you follow the naming convention for resources specified in this policy, users have full console capabilities. This policy is typically attached to users of the AWS Glue console who manage SageMaker AI notebooks.
+ [AWSGlueSchemaRegistryFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueSchemaRegistryFullAccess) – Grants full access to AWS Glue Schema Registry resources when the identity that the policy is attached to uses the AWS Management Console or AWS CLI. If you follow the naming convention for resources specified in this policy, users have full console capabilities. This policy is typically attached to users of the AWS Glue console or AWS CLI who manage the AWS Glue Schema Registry.
+ [AWSGlueSchemaRegistryReadonlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueSchemaRegistryReadonlyAccess) – Grants read-only access to AWS Glue Schema Registry resources when an identity that the policy is attached to uses the AWS Management Console or AWS CLI. If you follow the naming convention for resources specified in this policy, users have full console capabilities. This policy is typically attached to users of the AWS Glue console or AWS CLI who use the AWS Glue Schema Registry.
**Note**
You can review these permissions policies by signing in to the IAM console and searching for specific policies there.
You can also create your own custom IAM policies to allow permissions for AWS Glue actions and resources. You can attach these custom policies to the IAM users or groups that require those permissions.
To create a connection with VPC configuration while using a custom IAM role, it must have the following VPC access actions:
+ secretsmanager:GetSecretValue
+ secretsmanager:PutSecretValue
+ secretsmanager:DescribeSecret
+ ec2:CreateNetworkInterface
+ ec2:DeleteNetworkInterface
+ ec2:DescribeNetworkInterfaces
+ ec2:DescribeSubnets
## AWS Glue updates to AWS managed policies
View details about updates to AWS managed policies for AWS Glue since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the AWS Glue Document history page.
| Change | Description | Date |
| --- | --- | --- |
| AwsGlueSessionUserRestrictedNotebookPolicy – Minor update to an existing policy. | Add allow for glue:TagResource action on the owner tag key. Required for supporting on tag-on-create for sessions with owner tag key. | August 30, 2024 |
| AwsGlueSessionUserRestrictedNotebookServiceRole – Minor update to an existing policy. | Add allow for glue:TagResource action on the owner tag key. Required for supporting on tag-on-create for sessions with owner tag key. | August 30, 2024 |
| AwsGlueSessionUserRestrictedPolicy – Minor update to an existing policy. | Add allow for glue:TagResource action on the owner tag key. Required for supporting on tag-on-create for sessions with owner tag key. | August 5, 2024 |
| AwsGlueSessionUserRestrictedServiceRole – Minor update to an existing policy. | Add allow for glue:TagResource action on the owner tag key. Required for supporting on tag-on-create for sessions with owner tag key. | August 5, 2024 |
| AwsGlueSessionUserRestrictedPolicy – Minor update to an existing policy. | Add glue:StartCompletion and glue:GetCompletion to policy. Required for Amazon Q data integration in AWS Glue. | April 30, 2024 |
| AwsGlueSessionUserRestrictedNotebookServiceRole – Minor update to an existing policy. | Add glue:StartCompletion and glue:GetCompletion to policy. Required for Amazon Q data integration in AWS Glue. | April 30, 2024 |
| AwsGlueSessionUserRestrictedServiceRole – Minor update to an existing policy. | Add glue:StartCompletion and glue:GetCompletion to policy. Required for Amazon Q data integration in AWS Glue. | April 30, 2024 |
| AWSGlueServiceNotebookRole – Minor update to an existing policy. | Add glue:StartCompletion and glue:GetCompletion to policy. Required for Amazon Q data integration in AWS Glue. | Jan 30, 2024 |
| AwsGlueSessionUserRestrictedNotebookPolicy – Minor update to an existing policy. | Add glue:StartCompletion and glue:GetCompletion to policy. Required for Amazon Q data integration in AWS Glue. | Nov 29, 2023 |
| AWSGlueServiceNotebookRole – Minor update to an existing policy. | Add codewhisperer:GenerateRecommendations to policy. Required for a new feature where AWS Glue generates CodeWhisperer recommendations. | Oct 9, 2023 |
| AWSGlueServiceRole – Minor update to an existing policy. | Tighten scope of CloudWatch permissions to better reflect AWS Glue logging. | Aug 4, 2023 |
| AWSGlueConsoleFullAccess – Minor update to an existing policy. | Add databrew recipe List and Describe permissions to policy. Required to provide full administrative access for new features where AWS Glue can access recipes. | May 9, 2023 |
| AWSGlueConsoleFullAccess – Minor update to an existing policy. | Add cloudformation:ListStacks to policy. Preserves existing capabilities after changes to CloudFormation authorization requirements. | March 28, 2023 |
| New managed policies added for the interactive sessions feature: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/glue/latest/dg/security-iam-awsmanpol.html) | These policies were designed to provide additional security for interactive sessions and notebooks in AWS Glue Studio. The policies restrict access to the `CreateSession` API operation so that only the owner has access. | November 30, 2021 |
| AWSGlueConsoleSageMakerNotebookFullAccess – Update to an existing policy. | Removed a redundant resource ARN (`arn:aws:s3:::aws-glue-*/*`) for the action that grants read/write permissions on Amazon S3 buckets that AWS Glue uses to store scripts and temporary files. Fixed a syntax issue by changing `"StringEquals"` to `"ForAnyValue:StringLike"`, and moved the` "Effect": "Allow"` lines to precede the `"Action":` line in each place where they were out of order. | July 15, 2021 |
| AWSGlueConsoleFullAccess – Update to an existing policy. | Removed a redundant resource ARN (arn:aws:s3:::aws-glue-\$1/\$1) for the action that grants read/write permissions on Amazon S3 buckets that AWS Glue uses to store scripts and temporary files. | July 15, 2021 |
| AWS Glue started tracking changes. | AWS Glue started tracking changes for its AWS managed policies. | June 10, 2021 |
# Granting dynamically scoped policies for job execution
AWS Glue offers a powerful new capability: dynamic session policies for job executions. This feature allows you to specify custom, fine-grained permissions for each job run without creating multiple IAM roles.
When you start a Glue job using the `StartJobRun` API, you can include an inline session policy. This policy temporarily modifies the permissions of the job's execution role for the duration of that specific job run. It's similar to using temporary credentials with the `AssumeRole` API in other AWS services.
+ **Enhanced security**: You can limit job permissions to the minimum necessary for each run.
+ **Simplified management**: Eliminates the need to create and maintain numerous IAM roles for different scenarios.
+ **Flexibility**: You can be adjust permissions dynamically based on runtime parameters or tenant-specific needs.
+ **Scalability**: This method excels in multi-tenant environments where you need to isolate resources between tenants.
**Examples for granting dynamically scoped policies usage:**
The following examples demonstrate granting jobs *read* and *write* access only to a specific Amazon S3 bucket path, where the path is dynamically determined by the job run ID. This illustrates how to implement granular, execution-specific permissions for each job run.
**From CLI**
```
aws glue start-job-run \
--job-name "your-job-name" \
--execution-role-session-policy '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::specific-bucket/${JobRunId}/*"
]
}
]
}'
```
# Specifying AWS Glue resource ARNs
In AWS Glue, you can control access to resources using an AWS Identity and Access Management (IAM) policy. In a policy, you use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. Not all resources in AWS Glue support ARNs.
**Topics**
+ [Data Catalog ARNs](#data-catalog-resource-arns)
+ [ARNs for non-catalog objects in AWS Glue](#non-catalog-resource-arns)
+ [Access control for AWS Glue non-catalog singular API operations](#non-catalog-singular-apis)
+ [Access control for AWS Glue non-catalog API operations that retrieve multiple items](#non-catalog-plural-apis)
+ [Access control for AWS Glue non-catalog BatchGet API operations](#non-catalog-batch-get-apis)
## Data Catalog ARNs
Data Catalog resources have a hierarchical structure, with `catalog` as the root.
```
arn:aws:glue:region:account-id:catalog
```
Each AWS account has a single Data Catalog in an AWS Region with the 12-digit account ID as the catalog ID. Resources have unique ARNs associated with them, as shown in the following table.
| **Resource type** | **ARN format** |
| --- | --- |
| Catalog | `arn:aws:glue:region:account-id:catalog` For example: `arn:aws:glue:us-east-1:123456789012:catalog` |
| Database | `arn:aws:glue:region:account-id:database/database name` For example: `arn:aws:glue:us-east-1:123456789012:database/db1` |
| Table | `arn:aws:glue:region:account-id:table/database name/table name` For example: `arn:aws:glue:us-east-1:123456789012:table/db1/tbl1` |
| Federated S3 tables catalog (All table buckets) | `arn:aws:glue:region:account-id:catalog/s3tablescatalog` For example: `arn:aws:glue:us-east-1:123456789012:catalog/s3tablescatalog` |
| Federated S3 table bucket catalog (child catalog) | `arn:aws:glue:region:account-id:catalog/s3tablescatalog/bucket name` For example: `arn:aws:glue:us-east-1:123456789012:catalog/s3tablescatalog/amzn-s3-demo-bucket1` |
| Federated S3 tables database | `arn:aws:glue:region:account-id:database/s3tablescatalog/child catalog name/database name` For example: `arn:aws:glue:us-east-1:123456789012:database/s3tablescatalog/amzn-s3-demo-bucket1/nsdb1` |
| Federated S3 table | `arn:aws:glue:region:account-id:table/s3tablescatalog/child catalog name/database name/table name` For example: `arn:aws:glue:us-east-1:123456789012:table/s3tablescatalog/amzn-s3-demo-bucket1/nsdb1/s3tbl1` |
| Federated S3 tables catalog (A single table bucket registered with Lake Formation) | `arn:aws:glue:region:account-id:catalog`/*catalog name* For example: `arn:aws:glue:us-east-1:123456789012:catalog/amzn-s3-demo-bucket1` |
| Federated S3 tables database | `arn:aws:glue:region:account-id:catalog`/*catalog name*/*database name* For example: `arn:aws:glue:us-east-1:123456789012:database/amzn-s3-demo-bucket1/nsdb1` |
| Federated S3 table | `arn:aws:glue:region:account-id:catalog`/*catalog name*/*database name*/*table name* For example: `arn:aws:glue:us-east-1:123456789012:table/amzn-s3-demo-bucket1/nsdb1/s3tbl1` |
| Federated or managed catalog (top-level catalog in a multi-catalog) | `arn:aws:glue:region:account-id:catalog/top-level catalog name` For example: `arn:aws:glue:us-east-1:123456789012:catalog/nscatalog` ARN format for a managed catalog follows the same structure. |
| Federated multi-level catalog (child catalog in a multi-level catalog) | `arn:aws:glue:region:account-id:catalog/top-level catalog name/child catalog name` For example: `arn:aws:glue:us-east-1:123456789012:catalog/nscatalog/dbcatalog` |
| Federated database | `arn:aws:glue:region:account-id:database/name space catalog name/child catalog name/database name` For example: `arn:aws:glue:us-east-1:123456789012:database/nscatalog/dbcatalog/schemadb` |
| Federated table | `arn:aws:glue:region:account-id:table/name space catalog name/child catalog name/database name/table name` For example: `arn:aws:glue:us-east-1:123456789012:table/nscatalog/dbcatalog/schemadb/rstbl1` |
| Catalog link container | `arn:aws:glue:region:account-id:catalog`/*link container name* For example: `arn:aws:glue:glue:us-east-1:123456789012:catalog`/linkcontainer-example |
| Database | `arn:aws:glue:region:account-id:catalog`/*link container name*/*database name* For example: `arn:aws:glue:glue:us-east-1:123456789012:database`/linkcontainer-example/link-db |
| User-defined function | `arn:aws:glue:region:account-id:userDefinedFunction/database name/user-defined function name` For example: `arn:aws:glue:us-east-1:123456789012:userDefinedFunction/db1/func1` |
| Connection | `arn:aws:glue:region:account-id:connection/connection name` For example: `arn:aws:glue:us-east-1:123456789012:connection/connection1` |
| Interactive Session | `arn:aws:glue:region:account-id:session/interactive session id` For example: `arn:aws:glue:us-east-1:123456789012:session/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111` |
To enable fine-grained access control, you can use these ARNs in your IAM policies and resource policies to grant and deny access to specific resources. Wildcards are allowed in the policies. For example, the following ARN matches all tables in database `default`.
```
arn:aws:glue:us-east-1:123456789012:table/default/*
```
**Important**
All operations performed on a Data Catalog resource require permission on the resource and all the ancestors of that resource. For example, to create a partition for a table requires permission on the table, database, and catalog where the table is located. The following example shows the permission required to create partitions on table `PrivateTable` in database `PrivateDatabase` in the Data Catalog.
```
{
"Sid": "GrantCreatePartitions",
"Effect": "Allow",
"Action": [
"glue:BatchCreatePartitions"
],
"Resource": [
"arn:aws:glue:us-east-1:123456789012:table/PrivateDatabase/PrivateTable",
"arn:aws:glue:us-east-1:123456789012:database/PrivateDatabase",
"arn:aws:glue:us-east-1:123456789012:catalog"
]
}
```
In addition to permission on the resource and all its ancestors, all delete operations require permission on all children of that resource. For example, deleting a database requires permission on all the tables and user-defined functions in the database, in addition to the database and the catalog where the database is located. The following example shows the permission required to delete database `PrivateDatabase` in the Data Catalog.
```
{
"Sid": "GrantDeleteDatabase",
"Effect": "Allow",
"Action": [
"glue:DeleteDatabase"
],
"Resource": [
"arn:aws:glue:us-east-1:123456789012:table/PrivateDatabase/*",
"arn:aws:glue:us-east-1:123456789012:userDefinedFunction/PrivateDatabase/*",
"arn:aws:glue:us-east-1:123456789012:database/PrivateDatabase",
"arn:aws:glue:us-east-1:123456789012:catalog"
]
}
```
In summary, actions on Data Catalog resources follow these permission rules:
Actions on the catalog require permission on the catalog only.
Actions on a database require permission on the database and catalog.
Delete actions on a database require permission on the database and catalog plus all tables and user-defined functions in the database.
Actions on a table, partition, or table version require permission on the table, database, and catalog.
Actions on a user-defined function require permission on the user-defined function, database, and catalog.
Actions on a connection require permission on the connection and catalog.
## ARNs for non-catalog objects in AWS Glue
Some AWS Glue resources allow resource-level permissions to control access using an ARN. You can use these ARNs in your IAM policies to enable fine-grained access control. The following table lists the resources that can contain resource ARNs.
| **Resource type** | **ARN format** |
| --- | --- |
| Crawler | `arn:aws:glue:region:account-id:crawler/crawler-name` For example: `arn:aws:glue:us-east-1:123456789012:crawler/mycrawler` |
| Job | `arn:aws:glue:region:account-id:job/job-name` For example: `arn:aws:glue:us-east-1:123456789012:job/testjob` |
| Trigger | `arn:aws:glue:region:account-id:trigger/trigger-name` For example: `arn:aws:glue:us-east-1:123456789012:trigger/sampletrigger` |
| Development endpoint | `arn:aws:glue:region:account-id:devEndpoint/development-endpoint-name` For example: `arn:aws:glue:us-east-1:123456789012:devEndpoint/temporarydevendpoint` |
| Machine learning transform | `arn:aws:glue:region:account-id:mlTransform/transform-id` For example: `arn:aws:glue:us-east-1:123456789012:mlTransform/tfm-1234567890` |
## Access control for AWS Glue non-catalog singular API operations
AWS Glue non-catalog *singular* API operations act on a single item (development endpoint). Examples are `GetDevEndpoint`, `CreateUpdateDevEndpoint`, and `UpdateDevEndpoint`. For these operations, a policy must put the API name in the `"action"` block and the resource ARN in the `"resource"` block.
Suppose that you want to allow a user to call the `GetDevEndpoint` operation. The following policy grants the minimum necessary permissions to an endpoint named `myDevEndpoint-1`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MinimumPermissions",
"Effect": "Allow",
"Action": "glue:GetDevEndpoint",
"Resource": "arn:aws:glue:us-east-1:111122223333:devEndpoint/myDevEndpoint-1"
}
]
}
```
------
The following policy allows `UpdateDevEndpoint` access to resources that match `myDevEndpoint-` with a wildcard (\$1).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionWithWildcard",
"Effect": "Allow",
"Action": "glue:UpdateDevEndpoint",
"Resource": "arn:aws:glue:us-east-1:111122223333:devEndpoint/myDevEndpoint-*"
}
]
}
```
------
You can combine the two policies as in the following example. You might see `EntityNotFoundException` for any development endpoint whose name begins with `A`. However, an access denied error is returned when you try to access other development endpoints.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CombinedPermissions",
"Effect": "Allow",
"Action": [
"glue:UpdateDevEndpoint",
"glue:GetDevEndpoint"
],
"Resource": "arn:aws:glue:us-east-1:111122223333:devEndpoint/A*"
}
]
}
```
------
## Access control for AWS Glue non-catalog API operations that retrieve multiple items
Some AWS Glue API operations retrieve multiple items (such as multiple development endpoints); for example, `GetDevEndpoints`. For this operation, you can specify only a wildcard (\$1) resource, and not specific ARNs.
For example, to include `GetDevEndpoints` in the policy, the resource must be scoped to the wildcard (\$1). The singular operations (`GetDevEndpoint`, `CreateDevEndpoint`, and `DeleteDevendpoint`) are also scoped to all (\$1) resources in the example.
```
{
"Sid": "PluralAPIIncluded",
"Effect": "Allow",
"Action": [
"glue:GetDevEndpoints",
"glue:GetDevEndpoint",
"glue:CreateDevEndpoint",
"glue:UpdateDevEndpoint"
],
"Resource": [
"*"
]
}
```
## Access control for AWS Glue non-catalog BatchGet API operations
Some AWS Glue API operations retrieve multiple items (such as multiple development endpoints); for example, `BatchGetDevEndpoints`. For this operation, you can specify an ARN to limit the scope of resources that can be accessed.
For example, to allow access to a specific development endpoint, include `BatchGetDevEndpoints` in the policy with its resource ARN.
```
{
"Sid": "BatchGetAPIIncluded",
"Effect": "Allow",
"Action": [
"glue:BatchGetDevEndpoints"
],
"Resource": [
"arn:aws:glue:us-east-1:123456789012:devEndpoint/de1"
]
}
```
With this policy, you can successfully access the development endpoint named `de1`. However, if you try to access the development endpoint named `de2`, an error is returned.
```
An error occurred (AccessDeniedException) when calling the BatchGetDevEndpoints operation: No access to any requested resource.
```
**Important**
For alternative approaches to setting up IAM policies, such as using `List` and `BatchGet` API operations, see [Identity-based policy examples for AWS Glue](security_iam_id-based-policy-examples.md).
# Granting cross-account access
Granting access to Data Catalog resources across accounts enables your extract, transform, and load (ETL) jobs to query and join data from different accounts.
**Topics**
+ [Methods for granting cross-account access in AWS Glue](#cross-account-how-works)
+ [Adding or updating the Data Catalog resource policy](#cross-account-adding-resource-policy)
+ [Making a cross-account API call](#cross-account-calling)
+ [Making a cross-account ETL call](#cross-account-calling-etl)
+ [Cross-account CloudTrail logging](#cross-account-ct-logs)
+ [Cross-account resource ownership and billing](#cross-account-ownership-and-billing)
+ [Cross-account access limitations](#cross-account-limitations)
## Methods for granting cross-account access in AWS Glue
You can grant access to your data to external AWS accounts by using AWS Glue methods or by using AWS Lake Formation cross-account grants. The AWS Glue methods use AWS Identity and Access Management (IAM) policies to achieve fine-grained access control. Lake Formation uses a simpler `GRANT/REVOKE` permissions model similar to the `GRANT/REVOKE` commands in a relational database system.
This section describes using the AWS Glue methods. For information about using Lake Formation cross-account grants, see [Granting Lake Formation Permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/lake-formation-permissions.html) in the *AWS Lake Formation Developer Guide*.
There are two AWS Glue methods for granting cross-account access to a resource:
+ Use a Data Catalog resource policy
+ Use an IAM role
**Granting cross-account access using a resource policy**
The following are the general steps for granting cross-account access using a Data Catalog resource policy:
1. An administrator (or other authorized identity) in Account A attaches a resource policy to the Data Catalog in Account A. This policy grants Account B specific cross-account permissions to perform operations on a resource in Account A's catalog.
1. An administrator in Account B attaches an IAM policy to an IAM identity in Account B that delegates the permissions received from Account A.
The identity in Account B now has access to the specified resource in Account A.
The identity needs permission from *both* the resource owner (Account A) *and* their parent account (Account B) to be able to access the resource.
**Granting cross-account access using an IAM role**
The following are the general steps for granting cross-account access using an IAM role:
1. An administrator (or other authorized identity) in the account that owns the resource (Account A) creates an IAM role.
1. The administrator in Account A attaches a policy to the role that grants cross-account permissions for access to the resource in question.
1. The administrator in Account A attaches a trust policy to the role that identifies an IAM identity in a different account (Account B) as the principal who can assume the role.
The principal in the trust policy can also be an AWS service principal if you want to grant an AWS service permission to assume the role.
1. An administrator in Account B now delegates permissions to one or more IAM identities in Account B so that they can assume that role. Doing so gives those identities in Account B access to the resource in account A.
For more information about using IAM to delegate permissions, see [Access management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*. For more information about users, groups, roles, and permissions, see [Identities (users, groups, and roles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*.
For a comparison of these two approaches, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*. AWS Glue supports both options, with the restriction that a resource policy can grant access only to Data Catalog resources.
For example, to give the `Dev` role in Account B access to database `db1` in Account A, attach the following resource policy to the catalog in Account A.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Dev"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
In addition, Account B would have to attach the following IAM policy to the `Dev` role before it would actually get access to `db1` in Account A.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase"
],
"Resource": [
"arn:aws:glue:us-east-1:111122223333:catalog",
"arn:aws:glue:us-east-1:111122223333:database/db1"
]
}
]
}
```
------
## Adding or updating the Data Catalog resource policy
You can add or update the AWS Glue Data Catalog resource policy using the console, API, or AWS Command Line Interface (AWS CLI).
**Important**
If you have already made cross-account permission grants from your account with AWS Lake Formation, adding or updating the Data Catalog resource policy requires an extra step. For more information, see [Managing cross-account permissions using both AWS Glue and Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-cross-account.html) in the *AWS Lake Formation Developer Guide*.
To determine if Lake Formation cross-account grants exist, use the `glue:GetResourcePolicies` API operation or the AWS CLI. If `glue:GetResourcePolicies` returns any policies other than an already existing Data Catalog policy, then Lake Formation grants exist. For more information, see [Viewing all cross-account grants using the GetResourcePolicies API operation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-getresourcepolicies.html) in the *AWS Lake Formation Developer Guide*.
**To add or update the Data Catalog resource policy (console)**
1. Open the AWS Glue console at [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
Sign in as an AWS Identity and Access Management (IAM) administrative user who has the `glue:PutResourcePolicy` permission.
1. In the navigation pane, choose **Settings**.
1. On the **Data catalog settings** page, under **Permissions**, paste a resource policy into the text area. Then choose **Save**.
If the console displays a alert stating that the permissions in the policy will be in addition to any permissions granted using Lake Formation, choose **Proceed**.
**To add or update the Data Catalog resource policy (AWS CLI)**
+ Submit an `aws glue put-resource-policy` command. If Lake Formation grants already exist, ensure that you include the `--enable-hybrid` option with the value `'TRUE'`.
For examples of using this command, see [Resource-based policy examples for AWS Glue](security_iam_resource-based-policy-examples.md).
## Making a cross-account API call
All AWS Glue Data Catalog operations have a `CatalogId` field. If the required permissions have been granted to enable cross-account access, a caller can make Data Catalog API calls across accounts. The caller does this by passing the target AWS account ID in `CatalogId` so as to access the resource in that target account.
If no `CatalogId` value is provided, AWS Glue uses the caller's own account ID by default, and the call is not cross-account.
## Making a cross-account ETL call
Some AWS Glue PySpark and Scala APIs have a catalog ID field. If all the required permissions have been granted to enable cross-account access, an ETL job can make PySpark and Scala calls to API operations across accounts by passing the target AWS account ID in the catalog ID field to access Data Catalog resources in a target account.
If no catalog ID value is provided, AWS Glue uses the caller's own account ID by default, and the call is not cross-account.
For PySpark APIs that support `catalog_id`, see [GlueContext class](aws-glue-api-crawler-pyspark-extensions-glue-context.md). For Scala APIs that support `catalogId`, see [AWS Glue Scala GlueContext APIs](glue-etl-scala-apis-glue-gluecontext.md).
The following example shows the permissions required by the grantee to run an ETL job. In this example, *grantee-account-id* is the `catalog-id` of the client running the job and *grantor-account-id* is the owner of the resource. This example grants permission to all catalog resources in the grantor's account. To limit the scope of resources granted, you can provide specific ARNs for the catalog, database, table, and connection.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetConnection",
"glue:GetDatabase",
"glue:GetTable",
"glue:GetPartition"
],
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Resource": [
"arn:aws:glue:us-east-1:111122223333:*"
]
}
]
}
```
------
**Note**
If a table in the grantor's account points to an Amazon S3 location that is also in the grantor's account, the IAM role used to run an ETL job in the grantee's account must have permission to list and get objects from the grantor's account.
Given that the client in Account A already has permission to create and run ETL jobs, the following are the basic steps to set up an ETL job for cross-account access:
1. Allow cross-account data access (skip this step if Amazon S3 cross-account access is already set up).
1. Update the Amazon S3 bucket policy in Account B to allow cross-account access from Account A.
1. Update the IAM policy in Account A to allow access to the bucket in Account B.
1. Allow cross-account Data Catalog access.
1. Create or update the resource policy attached to the Data Catalog in Account B to allow access from Account A.
1. Update the IAM policy in Account A to allow access to the Data Catalog in Account B.
## Cross-account CloudTrail logging
When an AWS Glue extract, transform, and load (ETL) job accesses the underlying data of a Data Catalog table shared through AWS Lake Formation cross-account grants, there is additional AWS CloudTrail logging behavior.
For purposes of this discussion, the AWS account that shared the table is the owner account, and the account that the table was shared with is the recipient account. When an ETL job in the recipient account accesses data in the table in the owner account, the data-access CloudTrail event that is added to the logs for the recipient account gets copied to the owner account's CloudTrail logs. This is so owner accounts can track data accesses by the various recipient accounts. By default, the CloudTrail events do not include a human-readable principal identifier (principal ARN). An administrator in the recipient account can opt in to include the principal ARN in the logs.
For more information, see [Cross-account CloudTrail logging](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-logging.html) in the *AWS Lake Formation Developer Guide*.
**See Also**
[Logging and monitoring in AWS Glue](logging-and-monitoring.md)
## Cross-account resource ownership and billing
When a user in one AWS account (Account A) creates a new resource such as a database in a different account (Account B), that resource is then owned by Account B, the account where it was created. An administrator in Account B automatically gets full permissions to access the new resource, including reading, writing, and granting access permissions to a third account. The user in Account A can access the resource that they just created only if they have the appropriate permissions granted by Account B.
Storage costs and other costs that are directly associated with the new resource are billed to Account B, the resource owner. The cost of requests from the user who created the resource are billed to the requester's account, Account A.
For more information about AWS Glue billing and pricing, see [How AWS Pricing Works](https://d0.awsstatic.com/whitepapers/aws_pricing_overview.pdf).
## Cross-account access limitations
AWS Glue cross-account access has the following limitations:
+ Cross-account access to AWS Glue is not allowed if you created databases and tables using Amazon Athena orAmazon Redshift Spectrum prior to a region's support for AWS Glue and the resource owner account has not migrated the Amazon Athena data catalog to AWS Glue. You can find the current migration status using the [GetCatalogImportStatus (get\$1catalog\$1import\$1status)](aws-glue-api-catalog-migration.md#aws-glue-api-catalog-migration-GetCatalogImportStatus). For more details on how to migrate an Athena catalog to AWS Glue, see [Upgrading to the AWS Glue Data Catalog step-by-step](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) in the *Amazon Athena User Guide*.
+ Cross-account access is *only* supported for Data Catalog resources, including databases, tables, user-defined functions, and connections.
+ Cross-account access to the Data Catalog from Athena requires you to register the catalog as an Athena `DataCatalog` resource. For instructions, see [Registering an AWS Glue Data Catalog from another account](https://docs.aws.amazon.com/athena/latest/ug/data-sources-glue-cross-account.html) in the *Amazon Athena User Guide*.
# Troubleshooting AWS Glue identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Glue and IAM.
**Topics**
+ [I am not authorized to perform an action in AWS Glue](#security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my AWS Glue resources](#security_iam_troubleshoot-cross-account-access)
## I am not authorized to perform an action in AWS Glue
If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a fictional `my-example-widget` resource but doesn't have the fictional `glue:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: glue:GetWidget on resource: my-example-widget
```
In this case, the policy for the `mateojackson` user must be updated to allow access to the `my-example-widget` resource by using the `glue:GetWidget` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I am 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 AWS Glue.
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 AWS Glue. 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 want to allow people outside of my AWS account to access my AWS Glue 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 AWS Glue supports these features, see [How AWS Glue 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*.