Repository navigation
[RAM] Add support for self-signed SSL certificate auth in webhook connector - #161894
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
…signed # Conflicts: # x-pack/test/detection_engine_api_integration/security_and_spaces/group1/export_rules.ts
…y/kibana into 160812-webhook-selfsigned
…-ref HEAD~1..HEAD --fix'
Make sense. A solution would be to hide the file picker if there is a CA and show our own custom component (unrelated to file inputs) where the user can see a fake file name and an "X" icon to remove the CA. Pressing the "X" will show the file picker. Nevertheless, I don't think is ideal and it may be more confusing. We can leave it as it is and enhance it later if needed.
I found it confusing to press the |
No it defaults to Full |
…signed # Conflicts: # x-pack/test/tsconfig.json
…y/kibana into 160812-webhook-selfsigned
pmuellr
left a comment
There was a problem hiding this comment.
Not finished reviewing, but I hit a few things early that I think we'll need to get resolved.
- undefined-able values in config/secrets
hasAuth: falsevsauthType: None
We also need to get tests added, similar to what is currently in https://github.com/elastic/kibana/blob/main/x-pack/plugins/actions/server/integration_tests/axios_utils_connection.test.ts - would be fine to re-org that if it's getting a bit big - perhaps even just have tests for the new combinations of ssl-ish options in a separate module.
| const secretSchemaProps = { | ||
| user: schema.nullable(schema.string()), | ||
| password: schema.nullable(schema.string()), | ||
| user: schema.maybe(schema.string()), |
There was a problem hiding this comment.
I don't think we can use maybe() here - unless we finally fixed the partial update issue, but I'd guess not. Anything in config / schema can never be undefined. schema.nullable() accepts an undefined value (or value not preset for the property), and return null.
| const agentSSLOptions = getNodeSSLOptions(logger, generalSSLSettings.verificationMode); | ||
| const agentSSLOptions = getNodeSSLOptions( | ||
| logger, | ||
| sslOverrides?.verificationMode ?? generalSSLSettings.verificationMode, |
There was a problem hiding this comment.
Yes, the webhook settings should override kibana.yml settings.
I'm wondering if there's cases where somehow they would be mixed - would that make sense? Is it even possible? I'd think we wouldn't want that, as it might be difficult to figure out what settings would actually be used.
| @@ -54,6 +55,25 @@ const configSchemaProps = { | |||
| }), | |||
| headers: nullableType(HeadersSchema), | |||
| hasAuth: schema.boolean({ defaultValue: true }), | |||
There was a problem hiding this comment.
What is the intention of having both hasAuth - which was the way we determined whether to require a user/pass - and authType: NONE? I assume they "mean" the same thing. But if we leave it like this, there are lots of potential combinations we'll have to verify; hasAuth: false and authType: Basic should be an error, right?
Would it be better to not have authType: NONE at all? Cuts down on some of the invalid combinations. So the validation would be !hasAuth && !authType or hasAuth && authType, or whatever.
There was a problem hiding this comment.
hasAuth seems to be a property common to several connector types, attempting to remove it broke a lot of tests at a deeper level.
It would also be a major breaking change for existing connectors, I'm not quite sure how to handle that.
There was a problem hiding this comment.
It looks like hasAuth used by email and cases, but should just be a config, so independent of any other connectors.
But I'm not suggesting we remove it - though that IS a possibility - change 2-state hasAuth to 3-state authType. That would require a migration, so ... not a happy path for me :-)
My suggestion is to remove the NONE choice of authType. Since that's already covered by hasAuth. So you could only set authType if hasAuth is true, otherwise it would need to be null.
There was a problem hiding this comment.
Had some difficulty getting the form to correctly load saved connectors with hasAuth: false but it should be working now. Connector API will now throw an error if hasAuth is false and authType is anything but null or undefined.
…icationmode none selection
…signed # Conflicts: # x-pack/test/tsconfig.json
pmuellr
left a comment
There was a problem hiding this comment.
I'm no expert on client-side certs, but seems like the integration_tests that got added need to be changed to be able to start the server in a mode where it requires the client-side certs.
| }); | ||
|
|
||
| test('it works with cert, key, and ca in SSL overrides', async () => { | ||
| const { url, server } = await createServer({ useHttps: true }); |
There was a problem hiding this comment.
I think this isn't going to test the client-side certificate stuff. We'll need to add another option to createServer() to have it pass requestCert in the TLS options when creating the server. Otherwise, the server is just going to ignore those.
To make sure this is working, we should have a negative test as well. Make a request to a client-side enabled server WITHOUT any of the client-side stuff, and it should fail. If we had that test in now, presumably the request would succeed, so the test would fail.
There was a problem hiding this comment.
Adding requestCert and getting socket hang up errors. This seems like what Node does when you're sending it an invalid client certificate but I'm not sure, docs are very unclear. I'm still investigating.
There was a problem hiding this comment.
Figured it out, server wasn't being configured with the Kibana CA by default. Tests are pushed and working now.
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
pmuellr
left a comment
There was a problem hiding this comment.
LGTM
Realized we should probably have a function test for this as well, in https://github.com/elastic/kibana/blob/main/x-pack/test/alerting_api_integration/spaces_only/tests/actions/connector_types/stack/webhook.ts - we don't have to test all the possibilities, but it would be good to test all the way through with at least one set of good parameters - and probably a negative test as well for the client-side cert (don't send one on the request).
Fine to do this is as a follow-on PR before feature freeze ...
Summary
Closes #160812
Adds UI for CA and client-side SSL certificate auth to webhook connector, and adds these properties to the webhook's HttpsAgent on execution:
When Editing
Also creates a Field helper for EuiFilePicker
Checklist