[bug] Don't use package: write permissions for container workflow

[ianlewis]

Using package: write on the workflow is convenient but is not setting least privilege in the case where users are not using ghcr.io. We should force users to set the username and password and log into ghcr.io manually.

Related to #547

[ianlewis]

If the GitHub token does not have package: write permissions, logging in using Docker succeeds but cosign fails when trying to upload the image attestation.

This may be an issue with cosign or the workflow's usage of it. Maybe it's trying to use the job's GHA token rather than using Docker's login credentials?

Error: signing ghcr.io/ianlewis/actions-test@sha256:5d7b0d4b8d68d8aceef2027401c31d1db67ffb9a8e36e5fc52f0c123b37798d3: POST https://ghcr.io/v2/ianlewis/actions-test/blobs/uploads/: DENIED: installation not allowed to Write organization package
main.go:62: error during command execution: signing ghcr.io/ianlewis/actions-test@sha256:5d7b0d4b8d68d8aceef2027401c31d1db67ffb9a8e36e5fc52f0c123b37798d3: POST https://ghcr.io/v2/ianlewis/actions-test/blobs/uploads/: DENIED: installation not allowed to Write organization package

[ianlewis]

This may be an issue with cosign or the workflow's usage of it. Maybe it's trying to use the job's GHA token rather than using Docker's login credentials?

The workflow uses cosign login to login to the repository, but this doesn't seem to work with GHA tokens even if you set package: write permissions on the call to the reusable workflow and you pass the token in the registry-password secret.

[ianlewis]

#1283 will reopen this. It seems there is an issue with cosign not using the registry credentials provided by cosign login for some requests. I'm assuming it's because the fact that it's preferring the ambient GitHub credentials provided by GitHub actions.

I created sigstore/cosign#2489 to track.

[mchmarny]

This appears to be also failing against Artifact Registry (full trace for the above error here)

main.go:62: error during command execution: signing us-west1-docker.pkg.dev/cloudy-s3c/s3cme/s3cme@sha256:f17fc9c49e3e1cef22022332c0f55a51d60b12d7403990a6aac6564f4bbd4910: GET https://us-west1-docker.pkg.dev/v2/token?scope=repository%3Acloudy-s3c%2Fs3cme%2Fs3cme%3Apull&service=: DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/cloudy-s3c/locations/us-west1/repositories/s3cme" (or it may not exist)

This is despite of the cosign login to registry being succesful in the previous step

login to us-west1-docker.pkg.dev
auth.go:191: logged in via /home/runner/.docker/config.json

Also, cosign attest (after authentication with the same OIDC token), with the same predicate.json file, on the same image, works fine, so the rights of the impersonated service account for which the token was issued are correct.

COSIGN_EXPERIMENTAL=1 cosign attest --force --predicate predicate.json --type slsaprovenance $IMG_DIGEST

I ended up abandoning this reusable workflow and just used the released slsa-github-generator artifact manually (after sha verification).

FWIW, a Go app repo template with image build/publish pipelines, SBOM, and SLSA provenance (using your slsa-github-generator), and OIDC, KMS and Artifact Registry is available in https://github.com/mchmarny/s3cme

[ianlewis]

@mchmarny I'm pretty sure this doesn't have to do with the GITHUB_TOKEN's package:write permissions so I created issue #1545 to track.