[FEAT] Option to skip masking secrets

[rfinnie]

Is your feature request related to a problem? Please describe.

A common use case is to store both an actual secret (e.g. a password) with an associated piece of information (e.g. a username). If the user does not consider the username to be sensitive, it would be nice to tell the action to not mark a key as masked.

To be clear, I think this should be explicitly opt-in, and keys should remain masked by default.

Describe the solution you'd like

Something like this could work:

jobs:
    build:
        steps:
            - name: Import Secrets
              uses: hashicorp/[email protected]
              with:
                url: https://vault.mycompany.com:8200
                token: ${{ secrets.VAULT_TOKEN }}
                caCertificate: ${{ secrets.VAULT_CA_CERT }}
                secrets: |
                    secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID nomask ;
                    secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY

This layout would not be compatible with the implicit normalized variable format, but I think requiring an explicit variable when using nomask is fine.

Describe alternatives you've considered

Hardcoding the non-secret part in the workflow... ?

[jrarmstro]

On GitHub Enterprise Server, GitHub App IDs are typically very small numbers. When they're masked, this inhibits our ability to produce (unrelated) outputs from a step using a GitHub App due to masking of this short (non-secret) value masking unrelated output.

[maxcoulombe]

Hey @rfinnie , we discussed this request internally and we are concerned that not masking secrets would introduce security pitfalls, even as an opt-in. So we are leaning on the side of not implementing this feature.

Can you give some examples of use cases that would only be possible with unmasked secrets?

Another justification to not support this feature is that secrets defined directly in GitHub cannot be unmasked, and secrets obtained through vault-action should behave similarly to native GitHub secrets. They probably do not offer this option due to the same security concerns that it'd make it too easy to accidentally disclose sensitive values by mistake.

Let us know if these justificaitons make sense. We're happy to change our minds if someone can provide compellig use cases!

To @jrarmstro 's comment, if I understand correctly the behavior you are describing of values getting masked in unrelated outputs it is not something we control. GitHub actions use value-based comparisons when applying the masks, so if unrelated outputs match the value of a secret present in the context they will be masked as well. This is not a behavior specific to vault-action so I don't think the solution would be to unmask secrets.

[maxcoulombe]

Additional context, this would be a potential solution for request #502. I'm linking the issue here so we can consolidate the discussions.

[fairclothjm]

Closing since we have decided not to support this. Masking secrets is fundamental to how vault-action remains secure and we would prefer to err on the side of caution.