Skip to content

Commit

Permalink
Merge branch 'main' into automerge.yml
Browse files Browse the repository at this point in the history
  • Loading branch information
Naarcha-AWS authored Mar 28, 2024
2 parents bda2db9 + 6f8261b commit ca9ce89
Show file tree
Hide file tree
Showing 3 changed files with 62 additions and 25 deletions.
3 changes: 2 additions & 1 deletion _api-reference/document-apis/reindex.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,10 +73,11 @@ slice | Whether to manually or automatically slice the reindex operation so it e
_source | Whether to reindex source fields. Specify a list of fields to reindex or true to reindex all fields. Default is true.
id | The ID to associate with manual slicing.
max | Maximum number of slices.
dest | Information about the destination index. Valid values are `index`, `version_type`, and `op_type`.
dest | Information about the destination index. Valid values are `index`, `version_type`, `op_type`, and `pipeline`.
index | Name of the destination index.
version_type | The indexing operation's version type. Valid values are `internal`, `external`, `external_gt` (retrieve the document if the specified version number is greater than the document’s current version), and `external_gte` (retrieve the document if the specified version number is greater or equal to than the document’s current version).
op_type | Whether to copy over documents that are missing in the destination index. Valid values are `create` (ignore documents with the same ID from the source index) and `index` (copy everything from the source index).
pipeline | Which ingest pipeline to utilize during the reindex.
script | A script that OpenSearch uses to apply transformations to the data during the reindex operation.
source | The actual script that OpenSearch runs.
lang | The scripting language. Valid options are `painless`, `expression`, `mustache`, and `java`.
Expand Down
49 changes: 25 additions & 24 deletions _security/access-control/document-level-security.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,30 +10,31 @@ redirect_from:

# Document-level security (DLS)

Document-level security lets you restrict a role to a subset of documents in an index. The easiest way to get started with document- and field-level security is to open OpenSearch Dashboards and choose **Security**. Then choose **Roles**, create a new role, and review the **Index permissions** section.

![Document- and field-level security screen in OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/images/security-dls.png)


## Simple roles

Document-level security uses the OpenSearch query DSL to define which documents a role grants access to. In OpenSearch Dashboards, choose an index pattern and provide a query in the **Document level security** section:

```json
{
"bool": {
"must": {
"match": {
"genres": "Comedy"
}
}
}
}
```

This query specifies that for the role to have access to a document, its `genres` field must include `Comedy`.

A typical request to the `_search` API includes `{ "query": { ... } }` around the query, but in this case, you only need to specify the query itself.
Document-level security lets you restrict a role to a subset of documents in an index.
For more information about OpenSearch users and roles, see the [documentation](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles).

Use the following steps to get started with document-level and field-level security:
1. Open OpenSearch Dashboards.
2. Choose **Security** > **Roles**.
3. Select **Create Role** and provide a name for the role.
4. Review the **Index permissions** section and any necessary [index permissions](https://opensearch.org/docs/latest/security/access-control/permissions/) for the role.
5. Add document-level security, with the addition of a domain-specific language (DSL) query in the `Document level security - optional` section. A typical request sent to the `_search` API includes `{ "query": { ... } }` around the query, but with document-level security in OpenSearch Dashboards, you only need to specify the query itself. For example, the following DSL query specifies that for the new role to have access to a document, the query's `genres` field must include `Comedy`:

```json
{
"bool": {
"must": {
"match": {
"genres": "Comedy"
}
}
}
}
```

- ![Document- and field-level security screen in OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/images/security-dls.png)

## Updating roles by accessing the REST API

In the REST API, you provide the query as a string, so you must escape your quotes. This role allows a user to read any document in any index with the field `public` set to `true`:

Expand Down
35 changes: 35 additions & 0 deletions _security/access-control/users-roles.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,23 @@ The Security plugin includes an internal user database. Use this database in pla

Roles are the core way of controlling access to your cluster. Roles contain any combination of cluster-wide permissions, index-specific permissions, document- and field-level security, and tenants. Then you map users to these roles so that users gain those permissions.

## Creating and editing OpenSearch roles

You can update OpenSearch by using one of the following methods.

### Using the API

You can send HTTP requests to OpenSearch-provided endpoints to update security roles, permissions, and associated settings. This method offers granular control and automation capabilities for managing roles.

### Using the UI (OpenSearch Dashboards)

OpenSearch Dashboards provides a user-friendly interface for managing roles. Roles, permissions, and document-level security settings are configured in the Security section within OpenSearch Dashboards. When updating roles through the UI, OpenSearch Dashboards calls the API in the background to implement the changes.

### Editing the `roles.yml` file

If you want more granular control of your security configuration, you can edit roles and their associated permissions in the `roles.yml` file. This method provides direct access to the underlying configuration and can be version controlled for use in collaborative development environments.
For more information about creating roles, see the [Create roles][https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles) documentation.

Unless you need to create new [reserved or hidden users]({{site.url}}{{site.baseurl}}/security/access-control/api/#reserved-and-hidden-resources), we **highly** recommend using OpenSearch Dashboards or the REST API to create new users, roles, and role mappings. The `.yml` files are for initial setup, not ongoing use.
{: .warning }

Expand Down Expand Up @@ -75,6 +92,24 @@ See [YAML files]({{site.url}}{{site.baseurl}}/security/configuration/yaml/#roles

See [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api/#create-role).

## Edit roles

You can edit roles using one of the following methods.

### OpenSearch Dashboards

1. Choose **Security** > **Roles**. In the **Create role** section, select **Explore existing roles**.
1. Select the role you want to edit.
1. Choose **edit role**. Make any necessary updates to the role.
1. To save your changes, select **Update**.

### roles.yml

See [YAML files]({{site.url}}{{site.baseurl}}/security/configuration/yaml/#rolesyml).

### REST API

See [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api/#create-role).

## Map users to roles

Expand Down

0 comments on commit ca9ce89

Please sign in to comment.