Identity as a Service:Configure credential-free M2M access to cloud resources

1.1 Why we need credential-free access

Traditionally, workloads running in servers, containers, or CI/CD pipelines require a long-term AccessKey (AK/SK) stored in configuration files or environment variables to access cloud resources. This approach introduces three major challenges:

The Credential-Free approach resolves this by ensuring workloads no longer store any long-term secrets. Instead, they leverage native identity proofs provided by the deployment environment (e.g., Instance Identity Documents, ServiceAccount tokens, X.509 certificates) to authenticate with IDaaS. IDaaS then exchanges this identity for a short-lived cloud provider STS Token. Throughout this lifecycle, zero static credentials are ever saved to disk.

1.2 End-to-End architecture flow

The architecture involves three primary entities: Client applications running in various environments (Alibaba Cloud ECS/ECI, AWS EC2, Kubernetes, On-Premises IDC, etc.; see Chapter 3) on the left; the IDaaS EIAM Authorization Server and PAM Service in the middle; and the target Cloud Provider (Alibaba Cloud, AWS, GCP, Azure, etc.) on the right. The complete flow consists of four steps:

The client application ultimately uses the STS Token (a three-part temporary credential: AccessKeyId + AccessKeySecret + SecurityToken) to invoke the target cloud's OpenAPI/SDK, refreshing it at Step ② before expiration.

This architecture ensures no static credentials exist on either side. The client stores no long-term keys (Step ①), and the IDaaS PAM does not store target cloud Access Keys. Instead, PAM uses OIDC identity federation to assume roles (Steps ③ & ④). The cloud provider only needs an established OIDC Identity Provider trust with IDaaS and appropriate role authorizations (see Chapter 4 Prerequisites).

2.1 M2M application model

IDaaS EIAM's Machine-to-Machine (M2M) capabilities are built around two application types:

The scope parameter in an AccessToken request is formatted as <Audience>|<Scope> (e.g., urn:cloud:idaas:pam|cloud_account_role:obtain_access_credential). The Server App must grant this scope to the Client App in advance.

Prerequisites: The instance must have M2M management enabled (License control), the application must have M2M client capabilities activated, and token endpoints/credentials must be provisioned.

2.2 Authentication methods

The token endpoint supports the following client authentication methods for the client_credentials grant type:

2.3 Verification mechanisms for federated credentials

2.4 Authentication methods comparison matrix

3.1 Quick reference matrix

Section 2 explains the available authentication methods. The following matrix groups deployment environments by cloud provider and recommends a method for each. See Sections 3.2 through 3.9 for implementation details and Section 4 for the shared process that obtains Alibaba Cloud STS credentials.

3.2 Alibaba Cloud workloads

Alibaba Cloud provides end-to-end credential-free best practices across all major compute types. Other clouds will follow similar integration patterns.

3.3 AWS workloads

AWS commonly runs workloads on EC2 virtual machines and EKS containers. For serverless environments such as Lambda, use private_key_jwt and inject the KMS- or Secrets Manager-protected private key at runtime because no platform identity proof is available for third-party validation.

3.4 GCP workloads

GCP issues OIDC tokens through its service-account model for virtual machines, containers, and Cloud Run. Use OIDC federation for these workloads.

3.5 Azure workloads

Azure VMs and AKS provide identities issued by Microsoft Entra ID. Both integrate through OIDC federation. Managed services such as Azure Functions also support managed identities.

3.6 Tencent Cloud workloads

Tencent Cloud commonly runs workloads on CVM virtual machines and TKE containers. For serverless environments such as SCF, use private_key_jwt.

3.7 Huawei Cloud workloads

Huawei Cloud commonly runs workloads on ECS virtual machines and CCE containers.

3.8 Volcengine workloads

Volcengine commonly runs workloads on cloud servers and VKE containers.

3.9 On-premises & CI/CD

On-premises environments do not have a cloud-provider identity and must establish their own trust root. Self-managed Kubernetes is the exception because it can issue ServiceAccount OIDC tokens.

3.10 Auto Scaling scenarios (ECS + Auto Scaling)

Traditional static Access Keys are highly problematic for Auto Scaling Groups (ASG), as credentials must be baked into images, expanding the blast radius as instances scale out, while obfuscating audit trails.

Federated credentials natively solve this by shifting trust from the instance to the environment:

Integration best practices for auto scaling:

1. Never bind Trust Conditions to instance IDs: Because Auto Scaling dynamically provisions new IDs, hardcoding them will cause authentications to fail. Instead, bind Trust Conditions to the Image ID (AMI) to establish a stable, workload-specific trust perimeter.

2. Alternative (PLUGIN): Assign an instance RAM role to the Launch Template. New instances natively assume the role, and the PLUGIN method invokes IDaaS seamlessly.

3. Fetch signatures in real-time: Do not cache IMDS signatures. Fetch a fresh PKCS#7 signature immediately prior to token exchange.

4. Clean images: Ensure Launch Templates and custom images contain absolutely no credentials.

5. Granular auditing: IDaaS logs capture the unique Instance ID from the assertion, allowing you to differentiate API calls made by newly scaled instances versus existing ones.

The image-ID and PLUGIN patterns also apply to other cloud scaling services. For AWS EC2 Auto Scaling, bind PKCS#7 trust conditions to the AMI ID. GCP managed instance groups and Azure virtual machine scale sets automatically expose managed identity tokens for OIDC. Container autoscaling through HPA or Cluster Autoscaler retains ServiceAccount-based isolation without distributing credentials.

4.1 Prerequisites

4.2 Invoke ObtainCloudAccountRoleAccessCredential

curl -s --request GET \
  --url "https://eiam-developerapi.<region>.aliyuncs.com/v2/<instanceId>/cloudAccountRoles/_/actions/obtainAccessCredential?cloudAccountRoleExternalId=acs:ram::<Account_ID>:role/<Role_Name>&durationSeconds=3600" \
  --header "Authorization: Bearer <AccessToken>"

Use GET /v2/{instanceId}/cloudAccountRoles/_/actions/listAssumableCloudAccountRoles with NextToken cursor pagination to discover cloud roles that the current identity can assume.

4.3 Response structure

{
  "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"
    }
  }
}

4.4 Credential usage and rotation

• Proactive Refresh: Refresh the STS token slightly before expiration (e.g., 5 minutes prior) rather than fetching a new token for every API call.

• SDK Injection: Pass the three-part credential to the Alibaba Cloud SDK's CredentialsProvider. The SDK will automatically append the SecurityToken.

• Short TTLs: Keep durationSeconds as brief as the workload requires (default 3600s recommended).

4.5 SDK integration (recommended)

IDaaS provides dedicated SDKs to automate the entire lifecycle (Auth → AccessToken → STS Token → Refresh):

With the Core SDK deployment configuration, set clientDeployEnvironment=ALIBABA_CLOUD_ECS for PKCS#7 or KUBERNETES for OIDC. The SDK selects the appropriate federated credential material without requiring environment-specific business logic.