[Auth0] Add agentless deployment#18141
Conversation
|
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 |
| - 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
|
| - input: cel | ||
| title: Auth0 log events via API requests | ||
| description: Collects log events from Auth0 via API requests. | ||
| enabled: false |
There was a problem hiding this comment.
Kibana has addressed elastic/kibana#261788. Let's revert this change.
There was a problem hiding this comment.
Sure, let me check
There was a problem hiding this comment.
@andrewkroh
The PR has been merged with the 9.5.0 label, and the backport has been skipped. As per the current schedule, this 9.5.0 is planned for the July release. Shall we proceed with the workaround until then, as reverting the changes may cause the issue in the current serverless setup?
Let me know your thoughts on this.
There was a problem hiding this comment.
Is this a problem only affecting agentless deployments on Serverless? If so, the PR that was merged to main will be deployed to Serverless soon. Serverless uses artifacts produced from main not traditional tagged stack releases.
But if this is a problem affecting agentless on ECH too, then the fix should be backported and we should wait for that to be available on ECH.
There was a problem hiding this comment.
But if this is a problem affecting agentless on ECH too, then the fix should be backported and we should wait for that to be available on ECH.
The changes are now backported:
- [8.19] [Fleet] Fix missing fields for
enabled:falseinputs in agentless deployment modes (#265106) kibana#266203 - [9.3] [Fleet] Fix missing fields for
enabled:falseinputs in agentless deployment modes (#265106) kibana#266201 - [9.4] [Fleet] Fix missing fields for
enabled:falseinputs in agentless deployment modes (#265106) kibana#266103
Once they are available on ECH, we should update the stack version constraints accordingly.
Proposed commit message
Checklist
changelog.ymlfile.How to test this PR locally
Related issues