HashiCorp Vault AppRole support. #1087
Conversation
nixops/resources/vault_approle.py
Outdated
|
|
||
| state = nixops.util.attr_property("state", nixops.resources.ResourceState.MISSING, int) | ||
| vault_token = nixops.util.attr_property("vaultToken", None) | ||
| _reserved_keys = [ "vaultAddress", "roleName", "roleId", "bindSecretId" |
There was a problem hiding this comment.
are these really _reserved_keys ? it seems like these are actually the options from nix expression that defines the vault app role so you actually need them to fire up the diff engine.
_reserved_keys is meant to be used for ignoring attributes that are stored or internal which we don't want to handle e.g in EC2 the instance id would be reserved as otherwise the diff engine will always notice that there is a diff between the config and the state.
There was a problem hiding this comment.
@AmineChikhaoui ok so _reserved is used for attributes set by nixops while the options are set using nixops.util.attr_property ?
nixops/resources/vault_approle.py
Outdated
| return "vault-approle" | ||
|
|
||
| def __init__(self, depl, name, id): | ||
| nixops.resources.DiffEngineResourceState.__init__(self, depl, name, id) |
There was a problem hiding this comment.
I would expect some handlers to be defined here since you're using DiffEngineResourceState.
The handler should handle a set of keys e.g ["vaultAddress" "roleName"] and whenever there is a diff between the config and stored state it will call a function that will handle the realization of the diff. (see https://github.com/NixOS/nixops/blob/master/nixops/resources/vpc_internet_gateway.py#L41 for a simple example)
nixops/resources/vault_approle.py
Outdated
|
|
||
| @property | ||
| def resource_id(self): | ||
| path = '/v1/auth/approle/role/' |
There was a problem hiding this comment.
this path is being in many places, please defined once in a static variable, maybe in vault_common ?
nixops/resources/vault_approle.py
Outdated
| def prefix_definition(self, attr): | ||
| return {('resources', 'vaultApprole'): attr} | ||
|
|
||
| def _connect(self, vault_token): |
There was a problem hiding this comment.
It doesn't seem that _connect does any actual connection, we typically use a connect method to create an http client and cache it for later uses. And btw any reason for not using an actual Vault python library such as https://github.com/hvac/hvac
There was a problem hiding this comment.
Connect is basically to test if the token is actually valid and can create role it is not like other _connect methods in ec2 pr datadog.
we can use hvoc but it is an overkill. Also, I was not able to package it in nixpkgs since it relies on another package where the maintainer is freezing a given other package (lot of packages :p) to a version and fail for to build with the version in nixpkgs.
nixops/resources/vault_approle.py
Outdated
| # log warning if token lifetime is less then 30 min ?!s | ||
| # check for permissions and take sure it can create role_ids | ||
|
|
||
| def create(self, defn, check, allow_reboot, allow_recreate): |
There was a problem hiding this comment.
If you use handlers you should be able to get rid of the create method and only keep methods for realizing specific attributes changes
nixops/resources/vault_approle.py
Outdated
| header = {"X-Vault-Token": self.vault_token} | ||
| path = '/v1/auth/approle/role/' | ||
| remote_endpoint = self.vault_address + path + self.role_name | ||
| data = { |
There was a problem hiding this comment.
I would expect the API to support modifying most of the configs which I don't see being handled.
Which brings us back to the diff engine handers :) It should be much cleaner to define a handler for each modifiable attribute so that any change from the nix expression is handled correctly
There was a problem hiding this comment.
As i said in the description i will be taking care of that next.
Co-authored-by: PsyanticY <iuns@outlook.fr>
AmineChikhaoui
force-pushed
the
vault_backend
branch
from
2f9cf23
to
01d5b96
Compare
PsyanticY
changed the title
Hashicorp vault provide a highly available/secure why to store secrest in the cloud using various back-ends (consul for instance). Authentication to the vault can occur using multiple methods such as LDAP, GitHub and Approle which is the best choice for programmatic users like ec2/gcp (...) deployments.
The idea is to create an AppRole for each deployment which will allow it to have access to secrets based on the policies (an argument). Once created the approle will then be used by the instance to request the keys/secrets from the vault server. ( I can explain the use case more if it is not that clear ).
What left to to in This PR is: