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

Integrate SonarQube with Teamcity

Sonarqube is a self-managed, automatic code review tool that systematically helps you deliver clean code. SonarQube integrates into your existing workflow and detects issues in your code to help you perform continuous code inspections of your projects. In this article we will examine how to integrate it with Teamcity in order to scan our workflows during build.

First you will need to install the sonar runner for your teamcity installation. You should go in the administration tab

and then plugins

Then browse plugin directory and install the sonar runner.

After that you should go in root project and integrate sonar tool with teamcity.

Press add a new server and provide Name, URL and the Token. Token can be retrieved from your sonar installation. Under Administration select security and create a new token with an expiry date.

Finally you can create a new build definition and use the sonar scanner plugin.

Posted on Leave a comment

How to find custom defined values in helm charts

I was trying to validate if a custom value that I overrode on a helm deployment was correct. In order to override a value in values.yaml you will need to pass the set flag as shown below.

helm upgrade --install -n sonarqube sonarqube sonarqube/sonarqube --set persistence.enabled=true

In the above installation command I override the persistence.enabled value to true instead of false that is by default.

First of all you will need to get the release name of the helm chart that you deployed. You can find this information by

helm list --all -n namespace

After finding the name of the release you will need to use the get command in order to get values.

 helm -n sonarqube get values sonarqube -n sonarqube

This option will persist the Elasticsearch indexes in a Persistent Volume, but with regular killing operations by the Kubernetes Cluster, these indexes can be corrupted. By default, persistency is disabled in the Helm chart.

Deploy SonarQube on Kubernetes (sonarsource.com)

Posted on Leave a comment

How to implement Managed Identity on Service Fabric

Workloads deployed in Service Fabric clusters require Azure AD application credentials or managed identities to access Azure AD protected resources, such as Azure Key Vault and storage accounts. In case of Azure AD applications one can create a new app registration then assign permissions from Access control and finally use the client secret of this application inside the service fabric service.

If you need to enhance security and built based on well architected framework principles you can integrate managed identity authentication inside service fabric applications. Typically when you need to deploy an application on service fabric you should connect to the cluster and deploy using powershell commands. If you want to use managed identity it’s a whole different procedure and the first thing that needs to be changed is the deployment of the service inside the sf cluster.

The high level diagram can be found below.

It is mandatory to deploy the service fabric application as an arm template in order to enable managed identity. There is no other way to implement managed identity authentication except from arm templates.

In more detail there are some steps that need to be performed for the deployment:

  • some references for the user assigned managed identity should be added inside service fabric application in ServiceManifest.xml and ApplicationManifest.xml
  • the output package after the build should be bundled in a sfpkg zip format
  • the package should be uploaded in a storage account and it should be accessible from service fabric cluster (sas token)
  • an arm template should be created with some necessary information for the deployment such as application type and version, packageUrl, cluster name, managed identity name etc.
  • arm template should be applied in service fabric cluster resource group

Service fabric cluster configuration

ManagedIdentityTokenService should be enabled on Service Fabric cluster.

https://learn.microsoft.com/en-us/azure/service-fabric/configure-existing-cluster-enable-managed-identity-token-service

Azure configuration

  • Given that you have already created a user assigned Managed Identity you will need to add some references inside the service fabric application.

ApplicationManifest.xml

 <Principals>
    <ManagedIdentities>
      <ManagedIdentity Name="userassignedMI" />
    </ManagedIdentities>
  </Principals>
    <Policies>
      <IdentityBindingPolicy ServiceIdentityRef="SFServiceUser" ApplicationIdentityRef="userassignedMI" />
    </Policies>

ServiceManifest.xml

<ManagedIdentities DefaultIdentity="SFServiceUser">
    <ManagedIdentity Name="SFServiceUser" />
</ManagedIdentities>

https://learn.microsoft.com/en-us/azure/service-fabric/how-to-deploy-service-fabric-application-user-assigned-managed-identity

  • Then the appropriate RBAC should be assigned on the user assigned managed identity which is referenced inside service fabric application.

Code

In our code we can authenticate using Managed Identity instead of a connection string (DefaultAzureCredential class will automatically locate the managed identity configuration and use it).

var blobServiceClient = new BlobServiceClient( new Uri("https://storage.blob.core.windows.net"), new DefaultAzureCredential());

Deployment

The final step would be to deploy the application. Apply arm-template.json to create the SF service.

 az deployment group create --name sfdeployment --resource-group rgofsfcluster --template-file servicefabric-arm.json

Finally application will be created on service fabric cluster using arm templates supporting managed identity authentication.