-
Notifications
You must be signed in to change notification settings - Fork 467
enabled support for NGINX TLS Passthrough #3824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Welcome @vijayant7! |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vijayant7 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Thanks for this. There's a related PR here by @shahvrushali22 Wanted to give you a heads up. I haven't looked too closely at your PR yet, just thought I'd show you in case there is some overlap. |
Sure. Thanks. Yes the ask does seem similar. Waiting for the review @illume :) |
|
The backend test build failed but seems an issue with the GoLint env setup. Not the code itself ? |
The GoLint check is failing
|
Ive put the change that fixes this. Please re-run the workflow. |
|
@illume needed to re run the backend linting check workflow. Also can i run these workflows each time commit and push to repo to check if all is good with the commit or not ? |
|
@vijayant7 until the first PR is merged we have to run the GitHub checks manually. You can run Also we follow linux kernel style commit messages, see https://headlamp.dev/docs/latest/contributing/#2-follow-commit-guidelines |
thanks. This is very helpful. Its my first time contributing hence did now know. |
… and rename robustness\n\n- Replace ListenAndServe* with http.Server using Read/Write/Idle timeouts to address gosec G114\n- Fix gofumpt/wsl cuddled-assignment and formatting issues in cmd and tests\n- Add comment documenting why timeouts are set\n- Make renameContextInStore robust by searching contexts when direct lookup fails\n- Minor test cleanup and formatting
@illume please run the checks. My local golint check has passed. committed with updates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enables TLS termination at the Headlamp backend server, allowing users to serve HTTPS directly from the container instead of relying on ingress TLS termination.
- Adds optional TLS support with environment variables for enabling TLS and specifying certificate/key files
- Updates server startup logic to use
ListenAndServeTLSwhen TLS is enabled - Includes comprehensive documentation and sample Kubernetes manifest for TLS configuration
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| kubernetes-headlamp-tls-sample.yaml | Sample Kubernetes deployment showing TLS configuration with secret mounting |
| docs/development/tls.md | Documentation explaining TLS backend feature usage and configuration |
| backend/pkg/headlampconfig/headlampConfig.go | Adds TLS configuration fields to HeadlampCFG struct |
| backend/cmd/headlamp_test.go | Unit tests for TLS configuration from environment variables |
| backend/cmd/headlamp.go | Main implementation of TLS support and server refactoring |
| README.md | Updates main documentation to highlight new TLS backend feature |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
Thanks a lot @vijayant7 Please bear with us, we have quite a backlog of PRs and issues we're getting through. |
Thanks so much i completely get it. . Let me know if anything is needed from my side. The copilot review is closed as i see. |
|
hi @illume i did some local tests. Attaching the functional test I performed . This shows the code performs as intended with a NGINX TLS Passthrough and Transport Server Setup |
|
@illume @ashu8912 @yolossn @joaquimrocha if you may please help trigger the workflow so checks can pass. These had passed but the PR was rebased so they need to run again. Also if you may review and let me know next steps this itll help as we are restricted not to use Headlamp until this feature is implemented. Ive added my internal test report hereThanks ! |
|
@yolossn what do you think? |
| // initTLSConfigFromEnv initializes HeadlampConfig with TLS options from environment variables. | ||
| func initTLSConfigFromEnv(config *HeadlampConfig) { | ||
| // HEADLAMP_ENABLE_TLS: "true" to enable TLS | ||
| if os.Getenv("HEADLAMP_ENABLE_TLS") == strTrue { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This be done in the command line config parsing like the rest of the configuration.
|
@yolossn I think this... I'll finish off a few things from the earlier PR: @vijayant7 Then take some bits from this PR. I'll add you as a co author. |
Sounds good, the other PR has the config and helm handled properly. |
|
@illume any idea when this feature will be rolled out in release via your other PR. Our implementation is dependent on this feature. Also I have amended the documentation as suggested by you in the comment. Thanks! |
|
Closing in favour of this one (which includes elements of this PR): |



Summary
Add Optional TLS Termination at Headlamp Backend
What this PR does
Adds support for terminating TLS directly at the Headlamp backend server.
Introduces new environment variables:
HEADLAMP_ENABLE_TLS (set to true to enable)
HEADLAMP_TLS_CERT_FILE (path to TLS certificate)
HEADLAMP_TLS_KEY_FILE (path to TLS private key)
If enabled, Headlamp will serve HTTPS using the provided cert/key. If not set, default behavior (TLS at ingress) is unchanged.
Updates documentation and README to describe the new feature and usage.
Adds a sample Kubernetes manifest snippet for enabling backend TLS.
Why
Allows users to use NGINX TLS passthrough or similar setups, where TLS is terminated at the Headlamp container, not at the ingress.
Increases deployment flexibility and security options.
How to use
See tls.md for full instructions and examples.
Related Issue
Fixes #3823
Changes
Added support for optional TLS termination at the Headlamp backend.
Introduced new config fields: EnableTLS, TLSCertFile, and TLSKeyFile in the backend config.
Added environment variable support:
HEADLAMP_ENABLE_TLS
HEADLAMP_TLS_CERT_FILE
HEADLAMP_TLS_KEY_FILE
Updated backend startup logic to use http.ListenAndServeTLS when TLS is enabled and cert/key are provided.
Added documentation for the new feature in tls.md, including usage and Kubernetes manifest example.
Updated the main README.md to reference the new TLS backend feature.
No breaking changes: if TLS is not enabled, Headlamp continues to expect TLS termination at the ingress as before.
Steps to Test
Build and deploy Headlamp with your changes.
Create a Kubernetes TLS secret (or use your own cert/key):
kubectl create secret tls headlamp-tls --cert=path/to/tls.crt --key=path/to/tls.key -n kube-system
Update your Headlamp deployment:
Add these environment variables to the container:
value: "true"
value: "/certs/tls.crt"
value: "/certs/tls.key"
Mount the secret as a volume:
volumeMounts:
mountPath: /certs
volumes:
secret:
secretName: headlamp-tls
Expose the Headlamp service on the HTTPS port (e.g., 4466).
Access Headlamp directly via HTTPS:
Open a browser and go to https://:4466
You should see a valid TLS connection (browser lock icon
Test with NGINX ingress in TLS passthrough mode (optional):
Configure NGINX to use TLS passthrough to the Headlamp service.
Ensure TLS is terminated at the Headlamp container, not at the ingress.
Test fallback:
Remove the TLS environment variables and restart Headlamp.
Confirm it serves HTTP as before.
Notes for the Reviewer
This PR is fully backward compatible. If the new TLS environment variables are not set, Headlamp will continue to expect TLS termination at the ingress as before.
Please review the new documentation in tls.md for usage and deployment details.
If you have a test cluster, you can follow the steps in the PR description to verify both HTTP and HTTPS modes.
Feedback on config naming, documentation clarity, or additional test scenarios is welcome!