# Vault-native safety for Terraform and OpenTofu

General-purpose runners treat Vault as one more provider. Nojam knows what a Vault change means: which credential a job should get, which objects can never be rebuilt, and which policy quietly reaches every team.

## A credential for each job and each phase

Each job logs in to Vault with its own short-lived credential: a JWT signed by Nojam's built-in OIDC issuer, or a hardened AppRole while you move off today's setup. Plans get a read-only role. The apply role is bound to `main`. The token is revoked when Terraform finishes.

The issuer's public keys can be limited to your Vault servers, or handed to Vault directly so the endpoints are closed to everyone else.

Nojam guards its own access too. Plans that would change the auth mounts or policies Nojam uses are denied.

## Protection for what can't be rebuilt

Some deletes are routine and some are permanent. Nojam tells them apart.

- Removing an audit device is refused.
- Deleting KV data or a KV store, a Transit key, a PKI CA or a namespace, or touching the `admin` policies, needs a break-glass label and an extra approver, in every namespace.
- Other mounts and auth methods are held only if you name them, for example `auth/oidc` or `database-prod*`.
- You add your own rules by Vault path, such as `**/kv-prod/**`, and a pull request can't weaken them.

Routine work isn't slowed down. In our tests, 50 policies that grant KV access were removed and recreated through normal review without a single hold.

## Break-glass that approvers can judge

A risky change needs a stated reason before anyone may approve it, as many extra approvers as the target asks for, and optionally a ServiceNow incident or change that ServiceNow confirms at every approval.

Approvers see one page: why the change is held, what it destroys, with KV data marked as not rebuildable, the reason, the pull request, the plan, the record and the approvals so far. It exports as PDF or PNG for a change board.

On Vault Enterprise a target can send break-glass applies through a Vault control group. After Nojam's approvals, Vault holds the apply's token until the people it names, for example two members of `security-team`, authorise it in Vault itself. A compromised Nojam can't skip them.

## Policies that reach further than they look

On Vault Enterprise, a policy in a parent namespace whose path starts with a wildcard, such as `"*"` or `"+/kv/*"`, also grants in every child namespace. Nojam holds that change for break-glass and names the path.

Any change that lets a policy in one namespace reach into a child namespace says so on the pull request, and can be set to need an extra approver:

```
vault_policy.shared_read (in admin) newly reaches admin/team-a, admin/team-b
```

## One namespace per team, at any number of teams

Tested on real Vault Enterprise 2.2.1, not only the community edition. A team's jobs log in at the parent namespace, out of the team's reach, and work only in their own. In another team's namespace, or the parent, they get "forbidden".

A new team is one line in `teams.yaml`. Nojam creates its namespace, its policies and its plan and apply roles on every cluster, through the same reviewed pull request. Removing a team is held for break-glass.

Install the GitHub App on the whole organisation with a name mask such as `vault-ns-*`, and new team repositories are picked up as they appear.

## Providers a pull request can't change

Providers come only from your mirror and an allow-list, and must match the lock file committed with each stack. A new provider or version shows up in the pull request summary and is passed to policy. Modules that follow a branch or a version range are flagged or refused.

Nojam serves the verified mirror itself, so runners never reach a public registry. A strict site can fill the mirror from its own folder or artifact store with no download at all, and the same signature and checksum checks still apply.

## Clusters that change under you

Behind a load balancer, the server and the runners may reach different Vault nodes. Nojam's sealed token hand-over works across performance standbys, and a revoked token is refused by every node within moments.

During a leader election, a restart or a load balancer failover, a job waiting for credentials is held and tried again. In our tests on a three-node cluster with a leader change every 3 seconds, every plan went through.

An outage longer than 15 minutes still fails the job, and the job says why.

## From one shared state to one per namespace

`nojam state split` groups the resources of a shared state by namespace and rewrites their addresses to match each team's code. Where it can't tell where a resource belongs, it refuses to guess.

Nothing in Vault changes, so there is no outage and nothing is recreated. Every new state must plan to `+0 ~0 −0` against Vault, checked by Nojam in shadow mode, before anything is applied. The original state file is your way back.

Until you split, Nojam runs the shared state as it is, with size guardrails that warn before it grows too big.

## See it on your own Vault

Bring one cluster and a few repositories. The pilot starts in shadow mode, so nothing in your current pipeline changes.

[Request a pilot](https://nojam.io/pilot.md) [Join early access](https://nojam.io/early-access.md)

---

Canonical page: https://nojam.io/vault-native/  
Site map for AI agents: https://nojam.io/llms.txt