risingwavelabs · Copilot · Mar 19, 2026 · Mar 23, 2026 · Mar 25, 2026 · Mar 25, 2026
diff --git a/cloud/cloud-metadata.mdx b/cloud/cloud-metadata.mdx
@@ -0,0 +1,62 @@
+---
+title: "Cloud metadata"
+sidebarTitle: "Cloud metadata"
+description: "View and use the cloud metadata values exposed in the RisingWave Cloud Console, including the IAM role ARN, PrivateLink Principal, and egress public IPs for your project."
+---
+
+RisingWave Cloud exposes a set of environment-specific metadata values for each project. These values are required when setting up cross-account access (IAM role assume) and PrivateLink connections. All values are read-only and are generated automatically when a project is created.
+
+## Where to find cloud metadata
+
+In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Then select the **Cloud Meta** tab.
+
+<Frame>
+<img src="/images/cloud/cloud-metadata/connection-cloud-meta.png" alt="Cloud Meta tab in the Connection page of the RisingWave Cloud Console"/>
+</Frame>
+
+<Note>
+Cloud metadata is only available for projects on the **Standard** plan or above.
+</Note>
+
+## Metadata fields
+
+### Workload Identity (IAM Role ARN)
+
+| Field | Example value |
+|:------|:--------------|
+| **Workload Identity (IAM Role ARN)** | `arn:aws:iam::023339134545:role/g1jk13sq56ejdref71h1cvokbh-role` |
+
+The AWS IAM role ARN that RisingWave Cloud uses to access AWS resources on behalf of this project. When you configure [IAM role assume](/cloud/iam-role-assume) (cross-account S3 access), you add this ARN as a trusted principal in your IAM role's trust policy.
+
+### PrivateLink Principal
+
+| Field | Example value |
+|:------|:--------------|
+| **PrivateLink Principal** | `arn:aws:iam::023339134545:role/test-useast1-eks-a-cloudagent-role` |
+
+The AWS principal associated with the RisingWave Cloud deployment that hosts your project. When you create a PrivateLink endpoint service in your AWS account, add this principal to the list of **Allowed principals** so that RisingWave Cloud can connect to your service.
+
+### Egress public IPs
+
+| Field | Example value |
+|:------|:--------------|
+| **Egress public IPs** | `203.0.113.10, 203.0.113.11` |
+
+The public IP addresses from which outbound traffic from this project originates. Add these IPs to the allowlist of any firewall rules or security groups that restrict inbound access to your services (for example, a database or Kafka cluster that RisingWave connects to).
+
+## Cloud metadata by platform
+
+| Metadata field | AWS | GCP | Azure |
+|:---------------|:----|:----|:------|
+| Workload Identity (IAM Role ARN) | ✅  | ✅ (service account email) | ✅ (managed identity resource ID) |
+| PrivateLink Principal | ✅ (AWS account ARN) | ✅ (GCP project number) | ✅ (Azure subscription ID) |
+| Egress public IPs | ✅  | ✅  | ✅    |
+
+<Note>
+GCP and Azure metadata field names differ from the AWS equivalents. The Console labels each field for the platform of your project.
+</Note>
+
+## Next steps
+
+- [Set up IAM role assume](/cloud/iam-role-assume) — use the IAM role ARN to grant RisingWave Cloud cross-account S3 access.
+- [Configure PrivateLink](/cloud/create-a-connection) — use the PrivateLink Principal when setting up your endpoint service's allowed principals.
diff --git a/cloud/create-a-connection.mdx b/cloud/create-a-connection.mdx
@@ -30,8 +30,8 @@ You need to set up a PrivateLink service in your VPC and make sure it runs prope
 
 ## Create PrivateLink connection
 
