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, 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
readimpliesusewriteimpliescreate,execute, andread(With the exception of secrets, wherewritedoes not implyread)adminimpliesdeveloperandwrite
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 and Python tasks in all repositories Execute Scala and Python notebook paragraphs in all repositories | Create Scala and Python tasks in a given repository Execute Scala and Python notebook paragraphs in a given repository | ||
| 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 User Roles.
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