Docs / Clouds
Alibaba Cloud
Connect an Alibaba Cloud account with RAM OIDC federation, with no AccessKey to store.
Pangea reaches Alibaba Cloud through OIDC web-identity federation. You create a RAM identity provider that trusts the Pangea issuer and a role that trusts that provider. Pangea mints a short-lived token for your team and calls sts:AssumeRoleWithOIDC.
No AccessKeyId or AccessKeySecret is stored. Pangea keeps the role ARN and the OIDC provider ARN. The exchange needs both.
Pick your site when you connect: China (ram.console.aliyun.com) or International (ram.console.alibabacloud.com).
Connect
The dialog in Connectors → Connect → Alibaba Cloud walks through these steps. If the aliyun CLI is installed on your Mac, it also offers a guided setup where the agent runs it for you.
1. Add the identity provider
In the RAM console, open Identity Providers and create an OIDC identity provider:
| Field | Value |
|---|---|
| Issuer URL | https://api.pangea.build |
| Client ID | sts.aliyuncs.com |
Alibaba Cloud fetches the issuer's signing keys itself, so there is no key to paste. Create the provider, then copy its ARN.
2. Create the role
In the RAM console, open Roles → Create Role. Choose trusted entity IdP → OIDC and pick the provider you just added. The console generates the trust policy. Add a condition on oidc:sub equal to your team's subject, which you copy from the dialog in Pangea. That condition pins the role to your team, so no other Pangea team can assume it.
Attach a policy covering the work you want done. For ACK and ECS, use AliyunCSFullAccess with AliyunECSReadOnlyAccess, or AdministratorAccess for a dedicated account. Add SWAS permissions if you need them. Create the role, then open it and copy its ARN.
The finished trust policy looks like this. <account-id> and <provider-name> come from the provider ARN you copied in step 1. Copy <team-subject> from the dialog verbatim:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": ["acs:ram::<account-id>:oidc-provider/<provider-name>"]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"oidc:iss": "https://api.pangea.build",
"oidc:aud": "sts.aliyuncs.com",
"oidc:sub": "<team-subject>"
}
}
}
]
}
Keep "Action": "sts:AssumeRole" exactly as the console generates it. In Alibaba Cloud RAM, sts:AssumeRole is the only action a trust policy grants to an OIDC provider. AssumeRoleWithOIDC is the name of the STS API Pangea calls, not a trust-policy action. If you change the action to sts:AssumeRoleWithOIDC, STS rejects the exchange and the bind fails. Also keep the oidc:sub condition. Without it, any Pangea team could assume the role.
3. Bind the role
Enter a label, the role ARN (for example acs:ram::123456789012345:role/PangeaConnector) and the OIDC provider ARN (for example acs:ram::123456789012345:oidc-provider/pangea) in Pangea.
In the Pangea app
- ECS instances and SWAS instances: the account's compute.
- Clusters: ACK clusters appear in the shared cluster browser, next to EKS, GKE and the rest.
What the agent can do for you
The agent operates the account within the policy you attached to the role. It correlates it with your other connected accounts and proposes changes as plans.
Permissions and authorization
Team Administrators connect and remove this binding and can restrict it with a member allow-list. Select the connection for the conversation before you ask the agent to use it. The role's policy stays the outer limit, whatever the prompt or permission mode.
Individual actions follow Auto Mode and Full Access. Significant cloud infrastructure work uses plans. A routine API action does not create a plan on its own, so say so explicitly when you want to review changes first.
Verify cluster access
ACK API access and the cluster's Kubernetes RBAC are separate.
- Read the expected account and cluster metadata.
- Then check a bounded namespace or workload read in that cluster.
A successful account-level listing does not prove that pod logs, exec or writes are allowed. For a denial, find out whether cloud IAM, network reachability or in-cluster RBAC is blocking it before you ask an administrator for a scoped change. Never fix a read failure by granting cluster-admin blindly.