Skip to content
Merged
7 changes: 7 additions & 0 deletions modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -347,6 +347,7 @@
**** xref:sql:get-started/oltp-vs-olap.adoc[]
**** xref:sql:get-started/redpanda-sql-vs-postgresql.adoc[]
** xref:sql:connect-to-sql/index.adoc[Connect to Redpanda SQL]
*** xref:sql:connect-to-sql/authenticate.adoc[Authenticate]
*** xref:sql:connect-to-sql/language-clients/psycopg2.adoc[]
*** xref:sql:connect-to-sql/language-clients/java-jdbc.adoc[]
*** xref:sql:connect-to-sql/language-clients/php-pdo.adoc[]
Expand All @@ -356,6 +357,7 @@
*** xref:sql:query-data/query-streaming-topics.adoc[Query Streaming Topics]
*** xref:sql:query-data/query-iceberg-topics.adoc[Query Iceberg Topics]
** xref:sql:manage/index.adoc[Manage Redpanda SQL]
*** xref:sql:manage/manage-access.adoc[Manage access]
** xref:sql:troubleshoot/index.adoc[Troubleshoot]
*** xref:sql:troubleshoot/degraded-state-handling.adoc[]
*** xref:sql:troubleshoot/memory-management.adoc[Memory Management]
Expand Down Expand Up @@ -544,14 +546,19 @@
**** xref:reference:sql/sql-statements/alter-redpanda-catalog.adoc[]
**** xref:reference:sql/sql-statements/alter-storage.adoc[]
**** xref:reference:sql/sql-statements/alter-table.adoc[]
**** xref:reference:sql/sql-statements/alter-user.adoc[]
**** xref:reference:sql/sql-statements/copy-to.adoc[]
**** xref:reference:sql/sql-statements/create-redpanda-catalog.adoc[]
**** xref:reference:sql/sql-statements/create-storage.adoc[]
**** xref:reference:sql/sql-statements/create-table.adoc[]
**** xref:reference:sql/sql-statements/create-user.adoc[]
**** xref:reference:sql/sql-statements/describe.adoc[]
**** xref:reference:sql/sql-statements/drop-redpanda-catalog.adoc[]
**** xref:reference:sql/sql-statements/drop-storage.adoc[]
**** xref:reference:sql/sql-statements/drop-table.adoc[]
**** xref:reference:sql/sql-statements/drop-user.adoc[]
**** xref:reference:sql/sql-statements/grant.adoc[]
**** xref:reference:sql/sql-statements/revoke.adoc[]
**** xref:reference:sql/sql-statements/select.adoc[]
**** xref:reference:sql/sql-statements/set-show.adoc[]
**** xref:reference:sql/sql-statements/show-execs.adoc[]
Expand Down
56 changes: 56 additions & 0 deletions modules/reference/pages/sql/sql-statements/alter-user.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
= ALTER USER
:description: The ALTER USER statement changes the password or superuser status of an existing user.
:page-topic-type: reference

The `ALTER USER` statement changes the password or superuser status of an existing user. `ALTER ROLE` is a synonym for `ALTER USER`, provided for PostgreSQL compatibility.

A superuser can alter any user. A non-superuser can alter their own user (for example, to change their own password) but cannot change their own superuser status.

== Syntax

[source,sql]
----
ALTER { USER | ROLE } user_name [WITH]
[ PASSWORD 'password' ]
[ SUPERUSER | NOSUPERUSER ];
----

* `user_name`: Name of the existing user to alter. Use the reserved keyword `CURRENT_USER` or `CURRENT_ROLE` to alter the user running the statement.
* `PASSWORD 'password'`: Optional. The new password. Must be a non-empty string literal if specified.
* `SUPERUSER`: Optional. Promotes the user to superuser. Requires superuser privileges on the current session.
* `NOSUPERUSER`: Optional. Removes superuser status from the user. The protected system superuser cannot be demoted.
Comment on lines +20 to +21
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a caveat here. SUPERUSER can do thouse queries altering the user type, but there is a claud operator that will override it if it isn't reflected in the organization IAM. It's will be usefull for selfhosted tho, so maybe we should put some note advicing not to use it on BYOC?

* `WITH`: Optional. Has no effect; provided for PostgreSQL compatibility.

[NOTE]
====
On Redpanda Cloud BYOC, the Cloud operator synchronizes users from Redpanda Cloud's organization IAM. Changes from `ALTER USER` to attributes such as `SUPERUSER` may be reverted by the operator if they don't match the IAM-managed state. Manage user superuser status through Redpanda Cloud's data-plane RBAC roles instead. See xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL].
====

== Examples

Change the password for an existing user:

[source,sql]
----
ALTER USER "alice@example.com" WITH PASSWORD 'new_secret';
----

Change your own password (as the current user):

[source,sql]
----
ALTER USER CURRENT_USER WITH PASSWORD 'new_secret';
----

Promote a regular user to superuser:

[source,sql]
----
ALTER USER "alice@example.com" SUPERUSER;
----

== Suggested reading

* xref:reference:sql/sql-statements/create-user.adoc[CREATE USER]
* xref:reference:sql/sql-statements/drop-user.adoc[DROP USER]
* xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL]
53 changes: 53 additions & 0 deletions modules/reference/pages/sql/sql-statements/create-user.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
= CREATE USER
:description: The CREATE USER statement creates a new user in Redpanda SQL with a required password. Only a superuser can create users.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same story as with SUPERUSER altering. If the user doesn't exist in organization IAM, the oxla operator in cloud will revoke those users login accesses (will not delete it)

:page-topic-type: reference

The `CREATE USER` statement creates a new user in Redpanda SQL. `CREATE ROLE` is a synonym for `CREATE USER`, provided for PostgreSQL compatibility. Only a superuser can run this statement.

A password is required when creating a user.

[NOTE]
====
Error messages from the SQL engine refer to users as "roles" (for example, `role "alice@example.com" does not exist`). This is consistent with PostgreSQL terminology and refers to the same object that `CREATE USER` produces.
====

[NOTE]
====
On Redpanda Cloud BYOC, users are provisioned automatically when a Redpanda Cloud user or service account is assigned a role with the *SQL: Access* or *SQL: Manage* permission. `CREATE USER` works syntactically, but the Cloud operator revokes `CONNECT` access for any user not present in Redpanda Cloud's organization IAM. Manage user lifecycle through Redpanda Cloud IAM instead. See xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL].
====

== Syntax

[source,sql]
----
CREATE { USER | ROLE } user_name [WITH] PASSWORD 'password' [SUPERUSER | NOSUPERUSER];
----

* `user_name`: Name of the new user. Cannot be `CURRENT_USER` or `CURRENT_ROLE`.
* `PASSWORD 'password'`: Required. The password must be a non-empty string literal.
* `SUPERUSER`: Optional. Grants superuser privileges to the new user. Superusers bypass authorization checks.
* `NOSUPERUSER`: Optional. Explicitly marks the user as a non-superuser. Default when neither `SUPERUSER` nor `NOSUPERUSER` is specified.
* `WITH`: Optional. Has no effect; provided for PostgreSQL compatibility.

== Examples

Create a regular user with a password:

[source,sql]
----
CREATE USER "alice@example.com" WITH PASSWORD 'secret123';
----

Create a superuser:

[source,sql]
----
CREATE USER "admin@example.com" WITH PASSWORD 'admin_secret' SUPERUSER;
----

== Suggested reading

* xref:reference:sql/sql-statements/alter-user.adoc[ALTER USER]
* xref:reference:sql/sql-statements/drop-user.adoc[DROP USER]
* xref:reference:sql/sql-statements/grant.adoc[GRANT]
* xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL]
53 changes: 53 additions & 0 deletions modules/reference/pages/sql/sql-statements/drop-user.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
= DROP USER
:description: The DROP USER statement removes an existing user. The user cannot own objects or hold grants when dropped.
:page-topic-type: reference

The `DROP USER` statement removes an existing user from Redpanda SQL. `DROP ROLE` is a synonym for `DROP USER`, provided for PostgreSQL compatibility. Only a superuser can run this statement.

A user cannot be dropped while they own objects (for example, a catalog or table created by that user) or hold privilege grants. Reassign or drop the owned objects and revoke the grants first, then drop the user.

[NOTE]
====
On Redpanda Cloud BYOC, the Cloud operator synchronizes users from Redpanda Cloud's organization IAM. If you `DROP USER` for an identity that still exists in Redpanda Cloud IAM, the operator can re-provision the user on the next sync. Remove the user from Redpanda Cloud IAM first, or use the data-plane RBAC role to revoke their SQL access. See xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL].
====

== Syntax

[source,sql]
----
DROP { USER | ROLE } [IF EXISTS] user_name;
----

* `user_name`: Name of the user to drop. Cannot be `CURRENT_USER` or `CURRENT_ROLE`. The user running the statement cannot drop themselves, and the protected system superuser cannot be dropped.
* `IF EXISTS`: Optional. Prevents an error if the user does not exist.

== Examples

Drop an existing user:

[source,sql]
----
DROP USER "alice@example.com";
----

Drop a user only if it exists:

[source,sql]
----
DROP USER IF EXISTS "legacy-account@example.com";
----

If the user has dependent grants or owned objects, the statement fails with an error listing the objects. Revoke the grants and reassign or drop owned objects first:

[source,sql]
----
REVOKE SELECT ON EXTERNAL SOURCE default_redpanda_catalog FROM "alice@example.com";
DROP USER "alice@example.com";
----

