Skip to main content
IAM role assume (also called cross-account role delegation) lets RisingWave Cloud call sts:AssumeRole to obtain temporary credentials for your AWS IAM role. This avoids storing long-term access keys and follows AWS security best practices. Use this method when you want RisingWave Cloud to read from or write to an S3 bucket in your AWS account using a role you control.

​
How it works

RisingWave Cloud (AWS account: <rw-account-id>)
  → calls sts:AssumeRole
  → on: arn:aws:iam::<your-account-id>:role/<your-role>
  → receives temporary credentials
  → accesses your S3 bucket
  1. You create an IAM role in your AWS account with the required S3 permissions.
  2. You configure the role’s trust policy to allow RisingWave Cloud’s IAM role ARN to assume it.
  3. You set s3.assume_role (or s3.iam_role_arn) in your RisingWave SQL statement to the ARN of your role.

​
Required cloud metadata values

Before you begin, retrieve the following values from your project’s Cloud metadata page in the RisingWave Cloud Console (Connection → Cloud Meta tab):
Metadata fieldWhere it’s used
Workload Identity (IAM Role ARN)The Principal.AWS value in your IAM trust policy

​
Step-by-step setup

​
Step 1 — Create an IAM policy for S3 access

Create a policy that grants RisingWave the necessary permissions on your S3 bucket. Replace <bucket> and <prefix> with your values.
Example: S3 read/write policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion"
            ],
            "Resource": "arn:aws:s3:::<bucket>/<prefix>/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::<bucket>",
            "Condition": {
                "StringLike": {
                    "s3:prefix": ["<prefix>/*"]
                }
            }
        }
    ]
}

​
Step 2 — Create an IAM role with the policy attached

  1. In the AWS IAM console, create a new role.
  2. Select Another AWS account as the trusted entity type and enter the AWS account ID extracted from the Workload Identity (IAM Role ARN) (the 12-digit number after iam::).
  3. Attach the S3 policy created in Step 1.

​
Step 3 — Configure the trust policy

After the role is created, update its trust policy to allow the specific RisingWave Cloud IAM role to assume it. Replace <iam-role-arn> with the Workload Identity (IAM Role ARN) from Cloud metadata.
Example: Trust policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "<iam-role-arn>"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

​
Step 4 — Use the role in RisingWave

Set s3.assume_role to the ARN of the role you created in Step 2 and set enable_config_load = 'true'.
Example: Sink using IAM role assume
CREATE SINK my_sink FROM my_source WITH (
    connector = 'redshift',             -- or 'snowflake_v2', 'iceberg', etc.

    -- S3 staging
    s3.bucket_name    = '<your-bucket>',
    s3.region_name    = '<your-region>',
    s3.path           = '<your-prefix>',

    -- IAM role assume (no long-term credentials needed)
    s3.assume_role    = 'arn:aws:iam::<your-account-id>:role/<your-role>',
    enable_config_load = 'true',

    -- other connector-specific parameters...
);
For connectors that use s3.iam_role_arn instead of s3.assume_role (for example, the Iceberg connector), use:
Example: Iceberg connector with IAM role assume
CREATE SINK my_iceberg_sink FROM my_mv WITH (
    connector = 'iceberg',
    type      = 'append-only',
    -- ...
    s3.iam_role_arn    = 'arn:aws:iam::<your-account-id>:role/<your-role>',
    enable_config_load = 'true',
);

​
Verify the setup

After creating the sink or source, run a quick sanity check:
  1. Check that the role is assumable — in the AWS console, use IAM → Roles → <your-role> → Trust relationships to confirm the correct principal and condition are present.
  2. Check S3 permissions — run an aws s3 ls s3://<bucket>/<prefix>/ command using the role (via aws sts assume-role) to verify read access.
  3. Check RisingWave logs — if the sink or source fails, look for AccessDenied or InvalidClientTokenId errors. These indicate a misconfigured trust policy or incorrect ARN.

​
Common errors

ErrorLikely causeFix
AccessDenied when calling AssumeRoleThe trust policy principal doesn’t match the RisingWave Cloud IAM role ARNCopy the exact Workload Identity (IAM Role ARN) from Cloud metadata and update the trust policy
AccessDenied on S3 operations after assumingThe attached S3 policy is missing required actionsAdd the missing S3 actions (see Step 1)
InvalidClientTokenIdIncorrect IAM role ARN in the trust policyUse the Workload Identity (IAM Role ARN) from Cloud metadata

​
Managing allowed principals in RisingWave Cloud

To view and manage the IAM role ARNs that are authorized to access your project’s resources via IAM Assume Role, go to your project in the RisingWave Cloud Console, click Connection in the left sidebar, and select the Allowed Principals tab.
Allowed Principals tab in the Connection page of the RisingWave Cloud Console
Click + Add Principal to add an IAM Role ARN that is allowed to access this project’s resources.