When organizations used to build applications in the past (mostly on-prem, but also in the public cloud), a common practice for allowing services to authenticate between each other was to create a service account (sometimes referred to as an application account) and embed its credentials in code or configuration files.
Another common way to gain access to services was to use static credentials such as keys. To name a few examples – AWS IAM user access keys, Azure shared access signature (SAS) tokens, or Google service account keys.
In this blog post, I will explain the risks related to using static credentials and provide recommendations when designing and building modern applications in the cloud.
Introduction to static credentials
Before we begin a conversation about static credentials, it is important to under why we need them in the first place.
Naturally, we don’t want to use a human (such as a developer, a DevOps or a DBA) credentials as part of code or configuration files to authenticate an application component (such as an API endpoint, or a front-end web application) to a backend service (such as a database, storage, message queue, etc.)
The most common practice for many years, which originated in on-prem legacy applications, was to create a service or application account and use it for non-interactive login.
Such identities are now known as NHI (or non-human identity), and since they were used as part of applications, and not as part of human/interactive login, they used to have static credentials (hopefully, long and complex passwords), and in most cases, their credentials were kept permanent and were never replaced (i.e., long-lived credentials).
Static credentials risks
Static credentials create persistent and often invisible weaknesses in cloud environments, offering attackers simple entry points while limiting an organization’s ability to detect misuse, enforce strong controls, or contain incidents effectively.
Below is a list of risks relating to the use of static credentials:
- High blast radius - Broad, persistent access makes any compromise immediately severe.
- Susceptibility to accidental exposure - Frequent real-world leaks through code repos, logs, and CI artifacts make this a major threat vector.
- Lack of automatic short-lived expiration - Keys remain valid long after they should not, enabling silent long-term abuse.
- Difficult rotation and poor key hygiene - Operational friction leads to rarely rotated, aging credentials that attackers can exploit for extended periods.
- No strong binding to workloads - Attackers can use stolen credentials from any location or infrastructure, increasing exploitability.
- Credential reuse across environments - Compromise of a single environment cascade laterally, expanding impact.
- Limited visibility and enforcement - Weak contextual signals hinder detection and prevent the application of strong access controls.
- Target for automated reconnaissance - Attackers routinely harvest exposed keys, though the actual impact depends on whether exposure occurs.
- Poor alignment with zero trust principles - Creates structural security gaps but typically manifests through other higher-ranked risks.
- Operational drag on incident response - Increases containment time but is a downstream effect rather than a primary threat.
Vault as an interim solution
In the past, organizations used to deploy solutions such as CyberArk Privileged Access Manager or BeyondTrust Password Safe.
As organizations began to embrace the public cloud, organizations began to use managed secrets managers such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or HashiCorp Vault (as a vendor-agnostic solution).
Although the mentioned solutions assisted in managing the entire lifecycle of static credentials (from generation, storage, retrieval and revocation), and the credentials weren’t as long as in the past, it still kept the problem of having static credentials.
The Long-term solution
The recommended solution is to avoid long-lived credentials when building modern applications in the cloud.
The alternative to using short-lived credentials depends on the use case.
General purpose
For most cloud workloads (such as compute, storage, database, messaging, integration, APIs, etc.), use one of the following solutions:
- AWS IAM Role - is a temporary permission identity that workloads or users can assume to access AWS resources without relying on long-lived credentials.
- Managed identities - Azure-provided workload identities automatically tied to Azure resources, giving them token-based access to cloud services without requiring you to create, store, or rotate any credentials.
- Entra workload identities - the broader category of non-human identities (such as service principals, app registrations, and federated identities) used by applications or services to authenticate to Microsoft Entra ID, including workloads that run outside Azure or require flexible, cross-platform identity options.
- Google Managed workload identities - short-lived, automatically managed identities that allow Google Cloud workloads to authenticate securely without using long-lived service account keys.
Managed Kubernetes
For allowing Pods within a managed Kubernetes environment access to cloud services, use one of the following solutions:
- AWS EKS Pod Identity - lets Kubernetes pods in an Amazon EKS cluster assume an IAM role and receive temporary credentials.
- Microsoft Entra Workload Identity for AKS - enables pods in an AKS cluster to use Kubernetes service-account tokens, which are exchanged for Azure AD tokens.
- Workload Identity for GKE - allows workloads in a Google Kubernetes Engine cluster to use Kubernetes service accounts that map to Google IAM identities.
External (Federated) Identities
For scenarios that you need to grant access to external/federated identities through OIDC, temporary (or short-lived credentials) to resources in the cloud eco-system, use one of the following solutions:
- AWS Security Token Service (AWS STS) - issues short-lived, scoped credentials that external or federated identities obtain through the AssumeRole API, allowing them to access AWS resources temporarily without relying on long-lived access.
- Azure Workload Identity Federation - allows external or non-Azure workloads to exchange their trusted identity tokens for short-lived Microsoft Entra tokens, enabling secure access to Azure resources without storing long-lived secrets.
- Google Workload Identity Federation - lets external or non-Google Cloud workloads exchange trusted identity tokens for short-lived Google Cloud credentials, enabling secure access without using long-lived service account keys.
AI Agents
For scenarios that you need to grant access to AI agents, access to resources in the cloud eco-system, use one of the following solutions:
- Amazon Bedrock AgentCore Identity - Purpose-built IAM service for Bedrock agents with centralized agent identity directory, inbound authorizer (SigV4/OAuth/JWT), and outbound credential provider.
- Microsoft Entra Agent ID (PREVIEW) - Extends Entra security to AI agents via special service principals with Conditional Access, Identity Protection, Governance, Network Controls, and developer platform for scalable agent lifecycle management and token issuance.
- Vertex AI IAM role - Standard GCP IAM roles/service accounts granted to Vertex AI workloads for accessing resources like Storage/BigQuery via ADC; no agent-specific abstraction.
Summary
When managing non-human identities, always prefer temporary (roles/managed identities) over static or long-lived credentials.
If the target service does not support temporary credentials, use short-lived credentials and regularly rotate the credentials to avoid potential credential breaches.
Whatever you do, never store credentials as part of code, configuration files, Git repositories, etc.
This blog post focused on solutions offered by the hyper-scale cloud providers; naturally, there are commercial solutions offering similar functionalities, including a single pane of glass for managing non-human identities for the entire cloud environments, including multi-cloud environments.
Disclaimer: AI tools were used to research and edit this article. Graphics are created using AI.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (0)