drop clientCertificateRef from backendpolicy

[hbagdi]

See #395

[hbagdi]

/cc @robscott

[robscott]

A bit more context - we also discussed this in Slack and at office hours today and determined that it didn't make sense to specify this on BackendPolicy. Maybe in the future it could make sense somewhere that was more closely tied to Gateway.

Thanks!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hbagdi, robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tsaarni]

Sorry for commenting an old issue, but wanted to ask your opinion about potential use case for the removed attribute.

Assume we have application developer working within Kubernetes namespace. Application developer wants to secure the traffic between proxy and their backend service.

1. Application developer generates their own certificates and configures server certificate to their backend server
2. To get the proxy to validate the server certificate, the application developer configures reference to the CA certificate secret to BackendPolicy.spec.tls.certificateAuthorityRef

Next the developer would like to protect the backend service even further, by allowing incoming TLS connections only from the proxy - the developer would like to enable TLS with mutual authentication by configuring a client certificate to the proxy, and have their backend validate that against trusted CA certificate.

Symmetrically, application developer could enable client authentication by themselves, like they did for the server authentication in step 2 above. This would require client certificate to be configurable per backend service, not per Gateway.

Previously I worked with similar feature in Contour projectcontour/contour#2338 and there we implemented global configuration only. It would be nice to have it per backend server as well, since that will:

• Allow "self-service" workflow for the application developer, since they do not need to depend on cluster admin to configure client certificate for the proxy
• Cluster admin does not need to manage / coordinate / distribute single CA certificate for the development teams working in the cluster. Each team can configure their own client certificates for the proxy and CA certificates to their backend for validating the client cert

[hbagdi]

@tsaarni That is a very reasonable use case. Could you please open a Github issue to track your use case?

The thinking here was to enable the global use case first, recommend that approach first and then add in this attribute in future.
The global client-certificate for a Gateway should suffice most use cases and per-service client certificates should be in the minority.

[albionb96]

@tsaarni That is a very reasonable use case. Could you please open a Github issue to track your use case?

The thinking here was to enable the global use case first, recommend that approach first and then add in this attribute in future. The global client-certificate for a Gateway should suffice most use cases and per-service client certificates should be in the minority.

@hbagdi I know that I am replying to an old thread but, I don't quite understand what would be the "The global client-certificate for a Gateway" solution that you are mentioning here, because from my quick research, I came up at the following conclusion: #3024.

I cannot find anywhere that this feature is being supported from the GatewayAPI, also in this document it says that this feature is still not proposed: https://gateway-api.sigs.k8s.io/geps/gep-2907/?h=#3-configure-client-certificate-that-gateway-should-use-to-connect-to-backend. I don't know if that is up-to-date.

[youngnick]

Currently, there is no global client certificate for a Gateway solution. As part of work on #3024 and others, we are working on building that support out. I'd encourage you to join the discussion either on #3024, or to come to one of our community meetings and talk about what you're looking for.

The basic plan is up for debate, but our current thinking is that the first thing we do may be to allow the configuration of a secret on a Gateway for the Gateway implementation to use to talk to the backends. (Thus, "client secret").

If you're talking about other types of client secret, then again, I'd encourage you to join the discussion on something that's currently active.

[albionb96]

Currently, there is no global client certificate for a Gateway solution. As part of work on #3024 and others, we are working on building that support out. I'd encourage you to join the discussion either on #3024, or to come to one of our community meetings and talk about what you're looking for.

The basic plan is up for debate, but our current thinking is that the first thing we do may be to allow the configuration of a secret on a Gateway for the Gateway implementation to use to talk to the backends. (Thus, "client secret").

If you're talking about other types of client secret, then again, I'd encourage you to join the discussion on something that's currently active.

I would really like to join the discussion at #3024 , but it seems like I am the only attendant. (The discussion/question came from me and I am not getting any answers).