> 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/resource-level-permissions/lakehouse-access-control.md).
# Lakehouse: Access control
## What does it enable?
A Lakehouse follows the same access model as every other DataOS resource: nothing is shared automatically, and every permission traces back to someone who granted it.
When you create a Lakehouse, you become its owner and automatically receive:
* `Can Edit`: update the Lakehouse
* `Can Manage Access`: grant or revoke access to it for others
A **Tenant Admin** holds that same authority over every Lakehouse in the Tenant, whether or not they created it.
{% hint style="info" %}
Holding a Tenant role does not by itself give you access to a specific Lakehouse. Someone with `Can Manage Access` (the owner, or a Tenant Admin) has to grant it.
{% endhint %}
## Does this also cover the data inside the Lakehouse?
No. `Can Edit`, `Can Manage Access`, and `Can Use` govern the Lakehouse as a resource: creating it, updating it, and granting access to it. The namespaces, schemas, tables, and views inside it are separate entities, structured and governed from the **Manage Lakehouse** portal in the UI, not through these resource-level permissions.
{% hint style="info" %}
Holding `Can Edit` or `Can Manage Access` on the Lakehouse resource does not by itself grant access to the data inside it. See [Manage the Lakehouse](/operate/v1/data-admin/manage-lakehouse.md) for how namespaces, schemas, tables, and views are structured and governed.
{% endhint %}
## Who can create a Lakehouse?
A user with the **Tenant Admin**, **Data Admin**, or **Data Developer** Tenant role can create a Lakehouse, provided they also hold the permissions it depends on.
### What do you need before you can create one?
Creating a Lakehouse means using two other resources, and each needs its own `Can Use` grant:
Dependency
Permission needed
Secret
Can Use
Compute
Can Use
The grant can come from either the resource's owner or anyone who already holds `Can Manage Access` on it, including a Tenant Admin, who can grant the access to themself or others. That grant is audited either way.
{% hint style="info" %}
Owning a resource does not include `Can Use` on it. Creating a Depot, Secret, or Compute gives you `Can Edit` and `Can Manage Access`. Using it in a Data Product workload, including your own Lakehouse, still requires a `Can Use` grant, which you give yourself with your `Can Manage Access` authority. That self-grant is audited like any other.
{% endhint %}
Show example
`iamgroot` wants to create a Lakehouse, but the Depot, Secret, and Compute it needs all belong to `johndoe`. `johndoe` grants `iamgroot` `Can Use` on each of the three. Since owning those resources didn't already give `johndoe` `Can Use` on them either, `johndoe` grants that to himself too if he ever needs to reference them directly.
`iamgroot` can now create the Lakehouse. `iamgroot` becomes its owner, holding `Can Edit` and `Can Manage Access` on it, while `johndoe` keeps full control over the Depot, Secret, and Compute it depends on.
## What is the common access pattern?
DataOS access is deny by default: owning one resource never extends access to the resources it depends on.
That means:
* the Lakehouse owner manages access to the Lakehouse
* the Depot owner manages access to the Depot
* the Secret owner manages access to the Secret
* the Compute owner manages access to the Compute
Anyone with `Can Manage Access` on a resource can grant access on it, even without being the original creator. Within the Tenant, a Tenant Admin can do the same across all of them.
If you need to use a Depot, Secret, or Compute someone else owns, ask its owner (or anyone else holding `Can Manage Access` on it) for the grant first.
## What happens after the Lakehouse exists?
Once created, the owner controls who can work on it. A Tenant Admin can manage access to it too, even without having created it.
Typical grants on an existing Lakehouse:
Permission
Lets the grantee
Can Edit
Update the Lakehouse
Can Manage Access
Grant or revoke access for others
Can Use
Use a dependent resource, such as a Depot, Secret, or Compute
For the full access model, see [Access control](/operate/v1/access-model.md).
---
# 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/resource-level-permissions/lakehouse-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.