Access and credentials

The three components need different privilege scopes. Use this page to scope database grants, IAM roles, and network policy before you deploy.

Each component page covers its own access in context. This page puts them side by side, which is the view you want when you are writing the grants.

Use separate engine credentials for authoring, reconciliation, and query execution.

Access typesmetadata readDDL write (scoped)table data readKubernetes APIno access needed

How the three fit together

Authoring happens once, by a person. Reconciliation and serving are continuous and independent. They coordinate only through the Kubernetes API, never by calling each other.

Authoring happens once, by a person. Reconciliation and serving run continuously and independently. They coordinate through the Kubernetes API and never call each other, which is why queries keep being answered while the operator is upgrading.

Three database users, three scopes

Identity	Metadata	Table data	DDL	Catalog / cloud
ossiectl (a person)	read	none	none	read
Operator	read	none	view schema	none
Server	none	SELECT	none	none

Keep the operator and server as separate database users. Sharing one would give the query path the ability to alter schemas. How the chart resolves each credential is in the Configuration and deployment reference.

Known limits

Engine credentials are a static username and password from a Secret. Per-caller identity is available through passthrough or token exchange, but IAM, short-lived credentials, and key-pair schemes are not built yet. The full list of operational limits, including engine count, served namespaces, and artifact size, is in Configuration and deployment.