cruise-automation / daytona

A Vault client, but for containers and servers.
Apache License 2.0
293 stars 33 forks source link

Bug: Can't write secret file at the same time as a single secret #83

Closed jonnylangefeld closed 2 years ago

jonnylangefeld commented 2 years ago

On a kubernetes workload that is supposed to write a secrets file as well as a single secret to file the following env vars are configured:

          - name: DAYTONA_SECRET_DESTINATION_PATH
            value: '/home/vault/secrets'
          - name: DAYTONA_SECRET_DESTINATION_A_KEY
            value: '/home/vault/a-key'

However, that only writes the /home/vault/secrets file, not the /home/vault/a-key file, which is unexpected. It should write both files.

If the DAYTONA_SECRET_DESTINATION_PATH var is removed like so:

          # - name: DAYTONA_SECRET_DESTINATION_PATH
          #   value: '/home/vault/secrets'
          - name: DAYTONA_SECRET_DESTINATION_A_KEY
            value: '/home/vault/a-key'

Then it writes the /home/vault/a-key file, which is expected.

The reason this is flagged as bug is because it still works with the deprecated SECRET_PATH env variable:

          - name: SECRET_PATH
            value: '/home/vault/secrets'
          - name: DAYTONA_SECRET_DESTINATION_A_KEY
            value: '/home/vault/a-key'

Writes both files, /home/vault/secrets, and /home/vault/a-key, which is expected. So once the SECRET_PATH variable is finally removed this fix would not work anymore.

Maybe the solution to this problem is actually to not deprecate the SECRET_PATH env variable. Because its replacement DAYTONA_SECRET_DESTINATION_PATH has the flaw that it's unclear what it's supposed to do for secrets actually called path. Is it then supposed to write all secrets in that directory into one file, or is it only supposed to write that one secret called path?

broamski commented 2 years ago

@jonnylangefeld can you please verify this is still the case with the latest version? If so, can you please also provide some example storage path prefixes; VAULT_SECRET_X, VAULT_SECRETS_Y?

jonnylangefeld commented 2 years ago

I don’t have a test setup for this at the moment. Was there a commit that would have fixed this?

broamski commented 2 years ago

Without knowing which tag you tested this on, it's hard to say!

broamski commented 2 years ago

In the latest versions, this bug has been fixed. Here's an example configuration:

VAULT_SECRET_SINGLE=secret/data/single DAYTONA_SECRET_DESTINATION_SINGLE=$HOME/single \
VAULT_SECRETS_MANY=secret/data DAYTONA_SECRET_DESTINATION_MANY=$HOME/many
vault list secret/data
Keys
----
single
private_key
api_key

which yields:

{"level":"info","applicationName":"daytona","count":3,"outputDestination":"/home/compute/many","time":"2022-07-14T11:39:19-04:00","message":"Wrote secret"}
{"level":"info","applicationName":"daytona","count":1,"outputDestination":"/home/compute/single","time":"2022-07-14T11:39:19-04:00","message":"Wrote secret"}