== Suggested reading

* xref:reference:sql/sql-statements/create-user.adoc[CREATE USER]
* xref:reference:sql/sql-statements/alter-user.adoc[ALTER USER]
* xref:reference:sql/sql-statements/revoke.adoc[REVOKE]
* xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL]
123 changes: 123 additions & 0 deletions modules/reference/pages/sql/sql-statements/grant.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,123 @@
= GRANT
:description: The GRANT statement assigns privileges on a database object to a role. Only a superuser can grant privileges.
:page-topic-type: reference

The `GRANT` statement assigns privileges on a database object to a role. Only a superuser can grant privileges.

Redpanda SQL is deny-all by default. A role has no access to any object until a superuser grants it. For the broader access model, see xref:sql:manage/manage-access.adoc[].

== Privilege levels

A privilege is associated with a level. Each level supports a specific set of privilege types:

[cols="<25%,<40%,<35%",options="header"]
|===
|Level |Object |Privilege types

|Database
|The Redpanda SQL database
|`CONNECT`

|Schema
|A schema in the database
|`USAGE`, `CREATE`

|Table
|A native SQL table
|`SELECT`, `INSERT`, `UPDATE`, `DELETE`

|External source
|A Redpanda catalog or SQL storage definition
|`SELECT`
|===

`ALL PRIVILEGES` resolves to the full set of privilege types at the given level. For external sources, `ALL PRIVILEGES` resolves to `SELECT` only.

== Syntax

=== Grant on a table
Copy link
Copy Markdown
Contributor Author

@kbatuigas kbatuigas May 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be removed? It appears that this just targets "native" tables. Is the correct syntax for RP tables supposed to be like this example instead? Or is it GRANT SELECT ON TABLE default_redpanda_catalog=>'orders' TO "alice@example.com";?


[source,sql]
----
GRANT { privilege [, ...] | ALL [PRIVILEGES] } ON TABLE table_name TO role_name;
----

=== Grant on an external source

A Redpanda catalog (the object created by `CREATE REDPANDA CATALOG`) and a SQL storage definition (the object created by `CREATE STORAGE`) are both external sources.

The catalog-level form grants the privilege on every relation reachable through the source. The pattern form scopes the grant to relations whose name matches the pattern.

[source,sql]
----
GRANT { SELECT | ALL [PRIVILEGES] } ON EXTERNAL SOURCE catalog_name TO role_name;
GRANT { SELECT | ALL [PRIVILEGES] } ON EXTERNAL SOURCE catalog_name => 'pattern' TO role_name;
----

* `pattern`: A string literal that matches a relation name. The wildcard `*` is only allowed at the end of the pattern (for example, `'orders_*'`).

=== Grant on a schema

[source,sql]
----
GRANT { privilege [, ...] | ALL [PRIVILEGES] } ON SCHEMA schema_name TO role_name;
----

Schema-level privileges affect visibility and creation rights for objects in the schema. Without `USAGE` on a schema, a user cannot see catalogs in that schema or reference objects in it by name.

=== Grant on the database

Redpanda SQL exposes a single database, `oxla`.

[source,sql]
----
GRANT CONNECT ON DATABASE oxla TO role_name;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same story as previously, operator will sync it with IAM in the background

----

[NOTE]
====
On Redpanda Cloud BYOC, `CONNECT` is managed automatically through the Cloud operator. Assigning the *SQL: Access* or *SQL: Manage* data-plane RBAC role grants `CONNECT`. Removing the role revokes it. Manual `GRANT CONNECT` may be reverted by the operator.
====

== Examples

Grant `SELECT` on a topic surfaced through a Redpanda catalog:

[source,sql]
----
GRANT SELECT ON EXTERNAL SOURCE default_redpanda_catalog => 'orders' TO "alice@example.com";
----

Grant `SELECT` on every topic in a Redpanda catalog:

[source,sql]
----
GRANT SELECT ON EXTERNAL SOURCE default_redpanda_catalog TO "alice@example.com";
----

Grant `SELECT` on every topic whose name starts with `orders_`:

[source,sql]
----
GRANT SELECT ON EXTERNAL SOURCE default_redpanda_catalog => 'orders_*' TO "alice@example.com";
----

Grant `USAGE` on a schema so the user can see the catalogs and storage in it:

[source,sql]
----
GRANT USAGE ON SCHEMA public TO "alice@example.com";
----

Grant `SELECT` and `INSERT` on a native SQL table:

[source,sql]
----
GRANT SELECT, INSERT ON TABLE summary_data TO "alice@example.com";
----

== Suggested reading

* xref:reference:sql/sql-statements/revoke.adoc[REVOKE]
* xref:reference:sql/sql-statements/create-user.adoc[CREATE USER]
* xref:sql:manage/manage-access.adoc[Manage access to Redpanda SQL]
Loading