Skip to content
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

feat: Set vars when TLS disabled or Dev enabled #2008

Closed
wants to merge 1 commit into from

Conversation

Callisto13
Copy link
Contributor

This is so that the UI can query what has been set on the server and
display appropriate warning messages.

It will also be logged on each request whether TLS is enabled or not.

Part of #1959

This is so that the UI can query what has been set on the server and
display appropriate warning messages.

It will also be logged on each request whether TLS is enabled or not.
@Callisto13 Callisto13 added type/enhancement New feature or request team/mauvelous area/ui Issues that require front-end work and removed area/ui Issues that require front-end work labels Apr 26, 2022
@@ -286,7 +287,10 @@ func runCmd(cmd *cobra.Command, args []string) error {

func listenAndServe(log logr.Logger, srv *http.Server, options Options) error {
if options.Insecure {
log.Info("TLS connections disabled")
log.Info(
"WARNING: TLS connections disabled by the `--insecure` flag. All data INCLUDING AUTH TOKENS will be transmitted without encryption.")
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure this makes sense - we expect --insecure to pretty much always be set for security reasons: you'll have a separate ingress to encrypt the data, so you don't need to worry about how to configure allowed ciphers, special-case certificate renewal, and so on. That doesn't mean anything will be transmitted without encryption.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh i didn't realised we did that now. In that case, why do we offer TLS at all?

Copy link
Contributor

Choose a reason for hiding this comment

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

🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

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

looool excellent

i might be closing this one then

Copy link
Contributor

Choose a reason for hiding this comment

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

That other ingress is on the user to configure though right? And I assume we'd have no way of knowing whether they have appropriately configured? In which case a warning still feels valid but perhaps the wording changes to more of a "ensure you have an appropriately configured ingress..."

Copy link
Contributor

Choose a reason for hiding this comment

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

additionally, if we do indeed expect --insecure to be the default in a secure configuration... maybe we need to think about renaming :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Opened #2010 to discuss what we really want to do around this

@Callisto13
Copy link
Contributor Author

closing for now, may open again later

@Callisto13 Callisto13 closed this Apr 26, 2022
@makkes makkes deleted the insecure-warning branch December 9, 2022 09:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants