By David Goldschlag, CEO and co-founder of Aembit

Imagine a typical day for a DevOps professional: buried in lines of code, orchestrating seamless interactions between applications, and managing the incessant flow of data across diverse environments. It's easy for identity and access, the very cornerstone enabling all these operations, to go unnoticed and underappreciated in the hustle to build, test, and deploy software quickly and reliably.

Yet the importance of managing machine-to-machine interactions has never been more pronounced, as applications evolve from monolithic to dynamic and distributed. All of this is driven by API-first and cloud-native environments, in addition to serverless functions and microservices architectures, the territories that modern DevOps practitioners call home.

While digital transformation has made systems faster and more scalable and flexible, it has yielded a subtle-yet-critical byproduct: For these modern systems to flourish, their components and functions - which we like to term "workloads" - must exhibit seamless interaction and communication, often traversing through third-party and multicloud environments. This necessitates that we are able to manage, enforce, and audit application-layer access controls between workloads by defining application-layer access policies to identify client workloads and to issue access credentials.

Workload identities now outnumber human identities 10:1 - double that of 2021, according to a recent report from Microsoft. Yet, as an industry, we are still in the very early stages of adequately securing non-human identities.

Digital workloads are increasingly becoming a focal point for attackers, not just a background element of your infrastructure. Whether it's a custom application, off-the-shelf software that you've deployed, a microservice, or a third-party API, these components often have extensive access to sensitive data and systems. A compromised workload can be the launching pad for sophisticated attacks, causing not just data exposure but potentially crippling business operations.

Open-source frameworks like Istio and SPIFFE have arrived to help address this challenge, laying the groundwork for secure interactions. However, there's a pressing need for strategies that can be implemented today across trust domains, while going beyond mere identity verification, to also encompass policy enforcement and contextual decision-making.

Here is specifically why the current state of machine-to-machine IAM is failing DevOps and security practitioners, and why workload identity and access management (IAM) should resemble a holistic approach that addresses diverse interactions, variable trust levels, and auditing and compliance requirements.

1)   Secrets Aren't Good Enough

When it comes to workload communication, secrets serve as the primary method to secure and authenticate interactions between workloads. However, secrets, especially those with extended lifespans that have been hardcoded into configuration files or disseminated through spreadsheets, offer a protracted opportunity for adversaries to uncover and exploit them. Adopting modern practices requires using and regularly updating temporary tokens that are time-bound. This means that even if a token is exposed, the damage is limited because the token is designed to be short-lived.

Secrets managers are good at managing secrets, but that misses the point: In order to access the secrets manager, you often need an identity secret, and possession of an access secret implies that access is authorized. Thus they fall short in offering a comprehensive and centralized approach for securing workload communications.

2)   Cross-Platform Environments Present Challenges

Picture this: Your AWS environment is humming along perfectly, thanks to meticulously configured AWS IAM roles. But the moment you cross the proverbial border to Microsoft Azure, Google Cloud, or any other cloud provider, including specialized SaaS or PaaS providers like Salesforce or Heroku, your AWS IAM roles become unrecognized and inapplicable.

Different cloud providers may use different data schema definitions, meaning the way they organize, categorize, and manage data may vary. These variations can pose a problem when trying to manage workload identities spanning different cloud environments, as the identity attributes defined under one schema may not be interpreted or recognized the same way under a different schema.

This scenario typically compels teams to devise new IAM policies for each cloud environment they operate in, considering the distinctive services and resources each provider offers. While these new policies are essential to govern access and permissions specific to the new environment, the effort involved in configuring similar policies across multiple platforms is redundant, leading to delays in deployments, elevated operational costs, and potential risks due to discrepancies in security protocols.

Mapping between environments needs to be done pairwise, which can lead to an "m times n" complexity problem. What you really want is a single point through which identities and access policies are brokered, reducing complexity to "m + n."

3)   Zero Trust Isn't Just a User Need

Zero Trust, with its foundational "never trust, always verify" principle, has been widely praised and adopted for its ability to uniquely address the remote and hybrid worker needs of the modern enterprise. It manages and secures user identities by viewing every person as a potential threat. There's no inherent trust granted to users based on their network location.

Translating this to workloads, especially in diverse and multicloud setups, is crucial. It ensures every interaction between workloads is authenticated and validated, mitigating risks associated with unauthorized access.

The Zero Trust model for users also includes conditional access, which treats the security and posture of the user's laptop as part of the access policy, along with user identity. With workloads, the situation is similar: Each access request is evaluated based both on the workload's identity and on its context and accompanying conditions, ensuring heightened security levels by allowing access only after thorough validation. This approach ensures that only workloads that meet predefined security criteria can access specific resources or communicate with other machines. For example, workloads with up-to-date security patches and robust security configurations may be granted broader access.

Conclusion

Workloads have surpassed human identities in sheer numbers and exhibit immense diversity in today's multifaceted IT environments, making the task of managing and securing these identities a pivotal concern. Addressing this requires a unified approach that goes beyond traditional solutions - and standards. But the renaissance will happen sooner than you think. And someday, in the not-too-distant future, we'll equate workload identity with having the same degree of maturity as user identity.

++

Join us at KubeCon + CloudNativeCon North America this November 6 - 9 in Chicago for more on Kubernetes and the cloud native ecosystem. 

##

ABOUT THE AUTHOR

David Goldschlag is the co-founder and CEO of Aembit. He previously founded several companies, including New Edge Labs, which is now Netskope's Zero Trust Network Access offering. Early in his career, David worked for the NSA and the Naval Research Laboratory, where he co-invented Onion Routing, which later became Tor.