100 Days of Cloud – Day 53: Deploy Web App using Azure App Service

Its Day 53 of my 100 Days of Cloud journey, and today I’m going to deploy a Web App using Azure App Service using both manual and automated deployment methods.

In the previous post, we looked at the fundamentals of Azure App Service:

  • It can use multiple programming languages to run your Web Apps or Services.
  • Benefits of using App Service over on-premise hosting.
  • The various App Service plans available.
  • Manual or Automated deployment options using familiar tools.
  • Integrate directly with multiple providers for authentication.

Manual Deployment

So with all the theory out of the way, lets dive in and deploy a Web App. We’ll start with the manual deployment method. Login to the Azure portal and open the Cloud Shell from the menu bar.

The location of Cloud Shell launch button.

After the shell opens be sure to select the Bash environment:

Next up, we need to create a htmlapp directory to store the files and code for our Web App:

Next, we’ll run this command in order to clone a sample Web App from the Azure Samples respository on GitHub, There are over two thousand code samples available in multiple languages, and you can browse the site here to find what you’re looking for.

git clone https://github.com/Azure-Samples/html-docs-hello-world.git

Now, change to the directory that contains the sample code and run the following command:

az webapp up --location <MyLocation> --name <MyAppName> --html

Replace <myLocation> with the Azure region that you want to deploy the Web App to, and <myAppName> with a name for your WebApp. So in my case, I’ll be running this command:

az webapp up --location northeurope --name MyDay53WebApp --html

Running this command does a number of things:

  • Creates a resource group
  • Creates an App Service Plan
  • Creates the Web App
  • Configures default logging for the app

We can see all of this info in the output from the command. We need to make a note of the Resource Group as we’ll need this later for both re-deployment and removal.

So now if we browse to the URL provided in the output:

We can see that the sample website is available. So now lets change the heading – from our bash shell we’ll run code index.html to open the editor.

We can see in Line 10 the title that we saw when we browsed to the site, and on line 19 the header at the top of the page. Lets change this to something different:

We use ctrl-s to save and ctrl-q to quit the editor. Now, we;ll run the same command we ran earlier to redeploy the Web App:

az webapp up --location northeurope --name MyDay53WebApp --html

As we can see from the command output, it detects that the WebApp name specified already exists so will deploy the new content to this app.

And now when we refresh the page, we see that both the header and the title have changed as expected:

Automated Deployment using GitHub

So now lets take a look at one of ways to automate deployment and update of our Web App – we’ll demonstrate this using GitHub.

The first thing we need to do it locate our sample Web App respository in GitHub. Once we locate this, we’ll click on the “Fork” button:

What this does is takes a copy of the repository into our own GitHub account, so now I can see it here:

Now we can use this repository in a CI/CD Deployment model where changes to the App are pushed into production every time we make changes to the code.

So back into the Azure Portal we go, and we need to locate our existing Web App, and click on “Deployment Center”. We can see there is warning that we are in the Production Slot – this is because we are using the Free Tier for this deployment – we’ll look at deployment slots in the next post. So we start by clicking on “Source*” to select the code source, and we select “GitHub”

Now, we need to Authorise Github as the provider:

And now we click “Authorize App Service”

Once we’re loged into Github, we can select the Repository and Branch that we wish to use in our deployment. One thing that I changed here was the Build Provider – where we see “Building with GitHub Actions”, I changed this to “App Service Build Service”

Once all of the options are selected, click on “Save” and a page will appear confirming the settings selected:

So this is now effectively live, if we click on “Logs”, we can see that this created an update to our deployment. And because we are now using the base respository files, we can browse to the site and see we are back to the default title and heading on the site:

So now, we can edit the index.html file directly on GitHub to make changes:

So we’ll do a commit of the changes in GitHub. And if we check our logs again, we can see another deployment has happened:

And if we refresh the website, we can see our changes automatically got published!

Conclusion

So thats an overview of deploying to Azure App Service using manual and automated deployment methods. In the next post, we’ll look at more advanced options like auto-scaling and deployment slots.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 52: Azure App Service

Its Day 52 of my 100 Days of Cloud journey, and today I’m taking a look at Azure App Service.

How to Create a Serverless Meme-as-a-Service

After all my promises on Day 49 around doing further blogs on services such as AKS, Azure Monitor, Azure Security Center or Azure File Sync, I’m sure you weren’t expecting me to head off into another direction. The truth is dear reader that I have a rather embarrassing admission to make – I failed to follow my own advice….lets set the scene.

We go back in time to Day 17 where I spoke about the then upcoming Microsoft Ignite Cloud Skills Challenge, which enabled you to obtain a free exam voucher for completing an MS Learn Module. The exam voucher needs to be used by March 15th, and from the list of exams that were on the eligibility list, below were the ones that were of interest to me:

But of course Michael jumped ahead and booked the betas for AZ-800 and AZ-801 (as described in Day 47 and Day 51). So those 2 get scratched off the list and I get left with a choice of 3. And my own advice from Day 17 is ringing in my head:

Its not worth doing it if the only reason is for a free voucher and you don’t really know what to use it for, and then just take an exam for the sake of it because you have the voucher.

So what do I do? I could let the exam expire, or I could pick one of the 3 remaining and give it a go. And as this 100 Days journey is learning experience, I decide to go for the one that I will freely admit I know the least about, and thats AZ-204. Loading up the Microsoft Learn modules from the official exam page, the first thing I see is Azure App Service! A-ha! This looks familiar, and it should as the content was covered briefly on AZ-104.

Overview of Azure App Service

Azure App Service is a Platform as a Service (PaaS) offering that is used to host web applications, REST APIs and mobile back end services.

Because this is a PaaS offering, the underlying infrastructure is fully managed and patched by Azure. You can choose to run App Service on either Windows or Linux platforms depending on your application requirements. Because of this, you can use any programming language to run your Web Applications or Service, and these can the be hosted on App Service. This list includes but is not limited to:

  • .NET
  • Java
  • Node.js
  • Ruby
  • PHP
  • Python

Benefits of App Service

Because Azure App Service is a PaaS offering, it means that you are only responsible for managing the application/service and the data. Everything else is managed by Azure.

As well as the range of programming languages that are supported, you can also run scripts or executables as background services.

You can also scale in/out (adds/removes additional VMs as required) or scale up/down (adds/removes CPU or memory resources as required).

Lets compare this to hosting on your own on-premise servers. You are responsible for the following:

  • Procurement of Physical Servers, Storage, Networking equipment
  • Power and Cooling
  • Networking setup and security
  • Virtualization, Operating System (Installation, Patching, System Upgrades)
  • Middleware Components
  • Configuration of Web Services such as Apache, IIS or Nginx

App Service Plans

As with all Azure Services, there are different pricing tiers that define the compute resources that are allocated to your App Service. There are 4 different tiers to choose from:

  • Shared compute: Both Free and Shared share the resource pools of your apps with the apps of other customers. These tiers allocate CPU quotas to each app that runs on the shared resources, and the resources can’t scale out.
  • Dedicated compute: The Basic, Standard, Premium, PremiumV2, and PremiumV3 tiers run apps on dedicated Azure VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more VM instances are available to you for scale-out.
  • Isolated: This tier runs dedicated Azure VMs on dedicated Azure Virtual Networks. It provides network isolation on top of compute isolation, and maximum scale-out capabilities. You should run in Isolated if your app is resource intensive or needs to scale independently of other apps.
  • Consumption: This tier is only available to Azure Function apps. It scales the functions dynamically depending on workload.

Deployment Options for App Service

You have multiple options for deployment of your App Service. Automated deployment options are:

  • Azure DevOps
  • GitHub
  • Bitbucket

All of these options allow you to build your code, test and generate releases, and push the code changes to Azure. You also can maintain version control with these options.

Manual deployment options are:

  • Git – Web Apps have a Git URL that you can use a remote repository to deploy your Web App.
  • Azure CLI – you can package Web Apps and deploy them using CLI.
  • ZIP Deploy – Use curl or similar http to send a zip of your deployment files to App Service.
  • FTP/S – you can push your code directly to App Service over FTP or FTPS.

Authentication

