Hi guys !
I setup an on-prem Hashicorp Vault environment (debian 11 server) to answers some case I have. After reading the documentation, i still got several interrogations.
My use-case/need is to allow access to credentials to some apps/servers, without knowing the contents. (my environment is on-prem and up-to-date Windows-Linux servers + K8s clusters)
At the moment, (i know it’s the worst usage but it’s for testing purpose), i use root token in ansible with lookup method to be able to retrieve secrets and it works pretty well.
So in my mind i planned to create dedicated token (like 1x/app or servers) and apply a policy depends on the needs. BUT, the official documentation says :
Warning: Since tokens are considered opaque values, their structure is undocumented and subject to change. For these reasons, we do not recommend using tokens within your scripts or for automation since it can cause breakage.
Moreover, in the documentation, there’s a sheet about auth methods. I was thinking about use AppRole but it seems difficult to manage, or Username but it seems to be less secure that token ? I’m really not sure what methods may fit my needs.
Any advices or feedback about the easiest and good use of auth methods ? Thanks a lot !
Gael
AppRole would be the recommended method to use.
You shouldn’t store any form of secret in things like your source code management system, which is the same between a token, AppRole credentials or a username & password.
Hi @stuart-c , thanks for the reply.
So it means i should create one AppRole per purpose ?
About your second quotes, even if we have a private code repository, what should be your advice ? use AppRole credentials only while executing the playbook for example ?
Thanks a lot for your precious advices 
Yes you should have a different AppRole for each application/purpose, which allows you to have very precise policies, meaning apps can only access secrets they actually need.
Within your code repository you should store nothing secret, and only when the application is deployed/run should it be combined with secret information (such as credentials).
The mechanism for doing that depends on the technology you are using and your own policies. For example if things are being done manually you might expect the deploying user to enter their own username & password to unlock access to secrets stored in Vault (such as the AppRole details needed for an application). If you are hosting an application using Kubernetes you might use Secrets or the Kubernetes auth engine (instead of AppRole). With a cloud provider such as AWS you might delegate responsibility to them, using things like the AWS auth engine. Each option has different advantages and limitations (e.g. AWS auth engine only works if you host within AWS, and only allows authentication on an EC2 instance level rather than an application) so which option is best will vary between different companies, policies, compliance needs and technology stacks.
1 Like