This topic provides an overview of how Aembit works, including its core architecture, key components, and the flow of access requests. It also covers the main components of Aembit, including Workloads, Access Policies, Trust Providers, Access Conditions,
Use the links in each section to dive deeper into specific topics related to how Aembit works or start configuring and using those features.
The core problem Aembit solves
Section titled “The core problem Aembit solves”Most organizations secure workload access using static, long-lived secrets (API keys, passwords, tokens) that are:
- Difficult to securely distribute and store
- Prone to leakage and theft
- Hard to rotate regularly
- A significant security risk when compromised
Aembit shifts this paradigm by managing access instead of secrets, using verifiable workload identity to secure communications without requiring applications to store credentials.
Core architecture
Section titled “Core architecture”Aembit consists of two main components:
Aembit Edge: The data plane
Section titled “Aembit Edge: The data plane”The data plane deployed in your environment that:
- Intercepts traffic from your applications
- Gathers identity information
- Injects credentials for seamless authentication
- Forwards traffic to target services
More on Aembit Edge See Core Concepts
→
Deploy Aembit Edge See the Aembit User Guide
→
Aembit Cloud: The control plane
Section titled “Aembit Cloud: The control plane”The control plane that:
- Makes policy decisions
- Verifies workload identities
- Issues credentials
- Provides administration tools
- Captures audit logs
More on Aembit Cloud See Core Concepts
→
Configure Aembit Cloud See the Aembit User Guide
→
Evaluation flow: How Aembit grants access
Section titled “Evaluation flow: How Aembit grants access”To understand how Aembit works, knowing how Aembit makes decisions when evaluating Access Policies is useful.
The following diagram is a simplified illustration of the Access Policy evaluation flow:
Access Policies follow a multi-step process to decide whether to allow a Client Workload to access a Server Workload:
-
Request Initiation & Interception - A Client Workload attempts to connect to a Server Workload.
-
Identify the Workloads - Aembit Edge observes the Client Workload’s identity using metadata from your environment—such as Kubernetes service account names, VM identity tokens, or cloud-specific signals.
-
Match request to an Access Policy - Aembit Cloud compares the request to existing Access Policies. If no policy matches both workloads, Aembit denies the request.
-
Verify Identity with Trust Providers (optional) - Aembit checks with a Trust Provider (like AWS, Azure, or Kubernetes) to verify the Client Workload’s identity. This process removes the need for long-lived secrets by leveraging native cloud or orchestration signals.
-
Evaluate Access Conditions (optional) - If the request matches a policy, Aembit checks whether it satisfies any extra conditions. For example, it might require the workload to run in a specific region or during certain hours.
-
Retrieve Credentials from a Credential Provider - When the request passes all checks, Aembit contacts the Credential Provider to retrieve the appropriate credential—such as an API key or OAuth token.
-
Inject the Credential - Aembit Edge injects the credential directly into the request, typically using an HTTP header. The Client Workload never sees or stores the credential.
Key components
Section titled “Key components”Aembit is built around several key components that work together to provide secure workload access:
Workloads: Non-human identities
Section titled “Workloads: Non-human identities”Aembit uses the term workload to refer to any application, service, or job that initiates requests to access other services or resources. Aembit organizes identities using two workload types:
- Client Workloads - Applications, services, or jobs initiating requests
- Server Workloads - Target APIs, databases, or services receiving requests
More on Client Workloads See Core Concepts
→
Configure Client Workloads See the Aembit User Guide
→
More on Server Workloads See Core Concepts
→
Configure Server Workloads See the Aembit User Guide
→
Access Policies: Defining access rules
Section titled “Access Policies: Defining access rules”Central to Aembit’s authorization model, Access Policies connect:
- A Client Workload (who wants access)
- A Server Workload (what they want to access)
- A Trust Provider (how to verify the client’s identity)
- Access Conditions (when/where/under what circumstances access is allowed)
- A Credential Provider (what credentials to issue)
Access Policies are the rules that define whether a specific Client Workload can access a specific Server Workload.
More on Access Policies See Core Concepts
→
Configure Access Policies See the Aembit User Guide
→
Trust Providers: Verifying identity
Section titled “Trust Providers: Verifying identity”Trust Providers verify Client Workload identity through environmental attestation rather than shared secrets. They support many platforms:
- AWS, Azure, and GCP environments
- Kubernetes clusters
- CI/CD pipelines (GitHub Actions, GitLab)
- On-premises systems via Kerberos
This “secretless” approach means your applications don’t need to store authentication credentials for their own identity.
More on Trust Providers See Core Concepts
→
Set up Trust Providers See the Aembit User Guide
→
Access Conditions: Adding context
Section titled “Access Conditions: Adding context”Access Conditions add contextual requirements to Access Policies, such as:
- Time restrictions
- Geographic location
- Security posture (via integrations with tools like Wiz or CrowdStrike)
This provides a Multi-Factor Authentication (MFA)-like strength for non-human access.
More on Access Conditions See Core Concepts
→
Set up Access Conditions See the Aembit User Guide
→
Credential Providers: Managing credentials
Section titled “Credential Providers: Managing credentials”Credential Providers obtain or generate the authentication credentials needed to access target services:
- Temporary cloud provider tokens
- OAuth tokens
- JWTs
- API keys
Aembit prioritizes short-lived, just-in-time credentials whenever possible.
More on Credential Providers See Core Concepts
→
Set up Credential Providers See the Aembit User Guide
→
Auditing logs: Tracking access requests
Section titled “Auditing logs: Tracking access requests”Aembit provides detailed audit logs of all access requests and administrative changes called Access Authorization Events.
More on Auditing See Core Concepts
→
Audit Aembit logs See the Aembit User Guide
→
Administrative capabilities: Managing Aembit
Section titled “Administrative capabilities: Managing Aembit”Aembit includes features for enterprise management:
- Resource Sets: Logically group resources by environment or team
- Role-Based Account Control (RBAC): Control administrative access within the platform
- Identity Providers: Integrate with existing identity systems for user management
- Audit Logging: Track policy evaluations and administrative changes
- Log Streams: Export logs to external systems for analysis
- And more…
More on Administration See Core Concepts
→
Configure Admin settings See the Aembit User Guide
→
Aembit Terraform Provider: Scaling Aembit
Section titled “Aembit Terraform Provider: Scaling Aembit”Aembit provides a comprehensive Terraform provider for managing configurations as code, enabling:
- Automated, consistent deployment
- Version-controlled configurations
- Integration with DevOps workflows
More on Aembit & Terraform See Core Concepts
→
Scale with Terraform See the Aembit User Guide
→