Correcting legacy users, roles, and action groups
Manually porting over some older commits.
This commit is contained in:
aetter
parent
5eac369c2a
commit
a05cbc4d94
|
|
@ -10,7 +10,7 @@ has_math: true
|
|||
# Exact k-NN with Scoring Script
|
||||
The k-NN plugin implements the OpenSearch score script plugin that you can use to find the exact k-nearest neighbors to a given query point. Using the k-NN score script, you can apply a filter on an index before executing the nearest neighbor search. This is useful for dynamic search cases where the index body may vary based on other conditions. Because this approach executes a brute force search, it does not scale as well as the [Approximate approach](../approximate-knn). In some cases, it may be better to think about refactoring your workflow or index structure to use the Approximate approach instead of this approach.
|
||||
|
||||
## Getting started with the score script
|
||||
## Getting started with the score script for vectors
|
||||
|
||||
Similar to approximate nearest neighbor search, in order to use the score script on a body of vectors, you must first create an index with one or more `knn_vector` fields. If you intend to just use the script score approach (and not the approximate approach) `index.knn` can be set to `false` and `index.knn.space_type` does not need to be set. The space type can be chosen during search. See the [spaces section](#spaces) to see what spaces the k-NN score script suppports. Here is an example that creates an index with two `knn_vector` fields:
|
||||
|
||||
|
|
@ -32,8 +32,6 @@ PUT my-knn-index-1
|
|||
}
|
||||
```
|
||||
|
||||
*Note* -- For binary spaces, such as the Hamming bit space, `type` needs to be either `binary` or `long`. The binary data then needs to be encoded either as a base64 string or as a long (if the data is 64 bits or less).
|
||||
|
||||
If you *only* want to use the score script, you can omit `"index.knn": true`. The benefit of this approach is faster indexing speed and lower memory usage, but you lose the ability to perform standard k-NN queries on the index.
|
||||
{: .tip}
|
||||
|
||||
|
|
@ -98,7 +96,8 @@ All parameters are required.
|
|||
- `space_type` corresponds to the distance function. See the [spaces section](#spaces).
|
||||
|
||||
|
||||
*Note* -- In later versions of the k-NN plugin, `vector` was replaced by `query_value` due to the addition of the `bithamming` space.
|
||||
In later versions of the k-NN plugin, `vector` was replaced by `query_value` due to the addition of the `bithamming` space.
|
||||
{ .note }
|
||||
|
||||
|
||||
The [post filter example in the approximate approach](../approximate-knn/#using-approximate-k-nn-with-filters) shows a search that returns fewer than `k` results. If you want to avoid this situation, the score script method lets you essentially invert the order of events. In other words, you can filter down the set of documents you want to execute the k-nearest neighbor search over.
|
||||
|
|
@ -172,6 +171,110 @@ GET my-knn-index-2/_search
|
|||
}
|
||||
```
|
||||
|
||||
## Getting started with the score script for binary data
|
||||
The k-NN score script also allows you to run k-NN search on your binary data with the Hamming distance space.
|
||||
In order to use Hamming distance, the field of interest must have either a `binary` or `long` field type. If you're using `binary` type, the data must be a base64-encoded string.
|
||||
|
||||
This example shows how to use the Hamming distance space with a `binary` field type:
|
||||
|
||||
```json
|
||||
PUT my-index
|
||||
{
|
||||
"mappings": {
|
||||
"properties": {
|
||||
"my_binary": {
|
||||
"type": "binary",
|
||||
"doc_values": true
|
||||
},
|
||||
"color": {
|
||||
"type": "keyword"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Then add some documents:
|
||||
|
||||
```json
|
||||
POST _bulk
|
||||
{ "index": { "_index": "my-index", "_id": "1" } }
|
||||
{ "my_binary": "SGVsbG8gV29ybGQh", "color" : "RED" }
|
||||
{ "index": { "_index": "my-index", "_id": "2" } }
|
||||
{ "my_binary": "ay1OTiBjdXN0b20gc2NvcmluZyE=", "color" : "RED" }
|
||||
{ "index": { "_index": "my-index", "_id": "3" } }
|
||||
{ "my_binary": "V2VsY29tZSB0byBrLU5O", "color" : "RED" }
|
||||
{ "index": { "_index": "my-index", "_id": "4" } }
|
||||
{ "my_binary": "SSBob3BlIHRoaXMgaXMgaGVscGZ1bA==", "color" : "BLUE" }
|
||||
{ "index": { "_index": "my-index", "_id": "5" } }
|
||||
{ "my_binary": "QSBjb3VwbGUgbW9yZSBkb2NzLi4u", "color" : "BLUE" }
|
||||
{ "index": { "_index": "my-index", "_id": "6" } }
|
||||
{ "my_binary": "TGFzdCBvbmUh", "color" : "BLUE" }
|
||||
|
||||
```
|
||||
|
||||
Finally, use the `script_score` query to pre-filter your documents before identifying nearest neighbors:
|
||||
|
||||
```json
|
||||
GET my-index/_search
|
||||
{
|
||||
"size": 2,
|
||||
"query": {
|
||||
"script_score": {
|
||||
"query": {
|
||||
"bool": {
|
||||
"filter": {
|
||||
"term": {
|
||||
"color": "BLUE"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"script": {
|
||||
"lang": "knn",
|
||||
"source": "knn_score",
|
||||
"params": {
|
||||
"field": "my_binary",
|
||||
"query_value": "U29tZXRoaW5nIEltIGxvb2tpbmcgZm9y",
|
||||
"space_type": "hammingbit"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Similarly, you can encode your data with the `long` field and run a search:
|
||||
|
||||
```json
|
||||
GET my-long-index/_search
|
||||
{
|
||||
"size": 2,
|
||||
"query": {
|
||||
"script_score": {
|
||||
"query": {
|
||||
"bool": {
|
||||
"filter": {
|
||||
"term": {
|
||||
"color": "BLUE"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"script": {
|
||||
"lang": "knn",
|
||||
"source": "knn_score",
|
||||
"params": {
|
||||
"field": "my_long",
|
||||
"query_value": 23,
|
||||
"space_type": "hammingbit"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Spaces
|
||||
|
||||
A space corresponds to the function used to measure the distance between 2 points in order to determine the k-nearest neighbors. From the k-NN perspective, a lower score equates to a closer and better result. This is the opposite of how OpenSearch scores results, where a greater score equates to a better result. We include the conversions to OpenSearch scores in the table below:
|
||||
|
|
|
|||
|
|
@ -74,14 +74,14 @@ You can mark users, role, role mappings, and action groups as reserved. Resource
|
|||
To mark a resource as reserved, add the following flag:
|
||||
|
||||
```yml
|
||||
opensearch_dashboards_user:
|
||||
kibana_user:
|
||||
reserved: true
|
||||
```
|
||||
|
||||
Likewise, you can mark users, role, role mappings, and action groups as hidden. Resources that have this flag set to true are not returned by the REST API and not visible in OpenSearch Dashboards:
|
||||
|
||||
```yml
|
||||
opensearch_dashboards_user:
|
||||
kibana_user:
|
||||
hidden: true
|
||||
```
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ GET _opensearch/_security/api/actiongroups/<action-group>
|
|||
"reserved": false,
|
||||
"hidden": false,
|
||||
"allowed_actions": [
|
||||
"opensearch_dashboards_all_read",
|
||||
"kibana_all_read",
|
||||
"indices:admin/aliases/get",
|
||||
"indices:admin/aliases/exists"
|
||||
],
|
||||
|
|
@ -532,7 +532,7 @@ GET _opensearch/_security/api/roles/<role>
|
|||
"human_resources"
|
||||
],
|
||||
"allowed_actions": [
|
||||
"opensearch_dashboards_all_read"
|
||||
"kibana_all_read"
|
||||
]
|
||||
}],
|
||||
"static": false
|
||||
|
|
@ -628,7 +628,7 @@ PUT _opensearch/_security/api/roles/<role>
|
|||
"human_resources"
|
||||
],
|
||||
"allowed_actions": [
|
||||
"opensearch_dashboards_all_read"
|
||||
"kibana_all_read"
|
||||
]
|
||||
}]
|
||||
}
|
||||
|
|
@ -1040,7 +1040,7 @@ PUT _opensearch/_security/api/securityconfig/config
|
|||
"respect_request_indices_options": false,
|
||||
"opensearch-dashboards": {
|
||||
"multitenancy_enabled": true,
|
||||
"server_username": "opensearch-dashboardsserver",
|
||||
"server_username": "kibanaserver",
|
||||
"index": ".opensearch-dashboards"
|
||||
},
|
||||
"http": {
|
||||
|
|
@ -1138,7 +1138,7 @@ PUT _opensearch/_security/api/securityconfig/config
|
|||
"respect_request_indices_options": false,
|
||||
"opensearch-dashboards": {
|
||||
"multitenancy_enabled": true,
|
||||
"server_username": "opensearch-dashboardsserver",
|
||||
"server_username": "kibanaserver",
|
||||
"index": ".opensearch-dashboards"
|
||||
},
|
||||
"http": {
|
||||
|
|
|
|||
|
|
@ -16,6 +16,9 @@ This page catalogs all default action groups. Often, the most coherent way to cr
|
|||
Name | Description
|
||||
:--- | :---
|
||||
unlimited | Grants complete access. Can be used on an cluster- or index-level. Equates to `"*"`.
|
||||
{% comment %}kibana_all_read | asdf
|
||||
kibana_all_write | asdf{% endcomment %}
|
||||
|
||||
|
||||
|
||||
## Cluster-level
|
||||
|
|
@ -27,6 +30,8 @@ cluster_monitor | Grants all cluster monitoring permissions. Equates to `cluster
|
|||
cluster_composite_ops_ro | Grants read-only permissions to execute requests like `mget`, `msearch`, or `mtv`, plus permissions to query for aliases.
|
||||
cluster_composite_ops | Same as `CLUSTER_COMPOSITE_OPS_RO`, but also grants `bulk` permissions and all aliases permissions.
|
||||
manage_snapshots | Grants permissions to manage snapshots and repositories.
|
||||
cluster_manage_pipelines | Grants permissions to manage ingest pipelines.
|
||||
cluster_manage_index_templates | Grants permissions to manage index templates.
|
||||
|
||||
|
||||
## Index-level
|
||||
|
|
@ -36,12 +41,14 @@ Name | Description
|
|||
indices_all | Grants all permissions on the index. Equates to `indices:*`.
|
||||
get | Grants permissions to use `get` and `mget` actions only.
|
||||
read | Grants read permissions such as search, get field mappings, `get`, and `mget`.
|
||||
write | Grants permissions to create and update documents within *existing indices*. To create new indices, see `CREATE_INDEX`.
|
||||
write | Grants permissions to create and update documents within *existing indices*. To create new indices, see `create_index`.
|
||||
delete | Grants permissions to delete documents.
|
||||
crud | Combines the READ, WRITE and DELETE action groups.
|
||||
search | Grants permissions to search documents. Includes SUGGEST.
|
||||
suggest | Grants permissions to use the suggest API. Included in the READ action group.
|
||||
crud | Combines the `read`, `write`, and `delete` action groups. Included in the `data_access` action group.
|
||||
search | Grants permissions to search documents. Includes `suggest`.
|
||||
suggest | Grants permissions to use the suggest API. Included in the `read` action group.
|
||||
create_index | Grants permissions to create indices and mappings.
|
||||
indices_monitor | Grants permissions to execute all index monitoring actions (e.g. recovery, segments info, index stats, and status).
|
||||
index | A more limited version of the `write` action group.
|
||||
data_access | Combines the `crud` action group with `indices:data/*`.
|
||||
manage_aliases | Grants permissions to manage aliases.
|
||||
manage | Grants all monitoring and administration permissions for indices.
|
||||
|
|
|
|||
|
|
@ -23,6 +23,6 @@ Action group | A set of permissions. For example, the predefined `SEARCH` action
|
|||
Role | Security roles define the scope of a permission or action group: cluster, index, document, or field. For example, a role named `delivery_analyst` might have no cluster permissions, the `READ` action group for all indices that match the `delivery-data-*` pattern, access to all document types within those indices, and access to all fields except `delivery_driver_name`.
|
||||
Backend role | (Optional) Arbitrary strings that you specify *or* that come from an external authentication system (e.g. LDAP/Active Directory). Backend roles can help simplify the role mapping process. Rather than mapping a role to 100 individual users, you can map the role to a single backend role that all 100 users share.
|
||||
User | Users make requests to OpenSearch clusters. A user has credentials (e.g. a username and password), zero or more backend roles, and zero or more custom attributes.
|
||||
Role mapping | Users assume roles after they successfully authenticate. Role mappings, well, map roles to users (or backend roles). For example, a mapping of `opensearch_dashboards_user` (role) to `jdoe` (user) means that John Doe gains all the permissions of `opensearch_dashboards_user` after authenticating. Likewise, a mapping of `all_access` (role) to `admin` (backend role) means that any user with the backend role of `admin` gains all the permissions of `all_access` after authenticating. You can map each role to many users and/or backend roles.
|
||||
Role mapping | Users assume roles after they successfully authenticate. Role mappings, well, map roles to users (or backend roles). For example, a mapping of `kibana_user` (role) to `jdoe` (user) means that John Doe gains all the permissions of `kibana_user` after authenticating. Likewise, a mapping of `all_access` (role) to `admin` (backend role) means that any user with the backend role of `admin` gains all the permissions of `all_access` after authenticating. You can map each role to many users and/or backend roles.
|
||||
|
||||
The security plugin comes with a number of [predefined action groups](default-action-groups/), roles, mappings, and users. These entities serve as sensible defaults and are good examples of how to use the plugin.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ config:
|
|||
dynamic:
|
||||
opensearch-dashboards:
|
||||
multitenancy_enabled: true
|
||||
server_username: opensearch-dashboardsserver
|
||||
server_username: kibanaserver
|
||||
index: '.opensearch-dashboards'
|
||||
do_not_fail_on_forbidden: false
|
||||
```
|
||||
|
|
@ -38,15 +38,15 @@ config:
|
|||
Setting | Description
|
||||
:--- | :---
|
||||
`multitenancy_enabled` | Enable or disable multi-tenancy. Default is true.
|
||||
`server_username` | Must match the name of the OpenSearch Dashboards server user from `opensearch_dashboards.yml`. Default is `opensearch-dashboardsserver`.
|
||||
`server_username` | Must match the name of the OpenSearch Dashboards server user from `opensearch_dashboards.yml`. Default is `kibanaserver`.
|
||||
`index` | Must match the name of the OpenSearch Dashboards index from `opensearch_dashboards.yml`. Default is `.opensearch-dashboards`.
|
||||
`do_not_fail_on_forbidden` | If true, the security plugin removes any content that a user is not allowed to see from search results. If false, the plugin returns a security exception. Default is false.
|
||||
|
||||
`opensearch_dashboards.yml` has some additional settings:
|
||||
|
||||
```yml
|
||||
opensearch.username: opensearch-dashboardsserver
|
||||
opensearch.password: opensearch-dashboardsserver
|
||||
opensearch.username: kibanaserver
|
||||
opensearch.password: kibanaserver
|
||||
opensearch.requestHeadersWhitelist: ["securitytenant","Authorization"]
|
||||
opensearch_security.multitenancy.enabled: true
|
||||
opensearch_security.multitenancy.tenants.enable_global: true
|
||||
|
|
@ -101,8 +101,8 @@ admin_tenant:
|
|||
|
||||
After creating a tenant, give a role access to it using OpenSearch Dashboards, the REST API, or `roles.yml`.
|
||||
|
||||
- Read-write (`opensearch_dashboards_all_write`) permissions let the role view and modify objects in the tenant.
|
||||
- Read-only (`opensearch_dashboards_all_read`) permissions let the role view objects, but not modify them.
|
||||
- Read-write (`kibana_all_write`) permissions let the role view and modify objects in the tenant.
|
||||
- Read-only (`kibana_all_read`) permissions let the role view objects, but not modify them.
|
||||
|
||||
|
||||
#### OpenSearch Dashboards
|
||||
|
|
@ -139,7 +139,7 @@ test-role:
|
|||
- tenant_patterns:
|
||||
- "human_resources"
|
||||
allowed_actions:
|
||||
- "opensearch_dashboards_all_read"
|
||||
- "kibana_all_read"
|
||||
static: false
|
||||
_meta:
|
||||
type: "roles"
|
||||
|
|
|
|||
|
|
@ -110,8 +110,8 @@ Role | Description
|
|||
`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.
|
||||
`opensearch_dashboards_read_only` | A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects. See `opensearch_security.readonly_mode.roles` in `opensearch_dashboards.yml`. Pair with the `opensearch_dashboards_user` role.
|
||||
`opensearch_dashboards_user` | Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indices.
|
||||
`kibana_read_only` | A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects. See `opensearch_security.readonly_mode.roles` in `opensearch_dashboards.yml`. Pair with the `kibana_user` role.
|
||||
`kibana_user` | Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indices.
|
||||
`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.
|
||||
|
|
@ -149,7 +149,7 @@ Map three roles to the read-only user:
|
|||
1. Choose the **Mapped users** tab and **Manage mapping**.
|
||||
1. For **Internal users**, add your read-only user.
|
||||
1. Choose **Map**.
|
||||
1. Repeat these steps for the `opensearch_dashboards_user` and `opensearch_dashboards_read_only` roles.
|
||||
1. Repeat these steps for the `kibana_user` and `kibana_read_only` roles.
|
||||
|
||||
|
||||
### Set up a bulk access role in OpenSearch Dashboards
|
||||
|
|
|
|||
|
|
@ -144,11 +144,11 @@ opensearch_security.audit.ignore_requests: ["indices:data/read/*", "SearchReques
|
|||
|
||||
## Exclude users
|
||||
|
||||
By default, the security plugin logs events from all users, but excludes the internal OpenSearch Dashboards server user `opensearch-dashboardsserver`. You can exclude other users:
|
||||
By default, the security plugin logs events from all users, but excludes the internal OpenSearch Dashboards server user `kibanaserver`. You can exclude other users:
|
||||
|
||||
```yml
|
||||
opensearch_security.audit.ignore_users:
|
||||
- opensearch-dashboardsserver
|
||||
- kibanaserver
|
||||
- admin
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -24,4 +24,4 @@ Understanding the authentication flow is a great way to get started with configu
|
|||
|
||||
If the role mapping doesn't include the user (or the user's backend roles), the user is successfully authenticated, but has no permissions.
|
||||
|
||||
5. The user can now perform actions as defined by the mapped security roles. For example, a user might map to the `opensearch_dashboards_user` role and thus have permissions to access OpenSearch Dashboards.
|
||||
5. The user can now perform actions as defined by the mapped security roles. For example, a user might map to the `kibana_user` role and thus have permissions to access OpenSearch Dashboards.
|
||||
|
|
|
|||
|
|
@ -29,14 +29,6 @@ The security plugin is actually two plugins: one for OpenSearch and one for Open
|
|||
If you disable the security plugin in `opensearch.yml` (or delete the plugin entirely) and still want to use OpenSearch Dashboards, you must remove the corresponding OpenSearch Dashboards plugin. For more information, see [Standalone OpenSearch Dashboards plugin install](../../../opensearch-dashboards/plugins/).
|
||||
|
||||
|
||||
### RPM or DEB
|
||||
|
||||
1. Remove all `opensearch_security` lines from `opensearch_dashboards.yml`.
|
||||
1. Change `opensearch.url` in `opensearch_dashboards.yml` to `http://` rather than `https://`.
|
||||
1. Enter `sudo /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin remove opensearchSecurityOpenSearch Dashboards`.
|
||||
1. Enter `sudo systemctl restart opensearch-dashboards.service`.
|
||||
|
||||
|
||||
### Docker
|
||||
|
||||
1. Create a new `Dockerfile`:
|
||||
|
|
@ -47,7 +39,7 @@ If you disable the security plugin in `opensearch.yml` (or delete the plugin ent
|
|||
COPY --chown=opensearch-dashboards:opensearch-dashboards opensearch_dashboards.yml /usr/share/opensearch-dashboards/config/
|
||||
```
|
||||
|
||||
In this case, `opensearch_dashboards.yml` is a "vanilla" version of the file with no OpenSearch entries. It might look like this:
|
||||
In this case, `opensearch_dashboards.yml` is a "vanilla" version of the file with no entries for the security plugin. It might look like this:
|
||||
|
||||
```yml
|
||||
---
|
||||
|
|
@ -64,6 +56,5 @@ If you disable the security plugin in `opensearch.yml` (or delete the plugin ent
|
|||
```
|
||||
|
||||
1. In `docker-compose.yml`, change `opensearch/opensearch-dashboards:{{site.opensearch_version}}` to `opensearch-dashboards-no-security`.
|
||||
1. Change `OPENSEARCH_URL` (`docker-compose.yml`) or `opensearch.url` (your custom `opensearch_dashboards.yml`) to `http://` rather than `https://`.
|
||||
1. Change `OPENSEARCH_HOSTS` or `opensearch.hosts` to `http://` rather than `https://`.
|
||||
1. Enter `docker-compose up`.
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ We provide a fully functional example that can help you understand how to use an
|
|||
|
||||
* `roles_mapping.yml` maps the `Administrator` and `Developers` LDAP groups (as backend roles) to security roles so that users gain the appropriate permissions after authenticating.
|
||||
|
||||
* `internal_users.yml` removes all default users except `administrator` and `opensearch-dashboardsserver`.
|
||||
* `internal_users.yml` removes all default users except `administrator` and `kibanaserver`.
|
||||
|
||||
* `config.yml` includes all necessary LDAP settings.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ We provide a fully functional example that can help you understand how to use an
|
|||
curl -XPUT https://localhost:9200/new-index/_doc/1 -H 'Content-Type: application/json' -d '{"title": "Spirited Away"}' -u psantos:password -k
|
||||
```
|
||||
|
||||
If you try the same request as `jroe`, it fails. The `Developers` group is mapped to the `readall`, `manage_snapshots`, and `opensearch_dashboards_user` roles and has no write permissions.
|
||||
If you try the same request as `jroe`, it fails. The `Developers` group is mapped to the `readall`, `manage_snapshots`, and `kibana_user` roles and has no write permissions.
|
||||
|
||||
1. Search for the document as `jroe`:
|
||||
|
||||
|
|
@ -469,7 +469,7 @@ In this case, it makes sense to exclude the OpenSearch Dashboards server user fr
|
|||
|
||||
```yml
|
||||
skip_users:
|
||||
- opensearch-dashboardsserver
|
||||
- kibanaserver
|
||||
- 'cn=Jane Doe,ou*people,o=TEST'
|
||||
- '/\S*/'
|
||||
```
|
||||
|
|
@ -536,7 +536,7 @@ authz:
|
|||
rolename: cn
|
||||
resolve_nested_roles: true
|
||||
skip_users:
|
||||
- opensearch-dashboardsserver
|
||||
- kibanaserver
|
||||
- 'cn=Jane Doe,ou*people,o=TEST'
|
||||
- '/\S*/'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -294,8 +294,8 @@ opensearch_security.openid.client_secret: "a59c51f5-f052-4740-a3b0-e14ba355b520"
|
|||
opensearch.url: "https://<hostname>.com:<http port>"
|
||||
|
||||
# Configure the OpenSearch Dashboards internal server user
|
||||
opensearch.username: "opensearch-dashboardsserver"
|
||||
opensearch.password: "opensearch-dashboardsserver"
|
||||
opensearch.username: "kibanaserver"
|
||||
opensearch.password: "kibanaserver"
|
||||
|
||||
# Disable SSL verification when using self-signed demo certificates
|
||||
opensearch.ssl.verificationMode: none
|
||||
|
|
|
|||
|
|
@ -113,11 +113,11 @@ Name | Description
|
|||
|
||||
## OpenSearch Dashboards settings
|
||||
|
||||
The Web Browser SSO Profile exchanges information through HTTP GET or POST. For example, after you log in to your IdP, it sends an HTTP POST back to OpenSearch Dashboards containing the SAML response. You must configure the base URL of your OpenSearch Dashboards installation where the HTTP requests are being sent to.
|
||||
The web browser SSO profile exchanges information through HTTP GET or POST. For example, after you log in to your IdP, it sends an HTTP POST back to OpenSearch Dashboards containing the SAML response. You must configure the base URL of your OpenSearch Dashboards installation where the HTTP requests are being sent to.
|
||||
|
||||
Name | Description
|
||||
:--- | :---
|
||||
`opensearch_dashboards_url` | The OpenSearch Dashboards base URL. Required.
|
||||
`kibana_url` | The OpenSearch Dashboards base URL. Required.
|
||||
|
||||
|
||||
## Username and Role attributes
|
||||
|
|
@ -290,7 +290,7 @@ authc:
|
|||
entity_id: http://idp.example.com/
|
||||
sp:
|
||||
entity_id: https://opensearch-dashboards.example.com
|
||||
opensearch_dashboards_url: https://opensearch-dashboards.example.com:5601/
|
||||
kibana_url: https://opensearch-dashboards.example.com:5601/
|
||||
roles_key: Role
|
||||
exchange_key: 'peuvgOLrjzuhXf ...'
|
||||
authentication_backend:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ nav_order: 3
|
|||
|
||||
Before running `securityadmin.sh` to load the settings into the `.opensearch_security` index, configure the YAML files in `plugins/opensearch-security/securityconfig`. You might want to back up these files so that you can reuse them on other clusters.
|
||||
|
||||
The best use of these YAML files is to configure [reserved and hidden resources](../../access-control/api/#reserved-and-hidden-resources), such as the `admin` and `opensearch-dashboardsserver` users. You might find it easier to create other users, roles, mappings, action groups, and tenants using OpenSearch Dashboards or the REST API.
|
||||
The best use of these YAML files is to configure [reserved and hidden resources](../../access-control/api/#reserved-and-hidden-resources), such as the `admin` and `kibanaserver` users. You might find it easier to create other users, roles, mappings, action groups, and tenants using OpenSearch Dashboards or the REST API.
|
||||
|
||||
|
||||
## internal_users.yml
|
||||
|
|
@ -50,22 +50,22 @@ admin:
|
|||
- "admin"
|
||||
description: "Demo admin user"
|
||||
|
||||
opensearch-dashboardsserver:
|
||||
kibanaserver:
|
||||
hash: "$2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H."
|
||||
reserved: true
|
||||
description: "Demo opensearch-dashboardsserver user"
|
||||
description: "Demo user for the OpenSearch Dashboards server"
|
||||
|
||||
opensearch-dashboardsro:
|
||||
kibanaro:
|
||||
hash: "$2a$12$JJSXNfTowz7Uu5ttXfeYpeYE0arACvcwlPBStB1F.MI7f0U9Z4DGC"
|
||||
reserved: false
|
||||
backend_roles:
|
||||
- "opensearch-dashboardsuser"
|
||||
- "kibanauser"
|
||||
- "readall"
|
||||
attributes:
|
||||
attribute1: "value1"
|
||||
attribute2: "value2"
|
||||
attribute3: "value3"
|
||||
description: "Demo opensearch-dashboardsro user"
|
||||
description: "Demo read-only user for OpenSearch dashboards"
|
||||
|
||||
logstash:
|
||||
hash: "$2a$12$u1ShR4l4uBS3Uv59Pa2y5.1uQuZBrZtmNfqB3iM/.jL0XoV9sghS2"
|
||||
|
|
@ -117,7 +117,7 @@ complex-role:
|
|||
- tenant_patterns:
|
||||
- "analyst_*"
|
||||
allowed_actions:
|
||||
- "opensearch_dashboards_all_write"
|
||||
- "kibana_all_write"
|
||||
static: false
|
||||
_meta:
|
||||
type: "roles"
|
||||
|
|
@ -154,15 +154,15 @@ own_index:
|
|||
- "*"
|
||||
and_backend_roles: []
|
||||
description: "Allow full access to an index named like the username"
|
||||
opensearch_dashboards_user:
|
||||
kibana_user:
|
||||
reserved: false
|
||||
hidden: false
|
||||
backend_roles:
|
||||
- "opensearch-dashboardsuser"
|
||||
- "kibanauser"
|
||||
hosts: []
|
||||
users: []
|
||||
and_backend_roles: []
|
||||
description: "Maps opensearch-dashboardsuser to opensearch_dashboards_user"
|
||||
description: "Maps kibanauser to kibana_user"
|
||||
complex-role:
|
||||
reserved: false
|
||||
hidden: false
|
||||
|
|
@ -192,13 +192,13 @@ readall:
|
|||
hosts: []
|
||||
users: []
|
||||
and_backend_roles: []
|
||||
opensearch_dashboards_server:
|
||||
kibana_server:
|
||||
reserved: true
|
||||
hidden: false
|
||||
backend_roles: []
|
||||
hosts: []
|
||||
users:
|
||||
- "opensearch-dashboardsserver"
|
||||
- "kibanaserver"
|
||||
and_backend_roles: []
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,9 @@ has_toc: false
|
|||
|
||||
OpenSearch has its own security plugin for authentication and access control. The plugin provides numerous features to help you secure your cluster.
|
||||
|
||||
The security plugin contains several default users, roles, action groups, and permissions that use `kibana` in their names. We will change these names in a future release.
|
||||
{ .note }
|
||||
|
||||
Feature | Description
|
||||
:--- | :---
|
||||
Node-to-node encryption | Encrypts traffic between nodes in the OpenSearch cluster.
|
||||
|
|
|
|||
4
index.md
4
index.md
|
|
@ -8,7 +8,7 @@ permalink: /
|
|||
|
||||
# OpenSearch documentation
|
||||
|
||||
This site contains the technical documentation for [OpenSearch](https://opensearch.org/), the search, analytics, and visualization suite with advanced security, alerting, SQL support, automated index management, deep performance analysis, and more.
|
||||
This site contains the technical documentation for [OpenSearch](https://opensearch.org/), the Apache 2.0-licensed search, analytics, and visualization suite with advanced security, alerting, SQL support, automated index management, deep performance analysis, and more.
|
||||
|
||||
[Get started](#docker-quickstart){: .btn .btn-blue }
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ Component | Purpose
|
|||
[Anomaly Detection](docs/ad/) | Identify atypical data and receive automatic notifications
|
||||
[Asynchronous Search](docs/async/) | Run search requests in the background
|
||||
|
||||
You can install OpenSearch plugins [individually](docs/install/plugins/) on existing clusters or use the [all-in-one packages](docs/install/) for new clusters. Most of these OpenSearch plugins have corresponding OpenSearch Dashboards plugins that provide a convenient, unified user interface.
|
||||
You can install OpenSearch plugins [individually](docs/install/plugins/) or use the [all-in-one packages](docs/install/). Most of these OpenSearch plugins have corresponding OpenSearch Dashboards plugins that provide a convenient, unified user interface.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue