You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Examples:
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, butall-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 mapThinking 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
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.
would have issues because the second secret shadows the first secret via the alias
The text was updated successfully, but these errors were encountered: