Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
changefeedccl: add new fine grained permissions
This change updates permissions semantics related to creating and managing changefeeds. The `CONTROLCHANGEFEED` role option will be deprecated in the future (see cockroachdb#94757). With this change, usages of `CONTROLCHANGEFEED` will come with a deprecation warning. Its existing behavior (see rules for creating changefeeds below) remains the same. The `SELECT` and `CHANGEFEED` privileges will be used for changefeeds henceforth: The `SELECT` privilege on a set of tables allows a user to run core changefeeds against them. The `CHANGEFEED` privilege on a set of tables allows a user to run enterprise changefeeds on them, and also manage the underlying changefeed job (ie. view, pause, cancel, and resume the job). Notably, a new cluster setting `changefeed.permissions.enforce_external_connections` is added and set to `false` by default. Enabling this setting restricts users with `CHANGEFEED` on a set of tables to create enterprise changefeeds into external connections only. To use a given external connection, a user typically needs the `USAGE` privilege on it. Note `ALTER DEFAULT PRIVILEGES` can be used with both the `CHANGEFEED` and `SELECT` privileges to assign course-grained permissions (ie. assign permissions to all tables in a schema rather than manually assign them for each table). Before this change, to create a changefeed, these checks were made in order: (a) If the user has the `CONTROLCHANGEFEED` role, then they require the `SELECT`privilege on all targeted tables (b) Otherwise, the user requires the `CHANGEFEED` privilege on all targeted tables With this change, these checks are updated: (a) If the user has the `CONTROLCHANGEFEED` role, then they require the `SELECT` privilege on all targeted tables. Note: creating a changefeed this way will now produce a deprecation notice. (b) If the changefeed is a core changefeed, they require the `SELECT` privilege on all targeted tables (c) Otherwise, the user requires the `CHANGEFEED` privilege on all targeted tables. Note: If `changefeed.permissions.enforce_external_connections` (disabled by default) is set to true, then the user will only be able to create a changefeed into an external connection which they have the `USAGE` privilege on. Before this change, to manage a changefeed job `J` (defined a viewing, pausing, resuming, and canceling), a user `U` could do so if they met at least one of the following conditions: (a) `U` is an admin (b) `U` is not an admin and `J` is owned by `U` (only for SHOW JOBS) (c) `U` is not an admin, `J` is not owned by an admin, and `U` has the `CONTROLJOB` role With this change, the conditions are updated: (a) `U` is an admin (b) `U` is not an admin and `J` is owned by `U` (only for `SHOW JOBS` or `SHOW CHANGEFEED JOBS`) (c) `U` is not an admin, `J` is not owned by an admin, and `U` has the `CONTROLJOB` role (d) `U` is not an admin, `J` is not owned by an admin, `J` is a changefeed job, and `U` has the `CHANGEFEED` privilege on targeted tables Before this change, permissions related to altering changefeeds with `ALTER CHANGEFEED` were not explicitly defined (we did not have tests to assert its behavior, but there were some permissions checks regardless). Basically, a user needed access to view a job (ie. look up it’s job ID via `SHOW JOBS`) and they needed to be able to create a new job. After all, `ALTER CHANGEFEED` is essentially the same as creating a new job after stopping the old one. With this change, the same rules apply: the user needs to be able to access the existing job and to be able to create a new changefeed with the new rules introduced in this change respectively. Fixes: cockroachdb#94756 Fixes: cockroachdb#92261 Fixes: cockroachdb#87884 Fixes: cockroachdb#85082 Fixes: cockroachdb#94759 Informs: cockroachdb#94757 Epic: CRDB-19709 Release note (enterprise change): The `CONTROLCHANGEFEED` role option will be deprecated in the future (see cockroachdb#94757). With this change, usages of `CONTROLCHANGEFEED` will come with a deprecation warning. Its existing behavior (see rules for creating changefeeds above) remains the same. The `SELECT` and `CHANGEFEED` privileges will be used for changefeeds henceforth: The `SELECT` privilege on a set of tables allows a user to run core changefeeds against them. The `CHANGEFEED` privilege on a set of tables allows a user to run enterprise changefeeds on them, and also manage the underlying changefeed job (ie. view, pause, cancel, and resume the job). Notably, a new cluster setting `changefeed.permissions.enforce_external_connections` is added and set to `false` by default. Enabling this setting restricts users with `CHANGEFEED` on a set of tables to create enterprise changefeeds into external connections only. To use a given external connection, a user typically needs the `USAGE` privilege on it. Note `ALTER DEFAULT PRIVILEGES` can be used with both both the `CHANGEFEED` and `SELECT` privileges to assign coarse-grained permissions (ie. assign permissions to all tables in a schema rather than manually assign them for each table).
- Loading branch information