Implement /system/secrets and use Nomad's configured Vault API

[acornies]

What are the steps to reproduce this issue?

1. download latest faas-cli ()
2. download latest gateway >= 0.9.14
3. try out faas-cli ~= 0.8.3 using faas-cli secret ...

What happens?

The secret endpoints are not yet supported.

Any other comments?

Adding this for tracking. The approach so far is to implement against Vault's API using the already-established convention of the default Vault policy and key prefix from faas-nomad.

[alexellis]

I didn't realize this wasn't implemented yet. I mentioned Nomad being available in the blog post, but given that this provider has fewer users this may be something that goes unnoticed in the interim.

https://www.openfaas.com/blog/unified-secrets/

[acornies]

Working on it...

[nicholasjackson]

Just taking a look at this, need to think about the security round vault, theoretically the access to Vault through the CLI is weaker than the vault auth. Just need to think about the security and how the policy would be implemented.

[acornies]

@nicholasjackson My implementation thus far uses the Nomad agent self config, which contains the Vault info. Ultimately faas-nomad needs a management style Nomad ACL token, which will provide the Vault token that's configured on the Nomad agent. It's very much tied to the permissions the Nomad agent has. (token seems to be redacted)

[acornies]

Actually, the only way to do this properly is to have an "openfaas" Vault policy (already required with secrets) and an AppRole token tied to that policy which is provided to faas-nomad. That way, the faas-cli can only manage secrets defined in the policy. The vault service and other config is discovered via agent/self etc.

This requires some Vault management up front, but I don't see a way around that. Suggestions?

[acornies]

I'd appreciate some feedback here: acornies@57bd520 when you get a chance. I'll keep going down this road unless I hear otherwise.

[acornies]

Addressed in #70 using Vault approle and secrets v1.