From 0b9f1973581ecfa81065ccaf06c9cacf1026b403 Mon Sep 17 00:00:00 2001 From: keithhc2 Date: Fri, 10 Sep 2021 11:57:30 -0700 Subject: [PATCH 1/3] Added security to ISM --- _im-plugin/ism/api.md | 2 +- _im-plugin/ism/security.md | 40 +++++++++++++++++++ .../access-control/users-roles.md | 2 + 3 files changed, 43 insertions(+), 1 deletion(-) create mode 100644 _im-plugin/ism/security.md diff --git a/_im-plugin/ism/api.md b/_im-plugin/ism/api.md index af139695..3f7e0d1c 100644 --- a/_im-plugin/ism/api.md +++ b/_im-plugin/ism/api.md @@ -2,7 +2,7 @@ layout: default title: ISM API parent: Index State Management -nav_order: 5 +nav_order: 20 --- # ISM API diff --git a/_im-plugin/ism/security.md b/_im-plugin/ism/security.md new file mode 100644 index 00000000..b996e319 --- /dev/null +++ b/_im-plugin/ism/security.md @@ -0,0 +1,40 @@ +--- +layout: default +title: ISM security +nav_order: 10 +parent: Index State Management +has_children: false +--- + +# ISM security + +Using the security plugin with index state management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies. + +All index state management data are protected as system indices, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security-plugin/configuration/system-indices). + +## Basic permissions + +The security plugin comes with two built-in roles that cover most ISM use cases: `ism_read_access` and `ism_full_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/users-roles#predefined-roles). + +With security enabled, users not only need the correct index management permissions, but they also need permissions to relevant indices to execute [REST API]({{site.url}}{{site.baseurl}}/im-plugin/ism/api) calls. For example, if a user wants to use the REST API to attach a policy to an index named `system-logs`, they would need the necessary REST API permissions as well as access to `system-logs`. + +## (Advanced) Limit access by backend role + +You can use backend roles to configure fine-grained access to ISM policies and actions. For example, users of different departments in an organization might view different policies depending on what roles and permissions they are assigned. + +First, ensure your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security-plugin/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security-plugin/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-plugin/access-control/api#create-user). + +Use the REST API to enable the following setting: + +```json +PUT _cluster/settings +{ + "transient": { + "plugins.index_management.filter_by_backend_roles": "true" + } +} +``` + +With security enabled, only users who share at least one backend role can see and execute the policies and actions relevant to their roles. + +For example, consider a scenario with three users: `John` and `Jill`, who have the backend role `helpdesk_staff`, and `Jane`, who has the backend role `phone_operator`. `John` wants to create a policy that performs a rollup job on an index named `airline_data`, so `John` would need a backend role that has permissions to access that index, create relevant policies, and execute relevant actions, and `Jill` would be able to access the same index, policy, and job. However, `Jane` cannot access or edit those resources or actions. diff --git a/_security-plugin/access-control/users-roles.md b/_security-plugin/access-control/users-roles.md index 445e1e63..1422d972 100644 --- a/_security-plugin/access-control/users-roles.md +++ b/_security-plugin/access-control/users-roles.md @@ -121,6 +121,8 @@ Role | Description `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. +`ism_read_access` | Grants users permissions to view policies and current index states, but they are unable to create, add, update, or remove policies. +`ism_full_access` | Grants full permissions to all ISM actions. 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-plugin/access-control/default-action-groups/). From a69440b2626e495f438468e1d064ed4821ccee40 Mon Sep 17 00:00:00 2001 From: keithhc2 Date: Wed, 15 Sep 2021 13:47:04 -0700 Subject: [PATCH 2/3] Addressed comments --- _im-plugin/ism/security.md | 40 ------------------ _im-plugin/refresh-analyzer/index.md | 2 +- _im-plugin/security.md | 41 +++++++++++++++++++ .../access-control/users-roles.md | 3 +- 4 files changed, 43 insertions(+), 43 deletions(-) delete mode 100644 _im-plugin/ism/security.md create mode 100644 _im-plugin/security.md diff --git a/_im-plugin/ism/security.md b/_im-plugin/ism/security.md deleted file mode 100644 index b996e319..00000000 --- a/_im-plugin/ism/security.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -layout: default -title: ISM security -nav_order: 10 -parent: Index State Management -has_children: false ---- - -# ISM security - -Using the security plugin with index state management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies. - -All index state management data are protected as system indices, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security-plugin/configuration/system-indices). - -## Basic permissions - -The security plugin comes with two built-in roles that cover most ISM use cases: `ism_read_access` and `ism_full_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/users-roles#predefined-roles). - -With security enabled, users not only need the correct index management permissions, but they also need permissions to relevant indices to execute [REST API]({{site.url}}{{site.baseurl}}/im-plugin/ism/api) calls. For example, if a user wants to use the REST API to attach a policy to an index named `system-logs`, they would need the necessary REST API permissions as well as access to `system-logs`. - -## (Advanced) Limit access by backend role - -You can use backend roles to configure fine-grained access to ISM policies and actions. For example, users of different departments in an organization might view different policies depending on what roles and permissions they are assigned. - -First, ensure your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security-plugin/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security-plugin/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-plugin/access-control/api#create-user). - -Use the REST API to enable the following setting: - -```json -PUT _cluster/settings -{ - "transient": { - "plugins.index_management.filter_by_backend_roles": "true" - } -} -``` - -With security enabled, only users who share at least one backend role can see and execute the policies and actions relevant to their roles. - -For example, consider a scenario with three users: `John` and `Jill`, who have the backend role `helpdesk_staff`, and `Jane`, who has the backend role `phone_operator`. `John` wants to create a policy that performs a rollup job on an index named `airline_data`, so `John` would need a backend role that has permissions to access that index, create relevant policies, and execute relevant actions, and `Jill` would be able to access the same index, policy, and job. However, `Jane` cannot access or edit those resources or actions. diff --git a/_im-plugin/refresh-analyzer/index.md b/_im-plugin/refresh-analyzer/index.md index d9beb9bb..641d3484 100644 --- a/_im-plugin/refresh-analyzer/index.md +++ b/_im-plugin/refresh-analyzer/index.md @@ -1,7 +1,7 @@ --- layout: default title: Refresh search analyzer -nav_order: 40 +nav_order: 50 has_children: false redirect_from: /im-plugin/refresh-analyzer/ has_toc: false diff --git a/_im-plugin/security.md b/_im-plugin/security.md new file mode 100644 index 00000000..2fa6d456 --- /dev/null +++ b/_im-plugin/security.md @@ -0,0 +1,41 @@ +--- +layout: default +title: Index management security +nav_order: 40 +has_children: false +--- + +# Index management security + +Using the security plugin with index management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies. + +All index management data are protected as system indices, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security-plugin/configuration/system-indices). + +## Basic permissions + +The security plugin comes with one role that offers full access to index management: `index_management_full_access`. For a description of the role's permissions, see [Predefined roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/users-roles#predefined-roles). + +With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indices. For example, if a user wants to use the REST API to attach a policy that executes a transform job to an index named `system-logs`, they would need the permissions to attach a policy and execute a transform job, as well as access to `system-logs`. + +Finally, with the exceptions of Create Policy, Get Policy, and Delete Policy, users also need the `indices:admin/opensearch/ism/managedindex` permission to execute [ISM APIs]({{site.url}}{{site.baseurl}}/im-plugin/ism/api). + +## (Advanced) Limit access by backend role + +You can use backend roles to configure fine-grained access to index management policies and actions. For example, users of different departments in an organization might view different policies depending on what roles and permissions they are assigned. + +First, ensure your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security-plugin/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security-plugin/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-plugin/access-control/api#create-user). + +Use the REST API to enable the following setting: + +```json +PUT _cluster/settings +{ + "transient": { + "plugins.index_management.filter_by_backend_roles": "true" + } +} +``` + +With security enabled, only users who share at least one backend role can see and execute the policies and actions relevant to their roles. + +For example, consider a scenario with three users: `John` and `Jill`, who have the backend role `helpdesk_staff`, and `Jane`, who has the backend role `phone_operator`. `John` wants to create a policy that performs a rollup job on an index named `airline_data`, so `John` would need a backend role that has permissions to access that index, create relevant policies, and execute relevant actions, and `Jill` would be able to access the same index, policy, and job. However, `Jane` cannot access or edit those resources or actions. diff --git a/_security-plugin/access-control/users-roles.md b/_security-plugin/access-control/users-roles.md index 1422d972..86424304 100644 --- a/_security-plugin/access-control/users-roles.md +++ b/_security-plugin/access-control/users-roles.md @@ -121,8 +121,7 @@ Role | Description `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. -`ism_read_access` | Grants users permissions to view policies and current index states, but they are unable to create, add, update, or remove policies. -`ism_full_access` | Grants full permissions to all ISM actions. +`index_management_full_access` | Grants full permissions to all index management actions, including ISM, transforms, and rollups. 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-plugin/access-control/default-action-groups/). From 538703d4227378c173565b5f30e5c56125eb9c3e Mon Sep 17 00:00:00 2001 From: keithhc2 Date: Fri, 17 Sep 2021 14:58:07 -0700 Subject: [PATCH 3/3] Changed transform to rollup --- _im-plugin/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_im-plugin/security.md b/_im-plugin/security.md index 2fa6d456..d5d48ac6 100644 --- a/_im-plugin/security.md +++ b/_im-plugin/security.md @@ -15,7 +15,7 @@ All index management data are protected as system indices, and only a super admi The security plugin comes with one role that offers full access to index management: `index_management_full_access`. For a description of the role's permissions, see [Predefined roles]({{site.url}}{{site.baseurl}}/security-plugin/access-control/users-roles#predefined-roles). -With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indices. For example, if a user wants to use the REST API to attach a policy that executes a transform job to an index named `system-logs`, they would need the permissions to attach a policy and execute a transform job, as well as access to `system-logs`. +With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indices. For example, if a user wants to use the REST API to attach a policy that executes a rollup job to an index named `system-logs`, they would need the permissions to attach a policy and execute a rollup job, as well as access to `system-logs`. Finally, with the exceptions of Create Policy, Get Policy, and Delete Policy, users also need the `indices:admin/opensearch/ism/managedindex` permission to execute [ISM APIs]({{site.url}}{{site.baseurl}}/im-plugin/ism/api).