Magpie Permissions

August 22, 2019 19:01

Overview

This article describes how to grant permissions and manage security in Magpie. It is helpful to revisit user roles as well as understand different types of objects in Magpie. Permissions are granted to roles, individual users, or an entire organization. Magpie applies eight permission types to different target objects. As detailed in the table below, each type of permission grants specific access to target objects depending on type of object. Permissions types are:

Admin
Developer
Execute
Create
Write
Read
Use
Lineage

Object Admin

The user who creates a new metadata object is granted admin permissions on that object by default. A user with admin permissions for a given metadata object can perform any action on that object, including granting and revoking access to that object to other users. For metadata objects that encompass other objects, such as a table within a schema, admin permission also gives admin rights to the child objects.

Lineage permissions can only be granted by Organization Admins, as the permission can expose the existence of tables and data sources throughout the organization.

Permission inheritance

read implies use
write implies create, execute, and read (With the exception of secrets, where write does not imply read)
admin implies developer and write

Magpie Permissions

The following tables details what each permission means in the context of the target object. Blank cells indicate that the corresponding permission is not applicable to a given type of metadata object.

Organizations and Repositories

	Organization	Repository	Data Source	Secret
Admin	Grant or revoke any permission on any object	Grant or revoke permission on the repository Admin on all schemas, projects, and sources in the repository	Grant or revoke permission on the data source	Grant or revoke permission on the secret
Developer	Create Scala, Python, and R tasks Execute Scala, Python, and R notebook paragraphs
Write		Drop the repository Alter the repository Set repository defaults Write on all schemas, projects, and data sources within the repository	Drop the data source Alter the data source	Alter the secret
Execute		Execute on all projects and data sources within the repository	Run SQL on DB data source Delete files from file system data source Copy files to the file system source
Create		Create schemas, projects, and data sources within the repository	Save new tables in the data source
Read		Read on all schemas, projects, data sources within the repository	Describe the data source List objects in the data source Copy files from the data source Create new tables and streams from existing data in the source	Describe the secret Substitute the Secret in a command
Use	Create Secrets	Use the repository Describe the repository List schemas, projects, data sources sources, tables, and jobs within the repository	For Magpie tables that reference the data source, retrieve data
Lineage	View lineage of all objects within the organization	View lineage of the repository View lineage of all objects within the repository	View lineage of the data source
AccessToken	Allows users to create and manage personal access tokens Allows users to login to Magpie via the CLI or JDBC server by using an access token instead of a username or password.

Clusters

	Cluster
Admin	Grant or revoke permission on the cluster
Developer
Write	Drop the cluster Alter the cluster
Execute	Start and stop the cluster Kill jobs via the Spark UI
Create
Read	View cluster history View the Spark UI for the cluster
Use	Use the cluster Describe the cluster
Lineage	View lineage of the cluster

Schemas

	Schema	Table
Admin	Grant or revoke permission on the schema Admin on all tables within the schema	Grant or revoke permission on the table
Developer
Write	Drop the schema Alter the schema Write on all tables within the schema	Drop the table Alter the table Overwrite the table, append to the table
Execute
Create	Create tables in the schema
Read	Read all tables within the schema	Describe the table Select, show, profile, discover relationships on the table
Use	Use the schema Describe the schema List tables within the schema
Lineage	View lineage of the schema View lineage of all tables and streams within the schema	View lineage of the table Includes table lineage graph, allowing user to view upstream objects

Projects

	Project	Job
Admin	Grant or revoke permission on the project Admin on all jobs within the project	Grant or revoke permission on the job
Developer
Write	Drop the project Alter the project Write on all jobs within the project	Drop the job Alter the job Create a schedule for the job Drop a schedule for the job Subscribe or unsubscribe to notifications for a job schedule
Execute	Execute on all jobs within the project	Execute the job
Create	Create jobs in the project
Read	Read all jobs within the project	Describe the job Get job history
Use	Use the project Describe the project List jobs
Lineage	View lineage of the project View lineage of all jobs within the project	View lineage of the job

Example

The following is an example of granting permissions to a role that has already been created. Roles are discussed in greater detail here.

The role is called pipeline_dev. The role will be used to create and test ETL jobs in a staging repository. The ETL jobs create new tables in a schema used for sales data.

First, grant the role create permissions on the staging repository. This provides users with this role basic access to the repository such as listing schemas and data sources.

grant use on repository staging to role pipeline_dev

In this example, let's say that the data source sales_app_source is used upstream in the ETL process. Grant the role read permission on the data source. Read permission allows users with this role to list objects in the source and create new tables from the source.

grant read on data source sales_app_source to role pipeline_dev

Next, grant write access on the ETL project. Write access will allow users with this role to modify all jobs in the project, create new jobs, execute all jobs within the project, and query execution history in the project.

grant write on project sales_etl to role pipeline_dev

Finally, grant create and read on the schema so users with this role can run jobs that create tables in the schema as well as query tables in the schema.

grant create on schema sales to role pipeline_dev;
grant read on schema sales to role pipeline_dev;

To verify that the permissions are as you expect, you can describe the role. Role descriptions include all details of permissions assigned to that role.

describe role pipeline_dev

See more on Granting Permissions.

See more on Granting Roles.