-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
x-pack/filebeat/input/http_endpoint: allow http_endpoint instances to share ports #33377
Conversation
7d0ebe5
to
595baa8
Compare
_ = servers.serve(ctx, cfg, &pub) // Always returns a non-nil error. | ||
}() | ||
} | ||
time.Sleep(time.Second) |
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'm not particularly proud of this, but I don't see another way to ensure that we have the servers up without doing nasty things inside pool.serve
.
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
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 had some questions relating to handling of conflicting listener config between input instances.
Once we are settled on the behavior, the documentation for http_endpoint should be updated to describe this feature.
p.servers[e.addr] = s | ||
p.mu.Unlock() | ||
|
||
if e.tlsConfig != 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.
For the case where one input instance is running with TLS and another is not, I think we should detect and prevent this.
On a similar note, should we prevent two inputs that are configured with different/inconsistent TLS options too?
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 will add this check, and yes, I think inconsistent configs should be disallowed.
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.
Hang on. This may not be the right thing to do; we already prevent two bindings of a pattern to an address (IP:port) so it is not possible to get into the situation where we have a conflicting TLS config. The next level of binding, where we are looking at an address as IP-only doesn't really make sense to check this for since there may be cases where one port expects TLS and another doesn't — I would imagine that this is rare, but the case where they have different TLS configurations would be less so.
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.
Here's an example config that demonstrates the problem I am thinking of.
---
filebeat.inputs:
- type: http_endpoint
id: http_endpoint-no-ssl
listen_address: 127.0.0.1
listen_port: 9001
url: '/webhook-alpha/'
preserve_original_event: true
# This one will start listening without TLS, but I would expect an error
# since we cannot have both an HTTP and HTTPS listener on 127.0.0.1:9001.
- type: http_endpoint
id: http_endpoint-with-ssl
listen_address: 127.0.0.1
listen_port: 9001
url: '/webhook-beta/'
preserve_original_event: true
ssl:
verification_mode: none
certificate: |
-----BEGIN CERTIFICATE-----
MIIBzjCCATGgAwIBAgIBATAKBggqhkjOPQQDBDASMRAwDgYDVQQKEwdBY21lIENv
MB4XDTIyMTAyNTEyNDQ0OFoXDTIzMDQyMzEyNDQ0OFowEjEQMA4GA1UEChMHQWNt
ZSBDbzCBmzAQBgcqhkjOPQIBBgUrgQQAIwOBhgAEANdwExxtIgYhw8kN485JxdAX
Y/XzbXA5w1G1ubO3sOpXIcQnuOZC/ea0xnbq9JLOxs9u1glr/K9awsXGlg5JQ3K6
Aa6dBg5IQIGc6UBbetCaOx3QQkrrKJFrlF+6oiwn3Cs+V/qZMwsNgDdEeq2gFINj
3ede5TUE+jmsqy+qcNTZ9ik6ozUwMzAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAww
CgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDBAOBigAwgYYCQQH2
bwUzZWpwyvXoBGwWfGeKcmNSRFK+5Ur9k2C+PW+C+tVw0oqJvuEcJys78cB9TVwM
OLBBY4Lip6CDGZ9Zu8MvAkETMcxFC2g3YIiHMFztfkMmU5XnVjjwjelmxNxREKUB
pyD8tx7ptfI6hI8EUrqD1mQwnLLFU7Rq7IAbNuFXksYeWw==
-----END CERTIFICATE-----
# Not a secret.
key: |
-----BEGIN EC PRIVATE KEY-----
MIHcAgEBBEIBtHeKAVWSypQo+PUDhUSMmh41Es6uCd+0OQhr3K9S3ntq7OjuMces
CN2dG3WJBDo3TEfVJOhrNKE31zoM7+PE+kygBwYFK4EEACOhgYkDgYYABADXcBMc
bSIGIcPJDePOScXQF2P1821wOcNRtbmzt7DqVyHEJ7jmQv3mtMZ26vSSzsbPbtYJ
a/yvWsLFxpYOSUNyugGunQYOSECBnOlAW3rQmjsd0EJK6yiRa5RfuqIsJ9wrPlf6
mTMLDYA3RHqtoBSDY93nXuU1BPo5rKsvqnDU2fYpOg==
-----END EC PRIVATE KEY-----
output.console.enable: true
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.
Done
9f8c5a5
to
4b0c496
Compare
This pull request is now in conflicts. Could you fix it? 🙏
|
4b0c496
to
3b86c3e
Compare
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.
Can you please add a description of the new feature to the http_endpoint asciidocs.
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
… share ports (#33377) This makes it possible for a single address/port to be configured with multiple endpoints. Prior to this change different endpoint would require exposing unique ports for each, increasing configuration complexity and attack surface.
What does this PR do?
This change adds a pool of http servers that share listening addresses and ports but respond to different mux endpoints.
Why is it important?
This reduces configuration complexity and port exposure in filebeat agents.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
The tests can be run using the
go test
command inx-pack/filebeat/input/http_endpoint
.Related issues
Use cases
Screenshots
Logs