opened
donaldguy
username_0
I may, myself, put some work into this but between it being a long while since I've touched Java/Groovy, unfamiliarity with the rundeck codebase, and a general lack of time I wanted to throw out the proposal for someone else to tackle if interested

## Motivation

As it currently stands there are two key storage backends, file and db -  http://rundeck.org/docs/administration/key-storage.html

While certain enhancements can be made in that direction, generally these lack several desirable qualities for secret management such as: encryption at rest, audibility, revocability, Role-based access control (per secret). While the bundled [Jasypt Encryption Plugin](http://rundeck.org/docs/plugins-user-guide/bundled-plugins.html#jasypt-encryption-plugin) addresses the first in principal, and other features of rundeck itself shine light on the others, but overall it is far from easy to get this right

HashiCorp's [Vault](https://www.vaultproject.io) is one of a class of software lately being popularized to address these concerns in a service oriented fashion.

Deferring to it as a storage mechanism would get Rundeck these gains "for free"

## Encryption/Storage Proposals 

1. Support Vault's [`transit`secret backend](https://www.vaultproject.io/docs/secrets/transit/index.html) as a [Storage Convertor Plugin](http://rundeck.org/docs/plugins-user-guide/configuring.html#storage-converter-plugins) - this would inject out of band audibility while also providing encryption at rest and a "break glass" procedure for locking down all keys without taking the rest of the rundeck system offline. Pursuant to the auth proposals below this could also be sufficient to include out-of-band role based access control. This would work in a manner similar to that described in this blog post: https://www.hashicorp.com/blog/how-atlas-uses-vault-for-managing-secrets.html

2. Support Vault's [`generic` secret backend](https://www.vaultproject.io/docs/secrets/generic/index.html) as a storage plugin. In addition to the benefits of 1, this would provide for out-of-band rotation and the ability to have expiring keys.

3. Support Vault's [`ssh` secret backend](https://www.vaultproject.io/docs/secrets/ssh/index.html) as a "storage" plugin to generate on demand one time use ssh credentials. While this requires greater cooperation from nodes, it moves the concerns of secret keeping pretty entirely out of the realm of rundeck's concern. It may be easier to implement as a Node Executor than as a secret backend.

## Authentication Proposals
Each of the above could in principal be done pursuant to any of the following ways to handle authentication

- A. ~~AppId~~ [AppRole](https://www.vaultproject.io/docs/auth/approle.html), [Token](https://www.vaultproject.io/docs/auth/token.html) or even [EC2 IAM Role](https://www.vaultproject.io/docs/auth/aws-ec2.html) based authentication for Rundeck as a whole. This would see rundeck users treated uniformly from Vault's perspective, leaving authorization concerns to rundeck's existing internal [ACL](http://rundeck.org/docs/administration/access-control-policy.html) management

- B. Building off the work of #1883 and bitly/oauth2_proxy#277 use delegated token from e.g. ` X-Forwarded-Access-Token` header of oauth2_proxy to feed into Vault's [`github` auth backend](https://www.vaultproject.io/docs/auth/github.html) and "act as user" for the duration of the request, enabling full fledged user-centric Role-Based-Access-Control on the secrets needed.

- C. Similar to B but using Vault's [`ldap` auth backend](https://www.vaultproject.io/docs/auth/ldap.html) 

### Closing Thoughts

Personally it is the premise of 3B or 2B that excite me. but 1A or 2A is probably the easiest to implement. The C's are probably important for feature completeness but irrelevant to me at the moment.

To add something perhaps better stated in motivation, I am amongst the people who currently am using Rundeck as a ~short lived containerized service using something like jjethwa/rundeck#31 - this makes the file backend a no-go, though something like a consul-template coprocess could let me use it as a sneaky approach to implement this. The db works but because I am delegating db credentials to the container hosts (in my case under a `fleet` cluster) more or less at-will, I would prefer stronger guarantees for my needed secrets. And since I need to manage RBAC policies in other systems already, I'd like to not need to duplicate the logic into rundeck.

Anyway, as I said, I might get to it - but if anyone else is excited to tackle it, please do :smile:
Enhancement Proposal: Hashicorp Vault backend for Key "Storage"
issue
created
donaldguy
username_0
additional Auth Proposal 
D. Pass through browser-presented client TLS certs and feed through the [`cert` auth backend](https://www.vaultproject.io/docs/auth/cert.html) ; cause everyone love maintaining client-cert infrastructure 😅
comment
created
cornfeedhobo
username_1
Yes. So much yes.
comment
created
ClarenceXu
username_2
Vote +1
comment
created
cornfeedhobo
username_1
So much yes to this entire proposal. I look forward to seeing something get traction.
comment
created
IngussNeilands
username_3
+1
comment
created
radius314
username_4
👍
comment
created
ryansmithevans
username_5
:+1:
comment
created
elliottsam
username_6
+1
comment
created
jothoma1
username_7
+1
comment
created
thalesac
username_8
People, please stop with this +1. 
In order to show support, subscribe to this issue and/or click on the thumbs of the **first post**.
comment
created
ValFadeev
username_9
@username_0 and everyone: in case there has not been any work started on this one yet, which is reasonably far down the line, I am happy to have a go. Just released a plugin for [Nomad](https://github.com/username_9/rundeck-nomad-plugin), so got a decent overview of Rundeck plugin system internals.
I would probably focus on plan **2A** initially, with token-based auth. Lead time 4-6 weeks to a minimal working implementation, given I have other workloads to handle.
comment
created
ahonor
username_10
@username_9 let us know if there is any guidance or feedback you need. Thanks! :)
comment
created
ValFadeev
username_9
@username_10 I sure will do. In the meantime would you mind adding the Nomad one to the plugins page. I could use some feedback that might be helpful in the design of the Vault plugin. Thanks in advance!
comment
created
ahonor
username_10
@username_9 Great. Also, here's a link to the Nomad step: http://rundeck.org/plugins/nomad/2017/08/14/nomad-step.html
comment
created
jothoma1
username_7
Hi,
@username_9 @username_10 Any news on this ?
Thanks in advance
comment
created
ValFadeev
username_9
@username_7 I did start work on this one, but it is taking a bit longer than expected. Hoping to release something in the next month or so.
comment
created
ValFadeev
username_9
**update**: will be publishing the first "draft" by the end of this week. Rather raw and buggy, so don't get too excited just yet. However, it does cover quite a lot in terms of auth backends, thanks to the good client library.
comment
created
ValFadeev
username_9
here it is: https://github.com/username_9/rundeck-vault-plugin
also posted some explanatory notes here:
https://groups.google.com/forum/#!topic/rundeck-discuss/jmqAwcBO-Q8
comment
closed
donaldguy
username_0
issue