[Auth0] Add agentless deployment#18141
Conversation
moxarth-rathod
added
enhancement
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
Vale Linting ResultsSummary: 2 warnings found
|
| File | Line | Rule | Message |
|---|---|---|---|
| packages/auth0/_dev/build/docs/README.md | 7 | Elastic.Latinisms | Latin terms and abbreviations are a common source of confusion. Use 'using' instead of 'via'. |
| packages/auth0/docs/README.md | 7 | Elastic.Latinisms | Latin terms and abbreviations are a common source of confusion. Use 'using' instead of 'via'. |
The Vale linter checks documentation changes against the Elastic Docs style guide.
To use Vale locally or report issues, refer to Elastic style guide for Vale.
🚀 Benchmarks reportTo see the full report comment with |
andrewkroh
added
the
documentation
| - remove: | ||
| field: | ||
| - organization | ||
| - division | ||
| - team |
There was a problem hiding this comment.
This should not be needed if the minimum kibana matches where elastic/kibana#230479 was applied.
There was a problem hiding this comment.
We need the minimum kibana version - 8.19.2 to fix elastic/kibana#230479.
There was a problem hiding this comment.
Why was the minimum version selected as ^8.18.0? I think we can safely move to at least 8.19.2, and drop this remove processor.
The 8.18 Elastic stack is unsupported / unmaintained. And it has been since 9.2 was released (Oct 23 2025)1.
Footnotes
There was a problem hiding this comment.
Got it, Thanks for the suggestions!
| - input: http_endpoint | ||
| title: Auth0 log events via Webhooks | ||
| description: Receives log events from Auth0 via Webhooks | ||
| enabled: false |
There was a problem hiding this comment.
This prevents a UI bug in serverless where having all available options disabled causes an issue. I'll create a separate issue for it and attach it here.
There was a problem hiding this comment.
Issue link: https://github.com/elastic/beats/issues/49942
There was a problem hiding this comment.
So this is a workaround for a UI bug? There needs to be a UI bug issue (elastic/kibana) associated as well.
I think the reason both inputs are disabled is to make the user choose their ingestion method. Changing the enabled default value does affect new users experience the onboarding flow, both in the UI and especially via the package_policy API.
Let's say you are an API user who was only configuring the CEL input in their requests. Then the http_endpoint becomes enabled by default in the integration package. The next time you try to reproduce an API request for auth0 you will get new behavior. They might not notice it in this case because there are no mandatory variables for the http_endpoint stream, but their agents will now have an HTTP server listening which is very surprising.
Or let's say, they were using the http_endpoint only. Now the CEL input becomes enabled by default. This is different from the earlier case because the CEL input does have two mandatory variables, client_id and client_secret, so now the package_policy API request that they used to make fails because they did not set the mandatory variables. This will be confusing because their request didn't ask for the CEL input at all.
All of this is to say that changing enabled can impact users.
If we must have a workaround and the requirement is to have an input enabled, then it should only enable the CEL input. The http_endpoint input is not supported in agentless. And ideally we should return the integration back to its original state (enabled=false) after Kibana addresses the UX issue.
There was a problem hiding this comment.
There is #18157 which looks related (though auth0 is not listed in that issue) and which links to elastic/kibana#260500.
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
💚 Build Succeeded
History
|
4 participants
Proposed commit message
Checklist
changelog.ymlfile.How to test this PR locally
Related issues