-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Actions] email action fails due to enabled HTTP proxy in kibana #92949
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Could you try execution the connector from it's "Test" tab? You may see more diagnostic information. Also curious about your email settings - server, port, secure setting Also, I'd have to look up the exact details on use of the proxy for email, but I believe your proxy will have to support connecting to an SMTP server via CONNECT, and it's not clear to me that every proxy will do this. Lastly, there is a bug in Kibana < 7.11 where if the proxy protocol and target protocol are not the same (http/https), then the connection will not succeed as we try to connect to the target with the proxy's protocol. In this case, with an |
Another thing I'm wondering is if the intention is to NOT use the http proxy with the email connector. I was frankly a little surprised that the If so, we'll need some separate setting for the email connector to ignore/respect the proxy setting. |
Removing the |
hi, thank you for your reply. I reproduced the issue and got the same error last night. please check the log. kibana log
slack Slack a message by curl with proxy config is ok on the kibana server and got an error on the kibana connector test. slack error message:
|
There's a bug in versions of Kibana < 7.11 where if the proxy protocol and target protocol don't match, the resulting HTTP request is unlikely to work, because the call will be made with the protocol of the proxy and not the target. That would happen in your case above with Slack, if That bug is fixed in 7.11.0. |
The original question concerned the email action and proxy. Is the customer's proxy set up to handle SMTP connections? Not clear to me that every http/s proxy can handle those, and we're wondering if we need to support a mode where:
In that case, I don't think the email action will work, so we'll need to do >something< ... more config, or change the email action to allow ignoring the proxy setting, etc. |
We have the same Issue when we set the proxy. Maybe having more granular Configuration Options or the possibility to define the Proxy per Connector would fix this problem. |
@simioa I just added a comment to our issue on per-connector network customizations here - #80120 (comment) Feel free to add more detail / let me know if something I wrote isn't correct. |
For the per-connector network customizations, it feels like the proxy info is not a good fit here, and doesn't align with our current kibana config dealing with proxies: Given all that, I think we should add two new configs:
The config keys are mutually exclusive - only one can be set. My first thought on cloud support is that we likely won't need it, because it doesn't seem like a cloud-deployed Kibana could connect to a customer-provided proxy. But with the newish private networking support, seems possible, or perhaps possible in the near future, so ... I think it should be cloud enabled. |
resolves elastic#92949 This PR adds two new Kibana config keys to further customize when the proxy is used when making HTTP requests. Prior to this PR, if a proxy was set via the `xpack.actions.proxyUrl` config key, all requests would be proxied. Now, there's a further refinement in that hostnames can be added to the `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` config keys. Only one of these config keys can be used at a time. If the target URL hostname of the HTTP request is listed in the `proxyBypassHosts` list, the proxy won't be used. If the target URL hostname of the HTTP request is **NOT** listed in the `proxyOnlyHosts` list, the proxy won't be used. Depending on the customer's environment, it may be easier to list the hosts to bypass, or easier to list the hosts that should only be proxied, so they can choose either method.
…#95365) resolves #92949 This PR adds two new Kibana config keys to further customize when the proxy is used when making HTTP requests. Prior to this PR, if a proxy was set via the `xpack.actions.proxyUrl` config key, all requests would be proxied. Now, there's a further refinement in that hostnames can be added to the `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` config keys. Only one of these config keys can be used at a time. If the target URL hostname of the HTTP request is listed in the `proxyBypassHosts` list, the proxy won't be used. If the target URL hostname of the HTTP request is **NOT** listed in the `proxyOnlyHosts` list, the proxy won't be used. Depending on the customer's environment, it may be easier to list the hosts to bypass, or easier to list the hosts that should only be proxied, so they can choose either method.
…elastic#95365) resolves elastic#92949 This PR adds two new Kibana config keys to further customize when the proxy is used when making HTTP requests. Prior to this PR, if a proxy was set via the `xpack.actions.proxyUrl` config key, all requests would be proxied. Now, there's a further refinement in that hostnames can be added to the `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` config keys. Only one of these config keys can be used at a time. If the target URL hostname of the HTTP request is listed in the `proxyBypassHosts` list, the proxy won't be used. If the target URL hostname of the HTTP request is **NOT** listed in the `proxyOnlyHosts` list, the proxy won't be used. Depending on the customer's environment, it may be easier to list the hosts to bypass, or easier to list the hosts that should only be proxied, so they can choose either method.
…#95365) (#96491) resolves #92949 This PR adds two new Kibana config keys to further customize when the proxy is used when making HTTP requests. Prior to this PR, if a proxy was set via the `xpack.actions.proxyUrl` config key, all requests would be proxied. Now, there's a further refinement in that hostnames can be added to the `xpack.actions.proxyBypassHosts` and `xpack.actions.proxyOnlyHosts` config keys. Only one of these config keys can be used at a time. If the target URL hostname of the HTTP request is listed in the `proxyBypassHosts` list, the proxy won't be used. If the target URL hostname of the HTTP request is **NOT** listed in the `proxyOnlyHosts` list, the proxy won't be used. Depending on the customer's environment, it may be easier to list the hosts to bypass, or easier to list the hosts that should only be proxied, so they can choose either method.
Kibana version:
7.10.2
Elasticsearch version:
7.10.2
Server OS version:
Redhat Linux 7.9
Browser version:
Chrome 88.0.4324.190
Browser OS version:
Windows 10
Original install method (e.g. download page, yum, from source, etc.):
yum
Describe the bug:
Alerting mail action goes failed due to enabled HTTP proxy in kibana
Steps to reproduce:
Expected behavior:
both mail and webhook (with proxy config )alert action works
Screenshots (if relevant):
Errors in browser console (if relevant):
Provide logs and/or server output (if relevant):
kibana config:
Any additional context:
The text was updated successfully, but these errors were encountered: