feat: sign released binaries and images with cosign
#60
Conversation
WalkthroughThe changes encompass updates to the GitHub Actions workflow for release processes, enhancements to the GoReleaser configuration for artifact signing and conditional execution, the introduction of a shell script for CI environment checks, and the creation of documentation outlining the release process. These modifications collectively improve the handling of releases, artifact signing, and the overall CI/CD workflow. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant CI
participant GoReleaser
participant Cosign
participant DockerHub
Developer->>CI: Create semantic versioned tag
CI->>GoReleaser: Trigger release process
GoReleaser->>Cosign: Sign artifacts
GoReleaser->>DockerHub: Publish images
Cosign->>Developer: Verify artifact integrity
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #60 +/- ##
=======================================
Coverage 90.40% 90.40%
=======================================
Files 13 13
Lines 521 521
=======================================
Hits 471 471
Misses 34 34
Partials 16 16 ☔ View full report in Codecov by Sentry. |
jamestelfer
force-pushed
the
signed-binaries
branch
from
ae0d7ee
to
5563e37
Compare
jamestelfer
changed the title
cosign
The CI variable is not present locally; this is used to disable changelog and release by default when running GoReleaser locally.
Signs using the GHA OIDC token provided by the build. This verifies both where it is build and the source that was used to build it from.
jamestelfer
force-pushed
the
signed-binaries
branch
from
a1b5a9e
to
a57c0c7
Compare
|
@coderabbitai full review |
Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (2)
docs/releases.md (2)
11-21: The release criteria are well-defined.The section clearly outlines the factors that determine when a release is ready, emphasizing the importance of stability and the preference for smaller, more frequent releases.
Consider rephrasing the sentence on line 13 to avoid overusing the word "greater":
-Releases are created on an as-needed basis. We prefer multiple, smaller releases over releases that have a greater number of changes. +Releases are created on an as-needed basis. We prefer multiple, smaller releases over releases with a larger number of changes.Tools
LanguageTool
[style] ~13-~13: The word ‘greater’ tends to be overused in this context. Consider an alternative.
Context: ...ller releases over releases that have a greater number of changes. A release is ready when: ...(A_GREAT_NUMBER)
51-72: The local testing process for releases is well-explained.The section provides clear instructions on how to test the release process locally using GoReleaser. It includes the command to run, the processes that are executed, and the processes that are skipped during local testing. The explanation of what local testing verifies is also helpful.
Consider adding a comma after "Thus" on line 71 to improve readability:
-Thus release testing verifies a proportion of the GoReleaser configuration, and allows the image/binary builds to be integration tested. +Thus, release testing verifies a proportion of the GoReleaser configuration, and allows the image/binary builds to be integration tested.Tools
LanguageTool
[uncategorized] ~71-~71: A comma might be missing here.
Context: ...g generation - GitHub release creation Thus release testing verifies a proportion o...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (4)
- .github/workflows/release.yaml (3 hunks)
- .goreleaser.yaml (4 hunks)
- ci-only.sh (1 hunks)
- docs/releases.md (1 hunks)
Additional context used
LanguageTool
docs/releases.md
[style] ~13-~13: The word ‘greater’ tends to be overused in this context. Consider an alternative.
Context: ...ller releases over releases that have a greater number of changes. A release is ready when: ...(A_GREAT_NUMBER)
[uncategorized] ~71-~71: A comma might be missing here.
Context: ...g generation - GitHub release creation Thus release testing verifies a proportion o...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
Additional comments not posted (15)
ci-only.sh (3)
1-3: LGTM!The shebang line and the strict error handling settings are correct and follow best practices.
4-8: LGTM!The check for the CI environment and the handling of non-CI environments are implemented correctly. Skipping the script execution and exiting with a status code of 0 in non-CI environments is a good approach. The message printed when skipping the script execution provides clarity on what is being skipped.
10-11: LGTM!Using
execto execute the script parameters is a good approach to use the script as a wrapper around other commands or scripts. It ensures that the script parameters are executed in the same environment as the current script..github/workflows/release.yaml (3)
10-12: LGTM!The
id-token: writepermission is correctly added and is required for generating the OIDC token used as the signing identity forcosign. This aligns with the PR objective.
34-37: LGTM!The "Install Cosign" step is correctly added using the
sigstore/cosign-installer@v3action with a specified release version. This step is necessary for signing the released artifacts with Cosign.
53-53: Verify the target DockerHub repository.Please ensure that "chinmina" is the intended DockerHub repository for publishing the images. If not, update the
KO_DOCKER_REPOenvironment variable with the correct repository name.docs/releases.md (3)
1-10: LGTM!The high-level overview of the release process is clear and concise. It covers the key aspects of the process, including the trigger, versioning, commit messages, artifact creation, and signing.
22-27: The release trigger process is clearly explained.The section provides a clear explanation of how releases are triggered using semantic-versioned tags and specifies that only repository administrators have the permission to create these tags.
28-50: The release signing process is thoroughly documented.The section provides a detailed explanation of the release signing process using the Sigstore ecosystem. It covers the tools used (
cosign,fulcio, andrekor), the benefits of the signing process, and the publishing of transparency records..goreleaser.yaml (6)
4-8: LGTM!The addition of the environment variables provides flexibility to control the behavior of the CI/CD pipeline based on the execution environment.
CIis used to determine if the pipeline is running in a CI environment.CHANGELOG_DISABLEandRELEASE_DISABLEare used to conditionally disable changelog generation and releases based on theCIvalue, which helps to avoid unnecessary steps in non-CI environments.KO_DOCKER_REPOis used to set the Docker repository for thekotool, with a default value that ensures a unique repository name for each run.This approach enhances the adaptability of the pipeline to different execution contexts.
22-33: Excellent addition of binary signing usingcosign!The introduction of the
binary_signssection to sign the released binaries usingcosignis a significant enhancement to the security and authenticity of the artifacts. Here are the key points:
- The signing process is executed only in the CI environment, ensuring the availability of the necessary OIDC token and avoiding unnecessary signing attempts in non-CI environments.
- The
cosign sign-blobcommand is used to sign the artifact and generate a.cosign.bundlefile for verification.- The
.cosign.bundlefile allows for easy verification of the signed artifacts by users, enhancing trust in the released binaries.This addition strengthens the overall security posture of the project and provides users with the ability to verify the authenticity of the artifacts they consume.
41-44: Great addition of the.cosign.bundlefile to the archive!Including the
.cosign.bundlefile generated by thebinary_signsstep in the archive is a thoughtful enhancement to the user experience. It provides several benefits:
- Users can easily verify the authenticity of the downloaded artifacts without the need to separately download the
.cosign.bundlefile.- The
strip_parentoption ensures a clean and straightforward archive structure, making it easier for users to locate and use the.cosign.bundlefile.This addition streamlines the verification process for users and promotes the adoption of secure practices when consuming the released artifacts.
48-48: Effective use of conditional changelog generation!The update to the
changelogsection to conditionally disable changelog generation based on theCHANGELOG_DISABLEenvironment variable is a smart approach. It offers the following benefits:
- Flexibility in controlling the behavior of the changelog generation process based on the execution environment.
- In non-CI environments, changelog generation will be enabled by default, allowing for manual generation of changelogs when needed.
- In CI environments, changelog generation will be disabled, avoiding unnecessary generation of changelogs during automated builds, saving time and resources.
This conditional behavior ensures that changelogs are generated only when required, making the overall process more efficient and tailored to the specific needs of each environment.
53-53: Effective use of conditional release disabling!The update to the
releasesection to conditionally disable releases based on theRELEASE_DISABLEenvironment variable is a prudent approach. It offers the following benefits:
- Flexibility in controlling the behavior of the release process based on the execution environment.
- In non-CI environments, releases will be enabled by default, allowing for manual creation of releases when needed.
- In CI environments, releases will be disabled, avoiding unintended releases during automated builds, reducing the risk of accidental deployments.
This conditional behavior ensures that releases are created only when explicitly intended, providing an additional layer of control and safety to the release process.
98-119: Excellent addition of Docker image signing usingcosign!The introduction of the
docker_signssection to sign the Docker images usingcosignis a significant enhancement to the security and authenticity of the container artifacts. Here are the key points:
- The signing process is executed only in the CI environment, ensuring the availability of the necessary OIDC token and avoiding unnecessary signing attempts in non-CI environments.
- The
cosign signcommand is used to sign the Docker image, providing an additional layer of security and authenticity to the container artifacts.- The
artifactsoption is set toallto ensure comprehensive coverage and prevent any unsigned images from being released.- The inclusion of the transparency log index enhances transparency and allows for easy auditing and verification of the signed images.
This addition strengthens the overall security posture of the project and provides users with the assurance that the container images they consume are authentic and tamper-proof.
Uses
cosignand the Github Actions OIDC token to sign the released binaries and images such that they can be verified before use.Summary by CodeRabbit
New Features
ci-only.sh).docs/releases.md).Configuration Enhancements
.goreleaser.yaml..github/workflows/release.yaml.These changes improve the flexibility and transparency of the release process, ensuring better artifact management and signing.