Summary
The PostgreSQL Grant managed resource currently supports withOption for privilege grants (WITH GRANT OPTION), but has no way to express WITH INHERIT FALSE on role membership grants — a feature introduced in PostgreSQL 16.
Background
PostgreSQL 16 added per-grant inheritance control:
GRANT some_role TO some_user WITH INHERIT FALSE;
This grants membership (the grantee can SET ROLE) without inheriting the role's privileges automatically. It is distinct from WITH GRANT OPTION and cannot be expressed through the existing withOption field.
Use Case
A common Crossplane pattern for RDS PostgreSQL with IAM database authentication:
- Create an
admin role with rds_iam membership (so migration tools like Flyway/Liquibase/Atlas can connect via IAM tokens).
- Grant the RDS master user membership in
admin so it can run ALTER DEFAULT PRIVILEGES FOR ROLE admin.
On PostgreSQL 15, step 2 creates a transitive chain: master_user → admin → rds_iam. This causes the master user's password authentication to break — RDS routes all connections for rds_iam members through PAM (IAM token verification), rejecting the regular password.
On PostgreSQL 16, GRANT admin TO master_user WITH INHERIT FALSE solves this cleanly: the master user has membership (satisfying the ALTER DEFAULT PRIVILEGES requirement) but does not inherit rds_iam and retains password authentication.
Without this field in the Grant CRD, the composition must either omit default privileges management entirely or work around the limitation in ways that push responsibility to the application layer.
Proposed Change
Add a withInherit boolean field to spec.forProvider on the PostgreSQL Grant resource:
apiVersion: postgresql.sql.m.crossplane.io/v1alpha1
kind: Grant
spec:
forProvider:
role: master_user
memberOf: admin
withInherit: false # emits: GRANT admin TO master_user WITH INHERIT FALSE
When withInherit is omitted, behavior is unchanged (PostgreSQL defaults to INHERIT TRUE).
This field should only be applied when memberOf is set (role membership grants). It has no meaning for privilege grants (privileges field).
References
Summary
The PostgreSQL
Grantmanaged resource currently supportswithOptionfor privilege grants (WITH GRANT OPTION), but has no way to expressWITH INHERIT FALSEon role membership grants — a feature introduced in PostgreSQL 16.Background
PostgreSQL 16 added per-grant inheritance control:
GRANT some_role TO some_user WITH INHERIT FALSE;This grants membership (the grantee can
SET ROLE) without inheriting the role's privileges automatically. It is distinct fromWITH GRANT OPTIONand cannot be expressed through the existingwithOptionfield.Use Case
A common Crossplane pattern for RDS PostgreSQL with IAM database authentication:
adminrole withrds_iammembership (so migration tools like Flyway/Liquibase/Atlas can connect via IAM tokens).adminso it can runALTER DEFAULT PRIVILEGES FOR ROLE admin.On PostgreSQL 15, step 2 creates a transitive chain:
master_user → admin → rds_iam. This causes the master user's password authentication to break — RDS routes all connections forrds_iammembers through PAM (IAM token verification), rejecting the regular password.On PostgreSQL 16,
GRANT admin TO master_user WITH INHERIT FALSEsolves this cleanly: the master user has membership (satisfying theALTER DEFAULT PRIVILEGESrequirement) but does not inheritrds_iamand retains password authentication.Without this field in the
GrantCRD, the composition must either omit default privileges management entirely or work around the limitation in ways that push responsibility to the application layer.Proposed Change
Add a
withInheritboolean field tospec.forProvideron the PostgreSQLGrantresource:When
withInheritis omitted, behavior is unchanged (PostgreSQL defaults toINHERIT TRUE).This field should only be applied when
memberOfis set (role membership grants). It has no meaning for privilege grants (privilegesfield).References
GRANTsyntax: https://www.postgresql.org/docs/16/sql-grant.html