Skip to main content
Nuphos reaches Volcengine (火山引擎) through OIDC web-identity federation. You register Nuphos as an IAM identity provider, create a role that trusts it, and Nuphos mints a short-lived token per team and calls sts:AssumeRoleWithOIDC. No access key is stored. Nuphos keeps only the role’s TRN.

​
Connect

The wizard in Connectors → Connect → Volcengine shows the issuer and client id for your team. Copy them from there.

​
1. Add the identity provider

In the IAM console, create an OIDC identity provider with the issuer URL and client id from the wizard.

​
2. Create the role

Create a role that trusts that provider, conditioned on the subject the wizard shows — that pins the role to your team. Attach a policy covering the work you want done (VKE and ECS, typically), then copy the role’s TRN. It looks like trn:iam::2100000000:role/Nuphos.

​
3. Authorize cluster access

VKE grants cluster access per region, so repeat the in-cluster authorization for each region that has clusters you want the agent to reach.

​
4. Bind the role

Enter the TRN in Nuphos.

​
In the Nuphos app

  • ECS instances — the account’s compute.
  • Clusters — VKE clusters land in the shared cluster browser alongside EKS, GKE, and the rest.

​
What the agent can do for you

The agent operates the account within whatever policy you attached to the role, correlating it with your other connected accounts and proposing changes as plans.

​
Permissions & authorization

Team Administrators connect and remove this binding and can restrict it with a member allow-list. Select the connection for the conversation before asking the agent to use it. Provider permissions remain the outer limit, regardless of the prompt or permission mode. Individual actions follow Auto Mode and Full Access. Significant cloud infrastructure work uses plans; a ticket, repository write or routine API action does not automatically create a plan. Give explicit instructions about reviewing changes before publishing when that is the workflow you need.

​
Verify cluster access

Check the VKE region explicitly; cluster authorization must cover each intended region. First read the expected account and cluster metadata, then verify a bounded namespace or workload read in that cluster. An account-level listing succeeding does not prove pod logs, exec or writes are authorized. For a denial, identify whether cloud IAM, network reachability or in-cluster RBAC is blocking it before asking an administrator for a scoped change. Never solve a read failure by blindly granting cluster-admin.