The Emerging World of Workload IAM

by Ramanan Subramanian on January 12, 2024

Ramanan Subramanian

An increasing number of Non-Human Identities

In the era of cloud computing, the proliferation of non-human identities has been remarkable. Businesses increasingly rely on software workloads like applications, services, and scripts, necessitating unique identities for accessing cloud resources. Microsoft research indicates that organizations often have five times more software workloads than human users. This surge in non-human entities, however, brings challenges to security. If compromised, workload (a non-human entity) access allows attackers to infiltrate and navigate organizational systems. Consequently, understanding and securing these identities is critical to corporate cybersecurity strategies.

Human and Non-Human Identities

Despite their inherent differences, human and non-human identities share several core requirements. Both necessitate robust access control mechanisms, need to adhere to policy controls, and must be governed effectively. However, the approach and technology used to manage these identities differ. For example, human identities are often managed through user-friendly interfaces centered around privacy and seamless user experiences, whereas non-human identities prioritize automated management and ownership clarity. This table provides a comparison, highlighting how non-humans and humans differ in the types of credentials they use and how policies are implemented and managed for each.

	Non-Human	Human
Authentication	Credentials such as certificates, keys, secrets	Identifiers and credentials (e.g., username and password, passwordless methods, MFA)
Operations	High level of automation	User-centric journeys and experiences
Persona	DevOps, DevSecOps: CI/CD, IAC focused	IT: User experience (UX) focused
Policy Implementation	Policy defined through code	Policy authoring via roles, often with the aid of low-code/no-code tools

Distinguishing Identities, Identifiers, and Credentials

It helps to distinguish these three key terms, which are often confused and used interchangeably.

Identities: The concept of identities in technology spans various terms and forms. These can be accounts, applications, service accounts, and other types of service identities. Each identity is represented as an object that is uniquely identified by an identifier, which could be local or centralized.
Identifiers: The identifiers and their naming conventions are specific to the platform. Human identities are often stored in systems like Active Directory, where they are identified using distinguished names (DNs). Meanwhile, service accounts and containers might use different, platform-specific identifiers.
Credentials: In terms of credentials, humans typically use passwords linked to their identity in the directory. On the other hand, non-humans use a wide array of credentials across various systems, each serving distinct purposes. Server credentials, like TLS server certificates and SSH host keys, are used to authenticate a non-human’s identity to others. Client credentials, such as OAuth 2.0 credentials, API keys, or client certificates, are used by non-humans to connect to external systems. These diverse types of credentials necessitate different handling and management approaches. Let us examine these elements for an everyday use case of S3 access.

A Key Use Case of S3 Access

Consider a scenario where a software workload requires access to an Amazon S3 bucket. In this case, the workload identity would need specific credentials to authenticate and access the S3 resource. This process involves multiple components - an identity provider (or trust provider) to validate (aka attest) the identity, a credential provider to issue the necessary credentials, and a resource access policy to govern the workload's actions on the S3 bucket. This use case illustrates the complexity and necessity of managing workload identities distinct from human identities.

Converged access diagram

Workload: In our S3 access scenario, the initiator workload is the entity that starts accessing the S3 resource. The workload could be a container, a virtual machine, or a serverless function. The initiator workload’s identity is crucial as it determines the level of access granted and the policies applied.
Target Service: In this context, the target service is the Amazon S3 bucket that the initiator workload seeks to access. The security and accessibility of this service depend heavily on the established Identity and Access Management (IAM) policies, ensuring that only authorized workloads can access or modify the data stored.
Identity Provider: The identity provider authenticates the initiator workload's identity. In a multi-cloud or hybrid-cloud environment, Ubyon Workload Attestor validates the identity of the workload before granting access to resources.
Credential Provider: Credential providers issue the necessary credentials for the workload to access the target resource. In our example, AWS IAM provides access keys or temporary tokens that the workload uses to authenticate with the S3 service.
Resource Access Policy: Resource access policies are crucial for defining what actions an authenticated identity can perform on a resource. For S3 access, this policy would specify which operations (like read, write, delete) the workload can perform on the bucket and its contents.
Workload Governance: Workload governance involves overseeing and managing the lifecycle of workload identities. This includes creating, maintaining, and retiring identities, monitoring their usage, and ensuring they adhere to security policies and compliance requirements.

Extending Coverage to IaaS, PaaS, and SaaS

The principles of workload IAM extend beyond just cloud storage access like S3. They are applicable across various cloud services, including IaaS, PaaS, and SaaS apps. Each service requires tailored identity and access management strategies to ensure secure and efficient operation. The list below summarizes Ubyon’s coverage of diverse workload IAM scenarios.

Workload IAM

Secured workload identity and access to cloud and enterprise resources that are public/private reachable

Components

Multi-tenanted Ubyon control plane
Ubyon workload agent
Private zero-trust access with TrustMesh

Initiator workloads

Native process
Virtual machines
Containers
Pods

Deployment

Helm Charts
Scripts

Management

IAC - Terraform
DX APIs
UI/ClickOps

Target workload and services

Cloud resources and services(PaaS)
Storage S3, PaaS out of the box
Cloud providers: AWS, GCP, Azure
Databases: RDS, MySQL, PostgreSQL, Redis
Data warehouse: Snowflake, Databricks

Resource access policies

Dynamic JIT policy
Conditional access policies
Long-term persistent policy

Credential providers

AWS
Azure
GCP
Hashicorp: Support for JWT, API Key, Username/Password, Certificate

Embrace Workload IAM with Ubyon

The rise of non-human identities has become a pivotal focus for wide-scale cloud adoption. Workload Identity and Access Management (IAM) is a critical capability required to meet the ever-evolving security demands of software workloads. With its innovative approach, Ubyon seamlessly integrates IAM for human and non-human entities, offering a unified solution that is proxyless and agentless.

Blog