Implementation of AppRole Auth

tuenti / secrets-manager

A daemon to sync Vault secrets to Kubernetes secrets

Apache License 2.0

171 stars 26 forks source link

Implementation of AppRole Auth #27

Closed rvojcik closed 5 years ago

rvojcik commented 5 years ago

Hi guys. Thank you for great project. I'm wondering if you could implement AppRole Auth. It's really easy to implement becouse output of the AppRole is token which you can use in traditional way. https://www.vaultproject.io/docs/auth/approle.html

AppRole provide way, how to authentificate against Vault using role-id and secret-id and get token from Vault for communication. Token can be then used, renewed etc. Role-ID and Secret-ID can be configured to not expire, so it's ideal for automation and there is no problem when some of the system is down for some period of time.

It could be nice if your system can first use AppRole auth to get token and then continue in normal way.

fcgravalos commented 5 years ago

Hi @rvojcik ! Thanks for using secrets-manager!

We have been considering this too to be honest :). But at some point we decided that was way more convenient to just use a token and renewing it.

We do use AppRole auth method internally, but we use it just to generate the token (attached to a policy) than later secrets-manger will consume in a pipeline that is fully automated. Wouldn't something like that work for you as well while we consider this feature?

rvojcik commented 5 years ago

Hi, thank you for reply. Yes I'm using same process right now. Using gitlab CI/CD to do a approle auth, retrieve token and pass to next deploy job so I thing it's the same workaround like yours. I'm pretty satisfied with it so I think there is no need to implement it. It could be nice to have it but it's not blocker for me now :)

fcgravalos commented 5 years ago

Thanks! On one hand I find It nice as well. But there's no direct method in the go client library, you can always use the general logical client and write in the auth path though.

But I find It also that just letting secrets-manager renew a token make It more agnostic of the login mechanism.

So I'm kind of torn here XD

rvojcik commented 5 years ago

Yes I understand. I can describe you my use case, why I think it could be nice to have it.

Imagine that you have token from approle, but it's configured to be short, for example like 40m. It's no problem when everything works, Secrets-Manager automaticly renew token when needed but when something broke, you can loose internet connection, or vault is down or sealed for some time, longer then TTL of the token. Then you have to redeploy Secrets-Manager to get new token. It could be nice if Secrets-Manager detects token already expired and use Approle to get newone without need to redeploy it.

fcgravalos commented 5 years ago

Hi @rvojcik !! I finally found the time (sorry for the delay) to really think about this and... I decided to implement approle as the only auth (for now) login mechanism to Vault :) . Here's my reasoning:

AppRole was always our first goal, but the lack of native method in the go client and our rush to release it made us go with Token + renewal loop which is also a common approach
As you pointed out, re-login with approle will make secrets-manager more resilient to network failures that lead to potential token expiration. Increasing the token TTL is an option but not a good one.
I won't support both ways of login, it will make the code complex and can't find a very good reason for it.

I hope I can have a PR soon to share ;).

Thanks again for using it!

rvojcik commented 5 years ago

Hi @fcgravalos, that is perfect ! Thx much for this :) I appreciate it :)

It helps a lot and now I can simplify my deployment.

Thanks !

fcgravalos commented 5 years ago

@rvojcik you can build from master the latest version of secrets-manager and give it a try :)