Azureheads #23 | Clusters in the Cloud

My virtual presentation at the #23 Azureheads virtual metup about the Azure Shared Disks feature.

You can view my PowerPoint presentation here

And the video recording at my youtube channel

The post Azureheads #23 | Clusters in the Cloud appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Azure Failover Cluster with Shared Disk

Recently MIcrosoft Azure anounched the preview feature “Shared Disk”. The Shared Disk can be attached at two Azure MVs at the same time. The purpose is to create SQL Server Failover Cluster Instances (FCI), Scale-out File Server (SoFS), File Server for General Use (IW workload), Remote Desktop Server User Profile Disk (RDS UPD) and  SAP ASCS/SCS. More or less we can have a failover cluster at Azure VMs like haveing an on-premises failover cluster with shared storage.

At this post I will demostrate step-by-step how to create a Failover Cluster in Azure with two Azure VMs and a Shared Disk.

Since this is a preview feature at the time I am wroting this post, we need to sign up for our preview.

Once we have the confiration that the Shared Disk preview is enabled at our Subscription, we can proceed and create our Shared Disk. Currently this can be done only by using an ARM Template, in order to define the “maxShares”: “[parameters(‘maxShares’)]” disk property. This property defines in how VMs can this Disk be attached.

Other limitations of the preview are:

• Currently only available with premium SSDs.
• Currently only supported in the West Central US region.
• All virtual machines sharing a disk must be deployed in the same proximity placement groups.
• Can only be enabled on data disks, not OS disks.
• Only basic disks can be used with some versions of Windows Server Failover Cluster, for details see
• Failover clustering hardware requirements and storage options.
• ReadOnly host caching is not available for premium SSDs with maxShares>1.
• Availability sets and virtual machine scale sets can only be used with FaultDomainCount set to 1.
• Azure Backup and Azure Site Recovery support is not yet available.

From the Azure Portal search and open the “Template Deployment”

Select the “Build your own template in the editor”

And paste the Shared Disk Json at the template

The Shared Disk Json:

{ 
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "dataDiskName": {
      "type": "string",
      "defaultValue": "mySharedDisk"
    },
    "dataDiskSizeGB": {
      "type": "int",
      "defaultValue": 1024
    },
    "maxShares": {
      "type": "int",
      "defaultValue": 2
    }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/disks",
      "name": "[parameters('dataDiskName')]",
      "location": "[resourceGroup().location]",
      "apiVersion": "2019-07-01",
      "sku": {
        "name": "Premium_LRS"
      },
      "properties": {
        "creationData": {
          "createOption": "Empty"
        },
        "diskSizeGB": "[parameters('dataDiskSizeGB')]",
        "maxShares": "[parameters('maxShares')]"
      }
    }
  ] 
}

After the Template Deployment is comleted you will see a normal disk at the Resoruce Group.

Create the VMs

Create both VMs like any normal Azure VM creation. I created wto Windows Server 2016 VMs. Both VMs must be added to the same availability set (Fault Domain = 1), in order to add them behing an internal load balancer and they must be added to the same Proximity Placement Group.

To create a Proximity Placement Group, just create a new resource, search for “Proximity Placement Group” and press create. Just provide a name for the PPG and the location, that must be the same as the Disk.

And select it at the VM creation wizard:

Attach the Sahred Disk to Both VMs

When attaching the Shared Disk to the VMs you will see the “disk shares used” This reports in how many VMs this disk is attached.

Once the VMs are ready we can start the Failover Cluster process. We need to add both VMs to the Domain. Then go tot he Disk Management and bring the disks online, GTP on both servers. The next step is to enable the Failover Clustering feature on both VMs. This can be easily acomplished using the below command:

Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools –ComputerName SDVM01
Install-WindowsFeature -Name Failover-Clustering –IncludeManagementTools –ComputerName SDVM02

Restart both VMs

Lets start the Failover Cluster Wizard. Select both Azure VMs and validate with running all tests.

The report should have sucess to all Storage Related Stuff. Only the Cluster IP will fail, since it cannot allocate an Azure IP.

So we will not create the Cluster uning the GUI wizard. We will create the cluster unsing the new-cluster command to spesify the cluter IP. But first lets create the Cluster IP Load Balancer.

To enable the Cluster IP we need to create an Internal StandardLoad Balancer with Static IP. Add both VMs to the Backend pool of the load balancer.

And Run this command to one of the two VMs:

New-Cluster -Name cluster1 -Node SDVM01,SDVM02  -StaticAddress 192.168.0.10

The cluster is ready and we can now we can add the Disk to the Cluster

righ click at the Cluster Disk 1 and select “Add to cluster shared volumes”

Wait untill the disk is online

‘

and check the C:ClusterStorage path for the “Volume1” link.

open the Volume1 and create a file, just to cehck that it is working

To have a more stable cluster, add a Quorum. At the cluster name, right click and select More Actions / Configure Quorum settings.

Since we are on Azure we will configure an Azure Storage account for quorum. Select the “Advanced Configuration”

and select the “Configure CLoud Witness”.

Create an Azure Storage Account

add the Storage Account to the Virtual Network of the VMs, to secure it

And once the Storage Account is ready, copy/paste the name and the Key to the Culster Quorum wizard.

Now we have a full failover cluster

Server 1:

Server 2:

Now we can deploy SQL Server FCI, File Server, etc.. !!!!

More info abuot the Shared Disk: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/disks-shared-enable

The post Azure Failover Cluster with Shared Disk – Step by Step appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Greek MVPs in Action | Accelerate your web applications with Azure Front Door

Thank you all who attented my presentation at Sunday’s 29/3/2020 virtual Greek MVPs in Actions event.

My presentation was about the Azure Front Door Service and how you can use it to accelerate and protect your web applications.

You can donwload my presentation here

The post Greek MVPs in Action | Accelerate your web applications with Azure Front Door appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Azure Front Door add custom domain & certificate

This is my third Azure Front Door Post. Already we created an Azure Front Door to scale and secure our web apps, and we used Web Application Firewall (WAF) rules to protect our web apps. At this post we will see how to add a custom domain name and our certificate to the Azure Front Door.

Azure Front Door provides ssl certificates and management for the .azurefd.net domain. But in most cases we will need to add our custom domain name and of cource our certificate.

To add a custom domain name and our certificate we need:

• The public certificate in PFX format
• Register the Azure Front Door Service Principal
• An Azure Key Vault
• Access to the Public DNS of our custom domain

Azure Key Vault

Azure Front Door imports custom certifiated only from Azure key Vault. So we need to create a Key Vault and provide access to the Azure Front Door Service Principal. First register the Azure Front Door Service Principal using this script: (I prefer cloud Shell)

New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"

Result:

Then search the Marketplace and create a key Vault

At the first page fill the name and region and go to the Next Page, Access Policy and press “+ Add Access Policy” to add a new access policy. At the certificate permissions select the get secret & get & list certificates and authorities. For principal select the “Microsoft.Azure.Frontdoor” and add.

Next at the Network Connectivity method select all networks, or if you select selected networks remember to allow the Azure Front Door Bckend IP Range, 147.243.0.0/16. For updated IP range check the https://www.microsoft.com/download/details.aspx?id=56519

Once the Key Vault is ready, open it, go to Certificatess -> Generate/Import

Slect Import and upload your certificate.

Edit the Front Door

Once the certificate is uploaded successfully, go to the Azure Front Door designer. At the Frontend/domains press the + to add the custom domain

Write your custom host name and the form will inform you to create a CNAME to point to the front door. You need to do this first to proceed.

After that enable the Custom Domain HTTPS and select use my own certificate

Select the KeyVault, the certificate and the version and press add adn then Save.

The process will start, it will check the certificate and it will import it to the Front Door.

Now, since we have the SSL termination at the Azure Front Door, we can forward the request unencripted to our backend, this is called SSL Offload. To do this update routing rule to accept HTTPS only requests, select for frontends the custom domain and for backend forwarding protocol HTTP only

Then go to the Web App and turn off the HTTPs Only.

We can now check our web app at the custom domain: https://myapp.funniest.gr

Don’t forget, we have locked our backend web apps with access restriction to allow only the Front Doors backend IP range 147.243.0.0/16

The post Azure Front Door add custom domain & certificate appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Infrastructure as Code | Deploy a VNET with NSG and UDRs

Infrastructure as Code, or just IaC, provides three three main advantages: cost reduction, faster execution and risk reduction, the attributes of the DevOps culture.

Microsoft Azure Resource Manager allows the managing and provisioning of Azure Resources, that can be Virtual Machines, Virtual Networks, Storage Accounts, Apps, SQL Databases and everything that a computer data center includes, through machine-readable definition files, known as JSON templates, without the need of physical hardware configuration or interactive configuration tools.

I am starting a series of posts about building infrastructure with JSON templates.

The tool I use to build my Azure Json templates is the Visual Studio Code. You can download it from https://code.visualstudio.com/ for every platform.

To work with Azure Resource Manager you need the Azure Resource Manager Tools extension. Open the VS Code, go to the Extensions Section, search and install the Azure Resource Manager Tools extension.

The extension is very helpful since it highlights the code, it provides references and intellisense.

At this post I am sharing & explaining my Azure json template for deploying a Virtual Network, a Network Security Group and a Route Table.

You can find and download my working template at my Git account :

https://github.com/proximagr/ARMTemplates/tree/master/VNET-2sub-NSG-UDR

Json Template Guide

Below you can find my template with comments, for better understanding.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
//** Define the Virtual Network Name */
    "vnetName": {
      "type": "string",
      "defaultValue": "Cloud-Corner-VNET",
      "metadata": {
        "description": "Cloud Corner VNET"
      }
//** Define the Address Space of the Virtual Network */
    },
      "vnetAddressPrefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/24",
        "metadata": {
          "description": "Address prefix"
        }
//** Define the Address Space of the the First Subnet */
      },
      "subnet1Prefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/27",
        "metadata": {
          "description": "Subnet 1 Prefix"
        }
//** Define the Name of the the First Subnet */
      },
      "subnet1Name": {
        "type": "string",
        "defaultValue": "Subnet1",
        "metadata": {
          "description": "Subnet 1 Name"
        }
//** Define the Address Space of the the Second Subnet */
      },
      "subnet2Prefix": {
        "type": "string",
        "defaultValue": "10.0.0.32/27",
        "metadata": {
          "description": "Subnet 2 Prefix"
        }
//** Define the Name of the the First Subnet */
      },
      "subnet2Name": {
        "type": "string",
        "defaultValue": "Subnet2",
        "metadata": {
          "description": "Subnet 2 Name"
        }
      },
//** Define the Name of the the Network Security Group */
      "networkSecurityGroup01Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-NSG-01",
        "metadata": {
          "description": "This is the name of the network security group"
        }
      },
//** Define the Name of the the First Route Table */
      "RouteTable01Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-UDR-01",
        "metadata": {
        "description": "Route Table 01 Name."
        }
      },
//** Define the Name of the the First Route of the First Route Table */
      "Route01Name": {
        "type": "string",
        "defaultValue": "To-internet",
        "metadata": {
          "description": "Route 01 Name."
        }
      },
//** Define the Next Hop Type of the the First Route of the First Route Table */
      "Route01NextHopType": {
        "type": "string",
        "allowedValues": [
        "VirtualNetworkGateway",
        "VnetLocal",
        "Internet",
        "VirtualAppliance",
        "None"
      ],
      "defaultValue": "VirtualAppliance",
        "metadata": {
          "description": "Route 01 Next Hop Type."
        }
      },
//** Define the Address Prefix of the First Route of the First Route Table */
      "Route01AddressPrefix": {
        "type": "string",
        "defaultValue": "0.0.0.0/0",
        "metadata": {
          "description": "Route 01 Address Prefix."
        }
      },
//** If you set "Virtyal Appliance for Next Hop Type, then you need to define the Next Hop IP Address, */
//** meaning the appliance's IP address. Here you define it for the First Route of the First Route Table */
        "RT01Route01NextHopIPAddress": {
        "type": "string",
        "defaultValue": "10.0.0.40",
        "metadata": {
          "description": "Next Hop IP Addess."
        }
      },
//** Define the Name of the Second Route Table */
      "RouteTable02Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-UDR-02",
        "metadata": {
          "description": "Route Table 02 Name."
        }
      },
//** Define the Name of the the First Route of the Second Route Table */
      "RT02Route01Name": {
        "type": "string",
        "defaultValue": "Local-Subnet",
        "metadata": {
        "description": "Route Table 02 Route 01 Name."
        }
      },
//** Define the Next Hop Type of the the First Route of the Second Route Table */
      "RT02Route01NextHopType": {
        "type": "string",
        "allowedValues": [
        "VirtualNetworkGateway",
        "VnetLocal",
        "Internet",
        "VirtualAppliance",
        "None"
      ],
      "defaultValue": "VnetLocal",
        "metadata": {
          "description": "Route 02 Next Hop Type."
        }
      },
//** Define the Address Prefix of the the First Route of the Second Route Table */
      "RT02Route01AddressPrefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/27",
        "metadata": {
          "description": "Route Table 02 Route 01 Address Prefix."
        }
      },
//** Define the Name of the the Second Route of the Second Route Table */
        "RT02Route02Name": {
          "type": "string",
          "defaultValue": "To-subnet-1",
          "metadata": {
            "description": "Route Table 02 Route 01 Name."
          }
        },
//** Define the Next Hop Type of the the Second Route of the Second Route Table */
        "RT02Route02NextHopType": {
          "type": "string",
          "allowedValues": [
          "VirtualNetworkGateway",
          "VnetLocal",
          "Internet",
          "VirtualAppliance",
          "None"
        ],
        "defaultValue": "VirtualAppliance",
          "metadata": {
            "description": "Route 02 Next Hop Type."
          }
        },
//** Define the address prefix of the the Second Route of the Second Route Table */
        "RT02Route02AddressPrefix": {
          "type": "string",
          "defaultValue": "10.0.0.32/27",
          "metadata": {
            "description": "Route Table 02 Route 01 Address Prefix."
          }
      },
//** Define the next hop IP address (the virtual appliance's address) of the the Second Route of the Second Route Table */
        "RT02Route02NextHopIPAddress": {
          "type": "string",
          "defaultValue": "10.0.0.40",
          "metadata": {
            "description": "Next Hop IP Addess."
          }
        }
    },
//** I dont use any variables, you can exclude this section*/
  "variables": {},
  "resources": [
//* create the First Route Table & Route*/
    {
    "apiVersion": "2017-10-01",
    "type": "Microsoft.Network/routeTables",
    "name": "[parameters('RouteTable01Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
    "disableBgpRoutePropagation": true,
    "routes": [
      {
        "name": "[parameters('Route01Name')]",
        "properties": {
          "addressPrefix": "[parameters('Route01AddressPrefix')]",
          "nextHopType": "[parameters('Route01NextHopType')]",
          "nextHopIpAddress": "[parameters('RT01Route01NextHopIPAddress')]"
          }
        }
      ]
    }
  },
//* create the Second Route Table & Routes*/
    {
    "apiVersion": "2017-10-01",
    "type": "Microsoft.Network/routeTables",
    "name": "[parameters('RouteTable02Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
    "disableBgpRoutePropagation": true,
    "routes": [
      {
        "name": "[parameters('RT02Route01Name')]",
        "properties": {
          "addressPrefix": "[parameters('RT02Route01AddressPrefix')]",
          "nextHopType": "[parameters('RT02Route01NextHopType')]"
        }
      },
          {
        "name": "[parameters('RT02Route02Name')]",
        "properties": {
          "addressPrefix": "[parameters('RT02Route02AddressPrefix')]",
          "nextHopType": "[parameters('RT02Route02NextHopType')]",
          "nextHopIpAddress": "[parameters('RT02Route02NextHopIPAddress')]"
          }
        }
      ]
    }
  },
//* create teh Network Security Group */
    {
    "apiVersion": "2019-02-01",
    "type": "Microsoft.Network/networkSecurityGroups",
    "name": "[parameters('networkSecurityGroup01Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
      "securityRules": [
        {
          "name": "HTTPS",
          "properties": {
            "description": "Open HTTPS to Public",
            "protocol": "Tcp",
            "sourcePortRange": "443",
            "destinationPortRange": "443",
            "sourceAddressPrefix": "*",
            "destinationAddressPrefix": "*",
            "access": "Allow",
            "priority": 101,
            "direction": "Inbound"
            }
          }
        ]
      }
    },
//* create the Virtual Network */
    {
      "apiVersion": "2018-10-01",
      "type": "Microsoft.Network/virtualNetworks",
      "name": "[parameters('vnetName')]",
      "location": "[resourceGroup().location]",
//*add a dependency in order to ensure that the NSG is created before the VNET, in order to be able to attach it*/
      "dependsOn": [
        "[parameters('networkSecurityGroup01Name')]"
      ],
      "properties": {
        "AddressSpace": {
          "AddressPrefixes": [
            "[parameters('vnetAddressPrefix')]"
          ]
        }
      },
      "resources": [
//* create the first subnet */
        {
        "apiVersion": "2018-10-01",
        "type": "subnets",
        "location": "[resourceGroup().location]",
        "name": "[parameters('subnet1Name')]",
//* add dependencies to create the resources with an order, because you need to ensure that the VNET is ready before creating the Subnet and also the Route Table*/
        "dependsOn": [
          "[parameters('vnetName')]",
          "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable01Name'))]"
        ],
        "properties": {
        "AddressPrefix": "[parameters('subnet1Prefix')]",
//*attach the Newtork Securoty Group to the Subnet*/
        "networkSecurityGroup": {
        "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroup01Name'))]"},
//*attacht the First route table to the Subnet*/
        "routeTable": {
        "id": "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable01Name'))]"
          }
         }
        },
//*create the second subnet*/
        {
        "apiVersion": "2018-10-01",
        "type": "subnets",
        "location": "[resourceGroup().location]",
        "name": "[parameters('subnet2Name')]",
        "dependsOn": [
          "[parameters('vnetName')]",
          "[parameters('subnet1Name')]",
          "[parameters('RouteTable02Name')]"
        ],
        "properties": {
          "AddressPrefix": "[parameters('subnet2Prefix')]",
//*attach the Newtork Securoty Group to the Subnet*/
          "networkSecurityGroup": {
          "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroup01Name'))]"},
//*attacht the second route table to the Subnet*/
          "routeTable": {
          "id": "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable02Name'))]"
            }
          }
        }
      ]
    }
  ]
}

Deploy the template

Deploy the template directly from here:

More Azure Resource Manager Templates: https://www.e-apostolidis.gr/microsoft/azure/create-azure-file-shares-using-arm-template-powershell/

The post Infrastructure as Code | Deploy a VNET & NSG & UDR appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

At this post we will see how we can Visualise our Azure environment using the Resource Graph Explorer. Resource Graph Explorer allows you to run Resource Graph queries, create charts and pin them to the Azure Dashboard.

Resource Graph Explorer is part of Azure Governance. You can find more guides about Azure Governance at my posts like How to limit the Azure VM Sizes and How to enforce tags for resources creation using the Azure Governance tag.

Create a chart showing the number of VMs by Operating System at my tenant.

Open the Azure Portal and search for the Resource Graph Explorer and open it

The window that will open looks familiar because it uses the same query language like Log Analytics, the Kusto. On the right side, at the Resource Window, you can search for any resource type, click it and it will be added to the Query Window. We will start with the “resources” that will bring us all resources

Then we will search for virtual machines to find the correct type

clicking the microsoft.computer/virtualmachines it will automatically change the query to narrow the search to bring only the Virtual Machines

To see the results just press “Run Query”. At the Resources window you can see all the VMs properties, like name, location, tags, resourcegroup and a property named “properties”. If you open this you will see all the details of the VMs.

The Operating System property is under “storageProfile” / “osDisk” / osType. So we need to alter our query like this:

resources
 | where type == "microsoft.compute/virtualmachines"
 | summarize count() by tostring(properties.storageProfile.osDisk.osType)

Running the above query will bring the VMs by OS. Next Results you can click Charts to select the Chart you like.

You can save the query to add a name and also reuse it. The name will appear once we add the chart to the Azure Dashboard, it will be the title.

For our Dashboard I will use a Donut chart. To add it to the Azure Dashboard click “Pin to dashboard”

And this is the dashboard view

We can add more resources, like Public IP Addresses

Change the query to this:

Resources
 | where type == "microsoft.network/publicipaddresses"

To expand the properties, add the ” | project properties ” at the query and  click the “see details” link.

View the properties details and find the name of the ip address key

To create a chart with all Public IP Addresses run the below query

Resources  
| where type == "microsoft.network/publicipaddresses"
| summarize count() by tostring(properties.ipAddress)

And this is the result, pined to Azure Dashboard

Add a chart to show the location of all of my resources

summarize count() by location | project  location, total=count_| order by total desc 
| where total > 1

Now at my Azure Dashboard I have VMs per OS, all Public IP Addresses and the location of all of my resources

Find more at the Azure Resource Graph documentation

The post Azure Dashboard using Resource Graph Explorer appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

The Microsoft Ignite The Tour in Milan 2020 ended and it is time for my recap. It was my first time speaking at Microsoft Ignite The Tour conference and I can say it was an amazing experience. I had the opportunity to connect with great people, speakers from all over the world, MIcrosoft employees and MVPs.

I was honored with two sessions, one 15 minutes Theater and one 45 minutes Breakthrough. Although I was very stressed about my presentations, it went very well and I have excellent evaluation scores.

My 15 minute Theater session at Microsoft Ignite The Tour Milan, where I talk about how to accelerate your web applications with Azure Front Door Service. Use the Azure WAN, 130+ edge sites with WAF & Layer 7 Load Balance at a global scale. Session code: THR30089

My 45 minutes Breakthrough session at Ignite The Tour Milan, where I will talk about how to use Azure Platform as a Service (PaaS): Design your apps with Elasticity, Resiliency and High Availability very easy, fast and secure. Session code: BRK30169

The post Speaking at Microsoft Ignite The Tour Milan 2020 appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Vulnerability Assessment for Azure VMs included in ASC

Hackers and all kind of intruders takes advantage of weakness and mistakes of operating systems and application to get unauthorized access. Those weakness are caused due to lack of updates and patches, mistakes in design and implementation or just a human error. The prevention method of those weaknesses and mistakes is a Vulnerability Analysis that depends upon two processes. The Vulnerability Assessment and the Penetration Testing.

Microsoft Azure, in cooperation with Qualys, offers Vulnerability Assessment at no additional cost for Azure Security Center Standard Tier. The Vulnerability Assessment Azure VM extension reports its findings to Azure Security Center. We have analyzed more Azure Security Center features at previous posts:

• Use Azure Security Center to protect your workloads
• ASC | Remediate security recommendations in 1 click
• Bulletproof manage your Azure VMs

ATTENTION! To take advance of the Qualys offering that is included at the Azure Security Center Standard Tier, without any additional cost, the extension must be installed from the Azure Security Center “Enable the built-in vulnerability assessment solution on virtual machines (powered by Qualys)”  recommendation and not by the “Vulnerability assessment solution should be installed on your virtual machines” recommendation.

Don’t worry if you don’t see this recommendation at your subscription yet. This is because it is a preview recommendation and it is being rolled-out slowly across all regions.

How to enable the Vulnerability Assessment extension

Go to Azure Security Center, at the “Resource Security Hygiene” and select the “Computer & apps”.

Find the “Enable the built-in vulnerability assessment solution on virtual machines (powered by Qualys)”  recommendation and click it.

At the recommendation page, under the “Affected resources” section, there are three tabs. The “Unhealthy resources”, the “Healthy resources” and the “Not applicable resources”. The “Unhealthy resources, are Virtual Machines that are eligible but we have not enabled the extension yet. The “Healthy resources” tab includes the Virtual Machines that already have the extension installed. The “Not applicable resources” tab includes the Virtual Machines that are not eligible for the extension. This category includes images from third party companies or they are not enabled for ASC Standard tier.

Select the Virtual Machines that you want to enable the extension and press “Remediate”

Once the extension is installed, it will need several minutes for the Virtual Machine will move to the “Healthy resources” tab and the Vulnerability Assessment scan will start. Note that if the Virtual Machine is stopped the remediation will fail. The Virtual Machine must be running for the extension to install.

To check the VM extension health, go to the VM and check the Extensions tab for “WindowsAgent.AzureSecurityCenter | Qualys.WindowsAgent.AzureSecurityCenter”

Viewing the Vulnerability Assessment results

After the extension is installed, the scan will start but it will need about 24 to 48 before you will be able to view the results. After the scan finishes, it will report he results at the Azure Security Center, under the “Remediate vulnerabilities found on your virtual machines (powered by Qualys)” recommendation.

Find more info at: https://docs.microsoft.com/en-us/azure/security-center/built-in-vulnerability-assessment

The post Vulnerability Assessment for Azure VMs included in ASC appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Azure Backup Explorer is a new Azure service that enables a consolidated dashboard of all backup items, jobs, policies & alerts for all recovery services vaults across all subscriptions. It provides a single dashboard to view the status of all backups of your subscriptions.

Until now, to view the backup status, you needed to open each recovery services vault and view only the status of the backup jobs of the specific recovery services job. Azure Backup Explorer allows to view the backup job status at scale, drill down to all backup items, jobs, alerts and policies and quickly troubleshoot and take actions,

How to use Azure Backup Explorer

Open any Recovery Services Vault and at the Overview screen, under the Backup , click the “Backup Explorer link.

A workbook view will open, displaying a summary of all Backup Items, Backup Jobs, Backup Alerts and Virtual Machines that are not enabled for backup. And all that info is a summary of all subscriptions and locations. You can filter the summary by subscription, vault location and vault and also you can change the time range.

The Backup Items button shows the protection state of the Virtual Machines that are backed up.

If you press the Backup Jobs button, it shows the Jobs by Status. There you can have a quick view off all backup status, like completed, completed with warnings or failed, and also the jobs by operation, like backup or restore.

Using the Backup Alerts button shows the alerts by severity and by alert type, if you have any alerts of course.

Finally the Backup not enabled button shows the Virtual Machines that are not at any backup job. You can view them by location and by resource group.

Read more at the Backup Explorer documentation

The post Azure Backup Explorer appeared first on Apostolidis Cloud Corner.

Source: e-apostolidis.gr

Compliance Report using Azure Policy

Azure Policy is a powerful tool for Azure Governance. With Azure Policy we can define rules for all Azure Subscriptions the we manage. We can use this rules for simple limitation actions, like permitting only specific VM Series and Sizes that can be created and also more complex rule sets that helps you standardize the whole Azure deployment. At my previous posts, we learned How to limit the Azure VM Sizes and How to enforce tags for resources creation

At the current post we will learn how to use Azure Policy to have a compliance report for our deployment. We will learn this by using an example. Then we will create two Virtual Networks and we will add a Network Security Group only to the first one. Finally we will use the Policy to audit whether the Subnets have assigned the NSG or Not.

First we need two Virtual Networks. You can create the Virtual Networks using the Azure Portal or using ARM template, like mine from my Github account: https://github.com/proximagr/ARMTemplates/blob/master/2vnets.json

After applying the template you will have two VNETs like that:

Then we will a Network Security Group (NSG) only to the MyVNET01 Virtual Network. Again using Azure Portal, PowerShell or my ARM Template for NSG

Assign the NSG to the MyVNET01 VIrtual Network

Add the Policy

Go to Azure Policy -> Definitions and click the “+ Policy definition” to create a new policy definition.

At the New Policy definition page, select the subscription (location) that the policy will be saved, then add a name. in this case we will use the sample policy template from Microsoft docs so I will add the same name.

Copy the policy Json text from https://docs.microsoft.com/en-us/azure/governance/policy/samples/nsg-on-subnet and paste it at the POLICY RULE below and Save.

At the “effect” part of the Json, change the “deny” to “audit”.

If you search for “NSG” you will see our new policy definition, ready to be assigned.

Click on the definition’s name to open it and press Assign.

I will just target the “ComplianceReport” Resource Group

At the parameters, I added the Resource ID of the NSG, “MyNSG01”

Evaluate the results

To check the compliance, go to Policy – Compliance page and search for nsg. You have to wait for about 15 minutes for the compliance policy to evaluate the resources.

If you search “nsg” you will see that the “Audit NSG on Subnet” policy is 50% compliant. Click on the policy’s name to view more details.

The assignment details page will open where we can see what resources are not compliant.

Click on the three dots (…) next to the non-compliant subnet and select “view compliance details” to check why this resource is not compliant.

The compliance details reports that the value is null and what the required (target) value must be.

If you want to trigger an on-demand compliance check, you need to make a POST request. You can follow my post Validate Azure Resource Move with Postman to create the access Token and then use it to make a POST request to the Resource Group sung this POST:

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{YourRG}/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview

Source:

https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects
https://docs.microsoft.com/en-us/azure/governance/policy/samples/nsg-on-subnet
https://docs.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers

The post Compliance Report using Azure Policy appeared first on Apostolidis IT Corner.

Source: e-apostolidis.gr