Allow setting labels on secrets used in conformance tests

[randmonkey]

The implementation Kong-Operator added a label selector on Secrets enabled by default to limit the secrets watched by the controllers to reduce the CPU & memory usage. But the conformance tests does not allow the implementation to label the secrets (used as listener certificates), the implementation has to change its defaults to watch all the secrets in the cluster.

Since only a small amount of secrets should an implementation to consider, it is reasonable to set the filters like label selectors on watched secrets to enhance security and reduce consumption of the controllers. So allowing the implementations to label the secrets in the conformance tests is meaningful. I do not think that a conformant implementation has to watch all the secrets in the cluster since most of them are not used.

[mlavacca]

I agree this is something worth implementing, and providing a mechanism to narrow down the amount of secrets to be watched by an implementation makes sense to me.

[mlavacca]

Curious to hear what other maintainers think about it @robscott @youngnick @shaneutt

[howardjohn]

I think this is a violation of the spec that is inappropriate as a default and should not be something the spec or conformance tests allows.

[robscott]

Since only a small amount of secrets should an implementation to consider, it is reasonable to set the filters like label selectors on watched secrets to enhance security and reduce consumption of the controllers.

+1, agree.

should not be something the spec or conformance tests allows

Kinda agree. I think today, any implementation should be able to support all Secrets (without labels) in a cluster to pass conformance tests. IMO, this does not need to be the default mode of the implementation.

I'd also be open to a proposal that standardized a concept like this in GW API, as it would alleviate some of sig-auth's concerns about the overly broad access to Secrets that many/most Ingress and Gateway controllers rely on. With that said, I don't believe that it's possible to limit RBAC access based on a label selector yet, so a more complete solution here would require some corresponding RBAC work.

In the past I've talked with @enj about options for restricting this kind of broad secret access, he might have some ideas for some easy wins.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale