Last Updated: 2023-12-20

Background

Starburst Galaxy's built-in attribute-based access control (ABAC) feature allows business domain owners, platform administrators, and data engineers to apply fine-grained access controls to various data entities. This is done by creating policies around the tags applied to those data entities. These controls are combined with roles and privileges, allowing organizations to enact precise, reusable policies around specific data entities.

The following diagram illustrates this architecture.

Prerequisites

You need a Starburst Galaxy account to complete this tutorial. Please see Starburst Galaxy: Getting started for instructions on setting up a free account.

Learning outcomes

Upon successful completion of this tutorial, you will be able to:

Create and apply tags to data entities in Starburst Galaxy.
Use tag-based policies to grant (allow/deny) data access privileges to roles.
Recognize the error messages that occur when you attempt to perform specific operations without the sufficient privileges.

About Starburst tutorials

Starburst tutorials are designed to get you up and running quickly by providing bite-sized, hands-on educational resources. Each tutorial explores a single feature or topic through a series of guided, step-by-step instructions.

As you navigate through the tutorial you should follow along using your own Starburst Galaxy account. This will help consolidate the learning process by mixing theory and practice.

Tutorial scenario

The Information Security (InfoSec) team at Chryse Corp. requires all departments to hide pii data(personally identifiable information) from unauthorized users.

Fortunately for the InfoSec team, Chryse Corp. uses Starburst Galaxy, so this is easy to implement. All they need to do is create a role and policy that denies access to data entities with a pii tag. Once the role is in place, it can be inherited by other roles across the organization via Starburst Galaxy's role-based access control (RBAC) features, denying pii access to unauthorized individuals.

In this tutorial, you'll help Chryse Corp. by tagging data entities with a pii tag, and then creating a role with a policy that denies pii access to unauthorized users. You will also use role inheritance to deny pii access.

Tagging

Attribute-based access control works by tagging data to create a group, then applying a policy to specific tags. These controls are especially useful for domain experts and line-of-business owners who work closely with the data associated with their domain.

Policies

Policies work by matching expressions to tags, and allowing or denying privileges based on matches. Starburst Galaxy allows two hierarchical levels of tags. A policy is applied to the top level tag, x, with the matching expression has.tag(x). A policy is applied to a specific nested tag, y, with the expression has.tag(x.y) or to all nested tags with the expression has.tag(x.*). To learn more about policies, see our technical documentation page.

The following video walks through all of the steps in this tutorial. Please feel free to watch and follow along with the steps in your own account, or skip to the written instructions if you prefer.

Background

Tags are the foundation of attribute-based access control. In this section, you will create three tags to identify personally identifiable information (pii). Your team has asked you to create tags for customer phone numbers and social security numbers.

Step 1: Sign into Starburst Galaxy

Sign into Starburst Galaxy in the usual way. If you have not already set up an account, you can do that here.

Step 2: Verify that your role is set to accountadmin

Only the data entity owner can add metadata to data entities. In this tutorial, you'll add tags from the accountadmin role.

Your current role appears below your email address in the top, right-hand corner of the browser.
If your role is not set to accountadmin, click your username and choose accountadmin from the list under Your roles & privileges.

Step 3: Create a tag for personally identifiable information (pii)

Now it's time to create a tag for pii data. The tags for phone number and ssn will be nested under the main pii tag. These are special types of pii data, so the tagging process will reflect this hierarchical relationship.

In the left-hand navigation menu, expand the Access menu.
Click Tags.
Click Create tag.
Enter pii in the Name field.
Enter a meaningful Description. For example, "Personally identifiable information".
Select a color for the tag from the list of available colors. This will help differentiate it from other tags.
Click Create tag.

Step 4: Create two nested tags for phone and SSN data

Now you can create the two nested tags. These will tag phone numbers and Social Security Number (SSN) data.

