Last Updated: 2024-01-25

Background

In this tutorial, you will use Starburst Galaxy's built-in, role-based access control (RBAC) to allow and deny privileges to data.

Knowing how roles and privileges function is important, regardless of your role within an organization.

If you're a data consumer, understanding roles and privileges will help you better communicate with the individuals that grant you access. For example, you'll know how to determine whether you need access to additional data sets or require additional privileges related to the data sets to which you already have access.

If you're a platform administrator or data engineer, this tutorial is a quick introduction to using role-based access control in Starburst Galaxy.

Prerequisites

You need a Starburst Galaxy account to complete this tutorial. Please be sure to complete the tutorial titled Starburst Galaxy: Getting started before attempting this tutorial.

Learning outcomes

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

• Switch between your assigned roles.
• Use the Starburst Galaxy Web UI to determine the privileges and permissions granted to your assigned roles.
• Recognize the error messages associated with lacking the privileges to perform specific operations.

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

Burst Bank is modernizing its data storage systems by making better use of its data lake. As part of this process, data consumers will now use Starburst Galaxy to access some of their data directly from a data lake.

In the first two sections of this tutorial, you'll act as a data engineer facilitating this change by creating the marketing role for the data consumers in the marketing department. These data consumers need access to most data related to customers to assess marketing campaigns. However, they cannot access sensitive information such as credit card numbers. Thus, you'll assign the privilege to access all schemas in the Burst Bank data lake. Then, you'll deny them the ability to access credit card numbers in the account table.

In the third section of this tutorial, you'll explore how the privileges granted to the marketing role appear to a data consumer using this role. In particular, you'll compare how Starburst Galaxy responds when you attempt to access data with varying levels of privileges.

Background

In Starburst Galaxy, you can switch between all of the roles assigned to you. Meanwhile, the two default roles are accountadmin and public.

By default, the accountadmin role is the only role able to create and assign roles. You can only use one role, with the privileges assigned to that role, at a time.

If you're a data consumer, you probably won't be assigned to the accountadmin role in your organization's Starburst Galaxy account. However, you do have access to this role in your free personal Starburst Galaxy account.

In this tutorial, you'll use the accountadmin role to create and assign roles.

Step 1: Log in to Starburst Galaxy

• Log in with the account you created when you completed the Starburst Galaxy: Getting started tutorial.

Step 2: Switch your role

In Starburst Galaxy, it's easy to switch between roles that have been assigned to you.

• Your current role, accountadmin, appears below your email address in the top, right-hand corner of the browser.
• Click on your username.
• A drop-down menu will appear.
• Switch to the public role.

Background

In this section, you'll create a role called marketing for data consumers in Burst Bank's marketing department. The members of the marketing team don't need admin privileges. As data consumers, they only need the privileges that allow them to select data from relevant tables.

You're going to make sure that these roles and privileges are set up correctly.

Step 1: Add a new role

You're going to start by adding a new role. To do this, you'll need to switch to accountadmin, so that you are operating under a role with the necessary privileges needed to create a new role for others.

• Switch to the accountadmin role.
• In the Account section of the left-hand navigation menu, expand the Access control menu.
• Click Roles and privileges.
• Click Add role.

Step 2: Enter role details

You're now going to enter the details of the new role. Remember, this is a marketing role, so the privileges will need to match those required by marketing.

• Enter marketing in the Role name field.
• Enter a meaningful Description. This will help you understand the role later, so make it as useful as you can.
• Because this is a new role, separate from accountadmin, do not select Grant to the creating role.
• Click the Add role button.

Step 3: Add privileges to the marketing role

Now that you have created the marketing role, you can add privileges to determine the new role's access controls.

• Click the marketing role link.
• Click the Privileges tab.

Step 4: Add a privilege to the marketing role

You are going to allow the role to SELECT from all tables in all schemas in the lakehouse_burst_bank catalog.

• Click Add privilege.
• Select the lakehouse_burst_bank catalog from the Scope dropdown.
• Set the permission to ALLOW Select from table.
• Click Save privileges.

