Self Hosted Secret Manager
A self hosted secret manager stores and encrypts keys on your own servers. You deploy the store, set up role rules, and let apps fetch keys. Engineering teams use this setup to keep passwords out of code and files. Still, broad role rules often give apps and people too many keys. Once an engineer pulls a database password, the secret store cannot check the session. How a self hosted secret manager works You run a self hosted secret manager inside your own private network. The server uses a m
GCP Secret Manager + Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A self hosted secret manager stores and encrypts keys on your own servers. You deploy the store, set up role rules, and let apps fetch keys.
Engineering teams use this setup to keep passwords out of code and files. Still, broad role rules often give apps and people too many keys. Once an engineer pulls a database password, the secret store cannot check the session.
How a self hosted secret manager works
You run a self hosted secret manager inside your own private network. The server uses a master key to lock and manage the storage disk. When the server starts, an admin or cloud key unlocks the main store.
Next, admins define paths or folders for different teams and apps. Each folder holds API keys, database passwords, or TLS certs. Admins then write rules that state which roles can read or write each path.
Apps and engineers log in using an identity provider or a machine role. The secret server checks the login token against its rule list. If the role matches, the server returns the secret over an encrypted link.
Many stores can also create temporary database users with an expiration timer. When the timer ends, the secret server drops the user from the database. Every read, write, and login event goes into a central audit log.
What secret stores solve and what they miss
A secret store solves the problem of static passwords sitting in plain text. It stops teams from sharing keys in chat rooms or source code repos. Central logs also show who fetched a secret and when they took it.
GCP Secret Manager + Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Yet a secret manager only controls who gets the key at login time. Once a user or script holds the password, the secret store steps aside. It cannot see what queries run inside the database session after login.
An engineer with a valid key can run a broad table read. That query might return thousands of emails, phone numbers, or card numbers. The secret audit log only shows that the engineer read the password earlier.
Managing day-two operations on your servers
Running your own secret server takes steady work from your platform team. You must back up the encrypted storage disk on a regular schedule. If the disk fails without a backup, you lose all stored keys.
You also need a clear plan to manage the server after a reboot. If a server restarts at night, locked keys can break your running apps. Teams often spread server nodes across zones to keep the store online.
Key rotation is another task that needs careful planning and testing. Changing a database password in the store can break apps that cache old keys. Teams must set up apps to reload keys when a rotation happens.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens if a self hosted secret manager goes offline?
Apps that already cached their keys will keep running for a short time. New app starts and new user logins will fail until you restore the server.
Does a secret manager mask sensitive data in database queries?
No, a secret store only hands out the login key to the user. It does not inspect queries or rewrite emails and card numbers in results.
How often should teams rotate keys in a secret store?
Teams should rotate human passwords and high-risk keys every few days or weeks. Short-lived credentials that expire after one work shift reduce the risk of leaked keys.