search

solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.08k stars 437 forks source link

mTLS: Support separate secret (or configmap) for CA to verify downstream client certs #7232

Open dynajoe opened 2 years ago

dynajoe commented 2 years ago

Version

1.12.x (latest stable)

Is your feature request related to a problem? Please describe.

The docs recommend combining the serving cert with the cert used to verify downstream clients in one secret: https://docs.solo.io/gloo-edge/latest/reference/cli/glooctl_create_secret_tls/

This is problematic when using cert-manager Let's Encrypt certs because it populates ca.crt, tls.crt, and tls.key. All three of these fields describe the serving cert. For public facing mutual TLS the CA's that verify clients are usually different from the CA that issued the serving cert.

Describe the solution you'd like

A new field that can point to a config map or secret containing the CA's to verify client cert separate from the secret containing the serving cert.

Istio accomplishes this by convention by looking for a secret named exactly the same as the serving cert but with cacert appended: https://istio.io/latest/docs/reference/config/networking/gateway/#ServerTLSSettings

credentialName:

For gateways running on Kubernetes, the name of the secret that holds the TLS certs including the CA certificates. Applicable only on Kubernetes. The secret (of type generic) should contain the following keys and values: key: privateKey and cert: serverCert. For mutual TLS, cacert: CACertificate can be provided in the same secret or a separate secret named secret-cacert. Secret of type tls for server certificates along with ca.crt key for CA certificates is also supported. Only one of server certificates and CA certificate or credentialName can be specified. I do not prefer the convention based approach in general and suggest using a more explicit reference.

Describe alternatives you've considered

Manual steps of forming a new secret by joining a cert managed by cert-manager with a ca cert. Even if automated this seems like an error prone and difficult to discover way of doing things. We have thousands of hosts with different client CAs that change frequently.

Additional Context

No response

github-actions[bot] commented 3 months ago

This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.