Client Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn more represent the software applications, scripts, or automated processes that initiate access requests to Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more. They’re the “clients” in Aembit’s client-server access model, acting as the requesting party that needs to consume services, APIs, or data from other workloads.
Unlike human users, Client Workloads operate autonomously without direct user interaction. They include applications like microservices, CI/CD pipeline jobs, serverless functions, background scripts, and AI agents that need to access databases, APIs, or other services as part of their automated workflows.
The core challenge Client Workloads solve is secretless authentication—eliminating the need to store and manage long-lived credentials like API keys or passwords within the workload itself. Instead, Aembit identifies and authenticates Client Workloads based on verifiable evidence from their runtime environment.
Start configuring Client Workloads See Client Workloads in the User Guide
→
How Client Workloads work
Section titled “How Client Workloads work”The following steps outline how Client Workloads function within Aembit’s access control flow:
-
Access Request - A Client Workload (for example, a microservice, CI/CD job, or Lambda function) attempts to access a Server Workload (for example, a database or API).
-
Send Identity Evidence - Aembit Edge: Aembit Edge represents components deployed within your operational environments that enforce Access Policies by intercepting traffic, verifying identities, and injecting credentials just-in-time.Learn more intercepts the request and collects identity evidence from the Client Workload’s runtime environment. This evidence varies by platform—for example, Kubernetes service account tokens, AWS instance metadata, or GitHub Actions OIDC tokens. Aembit Edge then sends this evidence to Aembit Cloud for processing.
-
Identity Matching - Aembit Cloud: Aembit Cloud serves as both the central control plane and management plane, making authorization decisions, evaluating policies, coordinating credential issuance, and providing administrative interfaces for configuration.Learn more compares the collected evidence against configured Client Workload definitions to identify which specific workload is making the request.
-
Policy Evaluation - Once identified, Aembit Cloud locates the appropriate Access Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more that links the identified Client Workload to the target Server Workload.
-
Authentication and Authorization - The Access Policy’s Trust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn more cryptographically verify the Client Workload’s identity, and any Access Condition: Access Conditions add dynamic, context-aware constraints to authorization by evaluating circumstances like time, location, or security posture to determine whether to grant access.Learn more are evaluated.
-
Credential Retrieval - If access passes authorization, Aembit obtains the necessary credentials from the configured Credential Provider: Credential Providers obtain the specific access credentials—such as API keys, OAuth tokens, or temporary cloud credentials—that Client Workloads need to authenticate to Server Workloads.Learn more.
The Credential Provider is specifically associated with the target Server Workload and knows how to generate or retrieve the appropriate authentication credentials (such as API keys, OAuth tokens, or database passwords) that the Server Workload expects.
-
Credential Injection - Aembit Edge injects the obtained credentials into the Client Workload’s original request and forwards the modified request to the Server Workload.
The following diagram illustrates this process:
Supported identification methods
Section titled “Supported identification methods”Aembit offers multiple identification methods tailored to different deployment environments, called Client Workload Identifiers. These enable you to accurately recognize Client Workloads based on their runtime context and platform-specific attributes.
Cloud Platforms
- AWS identifiers - EC2 Instance ID, ECS Task Family, Lambda ARN, IAM Role ARN, Account ID, and Region
- Azure identifiers - Subscription ID and VM ID
- Google Cloud identifiers - Identity Token claims
Container Orchestration
- Kubernetes identifiers - Pod Name, Pod Name Prefix, Service Account Name, and Namespace
CI/CD Platforms
- GitHub Actions identifiers - Repository and Subject claims from OIDC tokens
- GitLab Jobs identifiers - Namespace Path, Project Path, Ref Path, and Subject claims from OIDC tokens
- Terraform Cloud identifiers - Organization ID, Project ID, and Workspace ID from OIDC tokens
Virtual Machines and Generic
- Hostname and Process identifiers - System hostname, process name, process user, and source IP
- Aembit Client ID - Native Aembit identifier for edge cases
Aembit supports configuring multiple identifiers for a single Client Workload definition to increase specificity and prevent misidentification.
Benefits of using Client Workloads
Section titled “Benefits of using Client Workloads”- Secretless Authentication - Eliminates the need for Client Workloads to store or manage long-lived identity secrets like API keys or passwords.
- Environment-Native Identity - Leverages existing platform identity mechanisms (Kubernetes service accounts, cloud metadata, OIDC tokens) rather than introducing new credential management overhead.
- Precise Access Control - Enables granular policies that specify exactly which workloads can access which resources, supporting the principle of least privilege.
- Automated Credential Management - Handles the entire credential lifecycle automatically, from identity verification to credential injection, reducing operational burden.
- Audit and Compliance - Provides detailed logging of which workloads accessed what resources and when, supporting security monitoring and compliance requirements.