I have a policy named high that allows all capabilities (including sudo) on *. Under it I have another rule which specifically denies access to secret/data/* so that the policy can’t view secret content.
This policy exists in the root namespace and also in a sub namespace. When I authenticate to my vault, I’m doing so using the root namespace and I’m correctly receiving the high policy if I check the output of my token information.
The expected behaviors are as follows:
- Because I authenticated to the root namespace, I should not be able to access anything in the sub namespace
- I should not be able to see secrets in the “secret/” KV v2 mount in the root namespace due to the explicit deny
But what is actually happening is:
- I can list and read everything in the sub namespace
It almost seems as if the policy I’ve been assigned at the root namespace is trumping the policies in sub namespaces. I’m at a loss of how to debug this, I’ve looked at the audit logs, and run almost every command I can think of to verify configuration.
Here is the policy as defined
path "*" {
capabilities = ["create", "read", "update", "delete", "patch", "list", "sudo"]
}
path "secret/data/*" {
capabilities = ["deny"]
}
Hi @nopcorn,
To make your policy in the root namespace address a path in a sub-namespace, you would need to prepend the name of the sub-namespace to the policy path (e.g., “my-ns/secret/data/*”)
https://developer.hashicorp.com/vault/tutorials/enterprise/namespaces#policy-with-namespaces
Working with such a policy on the root level should be good enough.
Alternatively, you can also decide to define the policies that affect paths in the namespaces on the level of the specific namespace only (“my-ns” in my example above). In that case only specify the relative path that you have given in your example (“secret/data/*”).
For authentication you have two options. If you authenticate on the level of the sub-namespace, you can directly attach the policy to an authentication role or group. If you decide to keep the auth method on the root level, however, ensure to “make the external group in the root namespace member of your group in the namespace with the relative path policy”. This way you can ensure policies are “inherited” from the sub-namespace even though you login on the root level. This keyword “inherited” should then also be visible on the Token lookup.
These two strategies are again explained here: Secure multi-tenancy with namespaces | Vault | HashiCorp Developer
almost seems as if the policy I’ve been assigned at the root namespace is trumping the policies in sub namespaces
Correct, I assume this is how it works (not the other way around, you should never be able to define permissions on the path hierarchy further up with a policy from a sub-namespace, that would lead to privilege escalation).
Hope the explanations are helpful.
Best,
Andreas