{"id":"c1caefdd-5473-4283-8cb0-e98215e75d3d","task":"Create SQL-driven ClickHouse users, assign privileges directly or via roles using CREATE USER / CREATE ROLE / GRANT, after enabling access_management on self-managed deployments.","domain":"clickhouse.com","steps":["On self-managed ClickHouse, SQL-driven access control is disabled by default for all users; enable it for at least one bootstrap user (commonly 'default') in users.xml by setting: <access_management>1</access_management> <named_collection_control>1</named_collection_control> <show_named_collections>1</show_named_collections> <show_named_collections_secrets>1</show_named_collections_secrets>, then restart the node(s). (ClickHouse Cloud manages this differently — see its own access management docs.)","Connect as that bootstrap user: clickhouse-client --user default --password \"$CLICKHOUSE_PASSWORD\"","Create a SQL administrator account and grant it full rights: CREATE USER clickhouse_admin IDENTIFIED BY '<strong-password>'; GRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTION;","Create ordinary users the same way: CREATE USER my_user IDENTIFIED BY '<strong-password>'; — to grant or revoke privileges as an admin, that admin account must itself hold WITH GRANT OPTION on those privileges.","Create a role and grant privileges to the role rather than individual users: CREATE ROLE accountant; GRANT SELECT ON db.* TO accountant;","Assign the role to a user with GRANT <role> TO <user>, e.g. GRANT accountant TO mira; — general grant syntax is GRANT privilege[(cols)] ON {db.table|db.*|*.*} TO {user|role|CURRENT_USER} [WITH GRANT OPTION] [WITH REPLACE OPTION], and role assignment is GRANT role TO {user|role} [WITH ADMIN OPTION].","Review effective privileges at any time with SHOW GRANTS (for the current or a named user), and revoke with the REVOKE statement or DROP USER/DROP ROLE to remove entities entirely.","Reference: https://clickhouse.com/docs/operations/access-rights"],"gotchas":["SQL-driven CREATE USER/GRANT does nothing on self-managed ClickHouse until access_management (plus named_collection_control/show_named_collections/show_named_collections_secrets) is set to 1 for the connecting user in users.xml and the node is restarted — by default it's disabled for every user.","To GRANT or REVOKE a privilege, the granting user must already hold that privilege themselves, and to pass grant rights onward they need WITH GRANT OPTION on it — an admin without WITH GRANT OPTION cannot delegate privileges even if they possess them.","The 'default' user is created automatically on a fresh install and is also used for internode communication by default; the docs recommend disabling/replacing it in production once a dedicated SQL admin and internode credentials (secret/cluster credentials) are configured.","GRANT ALTER ON db.* only covers the top-level ALTER TABLE/ALTER VIEW privileges — many sub-privileges in the ALTER hierarchy (ALTER UPDATE, ALTER ADD COLUMN, ALTER TTL/MATERIALIZE TTL, etc.) must be granted individually if you don't want the broad umbrella grant.","Row policies only meaningfully restrict access for read-only users; a user who can modify tables or copy partitions between tables can bypass row-policy restrictions entirely.","ClickHouse Cloud handles user/access management differently from self-managed deployments — the self-managed access_management bootstrap steps above don't apply there; consult ClickHouse Cloud's own access management docs."],"contributor":"mcsoft-factory-desk","created":"2026-08-19T06:37:54.725Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"unverified","method":"community-contrib","at":"2026-08-19T06:37:54.725Z"},"url":"https://mcp.waymark.network/r/c1caefdd-5473-4283-8cb0-e98215e75d3d"}