Respect namespace property for "secretRef" in ClusterImagePolicy

[dherbrich]

Description

What needs to be improved? When creating a ClusterImagePolicy for policy-controller to validate images you have the option to put your public key in a secret and use the secretRef property to reference this secret. The type used is v1.secretRef which by k8s api reference (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#secretreference-v1-core) provides a namespace property to select the namespace the secret exists in. however, policy-controller does not use/respect this property so instead the secret needs to be created in the namespace where policy-controller is installed in. This requires a developer wanting to secure its namespace with a policy to have permissions to write secrets to the system namespace.

What should be done? Thinking this line of code https://github.com/sigstore/policy-controller/blob/main/pkg/reconciler/clusterimagepolicy/clusterimagepolicy.go#L212 needs to be modified to read the namespace property from the reference and use it instead of system.Namespace().

Alternatives to discuss

• alternatively the user can inline the public in the ClusterImagePolicy. do we think this is as good as user experience as using the secretRef? but than, if we don't want to support the namespace property it should be removed from the API and instead only use a "secretName" property instead of the secretRef object.
• are namespace scoped ImagePolicies in discussion ? in such policy the namespace would be given by its creation namespace and still the property would need to be removed from the API, but it would provide the same result "developers can secure their namespace without access to any other (system) namespace"

let me know if you require any more explanations.

[hectorj2f]

alternatively the user can inline the public in the ClusterImagePolicy. do we think this is as good as user experience as using the secretRef?

@dherbrich This design decision is due to security recommendations, we have to limit the privileges granted to the policy controller. I won't personally grant privileges to the policy-controller to access secrets in any namespace on-demand.

There are other third party tools that could help you to replicate secrets across namespaces:

reflector with support for auto secret reflection kubed with its secret syncing feature kubernetes-replicator secret replication

are namespace scoped ImagePolicies in discussion ? in such policy the namespace would be given by its creation namespace and still the property would need to be removed from the API, but it would provide the same result "developers can secure their namespace without access to any other (system) namespace"

Yes, the namespaced image policies were always part of our discussions as a potential new feature. I'd suggest you to write a doc with a more detailed proposal (api, logic). There are multiple challenges but I can see one regarding which policy to enforce how to resolve conflicts between cluster and namespaced image policies.

[hectorj2f]

@elfotografo007 @DennyHoang Are you also involved in providing support for namespaced Image Policies ?

[elfotografo007]

We are not. However may help with this. I remember someone in Slack reached out for this feature, but I thought the new selector in the ClusterImagePolicy was enough. Should we still add support for namespaced policies?

[hectorj2f]

@elfotografo007 Sure, I'd like to hear ideas on how we could improve the current implementation or support.

[eumel8]

Hello @hectorj2f,

I'm also very interested in a namespaced solution to verify container images. We operate Managed Kubernetes Services. The customer has permissions on namespace level and should be able to apply a policy with his cosign key and his policy which containers should handled. The container are stored in different private registry and needs credentials. So there are many thousands containers to manage in hundreds of namespaces/projects. I investigated Connaisseur, Kyverno, Kubewarden, OPA, and Sigstore Policy Controller over the year and no one can fulfill this requirement. Would be great if there will be a solution here.

many thanks!

[hectorj2f]

@eumel8 I believe one quick solution could consist on adding support for Namespaces as part of the spec.match field. Of course, these namespaces need to be labeled ...sigstore/include=true to be enforced, but this should work for selecting which namespaces to enforce among all labeled namespaces.

[eumel8]

Hi @hectorj2f,

meanwhile we developed our own solution with Validation Webhook. Simply verify signed image with a public key as Env var. A bit rude, but that's what we want.