Blog

How to use Azue ARC-enabled servers with managed identity to access to Azure Storage Account

In this demo we will show how to use Azure ARC-enabled servers with managed identity to access to Azure Storage Account.

Prerequisites

• An Azure subscription. If you don't have an Azure subscription, create a free account before you begin.

Required permissions

You'll need the following Azure built-in roles for different aspects of managing connected machines:

• To onboard machines, you must have the Azure Connected Machine Onboarding or Contributor role for the resource group where you're managing the servers.
• To read, modify, and delete a machine, you must have the Azure Connected Machine Resource Administrator role for the resource group.
• To select a resource group from the drop-down list when using the Generate script method, you'll also need the Reader role for that resource group (or another role that includes Reader access).

Register Azure resource providers

To use Azure Arc-enabled servers with managed identity, you need to register the following resource providers:

az account set --subscription "{Your Subscription Name}"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'

Networking requirements

The Azure Connected Machine agent for Linux and Windows communicates outbound securely to Azure Arc over TCP port 443. In this demo, we have use Azure Private Link.

Azure ARC-enabled enabled server

We use Use Azure Private Link to securely connect networks to Azure Arc-enabled servers to achieve this.

Some tips:

• If you have any issue registerin de VM: generate a script to register a machine with Azure Arc following that instructions here

• If you have an error that says "Path C:\ProgramData\AzureConnectedMachineAgent\Log\himds.log is busy. Retrying..." you can use the following command to resolve it if you know that you are doing:

 (get-wmiobject -class win32_product | where {$_.name -like "Azure *"}).uninstall() 

$Env:PEname = "myprivatelink"
$Env:resourceGroup = "myResourceGroup"
$file = "C:\Windows\System32\drivers\etc\hosts"

