Microsoft Azure: Access and Resources

As part of the Microsoft Enterprise Skills Initiative I am looking into different topics in Azure and summarize my learnings. This post is about Azure access and resources

Subscription #

Before being able to access Azure, you need an Microsoft Account and a Subscription. With the free account you have your private subscription but your company might create an additional subscription. Once you have a subscription you can start creating resources - keep in mind every resource costs money, so checkout the prices. So let’s have a look on this relates to each other:

On top we have the Management groups, which are containers for one or multiple subscriptions and allow you to manage access, policy, and compliance. Management groups can have multiple levels i.e. they itself can include other management groups:

• 10,000 management groups can be supported in a single directory.
• A management group tree can support up to six levels of depth.
• This limit doesn’t include the Root level or the subscription level.
• Each management group and subscription can only support one parent.
• Each management group can have many children.
• All subscriptions and management groups are within a single hierarchy in each directory.
• The top-level group is called Root management group

Each subscription groups together user accounts and the resources, and allows you to define limits and quotas for them. Thus every subscription is associated with an Azure Active Directory tenant. They also can have different billing profiles (payments, invoices, …). A user account is associated with one or more subscriptions.

Resources and Resource Groups #

Resources are instances of services that you create, like virtual machines, storage, or SQL databases. They are combined into resource groups, which act as a logical container. This allows logical grouping of resources, applying role-based access control (RBAC) permissions, and implies the same lifecycle - deleting a resource group also deletes all resources within. To prevent deletion or certain modifications by creating a resource lock:

• CanNotDelete: authorized users can read and modify a resource, but not delete the resource
• ReadOnly: authorized users can read a resource, but they can’t delete or update the resource

There are some considerations you should check, before applying any locks.

A resource group always belongs to a subscription and belong to a particular region. The region specifies where the metadata is stored. Resources still can have different locations.

The limit of a resource group is determined by the quota of the subscription, the resource group belongs to. Usage and quotas can be viewed in the Azure Resource manager in the Azure portal.

If you misplaced a resource, you can move it to another resource group or even another subscription. There are some exceptions like Azure ADS, which cannot be moved. For other resources like VMs, which have dependent resources (disk, …), you have to make sure you can also move the dependent resources along with it. Unless you to this operation with Azure portal - which validates the move beforehand - it is recommended to do a validation of your move operation before you actually perform it.

Resources are managed via the Azure Resource Manager which can be accessed via the Azure portal or other interfaces like Azure CLI. It allows you to manage resources using declarative language and templates.

How to organize the resources? #

How you defined your resource groups, depends on your use cases. So you might organize them …

• by resource types
• by environment (prod, qa, dev)
• by department (marketing, finance, human resources)
• by a combination of the above
• by who has authorization
• by billing account
• by lifecycle (e.g. for disposable environments for testing)

It is recommended to follow a consistent naming convention, so it is clear what the resource group is about.

Access and resource organization #

Identity and Access management #

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service, which helps your employees sign in and access internal (corporate network) and external (cloud applications) resources. There is a free tier as well as payed premium tiers (P1, P2). There are some differences between Azure AD and Active Directory Domain Services including features like application and device management. However with Azure AD Connect, ADDS and Azure AD can be connected together, in order to synchronize user identities between them. This also allow you to use features like SSO, multifactor authentication, and self-service password reset.

Basic multi-factor authentication features are available to Microsoft 365 and Azure Active Directory (Azure AD) administrators for no extra cost. With premium licenses you get MFA also for your users.

With premium license, you also get Conditional Access, a tool which uses policies to grant or block access to resources - they are like if-then statements, if a user wants to access a resource, then they must complete an action. The Conditional Access policies use signals (User group membership, IP Location, Device, Application user wants to access, …) to make a decisions (block access, grant access, grant access but require MFA, device must be compliant).

Azure role-based access control #

With Azure role-based access control or Azure RBAC you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

• Security principal is an object that represents a user, group, service principal, or managed identity that is requesting access to Azure resources
• Role definition or role is a collection of permissions of operations that can be performed. Azure offers some built-in roles for generic purposes (Contributor, Owner, Reader, User Access Administrator) as well as resource specific roles.
• Scope is the set of resources that the access applies to - see Understand scope. This can be
  • A management group (a collection of multiple subscriptions).
  • A single subscription.
  • A resource group.
  • A single resource.
• A role assignment is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access.

Some things to note:

