-
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
[ResponseOps][actions] add config for allow-listing email address domains #129001
Conversation
854f486
to
b80b9c2
Compare
6ff5116
to
3c4b94c
Compare
74e277f
to
56da55d
Compare
…ains resolves elastic#126944 Adds a new configuration setting for the actions plugin, xpack.actions.email.domain_allowlist, which is an array of domain name strings which are allowed to be sent emails by the email connector.
45f4962
to
7e8cd7f
Compare
@@ -1,5 +1,6 @@ | |||
pageLoadAssetSize: | |||
advancedSettings: 27596 | |||
actions: 20000 |
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 actual value was ~16K, figured I'd add some slop, but not quite sure if that's ok
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.
Yeah, that's fine
@@ -0,0 +1,56 @@ | |||
/* |
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.
These definitions were originally in a server directory, and accessed from a public directory, with an eslint directive to not generate a warning about that. However, when the actions plugin grew a public plugin, things got worse - we started getting a runtime message when Kibana started. So I extracted all the stuff from the server directory that the public code needed, and moved it in here.
@@ -454,21 +482,9 @@ describe('execute()', () => { | |||
"status": "ok", | |||
} | |||
`); | |||
delete sendEmailMock.mock.calls[0][1].configurationUtilities; |
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 is where I delete the configuration utilities from the calls structure, so we no longer compare it, so we don't have to change this code when we add new methods to the configuration utilities. I do this in some other tests that had the same pattern.
"configPath": ["xpack", "trigger_actions_ui"], | ||
"extraPublicDirs": ["public/common", "public/common/constants"], | ||
"requiredBundles": ["alerting", "esUiShared", "kibanaReact", "kibanaUtils"] | ||
"requiredBundles": ["alerting", "esUiShared", "kibanaReact", "kibanaUtils", "actions"] |
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 figured we need to add the actions bundle here, since it's now referencing code there. Though I think it worked at dev time without it - or maybe I was imagining that.
|
||
const ACTION_TYPE_ID = '.index'; | ||
let actionTypeModel: ActionTypeModel; | ||
|
||
beforeAll(() => { | ||
const actionTypeRegistry = new TypeRegistry<ActionTypeModel>(); | ||
registerBuiltInActionTypes({ actionTypeRegistry }); | ||
registerBuiltInActionTypes({ actionTypeRegistry, services: registrationServicesMock }); |
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.
registerBuiltInActionTypes()
takes an additional parameter now - services
- so all the connector type tests need this change; more below ...
Pinging @elastic/response-ops (Team:ResponseOps) |
@@ -1,5 +1,6 @@ | |||
pageLoadAssetSize: | |||
advancedSettings: 27596 | |||
actions: 20000 |
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.
Yeah, that's fine
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.
Changes LGTM! Tested locally the UI form validation in rule actions & connector flyouts. Also, tested implementing the allow_list after creating a rule and connector and saw the runtime validation prevent emails from sending out. Great work 👍
@@ -125,6 +125,11 @@ 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 cannot be made available. | |||
|
|||
`xpack.actions.email.domain_allowlist`:: | |||
A list of allowed email domains which can be used with the email connector. When this setting is not used, all email domains are allowed. When this setting is used, if any email is attempted to be sent that includes an addressee with an email domain that is not in the allowlist, the run of the connector will fail with a message indicating the emails not allowed. |
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 need to add a mention about the from
email domain 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.
Ah yes, we do. I realized I hadn't dealt with from
this week, so added it in as well, but forgot to update this.
For some reason the issue for this PR mentioned in the summary wasn't auto-linked in the issue itself; let's try it manually -here's the originating issue: #126944 |
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 great! Verified adding the domain allowlist works as expected for existing and new connectors. Left some comments about docs and more specificity in the error message.
@@ -125,6 +125,11 @@ 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 cannot be made available. | |||
|
|||
`xpack.actions.email.domain_allowlist`:: |
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 UI when creating a connector shows Email address <email> is not allowed.
if the from
is not allowed with a link to the email action type: https://www.elastic.co/guide/en/kibana/master/email-action-type.html but there is no mention of the domain allowlist on that page. Should we add a mention or a link to this allowlist entry?
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.
Ya, good idea, will add a link to that.
Reviewing now! |
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 reviewed the integration test change for the newly-exposed config setting -- LGTM.
I also took the liberty of reviewing the validation itself. I have some suggestions below!
@elasticmachine merge upstream |
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, thanks for the changes!
💚 Build SucceededMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
…ains (elastic#129001) resolves elastic#126944 Adds a new configuration setting for the actions plugin, xpack.actions.email.domain_allowlist, which is an array of domain name strings which are allowed to be sent emails by the email connector. backport of elastic#129001
…ess domains (#129001) (#131014) resolves #126944 Adds a new configuration setting for the actions plugin, xpack.actions.email.domain_allowlist, which is an array of domain name strings which are allowed to be sent emails by the email connector. backport of #129001 * additional changes after merge conflicts during cherry pick for backport
…ains (elastic#129001) resolves elastic#126944 Adds a new configuration setting for the actions plugin, xpack.actions.email.domain_allowlist, which is an array of domain name strings which are allowed to be sent emails by the email connector.
Summary
resolves #126944
docs preview:
Adds a new configuration setting for the
actions
plugin,xpack.actions.email.domain_allowlist
, which is an array of domain name strings which are allowed to be sent emails by the email connector. If this setting isn't used, there is no change to the way the email connector works before this PR - email addresses are generally only validated when the connector is executed, bynode-mailer
. If this setting is used, for each email connector, each email address specified in thefrom
property in config, andto
,cc
, andbcc
properties in params, will be validated, and their domains checked against the allow list. If any email is invalid (so we can't determine the domain), or it's domain is not in the allow list, that's considered an error condition, when the validation is run:from
propertyto
,cc
, orbcc
of any of it's actionsfrom
,to
,cc
, orbcc
are invalid/not allowed.This adds a new dependency on an npm package
email-addresses
, which we use to extract the domain from an email address. This also validates the email address, first. This seems like a well-maintained package and has no dependencies.We expose the config setting down into the UX via
exposeToBrowser
. A chat with Kibana Security indicated they didn't feel like this was a security concern. Basically, if we WANT to be able to validate email addresses in the UX, we will have to expose SOME way of validating email addresses via HTTP, so even the most obscure way of doing this (for example, exposing a new server endpoint to validate email addresses) will end up "leaking" which domains are actually allowed. If this is still felt to be a security concern, we can rip out everything on the UX side, and let the validation only happen on the server. The same error conditions will work, but the UX is not quite as nice - "Error saving connector: blah blah" instead of nice error indicators in appropriate fields in the UX.This required adding a new
public
plugin foractions
- it didn't have one before. Thecommon
folder for actions is also where the new validation logic is implemented, where it calls into theemail-addresses
package, so it's shared between client and server.Creating this new plugin caused some other issues, with some ServiceNow public code that was referencing the server plugin types, but using a
// eslint-disable-next-line @kbn/eslint/no-restricted-paths
comment to disable the compile time warning. With the new public plugin, this changed to a runtime warning message. So, the relevant types were extracted into common, and then the references to them changed. Seems like a good cleanup, and eliminated some//eslint-disable
usages.For function tests,
security_and_spaces
was left alone, so is the tester for NOT using the new config.spaces_only
now uses the new setting, and has added tests to ensure the code works as expected.To Verify
Add the new config, for example:
Then try creating a connector with a
from
with a different email address, and with anelastic.co
address. Should only work forelastic.co
. After creating a connector, try using the test page and using different values forto
,cc
, andbcc
. Should only work withelastic.co
addresses. Then add the email connector to an existing rule, and try setting theto
,cc
, andbcc
to different values to see they work or generate errors.Note, the email doesn't have to be a "live" one, you can use Gmail but give it bogus userid / password. In which case if you see a failure from Gmail, then the email would have validated and sent :-).
You can also test using previously created email connectors without the setting, then turn the setting on, and edit the connector to see the "new" errors.
Checklist
Delete any items that are not applicable to this PR.
Release Note
Adds a new configuration setting for the
actions
plugin,xpack.actions.email.domain_allowlist
, which is an array of domain name strings which are allowed to be sent emails by the email connector.