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:

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.

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.

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.

Step 5: View the new tags

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

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.

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.

Step 3: Select the pii.phone tag

Step 4: Select the pii.ssn tag

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

Step 5: Select the pii tag

Now it's time to assign a 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.

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.

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.

Step 3: Define policy details

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

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.

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.

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.

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.

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.

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.

Step 10: View Catalogs section

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

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.

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.

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

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.

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.

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.

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!


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.

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.

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!

Start Free with
Starburst Galaxy

Up to $500 in usage credits included

  • Query your data lake fast with Starburst's best-in-class MPP SQL query engine
  • Get up and running in less than 5 minutes
  • Easily deploy clusters in AWS, Azure and Google Cloud
For more deployment options:
Download Starburst Enterprise

Please fill in all required fields and ensure you are using a valid email address.