CXH-1584: Surface database-level access in redshift connector#134
Conversation
The database connect entitlement was always empty: Redshift's
svv_database_privileges never emits CONNECT, only TEMP/USAGE/CREATE
granted to named principals or PUBLIC. The grant query filtered on
CONNECT and the map only handled user/role/group identity types.
Rename the entitlement to access (which matches what it actually
represents), widen the query to privilege_type IN ('TEMP', 'USAGE',
'CREATE'), and update the three map entries' entitlement_id. Keep
immutable: true until per-privilege provisioning is validated end to
end. PUBLIC rows are intentionally skipped here; modeling PUBLIC needs
a synthetic principal and is tracked as a follow-up.
Verified against the local stub: grants now emit
database:dev:access:user:alice, database:dev:access:group:analysts,
and database:analytics:access:role:editor, with PUBLIC rows skipped.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| SELECT database_name, privilege_type, identity_name, identity_type | ||
| FROM svv_database_privileges | ||
| WHERE privilege_type = 'CONNECT' | ||
| WHERE privilege_type IN ('TEMP', 'USAGE', 'CREATE') |
There was a problem hiding this comment.
🟡 Suggestion: The IN ('TEMP', 'USAGE', 'CREATE') filter can return up to three rows per (principal, database) pair, and all three map to the single access entitlement. This will create duplicate grants for the same principal+entitlement when a user holds more than one of these privileges. Consider deduplicating with SELECT DISTINCT identity_name, identity_type, database_name (dropping privilege_type from the SELECT) so each principal gets one grant per database.
| purpose: permission | ||
| grantable_to: [user] | ||
| slug: connect | ||
| slug: access |
There was a problem hiding this comment.
🟡 Suggestion: Renaming the entitlement slug from connect to access is a B2 breaking change — any existing deployments that had synced grants under the old slug would see those grants disappear and new ones appear under access. The PR description asserts svv_database_privileges never actually emitted CONNECT rows, so no grants would have been synced. If that's confirmed, this is safe. Worth a note in the PR description that this is intentionally not backwards-compatible.
svv_database_privileges emits one row per (principal, database, privilege_type), so a principal holding TEMP+USAGE+CREATE produced three identical grants (same principal, same `access` entitlement, same database). The c1z store dedups them on write via the unique index on (external_id, sync_id), so the end state was correct, but the connector still spent cycles emitting and serializing the duplicates. Switch the SELECT to DISTINCT on (identity_name, identity_type, database_name) so a principal contributes exactly one row regardless of how many of TEMP/USAGE/CREATE they hold.
…abase-level-access # Conflicts: # examples/redshift-test.yml
4 participants
Redshift database-level access now shows up correctly in C1; the connector now reads the privilege types Redshift actually emits (TEMP, USAGE, CREATE) on each database, instead of an alias the underlying view does not use.