HashiCorp Vault — Vault Policies
Hi everyone. this is the 3rd article about HashiCorp Vault. You can view the previous stories using the links below.
Today we’re gonna talk about vault policies. We’re gonna learn what is it and how to use it. Let’s start.
Policies are typically used to define permissions in the HashiCorp vault.
You can use multiple options for policy assignments. These are;
- Token: You can assign a policy to a token when created.
- Identity: You can assign a policy to an entity via the identity secret engine.
- Auth methods: Policy can be applied via an auth method.
You can assign multiple policies at the same time. The most specific policy rules always win.
There are no versioning options on policies. So if you update any policy it automatically overrides the existing configuration.
When you spin up a vault server, it will automatically create a Default Policy on the vault. You can edit it but you cannot delete it.
There is also another special policy that comes up with the newly created vault server. It is called root policy. It is associated with to root token. This policy has full control right on the vault server. You can assign root policy to another token by the way. It cannot be changed and it can not be deleted.
Policy Syntax
In HashiCorp Vault architecture policy syntax is defined either HCL or JSON format. In policy structure, you have to consider two main components when you define policy.
These are,
- Path: where do you want to assign permission
- Capabilities: What permissions do you want to give at this path
When you define a policy basically you need to define a path. You can define paths with various options.
Assign policy to specific path
path “secret/database/config”
Assign policy to multiple path
- Path1 : secrets/firat/app1
- Path2: secrets/firat/app2/keys
- Path3: secrets/firat/app3/configs
path “secrets/firat/app*”
Using Path segment match
If we want to write a path definition like the below we can use “+” expression to match these two paths.
- Path1: secrets/firat/web1/keys
- Path2: secret/firat/web2/keys
path “secrets/firat/+/keys”
By using the two placeholders I mentioned above, it is possible to dynamically match the policies with the paths.
Parameters
Parameters can also be used in the path while defining the policy. This is very useful for identity and secret management engines.
For example, the following parameter can be used to resolve the entity name of the identity and use it in the path.
path “identity/entity/name/{{identity.entity.name}}/*”
You can see that kind of assignment on default policy.
For example, the rights of tokens to see their own entities are defined on the default policy as follows.
Capabilities
Capabilities mostly consist of crud operations like below.
- Create — create a new key
- Read — read data from a key
- Update — update value for a key
- Delete — removal of a key
There are also a few additional capabilities that are available. These are list,sudo, and deny capabilities.
List — It let us enumerate keys. It just lists the keys. It doesn’t show us the key value.
Sudo — Basically it allows us to define special permissions. A certain path can be root protected. Even you have write permissions you can not update values on that path. If you have root capabilities assigned you can update the value on that path.
Deny — This capability allows us to disable access of path. It overrides all other actions. If I have deny access and write access on a particular path, deny would override the write capabilities. It also denies the full path.
Let’s take a look at some capabilities example.
If you want to assign full access permission to a specific path but you want to prevent access particular path under that path, you can write policy like below.
Using the following command you can easily manage vault policies via CLI.
List existing policies
vault policy list
Read specific policy content
vault policy read k8s-policy
Create new policy
vault policy write k8s-policy k8s-policy.hcl
Delete existing policy
vault policy delete k8s-policy
When you create a policy you need to assign it to a token. You have three options to assign a policy to a token.
You can assign a policy to a token directly when you create it.
vault token create -policy=”k8s-policy”
You can assign a policy to an entity inside an identity engine.
vault write identity/entity/user/firat policies=”k8s-policy”
You can assign a policy to an authentication method.
vault write auth/userpass/users/firat token_policies=”k8s-policy”
Conclusion
The policies can be assigned to tokens directly. Or you can assign them to both identity engine and authentication method. There is a special policy called root policy. It can do anything. You can not modify or delete it. When you create new token, the default policy directly assigned to it. The default policy can be modified but it can not be deleted.
The policy contain two parts. Path define action location and the capabilities define the action.
Source:
