Secret lookup in GitHub Actions is limited to one path in Vault

[robwhitby]

Halfpipe uses Concourse's secret format of ((<map>.<key>)).

Concourse has it's own logic to lookup that secret in Vault, in order or priority:

1. <team>/<pipeline>/<map>
2. <team>/<map>
3. <shared>/<map>

When rendering a GitHub Actions workflow we currently only lookup the secret in 2. This means it is impossible to reference a secret in the pipeline or shared locations.

[robwhitby]

I don't see a way of supporting multiple locations using the hashicorp vault action. Perhaps we should look at it in a different way and allow a different secret syntax in halfpipe.

e.g. as well as ((map.key)) we could allow ((/springernature/shared/map key))

[dhs3000]

One other way could be to enhance (/let it be enhanced) the hashicorp vault action to allow for optional secrets, so that we can lookup all possibilities and take the first existing secret.

Having that said, the option to allow for a format defining the full path as proposed by @robwhitby sounds more flexible/better to me.

[robwhitby]

@dhs3000 yep agree. I would prefer to avoid modifying the hashicorp action because (a) we'd have to then maintain it, and (b) the logic of looking in 3 places is specific to Concourse - so in the future a third target platform for halfpipe would have the same problem

[robwhitby]

this is how I think it will work:

halfpipe manifest	concourse	actions
((map.key))	/springernature/team/pipeline/map key /springernature/team/map key /springernature/shared/map key	/springernature/team/map key
((/path/to/map key))	lint error	/path/to/map key

It means actions won't have the fallback logic of Concourse but will be more flexible as secrets can be read from anywhere in Vault (assuming the credentials used allow access).