-1. Go to the [**Project**](https://cloud.risingwave.com/project/home/) page and select the project you want to connect the VPC to.
-2. Select **PrivateLink** tab, and click **Create PrivateLink**.
+1. In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar.
+2. Select the **PrivateLink** tab, and click **Create PrivateLink**.
 3. For **Name**, enter a descriptive name for the connection.
 4. For **Endpoint service name** or **Service attachment** or **Private link service resource ID:**
 
@@ -85,5 +85,5 @@ For details on how to use the VPC endpoint to create a source with the PrivateLi
 
 When you no longer need a connection:
 
-1. Go to the [**Connection**](https://cloud.risingwave.com/connection/) page and click **Create PrivateLink**.
+1. In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Select the **PrivateLink** tab.
 2. Hover over the connection you want to drop and click the delete button, then confirm the deletion.
diff --git a/cloud/iam-role-assume.mdx b/cloud/iam-role-assume.mdx
@@ -0,0 +1,162 @@
+---
+title: "Set up IAM role assume"
+sidebarTitle: "IAM role assume"
+description: "Configure cross-account S3 access so that RisingWave Cloud can assume an IAM role in your AWS account without sharing long-term credentials."
+---
+
+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](/cloud/cloud-metadata) page in the RisingWave Cloud Console (**Connection** → **Cloud Meta** tab):
+
+| Metadata field | Where 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.
+
+```json 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](https://console.aws.amazon.com/iam/), 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.
+
+```json 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'`.
+
+```sql 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:
+
+```sql 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
+
+| Error | Likely cause | Fix |
+|:------|:-------------|:----|
+| `AccessDenied` when calling `AssumeRole` | The trust policy principal doesn't match the RisingWave Cloud IAM role ARN | Copy the exact **Workload Identity (IAM Role ARN)** from Cloud metadata and update the trust policy |
+| `AccessDenied` on S3 operations after assuming | The attached S3 policy is missing required actions | Add the missing S3 actions (see Step 1) |
+| `InvalidClientTokenId` | Incorrect IAM role ARN in the trust policy | Use 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](https://cloud.risingwave.com), click **Connection** in the left sidebar, and select the **Allowed Principals** tab.
+
+<Frame>
+<img src="/images/cloud/iam-role-assume/connection-allowed-principals.png" alt="Allowed Principals tab in the Connection page of the RisingWave Cloud Console"/>
+</Frame>
+
+Click **+ Add Principal** to add an IAM Role ARN that is allowed to access this project's resources.
+
+## Related pages
+
+- [Cloud metadata](/cloud/cloud-metadata) — retrieve the IAM role ARN for your project
+- [PrivateLink connection configuration](/cloud/create-a-connection) — set up private network connectivity
+- [Sink to Amazon Redshift](/integrations/destinations/redshift) — end-to-end example with S3 staging
+- [Sink to Snowflake](/integrations/destinations/snowflake-v2) — end-to-end example with S3 staging
diff --git a/cloud/privatelink-overview.mdx b/cloud/privatelink-overview.mdx
@@ -29,4 +29,12 @@ All data transmitted through PrivateLink connections is automatically encrypted
 
 On the **RisingWave Cloud** side, RisingWave Cloud will create an endpoint (specifically an AWS VPC endpoint, GCP Private Service Connect endpoint, or Azure private endpoint) and bind it with one running RisingWave project.
 
-On the **Customer** side, you need to set up a PrivateLink service (specifically an AWS endpoint service, GCP published service, or Azure Private Link service) in your VPC network first.
+On the **Customer** side, you need to set up a PrivateLink service (specifically an AWS endpoint service, GCP published service, or Azure Private Link service) in your VPC network first.
+
+## Accessing PrivateLink in the Console
+
+In the [RisingWave Cloud Console](https://cloud.risingwave.com), go to your project and click **Connection** in the left sidebar. Then select the **PrivateLink** tab to create and manage PrivateLink connections.
+
+<Tip>
+When setting up an AWS endpoint service, add the **PrivateLink Principal** from your project's **Cloud Meta** tab ([Cloud metadata](/cloud/cloud-metadata)) to the service's allowed principals list so that RisingWave Cloud can connect.
+</Tip>
diff --git a/docs.json b/docs.json
@@ -525,6 +525,8 @@
                       "cloud/manage-resources",
                       "cloud/manage-database-users",
                       "cloud/manage-backups",
+                      "cloud/cloud-metadata",
+                      "cloud/iam-role-assume",
                       {
                         "group": "PrivateLink",
                         "pages": [

diff --git a/iceberg/object-storage.mdx b/iceberg/object-storage.mdx
@@ -24,7 +24,7 @@ These parameters configure the connection to an S3-compatible storage system, su
 <Note>
 In RisingWave Cloud, you have two options:
 - Provide `s3.access.key` and `s3.secret.key`, or
-- Use IAM role delegation: grant S3 permissions to your own IAM role, allow the RisingWave Cloud tenant role to assume it, then set `s3.iam_role_arn = '<your_role_arn>'` and `enable_config_load = true`. The setup is the same as in the Snowflake sink guide: [Set up S3 IAM and role](/integrations/destinations/snowflake-v2#set-up-s3-iam-and-role).
+- Use IAM role delegation: grant S3 permissions to your own IAM role, allow the RisingWave Cloud tenant role to assume it, then set `s3.iam_role_arn = '<your_role_arn>'` and `enable_config_load = true`. See [Set up IAM role assume](/cloud/iam-role-assume) for a step-by-step guide, including how to retrieve the required IAM role ARN from the [Cloud metadata](/cloud/cloud-metadata) page.
 
 If you use a REST catalog with **vended credentials** (`vended_credentials = true`), you can omit S3 credentials here because the catalog server provides temporary credentials.
 

diff --git a/images/cloud/cloud-metadata/connection-cloud-meta.png b/images/cloud/cloud-metadata/connection-cloud-meta.png
diff --git a/images/cloud/iam-role-assume/connection-allowed-principals.png b/images/cloud/iam-role-assume/connection-allowed-principals.png
diff --git a/integrations/destinations/redshift.mdx b/integrations/destinations/redshift.mdx
@@ -43,17 +43,13 @@ These options only need to be set when `with_s3 = true`:
 | s3.region_name               | AWS region for S3  |
 | s3.bucket_name               | S3 bucket name |
 | s3.path                      | S3 folder path for sink files |
-| enable_config_load           | Load S3 credentials from environment (self-hosted only) |
+| enable_config_load           | Load S3 credentials from environment |
 | s3.credentials.access        | AWS access key ID |
 | s3.credentials.secret        | AWS secret access key |
 | s3.endpoint_url              | Custom S3 endpoint URL (for self-hosted setups) |
 | s3.assume_role               | IAM role ARN to assume for S3 access |
 
 
-<Note>
-In RisingWave Cloud, the default AWS credential provider chain is disabled. Provide `s3.credentials.access` and `s3.credentials.secret` (or use a supported assume-role setup). These credentials cannot be omitted. The `enable_config_load` option is supported only in self-hosted deployments.
-</Note>
-
 ## Auto schema change
 
 <Tip>
@@ -95,9 +91,11 @@ enable_config_load = 'true',
 ```
 
 To use this method, you need to configure an IAM Role in AWS that RisingWave can assume. This involves:
-1. Obtaining the RisingWave service ARN from our [support team](mailto:cloud-support@risingwave-labs.com).
+1. Obtaining the RisingWave Cloud IAM role ARN (**Workload Identity (IAM Role ARN)**) from the [Cloud metadata](/cloud/cloud-metadata) page in the Console (**Connection** → **Cloud Meta** tab).
 2. Creating an IAM policy with the necessary S3 read/write permissions for your bucket and prefix.
-3. Configuring the IAM Role's trust policy to allow the RisingWave service ARN to assume it.
+3. Configuring the IAM Role's trust policy to use the RisingWave Cloud IAM role ARN as the trusted principal.
+
+For a complete step-by-step walkthrough, see [Set up IAM role assume](/cloud/iam-role-assume).
 
 ## Append-only and upsert modes
 

diff --git a/integrations/destinations/snowflake-v2.mdx b/integrations/destinations/snowflake-v2.mdx
@@ -51,7 +51,7 @@ These options only need to be set when `with_s3 = true`:
 | s3.region_name                 | AWS region for S3 |
 | s3.bucket_name                 | S3 bucket name |
 | s3.path                        | S3 folder path for sink files |
-| enable_config_load             | Load S3 credentials from environment (self-hosted only) |
+| enable_config_load             | Load S3 credentials from environment |
 | s3.credentials.access          | AWS access key ID |
 | s3.credentials.secret          | AWS secret access key |
 | s3.endpoint_url                | Custom S3 endpoint URL (for self-hosted setups) |
@@ -167,9 +167,11 @@ enable_config_load = 'true',
 ```
 
 To use this method, you need to configure an IAM Role in AWS that RisingWave can assume. This involves:
-1. Obtaining the RisingWave service ARN from our [support team](mailto:cloud-support@risingwave-labs.com).
+1. Obtaining the RisingWave Cloud IAM role ARN (**Workload Identity (IAM Role ARN)**) from the [Cloud metadata](/cloud/cloud-metadata) page in the Console (**Connection** → **Cloud Meta** tab).
 2. Creating an IAM policy with the necessary S3 read/write permissions for your bucket and prefix.
-3. Configuring the IAM Role's trust policy to allow the RisingWave service ARN to assume it.
+3. Configuring the IAM Role's trust policy to use the RisingWave Cloud IAM role ARN as the trusted principal.
+
+For a complete step-by-step walkthrough, see [Set up IAM role assume](/cloud/iam-role-assume).
 
 ## Append-only and upsert modes
 
@@ -443,7 +445,7 @@ RisingWave supports direct access to S3 using Access Key / Secret Key (AK/SK) by
 }
 ```
 
-2. Configure the following additional trusted entities for your IAM Role to allow RisingWave arn to assume the role. Contact our [support team](mailto:cloud-support@risingwave-labs.com) to obtain the correct role to use. Please don’t click required external id to trust RisingWave arn here.
+2. Configure the following additional trusted entities for your IAM Role to allow RisingWave to assume the role. Obtain the **Workload Identity (IAM Role ARN)** from the [Cloud metadata](/cloud/cloud-metadata) page (**Connection** → **Cloud Meta** tab). See [Set up IAM role assume](/cloud/iam-role-assume) for a complete walkthrough.
 
 ```json Example
 {