Feature Request: Support non-AWS OIDC authentication (e.g., Alibaba Cloud RRSA) for S3-compatible storage backends

[ygsa]

Feature Request: Support Alibaba Cloud RRSA (OIDC-based pod identity) for S3-compatible storage

Is your feature request related to a problem? Please describe.

Tempo supports AWS IRSA (IAM Roles for Service Accounts) for S3 authentication via the credentials.IAM{} provider in the credential chain. This works because minio-go automatically detects AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN, then calls AWS STS AssumeRoleWithWebIdentity to obtain temporary credentials.

However, when running Tempo on Alibaba Cloud ACK (Container Service for Kubernetes) with RRSA (RAM Roles for Service Accounts) — which is Alibaba Cloud's equivalent of IRSA — the same mechanism does not work, because:

1. RRSA injects different environment variables: ALIBABA_CLOUD_OIDC_TOKEN_FILE, ALIBABA_CLOUD_ROLE_ARN, ALIBABA_CLOUD_OIDC_PROVIDER_ARN
2. The STS API is AssumeRoleWithOIDC (not AssumeRoleWithWebIdentity) and requires an additional OIDCProviderArn parameter
3. The STS endpoint is sts.aliyuncs.com (not sts.amazonaws.com)

Both IRSA and RRSA follow the same pattern: an OIDC token is projected into the pod, which is exchanged for temporary credentials via an STS call. The only differences are the environment variable names, STS endpoint, and API parameters.

Describe the solution you'd like

Support Alibaba Cloud RRSA in the S3 credential chain, similar to how AWS IRSA is supported today. When the ALIBABA_CLOUD_OIDC_TOKEN_FILE environment variable is present, Tempo should be able to use it to obtain temporary credentials from Alibaba Cloud STS.

This would allow Tempo to run on Alibaba Cloud ACK with RRSA without requiring static AK/SK or external credential rotation mechanisms.

Describe alternatives you've considered

• Static AK/SK via env vars (AWS_ACCESS_KEY_ID): Works but requires external rotation (e.g., Vault). No auto-refresh.
• credential_process: Cannot work because Tempo uses a distroless container image — there is no shell or dynamic linker available to execute external binaries.
• Init container to pre-fetch credentials: Works as a workaround but credentials expire (max 12h for Alibaba STS) and minio-go does not re-read them after startup.

Additional context

Environment:

• Tempo version: v2.10.3
• Helm chart: tempo-distributed 2.14.0
• Cloud provider: Alibaba Cloud
• Kubernetes: ACK (Alibaba Cloud Container Service for Kubernetes)
• Object storage: Alibaba Cloud OSS (S3-compatible API)
• Authentication: RRSA (OIDC-based, identical pattern to AWS IRSA)

How IRSA works today (for reference):

• EKS injects AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN into the pod
• minio-go's credentials.IAM{} detects these env vars
• Calls AWS STS AssumeRoleWithWebIdentity with the OIDC token
• Returns temporary credentials with auto-refresh

What RRSA needs:

• ACK injects ALIBABA_CLOUD_OIDC_TOKEN_FILE, ALIBABA_CLOUD_ROLE_ARN, ALIBABA_CLOUD_OIDC_PROVIDER_ARN
• Call Alibaba STS AssumeRoleWithOIDC with the OIDC token + provider ARN
• Return temporary credentials with auto-refresh

References:

• Alibaba Cloud RRSA documentation
• Alibaba Cloud AssumeRoleWithOIDC API
• Tempo S3 credential chain source
• PR #320 - Original IRSA support
• aliyun/credentials-go - Go SDK for RRSA