From 2da97978d42111c947714d2749a5ee5d94b311f8 Mon Sep 17 00:00:00 2001
From: keithhc2 <keithhc2@users.noreply.github.com>
Date: Tue, 18 Jan 2022 15:18:20 -0800
Subject: [PATCH 1/5] Added note about monitors

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
---
 _monitoring-plugins/alerting/security.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/_monitoring-plugins/alerting/security.md b/_monitoring-plugins/alerting/security.md
index 5e5dfa74..e07bbb46 100644
--- a/_monitoring-plugins/alerting/security.md
+++ b/_monitoring-plugins/alerting/security.md
@@ -31,6 +31,8 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
 
 After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
 
+Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting.
+{: .note}
 
 ## (Advanced) Limit access by backend role
 
@@ -55,7 +57,6 @@ Now when users view alerting resources in OpenSearch Dashboards (or make REST AP
 
 If `jdoe` creates a monitor, `jroe` can see and modify it, but `psantos` can't. If that monitor generates an alert, the situation is the same: `jroe` can see and acknowledge it, but `psantos` can't. If `psantos` creates a destination, `jdoe` and `jroe` can't see or modify it.
 
-
 <!-- ## (Advanced) Limit access by individual
 
 If you only want users to be able to see and modify their own monitors and destinations, duplicate the `alerting_full_access` role and add the following [DLS query]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) to it:

From d5cebf02e3c00d2dcb0293735c6efe8a0c877b38 Mon Sep 17 00:00:00 2001
From: keithhc2 <keithhc2@users.noreply.github.com>
Date: Tue, 18 Jan 2022 15:33:18 -0800
Subject: [PATCH 2/5] Addressed comments

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
---
 _monitoring-plugins/alerting/security.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_monitoring-plugins/alerting/security.md b/_monitoring-plugins/alerting/security.md
index e07bbb46..12f777b6 100644
--- a/_monitoring-plugins/alerting/security.md
+++ b/_monitoring-plugins/alerting/security.md
@@ -31,7 +31,7 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
 
 After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
 
-Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting.
+Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting. If your monitor's trigger has alerts configured, the Alerting plugin continues to send out alerts unless the trigger's action is manually deleted.
 {: .note}
 
 ## (Advanced) Limit access by backend role

From 802e16db9382269e8a5bc15f24ff4360ce140671 Mon Sep 17 00:00:00 2001
From: keithhc2 <keithhc2@users.noreply.github.com>
Date: Tue, 18 Jan 2022 15:50:58 -0800
Subject: [PATCH 3/5] Clarified alerts a bit

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
---
 _monitoring-plugins/alerting/security.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/_monitoring-plugins/alerting/security.md b/_monitoring-plugins/alerting/security.md
index 12f777b6..24242055 100644
--- a/_monitoring-plugins/alerting/security.md
+++ b/_monitoring-plugins/alerting/security.md
@@ -31,8 +31,9 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
 
 After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
 
-Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting. If your monitor's trigger has alerts configured, the Alerting plugin continues to send out alerts unless the trigger's action is manually deleted.
-{: .note}
+Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting.
+
+If your monitor's trigger has alerts configured, the Alerting plugin continues to send out alerts regardless of destination type. To stop alerts, the trigger's action must be manually deleted or disabled.
 
 ## (Advanced) Limit access by backend role
 

From 7908f58598f7dbee1f355ecf9d6d8785dade638d Mon Sep 17 00:00:00 2001
From: keithhc2 <keithhc2@users.noreply.github.com>
Date: Tue, 18 Jan 2022 16:41:51 -0800
Subject: [PATCH 4/5] Language tweaks

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
---
 _monitoring-plugins/alerting/security.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_monitoring-plugins/alerting/security.md b/_monitoring-plugins/alerting/security.md
index 24242055..659b1e52 100644
--- a/_monitoring-plugins/alerting/security.md
+++ b/_monitoring-plugins/alerting/security.md
@@ -31,9 +31,9 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
 
 After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
 
-Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting.
+Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has permissions removed. To stop a monitor, a user with the correct cluster permissions must manually disable or delete the monitor. To disable a monitor, the user must have `cluster:admin/opendistro/alerting/monitor/write`, and to delete a monitor, the user must have `cluster:admin/opendistro/alerting/monitor/delete`. This rule applies to all types of monitors.
 
-If your monitor's trigger has alerts configured, the Alerting plugin continues to send out alerts regardless of destination type. To stop alerts, the trigger's action must be manually deleted or disabled.
+If your monitor's trigger has notifications configured, the Alerting plugin continues to send out notifications regardless of destination type. To stop notifications, a user must manually delete them in the trigger's actions.
 
 ## (Advanced) Limit access by backend role
 

From b0af3912156877c7d85383e2d29d16a357f62852 Mon Sep 17 00:00:00 2001
From: keithhc2 <keithhc2@users.noreply.github.com>
Date: Tue, 8 Feb 2022 11:53:23 -0800
Subject: [PATCH 5/5] Language tweaks

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
---
 _monitoring-plugins/alerting/security.md | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/_monitoring-plugins/alerting/security.md b/_monitoring-plugins/alerting/security.md
index 659b1e52..c934c45d 100644
--- a/_monitoring-plugins/alerting/security.md
+++ b/_monitoring-plugins/alerting/security.md
@@ -31,7 +31,10 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
 
 After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
 
-Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has permissions removed. To stop a monitor, a user with the correct cluster permissions must manually disable or delete the monitor. To disable a monitor, the user must have `cluster:admin/opendistro/alerting/monitor/write`, and to delete a monitor, the user must have `cluster:admin/opendistro/alerting/monitor/delete`. This rule applies to all types of monitors.
+Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has their permissions removed. Only a user with the correct cluster permissions can manually disable or delete a monitor to stop it from executing:
+
+- Disable a monitor: `cluster:admin/opendistro/alerting/monitor/write`
+- Delete a monitor: `cluster:admin/opendistro/alerting/monitor/delete`
 
 If your monitor's trigger has notifications configured, the Alerting plugin continues to send out notifications regardless of destination type. To stop notifications, a user must manually delete them in the trigger's actions.