Tencent Cloud

Nuphos reaches Tencent Cloud through OIDC web-identity federation. You create a CAM 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:AssumeRoleWithWebIdentity. No SecretId/SecretKey is stored. Nuphos keeps the role ARN and the OIDC provider’s name — Tencent references providers by name, not ARN.

​

Connect

The wizard in Connectors → Connect → Tencent Cloud shows the values for your team — issuer, client id, subject, and the public key. Copy them from there, not from this page.

​

1. Add the identity provider

In the CAM console, open Identity Providers → Role SSO and create an OIDC provider with the issuer URL, client id, and public key the wizard gives you. Unlike AWS and Azure, Tencent does not fetch the issuer’s JWKS itself, so the wizard hands you the public key to paste. If Nuphos rotates its signing key, this provider has to be updated.

​

2. Create the role

Create a role that trusts the provider you just made, conditioned on the subject the wizard shows — that is what locks the role to your team, so no other Nuphos team can assume it. Attach a policy covering the work you want done (TKE and CVM, typically). Copy the role’s ARN; the last step asks for it.

​

3. Authorize cluster access (optional)

Tencent’s IAM only covers the control plane. To let the role act inside your TKE clusters, grant it access in each cluster as well. Skip this if you only want the agent to see cluster metadata.

​

4. Bind the role

Enter the role ARN and the provider name in Nuphos.

​

In the Nuphos app

• CVM instances — the account’s compute instances.
• Clusters — TKE 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

TKE control-plane IAM and per-cluster Kubernetes authorization 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.