fix: Add tls-server-name support for Teleport proxy compatibility

[arikalon1]

Summary

Fixes #495

This PR adds support for the tls-server-name field in kubeconfig cluster configurations, enabling KRR to work with Teleport Kubernetes proxy and similar setups where the TLS SNI (Server Name Indication) must differ from the server hostname.

Problem

When using Teleport as a Kubernetes proxy, the kubeconfig contains:

clusters:
- cluster:
    certificate-authority-data: <CA>
    server: https://company.teleport.sh:443
    tls-server-name: kube-teleport-proxy-alpn.company.teleport.sh

KRR was failing with SSL certificate verification errors because it wasn't respecting the tls-server-name field. The CA certificate is valid for the SNI name, not the server hostname.

Solution

Extended the existing config_patch.py pattern (already used for proxy-url) to also handle tls-server-name:

1. Read tls-server-name from the cluster config in _load_cluster_info()
2. Pass it to the Configuration object via _set_config()
3. Add tls_server_name attribute to the Configuration class

This follows the exact same approach already proven to work for the proxy-url field.

Testing

• Tested with Teleport Kubernetes proxy setup
• Existing functionality with standard kubeconfig still works

cc @prein - Would you be able to test this fix with your Teleport setup?

[coderabbitai]

Walkthrough

Adds TLS Server Name (SNI) support to Kubernetes configuration handling by reading the tls-server-name field from kubeconfig and propagating it through the configuration pipeline. This enables proper certificate verification when connecting through proxy services that require SNI to differ from the actual server hostname.

Changes

Cohort / File(s)	Summary
TLS SNI Configuration Support robusta_krr/core/integrations/kubernetes/config_patch.py	Added tls-server-name reading in _load_cluster_info() to extract SNI override from cluster configuration. Extended property propagation loop in _set_config() to handle both proxy and tls_server_name. Updated Configuration class constructor to accept and store optional tls_server_name parameter.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding tls-server-name support for Teleport proxy compatibility, which is the primary objective of this PR.
Description check	✅ Passed	The description is directly related to the changeset, explaining the problem, solution, and implementation approach for supporting tls-server-name in kubeconfig.
Linked Issues check	✅ Passed	The PR directly addresses issue #495 by implementing tls-server-name support in config_patch.py, following the proposed approach of explicit handling similar to proxy-url.
Out of Scope Changes check	✅ Passed	All changes are focused on adding tls-server-name support to the Configuration class and KubeConfigLoader, directly aligned with the issue requirements.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/tls-server-name-support-495

---

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3acc116 and 18f2cae.

📒 Files selected for processing (1)

• robusta_krr/core/integrations/kubernetes/config_patch.py

🔇 Additional comments (3)

robusta_krr/core/integrations/kubernetes/config_patch.py (3)

19-22: LGTM!

The tls-server-name handling follows the established pattern for proxy-url. Clear comment explains the intent.

---

32-42: Clean extension of Configuration class.

The addition of tls_server_name follows the established pattern for proxy. The implementation correctly stores the value on the configuration object.

However, for this to actually affect TLS SNI behavior, the kubernetes client's REST client (urllib3) must read this attribute when establishing SSL connections. If v26.1.0 doesn't natively support this, you may need additional patching of the API client's SSL context setup.

Please confirm this works end-to-end with a Teleport proxy setup as mentioned in the testing notes. If TLS SNI isn't being set correctly, additional patches to the REST client may be required.

---

24-29: Remove incorrect claim about type annotation removal.

The client_configuration parameter has never had a type annotation—this file was created with the current implementation. The loop refactor for proxy and tls_server_name is clean and follows the same pattern referenced in the kubernetes-client PR #1863 (noted in the comment at line 2). No changes needed.

Likely an incorrect or invalid review comment.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}