Building Security Governance for kt cloud PLATFORM: Introducing Vault and an Efficient Secret Delivery Strategy (ESO & CSI)

Even when infrastructure is codified with GitOps, Secrets require a separate security system. Kubernetes Secret is essentially close to plaintext, and leaving it in a Git repository creates simultaneous risks of leakage, audit, and access control problems.

To solve this, HashiCorp Vault is placed as the central vault, and the secret delivery method is split into two axes.

• External Secrets Operator(ESO): Synchronizes Vault's values into a Kubernetes Secret.
• Vault CSI Provider: Instead of leaving secrets in etcd, it injects them directly in a memory-based (tmpfs) form when the Pod runs.

ESO barely changes the existing application's environment variable usage pattern, so the migration cost is low, and when the Vault value changes, the Kubernetes Secret is automatically updated as well. On the other hand, the CSI Provider does not store secrets as a Kubernetes object, making it more secure, and when the Pod terminates, the secret disappears from memory as well.

The selection criteria are also clear. If compatibility and operational convenience are the priority, ESO is suitable, and if strong security and regulatory compliance are needed, the CSI Provider is the right fit.

• ESO recommended: general-purpose web services, cloud migration of legacy applications, environment-variable-based microservices
• CSI recommended: financial services, management of high-privilege API Keys, workloads where data protection matters, such as AI Foundry

The core of the operational strategy is to treat Vault not as a simple storage but as a security governance engine. To do this, the Kubernetes Auth Method should be used to link the Pod's ServiceAccount with Vault so it can authenticate without a separate password, and a multi-AZ HA and Raft-based configuration should be used to reduce single points of failure.

Also, permissions should be minimized at the namespace and path level. By establishing a standard path such as projects/{team-name}/{env}/, each workload should be designed to read only the Secrets permitted to it, so that platform-wide security boundaries are maintained.

Ultimately, this architecture is the work of turning security from an individual team's homework into a default capability provided by the platform. Developers can focus on business logic and model development rather than secret management, while the platform takes responsibility for the security guardrails behind the scenes with Vault, ESO, and CSI.