search

avast / marathon-vault-plugin

Marathon plugin which injects Vault secrets via environment variables
MIT License
30 stars 9 forks source link

support of file-based secrets #12

Open sev3ryn opened 6 years ago

sev3ryn commented 6 years ago

Hi, Are there plans to support file-based secrets for marathon? From what I experience - it is not working right now

rob-duewer commented 6 years ago

I'm wondering this too.

One case for this is when you have a secret (like a base64 encoded file or something) that is too long to pass in via env variable. (Mesos and docker will reject really long strings, with a os:execvpe error to the docker executor, from what I've found). Writing that secret's payload out to marathon's file based secret model so that the big secret payload could be available in the resulting app's task container would be really slick.

augi commented 6 years ago

Hi, thank you for this proposal!

Unfortunately, for our use-case the environment variables are sufficient so we are probably not going to add file-based secrets feature.

Also the problem is that I'm not sure how to implement it. We can use only the builder variable in taskInfo method and so we don't have any way how to store the secrets to a file in $MESOS_SANDBOX directory.

If you find a way how to implement this feature (ideally demonstrate via Pull Request) then we will definitely try to add this feature ASAP.

augi commented 6 years ago

Probably the only secure way how to store the secure value into a file is to use Mesos secrets but it would require to implement custom Mesos secret-resolver.

rob-duewer commented 6 years ago

I had originally envisioned using the builder variable to iterate through volume definitions, looking for the secret definition (just like is being done through the environment variables). Then injecting the decoded secret payload in, again very similarly to how injecting into the builder environment variable is being done. Looking at marathon file secrets, that would cause that resulting file to be written out to the target path in the running container.

However, I overlooked that the marathon behavior that the resulting file was not injected into a fully controllable spot inside the running app container image, only into a sub of the sandbox directory. And certainly, leaving the decoded secret payload into a persistent sandbox file (and that is easily accessible through the mesos interface), I completely agree with you, is definitely not a great idea!

And I think your analysis is right on that to do it properly to a tempfs isolated target, not exposed in the sandbox, would need a mesos secret-resolver. But I definitely agree, that's certainly not as easy as I had originally thought. Perhaps worth doing if there's a distinct case needed later where this is the only option and time allows, but not the quick and dirty case I had originally thought about.

For example, for the time being for my use, I think I'm going to take an alternate approach of passing in the file normally (via a URI fetch), but simply encrypting it. Then I'll protect that decryption passphrase via an environment variable secret in vault retrieved using the current method. Then I can use the resulting file in the running container however I want.

Thanks for taking the time to consider the request!

augi commented 6 years ago

If I understand it correctly, you are proposing this solution:

  1. The secret file is stored somewhere, accessible via HTTP(S) GET.
  2. You store this url to an environment variable (?) encrypted.
  3. The decryption key is in Vault.

Where would you store the encrypted url? And how to locate the decryption key in Vault?