Skip to content

feat(auth-proxy): add custom CA and mTLS support#655

Open
Saad Farooq (saad-supports-langchain) wants to merge 1 commit intomainfrom
saad/feat-auth-proxy-custom-ca-mtls
Open

feat(auth-proxy): add custom CA and mTLS support#655
Saad Farooq (saad-supports-langchain) wants to merge 1 commit intomainfrom
saad/feat-auth-proxy-custom-ca-mtls

Conversation

@saad-supports-langchain
Copy link
Copy Markdown

Summary

  • Add customCa for upstream TLS verification with private/internal CAs (Envoy uses BoringSSL and does not trust the system CA store)
  • Add mtls for client certificate presentation when upstream requires mutual TLS
  • mTLS requires customCa — chart fails validation without it, preventing an insecure deployment where Envoy sends client certs without verifying the server's identity
  • Rollout checksums on pod annotations for automatic restart on cert/CA changes
  • validate.yaml with all-or-nothing field checks and cross-feature dependency enforcement
  • 19 new unit tests across 4 test files (69 total passing)
  • README documentation for both features with secret examples and rotation workflows

Test plan

  • helm unittest . — 69 tests passing
  • Deploy with customCa only and verify upstream TLS verification
  • Deploy with customCa + mtls and verify mutual TLS handshake
  • Verify helm template fails when mtls is set without customCa
  • Verify helm template fails on partial customCa or mtls config

🤖 Generated with Claude Code

Add customCa for upstream TLS verification with private/internal CAs
and mtls for client certificate presentation to upstream services.

mTLS requires customCa — the chart fails validation without it because
Envoy would send client certificates without verifying the server's
identity, which is not mutual authentication.

- Helm helpers for secret mounting, rollout hashing, and Envoy TLS context
- validate.yaml with all-or-nothing field checks and mtls-requires-customCa
- Rollout checksums for automatic pod restart on cert changes
- 19 new unit tests across 4 test files
- README documentation for both features with examples

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use `customCa.secretName` and `customCa.secretKey` to mount a CA bundle that Envoy should trust for outbound HTTPS connections.

This bundle is applied to every HTTPS peer Envoy validates in this chart:
- The main upstream cluster defined by `authProxy.upstream`
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is upstream always https?


- Provide the full CA bundle Envoy should trust, not just a single private root. If your upstream or JWKS endpoint chains to public roots as well, include those certificates in the bundle.
- `customCa.secretName` and `customCa.secretKey` must either both be set or both be left empty.
- Envoy reads the CA bundle from a mounted Secret volume. To make trust changes deterministic, roll the pod when the bundle changes.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't pod rolling automatic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants