Add Security information to Security Analytics documentation (#3184)
* sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * fix#3183-sec-for-sec-a Signed-off-by: cwillum <cwmmoore@amazon.com> * fix#3183-sec-for-sec-a Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * fix#3183 for merge main Signed-off-by: cwillum <cwmmoore@amazon.com> * fix#3183 fixing links-breaking links Signed-off-by: cwillum <cwmmoore@amazon.com> * sec permissions for SA Signed-off-by: cwillum <cwmmoore@amazon.com> * fix#3183-sec-for-sec-a Signed-off-by: cwillum <cwmmoore@amazon.com> --------- Signed-off-by: cwillum <cwmmoore@amazon.com>
This commit is contained in:
Chris Moore
GitHub
parent
ade705e9f5
commit
ede72716a5
|
|
@ -12,6 +12,7 @@ You can register a new repository in which to store snapshots or update informat
|
|||
There are two types of snapshot repositories:
|
||||
|
||||
* File system (`fs`): For instructions on creating an `fs` repository, see [Register repository shared file system]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/#shared-file-system).
|
||||
|
||||
* Amazon Simple Storage Service (Amazon S3) bucket (`s3`): For instructions on creating an `s3` repository, see [Register repository Amazon S3]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/#amazon-s3).
|
||||
|
||||
For instructions on creating a repository, see [Register repository]({{site.url}}{{site.baseurl}}/opensearch/snapshots/snapshot-restore#register-repository).
|
||||
|
|
|
|||
|
|
@ -14,8 +14,9 @@ Restores a snapshot of a cluster or specified data streams and indices.
|
|||
|
||||
* For information about data streams, see [Data streams]({{site.url}}{{site.baseurl}}/opensearch/data-streams).
|
||||
|
||||
If open indices with the same name that you want to restore already exist in the cluster, you must close, delete, or rename the indices. See [Sample Request](#example-request) for information about renaming an index. See [Close index]({{site.url}}{{site.baseurl}}/api-reference/index-apis/close-index) for information about closing an index.
|
||||
If open indexes with the same name that you want to restore already exist in the cluster, you must close, delete, or rename the indexes. See [Example request](#example-request) for information about renaming an index. See [Close index]({{site.url}}{{site.baseurl}}/api-reference/index-apis/close-index) for information about closing an index.
|
||||
{: .note}
|
||||
|
||||
### Path parameters
|
||||
|
||||
| Parameter | Data type | Description |
|
||||
|
|
@ -69,7 +70,7 @@ POST /_snapshot/my-opensearch-repo/my-first-snapshot/_restore
|
|||
}
|
||||
````
|
||||
|
||||
#### Sample Response
|
||||
#### Example response
|
||||
|
||||
Upon success, the response returns the following JSON object:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
layout: default
|
||||
title: OpenSearch Security for Security Analytics
|
||||
nav_order: 2
|
||||
has_children: false
|
||||
---
|
||||
|
||||
# OpenSearch Security for Security Analytics
|
||||
|
||||
You can use OpenSearch Security with Security Analytics to assign user permissions and manage the actions that users can and cannot perform. For example, you might want one group of users to be able to create, update, or delete detectors and another group of users to only view detectors. You may want still another group to be able to receive and acknowledge alerts but to be prevented from performing other tasks. The OpenSearch Security framework allows you to control the level of access users have to Security Analytics functionality.
|
||||
|
||||
|
||||
## Security Analytics system indexes
|
||||
|
||||
Security Analytics indexes are protected as system indexes and treated differently than other indexes in a cluster. System indexes store configurations and other system settings and, for that reason, cannot be modified using the REST API or the OpenSearch Dashboards interface. Only a user with a TLS [admin certificate]({{site.url}}{{site.baseurl}}/security/configuration/tls/#configuring-admin-certificates) can access system indexes. For more information about working with this type of index, see [System indexes]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/).
|
||||
|
||||
|
||||
## Basic permissions
|
||||
|
||||
As an administrator, you can use OpenSearch Dashboards or the Security REST API to assign specific permissions to users based on the specific APIs they need to access. For a list of supported APIs, see [API tools]({{site.url}}{{site.baseurl}}/security-analytics/api-tools/index/).
|
||||
|
||||
OpenSearch Security has three built-in roles that cover most Security Analytics use cases: `security_analytics_full_access`, `security_analytics_read_access`, and `security_analytics_ack_alerts`. For descriptions of these and other roles, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
|
||||
|
||||
If these roles don't meet your needs, mix and match individual Security Analytics [permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/#security-analytics-permissions) to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opensearch/securityanalytics/detector/delete` permission allows you to delete detectors.
|
||||
|
||||
|
||||
## (Advanced) Limit access by backend role
|
||||
|
||||
You can use backend roles to configure fine-grained access to individual detectors based on roles. For example, backend roles can be assigned to users working in different departments of an organization so that they can view only those detectors owned by the departments in which they work.
|
||||
|
||||
First, make sure your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security/configuration/saml/). However, if you use the internal user database, you can use the REST API to [add them manually]({{site.url}}{{site.baseurl}}/security/access-control/api#create-user).
|
||||
|
||||
Next, enable the following setting:
|
||||
|
||||
```json
|
||||
PUT /_cluster/settings
|
||||
{
|
||||
"transient": {
|
||||
"plugins.security_analytics.filter_by_backend_roles": "true"
|
||||
}
|
||||
}
|
||||
```
|
||||
{% include copy-curl.html %}
|
||||
|
||||
Now when users view Security Analytics resources in OpenSearch Dashboards (or make REST API calls), they only see detectors created by users who share at least one backend role.
|
||||
For example, consider two users: `alice` and `bob`.
|
||||
|
||||
The following example assigns the user `alice` the `analyst` backend role:
|
||||
|
||||
```json
|
||||
PUT /_plugins/_security/api/internalusers/alice
|
||||
{
|
||||
"password": "alice",
|
||||
"backend_roles": [
|
||||
"analyst"
|
||||
],
|
||||
"attributes": {}
|
||||
}
|
||||
```
|
||||
{% include copy-curl.html %}
|
||||
|
||||
The next example assigns the user `bob` the `human-resources` backend role:
|
||||
|
||||
```json
|
||||
PUT /_plugins/_security/api/internalusers/bob
|
||||
{
|
||||
"password": "bob",
|
||||
"backend_roles": [
|
||||
"human-resources"
|
||||
],
|
||||
"attributes": {}
|
||||
}
|
||||
```
|
||||
{% include copy-curl.html %}
|
||||
|
||||
Finally, this last example assigns both `alice` and `bob` the role that gives them full access to Security Analytics:
|
||||
|
||||
```json
|
||||
PUT /_plugins/_security/api/rolesmapping/security_analytics_full_access
|
||||
{
|
||||
"backend_roles": [],
|
||||
"hosts": [],
|
||||
"users": [
|
||||
"alice",
|
||||
"bob"
|
||||
]
|
||||
}
|
||||
```
|
||||
{% include copy-curl.html %}
|
||||
|
||||
However, because they have different backend roles, `alice` and `bob` cannot view each other's detectors or their results.
|
||||
|
||||
|
||||
## A note on using fine-grained access control with the plugin
|
||||
|
||||
When a trigger generates an alert, the detector configurations, the alert itself, and any notifications that are sent to a channel may include metadata describing the index being queried. By design, the plugin must extract the data and store it as metadata outside of the index. [Document-level security]({{site.url}}{{site.baseurl}}/security/access-control/document-level-security) (DLS) and [field-level security]({{site.url}}{{site.baseurl}}/security/access-control/field-level-security) (FLS) access controls are designed to protect the data in the index. But once the data is stored outside the index as metadata, users with access to the detector and monitor configurations, alerts, and their notifications will be able to view this metadata and possibly infer the contents and quality of data in the index, which would otherwise be concealed by DLS and FLS access control.
|
||||
|
||||
To reduce the chances of unintended users viewing metadata that could describe an index, we recommend that administrators enable role-based access control and keep these kinds of design elements in mind when assigning permissions to the intended group of users. See [Limit access by backend role](#advanced-limit-access-by-backend-role) for more information.
|
||||
|
|
@ -1524,7 +1524,7 @@ PUT /_opendistro/_security/api/audit/config
|
|||
|
||||
A PATCH call is used to update specified fields in the audit configuration. The PATCH method requires an operation, a path, and a value to complete a valid request. For details on using the PATCH method, see the following [Patching resources](https://en.wikipedia.org/wiki/PATCH_%28HTTP%29#Patching_resources) description at Wikipedia.
|
||||
|
||||
Using the PATCH method also requires a user to have a security configuration that includes admin certificates for encryption. To find out more about these certificates, see [Configure admin certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/#configuring-admin-certificates).
|
||||
Using the PATCH method also requires a user to have a security configuration that includes admin certificates for encryption. To find out more about these certificates, see [Configuring admin certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/#configuring-admin-certificates).
|
||||
|
||||
```bash
|
||||
curl -X PATCH -k -i --cert <admin_cert file name> --key <admin_cert_key file name> <domain>/_opendistro/_security/api/audit -H 'Content-Type: application/json' -d'[{"op":"add","path":"/config/enabled","value":"true"}]'
|
||||
|
|
|
|||
|
|
@ -67,13 +67,26 @@ Rather than individual permissions, you can often achieve your desired security
|
|||
|
||||
## Cluster permissions
|
||||
|
||||
These permissions are for the cluster and can't be applied granularly. For example, you either have permissions to take snapshots (`cluster:admin/snapshot/create`) or you don't. You can't have permissions to take snapshots only for certain indices.
|
||||
These permissions are for the cluster and can't be applied granularly. For example, you either have permissions to take snapshots (`cluster:admin/snapshot/create`) or you don't. The cluster permission, therefore, cannot grant a user privileges to take snapshots of a select set of indexes while preventing the user from taking snapshots of others.
|
||||
|
||||
Cross-references to API documentation in the permissions that follow are only intended to provide an understanding of the permissions. As stated at the beginning of this section, permissions often correlate to APIs but do not map directly to them.
|
||||
{: .note }
|
||||
|
||||
|
||||
### Ingest API permissions
|
||||
|
||||
See [Ingest APIs]({{site.url}}{{site.baseurl}}/api-reference/ingest-apis/index/).
|
||||
|
||||
- cluster:admin/ingest/pipeline/delete
|
||||
- cluster:admin/ingest/pipeline/get
|
||||
- cluster:admin/ingest/pipeline/put
|
||||
- cluster:admin/ingest/pipeline/simulate
|
||||
- cluster:admin/ingest/processor/grok/get
|
||||
|
||||
### Anomaly Detection permissions
|
||||
|
||||
See [Anomaly detection API]({{site.url}}{{site.baseurl}}/observing-your-data/ad/api/).
|
||||
|
||||
- cluster:admin/opendistro/ad/detector/delete
|
||||
- cluster:admin/opendistro/ad/detector/info
|
||||
- cluster:admin/opendistro/ad/detector/jobmanagement
|
||||
|
|
@ -87,7 +100,12 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/ad/result/search
|
||||
- cluster:admin/opendistro/ad/result/topAnomalies
|
||||
- cluster:admin/opendistro/ad/tasks/search
|
||||
- cluster:admin/opendistro/alerting/alerts/ack (acknowledge)
|
||||
|
||||
### Alerting permissions
|
||||
|
||||
See [Alerting API]({{site.url}}{{site.baseurl}}/observing-your-data/alerting/api/).
|
||||
|
||||
- cluster:admin/opendistro/alerting/alerts/ack
|
||||
- cluster:admin/opendistro/alerting/alerts/get
|
||||
- cluster:admin/opendistro/alerting/destination/delete
|
||||
- cluster:admin/opendistro/alerting/destination/email_account/delete
|
||||
|
|
@ -105,10 +123,20 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/alerting/monitor/get
|
||||
- cluster:admin/opendistro/alerting/monitor/search
|
||||
- cluster:admin/opendistro/alerting/monitor/write
|
||||
|
||||
### Asynchronous Search permissions
|
||||
|
||||
See [Asynchronous search]({{site.url}}{{site.baseurl}}/search-plugins/async/index/).
|
||||
|
||||
- cluster:admin/opendistro/asynchronous_search/stats
|
||||
- cluster:admin/opendistro/asynchronous_search/delete
|
||||
- cluster:admin/opendistro/asynchronous_search/get
|
||||
- cluster:admin/opendistro/asynchronous_search/submit
|
||||
|
||||
### Index State Management permissions
|
||||
|
||||
See [ISM API]({{site.url}}{{site.baseurl}}/im-plugin/ism/api/).
|
||||
|
||||
- cluster:admin/opendistro/ism/managedindex/add
|
||||
- cluster:admin/opendistro/ism/managedindex/change
|
||||
- cluster:admin/opendistro/ism/managedindex/remove
|
||||
|
|
@ -118,6 +146,11 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/ism/policy/get
|
||||
- cluster:admin/opendistro/ism/policy/search
|
||||
- cluster:admin/opendistro/ism/policy/delete
|
||||
|
||||
### Index rollups permissions
|
||||
|
||||
See [Index rollups API]({{site.url}}{{site.baseurl}}/im-plugin/index-rollups/rollup-api/).
|
||||
|
||||
- cluster:admin/opendistro/rollup/index
|
||||
- cluster:admin/opendistro/rollup/get
|
||||
- cluster:admin/opendistro/rollup/search
|
||||
|
|
@ -125,6 +158,11 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/rollup/start
|
||||
- cluster:admin/opendistro/rollup/stop
|
||||
- cluster:admin/opendistro/rollup/explain
|
||||
|
||||
### Reporting permissions
|
||||
|
||||
See [Creating reports with the Dashboards interface]({{site.url}}{{site.baseurl}}/dashboards/reporting/).
|
||||
|
||||
- cluster:admin/opendistro/reports/definition/create
|
||||
- cluster:admin/opendistro/reports/definition/update
|
||||
- cluster:admin/opendistro/reports/definition/on_demand
|
||||
|
|
@ -134,6 +172,11 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/reports/instance/list
|
||||
- cluster:admin/opendistro/reports/instance/get
|
||||
- cluster:admin/opendistro/reports/menu/download
|
||||
|
||||
### Transform job permissions
|
||||
|
||||
See [Transforms APIs]({{site.url}}{{site.baseurl}}/im-plugin/index-transforms/transforms-apis/)
|
||||
|
||||
- cluster:admin/opendistro/transform/index
|
||||
- cluster:admin/opendistro/transform/get
|
||||
- cluster:admin/opendistro/transform/preview
|
||||
|
|
@ -141,30 +184,105 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:admin/opendistro/transform/start
|
||||
- cluster:admin/opendistro/transform/stop
|
||||
- cluster:admin/opendistro/transform/explain
|
||||
|
||||
### Observability permissions
|
||||
|
||||
See [Observability security]({{site.url}}{{site.baseurl}}/observing-your-data/observability-security/).
|
||||
|
||||
- cluster:admin/opensearch/observability/create
|
||||
- cluster:admin/opensearch/observability/update
|
||||
- cluster:admin/opensearch/observability/delete
|
||||
- cluster:admin/opensearch/observability/get
|
||||
|
||||
### Cross-cluster replication
|
||||
|
||||
See [Cross-cluster replication security]({{site.url}}{{site.baseurl}}/tuning-your-cluster/replication-plugin/permissions/).
|
||||
|
||||
- cluster:admin/plugins/replication/autofollow/update
|
||||
|
||||
### Reindex
|
||||
|
||||
See [Reindex document]({{site.url}}{{site.baseurl}}/api-reference/document-apis/reindex/).
|
||||
|
||||
- cluster:admin/reindex/rethrottle
|
||||
|
||||
### Snapshot repository permissions
|
||||
|
||||
See [Snapshot APIs]({{site.url}}{{site.baseurl}}/api-reference/snapshots/index/).
|
||||
|
||||
- cluster:admin/repository/delete
|
||||
- cluster:admin/repository/get
|
||||
- cluster:admin/repository/put
|
||||
- cluster:admin/repository/verify
|
||||
|
||||
### Reroute
|
||||
|
||||
See [Cluster manager task throttling]({{site.url}}{{site.baseurl}}/tuning-your-cluster/cluster-manager-task-throttling/).
|
||||
|
||||
- cluster:admin/reroute
|
||||
|
||||
### Script permissions
|
||||
|
||||
See [Script APIs]({{site.url}}{{site.baseurl}}/api-reference/script-apis/index/).
|
||||
|
||||
- cluster:admin/script/delete
|
||||
- cluster:admin/script/get
|
||||
- cluster:admin/script/put
|
||||
|
||||
### Update settings permission
|
||||
|
||||
See [Update settings]({{site.url}}{{site.baseurl}}api-reference/index-apis/update-settings/) on the Index APIs page.
|
||||
|
||||
- cluster:admin/settings/update
|
||||
|
||||
### Snapshot permissions
|
||||
|
||||
See [Snapshot APIs]({{site.url}}{{site.baseurl}}/api-reference/snapshots/index/).
|
||||
|
||||
- cluster:admin/snapshot/create
|
||||
- cluster:admin/snapshot/delete
|
||||
- cluster:admin/snapshot/get
|
||||
- cluster:admin/snapshot/restore
|
||||
- cluster:admin/snapshot/status
|
||||
- cluster:admin/snapshot/status*
|
||||
|
||||
### Task permissions
|
||||
|
||||
See [Tasks]({{site.url}}{{site.baseurl}}/api-reference/tasks/) in the API Reference section.
|
||||
|
||||
- cluster:admin/tasks/cancel
|
||||
- cluster:admin/tasks/test
|
||||
- cluster:admin/tasks/testunblock
|
||||
|
||||
### Security Analytics permissions
|
||||
|
||||
See [API tools]({{site.url}}{{site.baseurl}}/security-analytics/api-tools/index/).
|
||||
|
||||
| **Permission** | **Description** |
|
||||
| :--- | :--- |
|
||||
| cluster:admin/opensearch/securityanalytics/alerts/get | Permission to get alerts |
|
||||
| cluster:admin/opensearch/securityanalytics/alerts/ack | Permission to acknowledge alerts |
|
||||
| cluster:admin/opensearch/securityanalytics/detector/get | Permission to get detectors |
|
||||
| cluster:admin/opensearch/securityanalytics/detector/search | Permission to search detectors |
|
||||
| cluster:admin/opensearch/securityanalytics/detector/write | Permission to create and update detectors |
|
||||
| cluster:admin/opensearch/securityanalytics/detector/delete | Permission to delete detectors |
|
||||
| cluster:admin/opensearch/securityanalytics/findings/get | Permission to get findings |
|
||||
| cluster:admin/opensearch/securityanalytics/mapping/get | Permission to get field mappings by index |
|
||||
| cluster:admin/opensearch/securityanalytics/mapping/view/get | Permission to get field mappings by index and view mapped and unmapped fields |
|
||||
| cluster:admin/opensearch/securityanalytics/mapping/create | Permission to create field mappings |
|
||||
| cluster:admin/opensearch/securityanalytics/mapping/update | Permission to update field mappings |
|
||||
| cluster:admin/opensearch/securityanalytics/rules/categories | Permission to get all rule categories |
|
||||
| cluster:admin/opensearch/securityanalytics/rule/write | Permission to create and update rules |
|
||||
| cluster:admin/opensearch/securityanalytics/rule/search | Permission to search for rules |
|
||||
| cluster:admin/opensearch/securityanalytics/rules/validate | Permission to validate rules |
|
||||
| cluster:admin/opensearch/securityanalytics/rule/delete | Permission to delete rules |
|
||||
|
||||
### Monitoring permissions
|
||||
|
||||
Cluster permissions for monitoring the cluster apply to read-only operations, such as checking cluster health and getting information about usage on nodes or tasks running in the cluster.
|
||||
|
||||
See [REST API reference]({{site.url}}{{site.baseurl}}/api-reference/index/).
|
||||
|
||||
- cluster:monitor/allocation/explain
|
||||
- cluster:monitor/health
|
||||
- cluster:monitor/main
|
||||
|
|
@ -180,7 +298,11 @@ These permissions are for the cluster and can't be applied granularly. For examp
|
|||
- cluster:monitor/task/get
|
||||
- cluster:monitor/tasks/list
|
||||
|
||||
The following permissions are for indexes but apply globally to the cluster:
|
||||
### Index templates
|
||||
|
||||
The index template permissions are for indexes but apply globally to the cluster.
|
||||
|
||||
See [Index templates]({{site.url}}{{site.baseurl}}/im-plugin/index-templates/).
|
||||
|
||||
- indices:admin/index_template/delete
|
||||
- indices:admin/index_template/get
|
||||
|
|
|
|||
|
|
@ -101,42 +101,44 @@ See [Create role mapping]({{site.url}}{{site.baseurl}}/security/access-control/a
|
|||
|
||||
The security plugin includes several predefined roles that serve as useful defaults.
|
||||
|
||||
Role | Description
|
||||
:--- | :---
|
||||
`alerting_ack_alerts` | Grants permissions to view and acknowledge alerts, but not modify destinations or monitors.
|
||||
`alerting_full_access` | Grants full permissions to all alerting actions.
|
||||
`alerting_read_access` | Grants permissions to view alerts, destinations, and monitors, but not acknowledge alerts or modify destinations or monitors.
|
||||
`anomaly_full_access` | Grants full permissions to all anomaly detection actions.
|
||||
`anomaly_read_access` | Grants permissions to view detectors, but not create, modify, or delete detectors.
|
||||
`all_access` | Grants full access to the cluster: all cluster-wide operations, write to all indices, write to all tenants.
|
||||
`cross_cluster_replication_follower_full_access` | Grants full access to perform cross-cluster replication actions on the follower cluster.
|
||||
`cross_cluster_replication_leader_full_access` | Grants full access to perform cross-cluster replication actions on the leader cluster.
|
||||
`observability_full_access` | Grants full access to perform actions on Observability objects such as visualizations, notebooks, and operational panels.
|
||||
`observability_read_access` | Grants permission to view Observability objects such as visualizations, notebooks, and operational panels, but not create, modify, or delete them.
|
||||
`kibana_read_only` | A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects. To enable read-only mode in Dashboards, add the `opensearch_security.readonly_mode.roles` setting to the `opensearch_dashboards.yml` file and include the role as a setting value. See the [example configuration]({{site.url}}{{site.baseurl}}/dashboards/branding/#sample-configuration) in Dashboards documentation.
|
||||
`kibana_user` | Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indexes.
|
||||
`logstash` | Grants permissions for Logstash to interact with the cluster: cluster-wide searches, cluster monitoring, and write to the various Logstash indices.
|
||||
`manage_snapshots` | Grants permissions to manage snapshot repositories, take snapshots, and restore snapshots.
|
||||
`readall` | Grants permissions for cluster-wide searches like `msearch` and search permissions for all indices.
|
||||
`readall_and_monitor` | Same as `readall`, but with added cluster monitoring permissions.
|
||||
`security_rest_api_access` | A special role that allows access to the REST API. See `plugins.security.restapi.roles_enabled` in `opensearch.yml` and [Access control for the API]({{site.url}}{{site.baseurl}}/security/access-control/api/#access-control-for-the-api).
|
||||
`reports_read_access` | Grants permissions to generate on-demand reports, download existing reports, and view report definitions, but not to create report definitions.
|
||||
`reports_instances_read_access` | Grants permissions to generate on-demand reports and download existing reports, but not to view or create report definitions.
|
||||
`reports_full_access` | Grants full permissions to reports.
|
||||
`asynchronous_search_full_access` | Grants full permissions to all asynchronous search actions.
|
||||
`asynchronous_search_read_access` | Grants permissions to view asynchronous searches but not to submit, modify, or delete async searches.
|
||||
`index_management_full_access` | Grants full permissions to all index management actions, including Index State Management (ISM), transforms, and rollups.
|
||||
`snapshot_management_full_access` | Grants full permissions to all snapshot management actions.
|
||||
`snapshot_management_read_access` | Grants permissions to view policies but not create, modify, start, stop, or delete them.
|
||||
`point_in_time_full_access` | Grants full permissions to all Point in Time operations.
|
||||
| **Role** | **Description** |
|
||||
| :--- | :--- |
|
||||
| `alerting_ack_alerts` | Grants permissions to view and acknowledge alerts, but not to modify destinations or monitors. |
|
||||
| `alerting_full_access` | Grants full permissions to all alerting actions. |
|
||||
| `alerting_read_access` | Grants permissions to view alerts, destinations, and monitors, but not to acknowledge alerts or modify destinations or monitors. |
|
||||
| `anomaly_full_access` | Grants full permissions to all anomaly detection actions. |
|
||||
| `anomaly_read_access` | Grants permissions to view detectors, but not to create, modify, or delete detectors. |
|
||||
| `all_access` | Grants full access to the cluster, including all cluster-wide operations, permission to write to all cluster indexes, and permission to write to all tenants. For more information on access using the REST API, see [Access control for the API]({{site.url}}{{site.baseurl}}/security/access-control/api/#access-control-for-the-api). |
|
||||
| `cross_cluster_replication_follower_full_access` | Grants full access to perform cross-cluster replication actions on the follower cluster. |
|
||||
| `cross_cluster_replication_leader_full_access` | Grants full access to perform cross-cluster replication actions on the leader cluster. |
|
||||
| `observability_full_access` | Grants full access to perform actions on Observability objects such as visualizations, notebooks, and operational panels. |
|
||||
| `observability_read_access` | Grants permission to view Observability objects such as visualizations, notebooks, and operational panels, but not to create, modify, or delete them. |
|
||||
| `kibana_read_only` | A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects. To enable read-only mode in Dashboards, add the `opensearch_security.readonly_mode.roles` setting to the `opensearch_dashboards.yml` file and include the role as a setting value. See the [example configuration]({{site.url}}{{site.baseurl}}/dashboards/branding/#sample-configuration) in Dashboards documentation. |
|
||||
| `kibana_user` | Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indexes. |
|
||||
| `logstash` | Grants permissions for Logstash to interact with the cluster: cluster-wide searches, cluster monitoring, and write to the various Logstash indexes. |
|
||||
| `manage_snapshots` | Grants permissions to manage snapshot repositories, take snapshots, and restore snapshots. |
|
||||
| `readall` | Grants permissions for cluster-wide searches like `msearch` and search permissions for all indexes. |
|
||||
| `readall_and_monitor` | Same as `readall` but with added cluster permissions for monitoring. |
|
||||
| `security_rest_api_access` | A special role that allows access to the REST API. See `plugins.security.restapi.roles_enabled` in `opensearch.yml` and [Access control for the API]({{site.url}}{{site.baseurl}}/security/access-control/api/#access-control-for-the-api). |
|
||||
| `reports_read_access` | Grants permissions to generate on-demand reports, download existing reports, and view report definitions but not to create report definitions. |
|
||||
| `reports_instances_read_access` | Grants permissions to generate on-demand reports and download existing reports but not to view or create report definitions. |
|
||||
| `reports_full_access` | Grants full permissions to reports. |
|
||||
| `asynchronous_search_full_access` | Grants full permissions to all asynchronous search actions. |
|
||||
| `asynchronous_search_read_access` | Grants permissions to view asynchronous searches but not to submit, modify, or delete them. |
|
||||
| `index_management_full_access` | Grants full permissions to all index management actions, including Index State Management (ISM), transforms, and rollups. |
|
||||
| `snapshot_management_full_access` | Grants full permissions to all snapshot management actions. |
|
||||
| `snapshot_management_read_access` | Grants permissions to view policies but not to create, modify, start, stop, or delete them. |
|
||||
| `point_in_time_full_access` | Grants full permissions to all Point in Time operations. |
|
||||
| `security_analytics_full_access` | Grants full permissions to all Security Analytics functionality. |
|
||||
| `security_analytics_read_access` | Grants permissions to view the various components in Security Analytics, such as detectors, alerts, and findings. It also includes permissions that allow users to search for detectors and rules. This role does not allow a user to perform actions such as modfying or deleting a detector. |
|
||||
| `security_analytics_ack_alerts` | Grants permissions to view and acknowledge alerts. |
|
||||
|
||||
For more detailed summaries of the permissions for each role, reference their action groups against the descriptions in [Default action groups]({{site.url}}{{site.baseurl}}/security/access-control/default-action-groups/).
|
||||
|
||||
|
||||
## Sample roles
|
||||
|
||||
The following examples show how you might set up a read-only and a bulk access role.
|
||||
|
||||
The following examples demonstrate how you might set up a read-only role and a bulk access role.
|
||||
|
||||
### Set up a read-only user in OpenSearch Dashboards
|
||||
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ Connected as CN=node-0.example.com,OU=SSL,O=Test,L=Test,C=DE
|
|||
ERR: CN=node-0.example.com,OU=SSL,O=Test,L=Test,C=DE is not an admin user
|
||||
```
|
||||
|
||||
You must use an admin certificate when executing the script. To learn more, see [Configure admin certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/#configuring-admin-certificates).
|
||||
You must use an admin certificate when executing the script. To learn more, see [Configuring admin certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/#configuring-admin-certificates).
|
||||
|
||||
## Use the diagnose option
|
||||
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ If you are migrating an Open Distro for Elasticsearch cluster, we recommend firs
|
|||
|
||||
## Upgrade tool
|
||||
|
||||
The `opensearch-upgrade` tool lets you automate some of the steps in [Migrate to OpenSearch](#migrate-to-opensearch), eliminating the need for error-prone manual operations.
|
||||
The `opensearch-upgrade` tool lets you automate some of the steps in [Migrate to OpenSearch]({{site.url}}{{site.baseurl}}/upgrade-to/upgrade-to/#migrate-to-opensearch), eliminating the need for error-prone manual operations.
|
||||
|
||||
The `opensearch-upgrade` tool performs the following functions:
|
||||
|
||||
|
|
@ -202,7 +202,8 @@ The `opensearch-upgrade` tool doesn't perform an end-to-end upgrade:
|
|||
|
||||
To perform a rolling upgrade using the [OpenSearch tarball]({{site.url}}{{site.baseurl}}/opensearch/install/tar/) distribution:
|
||||
|
||||
Check [Upgrade paths](#migration-paths) to make sure that the version you’re upgrading to is supported and whether you need to upgrade to a supported Elasticsearch OSS version first.
|
||||
Check [Migration paths]({{site.url}}{{site.baseurl}}/upgrade-to/upgrade-to/#migration-paths) to make sure that the version you’re upgrading to is supported and whether you need to upgrade to a supported Elasticsearch OSS version first.
|
||||
{: .note }
|
||||
|
||||
1. Disable shard allocation to prevent Elasticsearch OSS from replicating shards as you shut down nodes:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue