Fine-grained access to databases and tables in the AWS Glue Data Catalog
If you use the AWS Glue Data Catalog with Amazon Athena, you can define resource-level policies for the following Data Catalog objects that are used in Athena: databases and tables.
You define resource-level permissions in IAM identity-based policies.
This section discusses resource-level permissions in IAM identity-based policies. These are different from resource-based policies. For more information about the differences, see Identity-based policies and resource-based policies in the IAM User Guide.
See the following topics for these tasks:
To perform this task | See the following topic |
---|---|
Create an IAM policy that defines fine-grained access to resources | Creating IAM policies in the IAM User Guide. |
Learn about IAM identity-based policies used in AWS Glue | Identity-based policies (IAM policies) in the AWS Glue Developer Guide. |
In this section
Limitations
Consider the following limitations when using fine-grained access control with the AWS Glue Data Catalog and Athena:
-
You can limit access only to databases and tables. Fine-grained access controls apply at the table level and you cannot limit access to individual partitions within a table. For more information, see Table partitions and versions in AWS Glue.
-
The AWS Glue Data Catalog contains the following resources:
CATALOG
,DATABASE
,TABLE
, andFUNCTION
.Note From this list, resources that are common between Athena and the AWS Glue Data Catalog are
TABLE
,DATABASE
, andCATALOG
for each account.Function
is specific to AWS Glue. For delete actions in Athena, you must include permissions to AWS Glue actions. See Examples of fine-grained permissions to tables and databases.The hierarchy is as follows:
CATALOG
is an ancestor of allDATABASES
in each account, and eachDATABASE
is an ancestor for all of itsTABLES
andFUNCTIONS
. For example, for a table namedtable_test
that belongs to a databasedb
in the catalog in your account, its ancestors aredb
and the catalog in your account. For thedb
database, its ancestor is the catalog in your account, and its descendants are tables and functions. For more information about the hierarchical structure of resources, see List of ARNs in Data Catalog in the AWS Glue Developer Guide. -
For any non-delete Athena action on a resource, such as
CREATE DATABASE
,CREATE TABLE
,SHOW DATABASE
,SHOW TABLE
, orALTER TABLE
, you need permissions to call this action on the resource (table or database) and all ancestors of the resource in the Data Catalog. For example, for a table, its ancestors are the database to which it belongs, and the catalog for the account. For a database, its ancestor is the catalog for the account. See Examples of fine-grained permissions to tables and databases. -
For a delete action in Athena, such as
DROP DATABASE
orDROP TABLE
, you also need permissions to call the delete action on all ancestors and descendants of the resource in the Data Catalog. For example, to delete a database you need permissions on the database, the catalog, which is its ancestor, and all the tables and user defined functions, which are its descendents. A table does not have descendants. To runDROP TABLE
, you need permissions to this action on the table, the database to which it belongs, and the catalog. See Examples of fine-grained permissions to tables and databases. -
When limiting access to a specific database in the Data Catalog, you must also specify the access policy to the
default
database and catalog for each AWS Region forGetDatabase
andCreateDatabase
actions. If you use Athena in more than one Region, add a separate line to the policy for the resource ARN for eachdefault
database and catalog in each Region.For example, to allow
GetDatabase
access toexample_db
in theus-east-1
(N.Virginia) Region, also include thedefault
database and catalog in the policy for that Region for the actionsGetDatabase
,GetDatabases
, andCreateDatabase
:{ "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:CreateDatabase" ], "Resource": [
"arn:aws:glue:us-east-1:123456789012:catalog"
,"arn:aws:glue:us-east-1:123456789012:database/default"
,"arn:aws:glue:us-east-1:123456789012:database/example_db"
] }
Mandatory: Access policy to the
Default
database and catalog per AWS Region
For Athena to work with the AWS Glue Data Catalog, the following access policy to the
default
database and to the AWS Glue Data Catalog per AWS Region for
GetDatabase
, GetDatabases
, and CreateDatabase
must be present :
{ "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:CreateDatabase" ], "Resource": [
"arn:aws:glue:us-east-1:123456789012:catalog"
,"arn:aws:glue:us-east-1:123456789012:database/default"
] }
Table partitions and versions in AWS Glue
In AWS Glue, tables can have partitions and versions. Table versions and partitions are not considered to be independent resources in AWS Glue. Access to table versions and partitions is given by granting access on the table and ancestor resources for the table.
For the purposes of fine-grained access control, the following access permissions apply:
-
Fine-grained access controls apply at the table level. You can limit access only to databases and tables. For example, if you allow access to a partitioned table, this access applies to all partitions in the table. You cannot limit access to individual partitions within a table.
Important Having access to all partitions within a table is not sufficient if you need to run actions in AWS Glue on partitions. To run actions on partitions, you need permissions for those actions. For example, to run
GetPartitions
on tablemyTable
in the databasemyDB
, you need permissions for the actionglue:GetPartitions
in the Data Catalog, themyDB
database, andmyTable
. -
Fine-grained access controls do not apply to table versions. As with partitions, access to previous versions of a table is granted through access to the table version APIs in AWS Glue on the table, and to the table ancestors.
For information about permissions on AWS Glue actions, see AWS Glue API permissions: Actions and resources reference in the AWS Glue Developer Guide.
Examples of fine-grained permissions to tables and databases
The following table lists examples of IAM identity-based policies that allow fine-grained access to databases and tables in Athena. We recommend that you start with these examples and, depending on your needs, adjust them to allow or deny specific actions to particular databases and tables.
These examples include the access policy to the default
database and
catalog, for GetDatabase
and CreateDatabase
actions. This
policy is required for Athena and the AWS Glue Data Catalog to work together. For multiple AWS
Regions, include this policy for each of the default
databases and their
catalogs, one line for each Region.
In addition, replace the example_db
database and test
table
names with the names for your databases and tables.
DDL statement | Example of an IAM access policy granting access to the resource |
---|---|
ALTER DATABASE | Allows you to modify the properties for the example_db
database.
|
CREATE DATABASE | Allows you to create the database named
example_db .
|
CREATE TABLE | Allows you to create a table named test in the
example_db
database.
|
DROP DATABASE | Allows you to drop the example_db database, including
all tables in it.
|
DROP TABLE | Allows you to drop a partitioned table named test in the
example_db database. If your table does not have
partitions, do not include partition
actions.
|
MSCK REPAIR TABLE | Allows you to update catalog metadata after you add Hive compatible
partitions to the table named test in the
example_db
database.
|
SHOW DATABASES | Allows you to list all databases in the
AWS Glue Data Catalog.
|
SHOW TABLES | Allows you to list all tables in the example_db
database.
|