Magpie Permissions

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 or individual users. 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

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.


Was this article helpful?
0 out of 0 found this helpful