Yeogiotae Secret Platform Build Story Part 2: Applying the Secret Store Across All Services

Yeogiotae aimed to spread its Secret store Secrethub company-wide, and started first with the well-standardized EKS environment. This was the path that could secure stability faster than EC2, where CI/CD structures vary widely.

On EKS, applications were designed not to call Secrethub directly; instead, External Secrets Operator (ESO) automatically synced values from Secrethub into Kubernetes Secret. To avoid circular reference, the API Key for accessing Secrethub was stored in AWS Secret Manager, and a structure was built where ClusterSecretStore looks it up, then ESO reads Secrethub and converts it into a Kubernetes Secret.

Before rolling this out into production, failure scenarios were organized first. For each error situation, the team checked whether a new Kubernetes Secret gets created, an existing Secret gets updated, or it remains unchanged, and also verified the ExternalSecret status together, so that the cause of an incident could be classified as an ESO issue / Secrethub issue / user request issue.

After comparing several alternatives for the Secret storage method, a single JSON file strategy was chosen. This allows Secrethub's JSON structure to be passed through as-is, lets applications read just one file, and greatly reduces the GitOps burden of having to modify values.yaml every time keys increase.

For Spring Boot adoption, a separate common library called Secrethub Loader was built. This library is implemented in pure Java to support both Spring Boot 2.x / 3.x, and uses EnvironmentPostProcessor to automatically inject Secrets at application startup. Thanks to this, @Value and @ConfigurationProperties can be used exactly as with existing configuration, and it works the same way across local, EC2, and EKS.

The biggest concern with the common library was dependency conflicts. To avoid this, the Shadow Jar approach was chosen, rewriting internal dependencies like Jackson into an independent namespace such as com.secrethub.shaded..., so it doesn't conflict with Spring Boot's own Jackson and can be deployed safely without polluting the classpath.

The core goal didn't end simply at centralizing Secrets. The focus was on defining failure situations that could arise in production, and building an explainable standard structure while still respecting the different configuration approaches of each team. Secrethub was completed not as a mere storage system, but as work that established a platform-wide standard.