Azure App Service allows you to integrate directly with multiple providers such as Azure AD, Facebook, Google or Twitter. This feature is built directly into the platform and doesn’t require any coding, language or security expertise to implement.

Conclusion

So thats an overview of the foundations of Azure App Service. In the next post, we’ll go through a demo of deploying a Web App using both manual and automated methods, and look at more advanced options like configuring diagnostic settings, auto-scaling and deployment slots.

Hope you enjoyed this intro to Azure App Service, until next time!

100 Days of Cloud – Day 51: AZ-801 Exam Day!

Its Day 51 of my 100 Days of Cloud Journey, and today I sat Exam AZ-801: Configuring Windows Server Hybrid Advanced Services (beta).

AZ-801 is the second exam required for the new Windows Server Hybrid Administrator Associate certification, which was announced at Windows Server Summit 2021. The first is Az-800 (Administering Windows Server Hybrid Core Infrastructure), which I blogged about in a previous post last week.

This certification is seen by many as the natural successor to the retired MCSE certifications which retired in January 2021, primarily because it focuses in some part on the on-premise elements within Windows Server 2019.

Because of the NDA, I’m not going to disclose any details on the exam, however compared to last weeks exam I felt that this exam is more heavily weighted towards Azure as opposed to last weeks exam which had a more even split. There are also some elements of Windows Server 2022 included in the exam.

The list of skills measured as their weightings are as follows:

  • Secure Windows Server on-premises and hybrid infrastructures (25-30%)
  • Implement and manage Windows Server high availability (10-15%)
  • Implement disaster recovery (10-15%)
  • Migrate servers and workloads (20-25%)
  • Monitor and troubleshoot Windows Server environments (20-25%)

Like all beta exams, the results won’t be released until a few weeks after the exam officially goes live so I’m playing the waiting game! In the meantime, you can check out these resources if you want to study and take the exam:

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 49: Managing Azure Services with Windows Admin Center

Its Day 49 of my 100 Days of Cloud Journey, and today I’m looking at how we can manage Azure Services from Windows Admin Center, either on and Azure or on-premise based installation.

In the previous post, we saw how we can use Azure Network Adapter to connect an on-premise server directly to an Azure Virtual Network using a Point to Site VPN Connection. However when we looked at our Server in the Windows Admin Center console, we saw a number of Azure options on the side menu.

Lets take a look at each of these menu options and what we have available. We’ll start with “Azure hybrid center”, when we click into this, the first option we see is a prompt to onboard the server to Azure Arc (we discussed the benefits of Azure Arc on Day 44):

Once we have onboarded to Azure Arc, we scroll down and see a number of other services available to us:

The list of services available here are:

  • Azure Site Recovery, which we covered in Day 19.
  • Azure Update Management, which allows us to manage Windows Updates on Azure Arc registered servers.
  • Azure File Sync, which allows us to host data in Azure File Shares and then sync data to on-premise servers (blog post coming up on that!)
  • Azure Extended Network, which allows us to extend our on-premise networks into Azure so that migrated VMs can keep their original IP Addresses.
  • Azure Monitor, which gives us full monitoring of our applications, infrastructure and networks (need a blog post about that too!).
  • Azure Backup, which we covered in Day 23.
  • Azure Security Center, which monitors security across hybrid workloads, applies policies and compliance baselines, blocks malicious activity, detects attacks and simplifies detection and remediation (another blog post needed on that!)

Wow, gave myself lots more work to do out of that!

A lot of the above options are part of the main menu, the one thats not mentioned above and is on the main menu is Azure Kubernetes Service (or AKS for short). Azure Kubernetes Service is a managed container orchestration service based on the open source Kubernetes system, which is available on the Microsoft Azure public cloud. … AKS is designed for organizations that want to build scalable applications with Docker and Kubernetes while using the Azure architecture.

When we click on the menu option, we can see the option is available to deploy a AKS Cluster:

I’m not going to delve in AKS in too much detail here (yes you’ve guessed it, its another blog post….. )

We can see how Windows Admin Center can provide a single management pane for Hybrid Services. You can check out this excellent post from Thomas Maurer’s blog for video descripions of how to use each service with Windows Admin Center.

