Overview

Krypton is a lightweight secret manager UI and API backed directly by Kubernetes Secret objects. No database, no persistent volumes, no secret sprawl: Kubernetes is the source of truth, and Krypton is the translation + visualization layer on top.

It is built with Next.js (App Router), @kubernetes/client-node, generic OIDC SSO, and shadcn-theme components.

How it works

Browser ──SSO login──▶ Krypton (Next.js)
                            │  ServiceAccount token (auto-mounted in-cluster)
                            │  https://kubernetes.default.svc  — no credentials to manage
                            ▼
                    Kubernetes API ──▶ etcd (Secrets + one access ConfigMap)

• State: every secret is a native Secret object. Standard tools (Velero, kubectl, GitOps) keep working; RBAC, audit logs, and network policies come free.
• Auth: users sign in via OIDC SSO (Keycloak, Entra ID, Okta, Google, GitHub…). Users do not need cluster credentials.
• Authz (hybrid): SSO proves who you are; per-secret annotations and one namespace-level ConfigMap decide what you may see. The app's ServiceAccount executes the K8s calls.
• History: K8s overwrites secrets in place, so Krypton snapshots the previous state into an immutable, UID/resourceVersion-bound Secret before updates and restores. Rollbacks preserve raw bytes and current access rules within the retained history.

What Krypton is not

• Not an encryption layer. Out of the box, Kubernetes Secrets are base64-encoded, not encrypted, in etcd. Krypton shows a warning banner until you confirm etcd encryption-at-rest is enabled (KRYPTON_ETCD_ENCRYPTED=true). Read the Security Model before production.
• Not a replacement for RBAC. Krypton adds an SSO-friendly authorization layer for users without cluster identities. The ServiceAccount it runs as should still follow least privilege (namespace Role by default, ClusterRole only for multi-namespace dashboards).
• Not a secret generator or rotation engine. It stores, versions, and gates access to values your teams already manage.

At a glance

Concern	Approach
Storage	Native Secret objects; snapshots labeled krypton.io/kind=history
Login	Generic OIDC (discovery-based), stateless HS256 session JWT
Authorization	Admins bypass; per-secret annotations override namespace fallback
Concurrency	Optimistic writes on metadata.resourceVersion (409 + reload on drift)
Size guard	1 MiB per-object limit enforced client- and server-side (413)
Consumer rollout	Opt-in bounded rollout requests for explicit Secret consumers; reports partial failures
Deployment	Raw manifests (app/k8s/) or Helm (helm/main + helm/krypton subchart)

Where to go next

• Quick Start — run the app locally in minutes.
• Architecture — request flow, scopes, and project layout.
• Security Model — assumptions, guarantees, and hardening.
• Sandbox — batteries-included kind + Dex environment.
• API Overview — drive Krypton from scripts and automation.