• permissions are inherited from parent to all child scopes
• role assignments are transitive for groups
• with multiple role assignments are “added” to each other, so your effective permissions are the sum of your role
• there is a limited possibility for deny assignments.

Azure Policy #

Azure Policy enables you to create, assign, and manage policies that control or audit your resources. These policies enforce different rules and effects over your resource configurations so that those configurations stay compliant with corporate standards. For example:

• only allowing specific types of resources to be created
• only allowing resources in specific Azure regions
• enforce naming convention on resource

This can be individual policies or groups of related policies, known as initiatives. So this works as follows

1. Create a policy definition.

   Every policy definition has conditions under which it’s enforced. And, it has a defined effect that takes place if the conditions are met.

2. Assign the definition to resources.

3. Review the evaluation results.

There are a lot of built-in policies available, but you can define your own policies. See also Azure Policy definition structure for details on the JSON format used for describing the policies.

The difference between Azure Policy and Azure role-based access control are

• Azure Policy evaluates state by examining properties on resources that are represented in Resource Manager and properties of some Resource Providers
• Azure RBAC focuses on managing user actions at different scopes

An example of a policy could be to prohibit create resources in US regions. The user might have the permission (RBAC) to create VMs, but when he want to create one in US, then the policy would prohibit him to do so.

Azure Policy establishes conventions for resources. Policy definitions describe resource compliance conditions and the effect to take if a condition is met. A policy is a well defined JSON-file with the following elements

• display name
• description
• mode
• metadata
• parameters
• policy rule
  • logical evaluation
  • effect

Taking the example of the documentation, this is a policy that limits where resources are deployed:

{
    "properties": {
        "displayName": "Allowed locations",
        "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
        "mode": "Indexed",
        "metadata": {
            "version": "1.0.0",
            "category": "Locations"
        },
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": [ "westus2" ]
            }
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}

Checkout Azure Policy samples for more.

Azure Blueprints #

Azure Blueprints allows you to defined a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. It is declarative way to orchestrate the deployment of various resource templates and other artifacts, such as:

• Role assignments
• Policy assignments
• Azure Resource Manager templates
• Resource groups

Tagging #

You can apply tags (name and a value pair) to your resources, resource groups, and subscriptions, to logically organize them into a taxonomy. This allow to extend the standard Azure properties of a resource which are

• department (like finance, marketing, and more)
• environment (prod, test, dev)
• cost center
• life cycle and automation (like shutdown and startup of virtual machines)

This allows you to better search, filter and organize your resources. Tags can be added by any of the methods mentioned above. This has to be done for each resources, as tags aren’t inherited from parent resources. Not all resources support tags and some resources have a narrower limitation on the length of the tags (default 512 chars).

Compliance and Legal #

The following picture show the categorization and some examples of available compliance offerings available in Azure:

Beside, there are certain legal documents you should be aware of:

• Microsoft Privacy Statement explains what personal data Microsoft collects on services, websites, apps, software, servers, and devices, how Microsoft uses it, and for what purposes.

• Online Services Terms (OST) is a legal agreement between Microsoft and the customer and details the obligations by both parties with respect to the processing and security of customer data and personal data

• Data Protection Addendum (DPA) defines the data processing and security terms for online services. These terms include:

  • Compliance with laws.
  • Disclosure of processed data.
  • Data Security, which includes security practices and policies, data encryption, data access, customer responsibilities, and compliance with auditing.
  • Data transfer, retention, and deletion.

Further resources to consult:

• Trust Center provides support and resources for the legal and compliance community.
• Azure compliance documentation provides you with detailed documentation about legal and regulatory standards and compliance on Azure.
• Azure Government is a separate, isolated instance of the Microsoft Azure service to address security and compliance needs of US federal agencies, state and local governments, and their solution providers.
• Azure China 21Vianet is a physically separated instance of cloud services located in China operated by 21Vianet.

Azure regions, availability zones, and region pairs #

Resources are created in regions, which are different geographical locations around the globe that contain one or multiple datacenters. This allows you to bring your applications closer to your users. There are also specialized regions for compliance or legal purposes which are physical and logical network-isolated, for example US DoD Central, US Gov Virginia, US Gov Iowa and more or China East, China North, and more.

Availability zones are physically separate data centers - equipped with independent power, cooling, and networking- within an Azure region. Availability zones are

• made up of one or more data centers
• has an isolation boundary
• are connected through high-speed, private fiber-optic networks
• not available in all regions

