mirror of
https://github.com/elastic/kibana.git
synced 2025-04-25 10:23:14 -04:00
42168954b4
* [DOCS] Renames index pattern in management, monitoring, and graph * [DOCS] Renames index pattern on landing page * Updates URL in doc link service * Update docs/management/advanced-options.asciidoc Co-authored-by: Lisa Cawley <lcawley@elastic.co> * Update docs/user/monitoring/kibana-alerts.asciidoc Co-authored-by: Lisa Cawley <lcawley@elastic.co> Co-authored-by: lcawl <lcawley@elastic.co> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
75 lines
2.7 KiB
Text
75 lines
2.7 KiB
Text
[role="xpack"]
|
|
[[graph-configuration]]
|
|
== Configure Graph
|
|
|
|
When a user saves a graph workspace in Kibana, it is stored in the `.kibana`
|
|
index along with other saved objects like visualizations and dashboards.
|
|
By default, both the configuration and data are saved for the workspace:
|
|
|
|
[horizontal]
|
|
*configuration*::
|
|
The selected data view, fields, colors, icons,
|
|
and settings.
|
|
*data*::
|
|
The visualized content (the vertices and connections displayed in
|
|
the workspace).
|
|
|
|
The data in a saved workspace is like a report--it is a saved snapshot that
|
|
potentially summarizes millions of raw documents. Once saved, these summaries
|
|
are no longer controlled by security policies. Because the original documents
|
|
might be deleted after a workspace is saved, there's no practical basis for
|
|
checking permissions for the data in a saved workspace.
|
|
|
|
For this reason, you can configure the save policy for graph workspaces to
|
|
ensure appropriate handling of your data. You can allow all users to save
|
|
only the configuration information for a graph, require all users to
|
|
explicitly include the workspace data, or completely disable the ability
|
|
to save a workspace.
|
|
|
|
For example, to disable the save option entirely, set
|
|
`xpack.graph.savePolicy` to `none` in `kibana.yml`:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
xpack.graph.savePolicy: none
|
|
--------------------------------------------------
|
|
|
|
The supported save policies are:
|
|
|
|
`none`::
|
|
Neither the configuration or data can be saved.
|
|
`config`::
|
|
Only the configuration is saved.
|
|
`configAndData`::
|
|
Both configuration and data are saved. This is the
|
|
default policy.
|
|
`configAndDataWithConsent`::
|
|
Only the configuration is saved unless the user
|
|
explicitly selects the include data option.
|
|
|
|
[float]
|
|
=== Use Security to grant access
|
|
You can also use security to grant read only or all access to different roles.
|
|
When security is used to grant read only access, the following indicator in Kibana
|
|
is displayed. For more information on granting access to Kibana, see
|
|
<<xpack-security-authorization>>.
|
|
|
|
[role="screenshot"]
|
|
image::user/graph/images/graph-read-only-badge.png[Example of Graph's read only access indicator in Kibana's header, width=50%]
|
|
|
|
[discrete]
|
|
[[disable-drill-down]]
|
|
=== Disable drilldown configuration
|
|
|
|
By default, users can configure _drilldown_ URLs to display additional
|
|
information about a selected vertex in a new browser window. For example,
|
|
you could configure a drilldown URL to perform a web search for the selected
|
|
vertex term.
|
|
|
|
To prevent users from adding drilldown URLs, set
|
|
`xpack.graph.canEditDrillDownUrls` to `false` in `kibana.yml`:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------
|
|
xpack.graph.canEditDrillDownUrls: false
|
|
--------------------------------------------------
|