Access control
On Marmot Cloud you grant a role to a person, team or service account on one resource, so an agent's service account can be granted the 3 assets it should see and reach nothing else.
How it works
A grant reaches the resource it's made on and everything under it. A source is a pipeline that answers data queries, and its tables sit under it:
- Grants inherit downwards. A grant on the whole catalog covers everything. A grant on a data product covers its assets, including ones that match its rules later. A grant on a glossary term covers the terms under it, and a grant on a source covers every table it serves.
- Grants add up. There are no deny rules, so keep catalog-wide grants narrow and lower the base role to keep something from most people.
- Grants can end. A grant with an end date stops working then. Marmot warns the holder and the people who manage access on the resource 7 days before, and removes the ended grant 30 days later.
Roles assigned under Settings → Members or on a service account, including the base role a new user gets, are catalog-wide grants.
Members
A member is user:<id>, group:<team-id>, serviceAccount:<id> or allAuthenticated (everyone who can sign in). Grant to teams rather than people, and let single sign-on keep teams in step with your directory.
Roles
Write permissions are checked across the whole catalog, so editing and administration roles only take effect there. These roles can also be granted lower down:
| Role | Gives | Grant on |
|---|---|---|
catalog.viewer | Read assets, data products and the glossary. | Data product, asset, glossary term |
catalog.accessAdmin | catalog.viewer, plus deciding who else has access. | Data product, asset, glossary term |
iam.viewer, iam.admin | Read, or change, who has access. | Data product, asset, glossary term |
asset.viewer | Assets and their lineage neighbours, without data. | Data product, asset |
asset.dataQuerier | asset.viewer, plus read-only queries. | Data product, asset, source |
dataProduct.viewer | A data product and its assets. | Data product |
glossary.viewer | Glossary terms. | Glossary term |
secretStore.viewer | A store and its secrets, without values. | Secret store |
secretStore.user | secretStore.viewer, plus attaching secrets to pipelines. | Secret store |
secretStore.reader | secretStore.viewer, plus reading values. | Secret store |
Every role can be granted across the whole catalog, including admin, editor (create and edit catalog content and pipelines), user (read the catalog, the base role for new users), access.viewer (the query log and query insights), access.admin (also choosing which sources answer queries) and catalog.none (nothing). Control who can query data covers the query roles.
Grant asset.viewer widely and asset.dataQuerier narrowly. Pipeline authors need secretStore.user, and almost nobody needs secretStore.reader or secretStore.admin, which can both read values.
Settings → Roles lists every role and the permissions it carries:
Who has access
The Access tab on a data product or asset lists what's granted on it and what reaches it from a wider scope:
To explain one member's access, use Check access.
Limitations
- You can't let a team edit only one data product's assets.
- Only someone who manages access across the whole catalog can grant on a secret store or a source.
- The Terraform provider can't grant on a source.
Next steps
- Grant and check access: give a team or an agent a role on a resource.
- Set up service accounts: identities for agents, scripts and CI.
- Set up single sign-on: keep teams in step with your directory.