We are using a storageclass in Kubernetes to dynamically provision azure file shares with pvc claims (https://learn.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv?source=recommendations)
We use recovery service vault to backup these file shares (https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview?WT.mc_id=Portal-Microsoft_Azure_Support#key-benefits-of-azure-file-share-backup).
Azure Backup locks the storage account associated with the file shares against deletion in Resource Group scope. The lock is called "AzureBackupProtectionLock" and it protects storage accouunts registered with a Recovery Services vault to guard against deletion of backups.
That seems fair, however this lock on resource group scope is blocking us from upgrading the AKS version. The screenshot with error is attached
Any idea how to prevent this behaviour ? Thanks :)
This error may occur if your resource group lock as applied as Read only access When a resource is marked as read-only, it can only be accessed; it cannot be update or deleted. By implementing this lock, all authorized users will only be granted the privileges offered by the Reader role.
Please check this Considerations before applying your locks To resolve this issue make sure to delete our locks in your resource group as below:
Go to azure portal -> your resource group ->under setting locks -> delete
You need access to Microsoft.Authorization/* or Microsoft.Authorization/locks/* operations in order to add or remove management locks. Only Owner and User Access Administrator have access to those activities among the built-in roles.
Reference: Lock your resources to protect your infrastructure
Related
I want to move azure resource group from one azure account to otherazure account. Can any one help me how to move this to other account?
If my understanding of your question is correct. You're intending to move Resource Group from one account/subscription to another Azure Subscription/owner. If this is the case, you can move resources from a source group to a target group in a different subscription.
There are some important steps to do before moving a resource. By verifying these conditions, you can avoid errors. Currently, not all resources in Azure support move. For a list of resources that support move, see Move operation support for resources.
Kindly verfiy and validate the move as outlined in this document- https://learn.microsoft.com/azure/azure-resource-manager/management/move-resource-group-and-subscription#validate-move before initiating the move process.
Note: Moving a resource only moves it to a new resource group or subscription. It doesn't change the location of the resource.
I have applied deletion lock on my subscription level so that all the resource will get the locks, while revoked the access from virtual machines, azure deletion lock is preventing the IAM role deletion, Is there any way to fix it?
the only way to fix it - remove the lock, delete the assignment, reestablish the lock. Assignment is really just another resource in the ARM model. nothing you can do about it.
We are building a solution in Azure Government and we will be using Terraform to deploy the solution. Seems the preferred method is to create a Service Principal for Terraform with the Service Principal having the Contributor role scoped to the subscription.
The one issue with this we are looking to solve is that this gives the Service Principal management plane access to the Key Vault...since it is in the subscription. With Contributor role, the service principal is not able to create new access policies (assign itself or others permissions to the data plane) but we are looking for a way that can remove the service principal from having any management plane permissions.
We have tried putting a ReadOnly lock on the Key Vault before creating the Service Principal but the lock does not stop the service principal from getting the Contributor permissions on the Key Vault.
Outside of creating a new role that has Contributor for everything EXCEPT for Key Vault, does anyone have any creative ideas that might help achieve this?
Yes, the root cause of all security issues is that the Service Principal's contributor role assignment is at the subscription level/scope, which enables it to do quite damage specially if multiple applications are deployed to the same subscription (e.g. delete any resource group).
One approach would be:
Provision one resource group for the Azure Key Vault specific to the application and region (the latter in case of geo-distributed applications).
Provision the Azure Key Vault on the resource group created on the previous step.
In our case, the Security Office was responsible for the first 2 steps, where they had monitoring (e.g. email, text-messages, etc.) for any change in the Azure Key Vault (e.g. new keys/secrets/certificates added/deleted/changed, permission changes, etc.).
Provision a second resource group, which will serve as a container for the application components (e.g. Azure Function, Azure SQL Server/Database, Azure Service Bus Namespace/Queue, etc.).
Create the Service Principal and assign the Contributor role to the
application resource group only, for example:
scope =
/subscriptions/{Subscription Id}/resourceGroups/{Resource Group
Name}
Find a sample PS script to provision a Service Principal with custom scope at https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.
Give appropriate permissions for the Service Principal in the Azure
Key Vault. In our case, we decided to have separate Service
Principal accounts for deployment (Read-Write permissions on keys/secrets/certificates) and runtime (Read-Only permissions on keys/secrets/certificates);
Find a sample PS script to set Service Principal permission on an Azure Key Vault at https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.
Having that said, there are lots of inconveniences with this approach, such as:
The process (e.g. via runbook) to provision the Azure Key Vault (including its resource group) and the application resource group will be outside of the main Terraform template responsible for the application components, which requires coordination with different teams/processes/tools/etc.
Live site involving connectivity often involves coordination among multiple teams to ensure RTO and MTTM (Mean Time To Mitigate) goals are achieved.
The Service Principal will be able to delete the application specific resource group when terraform destroy is executed, but it will fail to recreate it when running terraform apply after that due to lack of permission at the subscription level/scope. Here is the error:
provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".
Yeah, I know, this is a long answer, but the topic usually requires lots of cross-team discussions/brainstorming to make sure the security controls established by the Security Office are met, Developer productivity is not affected to the point that it will impact release schedules and RTO/MTTM goals are met. I hope this helps a bit!
While deleting a resource group am getting the below mentioned error.
Failed to delete resource group backupone: Deletion of resource group
'backupone' failed as resources with identifiers
'Microsoft.RecoveryServices/vaults/backupone' could not be deleted.
The provisioning state of the resource group will be rolled back. The
tracking Id is 'ee14d432-edf4-48e3-ba7f-016757125909'. Please check
audit logs for more details. (Code: ResourceGroupDeletionBlocked)
Vault cannot be deleted as there are existing resources within the
vault. Please ensure there are no backup items, protected servers or
backup management servers associated with this vault. Unregister the
following containers associated with this vault before proceeding for
deletion : backuponestg Unregister all containers from the vault and
then retry to delete vault (Code:
ServiceResourceNotEmptyWithContainerDetails)
Can someone please help me understand what is wrong?
As I commented above, the error message
Vault cannot be deleted as there are existing resources within the vault
hints to me there might be a Azure Site Recovery Vault in the resource group.
Here's some more information.
If you got a Azure Site Recovery Vault inside of a resource group, and it contains some data from backed up virtual machines, then this can block the deletion of the vault.
You need to, manually, first to clean up the vault before you can delete the ASR vault. This is a mechanism set in place to prevent accidental deletion of backed up data.
Check out this link for a more detailed guide on what steps you need to take to unassociate workloads with your vault.
from new Azure Portal, I selected a Virtual machine and then I am able to create Multilple resource locks of type - Delete.
How does these Multiple resource locks of same type works/helps , when all of these lock does the same thing ?
As an administrator, you may need to lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. You can set the lock level to CanNotDelete or ReadOnly.
CanNotDelete means authorized users can still read and modify a resource, but they can't delete the resource. More information please refer to this link.
How does these Multiple resource locks of same type works/helps , when
all of these lock does the same thing ?
You could create VMs in the same group and lock the resource group.