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

watch: use CONSUL_TLS_SERVER_NAME for https if defined (#4718) #4727

Merged
merged 3 commits into from
Oct 8, 2018

Conversation

igal-s
Copy link
Contributor

@igal-s igal-s commented Sep 30, 2018

I'm not sure that this is the best way of passing the configuration but it does resolve my issue

Copy link
Member

@mkeeler mkeeler left a comment

Choose a reason for hiding this comment

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

@igal-s Thanks for the PR. As my other comment suggested I think there may be an even simpler solution here.

Within the APIConfig function if we do not set the TLSConfig.Address at all then when it eventually gets passed to api.NewClient in the RunWithConfig function of the watch plan it should use the env var. I think overriding the addr within the reloadWatches function will only work so long as the TLS server name can be resolved to the address consul is serving the HTTP api on. So to account for the other cases where the server name only resolves to a public IP and the HTTP is listening only on other private/local IPs we need to make sure that the addr passed to the watch plan is an actual IP address and not a hostname.

Could you test out that theory

@@ -1475,7 +1476,7 @@ func (c *RuntimeConfig) APIConfig(includeClientCerts bool) (*api.Config, error)
cfg.Scheme = "https"
cfg.TLSConfig.CAFile = c.CAFile
cfg.TLSConfig.CAPath = c.CAPath
cfg.TLSConfig.Address = httpsAddr
cfg.TLSConfig.Address = dcfg.TLSConfig.Address
Copy link
Member

Choose a reason for hiding this comment

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

I think this whole PR may be able to be replaced by just removing this line.

@igal-s
Copy link
Contributor Author

igal-s commented Oct 6, 2018

@mkeeler you are right, I've tested it and not setting the TLSConfig.Address in the APIConfig function resolves the issue as well.
Thank you!

@hanshasselberg hanshasselberg merged commit e1fe3af into hashicorp:master Oct 8, 2018
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.

3 participants