Hope you enjoyed this post, lots more posts to come out of this one! Until next time!

100 Days of Cloud – Day 48: Azure Network Adapter

Its Day 48 of my 100 Days of Cloud Journey, and today I’m going to run through a quick demo of how to set up Azure Network Adapter.

In previous posts, I looked at the various connectivity offerings that Azure offer to allow access into a Virtual Network from either a peered VNET, an on-premise location using Site to Site VPN or Express Route, or a direct connection from a client PC using a Point to Site VPN.

For the majority of companies who are hosting resources in Azure, a Site to Site VPN will be the most commonly used model, however in most cases this extends their entire on-premise or datacenter location into Azure, and also give them visibility at the very least of all hosted resources.

Azure Network Adapter is a way to set up connectivity from on-premise servers running Windows Server 2019 directly into the Azure Virtual Network of your choice. By using Windows Admin Center to create the connection, this also creates the VPN Gateway Subnet and Certificate options. This eases the pain of creating connections between on-premises environments and Microsoft Azure public cloud infrastructure.

Lets have a look at how this is configured. There are some pre-requisites we need to make this work:

Using Azure Network Adapter to connect to a virtual network requires the following:

  • An Azure account with at least one active subscription.
  • An existing virtual network.
  • Internet access for the target servers that you want to connect to the Azure virtual network.
  • A Windows Admin Center connection to Azure.
  • The latest version of Windows Admin Center.

From Windows Admin Center, we browse to the Server we want to add the Azure Network Adapter to. We can see under Networks we have the option to “Add Azure Network Adapter (Preview)”:

When we click, we are prompted to register Windows Admin Center with Azure:

Clicking this brings us into the Account screen where we can register with Azure:

Follow the prompts and enter the correct information to connect to your Azure Tenant

Once we’re connected to Azure, we go back to our Server in Windows Admin Center and add our Azure Network Adapter:

What this will do is both create the network connection to Azure (which is effectively a Point-to-Site VPN Connection)  from our Server, but it also creates the VPN Gateway Subnet on the Virtual Network in our Azure Subscription. We also see that we can select a VPN Gateway SKU. When we click the “How much does this cost?” link, we can see pricing details for each of the available SKU’s.

We click create and see Success!! We also see that this can take up to 35 minutes to create.

We then get a notification to say our Point to Site Client Configuration has started:

And once that’s completed, we can see our VPN is up and connected:

And we can also see our gateway resources have been created in Azure:

Now, lets see if we can connect directly to our Azure VM. We can see the Private IP Address is 10.30.30.4:

And if we try to open an RDP connection from our Server to the Azure VM, we get a response asking for credentials:

You can disconnect or delete the VPN connection at any time in Windows Admin Center by clicking on the “ellipses” and selecting the required option:

Go ahead and try the demo yourelves, but as always don’t forget to clean up your resources in Azure once you have finished!

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 47: AZ-800 Exam Day!

Its Day 47 of my 100 Days of Cloud Journey, and today I sat Exam AZ-800: Administering Windows Server Hybrid Core Infrastructure (beta).

AZ-800 is one of 2 exams required for the new Windows Server Hybrid Administrator Associate certification, which was announced at Windows Server Summit 2021. The second exam is Az-801 (Configuring Windows Server Hybrid Advanced Services), which I’m taking next week so will write up a post on that then!

This certification is seen by many as the natural successor to the retired MCSE certifications which retired in January 2021, primarily because it focuses in some part on the on-premise elements within Windows Server 2019.

Because of the NDA, I’m not going to disclose any details on the exam, however I will say that it is exactly as its described – a Hybrid certification bringing together elements of both on-premise and Azure based infrastructure.

The list of skills measured as their weightings are as follows:

  • Deploy and manage Active Directory Domain Services (AD DS) in on-premises and cloud environments (30-35%)
  • Manage Windows Servers and workloads in a hybrid environment (10-15%)
  • Manage virtual machines and containers (15-20%)
  • Implement and manage an on-premises and hybrid networking infrastructure (15-20%)
  • Manage storage and file services (15-20%)