Now that you've added the privilege to select from tables in the lakehouse_burst_bank catalog, the marketing role view lists four privileges associated with Catalogs.

Step 5: Deny a privilege to the marketing role

Users with the marketing role will query the account table from the lakehouse_burst_bank catalog. This table includes credit card numbers, however, and this role shouldn't have access to that information.

• Click Add privilege.
• In the Scope dropdown, expand the lakehouse_burst_bank catalog, burst_bank schema, and account table. Select the cc_number column from this table.
• Set the permission to DENY Select from column.
• Click Save privileges.

Now that you've denied the marketing role the privilege to select from the cc_number column in the lakehouse_burst_bank.burst_bank.account table, the marketing role view lists five privileges associated with Catalogs.

Step 6: Assign yourself to the marketing role

This will allow you to switch to this role.

• Click Users.
• Click Assign user.
• Select your user name from the drop-down.
• Click Assign user.

Background

In this section of the tutorial, you'll become familiar with some of the indicators the Starburst Galaxy Web UI provides to let you know when you're attempting to perform an action for which you don't have the appropriate privileges. Additionally, you'll explore how the Starburst Galaxy Web UI responds when you attempt to access data you don't have the privileges to access.

Step 1: Attempt to start the a cluster from the marketing role

You're going to run your first test by attempting to start the cluster from the marketing role. Remember that this should fail because that role should not have the privileges necessary to start a cluster.

• Switch to the marketing role.
• Navigate to the Clusters pane.
• Under the Quick actions column, attempt to Resume the aws-us-east-1-free cluster.
• Notice that you're unable to resume the cluster from the Clusters pane. This is because you don't have the appropriate permissions. However, if you run a SQL statement on this cluster and the cluster is suspended rather than disabled, running the query will cause the cluster to resume.

Step 2: Start a cluster from the accountadmin role

Now you're going to contrast the result you saw in the last step by switching to the accountadmin role and resuming the cluster. This role has the correct privileges to start a cluster, so this time it should succeed..

• Switch to the accountadmin role.
• Under the Quick actions column, click Resume to start the aws-us-east-1-free cluster.

Step 3: Run a SQL query while using the accountadmin role

Now you're going to confirm that the cluster is working by running a SQL query on it. Remember, you're still on the accountadmin role, so it should work.

• Navigate to the query editor.
• Select aws-us-east-1-free as your cluster.
• Run the following query:

SELECT *
FROM
 "lakehouse_burst_bank"."burst_bank"."account"
LIMIT 10;

Step 4: View the results from the accountadmin role

The results should look similar to the image below. The cluster is able to start and the query is able to run because accountadmin has the correct level of permissions to execute those actions.

• Notice that you can see the cc_number column in the results.

Step 5: Run a SQL query while using the marketing role

With the cluster running, you're now going to switch back to the marketing role and run the query. Since the marketing role does have the privileges to run a query, it should run, but the cc_number column should no longer be visible because the marketing role does not have the right to view it.

• Switch to the marketing role.
• Run the query you ran in the previous step.

SELECT *
FROM
 "lakehouse_burst_bank"."burst_bank"."account"
LIMIT 10;

Step 6: View results from the marketing role

The results should look similar to the image below, and they are indeed different from the results you saw with the accountadmin role.

Running the query from the marketing role, you can no longer see the cc_number column in the results. Notably, you do not receive an error message, this column is simply missing for this role.

This is a good demonstration of the power of role-based access control.

Step 7: Run a SQL query while using the public role

Finally, you're going to test this process again by running the query using the public role. Again, the results should be different depending on the privileges of that role.

In this case, the public role does not include the right to query this dataset at all, so you should expect to encounter an error.

• Switch to the public role.
• Run the query you ran in the previous step.
• Notice the error message you get as a result of trying to access a table to which your role does not have access. Specifically, it says: Relation not found or not allowed. This tells us that users in the public role will not have access to the dataset at all owing to the restrictions of that role.

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 the basics of role-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!