Skip to content

fix: grant AWS SQLWorkspace S3 and RDS vendor permissions - #152

Open
mattisonchao wants to merge 7 commits into
streamnative:mainfrom
mattisonchao:fix/aws-sqlworkspace-vendor-permissions
Open

fix: grant AWS SQLWorkspace S3 and RDS vendor permissions#152
mattisonchao wants to merge 7 commits into
streamnative:mainfrom
mattisonchao:fix/aws-sqlworkspace-vendor-permissions

Conversation

@mattisonchao

@mattisonchao mattisonchao commented Aug 13, 2026

Copy link
Copy Markdown
Member

Motivation

AWS v2 SQLWorkspace provisioning runs through StreamNativeCloudBootstrapRole. The
bootstrap policy and permission boundary scoped the vendor role to S3, so the new
deterministic SQLWorkspace resources cannot be provisioned:

  • The deterministic rw-* state-store bucket cannot be created or configured with the
    existing bucket pattern.
  • The sqlworkspace-rds-* PostgreSQL meta store (RisingWave meta node backend) cannot
    be created: rds:CreateDBSubnetGroup / rds:CreateDBInstance are denied by both the
    attached policy and the permission boundary.

This change grants the least-privilege S3 and RDS operations required by the AWS v2
SQLWorkspace modules, scoped to StreamNative-tagged resources.

Companion implementation: streamnative/argo#1612.

Modifications

  • Grant bucket-level provisioning and configuration permissions for deterministic
    SQLWorkspace buckets matching rw-*-${account_id}-${region}-*.
  • Grant scoped RDS permissions for sqlworkspace-rds-* resources: create instance and
    subnet group (postgres engine, private, encrypted, Vendor=StreamNative tagged),
    manage/delete, final snapshot, and tags.
  • Allow rds:Describe* so the terraform provider can query engine versions and
    instance state while provisioning.
  • Allow the bootstrap role to create and manage the per-poolmember tiered-storage
    buckets produced by terraform-aws-cloud (<pm>-tiered-storage-snc), and the runtime
    role to read/write them; the existing s3_bucket_pattern (typically snc-*) does
    not match these names, so a brand-new poolmember fails at provision1 with
    s3:CreateBucket AccessDenied before SQLWorkspace provisioning even starts.
  • Pass the configured AWS region into the bootstrap-policy template.
  • Document S3 and RDS as bootstrap-role capabilities.

Testing

  • terraform validate -no-color passes in modules/aws/vendor-access.
  • Rendered policies parse as JSON with representative AWS inputs (account, region,
    bucket pattern, R53 zones).
  • Applied to the test account (598203581484): provision-policy v3 and permission
    boundary v48; the SQLWorkspace RDS E2E then proceeds past IAM denials.
  • Fresh poolmember E2E (streamnative/argo#1612, CE aws-usw1-dev-issue1612 in
    o-for6u) reproduces the s3:CreateBucket AccessDenied on
    aws-usw1-dev-issue1612-tiered-storage-snc at provision1; rendered policies with
    the added *-tiered-storage-snc resource parse as JSON and cover the bucket.

After release, existing AWS BYOC environments must apply the updated vendor-access
module before SQLWorkspace S3/RDS allocation is enabled.

@mattisonchao
mattisonchao requested a review from a team as a code owner August 13, 2026 05:02
@mattisonchao mattisonchao changed the title fix: grant AWS SQLWorkspace vendor permissions fix: grant AWS SQLWorkspace S3 vendor permissions Aug 13, 2026
The argo AWS v2 workflow provisions an RDS instance as the RisingWave
meta store (sqlworkspace-rds-* resources tagged Vendor=StreamNative).
Add scoped RDS create/manage/final-snapshot permissions to the
StreamNativeCloudProvisionPreservePolicy and the permission boundary,
mirroring the existing least-privilege SQLWorkspace S3 statements.
The upbound terraform provider queries engine versions and instance state
while provisioning; broaden the RDS grant from specific Describe actions to
rds:Describe* in the bootstrap policy and permission boundary.
@mattisonchao mattisonchao changed the title fix: grant AWS SQLWorkspace S3 vendor permissions fix: grant AWS SQLWorkspace S3 and RDS vendor permissions Aug 14, 2026
The vendor-access S3 scope (s3_bucket_pattern, typically "snc-*") does not match the per-poolmember tiered-storage bucket names produced by terraform-aws-cloud's dns-bucket module (<pm>-tiered-storage-snc). Creating a new poolmember therefore fails at provision1 with s3:CreateBucket AccessDenied, before SQLWorkspace provisioning even starts.

- provision_preserve: allow s3:CreateBucket and bucket management on *-tiered-storage-snc alongside the configured bucket pattern
- runtime_iam_policy: allow ListBucket and object access on *-tiered-storage-snc alongside the configured bucket pattern
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant