Hey everyone, our team primarily utilizes GitOps for our app and service deployments, mainly relying on Argo CD as our GitOps controller. We also incorporate KCL to manage all our manifests. Recently, I've been considering how to establish a level of provenance for our Kubernetes manifests similar to what we do for our container images. For instance, we sign and verify all our application images using Kyverno to enforce the deployment of only trusted images. However, it seems we haven't applied the same trust model to our manifests, where a specific trusted manifest could be the only one allowed for deployment. To address this, I created an experimental Argo CD plugin that enables publishing manifests to an OCI image and uses the existing provenance checks during the manifest application process. If the image doesn't pass those policy checks, it gets rejected. The repo for this plugin can be found [here](https://github.com/meigma/blob-argo-cmp/), and it includes an [integration test](https://github.com/meigma/blob-argo-cmp/blob/master/.github/workflows/integration.yml) demonstrating the end-to-end validation. Just an important note: this is still highly experimental, so it's not ready for production use. I'm posting this to gather insights on whether it makes sense to implement provenance for deployment manifests as we do with application images.
1 Answer
You know, you can sign git commits too, right? This seems a bit like over-engineering. Signing manifests might not be necessary since you're already securing your container images.
Totally get your point, but signing manifests can still be beneficial. Using OCI images makes distribution easier and can be helpful if you're working with generated content that's not stored directly in git, like KCL configs. Plus, this approach can complement the Git history with more comprehensive checks. Thanks for sharing your thoughts!