Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication failure on upload with buildx #1332

Closed
1 of 3 tasks
albertodonato opened this issue Mar 2, 2025 · 2 comments
Closed
1 of 3 tasks

Authentication failure on upload with buildx #1332

albertodonato opened this issue Mar 2, 2025 · 2 comments

Comments

@albertodonato
Copy link

Contributing guidelines

I've found a bug, and:

  • The documentation does not mention anything about my problem
  • There are no open or closed issues that are related to my problem

Description

When switching to buildx for multi-arch builds, the action fails when trying to push to ghcr.io with the following error:

failed to push ghcr.io/albertodonato/query-exporter:pr-247: unexpected status from POST request to https://ghcr.io/v2/albertodonato/query-exporter/blobs/uploads/: 403 Forbidden

For reference, this PR has the changes breaking the workflow, which works fine when running without buildx.

Expected behaviour

The action should succeed and upload built images for all arches.

Actual behaviour

Build succeeds but upload fails.

Repository URL

https://github.com/albertodonato/query-exporter

Workflow run URL

https://github.com/albertodonato/query-exporter/actions/runs/13603617943

YAML workflow

name: Docker image

on:
  push:
    branches:
      - main
    tags:
      - "[0-9]+.[0-9]+.[0-9]+"
  pull_request:
    branches:
      - main

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      attestations: write
      id-token: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to the Container registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=schedule
            type=semver,pattern={{version}}
            type=ref,event=branch
            type=ref,event=tag
            type=ref,event=pr
            type=sha,prefix=sha-
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          platforms: linux/amd64,linux/arm64

      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Workflow logs

No response

BuildKit logs


Additional info

No response

@polarathene
Copy link

polarathene commented Mar 4, 2025

403 Forbidden

Your workflow run is not permitted to packages: write

GITHUB_TOKEN Permissions
  Attestations: read
  Contents: read
  Metadata: read
  Packages: read

This is something you need to keep in mind when you want to publish images with PR tags with pull_request event triggers to the workflow.

  • When you do this with a local branch and not a remote one (from someone who is not a member of the project), you will have full token rights like with the main branch, and you can use permissions to restrict that further for the workflow.
  • Third-party contributors do not have this permission and it cannot be granted for security reasons (as they can alter the workflows that the PR will run). So you must keep in mind that not all PRs will be compatible for this usage.

I'm not 100% sure, but you might be able to re-run the workflow as a project maintainer and that may run with your own token/permissions, allowing it to succeed.

You'd think that GHA would fail earlier instead when the permissions for the job weren't the expected ones you defined explicitly, but that's not something this action can resolve AFAIK? 🤷‍♂

@albertodonato
Copy link
Author

Thanks for the explaination!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants