-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Fleet] Tighten policy permissions, take II #97366
[Fleet] Tighten policy permissions, take II #97366
Conversation
3e552e0
to
c17f064
Compare
368748d
to
8b1426f
Compare
Prepare code to provide tighth permissions as well.
We can read the package information from two places - The EPM registry (method `getRegistryPackage()`) - The local ES cache (method `getEsPackage()`) The package contains a property called `data_streams`. The contents of this property varied depending on from where the package was being loaded. The code in `getEsPackage` was cherry-picking what properties to load to do validation. We have changed the code so we cherry-pick only the properties that need some sort of validation, and pass the others in bulk.
8b1426f
to
dcc4c47
Compare
Pinging @elastic/fleet (Feature:Fleet) |
My assumption is that as long as a package does not specify any more fine grained permissions the permissions granted would be to append data for the data streams specified in the package as a default. Is this part of this PR? |
@ruflin yes, and only for the enabled data streams. For example, if a user adds the apache integration with only logs (no metrics), it will only give permissions to that agent to |
Hi @afgomez, in addition to the edge cases we discussed (Custom Logs, Endpoint, APM, etc), I remembered another set of permissions we need to add. If agent monitoring is enabled, we need to add permissions for those indices: elastic/beats#25350 (comment).
|
I'm assuming the agent releases are tied to the rest of the stack. How does it work right now when the user upgrades the stack?
What happens in the second step? Will the agent fetch its policy then? |
@elasticmachine merge upstream |
x-pack/plugins/fleet/server/services/package_policies_to_agent_permissions.ts
Outdated
Show resolved
Hide resolved
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Page load bundle
History
To update your PR or re-run it, just comment with: cc @afgomez |
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.
Thank you for making all the changes! I tested locally, Kibana only didn't test with agent usage yet, but the agent YAML LGTM 🚀
cluster: DEFAULT_PERMISSIONS.cluster, | ||
}; | ||
|
||
// TODO fetch this from the elastic agent package |
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.
Could you file an issue for this and link elastic/integrations#953 as a blocker?
One thing that would be nice to do on this PR would be to run the e2e-tests once before merging, it should show if most permissions we need are still in place. If I remember correctly this is possible. @mdelapenya should be able to help here. |
/run-fleet-e2e-tests |
I started the tests with the above command. The result is:
|
The job finished with errors: https://beats-ci.elastic.co/blue/organizations/jenkins/e2e-tests%2Fe2e-testing-mbp/detail/master/965/tests
All three fail because of timeouts: not reaching a desired state during a time window defined by max timeout (5-10 minutes!). The first one passes for Centos but not for Debian. |
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* master: clarify which parts of TM are experimental (elastic#101757) Add sh scripts with _bulk_action route usage examples (elastic#101736) [Uptime] Only register route in side nav if uptime show capability is true (elastic#101709) Use KIBANA_DOCS in doc link service (elastic#101667) [Alerting][Event log] Persisting duration information for active alerts in event log (elastic#101387) Address design issues in Discover/Graph (elastic#101584) Optimize performance for document table (elastic#101715) Change file data visualizer links to point to new location in home application (elastic#101393) [Fleet] Tighten policy permissions, take II (elastic#97366) [ML] Add debounce to the severity control update (elastic#101581) [Fleet] Fix routing issues with `getPath` and `history.push` (elastic#101658) [APM] Add link-to/transaction route (elastic#101731) [Index Patterns] Runtime fields CRUD REST API (elastic#101164) [ILM] Refactor types and fix missing aria labels (elastic#101518) [Lens] New summary row feature for datatable (elastic#101075) Blocks save event filter with a white space name (elastic#101599) Improve security server types (elastic#101661) [APM] Replace side nav with tabs on Settings page (elastic#101460) [APM] Only register items in side nav if user has permissions to see app (elastic#101707) [Security solution][Endpoint] Add back button when to the event filters list (elastic#101280)
Summary
Closes #64634.
This PR refines the work done in #94591. It narrows down the API key permissions that each agent needs based on the integrations that the policy uses.
To do so we look into the policy's
PacakgePolicy
and the enabled inputs. We link that with the packageDataStream
to determine which indices it uses and which permissions it needs. The permissions will be specified in the package'sdata_streams/*/manifest.yml
(pending proposal).At the moment of writing no packages specify what permissions they need, so I'm using the permissions that are necessary right now as defaults.
Testing
To test this PR:
The policy should have an
output_permissions
block, with several permissions per package instead of the genericlogs-*
,metrics-*
, etc.Checklist
Delete any items that are not applicable to this PR.