Kubernetes Native
Summary
Keymate runs on standard Kubernetes clusters. All platform components ship as Helm charts, making Helm the primary deployment format. You can install Keymate on any conformant Kubernetes distribution — managed services (AKS, EKS, GKE), self-managed clusters, or on-premises infrastructure.
This page explains the Kubernetes Native deployment model, what it requires, and how it relates to other deployment options.
Why It Exists
Enterprise IAM platforms need to run in diverse infrastructure environments. By packaging every component as a Helm chart, Keymate meets customers where they are: any Kubernetes cluster, any cloud provider, any network topology. No proprietary runtime or custom orchestration tool is required.
Where It Fits in Keymate
Kubernetes Native is the foundational deployment model. All other deployment options build on it:
- GitOps with ArgoCD adds automated orchestration on top of the same Helm charts
- OpenShift uses the same Helm charts with platform-specific adjustments
- Air-Gapped / On-Prem uses vendored copies of the same Helm charts in offline environments
Choosing this model means you install and manage Helm releases directly using standard Kubernetes tooling.
Boundaries
This model covers:
- Deploying Keymate on any conformant Kubernetes cluster using Helm
- Component dependency order and installation sequence
- Minimum cluster requirements (compute, storage, networking)
- Supported Kubernetes versions and distributions
This model does not cover:
- GitOps-based orchestration with ArgoCD (see GitOps with ArgoCD)
- Automated cloud cluster provisioning (see Infrastructure Provisioning)
- OpenShift-specific adjustments (see OpenShift)
How It Works
Helm as the Primary Packaging Format
Keymate distributes every platform component as a Helm chart. This includes identity services, authorization engines, API gateway configuration, service mesh components, data stores, and observability tooling.
You deploy the platform by installing these charts in a defined dependency order:
- Infrastructure layer — service mesh, certificate management, operators
- Data layer — databases, caches, message brokers
- Application layer — identity provider, authorization engine, API gateway, platform services
- Observability layer — telemetry collection, dashboards, alerting
Each layer depends on the previous one. The Platform Components page provides the full component list and dependency map.
What You Need
| Requirement | Details |
|---|---|
| Kubernetes cluster | Any conformant distribution: AKS, EKS, GKE, self-managed, on-premises |
| Kubernetes version | v1.28 or later recommended |
| Helm | v3.12 or later |
| Cluster resources | Sufficient CPU, memory, and storage for all platform components (see Pre-Deployment Checklist) |
| Network access | DNS resolution, TLS certificate provisioning, ingress controller |
| Credentials | Database credentials, TLS certificates, identity provider configuration |
Installation Flow
The general installation flow for the Kubernetes Native model:
- Verify cluster readiness using the Pre-Deployment Checklist
- Add the Keymate Helm repository or obtain chart archives
- Install components in dependency order (infrastructure → data → application → observability)
- Configure ingress, DNS, and TLS for external access
- Validate the deployment through health checks and smoke tests
For step-by-step instructions, see the Helm-Based Installation guide.
Diagram
Example Scenario
Scenario
A platform engineering team at Acme Corp needs to deploy Keymate on their existing AKS cluster. They use standard Kubernetes tooling and do not want to adopt ArgoCD.
Input
- Actor: Platform Engineer
- Environment: AKS cluster with 3 nodes, Kubernetes v1.30
- Method: Direct Helm installation
- Constraints: No GitOps tooling, corporate DNS and TLS requirements
Expected Outcome
- The team installs all Keymate components via Helm in the correct dependency order
- The platform serves traffic through the corporate ingress with valid TLS certificates
- The team manages upgrades and scaling through standard Helm and kubectl commands
Common Misunderstandings
- "Keymate requires ArgoCD." ArgoCD is an optional orchestration layer. The Kubernetes Native model works with Helm alone — no GitOps tooling is required.
- "There is a single Keymate Helm chart." Keymate consists of multiple components, each with its own Helm chart. You install the charts in a defined dependency order, not as a single umbrella chart.
- "I need Crossplane for infrastructure." Crossplane automates cloud cluster provisioning. If you already have a Kubernetes cluster, you do not need Crossplane at all.
Keymate is a multi-component platform. Installing components out of dependency order causes failures. Always follow the documented installation sequence or use the GitOps with ArgoCD model for automated ordering.
Design Notes
- Helm is the universal deployment interface. Whether you use GitOps, run on OpenShift, or operate in air-gapped environments, Helm charts remain the packaging format.
- The multi-chart architecture gives you fine-grained control over component versions, resource allocation, and upgrade sequencing.
- Helm values overrides support Tenant-level and environment-level customization. See Customization Overview for details.
Start with the Pre-Deployment Checklist to verify your cluster has sufficient resources before installation. Keymate deploys multiple components and requires adequate CPU, memory, and storage capacity.