Common Vault
You set up a common vault by putting shared keys in one central store. Then you link that store to your team identity provider with role rules. Most teams build this setup to stop engineers from sharing plain text passwords. They put database keys, API tokens, and cloud secrets into shared folders. Still, teams often make role permissions too broad to avoid blocking daily work. When one role reads every folder, any user with that role gets every key. How a common vault works in your architectu
HashiCorp Vault + Common Criteria (CC): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a common vault by putting shared keys in one central store. Then you link that store to your team identity provider with role rules. Most teams build this setup to stop engineers from sharing plain text passwords. They put database keys, API tokens, and cloud secrets into shared folders. Still, teams often make role permissions too broad to avoid blocking daily work. When one role reads every folder, any user with that role gets every key.
How a common vault works in your architecture
A common vault acts as the single source of truth for team secrets. Instead of keeping passwords in code or chat apps, you store them in paths. Each path holds the keys for a specific app, database, or cloud service. First, an admin sets up the store and turns on the encryption engine. The store locks all data at rest using a master key. Next, the admin connects the store to an identity tool like Okta.
Once the identity link works, you write policies for each team role. A policy is a simple rule that links a role to a secret path. It states whether a role can read, write, update, or delete a secret. When an engineer logs in, the identity tool checks their group membership. The store then hands the engineer a temporary token tied to their role policy. The engineer uses that token to pull the database password onto their laptop.
Apps and build servers follow a very similar flow to read secrets. A build server uses its machine role to log in and fetch deployment keys. Some setups also generate short-lived database users on the fly for each request. When the lease timer runs out, the store revokes that database user right away. Every login and secret read writes an entry to a central audit log.
What a shared secret store solves and what it misses
A central secret store solves the problem of scattered, unencrypted passwords across laptops. It gives security teams one place to rotate keys and check read logs. If an engineer leaves the company, you revoke their identity role in one place. You no longer need to hunt through code repos to find hardcoded keys. It also stops teams from pasting production database passwords into public chat channels.
HashiCorp Vault + Common Criteria (CC): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, a secret store only controls who can fetch a credential at login time. Once an engineer pulls a database password, the store is out of the picture. The engineer puts that password into a local client and connects to the database. At that point, the secret store cannot see what queries the engineer runs. It cannot stop a bad drop command or approve a risky data update.
The audit log only shows that a user read a password at nine o'clock. It never shows the fifty SQL statements that user ran over the next hour. Also, raw query results flow straight back to the local laptop screen. Sensitive fields like emails, phone numbers, card numbers, and national IDs appear in full. To control commands in flight and mask sensitive fields, you need statement-level controls.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between a team secret store and a password manager?
A password manager holds web logins for humans using browser plugins. A team secret store holds API keys and database credentials for both humans and apps. It uses role policies and machine identities to automate secret delivery.
How should we organize paths in a common vault?
Group your secret paths by team name, app name, and stage, like prod or dev. This clear layout lets you write tight role rules for each group. A developer role can read dev keys without touching production keys.
Why is secret rotation still hard with a central store?
Rotating a key in the store does not update the target database by itself. You must also update the database and restart any app holding the old key. If an engineer copied the key to a local file, rotation breaks their setup.