> For the complete documentation index, see [llms.txt](https://docs.coherent.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coherent.global/identity-and-access-management/client-credentials/eliminate-credential-rotation-with-managed-workload-identity.md). # Eliminate credential rotation with managed workload identity Stop managing secrets and certificates for machine-to-machine authentication. Use the identity your platform already manages. Keycloak can participate in this model by trusting a federated workload identity and accepting a signed token as the client assertion instead of requiring the Keycloak client to hold a long-lived secret or certificate. When applications authenticate using a client secret or certificate, the application owns a long-lived credential. That creates a lifecycle that must be managed: * Client secret: Protect and rotate. * Certificate: Protect the private key, monitor expiry, and rotate. Rotation is necessary, but it adds operational work, risk, and the possibility of failure. ## Eliminate the problem rather than process improvement Modern cloud platforms can provide workloads with an identity that is managed by the platform. Managed workload identity eliminates the need for application-managed credentials and their rotation lifecycle. With managed workload identity, the application does not store or manage secrets or private keys. The platform establishes the workload's identity and issues a short-lived signed token. The target identity provider or service validates that token and decides whether to issue or accept an access token. ```mermaid flowchart LR A[Workload] B[Cloud identity provider] C[Target identity provider / service] D[Access token / resource access] A -->|uses platform-managed identity| B B -->|issues short-lived signed token| C C -->|validates identity and authorization| D ``` The important architectural difference is that the workload does not possess any long-lived authentication credential. Trust is based on the workload identity and short-lived tokens issued by trusted identity providers. ## Why does this matter * No secrets to store, distribute, or rotate. * No certificate private keys to protect or certificates to renew. * Short-lived tokens reduce the impact of credential compromise. * Simpler operations and fewer credential-rotation failure modes. Where supported, the architectural objective is simple: Remove the credential. Remove the rotation. ## Managed identity across cloud platforms The terminology differs between cloud providers, but the principle is the same: give the workload a platform-managed identity and use short-lived credentials or tokens instead of application-managed secrets.
PlatformExamplePattern
Microsoft AzureMicrosoft Entra managed identitiesAzure resource obtains Entra tokens without storing application credentials.
AWSIAM roles for workloadsWorkloads such as EC2, ECS, Lambda, or Kubernetes use temporary role credentials instead of long-lived access keys.
Google CloudService accounts / workload identity federationWorkloads obtain short-lived credentials without maintaining service-account keys.
KubernetesService account / workload IdentityPod identity can be federated with a cloud identity provider instead of embedding cloud credentials in the pod.
The implementation is different in each platform, but the architecture remains the same: the workload proves its identity through the platform rather than by presenting a long-lived credential that the application team must manage. ## Keycloak as the target identity provider Keycloak supports this architecture through federated client authentication. Instead of authenticating a machine-to-machine client with a Keycloak client secret or locally managed certificate, Keycloak can validate a signed assertion issued for the workload by a trusted external identity provider. The result is the key architectural benefit: the Keycloak client no longer needs an application-managed credential. The workload obtains a short-lived identity token from its platform, presents it to Keycloak, and Keycloak validates the federated identity before issuing its own access token. ```mermaid flowchart LR A[Workload] B[Cloud identity provider] C[Keycloak] D[Protected API] A -->|uses platform-managed identity| B B -->|issues short-lived signed token| C C -->|Keycloak access token| D ``` ## Azure example Microsoft Azure implements this pattern through Microsoft Entra managed identities. Azure workloads can use system-assigned or user-assigned managed identities to obtain short-lived Microsoft Entra tokens without storing application credentials. For an overview of secretless authentication with Microsoft Entra managed identities, see: {% embed url="" %} A practical implementation is Microsoft Entra User-Assigned Managed Identity (UAMI) with Keycloak. The Azure workload obtains an Entra-signed JWT using its UAMI and presents that JWT to Keycloak as a federated client assertion. Keycloak validates the federated identity and issues its normal access token - without requiring a Keycloak client secret or application-managed certificate. For the implementation steps, including the Entra application role, UAMI authorization, Keycloak Identity Provider configuration, and Signed JWT – Federated client authentication, see: {% content-ref url="/pages/1sRoIBtGZWp6fjueSpdU" %} [MS Entra ID managed identity for client credentials](/identity-and-access-management/client-credentials/ms-entra-id-managed-identity-for-client-credentials.md) {% endcontent-ref %}