feat | GitHub workflow to pull and sign images #26
There are no files selected for viewing
| 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] | ||
|
There was a problem hiding this comment. 🚨 issue (security): Potential security risk in using repository_dispatch payload for credentials Store credentials as GitHub secrets instead of passing them via |
||
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| contents: read | ||
| id-token: write # Required for OIDC token access | ||
|
|
||
| jobs: | ||
| build-and-sign: | ||
| runs-on: ubuntu-latest | ||
akash2237778 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| 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 }} | ||
|
Collaborator
Author
There was a problem hiding this comment. @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.
Member
There was a problem hiding this comment. 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 }} | ||
|
Member
There was a problem hiding this comment. Why are we pushing before we are signing? Is this the usual flow, i.e., are only pushed images signed (on the registry)?
Collaborator
Author
There was a problem hiding this comment. Correct this is the usual flow, only pushed images are signed. But image integrity is maintained. |
||
|
|
||
| - name: Sign container image | ||
| env: | ||
| COSIGN_EXPERIMENTAL: "1" | ||
|
Member
There was a problem hiding this comment. What is the significance of that? Why is it required? What are potential risks?
Collaborator
Author
There was a problem hiding this comment. 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 $IMAGE_NAME@${{ steps.get-digest.outputs.digest }}" | ||
| echo "Verify with: cosign verify $IMAGE_NAME@${{ steps.get-digest.outputs.digest }}" | ||
|
Member
There was a problem hiding this comment. Don't we want to explicitly verify the signed image against the digest ourselves in an additional step so that we are sure everything worked as expected?
Collaborator
Author
There was a problem hiding this comment. yes, we can do that. I'll push this change. |
||
|
|
||
|
|
||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?