Merge pull request #298196 from rajats22/main

Updates in backup documentation Backup Vault and AKS Backup

Author: prmerger-automator[bot]

articles/backup/azure-kubernetes-service-cluster-restore-using-cli.md

@@ -162,6 +162,8 @@ The restore configuration is composed of following items:
 
 - `namespace_mappings`: You can map namespace (and underlying resources) to a different namespace in the target cluster. If the target namespace doesn't exist in the cluster, then a new namespace is created by the extension. The input value should be provided as key value pair.
 
+- `object_type`: This variable specifies whether the restore configuration is intended for a recovery point stored in the Operational Tier or the Vault Tier. If the recovery point is in the Operational Tier, set the value to **KubernetesClusterRestoreCriteria**. If the recovery point is in the Vault Tier or being restored to a secondary region, set the value to **KubernetesClusterVaultTierRestoreCriteria**.
+
 - `persistent_volume_restore_mode`: You can use this variable to decide whether you would like to restore the persistent volumes backed up or not. Accepted values are RestoreWithVolumeData, RestoreWithoutVolumeData
 
 - `resource_modifier_reference`: You can refer the Resource Modifier resource deployed in the cluster with this variable. The input value is a key value pair of the Namespace in which the resource is deployed and the name of the yaml file.
@@ -172,6 +174,8 @@ The restore configuration is composed of following items:
 
 - `staging_storage_account_id`: In case you're restoring backup stored in the **vault tier**, you need to provide an ID of storage account as a staging location. In this resource group, the backed up kubernetes resources are hydrated before being restored to the target cluster. 
 
+
+
 Now, prepare the restore request with all relevant details. If you're restoring the backup to the original cluster, then run the following command:
 
 ```azurecli
@@ -185,6 +189,13 @@ If the Target AKS cluster for restore is different from the original cluster, th
 az dataprotection backup-instance restore initialize-for-data-recovery --datasource-type AzureKubernetesService --restore-location $region --source-datastore OperationalStore --recovery-point-id $recoverypointid --restore-configuration restoreconfig.json --target-resource-id /subscriptions/$subscriptionId/resourceGroups/$aksclusterresourcegroup/providers/Microsoft.ContainerService/managedClusters/$targetakscluster >restorerequestobject.json
 
 ```
+If the target cluster is in secondary region then use the flag `--use-secondary-region`.
+
+```azurecli
+az dataprotection backup-instance restore initialize-for-data-recovery --datasource-type AzureKubernetesService --restore-location $region --source-datastore OperationalStore --recovery-point-id $recoverypointid --restore-configuration restoreconfig.json --target-resource-id /subscriptions/$subscriptionId/resourceGroups/$aksclusterresourcegroup/providers/Microsoft.ContainerService/managedClusters/$targetakscluster --use-secondary-region true >restorerequestobject.json
+
+```
+
 
 >[!Note]
 > In case you have picked a recovery point from vault tier with `--source-datastore` as VaultStore then provide a storage account and snapshot resource group in restore configuration.
@@ -197,6 +208,13 @@ Now, you can update the JSON object as per your requirements, and then validate
 az dataprotection backup-instance validate-for-restore --backup-instance-name $backupinstancename --resource-group $backupvaultresourcegroup --restore-request-object restorerequestobject.json --vault-name $backupvault
 
 ```
+If the target cluster is in secondary region then use the flag `--use-secondary-region`.
+
+```azurecli
+az dataprotection backup-instance validate-for-restore --backup-instance-name $backupinstancename --resource-group $backupvaultresourcegroup --restore-request-object restorerequestobject.json --vault-name $backupvault --use-secondary-region true
+
+```
+
 
 This command checks if the AKS Cluster and Backup vault have the required roles on different resource needed to perform restore. If the validation fails due to missing roles, you can assign them by running the following command:
 
@@ -212,7 +230,7 @@ az dataprotection backup-instance update-msi-permissions --datasource-type Azure
 > - The *User Identity* attached with the Backup Extension should have *Storage Blob Data Contributor* roles on the *storage account* where backups are stored in case of Operational Tier and on the **staging storage account* in case of Vault Tier. 
 > - The *Backup vault* should have a *Reader* role on the *Target AKS cluster* and *Snapshot Resource Group* in case of restoring from Operational Tier.
 > - The *Backup vault* should have a *Contributor* role on the *Staging Resource Group* in case of restoring backup from Vault Tier. 
-> - The *Backup vault* should have a *Storage Account Contributor* and *Storage Blob Data Owner* role on the *Staging Resource Group* in case of restoring backup from Vault Tier. 
+> - The *Backup vault* should have a *Storage Account Contributor* and *Storage Blob Data Owner* role on the *Staging Storage Account* in case of restoring backup from Vault Tier. 
 
 ## Trigger the restore
 
@@ -221,6 +239,12 @@ Once the role assignment is complete, you should validate the restore object onc
 ```azurecli
 az dataprotection backup-instance restore trigger --backup-instance-name $backupinstancename --restore-request-object restorerequestobject.json 
 ```
+If the target cluster is in secondary region then use the flag `--use-secondary-region`.
+
+```azurecli
+az dataprotection backup-instance restore trigger --backup-instance-name $backupinstancename --restore-request-object restorerequestobject.json --use-secondary-region true
+```
+
 
 >[!Note]
 >The resources hydrated in the staging resource group and storage account are not automatically cleaned up after the restore job is completed and are to be deleted manually.

articles/backup/backup-vault-overview.md

@@ -39,6 +39,18 @@ Azure Backup provides you two options (**Microsoft managed keys** and **Customer
 
 You can fetch your own keys to encrypt the backup data by using the **Customer Managed Keys** option under **Encryption settings** on the *Backup vault*.
 
+### Role-Based Access Control (RBAC) in Backup vault
+
+Backup vaults provide a robust Role-Based Access Control (RBAC) mechanism that not only governs who can access a Backup vault and what operations they can perform, but also enables fine-grained control over which individual workloads the vault can access and to what extent. This includes access to Azure resources such as Azure Disks or PostgreSQL servers to be backed up and Key Vaults used for encryption key management.
+
+RBAC is enforced through Managed Identities associated with the Backup vault. Specific roles can be assigned to these identities to grant the required access. Backup vaults support two types of managed identities:
+
+- **System Assigned Managed Identity:** This identity is automatically created when the Backup vault is provisioned and is tied to the lifecycle of the vault. You have the option to disable this identity if needed.
+
+- **User Assigned Managed Identity:** This is an independent Azure resource that can be assigned to one or more Backup vaults. Once assigned, any roles granted to this identity apply to the vault as well. The lifecycle of a user-assigned managed identity is decoupled from the vault, providing greater flexibility. Multiple user-assigned identities can be associated with a single Backup vault.
+
+These identities ensure secure and manageable access control, enabling Backup vaults to operate with the least privilege necessary while aligning with organizational security policies.
+
 ## Cross Region Restore support for PostgreSQL using Azure Backup
 
 Azure Backup allows you to replicate your backups to an additional Azure paired region by using Geo-redundant Storage (GRS)  to protect your backups from regional outages. When you enable the backups with GRS, the backups in the secondary region become accessible only when Microsoft declares an outage in the primary region. However, Cross Region Restore enables you to access and perform restores from the secondary region recovery points even when no outage occurs in the primary region; thus, enables you to perform drills to assess regional resiliency.