> 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/references/v1/resources/nilus/roles-and-permissions.md).

# Roles and permissions

A Nilus pipeline connects to a source and a destination using whatever credential the depot or connector resolves at runtime. That credential's underlying database or warehouse user needs a specific, minimal set of privileges: what Nilus actually does for that pipeline's mode, and nothing more.

This section is a provisioning reference for platform, database, and security administrators who need to grant those privileges correctly.

{% hint style="info" %}
**Not the same as** [**Nilus: Access control**](https://v2.dataos.info/operate/access-model/resource-level-permissions/nilus-access-control)

That page covers DataOS-level RBAC: who is allowed to create, edit, or run a `type: nilus` resource inside DataOS. This section covers a different layer: the SQL `GRANT`s or IAM roles the *source and destination systems* need to give the credential a Nilus pipeline actually connects with. Set up DataOS access there; provision the source and destination credentials here.
{% endhint %}

## How privileges map to pipeline mode

Privilege requirements don't come from the connector alone. They come from what a given pipeline does with that connector, which is determined by `spec.type` and which side of the pipeline the depot sits on:

| Operation                                        | Where it applies                                                    | What it typically needs                                                                                                                                                                                                    |
| ------------------------------------------------ | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Read** (batch or CDC source, initial snapshot) | Depot referenced in `source.address`                                | Connection/session access, plus `SELECT`-level read on the source schema, table, or collection                                                                                                                             |
| **Write** (batch or CDC sink)                    | Depot referenced in `sink.address`                                  | Connection/session access, DML scoped to the `incremental_strategy` (`append`, `merge`, or `replace`), and table/schema creation if Nilus auto-creates the destination                                                     |
| **CDC log or change-stream access**              | Source depot on a `type: cdc` pipeline                              | A server-level capability beyond ordinary read access: WAL/logical replication on PostgreSQL, native CDC change tables on SQL Server, or cluster-wide change streams on MongoDB. Usually requires an admin to enable first |
| **Hera metadata ingestion**                      | Depot referenced in `source.address` on a `type: metadata` pipeline | Read access to catalog objects (tables, schemas, columns), plus connector-specific system tables for lineage, usage, and tags                                                                                              |

Grant only the operations a given credential's pipelines actually perform. A user that only ever appears in `source.address` for batch pipelines needs no write grants; a user that never runs CDC needs no replication privilege.

### Same source, different pipeline modes

The same connector, and even the same depot, can appear in more than one pipeline mode, and each mode adds its own privilege on top of ordinary read access:

* A PostgreSQL depot used for a nightly batch extract only needs `SELECT` on the source schema.
* The same PostgreSQL server used for CDC additionally needs `wal_level = logical` enabled and the `REPLICATION` user attribute.
* The same server used for Hera metadata and lineage ingestion additionally needs the `pg_stat_statements` extension and `pg_read_all_stats`.

Each guide below breaks its grants down the same way: read, write (by strategy), CDC prerequisites where the connector supports CDC, and Hera metadata, ending in a permission matrix that maps every use case to the exact privileges it needs.

## Connector guides

| Connector     | Guide                                                                                                      | CDC supported | Access model                                                       |
| ------------- | ---------------------------------------------------------------------------------------------------------- | ------------- | ------------------------------------------------------------------ |
| PostgreSQL    | [PostgreSQL](/references/v1/resources/nilus/roles-and-permissions/postgresql-minimum-permissions.md)       | Yes           | SQL `GRANT` statements on roles                                    |
| MongoDB       | [MongoDB](/references/v1/resources/nilus/roles-and-permissions/mongodb-minimum-permissions.md)             | Yes           | Role-based access control (`createUser` roles)                     |
| MS SQL Server | [MS SQL Server](/references/v1/resources/nilus/roles-and-permissions/ms-sql-server-minimum-permissions.md) | Yes           | SQL `GRANT` statements, plus native CDC stored procedures          |
| Snowflake     | [Snowflake](/references/v1/resources/nilus/roles-and-permissions/snowflake-minimum-permissions.md)         | No            | SQL `GRANT` statements on roles                                    |
| Databricks    | [Databricks](/references/v1/resources/nilus/roles-and-permissions/databricks-minimum-permissions.md)       | No            | Unity Catalog `GRANT` statements, plus SQL warehouse UI permission |
| Kafka         | [Kafka](/references/v1/resources/nilus/roles-and-permissions/kafka-minimum-permissions.md)                 | No            | Kafka ACLs (`kafka-acls.sh`)                                       |
| Salesforce    | [Salesforce](/references/v1/resources/nilus/roles-and-permissions/salesforce-minimum-permissions.md)       | No            | Org permission sets / profiles (object and field-level Read)       |
| Stripe        | [Stripe](/references/v1/resources/nilus/roles-and-permissions/stripe-minimum-permissions.md)               | No            | Restricted API key scoped to Read                                  |

## Related docs

* [Secrets and Projections](/references/v1/resources/nilus/concepts/secrets-and-projections.md) - How Nilus resolves the credential that these grants apply to: Depot inference, explicit projection, or repo-auth
* [Batch Pipeline Config](/references/v1/resources/nilus/batch/pipeline-config.md) - `source.options` and `sink.options` reference for batch pipelines
* [CDC Pipeline Config](/references/v1/resources/nilus/cdc/pipeline-config.md) - `source.options` and `sink.options` reference for CDC pipelines
* [Troubleshooting](/references/v1/resources/nilus/troubleshooting.md) - Triage path for connection, authentication, and authorization failures


---

# 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/references/v1/resources/nilus/roles-and-permissions.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.