In addition there are region pairs, whereas each Azure region is always paired with another region within the same geography (such as US, Europe, or Asia) at least 300 miles away. This allows for replication fo resources, to be prepared for disasters.

Management tools #

We already know about the Azure Portal, the web-based user interface to access all features of Azure. But there are also other tools available. One is the Azure mobile app where you can access your Azure resources and do

• Monitor the health and status of your Azure resources.
• Check for alerts, quickly diagnose and fix issues, and restart a web app or virtual machine (VM).
• Run the Azure CLI or Azure PowerShell commands to manage your Azure resources.

Azure Powershell #

Azure PowerShell offers cmdlets to interact with Azure and Azure resources. If you are working on a Windows machine and you are familiar with Powershell, this makes it a good choice to make your work repeatable and automatable. It can be installed using and msi or as follows

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Azure CLI #

Azure CLI is another option for repeatable tasks using scripting, especially if you work in Linux or Mac, but also Windows.

Azure Resource Manager templates (ARM templates) #

Azure Resource Manager templates (ARM templates) allows you to describe the resources you want to use, in declarative JSON format, allowing you to automate setup and orchestration of your Azure infrastructure. An ARM has the following sections:

• Parameters - Provide values during deployment that allow the same template to be used with different environments.
• Variables - Define values that are reused in your templates. They can be constructed from parameter values.
• User-defined functions - Create customized functions that simplify your template.
• Resources - Specify the resources to deploy.
• Outputs - Return values from the deployed resources.

{
    "$schema": "http://schema.management.azure.com/schemas/2019-04- 01/deploymentTemplate.json#",
    "contentVersion": "",
    "parameters": {},
    "variables": {},
    "functions": [],
    "resources": [],
    "outputs": {}
}

By the use of template expressions - expressions which start and end with brackets [ and ] - you can extend the JSON values available within the template. The following shows a simple template to create a resource group and lock it:

{
  "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "rgName": {
      "type": "string"
    },
    "rgLocation": {
      "type": "string"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Resources/resourceGroups",
      "apiVersion": "2021-04-01",
      "name": "[parameters('rgName')]",
      "location": "[parameters('rgLocation')]",
      "properties": {}
    },
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2021-04-01",
      "name": "lockDeployment",
      "resourceGroup": "[parameters('rgName')]",
      "dependsOn": [
        "[resourceId('Microsoft.Resources/resourceGroups/', parameters('rgName'))]"
      ],
      "properties": {
        "mode": "Incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "parameters": {},
          "variables": {},
          "resources": [
            {
              "type": "Microsoft.Authorization/locks",
              "apiVersion": "2016-09-01",
              "name": "rgLock",
              "properties": {
                "level": "CanNotDelete",
                "notes": "Resource group and its resources should not be deleted."
              }
            }
          ],
          "outputs": {}
        }
      }
    }
  ],
  "outputs": {}
}

You can do much more complex things like multiple resources in one file. You may also split your declaration inti multiple, so called nested templates.

For more examples checkout Azure Quickstart templates. ARM templates can then be used in the Azure Portal, Azure Powershell.Azure CLI, REST API, Button in GitHub repository or Azure Cloud Shell.

Azure offers with Azure REST API a REST endpoint which allows you to manage your resources with HTTP requests. You need to be authenticated in order to do so.

At last Azure Cloud Shell is an interactive, authenticated, browser-accessible shell for managing Azure resources, offering the same flexibility as Bash or PowerShell console. This shell is accessible via Azure Portal.

Bicep #

TBD

Cost Management and SLA #

Costs in Azure should be properly planned, by using Total Cost of Ownership (TCO) Calculator. Furthermore, you can do the following to control and lower costs:

• Azure Reservations offers discounted prices on certain Azure services up to 72% if you reserve services and resources by paying in advance.
• Create resources in low-cost locations and regions.
• Assign tags to resources categorize costs by departments or environments.
• Resize underutilized virtual machines.
• Deallocate virtual machines during off hours.
• Delete unused resources.
• Migrate from IaaS to PaaS services.

Each component has it’s own Service-level agreements. Because using multiple components adds an extra level of complexity and slightly increases the risk of failure, to calculate the overall SLA for your services is to combine them by multiplying the SLA of each component. To improve the availability of the application, avoid having any single points of failure. So instead of adding more virtual machines, you can deploy one or more extra instances of the same virtual machine across the different availability zones in the same Azure region.