-
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] adds config allowing per-host networking options #96630
Conversation
5e68b33
to
a74afd4
Compare
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
This PR is not quite done, but I think ready for review, especially considering 7.13 feature freeze is next week - hopefully we can squeeze this in. todo's:
Note on the function tests - I've actually added some jest tests that do "kind of" end-to-end testing with various configs, using actual config properties, real https servers and our axios client. I'm surprised this ended up working out so well! I'm going to open an issue to add some similar sorts of tests for proxy and mail (using |
@gchaps will need a review of the docs here (link at the top), and advice on how to avoid the super narrow right-hand column starting 1/3 of the way down, after the example block, due to the excessive length of the config keys |
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.
kibana-docker LGTM
resolves: elastic#80120 Adds a new Kibana configuration key xpack.actions.customHostSettings which allows per-host configuration of connection settings for https and smtp for alerting actions. Initially this is just for TLS settings, expandable to other settings in the future. The purpose of these is to allow customers to provide server certificates for servers accessed by actions, whose certificate authority is not available publicly. Alternatively, a per-server rejectUnauthorized: false configuration may be used to bypass the verification step for specific servers, but require it for other servers that do not have per-host customization. Support was also added to allow per-host customization of ignoreTLS and requireTLS flags for use with the email action.
a74afd4
to
c2bb7d6
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.
This looks awesome! Doesn't have to be done as part of this PR, but I think it would be really helpful to expand the docs section with more examples of how this config can be used in conjunction with various example connector configs. Maybe a troubleshooting section for connector configs that give examples for how to update the config in response to the most commonly seen error messages when executing actions?
Ya, an extended example would be good here, especially since the cloud version will require inlining the ca PEM data - it's actually not that bad in YAML, but an example will clarify the exact syntax for customers. |
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
@elasticmachine merge upstream |
@legrego @jportner woops - should have given you a heads up on this last week. This PR is the "config-only" version of the per-host TLS configuration options, that I had you review previously in PR #94807 I did originally intend to use I just opened issue #97635 to track this. |
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.
Made a quick pass, mostly LGTM but see a few nits/suggestions in my comments below!
@legrego @jportner woops - should have given you a heads up on this last week. This PR is the "config-only" version of the per-host TLS configuration options, that I had you review previously in PR #94807
I did originally intend to use
verificationMode
instead ofrejectUnauthorized
, per comment in the previous PR - but we were already usingrejectUnauthorized
in two other config keys, so it seemed more appropriate to leave it that way, rather than to reshape that as the same shape asverificationMode
.
Makes sense, thanks for following up 👍
Note: this just means that users won't be able to use rejectUnauthorized: true
with hostname verification disabled (that is what verificationMode: certificate
does). We don't want to encourage disabling hostname verification anyway, so that's fine by me.
values. | ||
|
||
| `xpack.actions.customHostSettings[n].smtp.ignoreTLS` {ess-icon} | ||
| A boolean value indicatting that TLS must not be used for this connection. |
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
| A boolean value indicatting that TLS must not be used for this connection. | |
| A boolean value indicating that TLS must not be used for this connection. |
| A boolean value indicatting that TLS must not be used for this connection. | ||
|
||
| `xpack.actions.customHostSettings[n].smtp.requireTLS` {ess-icon} | ||
| A boolean value indicatting that TLS must be used for this connection. |
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
| A boolean value indicatting that TLS must be used for this connection. | |
| A boolean value indicating that TLS must be used for this connection. |
| `xpack.actions.customHostSettings[n].tls.certificateAuthoritiesFiles` {ess-icon} | ||
| A file name or list of file names of PEM-encoded certificate files which | ||
should be used to validate the server. |
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.
Note: this (and a few other cells) make the left column width stretch so much that the docs are difficult to read:
I see above for xpack.encryptedSavedObjects .encryptionKey
the workaround was to insert a space to cause the line break, but that means a user can't copy/paste the config property into their YML file without encountering a parsing error.
I ran into the same situation in #97158, I'll paste a relevant snippet of the PR description below:
the asciidoc hacks that I needed to make for the settings table in bb8e2aa are kind of awful, but it seems to be the only solution that will work. The key names for the new config options are too long, and they stretch the left column of the table out to the maximum size as a result. Regular columns in AsciiDoc will not preserve leading whitespace characters, so I had to utilize an AsciiDoc block element column style with the
a
operator.
So, for the short term, you could potentially change this to make it a bit more readable:
| `xpack.actions.customHostSettings[n].tls.certificateAuthoritiesFiles` {ess-icon} | |
| A file name or list of file names of PEM-encoded certificate files which | |
should be used to validate the server. | |
a| | |
---- | |
xpack.actions.customHostSettings: | |
- tls.certificateAuthoritiesFiles: {ess-icon} | |
---- | |
| A file name or list of file names of PEM-encoded certificate files which | |
should be used to validate the server. |
Kaarina suggested a better long term solution would be to change the layout to use a definition list instead of a table: #97158 (comment)
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.
Problem with this "style", is that I can't actually use the {ess-icon}
here. It shows up literally :-)
I ended up doing it the same as the "broken" xpack.encryptedSavedObjects .encryptionKey
style already in use here, but I think this is ok since it's unlikely customers would use the "single key/value" approach to setting these values; I'd guess they will use a complete "object" like the example provided in the doc.
// see: src/core/server/elasticsearch/legacy/elasticsearch_client_config.ts | ||
if (tlsSettings.rejectUnauthorized !== undefined) { | ||
agentOptions.rejectUnauthorized = tlsSettings.rejectUnauthorized; | ||
} |
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: you mentioned it in the asciidocs, but it's not abundantly clear here that this will inherit from xpack.actions.rejectUnauthorized
(which defaults to true
)
I would suggest just adding a comment:
// see: src/core/server/elasticsearch/legacy/elasticsearch_client_config.ts | |
if (tlsSettings.rejectUnauthorized !== undefined) { | |
agentOptions.rejectUnauthorized = tlsSettings.rejectUnauthorized; | |
} | |
// Note: if custom TLS settings are defined but rejectUnauthorized is not set, fall back to the config for `xpack.actions.rejectUnauthorized` (default: true) | |
// See also: src/core/server/elasticsearch/legacy/elasticsearch_client_config.ts | |
if (tlsSettings.rejectUnauthorized !== undefined) { | |
agentOptions.rejectUnauthorized = tlsSettings.rejectUnauthorized; | |
} |
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.
Added a number of comments in this file to hopefully clarify things.
|
||
expect(httpsAgent?.options.ca).toBe('ca data here'); | ||
expect(httpsAgent?.options.rejectUnauthorized).toBe(false); | ||
}); | ||
}); |
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.
Follow-on from #96630 (comment):
It would be good to see unit test cases for the different permutations of xpack.actions.rejectUnauthorized
and xpack.actions.customHostSettings[n].tls.rejectUnauthorized
.
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.
Added additional test cases.
if (tlsSettings?.rejectUnauthorized !== undefined) { | ||
tlsConfig.rejectUnauthorized = tlsSettings?.rejectUnauthorized; | ||
} |
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: same as #96630 (comment)
}, | ||
] | ||
`); | ||
}); | ||
}); |
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.
Same as #96630 (comment)
I think when I looked at some security code, it wasn't actually doing anything with the hostname verification bit - it appeared that perhaps node didn't support that at all, or easily. Or perhaps it ended up getting set up before hand. I think we probably need to look at changing |
@@ -48,6 +48,67 @@ You can configure the following settings in the `kibana.yml` file. | |||
+ | |||
Note that hosts associated with built-in actions, such as Slack and PagerDuty, are not automatically added to allowed hosts. If you are not using the default `[*]` setting, you must ensure that the corresponding endpoints are added to the allowed hosts as well. | |||
|
|||
| `xpack.actions.customHostSettings` {ess-icon} | |||
| A list of custom host settings to override existing global settings. It | |||
defaults to an empty list. In the example below, a custom host setting for a |
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.
defaults to an empty list. In the example below, a custom host setting for a | |
defaults to an empty list. In the following example, a custom host setting for a |
@@ -48,6 +48,67 @@ You can configure the following settings in the `kibana.yml` file. | |||
+ | |||
Note that hosts associated with built-in actions, such as Slack and PagerDuty, are not automatically added to allowed hosts. If you are not using the default `[*]` setting, you must ensure that the corresponding endpoints are added to the allowed hosts as well. | |||
|
|||
| `xpack.actions.customHostSettings` {ess-icon} | |||
| A list of custom host settings to override existing global settings. It | |||
defaults to an empty list. In the example below, a custom host setting for a |
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.
defaults to an empty list. In the example below, a custom host setting for a | |
Defaults to an empty list. In the example below, a custom host setting for a |
[cols="2*<"] | ||
|=== | ||
|
||
| `xpack.actions.customHostSettings[n].url` {ess-icon} |
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.
Try breaking this in two lines:
|xpack.action
.customHostSettings[n].url
{ess-icon}
|=== | ||
|
||
| `xpack.actions.customHostSettings[n].url` {ess-icon} | ||
| A URL associated with this custom host setting. Should be in form |
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.
| A URL associated with this custom host setting. Should be in form | |
| A URL associated with this custom host setting. Should be in the form of |
| `xpack.actions.customHostSettings[n].url` {ess-icon} | ||
| A URL associated with this custom host setting. Should be in form | ||
`protocol://hostname:port`, where `protocol` is `https` or `smtp`. If the | ||
port is not provided, 443 will be used for `https` and 25 will be used for |
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.
port is not provided, 443 will be used for `https` and 25 will be used for | |
port is not provided, 443 is used for `https` and 25 is used for |
| A URL associated with this custom host setting. Should be in form | ||
`protocol://hostname:port`, where `protocol` is `https` or `smtp`. If the | ||
port is not provided, 443 will be used for `https` and 25 will be used for | ||
`smtp`. The `smtp` URLs will be used for the Email actions which use this |
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.
`smtp`. The `smtp` URLs will be used for the Email actions which use this | |
`smtp`. The `smtp` URLs are used for the Email actions that use this |
|
||
Note that no other URL values should be part of this URL, including paths, | ||
query strings, and authentication information. When an http or smtp request | ||
is being made as part of executing an action, only the protocol, hostname and |
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.
is being made as part of executing an action, only the protocol, hostname and | |
is made as part of executing an action, only the protocol, hostname, and |
port of the URL for that request are used to look up these configuration | ||
values. | ||
|
||
| `xpack.actions.customHostSettings[n].smtp.ignoreTLS` {ess-icon} |
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.
xpack.actions
.customHostSettings[n]
.stmp.ignoreTLS {ess-icon}
| A boolean value indicatting that TLS must be used for this connection. | ||
|
||
| `xpack.actions.customHostSettings[n].tls.rejectUnauthorized` {ess-icon} | ||
| A boolean value indicating whether to bypass to certificate validation |
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 this be 2 sentences:
A boolean value indicating whether to bypass to certificate validation. Overrides the general xpack.actions.rejectUnauthorized configuration for requests made for this hostname/port.
|
||
| `xpack.actions.customHostSettings[n].tls.certificateAuthoritiesFiles` {ess-icon} | ||
| A file name or list of file names of PEM-encoded certificate files which | ||
should be used to validate the server. |
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.
Suggest this text:
A file name or list of file names of PEM-encoded certificate files to use to validate the server.
| `xpack.actions.customHostSettings[n].tls.certificateAuthoritiesData` {ess-icon} | ||
| The contents of a PEM-encoded certificate file, or multiple files appended | ||
into a single string. This configuration can be used for environments where | ||
the files themselves cannot be made available. |
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.
the files themselves cannot be made available. | |
the files cannot be made available. |
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.
Looks like there is an error with the format of the description for this setting:
xpack.actions.responseTimeout
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 wonder if something changed? Can no longer use |
within back-tick'd blocks? I ended up changing the |
to ,
, which looks fine, and did a little formatting to get the back-ticked section to not split across a line.
I elaborated on the example a bit, wasn't sure about the best way to show in concert with example connector configs, since that presumably would involve screenshots, at least for this PR. Also added a section in troubleshooting, basically just pointing to the action config page, referencing TLS errors. |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
…6630) resolves: elastic#80120 Adds a new Kibana configuration key xpack.actions.customHostSettings which allows per-host configuration of connection settings for https and smtp for alerting actions. Initially this is just for TLS settings, expandable to other settings in the future. The purpose of these is to allow customers to provide server certificates for servers accessed by actions, whose certificate authority is not available publicly. Alternatively, a per-server rejectUnauthorized: false configuration may be used to bypass the verification step for specific servers, but require it for other servers that do not have per-host customization. Support was also added to allow per-host customization of ignoreTLS and requireTLS flags for use with the email action.
…98674) resolves: #80120 Adds a new Kibana configuration key xpack.actions.customHostSettings which allows per-host configuration of connection settings for https and smtp for alerting actions. Initially this is just for TLS settings, expandable to other settings in the future. The purpose of these is to allow customers to provide server certificates for servers accessed by actions, whose certificate authority is not available publicly. Alternatively, a per-server rejectUnauthorized: false configuration may be used to bypass the verification step for specific servers, but require it for other servers that do not have per-host customization. Support was also added to allow per-host customization of ignoreTLS and requireTLS flags for use with the email action.
@pmuellr it looks like the docs aren't rendering properly? https://www.elastic.co/guide/en/kibana/current/alert-action-settings-kb.html |
resolves #80120
doc preview: https://kibana_96630.docs-preview.app.elstc.co/guide/en/kibana/master/alert-action-settings-kb.html
Summary
Adds a new Kibana configuration key
xpack.actions.customHostSettings
which allows per-host configuration of connection settings for https and smtp for alerting actions. Initially this is just for TLS settings, expandable to other settings in the future.The purpose of these is to allow customers to provide server certificates for servers accessed by actions, whose certificate authority is not available publicly. Alternatively, a per-server
rejectUnauthorized: false
configuration may be used to bypass the verification step for specific servers, but require it for other servers that do not have per-host customization.Support was also added to allow per-host customization of
ignoreTLS
andrequireTLS
flags for use with the email action.Checklist
Delete any items that are not applicable to this PR.
Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)This was checked for cross-browser compatibilityFor maintainers
This was checked for breaking API changes and was labeled appropriatelyRemaining To Do's
Release note
Adds a new Kibana configuration key
xpack.actions.customHostSettings
which allowsper-host configuration of connection settings for https and smtp for alerting
actions.