Sign container images

[notdurson]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story
Following on from PR #5158 , I'd like to continue the security hardening story by signing container images, as well as attesting to their provenance. The solution implemented in 5158 attests to builds - that is, it verifies that an image was built by the entity claiming to have built it - but it doesn't actually sign the container images in a given build.

Describe the solution you'd like

The next logical step is signing images. This requires creation and persistence of a signing key in the Atlantis repo, which will then be used to request signing certificates from Sigstore. These will subsequently sign container images built during Atlantis releases. Downstream users can then use cosign to verify Atlantis images before use.

Describe the drawbacks of your solution

This solution introduces additional complexity into the already-complex Atlantis build process. In order to sign container images, a signing key must be generated and stored as a GH Actions Secret. By definition, the key must remain private; project contributors must not have access to it. Granting contributors access to the key compromises its confidentiality. Thus, the Atlantis maintainers must be involved in any PRs opened to complete this feature.

Since Atlantis builds six different images, six signatures will be generated and published for each build.

Describe alternatives you've considered

As in issue #5157, I explored forking Atlantis and signing images published by the fork. We found that this would lead to extra engineering burden on small teams. We believe it best for the canonical upstream repo to sign its images, so that any downstream forks can remain assured of the integrity of the images they use.