Vault Verify Company Code
To run a vault verify company code check, match the tenant string against identity claims. The secret store reads this string before it hands out any database credentials. Many teams set up this step to separate data across different business units. Still, broad role rules often let users read secrets meant for other teams. If a shared role spans multiple units, one bad query can expose private records. How the vault verify company code flow works A company code acts as a tag for a specific t
Infrastructure as Code Security Scanning + HashiCorp Vault: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run a vault verify company code check, match the tenant string against identity claims. The secret store reads this string before it hands out any database credentials. Many teams set up this step to separate data across different business units. Still, broad role rules often let users read secrets meant for other teams. If a shared role spans multiple units, one bad query can expose private records.
How the vault verify company code flow works
A company code acts as a tag for a specific tenant or branch. When a user or app logs in, the identity tool sends a token. This token holds claims like the user email, team name, and company code. The secret store checks these claims against its own internal role rules.
In HashiCorp Vault, admins configure identity templates to read these incoming token claims. The system takes the company code from the token and fills in a path. That path points to a specific folder of secrets for that one business unit. If the code matches the rule, the store returns a database key.
This setup keeps role rules clean and short. Admins do not need to write a new rule for every single branch. Instead, one dynamic rule checks the code and routes the session to the right secrets. The user then takes that key and logs in to the database.
What native company code checks solve and miss
Checking the company code at login solves the initial routing problem. It ensures that a user from one branch only gets keys for that branch. It also stops apps from reading secret folders that belong to other tenants. Auditors like this setup because login logs show which code was used.
Yet this check only happens when the user asks for a secret key. Once the database session starts, the secret store steps out of the way. It cannot see what queries or commands the user runs inside the database. If two branches share one big database table, a broad key sees everything.
Database roles often have wide read rights across shared tables. A user with a valid key can still pull rows from another company code. Also, raw results might hold sensitive fields like emails, phone numbers, or card numbers. Native secret store checks cannot rewrite matched fields in results during a live query.
Infrastructure as Code Security Scanning + HashiCorp Vault: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing shared database sessions across teams
Many firms keep data for all company codes in one main database. They use a column in each table to mark which branch owns the row. In this model, handing out a raw database password creates a big risk. The database user role usually has rights to read the whole table.
Engineers logging in for support tasks need a way to run safe checks. They often need to read a few rows without pulling sensitive customer data. Relying only on secret store login checks leaves the actual query step wide open. Teams must pair identity checks with controls that watch the live session itself.
Good session controls look at every command before the database runs it. They also apply data masking to hide national IDs or card numbers in results. This keeps day-to-day support work safe even when tables hold mixed tenant records.
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 causes a company code check to fail at login?
Most failures happen when the identity token lacks the exact company code claim. Check that your identity provider sends the right field name and string case.
Can one user hold multiple company codes at the same time?
Yes, an identity token can pass a list of codes for one user. You should map each code to a separate role so sessions stay split.
Does verifying a company code restrict what SQL queries a user can run?
No, the secret store only checks the code before it gives out credentials. Once the user logs in to the database, only database permissions limit their queries.