mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-29 07:34:31 +00:00
64 lines
3.0 KiB
TeX
64 lines
3.0 KiB
TeX
\section{Secrets: Hanzo KMS}
|
|
|
|
\label{sec:kms}
|
|
%% ============================================================================
|
|
|
|
\subsection{Overview}
|
|
|
|
Hanzo KMS is a fork of Infisical adapted for the Hanzo ecosystem. It provides centralized secrets management with end-to-end encryption, environment-scoped secret injection, Kubernetes CRD-based synchronization, and audit logging. Secrets are encrypted at rest using AES-256-GCM with keys derived from a master key stored in a hardware security module (HSM) or cloud KMS (AWS KMS, GCP KMS).
|
|
|
|
\subsection{Feature Matrix}
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Secrets management comparison.}
|
|
\footnotesize
|
|
\begin{tabular}{@{}lccccc@{}}
|
|
\toprule
|
|
Feature & \rotatebox{60}{Hanzo KMS} & \rotatebox{60}{Vault} & \rotatebox{60}{AWS KMS} & \rotatebox{60}{Doppler} & \rotatebox{60}{Infisical} \\
|
|
\midrule
|
|
E2E encryption & \yes & \yes & \yes & \yes & \yes \\
|
|
Env scoping & \yes & \yes & \no & \yes & \yes \\
|
|
K8s sync & \yes & \yes & \pmark & \yes & \yes \\
|
|
HSM backend & \yes & \yes & \yes & \no & \yes \\
|
|
Dynamic secrets & \no & \yes & \no & \no & \no \\
|
|
Secret rotation & \yes & \yes & \yes & \yes & \yes \\
|
|
Audit log & \yes & \yes & \yes & \yes & \yes \\
|
|
IAM-native & \yes & \no & \no & \no & \no \\
|
|
Self-hosted & \yes & \yes & \no & \no & \yes \\
|
|
Open source & \yes & \yes & \no & \no & \yes \\
|
|
Web UI & \yes & \yes & \yes & \yes & \yes \\
|
|
CLI & \yes & \yes & \yes & \yes & \yes \\
|
|
K8s CRD & \yes & \yes & \no & \no & \yes \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Performance and Operational Complexity}
|
|
|
|
HashiCorp Vault is the most feature-rich alternative, offering dynamic secrets (database credentials generated on demand), PKI certificate authority, and transit encryption. However, Vault requires an unsealing ceremony (Shamir's secret sharing or auto-unseal via cloud KMS), a storage backend (Consul, etcd, or integrated Raft), and significant operational expertise. A production Vault deployment typically requires 3--5 nodes and a dedicated operations team.
|
|
|
|
Hanzo KMS trades Vault's dynamic secret generation for operational simplicity: a single binary, PostgreSQL-backed storage, and automatic K8s secret synchronization via the \texttt{KMSSecret} CRD. For organizations that do not require dynamic secrets, this eliminates approximately 80\% of Vault's operational surface.
|
|
|
|
\begin{table}[H]
|
|
\centering
|
|
\caption{Operational complexity comparison.}
|
|
\footnotesize
|
|
\begin{tabular}{@{}lrr@{}}
|
|
\toprule
|
|
System & Min nodes & Config files \\
|
|
\midrule
|
|
Hanzo KMS & 1 & 1 \\
|
|
HashiCorp Vault & 3 & 5+ \\
|
|
AWS KMS & N/A & IAM policies \\
|
|
Doppler & N/A & 0 (managed) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Key Differentiator}
|
|
|
|
Hanzo KMS authenticates against Hanzo IAM, meaning the same OIDC token that authenticates a developer to the platform also authorizes their access to secrets. No separate credential management. The \texttt{KMSSecret} CRD automatically syncs secrets to Kubernetes namespaces, eliminating manual \texttt{kubectl create secret} workflows.
|
|
|
|
%% ============================================================================
|