Merge branch 'main' into receipts-vs-invoices

Author: shainaraskas

deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md

@@ -39,8 +39,11 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ## Prerequisites [ec_prerequisites_3]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 * Have permissions on AWS KMS to [create a symmetric AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks) and to configure AWS IAM roles.
 
   :::{tip}
@@ -51,6 +54,8 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 * Have the following permissions on Azure:
 
     * Permissions to [create an RSA key](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#key-types-and-protection-methods) in the Azure Key Vault where you want to store your key.
@@ -67,6 +72,8 @@ When a deployment encrypted with a customer-managed key is deleted or terminated
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 * Consider the cloud regions where you need your deployment to live. Refer to the [list of available regions, deployment templates, and instance configurations](cloud://reference/cloud-hosted/ec-regions-templates-instances.md) supported by {{ecloud}}.
 * Have the following permissions in Google Cloud KMS:
 
@@ -93,8 +100,11 @@ At this time, the following features are not supported:
 ## Create an encryption key for your deployment [create-encryption-key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 1. Create a symmetric [single-region key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) or [multi-region replica key](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-replicate.html). The key must be available in each region in which you have deployments to encrypt. You can use the same key to encrypt multiple deployments. Later, you will need to provide the Amazon Resource Name (ARN) of that key or key alias to {{ecloud}}.
 
     ::::{note}
@@ -135,6 +145,8 @@ At this time, the following features are not supported:
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 1. Create an RSA key in your Key Vault. The key must be available in each region in which you have deployments to encrypt. You can use the same key to encrypt multiple deployments.
 2. After the key is created, view the key and note the key identifier. It should look similar to the following:
 
@@ -150,6 +162,8 @@ Provide your key identifier without the key version identifier so {{ecloud}} can
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 1. [Create a new symmetric key](https://cloud.google.com/kms/docs/create-key) in Google Cloud KMS.
 
     The key must be in a key ring that’s in the same region as your deployment. Do not use key ring in a multi-region location.
@@ -166,8 +180,11 @@ Provide your key identifier without the key version identifier so {{ecloud}} can
 ## Create a deployment encrypted with your key [ec_create_a_deployment_encrypted_with_your_key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 1. Create a new deployment. You can do it from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body), or from the API:
 
     * from the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body):
@@ -211,6 +228,8 @@ The deployment is now created and encrypted using the specified key. Future snap
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 To create a new deployment with a customer-managed key in Azure, you need to perform actions in {{ecloud}} and in your Azure tenant.
 
 **Step 1: Create a service principal for {{ecloud}}**
@@ -285,6 +304,8 @@ The deployment is now created and encrypted using the specified key. Future snap
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 **Step 1: Grant service principals access to your key**
 
 {{ecloud}} uses two service principals to encrypt and decrypt data using your key. You must grant these services access to your key before you create your deployment.
@@ -313,9 +334,19 @@ The deployment is now created and encrypted using the specified key. Future snap
         * `cloudkms.cryptoKeyVersions.useToEncrypt`
 
 
-::::{tip}
-The user performing this action needs to belong to the **Owner** or **Cloud KMS Admin** role.
-::::
+    The user performing this action needs to belong to the **Owner** or **Cloud KMS Admin** role.
+
+
+    ::::{note}
+    If [domain restricted sharing](https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains) is enabled, then you might not be able to grant the service principals access to the key resource directly. Alternatively, you can grant access to a Google group that contains the relevant service accounts.
+
+    1. Create a new Google group within the allowed domain.
+    2. In the Google Workspace administrator panel, [turn off domain restriction for your newly created Google group](https://support.google.com/a/answer/167097).
+    3. Add the service principals to the Google group.
+    4. Grant the Google group the roles as listed.
+    
+    If you can't use Google Groups for your org, then [contact Elastic Support](https://www.elastic.co/support) for alternatives. 
+    ::::
 
 
 **Step 2: Create your deployment**
@@ -370,14 +401,19 @@ You can check that your hosted deployment is correctly encrypted with the key yo
 ## Rotate a customer-managed key [rotate-a-customer-managed-key]
 
 :::::::{tab-set}
+:group: csps
 
 ::::::{tab-item} AWS
+:sync: aws
+
 {{ecloud}} will automatically rotate the keys every 31 days as a security best practice.
 
 You can also trigger a manual rotation [in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html), which will take effect in {{ecloud}} within 30 minutes. **For manual rotations to work, you must use an alias when creating the deployment. We do not currently support [on-demand rotations](https://docs.aws.amazon.com/kms/latest/APIReference/API_RotateKeyOnDemand.html) but plan on supporting this in the future.**
 ::::::
 
 ::::::{tab-item} Azure
+:sync: azure
+
 To rotate your key, you can [update your key version](https://learn.microsoft.com/en-us/azure/container-registry/tutorial-rotate-revoke-customer-managed-keys) or [configure a key rotation policy](https://learn.microsoft.com/en-us/azure/key-vault/keys/how-to-configure-key-rotation) in Azure Key Vault. In both cases, the rotation will take effect in {{ecloud}} within a day.
 
 For rotations to work, you must provide your key identifier without the key version identifier when you create your deployment.
@@ -386,6 +422,8 @@ For rotations to work, you must provide your key identifier without the key vers
 ::::::
 
 ::::::{tab-item} Google Cloud
+:sync: gcp
+
 Key rotations are triggered in Google Cloud. You can rotate your key [manually](https://cloud.google.com/kms/docs/rotate-key#manual) or [automatically](https://cloud.google.com/kms/docs/rotate-key#automatic). In both cases, the rotation will take effect in {{ecloud}} within a day.
 ::::::
 

explore-analyze/alerts-cases/alerts/view-alerts.md

@@ -47,24 +47,38 @@ To get more information about a specific alert, open its action menu (…) and s
 
 If an alert is affected by a maintenance window, the alert details include its identifier. For more information about their impact on alert notifications, refer to [*Maintenance windows*](maintenance-windows.md).
 
-### Alert statuses [alert-status]
+## Alert statuses [alert-status]
 
-There are three common alert statuses:
+There are four common alert statuses:
 
 `active`
-:   The conditions for the rule are met and actions should be generated according to the notification settings.
+:   The conditions for the rule are met. If the rule has [actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. 
 
-`recovered`
-:   The conditions for the rule are no longer met and recovery actions should be generated.
+`flapping`
 
-`untracked`
-:   Actions are no longer generated. For example, you can choose to move active alerts to this state when you disable or delete rules.
+:   The alert is switching repeatedly between active and recovered states. If the rule has actions that run when the alert status changes states, those actions are suppressed while the alert is flapping.
 
-::::{note}
-An alert can also be in a "flapping" state when it is switching repeatedly between active and recovered states. This state is possible only if you have enabled alert flapping detection in **{{stack-manage-app}} > {{rules-ui}} > Settings**. For each space, you can choose a look back window and threshold that are used to determine whether alerts are flapping. For example, you can specify that the alert must change status at least 6 times in the last 10 runs. If the rule has actions that run when the alert status changes, those actions are suppressed while the alert is flapping.
+::::{note}  
+
+Alert flapping is turned on by default. You can modify the criteria for changing an alert's status to the flapping state by configuring the **Alert flapping detection** settings. To do this, navigate to the **Alerts** page in the main menu, or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). Next, click **Manage Rules**, then **Settings** to open the global rule settings for the space. In the **Alert flapping detection** section, modify the rules' look back window and threshold for alert status changes. For example, you can specify that the alert must change its status at least 6 times in the last 10 runs for it to become a flapping alert. 
 
 ::::
 
+`recovered`
+:   The conditions for the rule are no longer met. If the rule has [recovery actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one. 
+
+
+    An active alert changes to recovered if the conditions for the rule that generated it are no longer met. 
+
+    A flapping alert changes to recovered when the rule's conditions are unmet for a specific number of consecutive runs. This number is determined by the **Alert status change threshold** setting, which you can configure under the **Alert flapping detection** settings.
+
+    For example, if the threshold requires an alert to change status at least 6 times in the last 10 runs to be considered flapping, then to recover, the rule's conditions must remain unmet for 6 consecutive runs. If the rule's conditions are met at any point during this recovery period, the count of consecutive unmet runs will reset, requiring the alert to remain unmet for an additional 6 consecutive runs to finally be reported as recovered.
+
+    Once a flapping alert is recovered, it cannot be changed to flapping again. Only new alerts with repeated status changes are candidates for the flapping status. 
+
+`untracked`
+:   The rule is disabled, or you’ve marked the alert as untracked. To mark the alert as untracked, go to the **Alerts** table, click the {icon}`boxes_horizontal` icon to expand the **More actions** menu, and click **Mark as untracked**. When an alert is marked as untracked, actions are no longer generated. You can choose to move active alerts to this state when you disable or delete rules.
+
 ## Mute alerts [mute-alerts]
 
 If an alert is active or flapping, you can mute it to temporarily suppress future actions. In both **{{stack-manage-app}} > Alerts** and **{{rules-ui}}**, you can open the action menu (…) for the appropriate alert and select **Mute**. To permanently suppress actions for an alert, open the actions menu and select **Mark as untracked**.

extend/contribute/api-docs/organize-annotate.md

@@ -304,6 +304,11 @@ class FooRequest {
 
 This example shows the "later addition" scenario where `laterAddition` was added after the initial API release, requiring a parameter-level availability annotation with a later version than the API-level availability.
 
+:::::{important}
+The `since` field is only available for `stack`. If the API is introduced in multiple major versions (eg: `8.19.0` and `9.1.0`), use the appropriate value in each branch.
+:::::
+
+
 **Deprecation notices** use the `@deprecated` annotation:
 
 ```ts
@@ -449,4 +454,4 @@ The annotation system doesn't support "OR" relationships between privileges. Whe
 :::
 :::
 
-::::
+::::

solutions/observability/cicd.md

@@ -285,7 +285,7 @@ To learn more about the integration of Jenkins with Elastic {{observability}}, s
 
 There are out of the box {{kib}} dashboards that help visualize some metrics for the CI/CD platform.
 
-Using the [Import API](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-dashboards) or the {{kib}} UI, you can [install dashboards](https://github.com/jenkinsci/opentelemetry-plugin/blob/master/docs/DASHBOARDS.md#elastic) that are compatible with version 7.12 or higher.
+Using the [Import saved objects API](https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-saved-objects-import) or the {{kib}} UI, you can [install dashboards](https://github.com/jenkinsci/opentelemetry-plugin/blob/master/docs/DASHBOARDS.md#elastic) that are compatible with version 7.12 or higher.
 
 For instance, you can follow the below steps:
 

solutions/observability/incident-management/view-alerts.md

@@ -2,6 +2,10 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/observability/current/view-observability-alerts.html
   - https://www.elastic.co/guide/en/serverless/current/observability-view-alerts.html
+applies_to:
+  stack: all
+  serverless:
+    observability: all
 products:
   - id: observability
   - id: cloud-serverless
@@ -50,37 +54,47 @@ From the **Alerts** table, you can click on a specific alert to open the alert d
 :screenshot:
 :::
 
+To further inspect the rule:
+
+* From the alert detail flyout, click **View rule details**.
+* From the **Alerts** table, click the {icon}`boxes_horizontal` icon and select **View rule details**.
+
+To view the alert in the app that triggered it:
+
+* From the alert detail flyout, click **View in app**.
+* From the **Alerts** table, click the {icon}`eye` icon.
+
+## Understand alert statuses [observability-view-alerts-understand-statuses]
+
 There are four common alert statuses:
 
 `active`
-:   The conditions for the rule are met and actions should be generated according to the notification settings.
+:   The conditions for the rule are met. If the rule has [actions](../../../explore-analyze/alerts-cases/alerts/create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. 
 
 `flapping`
-:   The alert is switching repeatedly between active and recovered states.
 
-`recovered`
-:   The conditions for the rule are no longer met and recovery actions should be generated.
+:   The alert is switching repeatedly between active and recovered states. If the rule has actions that run when the alert status changes states, those actions are suppressed while the alert is flapping.
 
-`untracked`
-:   The corresponding rule is disabled or you’ve marked the alert as untracked. To mark the alert as untracked, go to the **Alerts** table, click the ![More actions](/solutions/images/serverless-boxesHorizontal.svg "") icon to expand the *More actions* menu, and click **Mark as untracked**. When an alert is marked as untracked, actions are no longer generated. You can choose to move active alerts to this state when you disable or delete rules.
+::::{note}  
 
-::::{note}
-**Flapping alerts**
-
-The flapping state is possible only if you have enabled alert flapping detection. Go to the **Alerts** page and click **Manage Rules** to navigate to the {{obs-serverless}} **{{rules-app}}** page. Click **Settings** then set the look back window and threshold that are used to determine whether alerts are flapping. For example, you can specify that the alert must change status at least 6 times in the last 10 runs. If the rule has actions that run when the alert status changes, those actions are suppressed while the alert is flapping.
+Alert flapping is turned on by default. You can modify the criteria for changing an alert's status to the flapping state by configuring the **Alert flapping detection** settings. To do this, navigate to the **Alerts** page in the main menu, or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). Next, click **Manage Rules**, then **Settings** to open the global rule settings for the space. In the **Alert flapping detection** section, modify the rules' look back window and threshold for alert status changes. For example, you can specify that the alert must change its status at least 6 times in the last 10 runs for it to become a flapping alert. 
 
 ::::
 
+`recovered`
+:   The conditions for the rule are no longer met. If the rule has [recovery actions](../../../explore-analyze/alerts-cases/alerts/create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one. 
 
-To further inspect the rule:
 
-* From the alert detail flyout, click **View rule details**.
-* From the **Alerts** table, click the ![More actions](/solutions/images/serverless-boxesHorizontal.svg "") icon and select **View rule details**.
+    An active alert changes to recovered if the conditions for the rule that generated it are no longer met. 
 
-To view the alert in the app that triggered it:
+    A flapping alert changes to recovered when the rule's conditions are unmet for a specific number of consecutive runs. This number is determined by the **Alert status change threshold** setting, which you can configure under the **Alert flapping detection** settings.
+    
+    For example, if the threshold requires an alert to change status at least 6 times in the last 10 runs to be considered flapping, then to recover, the rule's conditions must remain unmet for 6 consecutive runs. If the rule's conditions are met at any point during this recovery period, the count of consecutive unmet runs will reset, requiring the alert to remain unmet for an additional 6 consecutive runs to finally be reported as recovered.
 
-* From the alert detail flyout, click **View in app**.
-* From the **Alerts** table, click the ![View in app](/solutions/images/serverless-eye.svg "") icon.
+    Once a flapping alert is recovered, it cannot be changed to flapping again. Only new alerts with repeated status changes are candidates for the flapping status. 
+
+`untracked`
+:   The rule is disabled, or you’ve marked the alert as untracked. To mark the alert as untracked, go to the **Alerts** table, click the {icon}`boxes_horizontal` icon to expand the **More actions** menu, and click **Mark as untracked**. When an alert is marked as untracked, actions are no longer generated. You can choose to move active alerts to this state when you disable or delete rules.
 
 
 ## Customize the alerts table [observability-view-alerts-customize-the-alerts-table]
@@ -98,15 +112,14 @@ You can also use the toolbar buttons in the upper-right to customize the display
 
 ## Add alerts to cases [observability-view-alerts-add-alerts-to-cases]
 
-From the **Alerts** table, you can add one or more alerts to a case. Click the ![More actions](/solutions/images/serverless-boxesHorizontal.svg "") icon to add the alert to a new or existing case. You can add an unlimited amount of alerts from any rule type.
+From the **Alerts** table, you can add one or more alerts to a case. Click the {icon}`boxes_horizontal` icon to add the alert to a new or existing case. You can add an unlimited amount of alerts from any rule type.
 
 ::::{note}
 Each case can have a maximum of 1,000 alerts.
 
 ::::
 
 
-
 ### Add an alert to a new case [observability-view-alerts-add-an-alert-to-a-new-case]
 
 To add an alert to a new case: