Posted on Leave a comment

Access Managed Identity from container inside VM – Azure

Managed identity is the best practice regarding security when accessing resources on Azure. There are many ways you can use it for service to service communication. Sometimes though you can use nested managed identity in more complex scenarios like the one demonstrated below. In this guide we will enable managed identity on a virtual machine and we will access this managed identity within a container that runs on that specific virtual machine. This case can be useful in complex deployment scenarios where you have multiple containers inside a virtual machine and you want to deploy using managed identity on azure.

The first thing you will need is the system assigned managed identity on the virtual machine.

Then you can run your containers inside the virtual machine. In my case the containers are windows based as a result I will use the route print command to show the routing table.

Run the following Commands to expose the managed identity endpoint

$gateway = (Get-NetRoute | Where { $_.DestinationPrefix -eq '0.0.0.0/0' } | Sort-Object RouteMetric | Select NextHop).NextHop
$ifIndex = (Get-NetAdapter -InterfaceDescription "Hyper-V Virtual Ethernet*" | Sort-Object | Select ifIndex).ifIndex
New-NetRoute -DestinationPrefix 169.254.169.254/32 -InterfaceIndex $ifIndex -NextHop $gateway -PolicyStore ActiveStore # metadata API

After the successful add of the route the managed identity endpoint should be redirected in the gateway and from there you will be able to authenticate.

We can verify the procedure by executing a key vault managed identity secret retrieval.

$token = Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -Headers @{Metadata="true"} -UseBasicParsing
$tokenvalue = ($token.Content | ConvertFrom-Json).access_token

Retrieve secret:

Invoke-WebRequest -Uri "https://test.vault.azure.net/secrets/testsecret/d9ce520dfdfdf4bdc9a41f5572069708c?api-version=7.3" -Headers @{Authorization = "Bearer $tokenvalue"} -UseBasicParsing

At last you can login using Managed Identity from the container using the powershell module.

References:

Co authored with Giannis Anastasiou @ Vivawallet

Posted on Leave a comment

Install linux azure devops agent on docker container

As we previously examined how we can create a containerized azure devops agent running on a windows machine, we will now go through the same procedure but with linux OS.

You can read the windows container azure devops agent article using the below link:

The first thing that you will need is a virtual machine that runs docker. When this requirement is fulfilled you can jump on the image building. In order to build your image you will need your Dockerfile and the instructions for the agent.

You can read the rest of the article on Medium using the link below:

A detailed deployment video can be found on my Udemy course:

https://www.udemy.com/course/mastering-azure-devops-cicd-pipelines-with-yaml/

Posted on Leave a comment

Containerize a .NET app with Docker and vs code

When you build your application with cloud native technologies you will build microservices on containers instead of monolithic applications. We will now examine how easy is to build a .NET application in a container and run this application on your local machine.

First we will need to create the visual studio solution. I will go through that with visual studio IDE and then I will use vs code. For my microservice I am using a ASP .NET Core web api with default code.

The target framework for the solution will be the latest .NET framework which is version 7. All other settings will be set to defaults.

When you run the app locally with IIsExpress you will be able to access the swagger interface through the port which you defined in the launchSettings.json. 

https://localhost:7057/swagger/index.html

This file can be located under Properties and there you can configure on which port the application will run. In the profiles section under https settings, you can find the default application URL and port. This will be needed in later steps.

Microsoft provides the below documentation in order to create a containerized application that runs on .NET

Build and run an ASP.NET Core app in a container
In this guide you will learn how to: Create a Dockerfile file describing a simple .NET Core service container. Build…code.visualstudio.com

In order to create a microservice based on our vs solution we will need a dockerfile. This can be created automatically with vs code.

In vs code command dialog search for docker add and select docker compose files to workspace.

Then select asp net core.

and after that your operating system. The next step will be to select the exposed port, or otherwise under which port your application will run. There we should provide the port that we found under our launchSettings.json or the one that we configured manually. In my case I will select the default one for the solution which was 7057.

When a popup window appears on the screen you should select add Dockerfile and automatically the build files will be generated.

Dockerfile

Based on my setup I altered two things in the generated Dockerfile. The first thing will be to change configuration to Debug instead of Release. For production environments you will consider using the release build directive. The second thing will be to add an environmental variable ASPNETCORE_ENVIRONMENT inside the container with the value Development.

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 7057

ENV ASPNETCORE_URLS=http://*:7057
ENV ASPNETCORE_ENVIRONMENT=Development

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["AspNetWebApi.csproj", "./"]
RUN dotnet restore "AspNetWebApi.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "AspNetWebApi.csproj" -c Debug -o /app/build

FROM build AS publish
RUN dotnet publish "AspNetWebApi.csproj" -c Debug -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "AspNetWebApi.dll"]

docker build command

after the build is completed and the image is created you can run a new container locally.

Keep in mind that in order to test your container you should create a port forward from the container to your host. I used the same port for the host so I added the -p 7057:7057

The logs of the container indicate a successful run of the application.

Our application now runs as a microservice container inside the host machine (my laptop). 

We can verify the access to our application using the URL with the swagger.

Youtube video:

Posted on Leave a comment

Connect Azure Web app container to Keyvault using Managed identity

Following the article on which I described how you can connect to Azure resources through Managed Identity, I will showcase how one can connect through a container running on an App Service (web app) to a keyvault in order to gather secrets from it.

The main two components that are required for this demo will be an app service and a keyvault.

First things first we will need some secrets in order to gather through the hosted application. The dbpassword that is shown below will be retrieved and used from the web app running on the container.

As examined in the article mentioned above, we should construct the appropriate URL in order to retrieve the access_token.

$kati = Invoke-WebRequest -Uri $env:MSI_ENDPOINT"?resource=https://vault.azure.net&api-version=2017-09-01" -Headers @{Secret=$env:MSI_SECRET} -UseBasicParsing | ConvertFrom-Json

Store the access_token on a separate variable (as it sometimes is not parsed correctly from powershell)

and perform an API call on your keyvault using as Authorization the token that we retrieved earlier.

Invoke-WebRequest -Uri "https://spfykey.vault.azure.net/secrets/dbpassword/4f371b23cf244717a585e12af9846dec?api-version=7.3" -Headers @{Authorization = "Bearer $metavliti"} -UseBasicParsing

As a result we sucessfully retrieved the password for the secret which is 123456 by performing a rest api call through the web app using the Managed Identity of the app service.

References:

https://learn.microsoft.com/en-us/rest/api/keyvault/keyvault/vaults