> 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-control.md).
# Access control
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 DataOS Resource, such as Compute, Depot etc.
Access is denied by default. A role may allow a user to sign in, work inside a Tenant, or create Resources, but it does not automatically grant access to shared Resources, Resources created by other users, Data Products, workloads, or data.
This keeps Instance administration, Tenant responsibility, and Resource access separate.
***
### Where access applies
DataOS access applies at the Instance, Tenant, and Resource level. Some Resources also include items that may need separate access control.
* **Instance:** The complete DataOS setup for an organization. An Instance can contain one or more Tenants. Instance-level access is controlled through Instance roles, such as Operator and User.
* **Tenant:** A separate access and governance boundary within the Instance. Tenants are commonly aligned to a team, domain, or business unit. Data Products and their supporting Resources are created, managed, and governed inside a Tenant. Tenant-level access is controlled through Tenant roles, such as Tenant Admin, Tenant Data Admin, Tenant Data Developer, and Tenant Data Consumer.
* **Resource:** A Tenant-owned asset that users create, manage, use, or govern. Examples include Compute, Depot, Secret, Cluster, Lakehouse, Vulcan, Nilus, Data Product, and App. Resource-level access is controlled through Resource permissions, such as `Can Use [Resource]`, `Can Edit`, and `Can Manage Access`.
* **Items within a Resource:** Some Resources, such as Lakehouse, Data Products, and Apps, include items that may need separate access control. The Resource itself is managed in Resource Catalog. Access to items within a Resource may be managed separately depending on the Resource such as Lakehouse Admin, Products, or Apps.
***
## Roles
Roles define what kind of responsibility a user has in DataOS. Roles apply at the Instance or Tenant level.
### Instance roles
Instance roles apply at the Instance level and define what a user can do for the overall DataOS setup. Instance user identity is managed through the customer’s IdP. Refer [Authentication and Authorization](/operate/v1/authentication-and-authorization.md) for more details.
* **User:** Allows a user to sign in to the DataOS Instance. This role alone does not grant access inside a Tenant.
* **Operator:** Manages Instance-level setup and administration using Instance Admin application on the DatOS UI. An Operator can provision and configure DataOS, create and manage Tenants, attach the Data Plane and Compute, invite users, assign Tenant Admins, and delete Tenants. Tenant access must be explicitly granted.
Instance roles and their capabilities
### Tenant roles
Tenant roles apply inside a specific Tenant and define what a user can do within that Tenant. Tenant users, roles, and access are managed through **Tenant Admin**.
* **Tenant Admin:** Manages user invites, Tenant roles, and Resource access inside the Tenant. Can create Resources and manage access to Resources created by other users.
* **Data Admin:** Manages Lakehouse governance, including namespaces, schemas, tables, and views. Can create Resources and manage access to Resources created by other users.
* **Data Developer:** Builds Data Products and data-movement pipelines using Vulcan and Nilus. Can create Resources and manage access to the Resources they create.
* **Data Consumer:** Views and interacts with permitted Data Products, dashboards, Apps, and governed data assets. Does not create Resources, run Data Product workloads, or manage Resource access.
Tenant roles and their capabilities
For detailed role capabilities, see [Roles and permissions](/operate/v1/access-model.md).
{% hint style="info" %}
All Tenant roles except Data Consumer can create Resources along with their assigned responsibilities. However, the ability to create a Resource should not be treated as the default operating practice for all users.
Sensitive or shared Resources, such as Compute, Depots, Secrets, and Clusters, should be created and governed only by authorized administrators or designated platform/data administrators.
{% endhint %}
***
## Permissions
Permissions control what a user or workload can do with a specific DataOS Resource. They apply at the Resource level to assets such as Compute, Depot, Secret, Cluster, Lakehouse, Vulcan, Nilus, Data Product, and App.
* **Can Edit:** Update or delete a specific Resource, such as a Data Product, Compute, Depot, Secret, Cluster, Lakehouse, Vulcan, Nilus, or App.
* **Can Manage Access:** Grant or revoke access on a specific Resource. This does not include the right to use or edit the Resource.
* **Can Use \[Resource]:** Use a specific Resource where usage access applies, such as Compute, Depot, Secret, Cluster, Lakehouse, Data Product, App, Vulcan, or Nilus.
When a user creates a Resource, they receive:
* `Can Edit` and
* `Can Manage Access` on that Resource.
However, creating a Resource does not automatically grant usage access to that Resource. Usage still requires the matching **Can Use \[Resource]** permission.
## Resource dependencies
A Data Product or data-movement pipeline may depend on several Resources to run. Access to the workload does not automatically provide access to those Resources. Each dependency requires its own matching permission.
For example, a workload may need:
* Can Use Compute to run on Compute.
* Can Use Depot to read from a Depot.
* Can Use Secret to authenticate with a Secret.
* Can Use Cluster to query through a Cluster.
If a Depot uses a Secret, the workload needs access to both Resources. Having Can Use Depot does not also grant Can Use Secret.
DataOS evaluates each dependency separately so users and workloads receive access only to the Resources they need.
For the complete permission reference, see [Roles and permissions](/operate/v1/access-model.md).
***
## How a request is authorized
When a user or Data Product workload performs an action, DataOS first authenticates the identity. It then checks the roles, permissions, grants, and policies that apply to the target being accessed.
Authorization is evaluated against the specific target of the request. For example, a Tenant role may allow a user to work inside a Tenant, but it does not automatically grant access to every Resource or every item within those Resources.
If the required access has not been explicitly granted, the request is denied.
For governed data access, semantic-layer policies such as masking and row filters are applied at query time based on the requesting identity.
Authentication is connected to the customer’s identity provider, such as Okta, Microsoft Entra ID, Google Workspace, or another enterprise IdP. See [Authentication and authorization](/operate/v1/authentication-and-authorization.md).
***
## Running a Resource as another user
Some Resources need to run under an identity that already has the required permissions. For example, a Data Product or data-movement pipeline may need to use a Depot that the user creating or running the Resource cannot access directly.
DataOS supports this through the `runAsUser` field. A user can set `runAsUser` only after an Operator has configured the **Run As User** use-case grant for the target identity. At runtime, the Resource executes under the named user’s identity, and DataOS evaluates permissions and policies using that identity, without changing who created the Resource.
```yaml
spec:
runAsUser: johndoe
```
---
# 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-control.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.