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:
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.
read(With the exception of secrets, where
writedoes not imply
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
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
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
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