Client Workloads represent the software applications, scripts, or automated processes that initiate access requests to Server Workloads. 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 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 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 that links the identified Client Workload to the target Server Workload.
-
Authentication and Authorization - The Access Policy’s Trust Providers cryptographically verify the Client Workload’s identity, and any Access Conditions are evaluated.
-
Credential Retrieval - If access passes authorization, Aembit obtains the necessary credentials from the configured Credential Provider.
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.