> 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-set-a-data-products-runtime-identity.md).

# How to set a Data Product's runtime identity ?

## Overview

A Data Product that reads from a **Snowflake Depot**, runs on a **shared Compute**, and queries through a **Cluster** needs access to all of those while it runs. If it runs under the identity of the developer who built it, the product breaks when that person changes teams or loses a grant. A production dependency should not rely on one individual.

Instead, give the product its own **runtime identity**: an **ApplicationUser** that holds the `Can Use` grants itself, referenced from the manifest through the `runAsUser` field. The product then executes under that identity and inherits its permissions. No consumer or developer needs individual grants for the product's dependencies at runtime.

This recipe spans three roles: the **Data Developer** decides the product needs a runtime identity, the **Tenant Admin** creates the ApplicationUser and grants it access, and the **Operator** authorizes the developer to run resources as that identity.

By the end of this recipe, an ApplicationUser holds `Can Use` on the product's dependencies, the developer is authorized to run resources as that identity, and the deployed product runs under it. It survives changes to the developer's personal access.

## Before you begin

{% hint style="info" %}

* You can involve all three roles this recipe needs: a **Tenant Admin** (to create the ApplicationUser and grant it access), an **Operator** (the only role that can authorize `runAsUser`), and the **Data Developer** who owns the manifest.
* You know the product's **dependencies**: the Compute it runs on, the Depots it reads, any Secrets those Depots are linked to, and the Cluster it queries through. If you granted these to the developer while building, it is the same list. See [Give a developer access to build a Data Product](/operate/v1/recipes/how-to-give-access.md).
* The dependency resources **already exist** and are managed by a Tenant Admin or Data Admin.
* The Operator has access to **Bifrost** to configure the `runAsUser` use-case grant.
  {% endhint %}

## Understand the three identities

`runAsUser` only changes the **runtime** identity. When a resource is applied, DataOS tracks three identities separately, and they can all be different people:

| Identity      | Who it is                        | What it controls                                    |
| ------------- | -------------------------------- | --------------------------------------------------- |
| **owner**     | Who the resource belongs to      | Ownership. Unchanged by `runAsUser`                 |
| **submitter** | Who ran the apply command        | Who deployed it. Unchanged by `runAsUser`           |
| **runAsUser** | Whose identity it executes under | Which permissions and policies apply **at runtime** |

Setting `runAsUser` to the ApplicationUser changes only the third. The developer is still the submitter; the product's runtime access follows the ApplicationUser.

## Steps

### 1. Create the ApplicationUser

The **Tenant Admin** creates the ApplicationUser that will serve as the product's runtime identity. For example, use `customer-360-app`. This is a non-human identity that exists to run the product, independent of any team member.

See [Create an application user](/operate/v1/access-model/runasuser-permissions/create-an-application-user.md).

### 2. Grant the ApplicationUser the permissions the product needs

The ApplicationUser must hold **every** permission the product uses at runtime. These are the same dependency-by-dependency `Can Use` grants a developer needs to build it. Grant them on the ApplicationUser, not on a person:

* `Can Use Compute` on the shared Compute the product runs on
* `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 it queries through

Each dependency is granted separately. `Can Use Depot` does not include the linked Secret. Where the standard access matches a role, assign that role to the ApplicationUser and grant only the extras it lacks.

See [Grant permissions](/operate/v1/access-model/runasuser-permissions/grant-permissions.md).

### 3. Authorize the developer to run resources as the ApplicationUser

Only an **Operator** can do this. The grant is made **on the ApplicationUser's profile, not the developer's**. In **Bifrost**, open the **ApplicationUser's Grants** tab and grant the **Run As User** use-case with the **developer's user ID** as the subject.

This is what lets the developer put `runAsUser: customer-360-app` in a manifest. `runAsUser` is built on explicit consent: without this Operator-configured grant, the manifest is rejected.

{% hint style="info" %}
The grant lives on the **ApplicationUser's** profile, with the developer as subject, not on the developer's own profile. Revoking it makes **any resource that uses that `runAsUser` fail at runtime**, so track which products depend on it before removing it.
{% endhint %}

### 4. Reference it in the manifest

The **Data Developer** sets `runAsUser` to the ApplicationUser's ID in the product manifest:

```yaml
spec:
  runAsUser: customer-360-app
```

### 5. Deploy and verify

Apply the manifest and run the product. It now executes under the ApplicationUser's identity and inherits its permissions. DataOS evaluates the product's access to Depots, Compute, Cluster, and governed data policies against `customer-360-app`, not the developer.

To confirm: the product should read the Snowflake Depot, run on the Compute, and query through the Cluster without any grant on the developer's own account. Removing the developer's personal `Can Use` grants should not affect the deployed product.

## Troubleshooting

| Symptom                                                        | Likely cause                                                                                                                                         | Fix                                                                                   |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Manifest apply is rejected when `runAsUser` is set             | The Operator has not granted the **Run As User** use-case with this developer as subject                                                             | Operator grants it on the **ApplicationUser's Grants tab** in Bifrost (step 3)        |
| Product runs but fails reading the Depot                       | The **ApplicationUser** is missing `Can Use Depot` or the linked `Can Use Secret`                                                                    | Grant the missing `Can Use` on the **ApplicationUser** (step 2), not on the developer |
| Product worked, then suddenly fails at runtime                 | The Run As User grant was revoked, or the ApplicationUser lost a `Can Use` grant                                                                     | Restore the revoked grant on the ApplicationUser's profile                            |
| Developer can set `runAsUser` for one identity but not another | The Run As User use-case is granted per identity; only identities where the Operator configured the grant with this developer as subject are allowed | Operator configures the grant for the intended ApplicationUser                        |
| Product still tied to the developer after teams change         | The manifest never adopted `runAsUser`, so it still runs as the submitter                                                                            | Add `runAsUser` and redeploy (step 4)                                                 |

## References

* [`runAsUser` permissions](/operate/v1/access-model/runasuser-permissions.md): the owner / submitter / runAsUser model and the consent it is built on.
* [Access control → Running a Resource as another user](/operate/v1/access-control.md): where `runAsUser` sits in the full access model.


---

# 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-set-a-data-products-runtime-identity.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.