Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Querying the same secret present in multiple vaults will only return the value from the last worker #78

Open
Serneum opened this issue Feb 4, 2021 · 0 comments

Comments

@Serneum
Copy link
Contributor

Serneum commented Feb 4, 2021

Examples:

workers:
  -
    resources:
      - kind: all-secrets
        vaultBaseURL: https://vault1-tst.vault.azure.net/
        credential: cred1
      - kind: secret
        name: secret-key-base
        vaultBaseURL: https://vault2-tst.vault.azure.net/
        credential: cred2

    sinks:
      - path: secrets.json
        template: '{{ (index .Secrets "secret-key-base").Value }}'
    frequency: 60s
workers:
  -
    resources:
      - kind: secret
        name: secret-key-base
        vaultBaseURL: https://vault1-tst.vault.azure.net/
        credential: cred1
      - kind: secret
        name: secret-key-base
        vaultBaseURL: https://vault2-tst.vault.azure.net/
        credential: cred2

    sinks:
      - path: secrets.json
        template: '{{ (index .Secrets "secret-key-base").Value }}'
    frequency: 60s

The value set in the Secrets map will always be whichever worker ran most recently. Maybe this okay, but maybe an error should be thrown instead. You could do a quick check of the config for duplicate secret names when it comes to individual secrets, but all-secrets can only be checked as the values are returned. That will either be after we determine the secret name, or maybe after returning the full map, then iterating over all keys and checking before assigning the data to the Secrets map

Thinking about this further, I think if you have two vaults, the first one is used to grab a number of secrets, the second one is used with all-secrets, we would blow away all of the pre-existing secrets from the first vault. This is due to only checking if secret and all-secrets is used with the same vaultBaseUrl. Maybe all-secrets should iterate over the returned map and insert into the Secrets map instead of just being assigned to the map entirely and blowing away any old data

Part of this issue could be solved by #75 since you could alias any duplicate keys. In that case, I wonder if we should only assign the value to the alias when it is present to avoid issues where you do something like

workers:
  -
    resources:
      - kind: secret
        name: secret-key-base
        alias: skb
        vaultBaseURL: https://vault1-tst.vault.azure.net/
        credential: cred1
      - kind: secret
        name: secret-key-base
        alias: secret_token
        vaultBaseURL: https://vault2-tst.vault.azure.net/
        credential: cred2

    sinks:
      - path: secrets.json
        template: '{{ (index .Secrets "secret-key-base").Value }}'
    frequency: 60s

By accidentally referencing secret-bey-base in the template instead of one of the aliases, you may not get the value you expect. At that point, it really is just a mistake by the user, but should we do everything we can to prevent that possibility?

And once aliases are actually in place, we need to check if an alias conflicts with another alias or a resource name to avoid this issue as well.

workers:
  -
    resources:
      - kind: secret
        name: secret_token
        alias: token
        vaultBaseURL: https://vault1-tst.vault.azure.net/
        credential: cred1
      - kind: secret
        name: secret-key-base
        alias: secret_token
        vaultBaseURL: https://vault2-tst.vault.azure.net/
        credential: cred2

    sinks:
      - path: secrets.json
        template: '{{ (index .Secrets "secret_token").Value }}'
    frequency: 60s

would have issues because the second secret shadows the first secret via the alias

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant