signing&verifying container images based on Kubernetes Secrets

[developer-guy]

Closes #347

Known issues about the implementation:

• We duplicated the Kubernetes Client logics (reducing both responsibilities to a single function?)

• It's a bit hard to distinguish namespace/name compared to other providers (adding a new -k8s flag for signing and verifying)

• Ref priority refactoring? (File -> KMS -> K8s) - we're checking K8s namespace/name in first-order ever since a file exists in that path

• We bring a brand-new loadPublicKey function to cli/keys.go due to import cycle now allowed problem

• We haven't been checked the values of the data map of the secret whether is nil or not nil.

• Use public key as a file

$ kubectl get secrets my-secret -ojson | jq -r '.data["cosign.pub"]' | base64 -D > /tmp/cosign.pub
$ ./cosign verify -key /tmp/cosign.pub gcr.io/$(gcloud config get-value project)/hello-world:cosign --> #OK

• Use public key as a K8s Secret

$ ./cosign verify -key tmp/cosign.pub2 gcr.io/$(gcloud config get-value project)/hello-world:cosign
error: loading public key: checking if secret exists: secrets "cosign.pub2" not found

[dlorenc]

This looks awesome so far! What do you think about using a "-key k8s:https://namespace/name" prefix or something like that to help with the signer type selection logic?

[developer-guy]

This looks awesome so far! What do you think about using a "-key k8s:https://namespace/name" prefix or something like that to help with the signer type selection logic?

Thank you @dlorenc for giving this idea, we thought that too, to do so we should move this logic to sigstore project as a new provider called k8s maybe, wdyt?
cc: @Dentrax

[dlorenc]

That sounds great!

[Dentrax]

Exactly! Should we add a brand-new kubernetes:https:// provider into kms init() function? By doing so, we are able to clean kubernetes package from cosign into sigstore, I guess. (By moving the all the K8s dependencies, maybe?) 🤔

[dlorenc]

I think that would make sense - cosign would still need to keep the key generation code though right?

[developer-guy]

I think that would make sense - cosign would still need to keep the key generation code, though, right?

The most suitable place for the Kubernetes provider is in the cosign project because of the key generation code. Because we have to generate key pairs before creating the actual Kubernetes secret, thus that logic belongs to cosign. Therefore, we have to keep that Kubernetes provider logic within the cosign project.

WDYT @Dentrax @dlorenc?

[dlorenc]

Good point. That makes sense to me. We can always move it around later if there's demand for it!

[developer-guy]

Good point. That makes sense to me. We can always move it around later if there's demand for it!

@dlorenc, I pushed new changes to support the k8s:https:// thing and update the description of the PR with some of the working examples screenshots, can you please take a look at it when time permits?

cc: @Dentrax

[dlorenc]

This is awesome!