$gisfqdn = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query '[0].privateDnsZoneConfigs[0].recordSets[0].fqdn' -o json).replace('.privatelink','').replace("`"","")
$gisIP = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[0].recordSets[0].ipAddresses[0] -o json).replace("`"","")
$hisfqdn = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[0].recordSets[1].fqdn -o json).replace('.privatelink','').replace("`"","")
$hisIP = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[0].recordSets[1].ipAddresses[0] -o json).replace('.privatelink','').replace("`"","")
$agentfqdn = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[1].recordSets[0].fqdn -o json).replace('.privatelink','').replace("`"","")
$agentIp = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[1].recordSets[0].ipAddresses[0] -o json).replace('.privatelink','').replace("`"","")
$gasfqdn = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[1].recordSets[1].fqdn -o json).replace('.privatelink','').replace("`"","")
$gasIp = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[1].recordSets[1].ipAddresses[0] -o json).replace('.privatelink','').replace("`"","")
$dpfqdn = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[2].recordSets[0].fqdn -o json).replace('.privatelink','').replace("`"","")
$dpIp = (az network private-endpoint dns-zone-group list --endpoint-name $Env:PEname --resource-group $Env:resourceGroup -o json --query [0].privateDnsZoneConfigs[2].recordSets[0].ipAddresses[0] -o json).replace('.privatelink','').replace("`"","")

$hostfile += "$gisIP $gisfqdn"
$hostfile += "$hisIP $hisfqdn"
$hostfile += "$agentIP $agentfqdn"
$hostfile += "$gasIP $gasfqdn"
$hostfile += "$dpIP $dpfqdn"

Storage Account configuration

Create a Storage Account with static website enabled

$resourceGroup = "myResourceGroup"
$location = "eastus"
$storageAccount = "mystorageaccount"
$indexDocument = "index.html"
az group create --name $resourceGroup --location $location
az storage account create --name $storageAccount --resource-group $resourceGroup --location $location --sku Standard_LRS
az storage blob service-properties update --account-name $storageAccount --static-website --index-document $indexDocument

Add private endpoints to the storage accoun for blob and static website

$resourceGroup = "myResourceGroup"
$storageAccount = "mystorageaccount"
$privateEndpointName = "myprivatelink"
$location = "eastus"
$vnetName = "myVnet"
$subnetName = "mySubnet"
$subscriptionId = "{subscription-id}"
az network private-endpoint create --name $privateEndpointName --resource-group $resourceGroup --vnet-name $vnetName --subnet $subnetName --private-connection-resource-id "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Storage/storageAccounts/$storageAccount" --group-id blob --connection-name $privateEndpointName --location $location
az network private-endpoint create --name $privateEndpointName --resource-group $resourceGroup --vnet-name $vnetName --subnet $subnetName --private-connection-resource-id "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Storage/storageAccounts/$storageAccount" --group-id web --connection-name $privateEndpointName --location $location

Disable public access to the storage account except for your ip

$resourceGroup = "myResourceGroup"
$storageAccount = "mystorageaccount"
$ipAddress = "myIpAddress"
az storage account update --name $storageAccount --resource-group $resourceGroup --bypass "AzureServices,Logging,Metrics" --default-action Deny
az storage account network-rule add --account-name $storageAccount --resource-group $resourceGroup --ip-address $ipAddress

Assign the Storage Blob Data Contributor role to the managed identity of the Azure ARC-enabled server

$resourceGroup = "myResourceGroup"
$storageAccount = "mystorageaccount"
$serverName = "myserver"
$managedIdentity = az resource show --resource-group $resourceGroup --name $serverName --resource-type "Microsoft.HybridCompute/machines" --query "identity.principalId" --output tsv
az role assignment create --role "Storage Blob Data Contributor" --assignee-object-id $managedIdentity --scope "/subscriptions/{subscription-id}/resourceGroups/$resourceGroup/providers/Microsoft.Storage/storageAccounts/$storageAccount"

Download azcopy, install it and copy something to $web in the storage account

Download azcopy in the vm

Invoke-WebRequest -Uri "https://aka.ms/downloadazcopy-v10-windows" -OutFile AzCopy.zip

Expand-Archive AzCopy.zip -DestinationPath $env:ProgramFiles

$env:Path += ";$env:ProgramFiles\azcopy"

Copy something to $web in the storage account

$storageAccount = "mystorageaccount"
$source = "C:\Users\Public\Documents\myFile.txt"
$destination = "https://$storageAccount.blob.core.windows.net/\$web/myFile.txt"
azcopy login --identity
azcopy copy $source $destination

Now you can check the file in the static website of the storage account.

Azure ARC

Azure ARC is a service that extends Azure management capabilities to any infrastructure. It allows you to manage resources running on-premises, at the edge, or in multi-cloud environments using the same Azure management tools, security, and compliance policies that you use in Azure. Azure ARC enables you to manage and govern your resources consistently across all environments, providing a unified control plane for your hybrid cloud infrastructure. Let's explore how Azure ARC works and how you can leverage it to manage your resources effectively.

Azure ARC Overview

Azure ARC is a service that extends Azure management capabilities to any infrastructure. It allows you to manage resources running outside of Azure using the same Azure management tools, security, and compliance policies that you use in Azure. Azure ARC provides a unified control plane for managing resources across on-premises, multi-cloud, and edge environments, enabling you to govern your resources consistently.

Azure ARC enables you to:

• Manage resources: Azure ARC allows you to manage resources running on-premises, at the edge, or in multi-cloud environments using Azure management tools like Azure Policy, Azure Monitor, and Microsoft Defender for Cloud.
• Governance: Azure ARC provides a unified control plane for managing and governing resources across all environments, enabling you to enforce security and compliance policies consistently.
• Security: Azure ARC extends Azure security capabilities to resources running outside of Azure, enabling you to protect your resources with Azure security features like Azure Security Center and Azure Defender.
• Compliance: Azure ARC enables you to enforce compliance policies across all environments, ensuring that your resources meet regulatory requirements and organizational standards.

Azure ARC Components

Azure ARC consists of the following components:

• Azure ARC-enabled servers: Azure ARC-enabled servers allow you to manage and govern servers running on-premises or at the edge using Azure management tools. You can connect your servers to Azure ARC to manage them using Azure Policy, Azure Monitor, and Microsoft Defender for Cloud.
• Azure ARC-enabled Kubernetes clusters: Azure ARC-enabled Kubernetes clusters allow you to manage and govern Kubernetes clusters running on-premises or in other clouds using Azure management tools. You can connect your Kubernetes clusters to Azure ARC to manage them using Azure Policy, Azure Monitor, and Microsoft Defender for Cloud.
• Azure ARC-enabled data services: Azure ARC-enabled data services allow you to manage and govern data services running on-premises or in other clouds using Azure management tools. You can connect your data services to Azure ARC to manage them using Azure Policy, Azure Monitor, and Microsoft Defender for Cloud.
• SQL Server enabled by Azure Arc: SQL Server enabled by Azure Arc allows you to run SQL Server on any infrastructure using Azure management tools. You can connect your SQL Server instances to Azure ARC to manage them using Azure Policy, Azure Monitor, and Microsoft Defender for Cloud.
• Azure Arc-enabled private clouds: Azure Arc resource bridge hosts other components such as custom locations, cluster extensions, and other Azure Arc agents in order to deliver the level of functionality with the private cloud infrastructures it supports.

Azure ARC Use Cases

Azure ARC can be used in a variety of scenarios to manage and govern resources across on-premises, multi-cloud, and edge environments. Some common use cases for Azure ARC include:

• Hybrid cloud management: Azure ARC enables you to manage resources consistently across on-premises, multi-cloud, and edge environments using the same Azure management tools and policies.
• Security and compliance: Azure ARC allows you to enforce security and compliance policies consistently across all environments, ensuring that your resources meet regulatory requirements and organizational standards.
• Resource governance: Azure ARC provides a unified control plane for managing and governing resources across all environments, enabling you to enforce policies and monitor resource health and performance.
• Application modernization: Azure ARC enables you to manage and govern Kubernetes clusters and data services running on-premises or in other clouds, allowing you to modernize your applications and infrastructure.

Getting Started with Azure ARC

To get started with Azure ARC, you need to:

1. Connect your resources: Connect your servers, Kubernetes clusters, or data services to Azure ARC using the Azure ARC agent.
2. Manage your resources: Use Azure management tools like Azure Policy, Azure Monitor, and Microsoft Defender for Cloud to manage and govern your resources consistently across all environments.
3. Enforce security and compliance: Use Azure security features like Microsoft Defender for Cloud to protect your resources and enforce security and compliance policies.

By leveraging Azure ARC, you can manage and govern your resources consistently across on-premises, multi-cloud, and edge environments, providing a unified control plane for your hybrid cloud infrastructure. Azure ARC enables you to enforce security and compliance policies consistently, ensuring that your resources meet regulatory requirements and organizational standards.

Conclusion

Azure ARC is a powerful service that extends Azure management capabilities to any infrastructure, enabling you to manage and govern resources consistently across on-premises, multi-cloud, and edge environments. By leveraging Azure ARC, you can enforce security and compliance policies consistently, ensuring that your resources meet regulatory requirements and organizational standards. Azure ARC provides a unified control plane for managing and governing resources, enabling you to manage your hybrid cloud infrastructure effectively.

For more information on Azure ARC, visit the Azure ARC documentation.

Microsoft Azure Certifications

Microsoft offers a wide range of certifications for IT professionals who want to demonstrate their expertise in Microsoft technologies. These certifications cover a variety of topics, including Azure, Office 365, Windows Server, and more.

Microsoft divide this certifications into different categories, such as:

• Infrastructure
• Data and AI
• Digital app and innovation
• Modern work
• Business applications
• Security

Inside of each category, you can find different certification levels:

• Fundamentals: This level is designed for individuals who are new to the technology and want to demonstrate their knowledge of the basics.
• Role-based: This level is designed for individuals who want to demonstrate their expertise in a specific role, such as Azure Administrator or Data Engineer.
• Specialty: This level is designed for individuals who want to demonstrate their expertise in a specific skill, such as Azure Virtual Desktop or Azure SAP.

In the case of role-based certifications, Microsoft offers different levels of certification, such as:

• Associate: This level is designed for individuals who have some experience in the technology and want to demonstrate their expertise in a specific role.
• Expert: This level is designed for individuals who have extensive experience in the technology and want to demonstrate their expertise in a specific role.

Allways is a good idea to start with the fundamentals certifications, and then move on to the role-based certifications that are relevant to your career goals.

In the majority of cases, you need associate certifications to get expert certifications.

Azure Certifications

Here's a table summarizing the Azure Certifications and their description:

You can find more information about Microsoft certifications on the Microsoft Certification Poster and in the Microsoft Learning website.

Privileged Access Management (PAM) Strategy with Microsoft Entra ID and some Azure Services

Today, I'd like to share a brief of a recommended strategy for Privileged Access Management (PAM) of other vendors with Microsoft Entra ID and some Azure Services. This strategy is divided into seven phases:

graph LR;
    A[Phase 1: Set Policy] 
    C[Phase 2: The Process of Discovery]
    E[Phase 3: Protect Credentials]
    G[Phase 4: Secure Privileged Access]
    I[Phase 5: Least Privilege]
    K[Phase 6: Control All Applications]
    M[Phase 7: Detect and Respond]

    A-->C
    C-->E
    E-->G
    G-->I
    I-->K
    K-->M
    M-->A

    classDef phase fill:#f9f,stroke:#333,stroke-width:2px;
    class A,C,E,G,I,K,M phase;

Phase 1: Set Policy

The first step in any PAM strategy is to establish a clear policy. This policy should define who has access to what, when they have access, and what they can do with that access. It should also include guidelines for password management and multi-factor authentication. For example:

• Define clear access control policies.
• Establish guidelines for password management and multi-factor authentication.
• Regularly review and update the policy to reflect changes in the organization.

How to implement this:

• Use Azure Policy to define and manage policies for your Azure environment.
• Use Microsoft Entra multifactor authentication for implementing multi-factor authentication.

Phase 2: The Process of Discovery

In this phase, we identify all the privileged accounts across the organization. This includes service accounts, local administrative accounts, domain administrative accounts, emergency accounts, and application accounts. For example:

• Use automated tools to identify all privileged accounts across the organization.
• Regularly update the inventory of privileged accounts.
• Identify any accounts that are no longer in use and deactivate them.

How to implement this:

• Use Microsoft Entra Privileged Identity Management to discover, restrict and monitor administrators and their access to resources and provide just-in-time access when needed.

Phase 3: Protect Credentials

Once we've identified all privileged accounts, we need to ensure that these credentials are stored securely. This could involve using a secure vault, regularly rotating passwords, and using unique passwords for each account. For example:

• Store credentials in a secure vault.
• Implement regular password rotation.
• Use unique passwords for each account.

How to implement this:

• Use Azure Key Vault to safeguard cryptographic keys and other secrets used by your apps and services and rotate secrets regularly.
• Implement Microsoft Entra ID Password Protection to protect against weak passwords that can be easily guessed or cracked.

Phase 4: Secure Privileged Access

Securing privileged access involves implementing controls to prevent unauthorized access. This could include limiting the number of privileged accounts, implementing least privilege, and using just-in-time access. For example:

• Limit the number of privileged accounts.
• Implement just-in-time access, where access is granted only for the duration of a task.
• Use session recording and monitoring for privileged access.

How to implement this:

• Use Microsoft Entra ID Conditional Access to enforce controls on the access to apps in your environment based on specific conditions.
• Implement Microsoft Entra Privileged Identity Management for just-in-time access.

Phase 5: Least Privilege

The principle of least privilege involves giving users the minimum levels of access — or permissions — they need to complete their job functions. By limiting the access rights of users, the risk of a security breach is reduced. For example:

• Implement role-based access control (RBAC) in Azure to grant the minimum necessary access to users.
• Regularly review user roles and access rights.
• Implement a process for revoking access when it's no longer needed.

How to implement this:

• Implement Role-Based Access Control (RBAC) in Azure to grant the minimum necessary access to users.
• Use Microsoft Entra ID Access Reviews to efficiently manage group memberships, access to enterprise applications, and role assignments.

Phase 6: Control All Applications

In this phase, we ensure that all applications, whether on-premises or in the cloud, are controlled and monitored. This includes implementing application control policies and monitoring application usage. For example:

• Implement application control policies that dictate what applications can be run on systems.
• Monitor application usage and block unauthorized applications.
• Regularly update and patch all applications to reduce vulnerabilities.

How to implement this:

• Use Microsoft Entra Application Proxy to control and secure access to on-premises and cloud apps.
• Enable Change Tracking and Inventory in Azure Automation to track changes to your Azure VMs. Use desired state configuration to ensure that your VMs are configured correctly.
• Implement Microsoft Intune to manage and secure your devices and applications.

Phase 7: Detect and Respond

The final phase involves setting up systems to detect and respond to any suspicious activity. This could involve setting up alerts for unusual activity, regularly auditing access logs, and having a response plan in place for when a breach occurs. For example:

• Set up alerts for unusual activity.
• Regularly audit access logs.
• Have a response plan in place for when a breach occurs, including steps for containment, eradication, and recovery.

How to implement this:

• Use Microsoft Defender for Cloud for increased visibility into your security state and to detect and respond to threats.
• Implement Azure Sentinel, Microsoft's cloud-native SIEM solution, for intelligent security analytics.

By following these seven phases, you can create a robust PAM strategy that protects your organization from security breaches and helps you maintain compliance with various regulations.

Remember, a good PAM strategy is not a one-time effort but an ongoing process that needs to be regularly reviewed and updated. Microsoft and Azure services provide a robust set of tools to help you implement and manage your PAM strategy effectively.

Azure Policy Management Best Practices

1. Version Control: Store your policy definitions in a version-controlled repository. This practice ensures that you can track changes, collaborate effectively, and roll back to previous versions if needed.

2. Automated Testing: Incorporate policy testing into your CI/CD pipelines. Automated tests can help you catch policy violations early in the development process, reducing the risk of non-compliance.

3. Policy Documentation: Document your policies clearly, including their purpose, scope, and expected behavior. This documentation helps stakeholders understand the policies and their impact on Azure resources.

4. Policy Assignment: Assign policies at the appropriate scope (e.g., Management Group, Subscription, Resource Group) based on your organizational requirements. Avoid assigning policies at a broader scope than necessary to prevent unintended consequences.

5. Policy Exemptions: Use policy exemptions judiciously. Document the reasons for exemptions and periodically review them to ensure they are still valid.

6. Policy Enforcement: Monitor policy compliance regularly and take corrective action for non-compliant resources. Use Azure Policy's built-in compliance reports and alerts to track policy violations.

7. Policy Remediation: Implement automated remediation tasks for policy violations where possible. Azure Policy's remediation tasks can help bring non-compliant resources back into compliance automatically.

8. Policy Monitoring: Continuously monitor policy effectiveness and adjust policies as needed. Regularly review policy violations, exemptions, and compliance trends to refine your policy implementation.

9. Policy Governance: Establish a governance framework for Azure Policy that includes policy creation, assignment, monitoring, and enforcement processes. Define roles and responsibilities for policy management to ensure accountability.

10. Policy Lifecycle Management: Define a policy lifecycle management process that covers policy creation, testing, deployment, monitoring, and retirement. Regularly review and update policies to align with changing organizational requirements.

11. Unique source of truth: Use EPAC, terraform, ARM,.... but use an unique source of truth for your policies.

By following these best practices, you can effectively manage Azure policies and ensure compliance with organizational standards across your Azure environment. Azure Policy plays a crucial role in maintaining governance, security, and compliance, and adopting these practices can help you maximize its benefits.

Enterprise Azure Policy as Code (EPAC)

Enterprise Azure Policy as Code (EPAC) is a powerful tool that allows organizations to manage Azure Policies as code in a git repository. It's designed for medium and large organizations with a larger number of Policies, Policy Sets, and Assignments, and/or complex deployment scenarios.

Key Features of EPAC

• Single and multi-tenant policy deployment: EPAC supports both single and multi-tenant policy deployments, making it versatile for different organizational structures.
• Easy CI/CD Integration: EPAC can be easily integrated with any CI/CD tool, which makes it a great fit for DevOps environments.
• Operational scripts: EPAC includes operational scripts to simplify operational tasks.
• Integration with Azure Landing Zones: EPAC provides a mature integration with Azure Landing Zones. Utilizing Azure Landing Zones together with EPAC is highly recommended.

Who Should Use EPAC?

EPAC is designed for medium and large organizations with a larger number of Policies, Policy Sets, and Assignments, and/or complex deployment scenarios. However, smaller organizations implementing fully-automated DevOps deployments of every Azure resource (known as Infrastructure as Code) can also benefit from EPAC.

How Does EPAC Work?

EPAC works by deploying all policies and policy assignments defined in the EPAC repository to the deploymentRootScope and its children. It takes possession of all Policy Resources at the deploymentRootScope and its children.

The process depicted in the image involves three key scripts that manage a deployment sequence. Here's a breakdown of the process:

1. Definition Files: The process begins with various definition files in JSON, CSV, or XLSX formats. These files contain policy definitions, policy set (initiative) definitions, assignments, exemptions, and global settings.

2. Planning Script: The Build-DeploymentPlans.ps1 script uses these definition files to create a deployment plan. This script requires Resource Policy Reader privileges.

3. Deployment Scripts: The deployment plan is then used by two deployment scripts:

4. Deploy-PolicyPlan.ps1: This script deploys Policy resources using the policy-plan.json file from the deployment plan. It requires Resource Policy Contributor privileges.
5. Deploy-RolesPlan.ps1: This script deploys Role Assignments using the roles-plan.json file from the deployment plan. It requires User Access Administrator privileges.

The process includes optional approval gates after each deployment step. These are typically used in production environments to ensure each deployment step is reviewed and approved before moving to the next.

Conclusion

EPAC is a robust solution for managing Azure Policies as code. It offers a high level of assurance in highly controlled and sensitive environments, and a means for the development, deployment, management, and reporting of Azure policy at scale.

References

• EPAC Documentation

Manage Azure Policy GitHub Action

It's recommended to review:

• Azure Policy
• Writing Your First Policy in Azure with Portal
• Writing Your First Initiative in Azure with Portal

Overview

The Manage Azure Policy GitHub Action empowers you to enforce organizational standards and assess compliance at scale using Azure policies. With this action, you can seamlessly integrate policy management into your CI/CD pipelines, ensuring that your Azure resources adhere to the desired policies.

Key Features

1. Customizable Workflows: GitHub workflows are highly customizable. You have complete control over the sequence in which Azure policies are rolled out. This flexibility enables you to follow safe deployment practices and catch regressions or bugs well before policies are applied to critical resources.

2. Azure Login Integration: The action assumes that you've already authenticated using the Azure Login action. Make sure you've logged in using an Azure service principal with sufficient permissions to write policies on selected scopes. Refer to the full documentation of Azure Login Action for details on permissions.

3. Policy File Structure: Your policy files should be organized in a specific directory structure within your GitHub repository. Here's how it should look:

   |- policies/
      |- <policy1_name>/
         |- policy.json
         |- assign.<name1>.json
         |- assign.<name2>.json
         ...
      |- <policy2_name>/
         |- policy.json
         |- assign.<name1>.json
         |- assign.<name2>.json
         ...
   

   • Each policy resides in a subfolder under the policies/ directory.
   • The policy.json file contains the policy definition.
   • Assignment files (e.g., assign.<name1>.json) specify how the policy is applied.

4. Inputs for the Action:

   • Paths: Specify the mandatory path(s) to the directory containing your Azure policy files.

Sample Workflow

Here's an example of how you can apply policies at the Management Group scope using the Manage Azure Policy action:

name: 'Test Policy'
on:
  push:
    branches: 
    - "*" 
    paths: 
     - 'policies/**'
     - 'initiatives/**'
  workflow_dispatch:

jobs:
  apply-azure-policy:    
    runs-on: ubuntu-latest
    steps:
    # Azure Login
    - name: Login to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
        allow-no-subscriptions: true

    - name: Checkout
      uses: actions/checkout@v2 

    - name: Create or Update Azure Policies
      uses: azure/manage-azure-policy@v0
      with:      
        paths:  |                
          policies/**
          initiatives/**
        assignments:  |
          assign.*_testRG_*.json

Remember to replace the placeholder values (such as secrets.AZURE_CREDENTIALS) with your actual configuration, you can follow this instructions to create a service principal and get the credentials: Create a service principal and get the credentials

Example of use for Policy

In this example we define all our policies and initiatives at management group level and assign to resource group, and we have a policy that requires a specific tag and its value.

You need to create a folder structure like this:

|- policies/
   |- require-tag-and-its-value/
      |- policy.json
      |- assign.testRG_testazurepolicy.json
|- initiatives/
   |- initiative1/
      |- policyset.json
      |- assign.testRG_testazurepolicy.json

policies

policy.json

{
    "id": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyDefinitions/requite-tag-and-its-value",
    "type": "Microsoft.Authorization/policyDefinitions",
    "name": "requite-tag-and-its-value",
    "properties": {
        "displayName": "Require a tag and its value",
        "policyType": "Custom",
        "mode": "Indexed",
        "description": "This policy requires a specific tag and its value.",
        "metadata": {
            "category": "Tags"
        },
        "parameters": {
            "tagName": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Name",
                    "description": "Name of the tag, such as 'environment'"
                }
            },
            "tagValue": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Value",
                    "description": "Value of the tag, such as 'production'"
                }
            }
        }
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "[concat('tags[', parameters('tagName'), ']')]",
                    "equals": "[parameters('tagValue')]"
                    }
                },
            "then": {
                "effect": "deny"
            }
        }
    }

assign.testRG_testazurepolicy.json

{
    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-testazurepolicy/providers/Microsoft.Authorization/policyAssignments/599a2c3a1a3b1f8b8e547b3e",
    "type": "Microsoft.Authorization/policyAssignments",
    "name": "599a2c3a1a3b1f8b8e547b3e",     
    "properties": {
        "description": "This policy audits the presence of a specific tag and its value.",
        "displayName": "Require a tag and its value",
        "parameters": {
            "tagName": {
              "value": "environment"
            },
            "tagValue": {
              "value": "production"
            }
          },
          "nonComplianceMessages": [
            {
              "message": "This resource is not compliant with the policy. Please apply the required tag and its value."
            }
          ],
          "enforcementMode": "Default",
          "policyDefinitionId": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyDefinitions/requite-tag-and-its-value",
          "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-testazurepolicy"
    }    
}

initiatives

policyset.json

{
    "id": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policySetDefinitions/initiative1",
    "type": "Microsoft.Authorization/policySetDefinitions",
    "name": "initiative1",
    "properties": {
        "displayName": "Initiative 1",
        "description": "This initiative contains a set of policies for testing.",
        "metadata": {
            "category": "Test"
        },
        "parameters": {
            "tagName": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Name",
                    "description": "Name of the tag, such as 'environment'"
                }
            },
            "tagValue": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Value",
                    "description": "Value of the tag, such as 'production'"
                }
            }
        },
        "policyDefinitions": [
            {
                "policyDefinitionId": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyDefinitions/requite-tag-and-its-value",
                "parameters": {
                    "tagName": {
                        "value": "[parameters('tagName')]"
                    },
                    "tagValue": {
                        "value": "[parameters('tagValue')]"
                    },
                    "effect": {
                        "value": "Deny"
                    }
                }
            }
        ]
    }
}

assign.testRG_testazurepolicyset.json

{
    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-testazurepolicy/providers/Microsoft.Authorization/policyAssignments/ada0f4a34b09cf6ad704cc62",
    "type": "Microsoft.Authorization/policyAssignments",
    "name": "ada0f4a34b09cf6ad704cc62",     
    "properties": {
        "description": "This initiative audits the presence of a specific tag and its value.",
        "displayName": "Require a tag and its value",
        "parameters": {
            "tagName": {
              "value": "environment"
            },
            "tagValue": {
              "value": "production"
            }
          },
          "nonComplianceMessages": [
            {
              "message": "This resource is not compliant with the policy. Please apply the required tag and its value."
            }
          ],
          "enforcementMode": "Default",
          "policyDefinitionId": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policySetDefinitions/requite-tag-and-its-value",
          "scope": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-testazurepolicy"
    }    
}

Conclusion

By incorporating the Manage Azure Policy action into your GitHub workflows, you can seamlessly enforce policies, maintain compliance, and ensure the robustness of your Azure resources, although it has its drawbacks, it is one more step compared to a portal. Later we will see the deployment with a more robust tool: EPAC

Learn more about Azure Policies and explore the action on the GitHub Marketplace.

Writing Your First Policy in Azure with Portal

Azure Policy is a service in Azure that you use to create, assign and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.

In this post, we'll walk through the steps of creating your first policy in Azure.

Prerequisites

1. An active Azure subscription.
2. Access to Azure portal.

Step 1: Open Azure Policy

• Login to the Azure Portal.
• In the left-hand menu, click on All services.
• In the All services blade, search for Policy.

Step 2: Create a New Policy Definition

• Click on Definitions under the Authoring section.
• Click on + Policy definition.

Step 3: Fill Out the Policy Definition

You will need to fill out several fields:

• Definition location: The location where the policy is stored.
• Name: This is a unique name for your policy.
• Description: A detailed description of what the policy does.
• Category: You can categorize your policy for easier searching and filtering.

The most important part of the policy definition is the policy rule itself. The policy rule is where you describe the logic that enforces the policy.

Here's an example of a simple policy rule that ensures all indexed resources have tags and deny creation or update if they do not.

{
    "properties": {
        "displayName": "Require a tag and its value",
        "policyType": "Custom",
        "mode": "Indexed",
        "description": "This policy requires a specific tag and its value.",
        "metadata": {
            "category": "Tags"
        },
        "parameters": {
            "tagName": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Name",
                    "description": "Name of the tag, such as 'environment'"
                }
            },
            "tagValue": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Value",
                    "description": "Value of the tag, such as 'production'"
                }
            }
        },
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "[concat('tags[', parameters('tagName'), ']')]",
                    "equals": "[parameters('tagValue')]"
                    }
                },
            "then": {
                "effect": "deny"
            }
        }
    }

But, in portal, you can add properties directly in the form but you can't add displayName, policyType and metadata because they are added by portal itself, so you can add only mode,parameters and policyRule, Policy definition could be like this:

• Definition location: Tenant Root Group
• Name: Require a tag and its value
• Description: This policy requires a specific tag and its value.
• Category: Tags
• POLICY RULE:

{

        "mode": "Indexed", 
        "parameters": {
            "tagName": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Name",
                    "description": "Name of the tag, such as 'environment'"
                }
            },
            "tagValue": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Value",
                    "description": "Value of the tag, such as 'production'"
                }
            }
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "[concat('tags[', parameters('tagName'), ']')]",
                    "equals": "[parameters('tagValue')]"
                    }
                },
            "then": {
                "effect": "deny"
            }
        }
}

Once you've filled out all the fields and written your policy rule, click on Save.

Step 4: Assign the Policy

• Go back to the Policy service in the Azure portal.
• Click on Assignments under the Authoring section.
• Click on + Assign Policy.
• In Basics, fill out the following fields:
  • Scope
    • Scope: Select the scope where you want to assign the policy.
    • Exclusions: Add any exclusions if needed.
  • Basics
    • Policy definition: Select the policy you created.
    • Assignment name: A unique name for the assignment.
    • Description: A detailed description of the assignment.
    • Policy enforcement: Enabled.
• In Parameters: Fill out any parameters needed for the policy.
• In Non-compliance message: A message to display when a resource is non-compliant.
• Click on Review + create: Review the assignment and click on Create.

Congratulations! You've just created and assigned your first policy in Azure. It will now evaluate any new or existing resources within its scope.

Remember, Azure Policy is a powerful tool for maintaining compliance and managing your resources at scale. Happy coding!

Azure Policy, defintion schema

This is the schema for the Azure Policy definition:

{
    "properties": {
        "displayName": {
            "type": "string",
            "description": "The display name of the policy definition."
        },
        "policyType": {
            "type": "string",
            "description": "The policy type of the policy definition."
        },
        "mode": {
            "type": "string",
            "description": "The mode of the policy definition."
        },
        "description": {
            "type": "string",
            "description": "The description of the policy definition."
        },
        "mode": {
            "type": "string",
            "description": "The mode of the policy definition."
        },
        "metadata": {
            "type": "object",
            "description": "The metadata of the policy definition."
        },
        "parameters": {
            "type": "object",
            "description": "The parameters of the policy definition."
        },
        "policyRule": {
            "type": "object",
            "description": "The policy rule of the policy definition. If/then rule."
        }       

    }
}

You can see other elements in the schema like id, type, and name, It's depens of how you want to deploy the policy definition.

Full schema is in Azure Policy definition schema.

Example

Here is an example of a policy definition:

{
    "properties": {
        "displayName": "Require a tag and its value",
        "policyType": "Custom",
        "mode": "Indexed",
        "description": "This policy requires a specific tag and its value.",
        "metadata": {
            "category": "Tags"
        },
        "parameters": {
            "tagName": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Name",
                    "description": "Name of the tag, such as 'environment'"
                }
            },
            "tagValue": {
                "type": "String",
                "metadata": {
                    "displayName": "Tag Value",
                    "description": "Value of the tag, such as 'production'"
                }
            }
        },
        "policyRule": {
            "if": {
                "field": "[concat('tags[', parameters('tagName'), ']')]",
                "exists": "false"
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}

This policy definition requires a specific tag and its value. If the tag does not exist, the policy denies the action.

How you can see, the most important part of the policy definition is the policy rule.

Conclusion

Understanding the schema for Azure Policy definitions is essential for creating and managing policies effectively. By defining the necessary attributes and rules, you can enforce compliance, security, and operational standards across your Azure environment. Leveraging the Azure Policy definition schema allows you to tailor policies to your organization's specific requirements and ensure consistent governance practices.

References

• Azure Policy definition schema
• Azure Policy

Writing Your First Initiative with Portal

Azure Policy is a service in Azure that you use to create, assign and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.

In this post, we'll walk through the steps of creating your first initiative in Azure.

Prerequisites

1. An active Azure subscription.
2. Access to Azure portal.
3. Azure Policy defined in your subscription, if you don't have one, you can follow the steps in Writing Your First Policy in Azure with Portal.

Step 1: Open Azure Policy

• Login to the Azure Portal.
• In the left-hand menu, click on All services.
• In the All services blade, search for Policy.

Step 2: Create a New Initiative Definition

• Click on Defitinions under the Authoring section.
• Click on + Initiative definition.

Step 3: Fill Out the Initiative Definition

You will need to fill out several fields:

• Basics:
• Initiative location: The location where the initiative is stored.
• Name: This is a unique name for your initiative.
• Description: A detailed description of what the initiative does.
• Category: You can categorize your initiative for easier searching and filtering.
• Policies:
• Add policy definition(s): Here you can add the policies that will be part of the initiative.
• Initiative parameters:
• Add parameter: Here you can add parameters that will be used in the initiative.
• Policy parameters:

• Add policy parameter: Here you can add parameters that will be used in the policies that are part of the initiative. You can use the parameters defined in the initiative as value for different policies.

• Click on Review + create: Review the assignment and click on Create.

Step 4: Assign the Initiative

• Go to Policy again.
• Go to Assignments under the Authoring section.
• Click on + Assign initiative.

You will need to fill out several fields: - Basics: - Scope: Select the scope where you want to assign the initiative. - Basics: - Initiative definition: Select the initiative you just created. - Assignment name: A unique name for the assignment. - Description: A detailed description of what the assignment does. - Policy enforcement: Choose the enforcement mode for the assignment. - Parameters: - Add parameter: Initialize parameters that will be used in the initiative. - Remediation: - Auto-remediation: Enable or disable auto-remediation. That means that if a resource is not compliant, it will be remediated automatically. In other post it will be explained how to create a remediation task. - Non-compliance messages: - Non-compliance message: Define a message that will be shown when a resource is not compliant.

• Click on Review + create: Review the assignment and click on Create.

Conclusion

Creating an initiative in Azure Policy is a powerful way to group policies together and enforce them across your Azure environment. By defining initiatives, you can streamline governance, simplify compliance management, and ensure consistent application of policies to your resources. Start creating initiatives today to enhance the security, compliance, and operational efficiency of your Azure environment.