Securely obtain short-lived STS credentials in multi-cloud, container, and on-premises environments by using the native identity of the deployment environment, IDaaS M2M federated authentication, and PAM authorization, without storing a long-term AccessKey.
1. Overview
1.1 Why credential-free access is needed
Traditionally, an application running on a server, in a container, or in a pipeline must store a long-term AccessKey pair (AK/SK) in a configuration file or an environment variable to access cloud resources. This causes three types of problems:
Challenge | Description |
Large exposure surface | The AK spreads across images, scripts, configuration centers, and logs. A single leak compromises the entire account. |
High rotation cost | Manual periodic rotation requires coordination with every consumer, so the actual execution rate is low. |
Difficult auditing | Multiple applications share one AK, so you cannot tell which application made a call and responsibility cannot be traced. |
Credential-free access works as follows: a workload no longer stores any long-term key. Instead, it uses the native identity proof provided by the deployment environment (an instance identity document, a ServiceAccount token, an X.509 certificate, and so on) to complete machine identity authentication with IDaaS. IDaaS then exchanges that identity for a short-lived STS token from the cloud provider. No static key is written to disk at any point in the process.
1.2 End-to-end flow
The flow involves three types of roles. On the left are the client applications that run in various deployment environments (Alibaba Cloud ECS/ECI, AWS EC2, Kubernetes, on-premises IDC, and others; see Chapter 3 for the complete list). In the middle are the IDaaS EIAM authorization server and the PAM service. On the right is the target cloud provider (Alibaba Cloud, AWS, GCP, Azure, and others). The complete process has four steps:
Step | Interaction | Description |
① Obtain an OAuth2 AccessToken | Client application → IDaaS authorization server | The client application completes client_credentials authentication by using the native identity proof of the deployment environment (for how to select an authentication method, see Chapters 2 and 3) and obtains a JWT AccessToken. |
② Request a cloud role STS token | Client application → IDaaS PAM service | Carrying the AccessToken, the client application calls the PAM service operation that obtains cloud role access credentials (ObtainCloudAccountRoleAccessCredential; see Chapter 4) and specifies the target cloud role. |
③ Obtain a temporary OIDC Token | IDaaS PAM service → IDaaS authorization server | The PAM service requests a short-lived OIDC Token from the authorization server, with the target cloud provider as the audience. |
④ Exchange for an STS token | IDaaS PAM service → target cloud provider | The PAM service uses that OIDC Token at the federated identity endpoint of the cloud provider to exchange for the STS token of the cloud role, and returns it to the client application. |
The client application finally uses the STS token (Security Token Service token, a three-part temporary credential: AccessKeyId + AccessKeySecret + SecurityToken) to access the OpenAPI or SDK of the target cloud. Before the token expires, return to Step ② to refresh it.
This flow ensures that no static credential is stored on either side: the client side stores no long-term key (Step ①), and the IDaaS PAM side likewise stores no AK of the target cloud. Steps ③ and ④ show that PAM uses an OIDC federated identity to exchange for temporary credentials at the cloud provider. The cloud provider only needs to establish OIDC identity provider trust with IDaaS in advance and complete role authorization (for the configuration method, see the prerequisites in Chapter 4).
2. Overview and differences of M2M application authentication methods
2.1 M2M application model
The M2M (Machine-to-Machine) capability of IDaaS EIAM revolves around two types of applications:
Role | Description | Key configurations |
M2M client application (Client) | The party that initiates authentication, that is, your business application. | Credential management (client_id, secrets, public keys, and federated credentials) and network scope restrictions. |
M2M server application (Server / Resource Server) | The party that is called. It defines the audience and the permissions of the token. | Audience identifier (audience), permission identifier (scope), and the list of authorized applications. |
In an AccessToken request, the scope parameter is in the **<Audience identifier>|<Permission identifier>**(for example, urn:cloud:idaas:pam|cloud_account_role:obtain_access_credential). The server application must grant the permission to the client application in advance.
Prerequisites: the instance has M2M management enabled (controlled by license), the application has the M2M client capability enabled, and the token endpoint and the credentials are ready.
2.2 List of authentication methods
The token endpoint supports the following client authentication methods for the client_credentials grant type:
Standard credentials
Method | Mechanism | Credential form |
| The HTTP Basic header carries client_id + client_secret. | Shared static key |
| A form parameter carries client_secret. | Shared static key |
| Uses client_secret as the HMAC key to sign the JWT assertion (RFC 7523). The secret itself does not appear in the request. | Shared static key (derived signature) |
| The client signs the JWT assertion with an asymmetric private key, and IDaaS verifies the signature with the public key uploaded in advance. | Private key file (RSA-2048 by default; the public key is uploaded in PEM format) |
client_secret_jwt avoids putting the secret on the wire in plaintext, but the HMAC key is still a static secret shared by both parties. Once it leaks, an assertion can be forged.private_key_jwt requires IDaaS to store only the public key. The private key never appears in any request, so security is significantly better and the private key can be rotated independently.
Federated credentials (the core of credential-free access)
Unified request format for federated credentials: in the token request, submit an external identity proof with client_assertion_type + client_assertion to replace your own static credentials:
Method | client_assertion_type | Assertion content | Trust anchor |
PKCS#7 |
| The instance identity document issued by the cloud platform metadata service (PKCS#7/CMS signature) | The cloud provider root certificate (currently supports Alibaba Cloud and AWS) |
OIDC |
| The ID Token issued by an external OIDC identity provider | The configured Issuer + JWKS |
PCA |
| The X.509 client certificate ( | A self-managed private CA root certificate |
All three types of federated credentials support two levels of expressions for fine-grained admission control (configured by the administrator on the federated trust source and on the application federated credential):
Trust condition (trustCondition): an expression based on the assertion content, for example, limiting the instance ID, region, namespace, or certificate subject.
Verification condition (verificationCondition): a secondary check at the application federated credential level, used to narrow the scope when multiple applications share one trust source.
Runtime credentials (PLUGIN)
Method | Mechanism | Applicable scenario |
| Reuses the Alibaba Cloud runtime identity (the STS credentials that come with a Function Compute role or an ECS instance role) to call the IDaaS OpenAPI and exchange for an M2M token, with the SDK configured as | Managed runtimes such as Function Compute, where federated credentials cannot be used |
There is also the cloud_idp (EDS) assertion type for WUYING terminal sessions. It belongs to a specific terminal scenario and is not covered in this topic.
2.3 Differences in the verification mechanisms of the three federated credentials
Dimension | PKCS#7 | OIDC | PCA |
Assertion source | The cloud platform metadata service (instance level) | Any OIDC IdP (cluster, platform, or enterprise IdP) | The private key of the client |
Signature verification | The cloud provider root certificate verifies the PKCS#7 signature. | Issuer + JWKS verifies the JWT. | The uploaded private CA root certificate verifies the certificate chain (CRL revocation checks are supported), and then the certificate public key verifies the JWT signature. |
Public key management | No configuration is required (the trust anchor is built in) | Three sources: statically uploaded JWKS, automatic discovery from the Issuer, or a specified JWKS URI | Upload the root certificate (the intermediate certificate is provided by the client with the request) |
Replay protection | Signature time window validation (the signature time must not be later than the current time and must fall within the configured validity window) | The exp/iat validation of the ID Token itself | The exp/iat of the JWT assertion + certificate revocation (CRL) |
What the client must keep | Nothing (the environment provides it automatically) | Nothing (the platform provides the token automatically) | The certificate private key (if it leaks, you can revoke it through the CRL to limit the damage) |
Typical environment | Alibaba Cloud ECS, AWS EC2 | Container platforms such as ACK/EKS/GKE/TKE/CCE, and GCP GCE | Self-managed data centers and high-compliance intranet environments |
2.4 Authentication method comparison table
Authentication method | Static credential | Leak prevention | Forgery prevention | Rotation cost | Applicable environment |
client_secret_basic / post | ✅ | Weak (plaintext on the wire) | Weak (shared secret) | Manual, with a high coordination cost | Getting-started verification and the development phase |
client_secret_jwt | ✅ | Medium | Weak (a leaked shared secret allows forgery) | Manual | General purpose |
private_key_jwt | Private key file | Strong (the private key never goes on the wire) | Strong | Medium (the private key can be rotated independently) | On-premises, CI/CD, and environments without a native identity |
PKCS#7 federation | ❌ | Strongest | Strongest (endorsed by the cloud provider) | Zero | Alibaba Cloud ECS, AWS EC2 |
OIDC federation | ❌ | Strongest | Strongest (issued by the platform) | Zero | All container platforms, and GCP GCE |
PCA federation | Private key (revocable) | Strong | Strong (CA chain + CRL) | Medium (PKI operations) | Self-managed data centers and high-compliance environments |
PLUGIN | ❌ (reuses the runtime role) | Strong | Strong | Zero | Function Compute (FC) |
3. Deployment environments and authentication method selection
This chapter describes the typical workload forms of each cloud provider (virtual machines, containers, serverless, and so on) and gives the recommended authentication method for each deployment scenario. It covers seven cloud providers: Alibaba Cloud, AWS, GCP, Azure, Tencent Cloud, Huawei Cloud, and Volcengine. It also covers non-cloud environments such as on-premises IDCs, self-managed Kubernetes clusters, and local development or CI-CD. The end of the chapter discusses how to handle dynamic workloads in elastic scaling scenarios (such as ECS + ESS).
3.1 Deployment environment × authentication method quick-reference matrix
Chapter 2 described the mechanisms and the differences of the authentication methods. The following tables group all deployment environments by cloud provider and summarize their native identity proofs and recommended authentication methods for quick selection. For the onboarding instructions of each provider and environment, see the corresponding sections (3.2 to 3.9). For the unified process of exchanging for an Alibaba Cloud STS token, see Chapter 4.
Alibaba Cloud (see section 3.2)
Deployment environment | Native identity proof | Recommended authentication method |
ECS (virtual machine) | Instance identity document (PKCS#7 signature) | PKCS#7 federated credential |
ACK (container) | ServiceAccount OIDC Token (RRSA) | OIDC federated credential |
Function Compute (FC) | Function runtime role credential | PLUGIN (OpenAPI authentication) |
AWS (see section 3.3)
Deployment environment | Native identity proof | Recommended authentication method |
EC2 (virtual machine) | Instance identity document (PKCS#7 signature) | PKCS#7 federated credential |
EKS (container) | ServiceAccount OIDC Token (IRSA) | OIDC federated credential |
GCP (see section 3.4)
Deployment environment | Native identity proof | Recommended authentication method |
GCE (virtual machine) | The OIDC Token of the default service account of the instance | OIDC federated credential |
GKE (container) | Workload Identity token | OIDC federated credential |
Azure (see section 3.5)
Deployment environment | Native identity proof | Recommended authentication method |
VM (virtual machine) | Managed identity token (issued by Microsoft Entra ID) | OIDC federated credential |
AKS (container) | Workload Identity token | OIDC federated credential |
Tencent Cloud (see section 3.6)
Deployment environment | Native identity proof | Recommended authentication method |
CVM (virtual machine) | No public instance identity signature mechanism | private_key_jwt / PCA federated credential |
TKE (container) | ServiceAccount OIDC Token | OIDC federated credential |
Huawei Cloud (see section 3.7)
Deployment environment | Native identity proof | Recommended authentication method |
ECS (virtual machine) | No public instance identity signature mechanism | private_key_jwt / PCA federated credential |
CCE (container) | ServiceAccount OIDC Token | OIDC federated credential |
Volcengine (see section 3.8)
Deployment environment | Native identity proof | Recommended authentication method |
Cloud server (virtual machine) | No known public instance identity signature mechanism | private_key_jwt / PCA federated credential |
VKE (container) | ServiceAccount OIDC Token (IRSA) | OIDC federated credential |
On-premises IDC and self-managed environments (see section 3.9)
Deployment environment | Native identity proof | Recommended authentication method |
Self-managed Kubernetes cluster | ServiceAccount OIDC Token (issued by the cluster) | OIDC federated credential |
Self-managed data center / bare metal / general-purpose server | None (you must build your own) | PCA federated credential / private_key_jwt |
Local development environment | None | private_key_jwt(during development, the secret can be injected through an environment variable) |
CI/CD pipeline | Platform OIDC (such as GitHub Actions) or none | OIDC federated credential / private_key_jwt |
One-sentence selection principle: prefer the native identity of the deployment environment (PKCS#7, OIDC, or PLUGIN federated credentials, with zero static credentials); when the environment does not provide a verifiable native identity, fall back to private_key_jwt or PCA (the private key never goes on the wire directly and is revocable); client_secret methods are recommended only for getting-started verification and the development phase.
3.2 Alibaba Cloud workloads
Alibaba Cloud is the only cloud provider with official end-to-end best practices (full coverage of ECS, ACK, and Function Compute). The following three sections serve as the reference implementation for all deployment environments; other providers and on-premises environments onboard in the same way.
3.2.1 ECS (virtual machine) — PKCS#7 federated credential
An ECS instance can obtain the platform-issued instance identity document and PKCS#7 signature from the instance metadata service. The signature is endorsed by the Alibaba Cloud root certificate, so you do not need to store any key on the instance. When you obtain the signature, bind the target IDaaS instance and the signature time into the audience for replay protection. On the IDaaS side, create a PKCS#7 federated trust source (select "Alibaba Cloud" as the trust source). After you add a federated credential to the M2M client application, use the signature as client_assertion (pkcs7-bearer) to exchange for an AccessToken.
Notes for onboarding: the signature is short-lived, so initiate the token request immediately after you obtain it and do not cache or reuse it. The trust condition can narrow admission to attributes such as a specified region. For the complete procedure, see the official scenario document Best practices: obtain an STS token on ECS without static credentials.
3.2.2 ACK (container) — OIDC federated credential (RRSA)
The RRSA (Resource Role for ServiceAccount) mechanism of ACK enables a Pod to obtain a platform-issued OIDC Token through its ServiceAccount. After you install the ack-pod-identity-webhook component, the token file path is injected into the container environment variable ALIBABA_CLOUD_OIDC_TOKEN_FILE, and the application can read it directly. On the IDaaS side, create an OIDC federated trust source: set Issuer to the OIDC issuer address of the ACK cluster, and use JWKS automatic discovery or a specified URI. Use that token as client_assertion (id-token-bearer) to exchange for an AccessToken. The trust condition can limit the namespace and the ServiceAccount to achieve Pod-level permission isolation.
For the complete procedure, see the official scenario document Best practices: obtain STS credentials on ACK without static credentials. This mode also applies to self-managed Kubernetes clusters. For the onboarding key points, see section 3.9.1.
3.2.3 Function Compute (FC) — PLUGIN (OpenAPI authentication)
Managed runtimes such as Function Compute cannot access the instance metadata service and cannot conveniently mount federated credential materials, but the runtime comes with Alibaba Cloud role credentials (STS). The PLUGIN method reuses these runtime credentials to call IDaaS OpenAPI and exchange for an M2M AccessToken — likewise zero static credentials for the function code. The execution role of the function must have the RAM permissions to call IDaaS OpenAPI.
For SDK usage documentation, see IDaaS EIAM SDK and Environment preparation.
3.3 AWS workloads
The typical AWS workloads are EC2 (virtual machine) and EKS (container). Serverless forms such as Lambda have no platform identity proof that a third party can verify, so private_key_jwt is recommended (encrypt the private key through KMS or Secrets Manager, and then inject it into the function environment variable).
3.3.1 EC2 — PKCS#7 federated credential
AWS EC2 provides the instance identity document and the PKCS#7 signature through IMDS (Instance Metadata Service; IMDSv2 is recommended). The mechanism is of the same origin and type as Alibaba Cloud ECS. The PKCS#7 federated trust source of IDaaS supports selecting AWS as the trust source. After it is created, use the EC2 instance identity signature as client_assertion (pkcs7-bearer) to exchange for an AccessToken. The request form is the same as that of Alibaba Cloud ECS (section 3.2.1). To narrow the admission surface, use the trust condition to limit attributes such as the AWS account ID and the region. The official end-to-end scenario document has not been published yet; before you implement this method, confirm the product release status with the Alibaba Cloud IDaaS team.
3.3.2 EKS — OIDC federated credential
An EKS cluster natively exposes an OIDC issuer and a public JWKS endpoint (which the IRSA mechanism relies on). Onboard it in the same mode as ACK in section 3.2.2: configure the OIDC Issuer of the EKS cluster as an IDaaS OIDC federated trust source, and the Pod uses the ServiceAccount Token as client_assertion (id-token-bearer). The trust condition can limit the namespace and the ServiceAccount. The specific issuer and JWKS addresses are subject to the cluster configuration.
3.4 GCP workloads
Both GCP virtual machines (GCE) and containers (GKE and Cloud Run) issue OIDC tokens based on the service account system, and are onboarded uniformly with OIDC federated credentials.
3.4.1 GCE (virtual machine) — OIDC federated credential
A GCE instance can obtain the OIDC identity token of its default service account from the metadata server (the audience can be specified). The issuer can be verified through the public JWKS of Google. Onboarding method: create an OIDC federated trust source in IDaaS (set Issuer to the Google identity service address, and discover the JWKS from the Issuer or specify a URI). The instance uses that identity token as client_assertion to complete client_credentials authentication. The trust condition can bind instance-related claims.
3.4.2 GKE (container) — OIDC federated credential
GKE relies on Workload Identity to provide platform-issued identity tokens for workloads. The onboarding mode is the same as in section 3.2.2: the cluster workload identity token is submitted to IDaaS as an OIDC federated credential assertion. The issuer and the JWKS of that token must be accessible to IDaaS, and the details are subject to the GKE cluster configuration.
3.5 Azure workloads
Both Azure virtual machines and AKS provide a platform identity issued by Microsoft Entra ID (formerly Azure AD), and are onboarded uniformly with OIDC federated credentials. Managed services such as Azure Functions also support managed identities.
3.5.1 VM (virtual machine) — OIDC federated credential (managed identity)
An Azure VM can enable a managed identity, and the application obtains a signed JWT issued by Microsoft Entra ID through the instance metadata service. Onboarding method: create an OIDC federated trust source in IDaaS. Set Issuer to the Microsoft Entra ID token issuance address of the tenant and obtain the JWKS from its public discovery endpoint. Configure audiences according to the aud of the managed identity token (that is, the resource identifier that corresponds to the resource parameter). The instance uses that token as client_assertion (id-token-bearer) to complete authentication. The trust condition can bind claims such as the tenant and the resource.
3.5.2 AKS (container) — OIDC federated credential (Workload Identity)
AKS supports Workload Identity federation: the cluster exposes an OIDC issuer and a JWKS endpoint, and a Pod uses the ServiceAccount token as its identity proof. The onboarding mode is the same as ACK in section 3.2.2: configure the OIDC issuer of the AKS cluster as an IDaaS OIDC federated trust source, submit the token as client_assertion, and limit the namespace and the ServiceAccount in the trust condition.
3.6 Tencent Cloud workloads
The typical Tencent Cloud workloads are CVM (virtual machine) and TKE (container). Serverless forms such as Serverless Cloud Function (SCF) are the same as CVM, and private_key_jwt is recommended.
3.6.1 CVM (virtual machine) — private_key_jwt / PCA federated credential
Tencent Cloud CVM does not provide a publicly signed instance identity document mechanism like Alibaba Cloud or AWS, so PKCS#7 federated credentials cannot be used. Use one of the following recommended methods:
private_key_jwt: the private key file is distributed with the deployment (recommended: distribute it encrypted through configuration management), and the public key is uploaded to IDaaS; the private key does not appear in the request, so the exposure surface is controllable
PCA federated credential (preferred when an enterprise PKI already exists): if the certificate private key leaks, it can be revoked through the CRL, which limits the damage better than a bare private key
3.6.2 TKE (container) — OIDC federated credential
TKE can issue ServiceAccount tokens for a cluster. If the cluster exposes an OIDC issuer and a JWKS endpoint, you can onboard the IDaaS OIDC federated trust source in the ACK mode described in section 3.2.2. In addition, IDaaS has released the Tencent Cloud account management capability (see Tencent Cloud identity management), which can be used together for credential management on the target cloud side.
3.7 Huawei Cloud workloads
The typical Huawei Cloud workloads are ECS (virtual machine) and CCE (container).
3.7.1 ECS (virtual machine) — private_key_jwt / PCA federated credential
As with Tencent Cloud CVM, Huawei Cloud ECS metadata does not provide a public instance identity signature that a third party can verify (an IAM agency is a resource-level authorization and does not produce a portable identity proof). private_key_jwt or a PCA federated credential is recommended.
3.7.2 CCE (container) — OIDC federated credential
If a CCE cluster is configured with a ServiceAccount token issuer (OIDC Issuer + JWKS), onboard it in the ACK mode described in section 3.2.2. On the Huawei Cloud side, documentation already exists for SSO integration between IAM Identity Center and IDaaS (for person identities). For machine identities, connect in the general OIDC federated credential mode described in this topic.
3.8 Volcengine workloads
The typical Volcengine workloads are the cloud server (virtual machine) and VKE (container).
3.8.1 Cloud server (virtual machine) — private_key_jwt / PCA federated credential
As of the last update of this topic, Volcengine cloud servers do not provide a public instance identity document mechanism that a third party can verify (subject to the official documentation). You therefore cannot use PKCS#7 federated credentials. The recommended options are private_key_jwt or a PCA federated credential, in the same way as Tencent Cloud CVM (section 3.6.1).
3.8.2 VKE (container) — OIDC federated credential (IRSA)
Volcengine Container Service VKE supports IRSA (IAM Roles for Service Accounts), can issue ServiceAccount OIDC Tokens for Pods, and exposes the issuer and JWKS endpoints (see Volcengine IRSA overview). The onboarding mode is the same as ACK in section 3.2.2: configure the OIDC issuer of the VKE cluster as an IDaaS OIDC federated trust source, and the Pod uses the ServiceAccount Token as client_assertion (id-token-bearer) to complete authentication. The trust condition limits the namespace and the ServiceAccount.
3.9 On-premises IDC and self-managed environments
On-premises IDCs and self-managed environments have no native identity endorsed by a cloud platform, so you must build your own trust root. The only exception is a self-managed Kubernetes cluster: Kubernetes itself can issue ServiceAccount tokens, so an OIDC federated credential can still be used.
3.9.1 Self-managed Kubernetes cluster — OIDC federated credential
A standard Kubernetes cluster natively supports OIDC identity issuance: according to the ServiceAccount token issuance parameters, kube-apiserver issues each Pod a bound token — a JWT signed by the cluster key that contains claims such as iss / aud / exp / the namespace / the ServiceAccount name. Onboarding steps:
Cluster side: configure the ServiceAccount token issuance parameters for kube-apiserver (
--service-account-issuer,--service-account-signing-key-fileand so on), and publish the JWKS endpoints (the apiserver/.well-known/openid-configurationand/openid/v1/jwks) to an address that IDaaS can access. By default, this endpoint is reachable only from inside the cluster, and is usually exposed through a reverse proxy or object storageIDaaS side: create an OIDC federated trust source, set Issuer to the cluster issuer address, and choose static JWKS upload or a specified JWKS URI
Application side: read the mounted ServiceAccount Token (a ServiceAccount Token projected volume) as
client_assertion(id-token-bearer). The mode is the same as ACK in section 3.2.2Trust condition limits the namespace and the ServiceAccount to achieve permission isolation among multiple workloads in the cluster
3.9.2 Self-managed data center / bare metal / general-purpose server — PCA or private_key_jwt
On-premises environments have no native identity endorsed by a platform, so you must build your own trust root. The PCA federated credential applies to scenarios that already have an enterprise PKI or high compliance requirements. The client certificate and the intermediate certificate chain are submitted with the request. IDaaS verifies the certificate chain against the uploaded private CA root certificate and supports CRL revocation checks, and a leaked private key can be revoked immediately to limit the damage. private_key_jwt applies to scenarios without a PKI that need fast onboarding: the RSA-2048 private key is kept locally, and the public key PEM is uploaded to IDaaS. In terms of security priority, PCA is better than a bare private key, because after a bare private key leaks you can only respond passively by rotating the key.
3.9.3 Local development environment
The first choice during development is private_key_jwt (keep the private key in a local environment variable so that no secret enters the code repository). For fast verification you can use client_secret, but you must inject the secret through an environment variable. Never write it into code or commit it in a configuration file. Use an SDK configuration file to switch environments, which ensures a smooth migration of the authentication method between development and production.
3.9.4 CI/CD pipeline
When the platform supports OIDC (such as the IdP token of GitHub Actions), use the OIDC token issued by the platform as the assertion and go with an OIDC federated credential for zero static credentials. When the platform has no OIDC, use private_key_jwt: store the private key in the platform secrets and inject it, keep the public key in IDaaS, and after a leak delete the public key in IDaaS to limit the damage.
3.10 Elastic scaling scenarios (such as ECS + ESS): how dynamic workloads authenticate
Cloud VMs are often used together with elastic scaling. Take Alibaba Cloud ECS + ESS (Auto Scaling) as an example: a scaling group dynamically creates and releases instances based on the load. In the traditional static AK mode, every newly scaled-out instance must obtain an AK, which is distributed with a custom image or a launch script. The credential exposure surface grows linearly with the scale-out. All instances also share the same AK, so auditing cannot distinguish the source of a call.
Federated credentials naturally fit elastic scaling, because the trust anchor is not on a single instance:
Dimension | Static AK mode | Federated credential mode (PKCS#7 / OIDC) |
How a new instance obtains credentials | The AK is distributed through an image or a launch script, and the exposure surface grows with the scale-out | After startup, the identity proof is automatically obtained from the local metadata service, and no key needs to be distributed |
How trust is established | Stores a shared key | Cloud provider root certificate / platform JWKS signature verification + trust condition |
Instance-level identifiability | Multiple instances share the same AK and cannot be distinguished | The assertion of each instance carries the local instance ID or Pod identifier, so auditing can reach a specific instance |
Scaling changes | Requires a credential distribution mechanism | Zero changes; the application code stays the same |
Onboarding key points for the ECS + ESS scenario:
Do not bind the trust condition to an instance ID: instance IDs change at any time when a scaling group scales in or out, and hardcoding the trust condition to an instance ID causes the authentication of newly scaled-out instances to be rejected. The recommended approach is to bind the trust condition to the image ID: each workload maintains one custom image, all scaling instances of the same workload naturally share that image, and the admission scope is stable and isolated per workload
Alternative: switch to the PLUGIN (OpenAPI authentication) method: attach the same ECS instance RAM role to the launch template of the scaling group, and a new instance automatically obtains the role credentials at startup. The application uses the PLUGIN method to reuse these role credentials to call IDaaS OpenAPI and exchange them for an AccessToken. This is likewise zero static credentials and requires no additional trust condition configuration for the image
Obtain the signature in real time for each token request (PKCS#7 method): before each AccessToken request, pull the local identity signature from the metadata service and submit it immediately. The signature itself is short-lived and should never be cached or reused. When you use the IDaaS SDK, configure
clientDeployEnvironment=ALIBABA_CLOUD_ECS, and the SDK obtains it automatically on demandThe scaling configuration contains no credentials: the launch template or the custom image deploys only the business application and the SDK configuration file (a non-sensitive configuration that contains no keys)
Auditing traces back to the instance: the IDaaS audit log records the credential identifier used for each authentication (including the instance information in the signature), so calls from scaled-out instances and existing instances can be distinguished
The image ID binding method and the PLUGIN + instance role method also apply to elastic scaling on other clouds. For AWS EC2 + Auto Scaling group, you can bind the trust condition to the AMI ID (PKCS#7). GCP managed instance groups and Azure virtual machine scale sets are automatically available based on managed identity tokens (OIDC). In container scenarios, HPA and Cluster Autoscaler are naturally isolated by ServiceAccount, and OIDC federated credentials are zero-touch.
Note: elastic scaling in private_key_jwt or PCA environments (the VMs of Tencent Cloud, Huawei Cloud, and Volcengine, and on-premises environments) requires a separately designed key distribution mechanism. The private key must be injected into a new instance through an encrypted image, a configuration management system (such as Vault), or a secure pull at startup, and a revocation or rotation plan is required. If your workload allows it, prefer migrating the workload to a container platform and switching to OIDC federated credentials, which completely removes the key distribution problem.
4. Obtain an Alibaba Cloud STS Token (the IDaaS cloud account management path)
This chapter describes the standard path when the target cloud is Alibaba Cloud: AccessToken → IDaaS DeveloperAPI → Alibaba Cloud STS Token. After obtaining an AccessToken, all the deployment environment chapters follow the unified process in this chapter to obtain an STS Token. This path also supports AWS and Tencent Cloud: the same operation obtains the corresponding temporary access credentials for a managed AWS / Tencent Cloud cloud role (awsStsToken / tencentCloudStsToken). The process and the parameters are exactly the same. This chapter uses Alibaba Cloud as an example.
4.1 Prerequisites
Prerequisite | Description |
The machine identity management capability is enabled | The instance has the IDaaS machine identity management capabilities enabled |
The cloud account is managed | In the IDaaS console, choose Asset Management > Cloud Identity to add an Alibaba Cloud account and create or synchronize cloud roles (RAM roles) |
PAM feature authorization | The application must have the feature authorization of the built-in PAM application "obtain cloud role access credentials" |
scope authorization | The M2M server application grants the permission |
4.2 Call ObtainCloudAccountRoleAccessCredential
curl -s --request GET \
--url "https://eiam-developerapi.<region>.aliyuncs.com/v2/<instanceId>/cloudAccountRoles/_/actions/obtainAccessCredential?cloudAccountRoleExternalId=acs:ram::<Alibaba Cloud account ID>:role/<RAM role name>&durationSeconds=3600" \
--header "Authorization: Bearer <AccessToken>"Parameter | Required | Description |
| Yes | The IDaaS instance ID |
| Yes |
|
| Yes | The business identifier of the cloud role. For Alibaba Cloud, this is the RAM role ARN (such as |
| No | The validity period of the STS Token, in seconds. The range is 900 to 43200, and the actual value is subject to the upper limit of the cloud provider. |
The auxiliary operation GET /v2/{instanceId}/cloudAccountRoles/_/actions/listAssumableCloudAccountRoles (NextToken cursor pagination) lists the cloud roles that the current identity can assume, and is used for role discovery.
4.3 Response structure and fields
{
"cloudAccountId": "ca_01kmegjc11qa1txxxxx",
"cloudAccountRoleId": "carole_01kmek49aqxxxx",
"cloudAccountRoleName": "role-test",
"cloudAccountRoleExternalId": "acs:ram::xxx:role/role-test",
"cloudAccountVendorType": "alibaba_cloud",
"cloudAccountRoleAccessCredential": {
"accessCredentialExpiresAt": 1767196800,
"alibabaCloudStsToken": {
"accessKeyId": "STS.NUgYrLnoC37mZZCNnAbez****",
"accessKeySecret": "****",
"securityToken": "****",
"expiration": "2026-10-20T04:27:09Z"
}
}
}Field | Description |
| The three-part Alibaba Cloud STS credential: |
| The time when the credential expires (a Unix timestamp in seconds). The application should refresh the credential in advance based on this value. |
| The type of the cloud account (in the scenario of this topic, the value is |
4.4 Recommendations for using and refreshing credentials
Caching and refreshing: call this operation again to refresh the credential before it expires (for example, 5 minutes in advance), so that you do not exchange for a new credential for every cloud API call
Passing to the SDK: fill the three-part credential into the CredentialsProvider of the Alibaba Cloud SDK (STS mode), and the SDK automatically signs with the SecurityToken
Short validity period:
durationSecondsshould be set to the minimum value based on the duration of a single task, and 3600 or less is recommended by default
4.5 SDK method (recommended)
IDaaS provides a dedicated adapter SDK that automatically completes the whole chain of "authentication → AccessToken retrieval → STS exchange → cache refresh":
SDK | Coordinates (Java / Python) | Responsibility |
IDaaS Core SDK |
| M2M authentication, token retrieval, and token refresh |
IDaaS Akless Alibabacloud Adapter |
| The adapter for AK-free scenarios: obtains the Alibaba Cloud temporary access credentials of a managed cloud role |
Together with the deployment environment configuration of the Core SDK (clientDeployEnvironment=ALIBABA_CLOUD_ECS corresponds to PKCS7, and KUBERNETES corresponds to OIDC), the SDK automatically selects the federated credential material based on the environment, and your application code does not need to be aware of environment differences.
5. Security best practices
Practice | Description |
Scope minimization | Grant only the required |
Trust condition narrowing | Configure trustCondition and verificationCondition on the federated credential to bind admission to specific attributes such as the instance ID, region, namespace, ServiceAccount, and certificate subject, which prevents lateral spread |
Network scope restriction | Configure the network scope of the M2M client application (specify the egress IP addresses or CIDR blocks). Calls inside a VPC network are controlled by the network zone policy |
Short credential validity period | Set the validity periods of the AccessToken and the STS Token as short as your needs allow. Use a PKCS#7 signature immediately after obtaining it, and do not write it to disk or reuse it |
Audience binding | In the audience of the instance identity, the |
Damage-control plan for private key methods | For private_key_jwt and PCA scenarios: rehearse the handling of a private key leak (delete the public key on the IDaaS side or revoke the certificate through the CRL) to make sure the damage-control path works |
Audit trail | All token issuance and cloud role credential retrieval actions are written to the IDaaS audit log. Federated credential authentication records the credential ID that was used (including the assertion jti or the certificate serial number) and the key claims (mobile phone numbers and email addresses are masked) |
Appendix A: Official documentation and SDK index
Topic | Link |
ECS credential-free scenario (PKCS#7 end-to-end) | Best practices: obtain an STS token on ECS without static credentials |
ACK credential-free scenario (RRSA + OIDC end-to-end) | Best practices: obtain STS credentials on ACK without static credentials |
Configure credential-free M2M access to cloud resources | |
M2M applications (inter-machine permission management) | |
Obtain the temporary access credentials of a cloud role (API) | Obtain the temporary access credentials of a cloud role (API) |
Cloud identity management overview | |
AWS cloud identity management | |
Tencent Cloud identity management | |
IDaaS EIAM SDK overview | |
SDK environment preparation (authentication method configuration) | SDK environment preparation (authentication method configuration) |
Volcengine VKE IRSA overview (external documentation) | |
Azure managed identities (external documentation) |
Appendix B: FAQ
Q1: Where can I view the token endpoint? Choose M2M application details > General configuration > Application configuration information > token endpoint. The instance-level endpoint is in the following format: https://<instance ID>.aliyunidaas.com/api/v2/{authorizationServerId}/oauth2/token. The default authorization server is iauths_system.
Q2: What do I do if scope reports "scope required" or "unauthorized"?client_credentials The request must carry a scope in the format <Audience identifier>|<Permission identifier>. You must also confirm that the M2M server application has granted this permission to your client application.
Q3: What do I do if PKCS#7 authentication reports "signature time validation failed"? The signature time is outside the validity window or is a future time. Initiate the request immediately after obtaining the signature, and do not cache or reuse it. Check the clock skew of the instance.
Q4: How do I configure the JWKS of an OIDC federated credential? Choose any of the three sources: statically uploaded JWKS, automatic discovery from the Issuer, or a specified JWKS URI. Cluster platforms usually use automatic Issuer discovery or a specified JWKS URI.
Q5: What materials must I provide for PCA authentication? Submit the following in the request: client_x509 (the client certificate; only one is supported), client_x509_chain (the intermediate certificate chain), and client_assertion (a JWT signed by the certificate private key; the audience must contain the client_id and the token endpoint). On the IDaaS side, upload the private CA root certificate as the trust anchor.
Q6: Is obtaining an STS Token for a multi-cloud target (such as AWS or Tencent Cloud) supported?ObtainCloudAccountRoleAccessCredential The credential structures of this operation already cover six cloud providers: Alibaba Cloud, AWS, Tencent Cloud, Huawei Cloud, GCP, and Entra ID. This topic focuses on Alibaba Cloud as the target cloud. For multi-cloud scenarios, follow the ongoing updates of the IDaaS cloud identity management references.
Q7: Why are federated credentials not used on Function Compute? A managed serverless runtime cannot access instance metadata or mount certificates, but it comes with role credentials. The PLUGIN method reuses the runtime credentials for OpenAPI authentication and likewise achieves zero static credentials.