--- updatedAt: 2026-02-03T09:52:00.000Z agentTools: projectIndex: https://docs.akeyless.io/llms.txt --- # Platform Components The Akeyless Platform is composed of several components that work together to provide identity security services without storing or reconstructing full private keys or long-lived secrets. This page describes each component’s role at a high level. ## High-Level Components * **Akeyless Platform** (SaaS control plane) * Internal **Key Fragment Managers (KFMs)** and the **Unified Access Manager (UAM)** * **Akeyless Gateway** (customer-deployed) * **Connectors** and **Targets** * **Client Tools** (CLI, SDKs, API) * Optional **Customer Fragment (CF)** in the customer environment Distributed Fragments Cryptography (DFC) and the Zero-Knowledge Encryption architecture are implemented across these components but are described in detail on their dedicated pages. *** ## Akeyless Platform (SaaS Control Plane) The Akeyless Platform is the cloud-hosted control plane that coordinates identity operations. It is responsible for: * Authenticating users, services, and workloads * Evaluating authorization policies (RBAC and ABAC) * Managing metadata for keys, secrets, and certificates * Orchestrating cryptographic operations using DFC * Providing administrative interfaces (UI, API) * Recording audit events and operational metrics Key characteristics: * The platform never stores complete private keys or full secrets in a retrievable form. * It routes cryptographic operations but does not perform fragment-level derivation. * All sensitive key material stays within KFMs or customer-controlled environments. *** ## Unified Access Manager (UAM) The Unified Access Manager coordinates authorization and routing for cryptographic operations: * Maintains logical metadata for keys, roles, and policies * Authorizes operations based on identity, policy, and context * Dispatches derivation requests to the appropriate KFMs * Does **not** hold fragment values or perform fragment-level computation UAM knows *which fragments* participate in an operation, not *the fragment data itself*. *** ## Key Fragment Managers (KFMs) KFMs are internal services responsible for holding and processing key fragments. Each KFM: * Stores one encrypted key fragment in its own isolated datastore * Runs in an independent region or cloud provider to ensure environmental separation * Performs fragment-specific derivation operations when requested * Never shares fragment values or communicates with other KFMs * Refreshes its fragment values periodically KFMs are not customer-facing. All access is mediated through the Akeyless Platform. *** ## Akeyless Gateway The Akeyless Gateway is an optional, lightweight component deployed within the customer environment. It is commonly used for: * Accessing private networks or internal systems * Integrating with on-premises databases, directories, or services * Participating in operations that use a Customer Fragment * Reducing latency by keeping derivation and request handling close to workloads Gateway characteristics: * Performs local combination of fragment derivations when a CF is present * Caches **non-sensitive** metadata to improve performance * Does **not** store secrets, private keys, or cryptographic fragments * Can run in constrained or air-gapped environments *** ## Customer Fragment (CF) Optionally, a Customer Fragment can be enabled when organizations require customer-controlled key custody. The CF: * Is generated and stored entirely within the customer environment * Is never transmitted to Akeyless * Must participate in any operation involving its associated key When a CF is used, the Gateway manages CF access and combines CF-derived values with derivations from KFMs. *** ## Connectors and Targets Connectors and Targets define how Akeyless interacts with external systems. They support: * Dynamic Secrets (for example, Cloud IAM credentials, database credentials) * Secrets rotation (for example, rotating passwords, tokens, or access keys) * Use of Akeyless-managed encryption keys in external services Examples include: * Cloud provider targets (AWS, Azure, GCP) * Database targets (PostgreSQL, MySQL, MSSQL) * Directory services (LDAP, Active Directory) * Application or service-specific integrations Connectors rely on customer-supplied identities or credentials. These identities are used only by the connector; callers never receive them directly. *** ## Client Tools Client tools are used by applications, automation systems, and administrators to interact with Akeyless services. Available tools include: * **Web Console** — UI for configuration, access control, and monitoring * **CLI** — Command-line interface for administrative and operational tasks * **SDKs** — Language clients (Go, Python, Java, JavaScript, and so on) * **REST API** — Core entry point for programmatic access Clients may communicate directly with the Akeyless Platform or through the Gateway. *** ## Logical Flow Between Components A typical cryptographic or secret-management request works as follows: 1. A client sends a request to the Akeyless Platform or through the Gateway. 2. UAM authenticates the caller and evaluates authorization policies. 3. UAM dispatches fragment-derivation requests to relevant KFMs. 4. KFMs return fragment-derived values. 5. If a Customer Fragment is configured, the Gateway derives a customer-side value. 6. The Gateway or client assembles a one-time derived key and completes the requested operation. 7. Derived key material is discarded immediately after use. This workflow maintains the zero-knowledge and non-reconstructive guarantees of the platform. *** ## Summary The Akeyless Platform consists of cloud-hosted control-plane services, internal fragment managers, and optional customer-deployed components. Each component has a clearly defined role, and none of them—individually or collectively—store or reconstruct full private keys. Together, they implement the Zero-Knowledge model and Distributed Fragments Cryptography used for secure, scalable identity operations.