Posts Tagged Azure
Azure Key Vault is used to safeguard system critical data, such as keys, secrets and certificates that are part of your infrastructure core operations.
Key Vault access is managed through two interfaces: management plane – this dictates access to the Key Vault itself but not managing its content which is based on RBAC model, data plane – this enables granular control of keys/secrets/certificates, which relies on Access Policy.
This brings us nicely to Access Policies which is meat of this article. I have had to deal with a situation lately while applying access policy for a colleague while a restriction is imposed on my Azure AD account (see example below)
This would have limited access to my account (which is external) to AAD, which means I cant read or search AAD which is required when adding access policy via the GUI – Setting RBAC without access to AAD works (as an exception) if you know the full FQDN of the user you are adding.
The way around is to use PowerShell, but this requires a prerequisite which is the Azure AD object ID for the user you want to add, this can be achieved by adding them temporarily on management plane to access their user properties and copy object ID before deleting that rule.
Now to the command I used to apply that permission:
Key property here is the BypassObjectIdValidation, if the Object ID exists in AAD then it will be linked and the user will have their access policy applied to Azure Key Vault.
While working with DevTest Labs on Microsoft Azure, it’s a good idea to make sure you have Auto-start and Auto-shutdown policies to keep cost down on resource utilisation while not being used.
The mistake or misconception I had form customers and I see this continuously that they forget to opt the VM in or out of the policy when scheduling these machines to shutdown or start at certain times.
This needs to be enforced on a per VM basis, see below.
I have been working with Microsoft lately on an issue that I was experiencing with an Azure application gateway (appGW) deployment that require both internal and external interfaces handling traffic over HTTPS.
If you try to attach the same AppGW front end port to internal and external front end configuration, this would cause the appGW to misbehave. In my scenario I had a rule attached to external interface for handling incoming traffic but no rule attached on the internal interface and as a consequence the internal interface started processing traffic while the external interface was rejecting all connections (not even 502 error! would you believe!). Just to note that all my appGW deployments are scripted using PowerShell/JSON.
Microsoft managed to replicate this internally and issued a bug report, they are working on it as we speak but without ETA currently.
I had to drop my second listener (internal) in order to bring the appGW back to it’s expected behaviour!
Infrastcuture in the cloud (IaaS) is such an evolving topic from the architectual point of view. As services do evolve and more functionalities get added in order to enable the end user to untilise these services in best forms, complexities do start to add to it.
IaaS require a lot of initial planning to minimise any downtime required to re-allocate services/servers for production (Prod).
If breaking to Azure services started as a proof of concept (PoC) initially and changed suddenly to being the business critical service that your business can’t function without – without the necessary transitional planning then we are on the same page here.
Microsoft Azure does add a lot of value to the business and continuity of its business operations.
In this article I will go over Azure different resources and the way they could be organised for ease of management and billing. Billing is an important topic if you want to understand how your services are being utilised in the cloud or in order to bill each business unit if your business is using the charge back model.
If you have just started building your infrastructure on Azure, ensure your business units use Azure Resource Groups to group their services/servers and that could save you a lot of time in the long run.
The way to move resources between different resource groups are a complex ‘PowerShell driven process’. First you need to understand the limitiation of resource move:
- vNet’s can’t be moved
- Re-allocated Azure resources will retain their source region, even if your destination resource group is in a different region.
- You can’t move a single VM attached to a cloud service, the cloud service and all VM’s attached to it will have to move together.
- From experience, move storage accounts seperately. When I try to move a storage account with the rest of resources I get error (“One resource move request can contain resources of only 1 provider.”) :
- If you would like to migrate the VM to a new vNet then the VM needs to be deleted and reprovisioned on the vNet – the VM will down for that duration.
- If you would like to move the VM to a new storage account, then the downtime will be much greater depending how big the VHD files are and the region. I won’t talk much about this process, you will find it detailed here.
Now we will talk about the interesting part, the move and re-allocation process.
- Download the latest Azure Powershell module (We will be using the latest Azure Resource Management module) as illustrated here
- Login to your subscription using Login-AzureRmAccount
- Get the content of your source resource group on Azure: Get-AzureRmResource
- Feed the output to Move-AzureRmResource
I have written a short script to demonstrate this process (MS Azure Resource Group Management(MS Azure Resource Group Management), I have added comments necessary to each of the steps in the script so you should be able to customize it to your needs.