Thursday, 29 November 2018

Create .NET Core Azure Function with Visual Studio 2017

Introduction

With all the talk about Serverless and Azure Functions, it’s a good time to learn how to do this if you don’t already know. In this post, we’ll do a walkthrough of you to create a simple .NET Core 2.1 Azure Function with Visual Studio 2017.

Prerequisites

First of all, let’s set up our environment.

1) Install Visual Studio 2017 (you can download the Visual Studio Community Edition for free here).

2) Install the .NET desktop development workload for Visual Studio. I have these options enabled:

image

image

3) Install the Universal Windows Platform development workload:

image

4) Install the ASP.NET and web development workload:

image

image

5) Install the Azure development workload:

image

image

6) Install the .NET Core cross-platform development

image

image

7) Install the Azure Functions Core Tools:

You can find more info here.

8) Install PostMan. This is a free tool for making HTTP requests so it’s great for testing out APIs. You can download it here.

Create a new Function App V2 project with Visual Studio 2017:

1) Create a new project in Visual Studio (File > New > Project)

image

2) Select Cloud > Azure Functions then select a folder and click OK.

image

3) On the new window that pops up, make sure you click the drop down and select Azure Functions v2 (.NET Core) and Http Trigger.

image

Click OK when done.

4) Let’s add some code. Rename Function1.cs to HttpTrigger.cs and add the contents below.

This method simply takes an HttpRequest input, extracts the two strings FirstName and LastName and outputs a greeting message.

Debug your Azure Function in Visual Studio

1) At the time of writing, there’s an issue with Visual Studio debugging for .NET Core Azure Functions V2. The workaround for this is here. Go ahead and go through this article then come back to continue at step 2.

2) Hit F5 to start debugging your function and you should be presented with something like this

image

As we can see, our function is running and the HttpTrigger is listed in green.

3) Let’s open up PostMan, create a new Request. It prompts you to create a request name and category.

image

image

4) Change the request to POST

image

5) Go to Body, select raw and add the JSON content below

image

6) In the console window, copy the HttpTrigger URL into PostMan:

image

image

7) Click Send in PostMan

You should get the greeting message below in PostMan

image

And you should see a request come through in the Azure Function console window

image

So, there you have it. Your first Azure Function running .NET Core 2.1. Hit Shift+F5 to stop debugging. You can find the project code on GitHub here.

Monday, 26 November 2018

Debug .NET Core 2.1 Azure Function V2 with Visual Studio 2017

Issue:

When you create a new .NET Core 2.1 Azure Function in Visual Studio and then try to debug it, you see the console pop up and disappear then you get this error:

A fatal error has occurred and debugging needs to be terminated. For more details, please see the Microsoft Help and Support web site. HRESULT=0x8000ffff. ErrorCode=0x0.

image

Workaround:

I’m sure Microsoft will resolve this soon but what you have to do to get around it is to configure the project debug properties and configure Visual Studio with the Executable to run and give it the path of func.dll. See steps below.

1) Install the Azure Functions Core Tools:

You can find more info here.

2) Right click your project, click on Properties and go to the Debug tab

3) Set the Launch type to Executable 

4) Set Executable to

5) Set the Application arguments

You settings should look like this when done.

image

Let’s go ahead and try debug our function and we can see it’s working now:

image

Happy coding!

Sunday, 18 November 2018

Azure Policy - Deny inbound RDP from the internet

Introduction

In this article, I’ll do a quick run through of Azure Policy and what you can do with it. Given that we can now deploy infrastructure in Azure quickly and we can provide multiple teams access, the question is how do we control what can be deployed. In this article, we’ll look at how to prevent users opening up inbound RDP ports open from the internet to their Windows VMs.

What is Azure Policy

Azure Policy is a new Azure feature where you can assign policies to your Azure subscriptions or management groups (groups of Azure subscriptions). Using Azure Policy, you can specify what Azure resources should be denied, which should be audited and which should be automatically remediated by deploying an additional ARM template you specify. For example you can block all storage accounts that don’t use encryption.

There are some built in policies however you can create your own using JSON. There are different parts to the JSON policy as code file:

  • Policy definitions: These are policies that will be enforced such as Allowed Resource Types (set which resources can be deployed), Allowed Virtual Machine SKUs (sets which VM SKUs can be deployed).
  • Initiative definitions: These are groups of policies that are aimed at achieving a larger goal. For example, you could have an initiative for reducing costs and then you can have a number of policies under that such as one policy which prevents users deploying large virtual machines and another which prevents them deploying databases which high DTUs. You can then assign the initiative definition to a subscription or management group.

Create Network Security Group for testing

For starters, I’ll go ahead and create a new Network Security Group which allows TCP port 3389 from the internet. For more information on Network Security Groups, see here.

image

image

image


Create Azure Policy Definition to deny inbound RDP

Now that we have created our Network Security Group which we want to block, we will go ahead and create an Azure Policy Definition.

1) Log into your Azure Portal and search for Policy:

image

2) Here you see the Overview pane with a summary of your compliance status. There are no assigned policies so we can see that we’re 100% compliant.

image

3) Create new policy code

The policy is written in JSON and includes a number of fields:

  • displayName - The name that will appear in the Azure Portal
  • description - The description that will appear in the Azure Portal
  • mode: If set to all then the policy applies to all resource types. If set to indexed then the policy applies to only resource types that support tags and location
  • parameters: Here we can set the parameters for our policy. Rather than create a policy for each inbound port you want to block, you can create a single policy which takes a port parameter. See below:


  • if….then: This is the policy condition and action. It works like most if statements - i.e. if the resource meets certain criteria then an action will be taken. The action can be deny, audit and other options. There’s more information here.

The full JSON content is below:


4) Click on Definitions and add a new Policy Definition, add the JSON content to it and click Save:

image

5) Assign the policy. Click the policy definition you just created and then click on Assign.

image

6) Select the subscription or management group you want to assign the policy to and then set the parameters. In this case, we want to block inbound RDP traffic from the internet so you’d need to specify 3389 in the parameters section at the bottom. Click assign when done.

image


Testing Azure Policy:

Let’s test this out. We need to wait a bit of time for the policy to apply and hopefully we should see that the policy is not compliant and we can click through to find the offending resource.

image

image

If you try to create a new NSG rule which allows inbound port 3389 from the internet, it is denied by policy then you get an error like this:

image

You also get blocked if you try to deploy using PowerShell, terraform, the REST API or other methods as they all use the Azure Resource Manager. 

Conclusion

In this article, we went through how you can use Azure Policy to deny the creation of any NSG rule that allows inbound traffic from the internet on specified ports. This is one step forward to achieving good Azure governance.