Like all beta exams, the results won’t be released until a few weeks after the exam officially goes live so I’m playing the waiting game! In the meantime, you can check out these resources if you want to study and take the exam:

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 46: Azure Well Architected Framework

Its Day 46 of my 100 Days of Cloud Journey, and today I’m looking at Azure Well Architected Framework.

Over the course of my 100 Days journey so far, we’ve talked about and deployed multiple different types of Azure resources such as Virtual Machines, Network Security groups, VPNs, Firewalls etc.

We’ve seen how easy this is to do on a Dev-based PAYG subscription like I’m using, however for companies who wish to migrate to Azure, Microsoft provides a ‘Well Architected Framework’ which offers guidance in ensuring that any resource or solution that is deployed or architected in Azure conforms to best practices around planning, design, implementation and on-going maintenance and improvement of the solution.

The Well Architected Framework is based on 5 key pillars:

  • Reliability – this is the ability of a system to recover from failures and continue to function, which in itself is built around 2 key values:
    • Resiliency, which returns the application to a fully functional state after a failure.
    • Availability, which defines whether users can access the workload if they need to.
  • Security – protects applications and data from threats. The first thing people would think of here is “firewalls”, which would protects against threats and DDoS attacks but its not that simple. We need to build security into the application from the ground up. To do this, we can use the following areas:
    • Identity Management, such as RBAC roles and System Managed Identities.
    • Application Security, such as storing application secrets in Azure Key Vault.
    • Data sovereignty and encryption, which ensures the resource or workload and its underlying data is stored in the correct region and is encrypted using industry standards.
    • Security Resources, using tools such as Microsoft Dender for Cloud or Azure Firewall.
  • Cost Optimization – managing costs to maximize the value delivered. This can be achieved in the form of using tools such as:
    • Azure Cost Management to create budgets and cost alerts
    • Azure Migrate to assess the system load generated by your on-premise workloads to ensure thay are correctly sized in the cloud.
  • Operational Excellence – processes that keep a system running in production. In most cases, automated deployments leave little room for human error, and can not only be deployed quickly but can also be rolled back in the event of errors or failures.
  • Performance Efficiency – this is the ability of a system to adapt to changes in load. For this, we can think of tools and methodologioes such as auto-scaling, caching, data partitioning, network and storage optimization, and CDN resources in order to make sure your workloads run efficiently.

On top of all this, the Well Architected Framework has six supporting elements wrapped around it:

Diagram of the Well-Architected Framework and supporting elements.
Image Credit: Microsoft
  • Azure Well-Architected Review
  • Azure Advisor
  • Documentation
  • Partners, Support, and Services Offers
  • Reference Architectures
  • Design Principles

Azure Advisor in particular helps you follow best practises by analyzing your deployments and configuration and provides recommends solutions that can help you improve the reliability, security, cost effectiveness, performance, and operational excellence of your Azure resources. You can learn more about Azure Advisor here.

I recommend anyone who is either in the process of migration or planning to start on their Cloud Migration journey to review the Azure Well Architected Framework material to understand options and best practices when designing and developing an Azure solution. You can find the landing page for Well Architected Framework here, and the Assessments page to help on your journey is here!

Hope you all enjoyed this post, until next time!

100 Days of Cloud – Day 45: Azure Spot and Reserved Instances

Its Day 45 of my 100 Days of Cloud Journey, and today I’m looking at Azure Spot Instances and Reserved Instances.

During previous posts where I deployed virtual machines, the deployments were based on a Pay-As-You-Go pricing model, this is one of the 3 pricing models available to us in Azure. While this type of pricing is good for the likes of what I’m doing here (ie quickly spinning up VMs for a demo and then deleting them immediately), its not considered cost effective for organisations who have a Cloud Migration strategy, a long term plan to host a large number of VMs in Azure, and also need the flexibility to use low costs VMs for development or batch processing.

Lets take a look at the other 2 pricing models, starting with Azure Spot Instances.

Azure Spot Instances

Azure Spot instances allow you to utilize any unused Azure Capacity in your region at the fraction of the cost. However, at any point in time when Azure needs the capacity back, the Spot Instances will be evicted and removed from service at 30 seconds notice.

