This topic explains how Aembit operates behind the scenes (at a high level) to provide secure, seamless access between workloads. Use the links in each section to dive deeper into specific topics related to how Aembit works or start configuring and using those features.
Aembit as an identity broker
Section titled “Aembit as an identity broker”Aembit operates conceptually as an identity broker. It acts as an intermediary, facilitating secure access requests initiated by a Client Workload (like an application or script) attempting to connect to a target Server Workload (like an API or database).
These workloads may operate across security boundaries or reside in different compute environments. For example, a Client Workload in AWS accessing a Server Workload in Azure. By centralizing the brokering function, Aembit helps you simplify the management of trust relationships and Access Policies across your disparate security boundaries and environments.
Aembit’s architecture
Section titled “Aembit’s architecture”Aembit consists of two cooperating systems: Aembit Edge and Aembit Cloud.
Aembit Edge communicates with Aembit Cloud to handle authentication and authorization of access between your workloads.
Separating the control plane and the data plane enables you to centralize policy management in the cloud while keeping the enforcement mechanism close to the workloads in your environments. The interception model employed by Aembit Edge is key to enabling the “No-Code Auth” capability.
Aembit Edge
Section titled “Aembit Edge”Aembit Edge acts as the data plane or interception point and runs alongside Client Workloads in your infrastructure (such as a Kubernetes cluster).
The primary function of Aembit Edge is to intercept outbound network requests from Client Workloads destined for target Server Workloads.
Upon interception, Aembit Edge sends requests from Client Workloads to Aembit Cloud which handles the authentication and authorization of that request. If Aembit Cloud approves access, then Aembit Edge does the following:
- Receives a credential from Aembit Cloud.
- Injects the credential into the original request “just-in-time.”
- Forwards the modified request to the intended target Server Workload.
Aembit Edge also sends detailed access event logs to Aembit Cloud for auditing purposes.
More on Aembit Edge See Core Concepts
→
Configure Aembit Edge See the Aembit User Guide
→
Aembit Cloud
Section titled “Aembit Cloud”Aembit Cloud acts as the control plane and receives requests intercepted by Aembit Edge.
Aembit Cloud determines whether to authorize Client Workload requests and what credential to deliver.
The primary functions of Aembit Cloud are to:
- Evaluate access requests.
- Authenticate Client Workloads and attest their identities through a Trust Provider.
- Enforce Access Policies (including Access Conditions such as GeoIP or time).
- Interact with external Credential Providers to obtain and issue necessary credentials.
- Communicate access decisions to Aembit Edge.
You can administer Aembit Cloud through your unique, and isolated Aembit Tenant to define access rules, configure trust and credential sources, and monitor access events.
Aembit Cloud logs all Access Authorization Events so you can audit and report metadata related to access control.
More on Aembit Cloud See Core Concepts
→
Configure Aembit Cloud See the Aembit User Guide
→
Access Policies
Section titled “Access Policies”Aembit uses Access Policies to control which Client Workloads can access which Server Workloads and under what conditions.
Access Policies evaluate the following components when making access decisions:
- Client Workloads - Any non-human entity that initiates an access request to consume a service or resource provided by a Server Workload.
- Trust Providers - Attest to workload identities and provide information about the environment in which they operate with high reliability and trustworthiness.
- Access Conditions - Criteria Aembit checks when evaluating an Access Policy to determine whether to grant a Client Workload access to a target Server Workload.
- Credential Providers - Systems that provide access credentials, such as OAuth tokens, service account tokens, API keys, or username-and-password pairs.
- Server Workloads - Software applications that serve requests from Client Workloads such as third-party SaaS APIs, API gateways, databases, and data warehouses.
For a simplified illustration of the Access Policy evaluation flow, see Evaluation flow: how Aembit grants access.
If a request meets all requirements, Aembit allows the connection and injects the credential. If any step fails, Aembit denies the request and logs the reason.
More on Access Policies See Core Concepts
→
Configure Access Policies See the Aembit User Guide
→
Trust Providers
Section titled “Trust Providers”Instead of Client Workloads managing and presenting a long-lived secret for authentication, Aembit uses Trust Providers to cryptographically verify the identity of Client Workloads attempting to access target Server Workloads. Trust Providers verify a Client Workload’s identity using evidence obtained directly from its runtime environment—also known as workload attestation.
Aembit integrates with many Trust Providers to support attestation across different environments:
- AWS
- Azure
- Kubernetes
- CI/CD platforms
- Aembit Agent Controller in Kerberos environments
Trust Providers supply cryptographically signed evidence, such as platform identity documents or tokens, about the Client Workload to Aembit Cloud. Aembit Cloud then validates this evidence to confirm the workload’s identity before proceeding with access policy evaluation. Upon successful attestation, Aembit Cloud gains high confidence in the Client Workload’s identity without relying on a shared secret.
More on Trust Providers See Core Concepts
→
Set up Trust Providers See the Aembit User Guide
→
Access Conditions
Section titled “Access Conditions”Aembit uses Access Conditions to provide a mechanism for adding dynamic, context-aware constraints to Access Policies—similar to Multi-Factor Authentication (MFA) for human identities.
Access Conditions allow Access Policies to incorporate rapid environmental or operational factors into the access decision. For example:
- Time - restrictions based on the time of day or day of the week
- GeoIP - geographic location of the requesting workload
During Access Policy evaluation, after Aembit Cloud matches the Client and Server Workloads to an Access Policy and it verifies the Client Workload’s identity, Aembit Cloud explicitly evaluates all associated Access Conditions. Only if all Access Conditions pass, along with the Client Workload’s identity check, does the Access Policy grant access and trigger the Credential Provider.
Aembit also integrates with external security posture management tools, such as Wiz or CrowdStrike. This allows Access Policies to enforce conditions such as “Aembit only grants access if Wiz reports a healthy security posture for that Client Workload.
More on Access Conditions See Core Concepts
→
Set up Access Conditions See the Aembit User Guide
→
Credential Providers
Section titled “Credential Providers”Aembit uses Credential Providers to facilitate secure authentication between workloads. Credential Providers generate and manage the credentials needed for a Client Workload to authenticate to a Server Workload when an Access Policy determines to grant a Client Workload access. Credential Providers abstract away the complexity of different authentication mechanisms and credential types, providing a consistent interface for workload-to-workload authentication regardless of the underlying systems.
When an Access Policy evaluation succeeds, Aembit Cloud triggers the Credential Provider to generate the appropriate credentials for the specific authentication mechanism that the target Server Workload requires. This interaction is what allows a Client Workload to authenticate to a Server Workload without storing or managing long-lived credentials. This design limits exposure and prevents credential sprawl.
Aembit supports many types of Credential Providers to accommodate different authentication requirements:
- Basic Authentication - For systems requiring username/password authentication
- OAuth 2.0 - For modern API authentication flows
- API Key - For services using API key-based authentication
- Certificate-Based - For systems requiring mutual TLS authentication
- Cloud Provider Credentials - For accessing cloud services (AWS, Azure, GCP) through Workload Identity Federation (WIF)
- SAML - For enterprise federated authentication scenarios
- Kubernetes Tokens - For Kubernetes-based workloads
You can also set up Credential Providers for external secrets management systems like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault to retrieve sensitive authentication material when needed.
To provide credential lifecycle management capabilities, Aembit offers Credential Provider integrations with services like GitLab to create, rotate, and delete access credentials on your behalf.
More on Credential Providers See Core Concepts
→
Set up Credential Providers See the Aembit User Guide
→
Observability
Section titled “Observability”Aembit logs every access request (Access Authorization Events) and administrative change. These logs help you understand what’s happening, troubleshoot problems, and meet compliance goals and requirements.
Aembit logs the following:
- Each request’s source, destination, and decision.
- The specific policy that allowed or blocked access.
- Details about which Trust Provider verified an identity.
- What credential Aembit delivered (or why it didn’t).
You can view this information in your Aembit Tenant UI or export it to external log systems for long-term storage and analysis by setting up a Log Stream.
See Audit and report
More on Auditing See Core Concepts
→
Audit Aembit logs See the Aembit User Guide
→
Administration
Section titled “Administration”Administration in Aembit provides a comprehensive framework for managing security policies, credentials, and access controls across your organization to control and monitor how your users access and use Aembit. To administer Aembit, you can do so through your unique, dedicated environment—your Aembit Tenant.
Aembit’s Administration UI provides centralized management of all Aembit’s primary components, including Access Policies. Additionally, you can configure and manage advanced Aembit Edge Component features such as TLS Decrypt, PKI-based TLS, proxy steering methods, and more.
Aembit’s administration system follows a Role-Based Access Control (RBAC) model, allowing you to delegate specific administrative responsibilities while maintaining the principle of least privilege.
Aembit’s administration capabilities include:
- Admin Dashboard - A central interface providing visibility into system status, recent activities, and security alerts.
- Users - Management of human users who interact with the Aembit administrative interface.
- Roles - Predefined and custom sets of responsibilities that you can assign to your users to control their administrative access.
- Permissions - Granular controls that define what actions your users can perform within your Aembit Tenant.
- Discovery - Tools for identifying and cataloging workloads across your infrastructure.
- Resource Sets - Logical groupings of resources that help organize and manage access at scale across your environment.
- Log Streams - Configuration for sending security and audit logs to external monitoring systems.
- Identity Providers - Integration with external identity systems for authenticating administrators.
- Sign-On Policies - Rules governing how administrators authenticate to the Aembit system.
About Aembit Tenants
Section titled “About Aembit Tenants”Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.
Each tenant operates independently with its own set of:
- Administrative Users - Users who manage the tenant have no access to other tenants.
- Resources - All workloads, policies, and configurations are tenant-specific.
- Security Boundaries - Complete isolation makes sure configurations in one tenant can’t affect others.
More on Administration See Core Concepts
→
Configure Admin settings See the Aembit User Guide
→
Aembit Terraform Provider
Section titled “Aembit Terraform Provider”Aembit supports scalable, repeatable infrastructure-as-code (IaC) workflows through the Aembit Terraform Provider.
Terraform gives you the ability to:
- Codify access policies and workload identity configuration.
- Version control changes to your identity and access infrastructure.
- Apply changes consistently across staging, production, and multicloud environments.
- Automate onboarding for new workloads, trust providers, and credential integrations.
This helps reduce manual steps, eliminate configuration drift, and ensure your access policies are reproducible and reviewable.
The Aembit Terraform Provider supports all core Aembit resources:
| Resource Type | Terraform Support |
|---|---|
| Trust Providers | ✅ Create and configure |
| Client Workloads | ✅ Manage identity matching |
| Server Workloads | ✅ Define endpoints, auth |
| Credential Providers | ✅ Integrate secrets/tokens |
| Access Policies | ✅ Authorize workload access |
| Access Conditions | ✅ Enforce dynamic controls |
| Resource Sets | ✅ Segment environments |
| Roles & Permissions | ✅ Assign fine-grained access |
This full coverage enables you to declare your Aembit configuration as code, just like cloud resources or Kubernetes objects.
More on Aembit & Terraform See Core Concepts
→
Scale with Terraform See the Aembit User Guide
→