Docs / Clouds
Volcengine
Connect a Volcengine (火山引擎) account with OIDC federation, with no access key to store.
Pangea reaches Volcengine (火山引擎) through OIDC web-identity federation. You register Pangea as an IAM identity provider and create a role that trusts it. Pangea mints a short-lived token for your team and calls sts:AssumeRoleWithOIDC.
No access key is stored. Pangea keeps only the role's TRN.
Connect
The dialog in Connectors → Connect → Volcengine walks through these steps. If the Volcengine CLI (ve or volcengine-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 Volcengine console, open IAM → Identity Providers. Add an OIDC provider with SSO type Role SSO:
| Field | Value |
|---|---|
| Issuer URL | https://api.pangea.build |
| Fingerprint | Click Get it now |
| Client ID | sts.volcengineapi.com |
| Min Issue Time | Leave the default |
Then click Submit.
2. Create the role
Open IAM → Roles → Create Role. Choose trust identity Identity provider → OIDC and pick the provider you just added.
Add a condition to the role's trust policy that pins it to your team's subject. Copy the subject from the dialog in Pangea.
The dialog lists the subject condition as optional. Add it anyway. It is what pins the role to your team. Without it, any Pangea team that knows your role TRN could assume the role.
Attach a policy covering the work you want done. For VKE and ECS, use VKEFullAccess, or AdministratorAccess for a dedicated account. Create the role, then open it and copy its TRN. It looks like trn:iam::2100000000:role/Pangea.
3. Authorize cluster access
IAM only covers the control plane. To let the role act inside your VKE clusters:
- In the VKE console, open Authorizations → Role authorization.
- Sign in as the cluster creator or root account. Only they can grant in-cluster RBAC.
- Enter the exact role name from step 2, then continue.
- Click Add role authorization. Pick your clusters (or Account All Resources), a namespace scope and an access right. Read-only is enough for browsing.
- Repeat for each region that has clusters. VKE grants access per region.
Skip this step if you have no clusters, or only want ECS. Clusters still bind without it, but their contents stay forbidden, and Pangea shows this same guidance when you open one.
4. Bind the role
Enter a label and the role TRN in Pangea.
In the Pangea app
- ECS instances: the account's compute.
- Clusters: VKE 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
Check the VKE region explicitly. Cluster authorization must cover each region you intend to use.
- 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.