Click Create tag.
Enter phone in the Name field.
Select Nested tag under.
Select pii from the Select nesting drop-down menu.
Enter a meaningful Description.
Select a color for the tag from the list of available colors. This will help differentiate it from other tags. Note: This should match the same color chosen in the previous step.
Click Create tag.
Repeat this process for the ssn tag.

Step 5: View the new tags

It's best to check that the new tags have been created successfully.

Expand the pii tag. You should see the two tags nested under it, similar to the image pictured below.

Background

You are going to assign the tags that you just created to tables, so that you can later create policies based on those tags.

In this scenario, the table that you have been asked to tag is the customer table, which contains several types of sensitive customer information. You're going to tag each of those types based on their attributes and then restrict access to them based on policies and roles.

Step 1: Select `customer` table

In this example, you will add tags to the lakehouse_burst_bank.burst_bank.customer table.

In the left-hand navigation menu, select Data>>Catalogs.
Expand the lakehouse_burst_bank catalog.
Expand burst_bank schema.
Select the customer table.

Step 2: Access tagging for the `phone` column

Now it's time to assign your tags, starting with the phone tag. You will assign this tag to the phone column.

Locate the column named phone.
Click the + icon next to No tags assigned.

Step 3: Select the pii.phone tag

Select the box in front of pii.phone.
Click once outside the drop-down to close it.
Click Save changes.

Step 4: Select the pii.ssn tag

Now it's time to assign the ssn tag to a column.

Repeat the steps above to assign the pii.ssn tag to the ssn column.

Step 5: Select the pii tag

Now it's time to assign a pii tag to the last_name column.

Repeat the steps above, but this time, assign the pii tag to the last_name column.

Step 6: Confirm changes

Again, it's best to confirm that all of these changes have been added successfully.

Return to the customer table.
Confirm all tags are assigned to the table.

Background

Now, you'll bring it all together by creating a role that uses the tags to deny access to pii data. You will also create a second role that inherits the first role to see how the privileges are inherited.

Step 1: Add a role that denies access to pii data

You're creating the role in this step, and in the next step you'll add the policy to deny access.

Expand the Access menu.
Click Roles and privileges.
Click Add role.
Enter deny_pii in the Role name field.
Enter a meaningful Description.
Click Add role.

Step 2: Add a new policy to the deny_pii role

Now it's time to add a new policy to the tag so that it can be implemented.

Select the deny_pii role.
Select the Policies tab.
Click the Add policy button.

Step 3: Define policy details

New policies require a definition. Complete the required fields to create the new policy.

In the Policy name field, enter deny_pii.
Type a meaningful Description.
Click the Next button.

Step 4: Define policy scope

Each policy in Starburst Galaxy has a defined scope. When you create a new policy, you must outline this scope as part of the creation process.

Using the Catalogs drop-down menu, select lakehouse_burst_bank .
Using the Schemas drop-down, select All schemas.
Select Match using expression.
In the box under Matching using expression, type the following: has_tag(pii.*).
Click the Next button.

Step 5: Add new privilege to control the denial of access

In this step, you are going to add a new privilege that denies access when selected.

Click the + Add privilege button.
In the Grant menu, select DENY.
In the Privileges menu, choose Select.
Click Create policy.

Step 6: Add a marketing role

Now it's time to add a new role. In this scenario, you're creating a role for the marketing department.

After the role is created, you will then add the deny_pii role to the marketing role to see how the privileges combine.

Expand Access.
Click Roles and privileges.
Click Add role.
In the box under Role name, type marketing.
Type a meaningful Description.
Click Add role.

Step 7: Assign the deny_pii role to the marketing role

You don't want marketing to have access to pii, so you're going to add the deny_pii role to the new marketing role.

Click the link for the marketing role.
Click Roles.
Click Assign role.
In the Role to assign menu, select deny_pii.

Click Assign role.

Step 8: Add new privilege to the marketing role

Now it's time to add privileges that allow the marketing role to select all schemas inside the lakehouse_burst_bank catalog.

Remember that some columns will be hidden for this role. This is because the marketing role has inherited privileges from the deny_pii role.

In the marketing role section, select the Privileges tab.
Click the add Add privilege button.

Step 9: Add privilege details

Now it's time to outline the details of the new privilege being created for the marketing role. This will outline exactly what the new privilege is allowed to do and what it is restricted from doing.

In the Scope drop-down menu, select lakehouse_burst_bank catalog. This will automatically ensure that this privilege applies to all schemas within the catalog.
Ensure that Allow is selected.
Choose Select from table under the What can they do? section.
Click the Save privileges button.

Step 10: View Catalogs section

Now it's time to check whether the new privilege is working properly.

Expand the Catalogs section at the bottom of the screen.
Expand the lakehouse_burst_bank catalog.
Expand the burst_bank schema.
Expand the customer table.

Notice that for both phone and ssn the Select from table column is denied. If you hover over either of them, you see that this restriction is inherited from the deny_pii policy.

Step 11: Assign yourself to the marketing role

Next, you're going to assign yourself to the role so that you can test it out later.

In the marketing role section, select the Users tab.
Click the Assign user button.
In the drop-down, select your Starburst Galaxy user name.
Click the Assign user button.

Background

Your team wants to make sure that the marketing role does not have access to sensitive customer information. This will be an opportunity to test the policies that you just created to confirm that they work. You'll want to make sure that the new privileges allow the correct types of data while restricting the types you intended.

Let's get going!

Step 1: Test accountadmin role access

First, you'll start by level-setting in the accountadmin role. Because accountadmin has broad privileges, you would expect to see all columns and all tables.

You're going to check that this is the case before proceeding.

In the left-hand navigation menu, expand the Query menu then click Query editor.
Ensure that the aws-us-east-1-free cluster is running, and that the lakehouse_burst_bank catalog and the burst_bank schema have been selected.
Paste the following SQL query into the editor.

It is composed of two SQL statements. One selecting all data from the customer table, and another selecting the last_name, phone, and ssn columns from the customer table. Each of these tests the attribute-based access in different ways.

SELECT * FROM customer;
SELECT last_name,phone,ssn FROM customer;

Click the Run selected (limit 1000) button.

Step 2: Confirm accountadmin results

Because accountadmin has total access to the columns in your query, you should see all three columns in your query results.

Confirm that the last_name column shows results.
Confirm that the phone column shows results.
Confirm that the ssn column shows results.

Step 3: Switch role to marketing

Now it's time to test the new marketing role to see whether the correct access has been granted and restricted in the appropriate way.

To do this, you're first going to have to switch roles to marketing so you can test its access as someone using that role.

In the upper right-hand corner of Starburst Galaxy, open the drop-down by your name to see the Your roles & privileges menu.
Select the marketing role.

Step 3: Test marketing role restrictions using projection

Now you're in the marketing role. It's time to test out the privileges unique to that role. To do this, you're going to start with the 2nd part of your SQL statement.

Recall that the marketing role should have its access denied to the phone and ssn columns in the customer table. You're going to re-run your query, but this time expect a different result. Specifically, you're going to expect the phone and ssn columns cannot be returned, resulting in an error.

Highlight your SQL query again
Click the Run selected (limit 1000) button.
The results of the second SQL statement should show an Access Denied error.
This is exactly what you expected because you've projected columns in your SELECT statement that you are not allowed to access.

Step 4: Test marketing role restrictions in SELECT all statement

Now it's time to turn to the first query, the one that returned all results. Last time, with accountadmin enabled, you saw results from every column.

This time, you're in the marketing role, so you'd expect the restricted columns to be blocked. Specifically, you'd expect these columns to be absent from the resultset, but all other columns to still be present.

Time to test your hypothesis!

