# Aembit software architecture

> Explanation and illustration of Aembit's software architecture

Aembit is a cloud-native, multi-tenant SaaS Workload IAM platform for federated workloads that provides credential brokering and access policy enforcement across diverse infrastructure environments.

## High-level architecture overview

Aembit’s architecture consists of two primary systems:

* **Aembit Cloud**: A multi-tenant SaaS platform responsible for centralized management, policy enforcement, credential brokering, and audit logging.
* **Aembit Edge**: Lightweight components deployed in customer environments (Kubernetes clusters, VMs, CI/CD pipelines) that enforce access policies and broker credentials locally.

**Deployment:** Edge components deploy as containers (Kubernetes), VMs (Linux/Windows), or serverless functions (AWS Lambda/ECS Fargate). They require outbound HTTPS connectivity to Aembit Cloud (no inbound ports) and you can deploy them redundantly for high availability. Edge components are stateless, enabling flexible scaling. For detailed deployment options, see [Deploy Aembit Edge](/user-guide/deploy-install/).

### Key components

* **Workloads**: Applications or services (clients and servers) that require access to resources.
* **Access Policies**: Declarative rules that define which workloads can access which resources, under what conditions.
* **Trust Providers**: Integrations with identity providers (AWS, Azure, Google Cloud) to verify workload identities.
* **Credential Providers**: Integrations that securely issue short-lived credentials (cloud IAM tokens, database passwords) to workloads.
* **Audit logs and workload events**: Comprehensive logging of access requests, policy evaluations, and credential issuance for compliance and forensics.

## Architecture diagram

Below is a high-level D2 diagram representing Aembit’s architecture:

![High-level architecture showing Client Workloads requesting access through Aembit Edge, policy evaluation in Aembit Cloud, identity verification via Trust Providers, and credential issuance to access Server Workloads](/d2/docs/get-started/security-posture/architecture-0.svg)

Aembit’s deployment model shows three zones: Aembit Cloud (SaaS, managed by Aembit), Your Infrastructure (where you deploy Edge components), and External Systems (existing identity providers and target workloads). Numbered arrows show a typical access flow from workload request through policy evaluation to credential delivery.

## Security design principles

Aembit’s architecture follows modern security principles:

* **Zero Trust**: Aembit authenticates every access request via workload identity and authorizes it against policy, with no implicit trust based on network location. This prevents lateral movement even if an attacker gains network access.

  Technical example

  Even if a container runs inside your trusted VPC, Aembit Edge requires identity attestation (via AWS IAM Role, Kubernetes Service Account, etc.) and policy evaluation before granting credentials. Network location alone is never sufficient. A compromised pod in your Kubernetes cluster can’t access production databases without valid service account credentials and an Access Policy authorizing that specific workload.

* **Least Privilege**: Aembit issues credentials dynamically for specific access requests only, with minimal scope and short validity periods. No long-lived static credentials exist in workload configurations or environment variables.

  Technical example

  When your application requests database access, Aembit issues credentials scoped to only that database. Each credential has a configurable TTL. The credential never exists in your container’s environment variables or configuration files. It’s delivered just-in-time via the Aembit Edge proxy. If an attacker dumps your container’s memory or environment, they won’t find static database passwords.

* **Defense in Depth**: Multiple security layers protect credential access: identity attestation at Edge, policy evaluation in Cloud, credential generation by providers, and audit logging at all stages. Compromise of any single layer doesn’t expose credentials.

  Technical example

  To access AWS S3, a workload must first pass identity verification at Edge (a valid Kubernetes service account token). It must then match an Access Policy in Cloud (including any time-based or IP-based conditions) and receive temporary AWS STS credentials from the Credential Provider. An attacker who compromises only the Edge component can’t forge credentials without also controlling the Cloud policy engine and STS credential generation.

* **Separation of Duties**: Separate components with distinct responsibilities handle identity verification (Trust Providers), policy decisions (Aembit Cloud), and credential issuance (Credential Providers). No single system has full control over access decisions.

  Technical example

  AWS validates workload identity via IAM roles (Trust Provider), Aembit Cloud evaluates Access Policies based on that identity, and then AWS STS issues temporary credentials (Credential Provider). No single component can unilaterally grant access. The Trust Provider can’t issue credentials, and the Credential Provider can’t override policy decisions. This separation limits the blast radius of any individual component compromise.

## Next steps

**To validate how this architecture addresses specific security scenarios:**

* [Threat Model](/get-started/security-posture/threat-model) for how the architecture prevents common attacks
* [Use Cases](/get-started/use-cases/) for practical security scenarios

**To plan your deployment:**

* [Deploy Aembit Edge](/user-guide/deploy-install/) for deployment overview and planning
* [Kubernetes Deployment](/user-guide/deploy-install/kubernetes/kubernetes) for Kubernetes clusters
* [VM Deployment](/user-guide/deploy-install/virtual-machine/) for Linux/Windows VMs
* [Serverless Deployment](/user-guide/deploy-install/serverless/) for Lambda/ECS Fargate
* [CI/CD Deployment](/user-guide/deploy-install/ci-cd/) for GitHub Actions and GitLab

**To understand component details:**

* [Aembit Edge Concepts](/get-started/concepts/aembit-edge) for Edge component details
* [Aembit Cloud Concepts](/get-started/concepts/aembit-cloud) for Cloud architecture details
* [How Aembit Works](/get-started/how-aembit-works) for end-to-end system flow

**To explore conceptual foundations:**

* [Conceptual Overview](/get-started/concepts/) for core concepts and terminology
* [Access Policies](/get-started/concepts/access-policies) for policy evaluation flow
* [Trust Providers](/get-started/concepts/trust-providers) for identity verification concepts