Cloud

GRANT

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 Manage Access to Redpanda SQL.

Privilege levels

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

Level Object Privilege types

Database

The Redpanda SQL database

CONNECT

Schema

A schema in the database

USAGE, CREATE

Table

A table or a view

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

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

The table name can also be the name of a view. There is no ON VIEW form. To grant a privilege on a view, use ON TABLE with the view name.

You can grant INSERT, UPDATE, or DELETE on a view, but these privileges have no effect, because a view is read-only. A statement that writes to a view fails with relation "<view-name>" does not exist. Granting SELECT on a view lets a role query the view without a grant on the tables that the view reads. See CREATE VIEW permissions.

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.

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

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.

GRANT CONNECT ON DATABASE oxla TO role_name;

On Redpanda Cloud BYOC, CONNECT is managed automatically through the Cloud operator. Assigning a role that has the SQL: Access or SQL: Manage permission grants CONNECT. Removing the role from the user revokes CONNECT. The Cloud operator can revert a manual GRANT CONNECT.

Examples

Grant SELECT on a topic surfaced through a Redpanda catalog:

GRANT SELECT ON EXTERNAL SOURCE default_redpanda_catalog => 'orders' TO "alice@example.com";

Grant SELECT on every topic in a Redpanda catalog:

GRANT SELECT ON EXTERNAL SOURCE default_redpanda_catalog TO "alice@example.com";

Grant SELECT on every topic whose name starts with orders_:

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:

GRANT USAGE ON SCHEMA public TO "alice@example.com";

Grant SELECT on a view so that the user can query it:

GRANT SELECT ON TABLE large_orders TO "alice@example.com";