With organizations like yours relying more heavily than ever on distributed systems, cloud computing, and interconnected APIs, the question of what – not just who – is allowed to execute a particular task within your digital footprint has never been more critical.
Over a decade ago, a potent mix of rising data breaches, tightening compliance rules, blossoming digital transformation, and BYOD policy implementation triggered massive adoption of user-based IAM. In today’s data-saturated, multi-cloud era, amid a meteoric rise of non-human identities, we’re witnessing a strikingly similar trend unfolding with workloads.
Just as your frontline workers are required to prove that they are who they say they are, so are the backend software components that interact with other software components to make your business thrive. Failing to ensure this, like we’ve seen with the perilous rise of phishing attacks and dark web-circulating user credentials, kicks open the door for further exposure and increased risk, as well as compliance violations.
Enter the concept of workload identity and access management (workload IAM), a security approach that bridges the gap between robust workload identity verification and the ability to simplify and accelerate application delivery to support your customers.
Workload IAM helps secure access between applications and other resources in single and multi-cloud environments, bringing a multitude of benefits for organizations, namely your DevOps and security teams. Workload IAM offers an enhanced level of control over application deployment, fostering reliable, efficient and secure operations. This, in turn, reduces the risk of unauthorized access and data leaks, supporting a DevSecOps approach where security is baked into every step of the development process. As a bonus, it also offers a clearer audit trail for compliance and investigatory purposes.
In the following sections of this post, we’ll examine the core concepts and key terms of workload IAM, address the critical questions surrounding this emerging approach, and detail how it can help you overcome the security and operational challenges of strongly identifying and authenticating workloads.
Primary Components of Workload Identity and Access Management (IAM)
Workloads
Understanding the concept of workload IAM starts with recognizing the wide array of computational tasks or processes involved in the digital operations of an organization, aka the star of our show – the workload.
Workloads can take various forms and operate in different environments. They include:
- Custom-built applications, designed and developed by your organization, operating in environments like AWS.
- Services, including database systems such as MySQL, PostgreSQL, or Snowflake, which provide key functionalities to support your operations.
- SaaS-based applications, like Salesforce or Microsoft Graph, that facilitate business processes without the need for local installation.
- Application programming interfaces (APIs) developed and maintained internally for your specific operations.
- Cloud-based APIs, such as Twilio or Stripe, which offer services that integrate with your existing system architecture.
- Serverless architectures, such as AWS Lambda or Google Cloud Functions, that allow your organization to build and run applications without managing servers. These can include function-as-a-service (FaaS) and backend-as-a-service (BaaS) solutions that trigger code in response to events or HTTP requests.
There are two categories of workloads: client workloads and server workloads. The difference between the two depends largely on the context of the interaction, where the “client” is the requester and the “server” is the responder.
A “client workload” refers to the applications or services that are requesting access to resources. They are essentially the consumers of data or services. For instance, in a microservices architecture, a client workload could be a service that is requesting data from another service.
On the other hand, a “server workload” refers to the applications or services that respond to these requests and provide the needed resources. They are the providers of data or services. Using the same example, in a microservices architecture, the server workload would be the service that is providing the requested data to the client workload.
Workload Policies
Policies determine what a given workload can and cannot do. This can apply to services, applications, APIs, or even specific functions within these. Policies for workloads can be very specific. For instance, you could have a policy that allows a workload to write data to a particular database, but not read from it. Or a policy might specify that a workload can access certain cloud resources but not others. When defining policies, it’s also essential to consider context. You might want to limit certain workloads’ actions based on time, the state of the system, or the risk level associated with a request.
It is important to distinguish between authentication, authorization, and access policies in the context of workload IAM. Workload IAM primarily focuses on defining and enforcing access policies, which serve as the bridge between a client workload’s authentication (its identity) and authorization (the permissions it has with respect to a server workload).
These policies map out the roles that each client workload assumes based on their identity. Conditional access policies, meanwhile, are rules that apply in specific conditions like location, time of day, health of client workload, or source IP address. These policies add an extra layer of control, as they consider the context of access, not just the client’s identity.
Therefore, workload IAM does more than verifying the ‘who’ (identity) or the ‘what they can do’ (authorization) – it determines ‘under what conditions’ these operations can be performed.
Workload Secrets
In the context of workload identity, “secrets” typically refer to any data credential that can be used to identify and authenticate a workload. These can include items such as API keys, passwords, tokens, certificates, and encryption keys.
- API Keys: API keys are unique identifiers used to authenticate a user, developer, or calling program to an API, acting as a complex password providing access to the API’s features and data, allowing for controlled, secure interactions between different software components.
- Passwords: Passwords are character-based secrets used to validate the workload’s identity and provide it access to secure systems or data. Passwords, akin to API keys, need to be linked with a service account name. The account is representative of the workload identity; the password certifies this identity.
- Tokens: Tokens are digital credentials established post-workload authentication, signifying their access privileges. These can be used to securely access a server or application without constantly sending the service account name and password with each interaction. Tokens have different forms. Short-lived, or ephemeral, tokens, for instance, are produced dynamically and possess a brief lifespan.
- Certificates: Digital certificates, also known as SSL/TLS certificates, are cryptographic files that help to secure the communication between networks or devices. These files serve as digital means of identity verification, used in public key infrastructure schemes to authenticate entities. Private keys provide proof of ownership, where an entity uses a private key to “sign” some data, and third-parties can use the corresponding public key from the certificate to verify the signature, thereby proving that the client was the signer.
- Encryption Keys: An encryption key is a random string of bits used in the process of cryptographic algorithms to transform plain text into cipher text and vice versa, ensuring that data remains secure during storage or transmission by making it unreadable to unauthorized users.
Trust Providers
Trust providers are third-party systems or services that can attest to workload identities and provide information about the environment in which they operate with high reliability and trustworthiness.
An example of a trust provider is the AWS Metadata Service. This service, when queried, can provide a cryptographically signed instance identity document that includes information about the underlying compute instance (e.g., EC2 instance) on which the workload runs.
Attestation is the process of asserting the identity of a workload. This is related to, but not precisely like SPIFFE/SPIRE.
The Pros and Cons of Secrets Managers
Secrets are fundamental to a workload’s digital identity and act as a unique virtual fingerprint, demonstrating its authenticity. However, many applications rely on static or long-lived credentials — secrets that are seldom updated and are frequently hardcoded within the applications themselves.
This is where technology like secrets managers come into play – they securely store, retrieve, and rotate these secrets. However, their limitation lies in their inability to centrally manage access. This often means that when these secrets are used to access a specific workload, the process can be indirect and require manual effort, leading to an overreliance on shared secrets for convenience sake.
More specifically, secrets managers fail to solve the problem of getting the secret into the secrets manager (the “secrets provisioning problem”) or the problem of getting the key to the correct and authorized client (the “last-mile problem”). Another way to look at it is that although secrets managers are a good place to store secrets, they don’t automate the lifecycle of the secret, which must be carefully handled to prevent exposure. Managing secrets thus distracts administrators from what they really want and need to do: manage access.
On the other hand, with workload IAM, when a client workload needs to access a service, the client workload authenticates to the platform. After verifying the identity of the client workload, workload IAM checks an access policy (is the client allowed to access the service?). If the access policy says ‘yes,’ then the IAM platform returns an access credential to the client. The credential may contain the client’s identity, but it also serves to map the client to a role or account, which defines for the service what rights the client has.
Identify vs. Access: Two Categories of Secrets
Within the context of workload IAM, it’s essential to differentiate between secrets utilized for identification and those employed for enabling access. Identifying secrets validate the workload’s identity, thus facilitating the regulation of access controls. Conversely, access-enabling secrets primarily enable workload access.
For example, Aembit Workload IAM typically distributes these access credentials to a proxy for the client workload, using a process known as attestation for authentication. This ‘secretless’ method authenticates the client workload by confirming its identity and integrity, eliminating the need for traditional secret-based identification. This not only enhances the security of the system but also streamlines the overall process of workload IAM.
Workload Logging and Auditing
Maintaining a comprehensive inventory of workload identities, meticulously tracking their activity, and periodically reviewing and updating their access rights is essential for creating a detailed audit trail that records who did what and when in your system environment. Keeping an exhaustive log of workload activity offers several benefits, including:
- Visibility: Logging provides a clear view of how your workloads interact with each other and with external systems. You can trace every transaction and pinpoint exactly what each workload is doing at any given moment. This is a huge boost to the efficiency of operations, as sometimes things go wrong, and access logs help you understand exactly what is happening.
- Security Analysis: When a security incident occurs, logs provide valuable data for forensic analysis. You can trace the actions of a potentially compromised workload, helping you understand the extent of a breach and plan your response accordingly.
- Compliance and Auditing: Earlier we mentioned that more stringent compliance regulations and requirements has helped to drive the IAM market, both for users and workloads. Several regulatory and industry frameworks, including HIPAA, GDPR, and PCI-DSS, mandate businesses to keep precise records of data access and interaction. Logging supports these obligations by delivering an exhaustive history of workload-related operations and transactions. PCI-DSS in particular, which is critical for organizations handling cardholder data, stipulates stringent access control measures, thus reinforcing the necessity for robust IAM solutions.
Workload Identity in Cloud Platforms
Popular public cloud platforms handle workload identity in various ways. For instance, Google Kubernetes Engine (GKE) uses its Workload Identity feature to allow workloads to authenticate to other Google Cloud services. AWS and Azure have similar features (IAM roles for Amazon EC2 and Managed Identities for Azure resources, respectively).
Keep in mind that while these cloud environments can provide rich IAM capabilities, users are limited to each cloud vendor’s environment and native services. For instance, AWS IAM can manage access to AWS services, but not to services offered by Azure or SaaS Applications.
Even within the same cloud environment, IAM complexities can arise, such as the federation between Amazon EKS (Elastic Kubernetes Service) and AWS IAM. This integration allows EKS workloads to assume an IAM role for accessing other AWS services through a feature called IAM Roles for Service Accounts (IRSA), using OpenID Connect (OIDC) for identity federation.
Understanding these nuanced IAM interactions, even within a single provider’s environment, is key to securing your workloads
How Workload Identity Relates to APIs, Applications, and Services
Workloads can take on various forms. Here is a deeper dive into common categories of “workloads” and the role identity plays.
APIs
Application programming interfaces (APIs) play a pivotal role in managing workload identities. APIs often serve as the communication link between services, and with the use of workload identities, you can ensure only authorized workloads are allowed access. Workload identities can authenticate themselves to an API, proving that they are authorized to request specific operations. Workload IAM ensures that only authorized APIs can access and interact with a system’s resources in the ways they’re permitted to do so.
Applications
Applications are more complex entities that make use of APIs for performing their functions. They comprise multiple workloads that need to share resources and interact with one another, often within a microservices architecture. Here, the emphasis of workload identity lies in verifying the authenticity and permissions of the individual components or workloads that make up an application. Workload IAM, in this context, ensures secure inter-service communication and prevents unauthorized access to shared resources by giving each application or service within it a unique identity.
Services
In the context of cloud services, workloads often need to interact with various cloud-based services (like database services, to read from or write data). Workload identity can be used to authenticate and authorize these interactions, ensuring that each workload can only access the services and resources that it’s supposed to. For example, in a cloud-native Kubernetes environment, each service has an associated ServiceAccount which can be used as its workload identity for interactions with other services and resources. In a distributed computing environment, services often need to interact with one another to perform complex tasks. Workload IAM ensures these interactions are securely managed to prevent unauthorized access.
__________________
In summary, workload IAM provides a robust framework for securely managing who or what can access and execute workloads. This helps ensure that your APIs, applications, databases, and services are interacting securely, with minimized risk of unauthorized access, disclosure or data breaches. Understanding all that is involved with workload IAM is key to implementing a robust and secure cloud architecture and maturing your overall security and risk program.
In Part 2, we’ll dig into the “how” of workload IAM!
For more information on how Aembit can help you get started with workload IAM, visit aembit.io and try us for free.
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
