Planes and responsibilities
Aembit divides its work between two planes, and each plane has its own users, interfaces, and responsibilities. Understanding the split tells you which part of the documentation applies to you. Administrators and automation work in the management plane, and your workloads interact with the control plane at runtime. This page explains what each plane does, who works in it, and how the two interact when a workload requests access.
The two planes
Section titled “The two planes”The management plane is where people and automation define the Aembit configuration. That configuration is the 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 and the components each one binds. A 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 verifies a workload’s identity. A 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 supplies the credential. An Access Policy authorizes a specific 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 to reach a specific Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more.
Three interfaces write that same configuration: the Tenant UI of your Aembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more, the Cloud API, and the Terraform provider, which is itself a Cloud API client.
The control plane authorizes workload access at runtime. When a workload requests access, the control plane verifies the workload’s identity through attestation, evaluates the Access Policy, and brokers the credential the workload needs. Nobody works in the control plane directly: 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 components and the Edge SDK, Edge API, and Aembit CLI talk to it on a workload’s behalf.
The two planes never trade jobs. No workload gets a credential through the management plane, and no one configures Access Policies through the control plane.
| Plane | Who works there | Interfaces | Responsibility |
|---|---|---|---|
| Management plane | Administrators, security engineers, and platform automation | Tenant UI, Cloud API, Terraform provider | Define and maintain the Access Policies and their components, and audit access |
| Control plane | Workloads, through Aembit Edge components or the runtime paths | Agent Proxy, Edge SDK, Edge API, CLI | Verify identity, evaluate the Access Policy, and broker the credential |
Both planes run in 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, and About Aembit Cloud covers the internal architecture of each.
Who does what
Section titled “Who does what”Administrators and security engineers work in the management plane. They create the Access Policies and their components, decide which workloads may reach which services, and review authorization events. Their home in the documentation is the User Guide.
Platform and DevOps engineers also work in the management plane, but through automation. They script configuration through the Cloud API or declare it as Terraform code, so the same Access Policies and their components become repeatable and version-controlled.
Developers decide how their workload participates in the control plane at runtime. Their only decision is where the credential handling lives. That handling lives in infrastructure with Agent Proxy, in code with the Edge SDK or Edge API, or in the shell with the Aembit CLI. Their home in the documentation is the Developer Guide.
The persona split is independent of the plane split, because every integration needs the management-plane configuration to exist first. Whether a security engineer creates that configuration in the Tenant UI or a pipeline creates it through Terraform changes nothing about how the workload retrieves its credential. Any pairing works: Agent Proxy with UI-managed configuration is the zero-code pattern, and the Edge SDK with Terraform is the everything-as-code pattern.
How the planes interact at runtime
Section titled “How the planes interact at runtime”A single access request touches both planes in a fixed order:
- An administrator or a pipeline defines the Access Policy in the management plane.
- The management plane distributes the configuration to the control plane.
- The workload makes a request, and an Aembit Edge component or a runtime path presents the workload’s attestation to the control plane.
- The control plane verifies the identity, evaluates the Access Policy, and brokers the credential.
- The credential returns to the Aembit Edge component or the workload, and the authorized request proceeds to the Server Workload.
Next steps
Section titled “Next steps”- Developer Guide overview - Choose the runtime path for your workload and the interface for your configuration
- User Guide - Configure and administer the Access Policies and their components in the Tenant UI
- About Aembit Cloud - The internal architecture of the control plane and management plane
- About Aembit Edge - The customer-side components that enforce authorization decisions