docs: address review comments on cloud-metadata page

Copilot · cyberchen98 · wjf3121 · commit 634e61f9eff6 · 2026-03-26T12:02:04.000+08:00
Co-authored-by: cyberchen98 <44337247+cyberchen98@users.noreply.github.com> Agent-Logs-Url: https://github.com/risingwavelabs/risingwave-docs/sessions/5bfb5281-ddfc-49e3-806e-fdf46d303614
diff --git a/cloud/cloud-metadata.mdx b/cloud/cloud-metadata.mdx
@@ -1,7 +1,7 @@
 ---
 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, external ID, account ID, VPC ID, and region for your project."
+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.
@@ -24,53 +24,35 @@ Cloud metadata is only available for projects on the **Standard** plan or above.
 
 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.
 
-### External ID
+### PrivateLink Principal
 
 | Field | Example value |
 |:------|:--------------|
-| **External ID** | `rwc-project-abc123-ext` |
+| **PrivateLink Principal** | `arn:aws:iam::123456789012:root` |
 
-A unique identifier for this project. Use it as the `sts:ExternalId` condition in your IAM trust policy to prevent [confused deputy attacks](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). Including an external ID is strongly recommended for production setups.
+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.
 
-### AWS account ID
+### Egress public IPs
 
 | Field | Example value |
 |:------|:--------------|
-| **AWS account ID** | `123456789012` |
+| **Egress public IPs** | `203.0.113.10, 203.0.113.11` |
 
-The AWS account ID associated with the RisingWave Cloud deployment that hosts your project. This is the account that issues `sts:AssumeRole` calls when assuming your IAM role.
-
-### Region
-
-| Field | Example value |
-|:------|:--------------|
-| **Region** | `us-east-1` |
-
-The AWS region in which this project runs. When creating PrivateLink connections, your VPC and PrivateLink service must be in the same region as the project.
-
-### VPC ID
-
-| Field | Example value |
-|:------|:--------------|
-| **VPC ID** | `vpc-0abc123def456gh78` |
-
-The VPC ID of the network associated with this project. Some PrivateLink endpoint service configurations (for example, when restricting which VPCs can connect) require this value.
+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 |
 |:---------------|:----|:----|:------|
 | IAM role ARN   | ✅  | ✅ (service account email) | ✅ (managed identity resource ID) |
-| External ID    | ✅  | —   | —     |
-| Account ID     | ✅ (AWS account ID) | ✅ (GCP project ID) | ✅ (Azure subscription ID) |
-| Region         | ✅  | ✅  | ✅    |
-| VPC ID         | ✅  | ✅ (VPC network name) | ✅ (VNet 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 and external ID to grant RisingWave Cloud cross-account S3 access.
-- [Configure PrivateLink](/cloud/create-a-connection) — use the region and VPC ID when creating PrivateLink connections.
+- [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
@@ -23,15 +23,6 @@ You need to create a project with the Standard plan or Advanced plan in RisingWa
    * See [Choose a project plan](/cloud/choose-a-project-plan/) for more information. Please note that Trial projects do not support PrivateLink connections.
    * The VPC you want to connect to and your project must be in the same region. If your preferred region is not available when creating a project, contact our [support team](mailto:cloud-support@risingwave-labs.com) or [sales team](mailto:sales@risingwave-labs.com).
 
-### Required cloud metadata
-
-Before you set up PrivateLink, retrieve the following values from your project's [Cloud metadata](/cloud/cloud-metadata) page (**Settings** → **Cloud metadata**):
-
-| Metadata field | Where it's used |
-|:---------------|:----------------|
-| **Region** | Confirm that your VPC and PrivateLink service are in the same region as the project |
-| **VPC ID** | Required if your endpoint service restricts which VPCs can connect |
-
 You need to set up a PrivateLink service in your VPC and make sure it runs properly. The following links might be helpful:
    * For AWS, see [Share your services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html).
    * For GCP, see [GCP Published services](https://cloud.google.com/vpc/docs/about-vpc-hosted-services).
diff --git a/cloud/iam-role-assume.mdx b/cloud/iam-role-assume.mdx
@@ -29,8 +29,6 @@ Before you begin, retrieve the following values from your project's [Cloud metad
 | Metadata field | Where it's used |
 |:---------------|:----------------|
 | **IAM role ARN** | The `Principal.AWS` value in your IAM trust policy |
-| **External ID** | The `sts:ExternalId` condition value in your IAM trust policy (recommended) |
-| **AWS account ID** | Verify that `sts:AssumeRole` calls originate from the correct RisingWave Cloud account |
 
 ## Step-by-step setup
 
@@ -73,17 +71,16 @@ Create a policy that grants RisingWave the necessary permissions on your S3 buck
 ### 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.
-3. Enter the **AWS account ID** from Cloud metadata as the trusted account.
-4. Attach the S3 policy created in Step 1.
+2. Select **Another AWS account** as the trusted entity type and enter the AWS account ID extracted from the **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. Include the external ID as a condition.
+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 **IAM role ARN** from Cloud metadata, and `<external-id>` with the **External ID** from Cloud metadata.
+Replace `<iam-role-arn>` with the **IAM role ARN** from Cloud metadata.
 
-```json Example: Trust policy with external ID
+```json Example: Trust policy
 {
     "Version": "2012-10-17",
     "Statement": [
@@ -92,25 +89,12 @@ Replace `<iam-role-arn>` with the **IAM role ARN** from Cloud metadata, and `<ex
             "Principal": {
                 "AWS": "<iam-role-arn>"
             },
-            "Action": "sts:AssumeRole",
-            "Condition": {
-                "StringEquals": {
-                    "sts:ExternalId": "<external-id>"
-                }
-            }
+            "Action": "sts:AssumeRole"
         }
     ]
 }
 ```
 
-<Warning>
-Always include the `sts:ExternalId` condition. Without it, any entity in the trusted account can assume your role — this is the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
-</Warning>
-
-<Note>
-The `sts:ExternalId` value is a project-specific string. If you delete and recreate your project or create a new project, update this value accordingly.
-</Note>
-
 ### 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'` (RisingWave Cloud only).
@@ -158,12 +142,11 @@ After creating the sink or source, run a quick sanity check:
 |:------|:-------------|:----|
 | `AccessDenied` when calling `AssumeRole` | The trust policy principal doesn't match the RisingWave Cloud IAM role ARN | Copy the exact 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 AWS account ID in the trust policy | Use the AWS account ID from Cloud metadata |
-| External ID mismatch | The `sts:ExternalId` in the trust policy doesn't match Cloud metadata | Copy the exact External ID from Cloud metadata |
+| `InvalidClientTokenId` | Incorrect IAM role ARN in the trust policy | Use the IAM role ARN from Cloud metadata |
 
 ## Related pages
 
-- [Cloud metadata](/cloud/cloud-metadata) — retrieve the IAM role ARN and external ID for your project
+- [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
@@ -32,5 +32,5 @@ On the **RisingWave Cloud** side, RisingWave Cloud will create an endpoint (spec
 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.
 
 <Tip>
-Before you configure PrivateLink, retrieve your project's **Region** and **VPC ID** from the [Cloud metadata](/cloud/cloud-metadata) page. Your VPC and PrivateLink service must be in the same region as the project.
+When setting up an AWS endpoint service, add the **PrivateLink Principal** from your project's [Cloud metadata](/cloud/cloud-metadata) page to the service's allowed principals list so that RisingWave Cloud can connect.
 </Tip>
