[feature] generator_container_slsa3 should support passing image as a secret

[Danil-Grigorev]

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

The image input of the generator_container_slsa3 workflow is declared as input which prohibits using secrets as values. The following example fails:

  provenance:
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      image: ${{ secrets.REGISTRY_IMAGE }}
      # Passing secrets in any form is impossible in a reusable workflow.
      # Encrypted value could not be decrypteded as the workflow can't be used as a step,
      # and secret outputs are always redacted when are passed between jobs as an output.
    secrets:
      registry-username: ${{ secrets.REGISTRY_USERNAME }}
      registry-password: ${{ secrets.REGISTRY_PASSWORD }}

Describe the solution you'd like

The image input should be available to provide a secret. Example workflow could look liks this:

  provenance:
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      digest: ${{ needs.build.outputs.digest }}
    secrets:
      secret: ${{ secrets.REGISTRY_IMAGE }}
      registry-username: ${{ secrets.REGISTRY_USERNAME }}
      registry-password: ${{ secrets.REGISTRY_PASSWORD }}

Describe alternatives you've considered

Unfortunately due to destination registry restrictions, we have no alternatives, but to provide every value as a secret, and we are unable to change the overlapping values between the registry endpoint and the published image name.

Additional context

[laurentsimon]

Temporarily re-opening for a question. Low-entropy secrets tend to create intermittent problems due to this bug https://github.com/orgs/community/discussions/37942. We have not heard of folks running into this problem with the container generator though, even though username isa low-entropy secret too. But I think it could trigger the problem. @behnazh-w is my understanding correct?

[ianlewis]

Ah yeah. I totally forgot about that issue. Apologies for merging too quickly.

I agree, it might be an issue so I'll take a look. It could trigger if we have any job outputs whose value match any part of the image name.

[ianlewis]

BTW, we included the registry-username secret to support AWS IDs but document that you shouldn't use it for regular low-entropy username values.

In the case of image it will pretty much always be low-entropy so probably shouldn't be a secret. I think the workaround for these types of values was to use variables to move the secret value to a non-secret.
https://docs.github.com/en/actions/learn-github-actions/variables

[laurentsimon]

ahh, I forgot about these variables! Yeah now I remember that's the solution to the problem. So let's document this in the generic container workflow then. @Danil-Grigorev Can you confirm this would solve your problem?

[Danil-Grigorev]

Unfortunately with variables the issue is the same - they are visible in the logs. While encrypting output values may help, github contexts does not allow to pass a masked variable directly between the jobs too. And due to specifics of the provenance job - requirement to run on a separate VM, if I understand this correctly, the value can’t be decrypted in an additional step.

I can confirm that the change is working when I tried that, and is not affected by the bug you mentioned with the given configuration. In fact this is the first success with everything in place 😄

  provenance:
    needs: [sign, build]
    permissions:
      actions: read
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@main
    with:
      digest: ${{ needs.build.outputs.digest }}
      compile-generator: true
    secrets:
      image: ${{ inputs.secret_registry && secrets[inputs.image] || inputs.image }}-${{ inputs.arch }}
      registry-username: ${{ inputs.secret_registry && secrets[inputs.username] || inputs.username }}
      registry-password: ${{ secrets[inputs.password] }}

[laurentsimon]

Unfortunately with variables the issue is the same - they are visible in the logs.

Note that the container name will be available in the provenance, which is currently recorded in the transparency log too. So its values will leak no matter what.