Allow application developer to specify TLS client certificate

[tsaarni]

What would you like to be added:

Application developer should be able to define a client certificate that the proxy uses when it connects to developer's backend service with TLS.

Why is this needed:

Background:

This feature has been previously discussed and it was included as BackendPolicy.spec.tls.clientCertificateRef. Later, Gateway level configuration was preferred #395 and feature was removed. As per discussion in the comments of #400, I would like to propose this capability to be re-introduced as an optional feature, as an alternative to global (per gateway) configuration.

Use case details:

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 service
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. Symmetrically, application developer could enable client authentication by themselves, like they did for the server authentication in step 2 above but this would require client certificate to be configurable per backend service, not per Gateway which would be outside of application developers domain.

Implementing this enhancement has following advantages:

• Allows "self-service" workflow for the application developer, since they do not need to depend on cluster admin to configure client certificate on gateway level
• 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

[youngnick]

This seems reasonable to me, with the proviso that the BackendPolicy client certificate details are documented as specifying the details for a TLS interaction between the Gateway and the serving Pods.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[tsaarni]

/remove-lifecycle stale

[youngnick]

This API has changed substantially with v1alpha2, we will need to revisit how we can achieve this.

[robscott]

It seems like it would be possible to achieve this with some form of policy attachment initially, not sure if there's a better approach or built in policy resource we can offer here.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[tsaarni]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[youngnick]

/remove-lifecycle stale
/lifecycle frozen

[shaneutt]

While grooming we saw that this one was open for a long period of time without anyone with a strong use case to champion it. We're going to close this as we don't expect anyone's ready to drive it forward, but if you still want this feature and have a strong use case we will be happy to reconsider this and re-open.

[tsaarni]

The use case is presented in the description and in my mind it is strong: application developer should be able to configure TLS certificates to protect backend communication without bothering the cluster administrator.

I have not participated actively in the gateway-api project though, so it is of course fair to close this.

[mikemorris]

Noting for posterity and shared context that this appears to be a duplicate of #763

[tsaarni]

Hi @mikemorris

Noting for posterity and shared context that this appears to be a duplicate of #763

While being closely related,

1. this current issue Allow application developer to specify TLS client certificate #622 was about allowing application developer to manage the client certificate for proxy when it initiates TLS connection towards their upstream/backend service.
2. The discussion in Document Self Service TLS Certificate Approaches #763 is about allowing application developer to manage server certificate for proxy when it terminates TLS connection from an external client. That is the same use case as Ingress.spec.tls.secretName targets, where application developer can set certificate for a virtual host(s) that they manage.

After very quick look at #1430 it seems to me like "GEP-1282: Describing Backend Properties" would rather allow addressing this (closed) issue than #763? Cc @candita.

[mikemorris]

Thanks for the explanation @tsaarni, that makes sense and I think #1282 could possibly address both use cases.

[youngnick]

This issue absolutely should be solved by #1282, or whatever #1282 turns into. I'm actually going to reopen this and link it in to #1282 as a specific use case that may be better served with something more targeted than what #1282 turned into.

[shaneutt]

@youngnick reviewing your previous comment and reviewing #1282, it appears that #1282 now includes the scope of this issue so it seems we should be able to close this as a duplicate. If I'm mistaken or I've missed something, please re-open!

[youngnick]

Hmm, we actually haven't solved this one, because #1282 is basically declined. However, this and #1067 are basically duplicates.

@candita, there's some more background for #1067 here.