-
Notifications
You must be signed in to change notification settings - Fork 263
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #241 from Brunoga-MS/main
Update to documentation for June 2024 the 5th release
- Loading branch information
Showing
23 changed files
with
320 additions
and
113 deletions.
There are no files selected for viewing
73 changes: 73 additions & 0 deletions
73
docs/content/patterns/alz/Bring-your-own-Managed-Identity.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| --- | ||
| title: Bring Your Own User Assigned Managed Identity (BYO UAMI) | ||
| geekdocCollapseSection: true | ||
| weight: 62 | ||
| --- | ||
|
|
||
| # Overview | ||
|
|
||
| The ***Bring Your Own User Assigned Managed Identity*** (BYO UAMI) feature, available with release [2024-06-05](../Whats-New#2024-06-05), allows both Greenfield and Brownfield customers to create a new User Assigned Managed Identity (UAMI) during the deployment of AMBA-ALZ. It also allows Brownfield customers, who deployed the ALZ pattern when this feature wasn't available, to use any existing one by configuring a couple of parameters. Thanks to this new feature, it's now possible to query Azure Resource Graph (ARG) using the Kusto Query Language. Log-based search alerts can now be enhanced to include ARG queries looking at resource tags. | ||
|
|
||
| # How this feature works | ||
|
|
||
| The BYO UAMI feature works by creating a new UAMI in the management subscription and assigns the ***Monitoring reader*** role on the parent pseudo root Management Group. With this new feature, it's now possible to query Azure Resource Graph (ARG) using the Kusto Query Language and to enhance Log-based search alerts that can now query ARG to look at resource tags or properties. It's enough to enter the necessary parameter values before running the ALZ pattern deployment. | ||
|
|
||
| Should Brownfield customers decide to use their own UAMI after the initial deployment, it will be sufficient to enter the parameter values for _bringYourOwnUserAssignedManagedIdentity_ and _bringYourOwnUserAssignedManagedIdentityResourceId_, leaving the _userAssignedManagedIdentityName_ parameter at its default and the parameter _managementSubscriptionId_ with no values: | ||
|
|
||
| Once parameters are set according to your needs, redeploy the AMBA-ALZ pattern and wait for the remediation to happen. You can also start the Policy remediation manually as documented at [Remediate Policies](../deploy/Remediate-Policies). | ||
|
|
||
| ## Conditional deployment behavior | ||
|
|
||
| The deployment template has conditions that controls what is being deployed according to the following two scenarios: | ||
|
|
||
| A. ***Customers want to use existing UAMI.*** In this scenario the deployment will: | ||
|
|
||
| {{< hint type=Important >}} | ||
| When using an existing UAMI provided by the customer, the customer has to grant the UAMI the ***Monitoring Reader*** role at the pseudo root Management Group level <ins>**before running the deployment.**</ins> | ||
| {{< /hint >}} | ||
|
|
||
| - Not deploy any UAMI | ||
| - Not assign the _Monitoring Reader_ role | ||
| - Set the provided existing UAMI as the identity to be used in the necessary alerts | ||
|
|
||
| Here's a sample extract of the parameter file with the relevant parameter configuration for this scenario: | ||
|
|
||
|  | ||
|
|
||
| B. ***Customers does not have an existing UAMI and want AMBA-ALZ to create a new one.*** In this scenario the deployment will: | ||
|
|
||
| {{< hint type=Info >}} | ||
| When a new UAMI is created by the deployment template, the ***Monitoring Reader*** role is <ins>*is automatically assigned at the pseudo root Management Group level during the deployment*</ins>. | ||
| {{< /hint >}} | ||
|
|
||
| - Deploy any UAMI | ||
| - Assign the *Monitoring Reader* role | ||
| - Set the provided existing UAMI as the identity to be used in the necessary alerts | ||
|
|
||
| Here's a sample extract of the parameter file with the relevant parameter configuration for this scenario: | ||
|
|
||
|  | ||
|
|
||
| ## Where is it used | ||
|
|
||
| This new feature is used in Log-search based alerts. At the moment of this release, there's one alert using it. The alert is part of the new ***Deploy Azure Monitor Vaseline Alerts for Hybrid VMs*** policySet added to monitor hybrid virtual machine. | ||
|
|
||
|  | ||
|
|
||
| {{< hint type=Info >}} | ||
| We're planning to use this feature more in the future and to include it as part of other alerts. | ||
| {{< /hint >}} | ||
|
|
||
| <!-- | ||
| ## Switching between BYO UAMI and new UAMI | ||
| The [conditional deployment behavior](../alz/Bring-your-own-Managed-Identity.md#conditional-deployment-behavior) discussed earlier, allows brownfield customers to switch from a new created UAMI to an existing one and viceversa. | ||
| Should customers decide to switch, it will be enough to: | ||
| - change the values in the parameter file to match one of the two scenarios previously discussed | ||
| - redeploy the AMBA-ALZ pattern | ||
| - run the remediation. Atthe moment it is sufficient to run the remediation for the [Deploy Azure Monitor Vaseline Alerts for Hybrid VMs](https://raw.githubusercontent.com/Azure/azure-monitor-baseline-alerts/main/patterns/alz/policySetDefinitions/Deploy-HybridVM-Alerts.json) policy initiative | ||
| The code will reconfigure the necessary alerts to use either the customer's provided UAMI or the new one created during the deployment. | ||
| --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
40 changes: 40 additions & 0 deletions
40
docs/content/patterns/alz/UpdateToNewReleases/Update_from_release_2024-04-12.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| --- | ||
| title: Updating from release 2024-04-12 | ||
| geekdocCollapseSection: true | ||
| weight: 98 | ||
| --- | ||
| {{< hint type=Important >}} | ||
| ***The parameter file structure has changed to accommodate a new feature coming soon.*** | ||
| {{< /hint >}} | ||
|
|
||
| # Pre update actions | ||
|
|
||
| The parameter file structure has changed to accommodate a new feature coming soon. For this reason, updating from release [2024-04-12](../../Whats-New#2024-04-12) requires the alignment of the parameter file structure you have been using so far with the new one coming with the release. | ||
|
|
||
| In particular the new parameter file has the following differences: | ||
|
|
||
| 1. Contains new parameters for using an existing User Assigned Managed Identity or creating a new one during the AMBA-ALZ deployment. It's required by the new hybrid virtual machine alert set. Make sure to review and set the following parameters correctly: | ||
|
|
||
| 1. ***bringYourOwnUserAssignedManagedIdentity***: set it to **Yes** if you would like to use your own User Assigned Managed Identity (UAMI) or to **No** if you don't have one and would like the deployment of AMBA-ALZ to create one. | ||
|
|
||
| 2. ***bringYourOwnUserAssignedManagedIdentityResourceId***: If you set the **bringYourOwnUserAssignedManagedIdentity** parameter to **Yes**: | ||
|
|
||
| 1.1. Enter the UAMI resource ID, leaving the **managementSubscriptionId** blank | ||
|
|
||
|  | ||
|
|
||
| 1.2. Configure it with the ***Monitoring Reader*** role on the pseudo root Management Group. | ||
|
|
||
| 3. ***userAssignedManagedIdentityName***: If you set the **bringYourOwnUserAssignedManagedIdentity** parameter to **No**, leave the default value or set a different one to specify a different name for the UAMI created during the deployment. The provided default name aligns with the ALZ standard naming convention. | ||
|
|
||
|  | ||
|
|
||
| 4. ***managementSubscriptionId***: If you set the **bringYourOwnUserAssignedManagedIdentity** parameter to **No**, enter the subscription ID of the subscription under the Management management group. The deployment procedure will create the UAMI in this subscription and assign it the ***Monitoring Reader*** role on the pseudo root Management Group | ||
|
|
||
|  | ||
|
|
||
|  | ||
|
|
||
| 2. Changes the previous parameter objects, such as ***policyAssignmentParametersCommon***, ***policyAssignmentParametersBYON*** and ***policyAssignmentParametersNotificationAssets*** into classic parameters using the same name as before. As result, the previous sections of the parameter you'll now look like the following image: | ||
|
|
||
|  |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.