[Write restricted dashboards] Audit events#241101
Merged
SiddharthMantri merged 4 commits intoelastic:security/read-only-dashboardsfrom Oct 29, 2025
Merged
[Write restricted dashboards] Audit events#241101SiddharthMantri merged 4 commits intoelastic:security/read-only-dashboardsfrom
SiddharthMantri merged 4 commits intoelastic:security/read-only-dashboardsfrom
Conversation
Contributor
Author
|
@elasticmachine merge upstream |
elena-shostak
approved these changes
Oct 29, 2025
Contributor
elena-shostak
left a comment
There was a problem hiding this comment.
Verified locally, can confirm audit events are logged 🥇
{"event":{"action":"saved_object_update_objects_access_mode","category":["database"],"type":["change"],"outcome":"success"},"kibana":{"space_id":"default","session_id":"t7/G14FYLIcazDDDJJAZq1gxZWmDUEbwmcqPY5elTkw=","saved_object":{"type":"access_control_type","id":"dea18e44-35d0-4742-979d-80f648729f2d"}},"user":{"id":"u_mGBROF_q5bmFCATbLXAcCwKa0k8JvONAwSruelyKA5E_0","name":"elastic","roles":["superuser"]},"trace":{"id":"e7846a78-d1ae-4964-bac5-43481975047c"},"client":{"ip":"127.0.0.1"},"service":{"node":{"roles":["background_tasks","ui"]}},"ecs":{"version":"9.0.0"},"@timestamp":"2025-10-29T18:53:20.166+01:00","message":"User has updated access mode of access_control_type [id=dea18e44-35d0-4742-979d-80f648729f2d]","log":{"level":"INFO","logger":"plugins.security.audit.ecs"},"process":{"pid":60576,"uptime":1590.573061042},"span":{"id":"60e751cf7fdde50f"}}
---
{"event":{"action":"saved_object_update_objects_owner","category":["database"],"type":["change"],"outcome":"success"},"kibana":{"space_id":"default","session_id":"k5srR22XWFHSt/qBe6qLZ2b0aGT+ZRXUyPZhz9lfKSg=","saved_object":{"type":"access_control_type","id":"6c5fdbbb-38b8-4883-b72b-fe571672043c"}},"user":{"id":"u_mGBROF_q5bmFCATbLXAcCwKa0k8JvONAwSruelyKA5E_0","name":"elastic","roles":["superuser"]},"trace":{"id":"f46e6d2f-94cd-4ede-9d9b-6cd8d190a26b"},"client":{"ip":"127.0.0.1"},"service":{"node":{"roles":["background_tasks","ui"]}},"ecs":{"version":"9.0.0"},"@timestamp":"2025-10-29T18:57:29.182+01:00","message":"User has updated owner of access_control_type [id=6c5fdbbb-38b8-4883-b72b-fe571672043c]","log":{"level":"INFO","logger":"plugins.security.audit.ecs"},"process":{"pid":60576,"uptime":1839.584627708},"span":{"id":"d0f06bcea572331b"}}
Contributor
💔 Build Failed
Failed CI StepsTest Failures
Metrics [docs]
History
|
3c5c01b
into
elastic:security/read-only-dashboards
11 of 12 checks passed
SiddharthMantri
added a commit
that referenced
this pull request
Dec 12, 2025
Closes elastic/kibana-team#808 The respective teams have been raising PRs against this feature branch. Approved PRs merged so far: - #221916 - #224411 - #239973 - #241101 - #238468 - #233552 - #228416 - #241168 - #244746 - #244830 ## Summary This pull request overhauls the saved object management workflow by introducing the concept of ownership for SOs - specifically enabled for dashboards only at the moment. Owners and administrators can now control a new write-restricted flag on their objects, allowing them to keep work draft/uneditable state before publishing. This change enables users to define who can modify shared objects, providing a crucial capability to manage and share dashboards. ## Release note Kibana Dashboards now support ownership and "write_restricted" mode. Users can now keep dashboards publicly editable or in a write-restricted state until they are ready to publish, giving them more control over who can edit their dashboards, regardless of broader space permissions. ## How to test ### Serverless Please reach out to me via slack or in the project channel (#read-only-dashboards) to be invited to the serverless environment where this feature has been enabled. ### Local - Clone this PR - Enable the feature by editing kibana.yml to include ``` savedObjects.enableAccessControl: true ``` - Start ES and Kibana as you would - Once started, seed Kibana with sample data. This should create a few dashboards. - Navigate to dashboards and create a new one. - In the share modal, change the view mode `Everybody in the space Can View`, <img width="500" height="410" alt="image" src="https://github.com/user-attachments/assets/b895442f-cce3-41a6-8b47-d206a9afbf43" /> - Now create a new role which grants access to indices and dashboards all. Create a new user and then assign that role to the newly created user. <img width="500" height="410" alt="image" src="https://github.com/user-attachments/assets/dd5251e1-a3b5-41a8-abc1-7e67399d65d2" /> - Login as the new user and navigate to the dashboard you had initially set as `Can view`. You'll see that you're not able to edit the dashboard and a warning like <img width="500" height="410" alt="Screenshot 2025-11-28 at 12 30 50" src="https://github.com/user-attachments/assets/1f71ccc7-9dc6-4a68-9a2c-540aa74e4f03" /> ### Local (2nd option) You can also follow the instructions in #224411 that detail how to use the funtional test runner to test this using the test plugin created for this feature. ### Risk matrix - What happens when your feature is used in a non-default space or a custom space? Works as expected - What happens when there are multiple Kibana nodes using the same Elasticsearch cluster? Does not depend on functionality of kibana nodes - What happens when a plugin you depend on is disabled? Changes are in core and security - both are always available - What happens when a feature you depend on is disabled? No dependency - What happens when a third party integration you depend on is not responding? No third party inregration - Does the feature work in Elastic Cloud? Yes - Does the feature create a setting that needs to be exposed, or configured differently than the default, on the Elastic Cloud? No - Is there a significant performance impact that may affect Cloud Kibana instances? No - Does your feature need to be aware of running in a container? No - Does the feature Work with security disabled, or fails gracefully? If disabled, fails gracefully. - Are there performance risks associated with your feature? No - Could this cause memory to leak in either the browser or server? No - Will your feature still work if Kibana is run behind a reverse proxy? Yes - Does your feature affect other plugins? No, other plugins could choose to use it if registering a SO with ownable types - Are migrations handled gracefully? Does the feature affect old indices or saved objects? Yes, migrations taken care of. - Are you using any technologies, protocols, techniques, conventions, libraries, NPM modules, etc. that may be new or unprecedented in Kibana? No --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co> Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com> Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co> Co-authored-by: Krzysztof Kowalczyk <krzysztof.kowalczyk@elastic.co> Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
seanrathier
pushed a commit
to seanrathier/kibana
that referenced
this pull request
Dec 15, 2025
Closes elastic/kibana-team#808 The respective teams have been raising PRs against this feature branch. Approved PRs merged so far: - elastic#221916 - elastic#224411 - elastic#239973 - elastic#241101 - elastic#238468 - elastic#233552 - elastic#228416 - elastic#241168 - elastic#244746 - elastic#244830 ## Summary This pull request overhauls the saved object management workflow by introducing the concept of ownership for SOs - specifically enabled for dashboards only at the moment. Owners and administrators can now control a new write-restricted flag on their objects, allowing them to keep work draft/uneditable state before publishing. This change enables users to define who can modify shared objects, providing a crucial capability to manage and share dashboards. ## Release note Kibana Dashboards now support ownership and "write_restricted" mode. Users can now keep dashboards publicly editable or in a write-restricted state until they are ready to publish, giving them more control over who can edit their dashboards, regardless of broader space permissions. ## How to test ### Serverless Please reach out to me via slack or in the project channel (#read-only-dashboards) to be invited to the serverless environment where this feature has been enabled. ### Local - Clone this PR - Enable the feature by editing kibana.yml to include ``` savedObjects.enableAccessControl: true ``` - Start ES and Kibana as you would - Once started, seed Kibana with sample data. This should create a few dashboards. - Navigate to dashboards and create a new one. - In the share modal, change the view mode `Everybody in the space Can View`, <img width="500" height="410" alt="image" src="https://github.com/user-attachments/assets/b895442f-cce3-41a6-8b47-d206a9afbf43" /> - Now create a new role which grants access to indices and dashboards all. Create a new user and then assign that role to the newly created user. <img width="500" height="410" alt="image" src="https://github.com/user-attachments/assets/dd5251e1-a3b5-41a8-abc1-7e67399d65d2" /> - Login as the new user and navigate to the dashboard you had initially set as `Can view`. You'll see that you're not able to edit the dashboard and a warning like <img width="500" height="410" alt="Screenshot 2025-11-28 at 12 30 50" src="https://github.com/user-attachments/assets/1f71ccc7-9dc6-4a68-9a2c-540aa74e4f03" /> ### Local (2nd option) You can also follow the instructions in elastic#224411 that detail how to use the funtional test runner to test this using the test plugin created for this feature. ### Risk matrix - What happens when your feature is used in a non-default space or a custom space? Works as expected - What happens when there are multiple Kibana nodes using the same Elasticsearch cluster? Does not depend on functionality of kibana nodes - What happens when a plugin you depend on is disabled? Changes are in core and security - both are always available - What happens when a feature you depend on is disabled? No dependency - What happens when a third party integration you depend on is not responding? No third party inregration - Does the feature work in Elastic Cloud? Yes - Does the feature create a setting that needs to be exposed, or configured differently than the default, on the Elastic Cloud? No - Is there a significant performance impact that may affect Cloud Kibana instances? No - Does your feature need to be aware of running in a container? No - Does the feature Work with security disabled, or fails gracefully? If disabled, fails gracefully. - Are there performance risks associated with your feature? No - Could this cause memory to leak in either the browser or server? No - Will your feature still work if Kibana is run behind a reverse proxy? Yes - Does your feature affect other plugins? No, other plugins could choose to use it if registering a SO with ownable types - Are migrations handled gracefully? Does the feature affect old indices or saved objects? Yes, migrations taken care of. - Are you using any technologies, protocols, techniques, conventions, libraries, NPM modules, etc. that may be new or unprecedented in Kibana? No --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co> Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com> Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co> Co-authored-by: Krzysztof Kowalczyk <krzysztof.kowalczyk@elastic.co> Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #221755
Summary
Adds audit events on successful completion of changing object owner or access mode.
Detailed list of audit events on issue attached above.
Audit events added in this PR:
'failure''failure'Logging scenarios
1. AccessControl is modified by owner
2. AccessControl is modified by non-owner
3. AccessControl is modified by admin on non-admin owned object
Steps to test using integration tests
You can use the existing integration tests for access control by adding the following to the config file at:
x-pack/platform/test/spaces_api_integration/access_control_objects/config.tsConfig to add at
kbnTestServer.serverArgsOnce you run the tests as
You can perform the tests as described here #224411 and verify the logs in
kibana_audit.logfile generated at the root level of your kibana repository.