Skip to main content
Nuphos reaches Alibaba Cloud through OIDC web-identity federation. You create a RAM identity provider that trusts the Nuphos issuer and a role that trusts that provider; Nuphos mints a short-lived token per team and calls sts:AssumeRoleWithOIDC. No AccessKeyId/AccessKeySecret is stored. Nuphos keeps the role ARN and the OIDC provider ARN, both of which the exchange requires.
Pick your partition when you connect: China (ram.console.aliyun.com) or International (ram.console.alibabacloud.com).

​
Connect

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

​
1. Add the identity provider

In the RAM console, create an OIDC identity provider using the issuer URL and client id from the wizard. Alibaba Cloud fetches the issuer’s JWKS itself, so there is no key to paste. Copy the provider’s ARN.

​
2. Create the role

Create a role with trusted entity IdP → OIDC and pick the provider you just added. The console generates the trust policy for you; add a condition on oidc:sub equal to the subject the wizard shows — that is what pins the role to your team, so no other Nuphos team can assume it. Attach a policy covering the work you want done (ACK, ECS, SWAS as needed) and copy the role’s ARN. The finished trust policy should look like this. <account-id> and <provider-name> come from the provider ARN you copied in step 1; <issuer>, <client-id>, and <subject> are the three values the wizard shows — copy them verbatim rather than typing them by hand:
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 Nuphos calls, not a trust-policy action. Changing the action to sts:AssumeRoleWithOIDC makes STS reject the exchange and the bind fails. Likewise, do not remove the oidc:sub condition — without it, any Nuphos team could assume the role.

​
3. Bind the role

Enter both ARNs in Nuphos.

​
In the Nuphos app

  • ECS instances and SWAS instances — the account’s compute.
  • Clusters — ACK 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

ACK API access and the cluster’s Kubernetes RBAC permissions are separate. 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.