> 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/concepts/foundations/access-control-landscape.md). # Access Control DataOS access control is based on three concepts: Scopes, roles, and permissions. Scopes define where access applies. Roles describe a user’s responsibility in that scope. Permissions define what actions the user can perform on resources. Access granted in one scope does not automatically extend to another scope. For example, an Instance Admin can create or manage tenants, but cannot access a tenant’s resources, data, or workloads unless that access is explicitly granted. This keeps administrative access separate from tenant access and follows least-privilege principles. *** ## The three scopes DataOS access is organized into three scopes: Instance, Tenant, and Resource. Each scope controls a different part of the system. Access granted in one scope does not automatically extend to another scope. | Scope | What it means | Contains | Access controlled by | | ------------ | ------------------------------------------------------------------------------------------- | ------------------------------------------- | -------------------- | | **Instance** | The complete DataOS environment for an organization. | Tenants | Roles | | **Tenant** | An isolated workspace inside an Instance, usually used by a team, domain, or business unit. | Resources | Roles | | **Resource** | A Tenant-owned asset, such as Compute, Depot, Secret, Workflow, Service, or Lakehouse. | Resource-specific objects, where applicable | Permissions | Roles control access at the Instance and Tenant scopes. Permissions control access to specific Resources. For example, an Instance Admin can create or manage tenants, but cannot access a tenant’s resources, data, or workloads unless that access is explicitly granted. This keeps administrative access separate from tenant and resource access, following least-privilege principles. {% hint style="info" %} **Core principle** Access granted in one scope does not automatically extend to another scope. Resource access must be explicitly granted. {% endhint %} *** ## Instance scope The Instance scope controls organization-level access to DataOS. User identity at this scope is managed through the customer’s Identity Provider, such as Okta, Microsoft Entra ID, Google Workspace, or another enterprise IdP. Instance roles are assigned when the Instance is created and cannot be modified afterward. There are two Instance roles: An Operator can perform Instance-level administration tasks, such as: * Create and provision Tenants * Configure Tenant settings * Attach a data plane to a Tenant * Attach compute to a Tenant * Delete Tenants * Invite users into a Tenant * Assign Tenant Admins An Operator provisions the Tenant and assigns one or more Tenant Admins. The Tenant Admin then manages day-to-day access within that Tenant. {% hint style="warning" %} **Access that must be explicitly granted** An Operator does not automatically get access to a Tenant’s resources, data, or workloads. That access must be granted separately at the Tenant or Resource scope. {% endhint %} *** ## Tenant scope A Tenant is an isolated environment inside an Instance where teams create, manage, and govern Data Products independently. ### Tenant-level 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) * [Tenant Data Admin](#tenant-data-admin) * [Tenant Data Developer](#tenant-data-developer) * [Tenant Data Consumer](#tenant-data-consumer) #### Tenant Admin A Tenant Admin manages users, roles, and access inside a Tenant. A Tenant Admin can create Resources, manage access to Resources, and assign Tenant-level roles. A Tenant Admin has `Can Manage Access` on every Resource in the Tenant by default. This means they can manage access on every Resource in the Tenant, including Resources created by other users. They can grant or revoke permissions for other users, or grant themselves the edit access required to the Resource.for a task. However, Can Manage Access is not the same as using or editing a Resource. To use a Resource or edit a Resource created by another user, the Tenant Admin must grant themselves the required permission separately. Can Manage Access only controls permission management. It does not automatically give usage or edit access to the Resource. **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 * 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 Depot, Can Use Secret, 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 Compute to use a Compute * Can Use Depot to use a Depot * Can Use Secret to use a linked Secret * Can Use Cluster to use a Minerva Cluster #### Elevating access to resources inside the tenant `Can Edit` on Resources created by other users requires an explicit permission. To update or delete another user's Resource, the Tenant Admin grants themselves `Can Edit` on that Resource first. That act is logged and auditable — the same as any other permission. For example: * To update or delete a Workflow created by a developer who has left the team, the Tenant Admin grants themselves `Can Edit` on that Workflow. * To re-delegate access governance of a Depot to a new user, the Tenant Admin grants `Can Manage Access` on that Depot to the intended user — Tenant Admin already holds `Can Manage Access` on all Resources by default. * To obtain usage rights on a Compute or Depot, the Tenant Admin grants themselves `Can Use Compute` or `Can Use Depot`, following the same process as any other user. This keeps even the most privileged role in the Tenant visible and accountable at every step. *** #### Tenant Data Admin A Tenant Admin can create Resources, manage access to Resources created by others and adminstrate Lakehouse objects such as namespaces, schemas, tables, and views. **What a Tenant Data Admin can do:** * Create Resources in the Tenant — Compute, Secret, Depot, Vulcan, Nilus, Depot, Lakehouse, and others. * Update and delete Resources they have created * Grant or revoke access on Resources they have created or any Resources created by others. * Create, configure, and govern Lakehouse namespaces, schemas, tables, and views through the Lakehouse interface * Access all Tenant-level applications Like a Tenant Admin, a Tenant Data Admin can manage access, but that does not automatically give them every usage or edit permission. **Access requiring an explicit permission:** * Compute access — requires an explicit `Can Use Compute` permission * Depot and linked Secret access — requires explicit `Can Use Depot` and `Can Use Secret` permissions * `Can Edit` and `Can Manage Access` on Resources created by other users — requires an explicit permission *** #### Tenant Data Developer The Tenant Data Developer builds workloads like Data Product, Nilus pipelines, that run in the Tenant. They request access to the shared customer-owned Resources — Compute, Depots, Clusters — needed to run their workloads. **What a Tenant Data Developer can do:** * Create Resources — Workflow, Service, Worker, Secret, Depot, and others * Update and delete Resources they have created * Grant or revoke access on Resources they have created * Access all Tenant-level applications **Access requiring an explicit permission:** * Compute access — requires an explicit `Can Use Compute` permission * Depot access — requires an explicit `Can Use Depot` permission * Secret access (created by others) — requires an explicit `Can Use Secret` permission * Minerva Cluster access — requires an explicit `Can Use Cluster` permission *** #### Tenant Data Consumer The Tenant Data Consumer accesses governed Data Products and data applications and applications. This role does not create workloads or Resources. **What a Tenant Data Consumer can do:** * View and interact with permitted Data Products, dashboards, and governed data assets * Access UI applications for data exploration and consumption **Outside this role's scope:** * Resource creation and workload execution * Direct access to common Resources — Compute, Depots, Secrets, and Clusters — requires an explicit permission under a role with broader scope *** ## Resource scope The Resource scope controls access to individual Resources inside a Tenant, such as Compute, Depot, Secret, Cluster, and others. A Tenant role may allow a user to create Resources. However, creating a Resource does not automatically allow the user to use that Resource. When a user creates a Resource, they automatically receive `Can Edit` and `Can Manage Access` on that Resource. This means they can update or delete the Resource, and they can grant or revoke access to it. All other access must be granted separately. For example, a user may be able to create a Depot, but using that Depot in a workload requires `Can Use Depot`. If the Depot depends on a Secret for authentication, the user also needs `Can Use Secret` on the linked Secret. Access to the Depot and access to the Secret are separate because the Depot defines the data connection, while the Secret protects the credentials used by that connection. This dependency model also applies to workload execution. A user may be able to create a Nilus pipeline, but running that pipeline requires access to the Resources it depends on, such as Compute, Depot, and Secret. | Permission | What it allows | | --------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Can Edit** | Update or delete the Resource. | | **Can Manage Access** | Grant or revoke access on the Resource. This does not include usage or edit access. | | **Can Use Depot** | Use a Depot in workloads. | | **Can Use Compute** | Run workloads on the node pools attached to a Compute. | | **Can Use Secret** | Use a Secret in workloads to authenticate to external systems. | | **Can Use Cluster** | Use a Minerva Cluster to query data sources. Separate Depot access is still required for the underlying sources. | {% hint style="warning" %} **Access that must be explicitly granted** A user only gets the action that the permission grants. For example, managing access to a Depot does not allow the user to use that Depot in a workload. To use it, the user still needs `Can Use Depot`, and if the Depot uses a linked Secret, the user also needs `Can Use Secret`. {% endhint %} Even if a Tenant role allows users to create Depots or Secrets, production credentials should be created only by designated users, such as a Tenant Admin or authorized Data Administrator. Other users can be granted `Can Use Depot` or `Can Use Secret` when they need to use those Resources in workloads. *** ## Running a Resource as another user Sometimes you need to perform an action you don't personally hold the permissions for — for example, creating a Resource that depends on a Depot you can't access. Rather than copying credentials or widening your own role, DataOS lets you run a Resource under another user's identity, with that user's explicit consent. By setting `runAsUser` in a Resource manifest, the Resource is created and runs under the named user's identity — their permissions apply, not yours: ```yaml spec: runAsUser: johndoe ``` The target user must first consent by granting you the **Run As User** use-case, and only an Operator can set up that permission. This keeps borrowed access deliberate and fully auditable — the same as any other permission. If the permission is later revoked, any Resource that uses `runAsUser` with that identity fails at runtime. See [RunAsUser permissions](/concepts/foundations/access-control-landscape/runasuser-permissions.md) for the full grant, use, and revoke workflow. *** ## Example: Building a Data Product **Scenario:** 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 customer’s Identity Provider and can sign in to DataOS. 2. The user is onboarded into the required Tenant. This may be done by the Operator through Instance Admin, or by the Tenant Admin if tenant onboarding has been delegated to them. 3. The Tenant Admin assigns the user the **Tenant Data Developer** role. This allows the user to work inside the Tenant and create the Data Product. 4. The Data Developer creates the Data Product and defines the required inputs, outputs, APIs, contracts, and ports. 5. Because the Data Product depends on shared Resources, the Tenant Admin grants the required Resource permissions: * `Can Use Compute` on the shared Compute where processing will run * `Can Use Depot` on the Snowflake Depot used as a data source * `Can Use Secret` on the Secret linked to the Snowflake Depot * `Can Use Cluster` on the Cluster used for querying 6. After the required permissions are granted, the Data Developer can build, run, and publish the Data Product using the approved Resources. {% hint style="success" %} Each permission is granted for a specific Resource and action. Access to the Snowflake Depot does not automatically grant access to the linked Secret, shared Compute, or Cluster. Each dependency must be granted separately. {% endhint %} --- # 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/concepts/foundations/access-control-landscape.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.