Select the first query.
Confirm that you no longer see the phone and ssn columns in the results of the first SQL statement. This is because the Marketing role does not have permission to view these columns.
Confirm that results for the last_name column are still visible. This is a bit unexpected. Although it makes sense, it might not be what you were imagining for the marketing role.
The result comes about because the matching expression only considers matching on has_tag(pii.*), which excludes parent tags.
This means that it restricts pii.phone and pii.snn but not pii generally.

Step 5: Identify a problem with the matching expression

Problem

The ABAC policies you set up for the marketing role worked to deny access to customer phone numbers and social security numbers as expected.

However, your team wanted the marketing role to be denied access to the customers' last names as well. Although it makes sense why this isn't the case, it's not quite what the company wanted.

Challenge

Try to fix the matching expression in the deny_pii policy so that the last_name column is hidden from the marketing role.

If you get stuck, view the last step below.

Step 6: Fix the matching expression (Solution)

Let's edit the matching expression set for the deny_pii policy to add some additional logic. This will help resolve the problem you identified.

Switch back to the accountadmin role.
Click Roles and Privileges.
Click deny_pii.
Click Policies.
Click deny_pii.

Step 7: Define new policy scopes

Now it's time to make the changes to the logic governing the scope of the policy. This will make it so that the marketing role restricts access to the last_name column.

Click the Next button to get to the Define policy scopes page.
In the Match using expression field, type the following: has_tag(pii.*) OR has_tag(pii).
This will change the logic governing the matching process to include both the child pii.* expressions and the parent pii expression.
This better matches the restrictions you originally intended to implement.
Click the Next button again, then click the Update policy button to save the policy.
Test the previous queries again to confirm that the policy is working properly.

Tutorial complete

Congratulations! You have reached the end of this tutorial, and the end of this stage of your journey.

Now that you've completed this tutorial, you should have a better understanding of just how easy and convenient it is to use attribute-based access control in Starburst Galaxy.

Continuous learning

At Starburst, we believe in continuous learning. This tutorial provides the foundation for further training available on this platform, and you can return to it as many times as you like. Future tutorials will make use of the concepts used here.

Next steps

Starburst has lots of other tutorials to help you get up and running quickly. Each one breaks down an individual problem and guides you to a solution using a step-by-step approach to learning.

Tutorials available

Visit the Tutorials section to view the full list of tutorials and keep moving forward on your journey!

Background

Prerequisites

Learning outcomes

About Starburst tutorials

Tutorial scenario

Tagging

Policies

Background

Step 1: Sign into Starburst Galaxy

Step 2: Verify that your role is set to accountadmin

Step 3: Create a tag for personally identifiable information (pii)

Step 4: Create two nested tags for phone and SSN data

Step 5: View the new tags

Background

Step 1: Select customer table

Step 2: Access tagging for the phone column

Step 3: Select the pii.phone tag

Step 4: Select the pii.ssn tag

Step 5: Select the pii tag

Step 6: Confirm changes

Background

Step 1: Add a role that denies access to pii data

Step 2: Add a new policy to the deny_pii role

Step 3: Define policy details

Step 4: Define policy scope

Step 5: Add new privilege to control the denial of access

Step 6: Add a marketing role

Step 7: Assign the deny_pii role to the marketing role

Step 8: Add new privilege to the marketing role

Step 9: Add privilege details

Step 10: View Catalogs section

Step 11: Assign yourself to the marketing role

Background

Step 1: Test accountadmin role access

Step 2: Confirm accountadmin results

Step 3: Switch role to marketing

Step 3: Test marketing role restrictions using projection

Step 4: Test marketing role restrictions in SELECT all statement

Step 5: Identify a problem with the matching expression

Problem

Challenge

Step 6: Fix the matching expression (Solution)

Step 7: Define new policy scopes

Tutorial complete

Continuous learning

Next steps

Tutorials available

Step 1: Select `customer` table

Step 2: Access tagging for the `phone` column