I Don’t Want to Live on the Root Token

Current implementation:

Vault gives you a root token at initialization.
It’s tempting to just keep using it for everything.

But for a long-term setup I want a clearer model:

  • Root token for bootstrap and emergencies only.
  • A dedicated admin persona for day-to-day Vault management.
  • Service identities for agents, proxies and apps.
  • Human operators with scoped capabilities.

High-Level Roles I’m Planning

Roughly:

  • Root:
  • enable/disable secrets engines,
  • manage top-level policies,
  • do dangerous operations.
  • Admin:
  • manage environment PKI mounts,
  • manage auth methods,
  • manage roles and policies for services.
  • Services:
  • Vault Agents,
  • reverse proxies,
  • applications that need secrets.
  • Human users:
  • maybe via GitHub/OIDC or cert auth,
  • each with limited permissions.

Policies as the Core

Instead of memorizing who can do what, I want:

  • policy files in version control,
  • clear mapping from:
  • user / service → policy names,
  • scripts to apply or diff policies.

This access model should match the Unix user layout and PKI design, so that:

  • a compromise of one environment proxy doesn’t give full Vault control,
  • an app-only identity can’t touch PKI admin or offline-like operations.

What The Model Looks Like Now

The current repo is much stricter than this original sketch:

  • root stays for bootstrap and emergency work,
  • admin certs exist for day-to-day PKI and auth management,
  • services authenticate as their own identities through auth/cert,
  • policies are attached per app or proxy instead of shared broad service roles.

That means the real mapping is closer to:

  • one Unix user
  • one agent certificate identity
  • one auth/cert mapping
  • one small policy set

Examples from the current setup:

  • app and proxy identities use their own certificate-auth mappings,
  • app policies are split into things like PKI issuance and optional KV access,
  • proxy identities are focused on CA-chain read and reload workflows instead of broad secret access.

This is the part that made the setup feel operational instead of experimental.