Secure SSH Connection to a VM using Azure Bastion

Running a VM in Azure is simple. Create it and it just works.

But if you need an RDP or SSH connection to it, you have to know about the security implications.

Enabling RDP or SSH on a VM will open an inbound port for the communication. And this is an invitation for hackers to try to get in using these ports.

A temporary solution is creating a really difficult password/key to get in or changing the port number on which the SSH/ RDP service is listening. But still, this is ‘like playing with fire’. Smart hackers can work around this.

What we need is some kind of terminal session to the VM without opening inbound ports.

Luckily, Microsoft offers a few solutions for this.

First of all, you can make use of the serial console page of the VM instance (as seen in a previous blog).

This is a simple solution but the console form factor is not that great and sometimes random logging messages are written over your shell access which makes it hard to do actual, serious work in this pane.

Recently, Microsoft offers a new and better solution called Azure Bastion.

Bastion enables seamless secure RDP/SSH connectivity to Azure Virtual Machines in your Azure Virtual Networks directly in your web browser and without the need of public IP on your Virtual Machines.

The relationship with VMs looks like this:

VM’s are made part of a virtual network containing a subnet called ‘AzureBastionSubnet’. Next to the VMs this Azure Bastion resource is running and that one makes it possible to create a secure SSH connection.

Note: you need to create an Azure portal connection ‘as a second channel’.

Let’s see how this works.

Advertentie

Towards zero-touch IoT Edge with edgeAgent direct methods

Update: 27-9-2021 The method GetLogs is now called GetModuleLogs. It’s not experimental anymore.

The holy grail of IoT Edge compute is zero-touch configuration and monitoring.

If we look at the life cycle of an edge device, these are the phases where the device is rolled out to production:

The only time when we want to have a person near that edge device is during the initial deployment (Plan, Register), during decommission (Retire) and during physical changes or while repairing the device.

To make zero-touch possible we first need to have a secure cloud connection that supports both sending telemetry to the cloud and retrieving commands from the cloud. And that is supported by Azure IoT Edge by default.

But still, we also need a second communication channel to log-in remotely in a secure way. This is typically done by hand to look at local settings, to check logging, to check connections, or to make repairs to eg. the operating system or the Azure IoT Edge runtime. This could be done using SSH and/or a Remore Desktop connection (RDP). Because this is typically an outbound connection, this is usually provided using a ‘jump box’ or a VPN connection so the connection is set up in a more secure way.

As said, this is done by hand… so far for zero-touch.

Now, if we look at what tasks are performed on the IoT Edge device using an SSH connection:

• Checking the log of running modules
• Restarting modules if their performance is not thusted or to force picking up settings
• Checking the cloud connectivity

What if exactly these three tasks could be performed from the cloud? What if these task could automated?

Let’s check this out.

How to implement module sideloading in Azure IoT Edge

As seen in the last couple of blogs, Azure IoT Edge is useful as a deployment vehicle for Docker containers.

The idea is that the default available edgeAgent module makes an outbound connection with the cloud so it can retrieve updated deployment manifests.

Once such a manifest is received, it will pull new or updated containers from their container repository (eg. hub.docker.com or your own Azure Container Registry).

Relying on Docker modules is smart: it’s flexible and reliable.

But there is one drawback: the size of containers. Containers on their own can have substantial sizes, one hundred megabytes in size is not uncommon.

Docker is a little bit smarter to cope with these sizes. Docker makes use of layers. Layers already downloaded are not downloaded again.

But still, if you are limited in the daily communication size (like on a satellite channel) or if you have to pay for the transfer of files over a metered network (like 3G/4G), it would be nice if you could ‘side-load’ these images to your Edge device.

The easiest way to side-load is during the assembly of your edge device while it’s made ready for shipping to the production site. Next to installing the Azure IoT Edge runtime and the moby container logic, you can already try to pull your containers as much as possible.

Once shipped, your containers are already in the local repository.

After that, you are NOT on your own.

Azure IoT Edge has a nice setting for controlling the pull mechanism.

Let’s check out how it works.

How to deploy and access MySql using Azure IoT Edge

In my previous blog, I showed how regular Docker containers can be rolled out using Azure IoT Edge.

But what about databases, can these be deployed too?

Yes, I showed how to deploy and connect to SQL Server in the past and it works very well if you like SQL Server.

But what about MySql, can we connect to this database too?

Many of the world’s largest and fastest-growing organizations including Facebook, Google, Adobe, Alcatel Lucent, and Zappos rely on MySQL to save time and money powering their high-volume Web sites, business-critical systems, and packaged software.

https://www.mysql.com/why-mysql/

MySql is available as an official Docker container which is needed for this exercise:

So let’s give it a try.

Primer on rolling out your Blazor container on Azure IoT Edge

Recently, Microsoft made Blazor, its new Website framework, available as part of .Net Core 3.

This new framework makes it possible to execute web assembly on the server. This is called Blazor Server App.

Blazor also comes in another flavor, Blazor Webassembly app. But this ‘client side’ version is still in preview.

The Visual Studio tooling provides tooling and templates so your app can be build as a WebApp or as a docker container:

This should be enough to get your application deployed on your local Docker CE container runtime.

Note: I had to update my .Net Core NuGet packages to get the initial test app running, probably because this was still inmature:

Update: In May 2021 I tested this again. It works fine now (on my machine).

I also switched over to release mode (I did not need to debug my app and I do not want to deploy debug versions):

Now I was able to build and run the app as a docker container on port 32780:

With ‘docker ps’ I can look at the ports. The ports seem to differ for no apparent reason:

Update: it seems the portnumbers are in sync now.

The good thing is that Microsoft supports both ‘classic’ deployment as a WebApp or as a Docker container.

This makes things interesting. Azure IoT edge supports common docker containers to be deployed on the edge.

So the question is: How can we roll out this container as a module using Azure IoT Edge?

Turn Jetson Nano vision into insights

Recently I got my hands on an Nvidia Jetson Nano toolkit. This wonderful device runs Ubuntu and is capable to support Azure IoT Edge:

The heart of this device, just beneath the cooling sink, is this board with a 128-core Maxwell GPU:

That is a lot of GPU compute power for just 99 dollars.

I found this hands-on lab from Paul DeCarlo. This simple to follow lab brings vision and object recognition to the cloud using Azure IoT Edge.

Let’s see how Azure Stream Analytics turns object recognition into insights in the cloud.