Because of this there is no SLA on Azure Spot instances, so they are not suitable for running production workloads. They are best suited for workloads that can handle interruptions, such as batch processing jobs, Dev/Test environments or Large compute workloads.

There is no availability guarantees, and availablity can vary based on size required, available capacity in your region, time of day etc. Azure will allocate the VM if there is available capacity, however there is no High Availability guarantees.

When the VMs are evicted, they can be either deallocated or deleted based on the policy you set when creating the VMs. Deallocate (this is the default) stops the VM and makes it available to redeploy (however this is not guaranteed and is based on capacity). You will also be charged for the underlying Storage Disk costs. Delete on the other hand will shut down and destroy the VMs and underlying storage.

You can see the full savings you can achieve by using Spot Instance VMs in the Azure Spot VMs Pricing Table here.

Azure Reserved Instances

Azure Reserved Instances is a way to reserve your compute capacity for a period of 1, 3 or 5 years at savings of over 70% when compared to Pay-As-You-Go pricing. This is best suited to Production workloads that need to have 24/7 runtime and high availability.

As we can see in the image from the Reservations blade in the Azure Portal above, you can purchase Azure Reserved Instances for a large number of Azure Resources, not just VMs.

Reservations can be aplied to a specific scope – that can be Subscription (single or multiple subscriptions), Resource Group or a single resource such as a VM, SQL Database or an App Service.

Once you click into any of the options on the Reservations blade, it will bring you into a list of available SKUs that you can purchase:

Another option to factor in is that Azure Reserved Instances can be use with Azure Hybrid Benefit, meaning you can use your on-premise Software Assurance-enabled Windows OS and SQL Server licences, which can bring your savings up to 80%! You can find out more about Azure Hybrid Benefit here, and get the full lowdown on Azure Reserved Instances here.

Conclusion

And thats a wrap on Azure Pricing models – you can see the cost savings you can make based on what your workloads are. Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 44: Azure Arc

Its Day 44 of my 100 Days of Cloud Journey, and today I’m looking at Azure Arc.

Azure Arc is a service that provides you with a single management plane for services that run in Azure, On Premises, or in other Cloud Providers such as AWS or GCP.

The majority of companies have resources both in on-premise and in come cases multiple cloud environments. While monitoring solutions can provide an overview of uptime and performance over a period of time, control and governance of complex hybrid and multi-cloud environments is an issue. Because these environments span multiple cloud and data centers, each of these environments operate their own set of management tools that you need to learn and operate.

Azure Arc solves this problem by allowing you to manage the following resources that are hosted outside of Azure:

  • Servers – both physical and virtual machines running Windows or Linux in both on-premise and 3rd party Cloud providers such as AWS or GCP.
  • Kubernetes clusters – supporting multiple Kubernetes distributions across multiple providers.
  • Azure data services – Azure SQL Managed Instance and PostgreSQL Hyperscale services.
  • SQL Server – enroll SQL instances from any location with SQL Server on Azure Arc-enabled servers.
Azure Arc management control plane diagram
Image Credit: Microsoft

For this post, I’m going to focus on Azure Arc for Servers, however there are a number of articles relating to the 4 different Azure Arc supported resource types listed above – you can find all of the articles here.

Azure Arc currently supports the following Windows and Linux Operating Systems:

  • Windows Server 2012 R2 and later (including Windows Server Core)
  • Ubuntu 16.04 and 18.04 (x64)
  • CentOS Linux 7 (x64)
  • SUSE Linux Enterprise Server (SLES) 15 (x64)
  • Red Hat Enterprise Linux (RHEL) 7 (x64)
  • Amazon Linux 2 (x64)

In order to register a Physical Server or VM with Azure Arc, you need to install the Azure Connected Machine agent on each of the operating systems targeted for Azure Resource Manager-based management. This is an msi installer which is available from the Microsoft Download Center.

You can also generate a script directly from the Azure Portal which can be used on target computers to download the Azure Connected Machine Agent, install it and connect the server/VM into the Azure Region and Resource Group that you specify:

A screenshot of the Generate script page with the Subscription, Resource group, Region, and Operating system fields selected.
Image Credit: Microsoft
A screenshot of the Administrator: Windows PowerShell window with the installation script running. The administrator is entering a security code to confirm their intention to onboard the machine.
Image Credit: Microsoft

The server then gets registered in Azure Arc as a connected machine:

Azure Arc for Servers: Getting started - Microsoft Tech Community
Image Credit: Microsoft

OK, so now we’ve got all of our servers connected into Azure Arc, what can we do with them? Is it just about visibility?

No. When your machine is connected to Azure Arc, you then have the following capabilities:

  • Protect Servers using Microsoft Defender for Endpoint, which is part of Microsoft Defender for Cloud
  • Collect security-related events in Microsoft Sentinel
  • Automate tasks using PowerShell and Python
  • Use Change Tracking and Inventory to assess configuration changes in installed software and operating system changes such as registry or services
  • Manage operating system updates
  • Monitor system performance using Azure Monitor and and collect data which can be stored in a Log Analytics Workspace.
  • Assign policy baselines using Azure Policy to report on compliance of these connected servers.

Conclusion

We can see how useful Azure Arc can be in gaining oversight on all of your resources that are spread across multiple Cloud providers and On Premise environments. You can check out the links provided above for a full list of capabilities, or else this excellent post by Thomas Maurer is a great starting point in your Azure Arc leaning journey.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 43: Azure JIT VM Access using Microsoft Defender for Cloud

Its Day 43 of my 100 Days of Cloud Journey, and today I’m looking at Just-In-Time (JIT) VM access and how it can provide further security for your VMs.

JIT is part of Microsoft Defender for Cloud – during the Autumn Ignite 2021, it was announced that Azure Security Center and Azure Defender would be rebranded as Microsoft Defender for Cloud.

There are 3 important points you need to know before configuring JIT:

  • JIT does not support VMs protected by Azure Firewalls which are controlled by Azure Firewall Manager (at time of writing). You must use Rules and cannot use Firewall policies.
  • JIT only supports VMs that have deployed using Azure Resource Manager – Classic deployments are not supported.
  • You need to have Defender for Servers enabled in your subscription.

JIT enables you to lock down inbound traffic to your Azure VMs, which reduces exposure to attacks while also providing easy access if you need to connect to a VM.

Defender for Cloud uses the following flow to decide how to categorize VMs:

Just-in-time (JIT) virtual machine (VM) logic flow.
Image Credit: Microsoft

Once Defender for Cloud finds a VM that can benefit from JIT, its add the VM to the “Unhealthy resources” tab under Recommendations:

Just-in-time (JIT) virtual machine (VM) access recommendation.
Image Credit: Microsoft

You can use the steps below to enable JIT:

  • From the list of VMs displaying on the Unhealthy resources tab, select any that you want to enable for JIT, and then select Remediate.
    • On the JIT VM access configuration blade, for each of the ports listed:
      • Select and configure the port using one of the following ports:
        • 22
        • 3389
        • 5985
        • 5986
      • Configure the protocol Port, which is the protocol number.
      • Configure the Protocol:
        • Any
        • TCP
        • UDP
      • Configure the Allowed source IPs by choosing between:
        • Per request
        • Classless Interdomain Routing (CIDR) block
      • Choose the Max request time. The default duration is 3 hours.
    • If you made changes, select OK.
    • When you’ve finished configuring all ports, select Save.

When a user requests access to a VM, Defender for Cloud checks if the user has the correct Azure RBAC permissions for the VM. If approved, Defender for Cloud configures the Azure Firewall and Network Security Groups with the specified ports in order to give the user access for the time period requested, and from the source IP that the user makes the request from.

You can request this access through either Defender for Cloud, the Virtual Machine blade in the Azure Portal, or by using PowerShell or REST API. You can also audit JIT VM access in Defender for Cloud.

For a full understanding of JIT and its benefits, you can check out this article, and also this article shows how to manage JIT VM access. To test out JIT yourself, this link brings you to the official Microsoft Learn exercise to create a VM and enable JIT.

Hope you enjoyed this post, until next time!