Secretless Cloud IAM
In cloud environments, credential security is paramount. Relying on long-lived credentials—such as access keys, service account keys, or client secrets—poses significant risks because they remain valid until explicitly rotated or revoked. If compromised, these credentials provide attackers with sustained access until they are replaced.
A more secure and industry-best practice is to use ephemeral credentials. These are short-lived, automatically rotated, and expire after a predetermined period. This approach significantly reduces the attack surface; even if credentials are compromised, they quickly become invalid, mitigating potential damage.
This resource highlights the key differences between long-lived and ephemeral credentials, offering real-world scenarios and code examples for assuming roles across major cloud providers.
This resource highlights the key differences between using long-lived credentials and ephemeral credentials, offering real-world scenarios and code examples for assuming roles across major cloud providers:
Service
Bad Practice
Good Practice
Bad PracticeIAM Access Keys
IAM Access Keys
IAM Access Keys, even when securely stored (such as in environment variables), due to their long-lived nature, remain active and valid until manually rotated or revoked. This poses a security risk as they provide continuous access if compromised.
Good PracticeIAM Roles
IAM Roles
The more secure approach is to use ephemeral credentials through AWS IAM roles. These credentials are short-lived and dynamically generated, limiting their validity. Even if compromised, they are only valid for a short time, drastically reducing the risk window.
Bad PracticeClient Secrets
Client Secrets
Even when stored securely in environment variables or secret management systems, long-lived service principal credentials (such as Client Secrets or Certificates) remain valid indefinitely unless manually rotated, which introduces risk. And so even though the credentials are securely retrieved, they are long-lived, meaning if they are compromised, attackers will have persistent access until the credentials are rotated or revoked.
Good PracticeManaged Identities
Managed Identities
Managed Identities provide a more secure alternative to using the standard IAM credentials in Azure, by eliminating the need for long-lived credentials. Managed Identities are automatically managed by Azure and are short-lived, reducing the attack surface.
Bad PracticeService Accounts Keys
Service Accounts Keys
Service account keys, even when stored securely, provide persistent access, which becomes a security risk if the keys are exposed. They are valid for extended periods, requiring manual intervention for rotation or revocation.
API Keys
Good PracticeWorkload Identity Federation
Workload Identity Federation
Workload Identity Federation eliminates the need for long-lived service account keys, using short-lived tokens that are automatically managed.
By using Workload Identity Federation, the credentials are ephemeral, automatically rotated, and valid only for short durations. This eliminates the need for long-lived service account keys and significantly reduces the risk of long-term exposure.
No Alternative