DEV Community: Bhanu prakash

Why We Killed Nested Namespaces (And You Probably Should Too)

Bhanu prakash — Fri, 30 Jan 2026 02:08:50 +0000

The Plan vs. Reality
The real problem was our namespace architecture. We'd designed this beautiful parent-child hierarchy:
engineering/ ├── team-alpha/ ├── team-beta/ research/ ├── lab-1/ ├── lab-2/
Looked clean in diagrams. Worked terribly in practice.
What Broke First
Problem 1: Permission inheritance was a minefield
Team Alpha couldn't understand why their policies sometimes worked and sometimes didn't. Turns out, parent namespace policies were interfering in ways nobody expected.
Created a policy in engineering/? Congrats, it now affects engineering/team-alpha/ in weird ways.
Problem 2: Mental overhead
Support conversation:

Team: "Our secret isn't working"
Me: "Which namespace?"
Team: "Uh... the team one?"
Me: "Parent or child?"
Team: "What's the difference?"

Every. Single. Time.
Problem 3: Automation nightmare
Writing scripts that work across parent AND child namespaces meant handling two different permission models. Code got messy fast:
This got old real quick if is_parent_namespace(ns): apply_parent_logic() else: apply_child_logic() check_parent_inheritance() pray_it_works()

The Breaking Point

I was onboarding a new team. Simple task: create their namespace, set up AppRole auth, done.

Except their parent namespace had conflicting policies. Their child namespace inherited permissions they didn't need. Auth setup failed in ways the error messages didn't explain.

Took me 3 hours to debug what should've been a 10-minute task.

That's when I talked to the team: "What if we just... stopped doing this?"

The Solution: Go Flat

We killed the hierarchy. New model:
team-alpha/ team-beta/ lab-1/ lab-2/

Need logical grouping? Use naming conventions:
eng_team-alpha/ eng_team-beta/ research_lab-1/ research_lab-2/
Underscores instead of slashes. Flat instead of nested.
What Changed
Onboarding went from 3 hours to 15 minutes
One namespace model. One set of policies. No inheritance surprises.
Support tickets dropped
Teams understood their namespace. No more "which namespace am I in?" questions.
Automation got stupid simple
No special cases. No inheritance checks. Just works.
Policies became predictable
What you write is what you get. No parent namespace secretly modifying things.
The Migration
Wasn't instant. We had production services in nested namespaces.
Phase 1: New namespaces use flat model only
Phase 2: Migrate low-risk teams first
Phase 3: Production migrations during maintenance windows
Phase 4: Deprecate parent/child model entirely
Took 3 months. Worth every minute.
The Pushback
"But we lose organizational structure!"
No, you don't. Use naming: dept_team_project. You can still grep, filter, and organize.
"What about RBAC across departments?"
Use Vault groups and entity aliases. Group-based permissions work better than namespace inheritance anyway.
"HashiCorp docs show parent/child namespaces!"
Docs show what's possible, not what's practical at scale. We learned the hard way.
When Nested Namespaces Make Sense
Look, I'm not saying nested namespaces are always wrong. They work if:

You have <10 namespaces total
Your team deeply understands Vault internals
You actually need different permission models per layer

We had 50+ namespaces and growing. Engineering teams, not Vault experts. Flat was the right call.
What I'd Tell My Past Self
"That pretty hierarchy in your architecture diagram? Users don't care. They want their secrets to work. Keep it simple."
Complexity is seductive in infrastructure design. Resist it.
The Vault Philosophy We Learned
Vault's "deny by default" model is powerful but unforgiving. Every layer of abstraction (like nested namespaces) adds opportunities for unexpected denials.
Simpler architecture = fewer surprises = happier teams.
Try This
If you're using nested namespaces, run this check:
bash# How many support tickets mention "namespace" or "permission denied"?
If it's more than 10% of your Vault tickets, consider flattening.
Your future self will thank you.

How I Discovered a Critical Security Gap in Our HashiCorp Vault - And What It Taught Me About Policy Design

Bhanu prakash — Thu, 29 Jan 2026 01:59:09 +0000

The Day I Found a Security Hole in Our Vault Setup
The "Oh Shit" Moment
I was writing a Python script to inventory service accounts across our 50+ Vault namespaces when something caught my eye. Teams were creating auth mounts with weird names - stuff we never approved.

Turns out, our wildcard policies had a massive flaw.

What We Screwed Up
Our policy looked innocent enough:

path "auth/*" { capabilities = ["create", "read", "update", "delete", "list"] }
We thought: "Let teams manage auth in their namespace. What could go wrong?"

Everything. Everything could go wrong.

That wildcard meant teams could create any auth mount type, not just the standard AppRole we supported. So they did:

Custom AppRole mounts: auth/my-special-approle/

Random Kubernetes auth (we don't even use K8s auth)

LDAP configs that bypassed our central auth

Experimental mounts nobody remembered creating

Out of 50+ namespaces, 15% had rogue auth mounts we didn't know existed.

Why This Actually Mattered
Monitoring blindspot: Our Splunk dashboards looked for auth/approle/. These custom mounts were invisible.

Support hell: Teams configured Vault Agents wrong, got auth failures, opened tickets. We couldn't help because their setup didn't match our docs.

Future nightmare: Try migrating 50 namespaces when everyone's doing their own thing.

How I Found It
Simple inventory script:

for namespace in all_namepaces: auth_mounts = vault_client.sys.list_auth_methods() for mount in auth_mounts: if mount not in ['approle/', 'token/']: print(f"WTF is this: {namespace}/{mount}")

The output was... concerning.

Checked Splunk to see if anyone was actually using these:

index=vault_audit request.path="auth/*/login" | stats count by request.namespace request.path

40% had zero logins in 90 days. Dead mounts from old experiments.

The Fix
Step 1: Stop the bleeding - locked down policies immediately:

`Old (bad)
path "auth/*" { capabilities = ["create", "read", "update", "delete"] }

New (specific)

path "auth/approle/*" { capabilities = ["create", "read", "update", "delete"] }`

Step 2: Reached out to teams, made migration plans

Step 3: Still migrating production stuff months later (it takes time)

What I Learned
Wildcards are dangerous. Be explicit. Always.

Your monitoring only catches what you're looking for. Inventory everything, not just what you expect.

Standards aren't real until you enforce them. Documentation doesn't count if the system allows chaos.

Fixing production takes forever. We're still cleaning this up.

The Bigger Issue
This also exposed that our parent/child namespace model was overly complex. We eventually flattened everything - but that's Part 2.

If You Run Vault
Check your policies right now:

vault policy read your-policy | grep "*"

Every wildcard is a potential problem. Can you be more specific?

Then actually inventory what exists in your Vault. I bet you'll find surprises.

Next up: Why we ditched nested namespaces and went flat. Plus the monitoring system I built to catch this stuff automatically.

Drop a comment if you've hit similar issues. I know I'm not the only one.