-
Notifications
You must be signed in to change notification settings - Fork 453
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
[xserver] TLS support added to xserver, aggregator server, and aggregator client #4266
base: master
Are you sure you want to change the base?
[xserver] TLS support added to xserver, aggregator server, and aggregator client #4266
Conversation
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.
lgtm but pls get another stamp from @andrewmains12 or @justinjc
src/x/server/tls_mode.go
Outdated
// TLSMode represents the TLS mode | ||
type TLSMode uint16 | ||
|
||
func (t *TLSMode) UnmarshalText(mode []byte) error { |
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.
nit: in statsdex we use enumer to deal with this boilerplate, check any generate.go
file, i think this will also allow you to use it directly in config structures instead of a string with regexes
src/aggregator/client/conn.go
Outdated
func (c *connection) upgradeToTLS(conn net.Conn) (net.Conn, error) { | ||
certPool := x509.NewCertPool() | ||
if c.tls.CAFile() != "" { | ||
certs, err := os.ReadFile(c.tls.CAFile()) |
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.
Should we be caching the cert file? We recreate connections with some amount of frequency.
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.
Or maybe more appropriately, it just goes in the pool.
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.
I have added a TTL config cache on the connection level. It will be helpful for reconnecting but not for establishing new connections. The client has fewer connections than the server, so I believe it will be a neglectable overhead.
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.
Sure, fair enough. Just for my understanding though--why not use the same cache for connecting as well?
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.
That's because the write manager is responsible for creating connections(it can be considered as a connection pool). Theoretically, it can contain TLS options and use its TLS config cache to establish a connection. However, it knows nothing about connection parameters, and I don't want it to have that information because it doesn't seem to be something that should be responsible for secure connections. Also, even if it would manage the TLS configuration, a connection should do certificate rotation on its own in case of reconnection.
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.
Do we have an end to end integration test of this? I'd like to see aggregator client with TLS enabled talking to aggregator server with TLS enabled.
|
// Before reading we need to ensure if we know the type of the connection. | ||
// After reading data it will be impossible to determine | ||
// if the connection has the TLS layer or not. | ||
if s.isTLS == nil { |
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.
Fyi: if this were multithreaded, this would be a racy read (not protected by your lock).
… in buildkite pipeline (m3db#4284) * uncomment test * comment out TestGraphiteFindSequential * do not skip TestGraphiteFindParallel * skip TestGraphiteFindSequential * uncomment dbnode read test
…#4282) * uncomment last test * uncomment second command * add common step * add another command * switch order of commands * fix typo * test1 * uncomment rest of passing pipeline tests
What this PR does / why we need it:
TLS support was added to xserver and aggregator client.
The server supports 3 modes: disabled(allows plaintext connections only), permissive(allows both plaintext and TLS connections), and enforced(TLS connections only). Also, mutual TLS can be enabled in the server config.
Special notes for your reviewer:
Does this PR introduce a user-facing and/or backwards incompatible change?:
Does this PR require updating code package or user-facing documentation?: