> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/access-model.md).
# Roles & Permissions
DataOS access control is based on **roles** and **permissions**.
A **role** defines a user’s responsibility at the Instance or Tenant level. A **permission** defines what a user can do with a specific Resource, such as Compute, Secret, Depot, or Cluster.
Holding a role does not automatically grant access to shared Resources or Resources created by other users. That access must be granted separately.
For how access is evaluated across the Instance, Tenant, and Resource levels, see [Access control](/operate/v1/access-control.md).
## Roles
Roles apply at the Instance and Tenant levels.
* Instance is the complete DataOS environment for an organization. It can contain one or more Tenants.
* Tenant is an isolated workspace inside an Instance, usually used by a team, domain, or business unit.
A user can hold more than one role at the same time.
### Instance roles
The Instance role controls organization-level access to DataOS. User identity at this level is managed through the customer’s Identity Provider, such as Okta, Microsoft Entra ID, Google Workspace, or another enterprise IdP.
#### User
The User role allows a user to sign in to DataOS.
This role alone does not grant access inside a Tenant. The user must also be added to a Tenant and assigned the appropriate Tenant role.
#### Operator
An Operator manages the overall DataOS setup through the Instance Admin application.
An Operator can:
* Provision and configure DataOS.
* Create and manage Tenants.
* Provision the Data Plane and Compute.
* Invite users.
* Assign Tenant Admins.
* Delete Tenants.
Instance roles are assigned when the Instance is created and cannot be modified afterward
{% hint style="info" %}
Instance roles are assigned when the Instance is created and cannot be modified afterward
{% endhint %}
### Tenant roles
Tenant roles are managed inside DataOS. These roles are created with the Tenant and include the Tenant name, such as `analytics Tenant Admin`, where `analytics` is the Tenant name.
Roles inside Tenant:
* [Tenant Admin](#tenant-admin)
* [Data Admin](#tenant-data-admin)
* [Data Developer](#tenant-data-developer)
* [Data Consumer](#tenant-data-consumer)
By default, none of the Tenant roles holds Compute, Secret, Depot, or Cluster use access. Each requires an explicit `Can Use` permission before it can be referenced in a Data Product workload.
#### Tenant Admin
A Tenant Admin uses the Tenant Admin application in the DataOS UI to manage users and assign Tenant-level roles.
**What a Tenant Admin can do:**
* Invite users to the Tenant and assign Tenant-level roles
* Create Resources such as Compute, Secret, Depot, Cluster, Lakehouse, Nilus, Vulcan, and others
* Update and delete Resources they created
* Grant or revoke access on Resources they created
* Manage access on any Resource in the Tenant, including Resources created by other users
* Grant `Can Edit` on a Resource to themselves or another user when that Resource needs to be updated or deleted
* Grant permissions such as `Can Use Compute`, `Can Use Secret`, `Can Use Depot`, or `Can Use Cluster` to users in the Tenant
**Access that must be granted separately:**
* `Can Edit` on Resources created by other users
* `Can Use [Resource]` to use a Compute, Secret, Depot, Cluster
Elevating access to Resources
A Tenant Admin can manage access on every Resource in the Tenant by default. However, they still need an explicit permission to use a Resource or to edit a Resource created by another user.
Access is granted from the **Resource Catalog**.
To grant the required permission:
1. Open the **Resource Catalog**.
2. Search for the Resource by name.
3. Open the Resource.
4. Go to the **Access** tab.
5. Grant the required permission to themselves or another user.
For example, if a Tenant Admin creates a Compute, they already have `Can Edit` and `Can Manage Access` on that Compute because they created it. However, they do not get `Can Use Compute` by default.
To use that Compute, the Tenant Admin opens the Compute in the Resource Catalog, goes to the **Access** tab, and grants themselves `Can Use Compute`.
For Resources created by other users, the Tenant Admin already has `Can Manage Access` by default. If they need to update or delete one of those Resources, they first grant themselves `Can Edit` on that Resource.
For example:
* If a Resource needs to be updated or deleted and the original creator is unavailable, the Tenant Admin can grant themselves `Can Edit` on that Resource before making the change.
* If access governance for a Depot needs to be handed over to another user, the Tenant Admin can grant `Can Manage Access` on that Depot to the intended user.
* If the Tenant Admin needs to use a Compute or Depot, they can grant themselves `Can Use Compute` or `Can Use Depot`.
Each grant is logged and auditable. This keeps even the most privileged role inside the Tenant visible and accountable.
#### Data Admin
A Data Admin governs data within the Tenant, with Lakehouse administration as a core responsibility. They create and manage namespaces, schemas, tables, and views, and control access to governed data assets.
**What a Data Admin can do:**
* Create Resources such as Compute, Secret, Depot, Vulcan, Nilus, Lakehouse, and others
* Update and delete Resources they created
* Grant or revoke access on Resources they created
* Manage access on Resources created by other users
* Create, configure, and govern Lakehouse namespaces, schemas, tables, and views through the Lakehouse interface
* Access Tenant-level applications
**Access permission that must be granted separately:**
* `Can Edit` on Resources created by other users
* Can Use \[Resource] permission to use a Compute, Depot, Secret, or Cluster, regardless of who created it
Elevating access to Resources
A Data Admin can manage access on Resources by default. However, they still need an explicit permission to use a Resource or to edit a Resource created by another user.
Access is granted from the **Resource Catalog**.
To grant the required permission:
1. Open the **Resource Catalog**.
2. Search for the Resource by name.
3. Open the Resource.
4. Go to the **Access** tab.
5. Grant the required permission to themselves or another user.
For example, if a Data Admin creates a Depot, they already have `Can Edit` and `Can Manage Access` on that Depot because they created it. However, if the Depot uses a linked Secret, they also need `Can Use Secret` on that Secret.
To complete the required access, the Data Admin opens the linked Secret in the Resource Catalog, goes to the **Access** tab, and grants themselves `Can Use Secret`.
For Resources created by other users, the Data Admin can manage access. If they need to update or delete one of those Resources, they first grant themselves `Can Edit` on that Resource.
For example:
* If a Resource needs to be updated or deleted and the original creator is unavailable, the Data Admin can grant themselves `Can Edit` on that Resource before making the change.
* If access governance for a Depot needs to be handed over to another user, the Data Admin can grant `Can Manage Access` on that Depot to the intended user.
* If the Data Admin needs to use a Depot and its linked Secret, they can grant themselves `Can Use Depot` and `Can Use Secret`.
Each grant is logged and auditable. This keeps Data Admin access visible, controlled, and accountable.
#### Data Developer
A **Data Developer** builds Data Product workloads such as Data Products and Nilus pipelines.
A Data Developer can update, delete, and manage access on the Resources they created. For Resources created by other users, they must request the required permission from a Tenant Admin or Data Admin.
**What a Data Developer can do:**
* Create Resources such as Workflow, Service, Worker, Secret, Depot, and others
* Update and delete Resources they created
* Grant or revoke access on Resources they created
* Access Tenant-level applications
**Access that must be granted separately:**
* `Can Edit` on Resources created by other users
* `Can Manage Access`on Resource created by other users if required
* `Can Use Compute` to use a Compute
* `Can Use Secret` to use a Secret created by another user
* `Can Use Depot` to use a Depot
* `Can Use Cluster` to use a Minerva Cluster
Requesting access to Resources
A Data Developer cannot grant themselves access to shared Resources unless they already have permission to manage access on that Resource.
When they need access, they request the required permission from a Tenant Admin or Data Admin. For example:
* If a Data Product workload needs to run on a shared Compute, the developer requests `Can Use Compute`.
* If a pipeline needs to read from or write to a Depot, the developer requests `Can Use Depot`.
* If the Depot depends on a Secret created by another user, the developer also requests `Can Use Secret` on that Secret.
* If a Data Product workload needs to use a Minerva Cluster, the developer requests `Can Use Cluster`.
After the permission is granted, the developer can use the Resource for the intended Data Product workload.
Each grant is logged and auditable. This keeps shared Resource access controlled and accountable.
#### Data Consumer
A Data Consumer uses Data Products, dashboards, applications, and governed data made available to them. The role does not include creating Resources, running workloads, or directly using shared Resources unless the required access is granted separately.res an explicit permission, granted separately.
**What a Data Consumer can do:**
* View and interact with permitted Data Products, dashboards, and governed data assets
* Access UI applications for data exploration and consumption
**Access that must be granted separately:**
Access to individual Data Products, dashboards, applications, or governed data assets The matching Can Use \[Resource] permission when direct Resource access is required, such as Can Use Cluster for querying through a Minerva Cluster
**Not included in this role:**
* Creating Resources
* Building or running Data Product workloads
* Updating or deleting Resources
* Managing access on Resources
Requesting access to query data
A Data Consumer cannot grant themselves access to shared Resources.
When they need additional access, they must request the required permission from a Tenant Admin or Data Admin.
For example, if a Data Consumer needs to query data from Workbench, they must request `Can Use Cluster` on the required Cluster.
After the permission is granted, they can use the Cluster for the permitted query activity.
Each grant is logged and auditable. This keeps data consumption controlled and accountable.
## Permissions
Permissions control access at the resource level: an individual Compute, Secret, Depot, or Cluster. A permission gives one user a grant on a specific resource. The common permissions:
| Permission | Lets the grantee |
| ------------------- | ------------------------------------------------- |
| `Can Use Compute` | Run Data Product workloads on a Compute |
| `Can Use Secret` | Use a Secret to authenticate to external systems |
| `Can Use Depot` | Reference a Depot in a Data Product workload |
| `Can Use Cluster` | Query data sources through a Cluster |
| `Can Edit` | Update or delete the resource |
| `Can Manage Access` | Grant and revoke access on the resource to others |
### Permissions received when creating a Resource
When a user creates a Resource, they automatically receive:
* Can Edit
* Can Manage Access
These permissions allow the user to update or delete the Resource and manage who can access it.
They do not include permission to use the Resource. Where usage access applies, the corresponding Can Use permission must be granted separately.
For example, a user who creates a Compute receives Can Edit and Can Manage Access, but still needs Can Use Compute before running workloads on it.
#### Granting Can Use permissions
To use a shared Resource, a user must receive the matching Can Use permission from a Tenant Admin, Data Admin, or another user with Can Manage Access on that Resource. They can also revoke the permission when it is no longer required.
Can Manage Access does not include permission to use the Resource. A user who also needs to use it must receive the appropriate Can Use permission separately.
#### Resource permission dependencies
Each Resource dependency requires its own `Can Use` permission. Access to one Resource does not extend to the Resources connected to it.
For example:
* A workload using a Depot linked to a Secret needs both `Can Use Depot` and `Can Use Secret`.
* A workload querying through a Cluster needs `Can Use Cluster` and any required permissions for the Depots it uses.
Because Depots and Secrets may contain production connection details and credentials, they should be created and managed by a Tenant Admin or Data Admin. Other users should receive only the permissions required for their workloads.
### Authentication and Authorization
DataOS authenticates users through the enterprise IdP. After sign-in, the same identity is used to evaluate access across Instance roles, Tenant roles, Resource permissions, and governed data policies.
See [Authentication and authorization](/operate/v1/authentication-and-authorization.md).
## Example: building a Data Product
A Data Developer needs to build a Data Product that reads from Snowflake, runs on a shared Compute, and uses a Cluster for querying.
1. The user is added to the organization's identity provider and can sign in to DataOS.
2. The user is added to the Tenant by the Operator, or by the Tenant Admin where onboarding is delegated.
3. The Tenant Admin assigns the user the **Data Developer** role, so they can work in the Tenant and create the Data Product.
4. The Data Developer builds the Data Product on Vulcan and defines its inputs, outputs, contracts, and ports. (A pipeline that moves data into it would run on Nilus.)
5. Because the product depends on resources the developer does not yet hold, the Tenant Admin grants the matching `Can Use` on each one:
* `Can Use Compute` on the shared Compute where the product runs
* `Can Use Depot` on the Snowflake Depot it reads from
* `Can Use Secret` on the Secret linked to that Depot
* `Can Use Cluster` on the Cluster used for querying
6. With those grants in place, the Data Developer can build, run, and publish the product using the approved resources.
Each grant covers one resource and one action. Access to the Snowflake Depot does not extend to its linked Secret, the shared Compute, or the Cluster. Each dependency is granted separately.
## Where each role uses this
* [Operator Manage access](/operate/v1/dataos-operator/governance.md): Keeps Tenant role design consistent and audits high-privilege access.
* [Tenant Admin Manage access](/operate/v1/tenant-admin/governance.md): Grants `Can Use` access on Compute and data sources, and configures `ApplicationUser` and `runAsUser` setup.
* [Data Admin Access control](/operate/v1/data-admin/access-control.md): Governs Lakehouse access, including namespaces, schemas, tables, and views.
* [Developer Manage Data Product access](/operate/v1/data-developer/governance.md): Defines access policies for the Data Products they own.
* [Consumer Governance enforced on you](/operate/v1/data-consumer/governance-enforced.md): Understands how masking, filters, and access rules affect what they can see and use.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://v2.dataos.info/operate/v1/access-model.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.