Lake Formation Tag-Based Access Control Permissions Model - AWS Lake Formation

Lake Formation Tag-Based Access Control Permissions Model

The following are the rules and permissions that you must understand to effectively use the Lake Formation tag-based access control (LF-TBAC) method for securing your data lake.

  • All LF-tags must be predefined before they can be assigned to Data Catalog resources or granted to principals.

    Data engineers and analysts decide on the characteristics and relationships for LF-tags. The data lake administrator then creates and maintains the LF-tags in Lake Formation. Only the data lake administrator can perform create, update, and delete operations on LF-tags.

  • You can assign multiple LF-tags to Data Catalog resources. Only one value for a particular key can be assigned to a particular resource.

    For example, you can assign module=Orders, region=West, division=Consumer, and so on to a database, table, or column. You can't assign module=Orders,Customers.

  • You can't assign LF-tags to resources when you create the resource. You can only add LF-tags to existing resources.

  • You can grant LF-tag expressions, not just single LF-tags, to a principal.

    A LF-tag expression looks something like the following (in pseudo-code).

    module=sales AND division=(consumer OR commercial)

    A principal that is granted this LF-tag expression can access only Data Catalog resources (databases, tables, and columns) that are assigned module=sales and either division=consumer or division=commercial. If you want the principal to be able to access resources that have module=sales or division=commercial, don't include both in the same grant. Make two grants, one for module=sales and one for division=commercial.

    The simplest LF-tag expression consists of just one LF-tag, such as module=sales.

  • A principal that is granted permissions on a LF-tag with multiple values can access Data Catalog resources with either of those values. For example, if a user is granted a LF-tag with key=module and values=orders,customers, the user has access to resources that are assigned either module=orders or module=customers.

  • At first, only the data lake administrator can assign LF-tags to Data Catalog resources. The data lake administrator can grant the DESCRIBE and ASSOCIATE permissions on LF-tags to principals so that those principals can view and assign LF-tags. The following table describes these permissions.

    Permission Description
    DESCRIBE A principal with this permission on a LF-tag can view the LF-tag and its values when they assign LF-tags to resources or grant permissions on LF-tags. You can grant DESCRIBE on all key values or on specific values.
    ASSOCIATE A principal with this permission on a LF-tag can assign the LF-tag to a Data Catalog resource. Granting ASSOCIATE implicitly grants DESCRIBE.

    These permissions are grantable. A principal who has been granted these permissions with the grant option can grant them to other principals.

  • At first, the data lake administrator is the only principal who can grant permissions on Data Catalog resources (data permissions) by using the LF-TBAC method. If the data lake administrator grants data permissions with LF-TBAC to a principal in their account with the grant option, the grant recipient can then grant data permissions on the resources in one of two ways:

    • Using the named resource method.

    • Using the LF-TBAC method, but only using the same LF-tag expression.

      For example, assume that the data lake administrator makes the following grant (in pseudo-code).

      GRANT (SELECT ON TABLES) ON TAGS module=customers, region=west,south TO user1 WITH GRANT OPTION

      In this case, user1 can grant SELECT on tables to other principals by using the LF-TBAC method, but only with the complete LF-tag expression module=customers, region=west,south.

  • Although data lake administrators have implicit Lake Formation permissions to create, update, and delete LF-tags, to assign LF-tags to resources, and to grant LF-tags to principals, data lake administrators also need the following LF-TBAC-related AWS Identity and Access Management (IAM) permissions.

    "lakeformation:AddLFTagsToResource", "lakeformation:RemoveLFTagsFromResource", "lakeformation:GetResourceLFTags", "lakeformation:ListLFTags", "lakeformation:CreateLFTag", "lakeformation:GetLFTag", "lakeformation:UpdateLFTag", "lakeformation:DeleteLFTag", "lakeformation:SearchTablesByLFTags", "lakeformation:SearchDatabasesByLFTags"

    Principals who assign LF-tags to resources and grant LF-tags to principals must have the same permissions, except for the CreateLFTag, UpdateLFTag, and DeleteLFTag permissions.

    For more information, see Lake Formation Personas and IAM Permissions Reference.

  • If a principal is granted permissions on a resource with both the LF-TBAC method and the named resource method, the permissions that the principal has on the resource is the union of the permissions granted by both methods.

  • Lake Formation supports granting DESCRIBE and ASSOCIATE on LF-tags across accounts, and granting permissions on Data Catalog resources across accounts using the LF-TBAC method. In both cases, the principal is an AWS account ID.


    Currently, LF-TBAC cross-account grants to organizations and organizational units are not supported.

    For more information, see Cross-Account Access in Lake Formation.

Example – Life Cycle of a LF-Tag

  1. The data lake administrator Michael creates a LF-tag module=Customers.

  2. Michael grants ASSOCIATE on the LF-tag to the data engineer Eduardo. Granting ASSOCIATE implicitly grants DESCRIBE.

  3. Michael grants Super on the table Custs to Eduardo with the grant option, so that Eduardo can assign LF-tags to the table. For more information, see Assigning LF-Tags to Data Catalog Resources.

  4. Eduardo assigns the LF-tag module=customers to the table Custs.

  5. Michael makes the following grant to data engineer Sandra (in pseudo-code).

  6. Sandra makes the following grant to data analyst Maria.

    GRANT (SELECT ON TABLES) ON TAGS module=customers TO Maria

    Maria can now run queries on the Custs table.