Platform Components
Summary
The Keymate platform consists of multiple components organized into four deployment layers: infrastructure, data, application, and observability. Each layer depends on the previous one. Understanding the component map and dependency order is essential for both Helm-based and GitOps-based installations.
This page lists every component, explains its role, and defines the deployment sequence.
Why It Exists
Keymate is not a single binary — it is a platform composed of specialized services for identity management, fine-grained authorization, API gateway enforcement, and operational observability. Deploying these services requires understanding what each one does and which services must be running before others can start.
Where It Fits in Keymate
This page sits between the deployment model decision (how you want to deploy) and the actual installation guides (step-by-step instructions). Read this page to understand what you are deploying before following the installation steps.
Boundaries
This page covers:
- The component list and what each component does
- The four deployment layers and their dependency order
- Which components are required and which are optional
This page does not cover:
- Step-by-step installation commands (see Helm-Based Installation or GitOps-Based Installation)
- Component internals or API reference (see Platform Components documentation)
- Sizing and resource allocation (see Pre-Deployment Checklist)
How It Works
Deployment Layers
Install components in four layers. Verify each layer is healthy before starting the next one.
Layer 1 — Infrastructure
Infrastructure components deliver the foundational services that all other layers depend on: networking and TLS.
| Component | Role |
|---|---|
| Service Mesh | Provides mutual TLS (mTLS) between services, traffic management, and zero-trust network security |
| Certificate Manager | Automates TLS certificate provisioning and renewal using Let's Encrypt or a custom CA. Optional if you manage TLS certificates externally |
These components must be running and healthy before deploying data services.
Layer 2 — Data
Data components provide persistent storage, caching, and messaging infrastructure that application services consume.
| Component | Role |
|---|---|
| Relational Database | Stores identity data, authorization models, and platform configuration using a relational database |
| Distributed Cache | Provides low-latency caching for business application services |
| Message Broker | Enables asynchronous event-driven communication between platform services |
These services must accept connections before application services can start.
Layer 3 — Application
Application components deliver core Keymate functionality: identity management, authorization decisions, traffic enforcement, and platform administration.
| Component | Role |
|---|---|
| Identity Provider | Manages user authentication, federation (OIDC, SAML), session management, and Tenant/Organization structure |
| Authorization Engine | Evaluates fine-grained authorization decisions across RBAC, ABAC, and ReBAC models |
| API Gateway | Routes inbound traffic, enforces rate limiting, and delegates authorization checks to the Access Gateway. Runs at the network edge |
| Access Gateway | Receives authorization check requests from the API Gateway, enriches context, orchestrates policy evaluation, and returns access decisions. A Keymate microservice running at the application layer |
| Event Hub | Provides asynchronous event-driven communication between platform services with guaranteed delivery and dead letter handling |
| Integration Hub | Manages connectors to external systems and distributes events to subscriber endpoints |
| Platform Services | Additional business logic services including Policy Engine, access management, and organization management |
Layer 4 — Observability
Observability components collect, store, and visualize telemetry data (logs, metrics, traces) from all platform layers.
| Component | Role |
|---|---|
| Telemetry Collector | Collects logs, metrics, and traces from all platform components using OpenTelemetry |
| Observability Platform | Provides dashboards, alerting, and trace analysis for operational monitoring |
Deploy the observability layer last because it monitors the components from all previous layers. Once running, it provides immediate visibility into the health of the entire platform.
Component Dependency Map
The full dependency flow across all four layers:
Required vs Optional Components
| Component | Required | Notes |
|---|---|---|
| Service Mesh | Yes | Provides mTLS and traffic management |
| Certificate Manager | Recommended | Automates TLS provisioning. Not required if you manage TLS certificates externally |
| Relational Database | Yes | Core data storage |
| Distributed Cache | Yes | Business application caching |
| Message Broker | Yes | Inter-service communication |
| Identity Provider | Yes | Authentication and identity management |
| Authorization Engine | Yes | Fine-grained authorization decisions |
| API Gateway | Yes | Network edge traffic routing, rate limiting, authorization delegation |
| Access Gateway | Yes | Authorization orchestration, context enrichment, policy evaluation proxy |
| Event Hub | Yes | Asynchronous event-driven communication |
| Integration Hub | Yes | External system connectors and event distribution |
| Platform Services | Yes | Core Keymate business logic |
| Telemetry Collector | Recommended | Required for observability |
| Observability Platform | Recommended | You can replace it with external tooling via OTel export |
Example Scenario
Scenario
A platform engineer at Acme Corp is preparing to install Keymate on a new Kubernetes cluster. They need to understand what services are deployed and plan the installation sequence.
Input
- Actor: Platform Engineer
- Environment: New Kubernetes cluster with no existing Keymate components
- Goal: Understand the full component set before starting installation
Expected Outcome
- The engineer knows all components that need to be deployed
- The dependency order is clear: infrastructure → data → application → observability
- The engineer can estimate resource requirements based on the component list
- The engineer proceeds to the Pre-Deployment Checklist with a clear understanding of what is being deployed
Common Misunderstandings
- "API Gateway and Access Gateway are the same thing." They are different components with different roles. The API Gateway runs at the network edge and handles traffic routing, rate limiting, and TLS termination. The Access Gateway is a Keymate microservice that receives authorization check requests from the API Gateway, enriches context, and orchestrates policy evaluation. The API Gateway calls the Access Gateway — not the other way around.
- "All components are custom-built by Keymate." Keymate builds on proven open-source foundations and adds enterprise integration, hardening, and orchestration on top.
- "I can skip the infrastructure layer if I already have a service mesh." If your cluster already runs a compatible service mesh and certificate manager, you may be able to reuse them. Consult the installation guide for compatibility details.
- "The observability layer is optional." The observability platform itself can be replaced with external tooling, but the telemetry collector is needed to emit data. Without it, you have no visibility into platform health.
Design Notes
- The layered architecture ensures clean separation of concerns. Infrastructure changes do not affect application services, and application deployments do not require infrastructure restarts.
- The same component set deploys regardless of deployment method (Helm or GitOps). The deployment method changes how you install components, not which components you install.
- Components use standard Kubernetes primitives (Deployments, StatefulSets, Services, ConfigMaps, Secrets). No custom resource definitions are needed beyond those that operators in Layer 1 install.