Skip to content

feat | GitHub workflow to pull and sign images #26

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.

Sign up for GitHub

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

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from
Open

feat | GitHub workflow to pull and sign images #26

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5ebeb83
feat | GitHub workflow to pull and sign images
akash2237778 Jun 3, 2025
36180e6
fix review comments
akash2237778 Jun 3, 2025
461aa2f
fix: Image verification after signing
akash2237778 Jul 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions .github/workflows/image-signer.yaml
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not immediately obvious why we are pulling an existing image, retag it, push it and sign it. Where does the original image come from? And what event would typically trigger this workflow?

Can you explain in the documentation, together with a concrete example, how this whole process works? The use case has to be crystal clear. Ideally include a diagram.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more question I have is in the linked issue: Do you think other container registries (Docker Hub) would work as well?

Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
name: Pull and Sign Container Image

on:
repository_dispatch:
types: [sign-image]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 issue (security): Potential security risk in using repository_dispatch payload for credentials

Store credentials as GitHub secrets instead of passing them via client_payload, and restrict workflow dispatch permissions to trusted users.

workflow_dispatch:

permissions:
contents: read
id-token: write # Required for OIDC token access

jobs:
build-and-sign:
runs-on: ubuntu-latest
steps:
# Checkout the repository
- name: Checkout code
uses: actions/checkout@v4

# Log in to Docker Hub
- name: Log in to Docker Hub
uses: docker/login-action@v3
with:
registry: docker.io
username: ${{ github.event.client_payload.docker_username }}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uniqueg do you think Container Registry will remain same for one pubgrade instance? If yes, then we can move these registry credentials to Github Secrets.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instance: yes. Implementation: no. That is, one organization deploying Pubgrade will almost certainly use a different set of credentials than another organization deploying their own Pubgrade instance.

Would one code repository use different instances/deployments of Pubgrade, connected with different registries? Possibly. But it's not a feature we absolutely have to support. At least not now.

Does that answer your question?

password: ${{ github.event.client_payload.docker_password }}

# Pull the container image
- name: Pull Image
run: docker pull ${{ github.event.client_payload.pull_tag }}

- name: Extract image name
run: |
IMAGE_TAG=${{ github.event.client_payload.push_tag }}
IMAGE_NAME=$(echo $IMAGE_TAG | sed 's/:.*//')
echo "IMAGE_NAME=$IMAGE_NAME" >> $GITHUB_ENV

- name: Get Image Digest
id: get-digest
run: |
DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' ${{ github.event.client_payload.pull_tag }} | cut -d'@' -f2)
echo "digest=$DIGEST" >> $GITHUB_OUTPUT


# Install Cosign
- name: Install Cosign
uses: sigstore/cosign-installer@v3
with:
cosign-release: 'v2.2.1' # Use a specific version for stability

- name: Tag changed
run: docker tag ${{ github.event.client_payload.pull_tag }} ${{ github.event.client_payload.push_tag }}

- name: Push Tagged Image
run: docker push ${{ github.event.client_payload.push_tag }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we pushing before we are signing? Is this the usual flow, i.e., are only pushed images signed (on the registry)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct this is the usual flow, only pushed images are signed. But image integrity is maintained.


- name: Sign container image
env:
COSIGN_EXPERIMENTAL: "1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the significance of that? Why is it required? What are potential risks?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This flag is needed to use Keyless signing in Cosign. I'll check if we can remove it with some latest version of cosign

run: |
cosign sign --yes ${{ github.event.client_payload.push_tag }}

# Output the digest for reference
- name: Output Digest for Verification
run: |
echo "Image pushed and signed as ${{ github.event.client_payload.push_tag }} with digest akash7778/sampletestt@${{ steps.get-digest.outputs.digest }}"
echo "Verify with: cosign verify $IMAGE_NAME:${{ steps.get-digest.outputs.digest }}"