Last Updated: 2024-01-25
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.
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.
Upon successful completion of this tutorial, you will be able to:
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.
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.
In Starburst Galaxy, you can switch between all of the roles assigned to you. 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.
In Starburst Galaxy, it's easy to switch between roles that have been assigned to you.
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.
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.
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.
Now that you have created the marketing role, you can add privileges to determine the new role's access controls.
You are going to allow the role to SELECT
from all tables in all schemas in the lakehouse_burst_bank
catalog.
lakehouse_burst_bank
catalog from the Scope dropdown.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.
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.
lakehouse_burst_bank
catalog, burst_bank_with_stats
schema, and account
table. Select the cc_number
column from this table. Now that you've denied the marketing role the privilege to select from the cc_number
column in the lakehouse_burst_bank.burst_bank_with_stats.account
table, the marketing role view lists five privileges associated with Catalogs.
This will allow you to switch to this role.
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.
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.
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.
aws-us-east-1-free
cluster. Now you're going to confirm that the cluster is working by running a SQL query on it. Remember, you're still in the accountadmin role, so it should work.
aws-us-east-1-free
as your cluster.SELECT *
FROM
"lakehouse_burst_bank"."burst_bank_with_stats"."account"
LIMIT 10;
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.
cc_number
column in the results.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.
SELECT *
FROM
"lakehouse_burst_bank"."burst_bank_with_stats"."account"
LIMIT 10;
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.
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.
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.
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.
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.
Visit the Tutorials section to view the full list of tutorials and keep moving forward on your journey!