> 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/recipes/how-to-give-access.md).

# How to provide access ?

## Overview

A Data Developer is building a Data Product that reads from a **Snowflake Depot**, runs on a **shared Compute**, and queries through a **Minerva Cluster**. They can sign in and hold the Data Developer role, but by default they hold **no access to any of those resources**. Access is denied until it is granted. Creating a resource never grants the right to *use* it.

As the Tenant Admin, grant the matching `Can Use` on each dependency the product touches. Grant no more than required. **Each dependency is granted separately.** Access to the Snowflake Depot does not extend to the Secret it is linked to, the Compute it runs on, or the Cluster it queries through. Miss one and the workload fails at runtime with an access error that looks unrelated to the missing grant.

By the end of this recipe, the developer holds four grants: `Can Use` on the Compute, Depot, Depot's linked Secret, and Cluster. They can build, run, and publish the product with approved resources only.

## Before you begin

{% hint style="info" %}

* You are a **Tenant Admin** (or Data Admin). You hold `Can Manage Access` on every resource in the Tenant by default, including resources you did not create. You can grant `Can Use` on any of them.
* The developer can already **sign in to the Instance** and is **in the Tenant with the Data Developer role**. If not, onboard them first. See [Manage access → Onboard users and assign roles](/operate/v1/tenant-admin/governance.md).
* The resources the product depends on **already exist**. Compute, Depots, Secrets, and Clusters carry production connection details and credentials and should be created and managed by a Tenant Admin or Data Admin, not the developer.
* You know **which resources the product depends on**. Ask the developer, or read the dependencies in the product manifest (its inputs, the Compute it runs on, and the Cluster it queries through).
  {% endhint %}

## Steps

### 1. List the product's dependencies

Before granting anything, write down every resource the workload touches and the exact permission each one needs. Access to a workload does not cascade to its dependencies. DataOS evaluates each one on its own.

For this product:

| Dependency                     | Why the product needs it              | Grant to issue    |
| ------------------------------ | ------------------------------------- | ----------------- |
| Shared **Compute**             | The product's workload runs on it     | `Can Use Compute` |
| Snowflake **Depot**            | The product reads source data from it | `Can Use Depot`   |
| **Secret** linked to the Depot | Authenticates the Depot to Snowflake  | `Can Use Secret`  |
| Minerva **Cluster**            | The product queries through it        | `Can Use Cluster` |

{% hint style="warning" %}
**The linked Secret is the one people forget.** A Depot that connects to Snowflake almost always references a Secret for its credentials. `Can Use Depot` does **not** include `Can Use Secret`. They are separate resources with separate grants. If you grant the Depot but not its Secret, the read fails at runtime even though the Depot grant looks correct.
{% endhint %}

### 2. Open the first resource's Access tab

Grants are issued per resource, from the resource itself:

1. Open the **Resource Catalog**.
2. Search for the resource by name. Start with the shared **Compute**.
3. Open it and go to the **Access** tab. This lists who currently has access and at what level.

### 3. Grant Can Use

On the **Access** tab, click **Grant Permission**, then:

1. Select the **Data Developer**. Prefer a **role** when this access is standard for everyone in that role.
2. Choose **`Can Use`**. The three levels differ:
   * `Can Use`: reference the resource in a Data Product workload. **This is what a developer building a product needs.**
   * `Can Edit`: change the resource's configuration. Not needed here.
   * `Can Manage Access`: grant the resource onward to others. Not needed here.
3. Confirm the grant.

{% hint style="info" %}
**Grant to a role, not a person, when the access is standard.** If every Data Developer on this team uses the same shared Compute, grant `Can Use` to the role once. New joiners inherit it, and leavers lose it automatically. Reserve individual grants for one-off access, and review those periodically.
{% endhint %}

### 4. Repeat for every dependency: include the linked Secret

Go back to the **Resource Catalog** and repeat step 3 for each remaining dependency:

* `Can Use Depot` on the Snowflake Depot
* `Can Use Secret` on the Secret linked to that Depot
* `Can Use Cluster` on the Cluster used for querying

Each grant covers **one resource and one action**. Four dependencies means four grants. Do not stop after the Depot. The linked Secret and Cluster are separate resources. Each needs its own `Can Use`.

### 5. Confirm the developer can build and run

Ask the developer to build, run, and publish the product. With all four grants in place, the workload can reach every dependency it needs.

To verify from your side, open each resource's **Access** tab again and confirm the developer (or their role) appears with `Can Use`. If the workload still fails, the error usually names the resource missing a grant. Check it against your list from step 1.

### 6. For the deployed product, prefer a runtime identity (optional)

The grants above let the **developer** build and run the product interactively. Once the product is **deployed and running unattended**, avoid tying it to a person's grants. A developer moving teams should not break a production product.

Instead, give the product a stable **runtime identity** (an ApplicationUser referenced through `runAsUser`) that holds the `Can Use` grants itself. The product then runs under that identity, and no per-user grants are needed at runtime. See [How to set a Data Product's runtime identity](/operate/v1/recipes/how-to-set-a-data-products-runtime-identity.md).

## Troubleshooting

| Symptom                                                                  | Likely cause                                                                                                  | Fix                                                                                                                 |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Workload fails reading the Depot, even though `Can Use Depot` is granted | The Depot's **linked Secret** was not granted                                                                 | Grant `Can Use Secret` on the Secret the Depot references (step 4)                                                  |
| Developer can't run the product on the shared Compute                    | `Can Use Compute` is missing. Creating or holding another grant never implies use access                      | Grant `Can Use Compute` on that Compute                                                                             |
| Developer can see data but can't query it through Workbench              | `Can Use Cluster` missing                                                                                     | Grant `Can Use Cluster` on the Minerva Cluster                                                                      |
| You granted access but the developer is still blocked                    | Granted at the wrong level (`Can Manage Access` or `Can Edit` instead of `Can Use`), or to the wrong identity | Re-check the Access tab; `Can Manage Access` does **not** include the right to use the resource                     |
| You can't grant on a resource                                            | The resource is in a different Tenant, or you lack `Can Manage Access` on it                                  | Grant from within the owning Tenant; a Tenant Admin holds `Can Manage Access` on that Tenant's resources by default |
| Deployed product breaks after the developer changes teams                | The product runs under the developer's personal grants                                                        | Move the product to a runtime identity (step 6)                                                                     |

## References

* [Access control](/operate/v1/access-control.md): the full model, including levels, roles, permissions, grants, and dependencies.
* [Roles & Permissions](/operate/v1/access-model.md): Tenant role capabilities and the `Can Use` / `Can Edit` / `Can Manage Access` reference.
* [Resource-level permissions](/operate/v1/access-model/resource-level-permissions.md): permissions for each resource type.
* [Manage access](/operate/v1/tenant-admin/governance.md): the Tenant Admin's grant and onboarding workflow.
* [How to set a Data Product's runtime identity](/operate/v1/recipes/how-to-set-a-data-products-runtime-identity.md): use a stable identity instead of per-user grants.


---

# 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/recipes/how-to-give-access.md?ask=<question>&goal=<endgoal>
```

`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.