> 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/governance/adminstration/tenant.md). # Tenant Admin Tenant creation is an Instance-level activity performed by an Operator. Day-to-day Tenant governance is the responsibility of the Tenant Admin. ## What is a Tenant Admin? A **Tenant Admin** is the highest-privileged role within a DataOS Tenant. An Operator assigns the role to a user who governs the Tenant access model, oversees resource lifecycle, and keeps the Tenant operationally ready. ## Tenant Admin responsibilities As a Tenant Admin, you handle access control, resource oversight, and selected resource creation inside the Tenant boundary. These responsibilities define how Tenant-level governance applies after the Tenant is provisioned. ### Access management Use the **Tenant Admin** application in the DataOS UI to find users in the Instance and assign Tenant-level roles. This lets you onboard users without requiring Instance-level intervention for every access request. It keeps Instance-level operations separate from Tenant-specific access decisions. ### Resource management By default, DataOS access control prevents one user from updating, deleting, or managing a resource created by another user. As a Tenant Admin, you have elevated privilege within the Tenant and can act on those resources when operations require it. Apply this when the original resource creator is unavailable, has left the team, or can no longer maintain the resource. You can update, delete, or grant access to Tenant resources such as a Depot to keep operations stable. ### Resource creation You can create resources within the Tenant like any authorized user. This matters for resources that hold credentials, connection details, or other sensitive configuration values. In practice, Tenant Admins create controlled resources such as Secrets and Depots when those resources require privileged information that should not be accessible to standard Tenant users. ### Secret management DataOS stores credentials as **Secret** resources so Tenant workloads can authenticate to external systems without embedding credentials in configuration files. Most Tenant workloads need credentials. Operators create Secrets when they hold the credential material. Tenant users can create Secrets when they hold the connection credentials and policy permits it. Create and manage Secrets only through the CLI using the DataOS Secret resource type. ### Data sources Data source connections link workloads to external systems such as Snowflake, Databricks, Amazon Redshift, or other warehouses and databases. DataOS represents each connection as a **Depot** resource. Operators or Tenant Admins create Depots through the CLI. Users with sufficient access and the required connection details can create Depot resources without an Operator handoff. *** ## Related * [Roles & Permissions](/operate/governance/roles-and-permissions.md): Default role definitions and the Tenant roles capability matrix * [Access Control](/concepts/foundations/access-control-landscape.md): Full access model including the zero-trust grant model and audit requirements --- # 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/governance/adminstration/tenant.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.