Docs / Clouds
Tencent Cloud
Connect a Tencent Cloud account with OIDC role SSO, with no SecretId or SecretKey to store.
Pangea reaches Tencent Cloud through OIDC web-identity federation. You create a CAM 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:AssumeRoleWithWebIdentity.
No SecretId or SecretKey is stored. Pangea keeps the role ARN and the OIDC provider's name. Tencent references providers by name, not by ARN.
Pick your site when you connect: China (console.cloud.tencent.com) or International (console.tencentcloud.com). They are separate accounts with separate consoles, and the site must match the account.
Connect
The dialog in Connectors → Connect → Tencent Cloud walks through these steps. If tccli 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 CAM console, open Identity Providers → Role SSO and create an OIDC identity provider:
| Field | Value |
|---|---|
| Issuer URL | https://api.pangea.build |
| Client ID | sts.tencentcloudapi.com |
| Public key | Copy it from the dialog in Pangea. |
Note the provider's name. The last step asks for it.
Unlike AWS and Azure, Tencent does not fetch the issuer's signing keys itself, so you paste the public key by hand. If Pangea rotates its signing key, you must update this provider with the new key from the dialog.
2. Create the role
In the CAM console, open Roles → Create Role, choose identity provider → OIDC, and pick the provider you just added. Set the conditions:
| Condition | Value |
|---|---|
oidc:aud |
sts.tencentcloudapi.com |
oidc:iss |
Filled in for you |
oidc:sub |
Your team's subject. Copy it from the dialog in Pangea. |
The dialog lists the oidc:sub condition as optional. Add it anyway. It is what locks the role to your team. Without it, any Pangea team that knows your role ARN and provider name could assume the role.
Attach a policy covering the work you want done. For TKE and CVM, use QcloudTKEFullAccess with QcloudCVMReadOnlyAccess, or AdministratorAccess for a dedicated account. Create the role, then open it and copy its ARN. It looks like qcs::cam::uin/123456789:roleName/Pangea.
3. Authorize cluster access (optional)
CAM only covers the control plane. To let the role act inside your TKE clusters, grant it access in each cluster:
- In the TKE console, open the cluster → Authorization Management → ClusterRoleBinding.
- Open the RBAC policy generator, choose account type Service role, and select the role from step 2.
- Pick the RBAC permissions (read-only is enough for browsing) and apply.
- Repeat for each cluster.
Skip this if you have no clusters, or only want CVM. 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, the role ARN and the OIDC provider name in Pangea.
In the Pangea app
- CVM instances: the account's compute instances.
- Clusters: TKE 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
TKE control-plane IAM and per-cluster Kubernetes authorization 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.