Introduction to Azure DevOps Workload identity federation (OIDC) with Terraform

by Contributed | Sep 11, 2023 | Technology

This article is contributed. See the original author and article here.

Welcome! This post is going to cover the end-to-end process of configuring and using Workload identity federation in Azure DevOps for your Terraform deployments. We’ll cover:

• Why use Workload identity federation


• What is Workload identity federation and how does it work


• How can your organisation join the Workload identity federation preview


• How to configure Workload identity federation using the Azure DevOps Terraform provider


• How to use Workload identity federation in an Azure DevOps Pipeline with the Terraform task

Why use Workload identity federation

Up until now the only way to avoid storing service principal secrets for Azure DevOps pipelines was to use a self-hosted Azure DevOps agents with managed identities. Now with Workload identity federation we remove that limitation and enable you to use short-lived tokens for authenticating to Azure. This significantly improves your security posture and removes the need to figure out how to share and rotate secrets. Workload identity federation works with many Azure DevOps tasks, not just the Terraform ones we are focussing on in this article, so you can use it for deploying code and other configuration tasks. I encourage you to learn more about the supported tasks here.

What is Workload identity federation and how does it work

Workload identity federation is an OpenID Connect implementation for Azure DevOps that allow you to use short-lived credential free authentication to Azure without the need to provision self-hosted agents with managed identity. You configure a trust between your Azure DevOps organisation and an Azure service principal. Azure DevOps then provides a token that can be used to authenticate to the Azure API.

You can read more about how Workload identity federation works here.

In the first iteration Workload identity federation for Azure DevOps works within the scope of a Service Connection. A new type of Azure Resource Manager Service Connection is available that enables this:

Any task that supports a Service Connection and has been updated to use Workload identity federation can then use your configured trust to interact with Azure resources.

On the Azure side we need to configure Federated Credentials on an App Registration or User Assigned Managed Identity service principal. There are a few settings needed for this, which you can find in the Azure DevOps Service Connection or you can figure out up front:

• Issuer URL: This is the a URL in the format https://vstoken.dev.azure.com/ where organisation-id is the GUID of your Azure DevOps organisation. For example https://vstoken.dev.azure.com/f66a4bc2-08ad-4ec0-a25e-e769dab3b294.


• Subject identifier: This is the mapping to your service connection in the format sc://// where organisation-name is your Azure DevOps organisation name, project-name is your Azure DevOps project name and service-connection-name is the name of your service connection. For example sc://my-organisation/my-project/my-service-connection.


• Audience: This is always api://AzureADTokenExchange.

Here is what it looks like in the Azure Portal:

Once we have the service connection and federated credentials configured, we can use the service connection to authenticate to Azure. You’ll just need to grant your service principal some permissions in the subscription.

How can your organisation join the Workload identity federation preview

The preview is open to anyone, you can input the name of your Azure DevOps organisation into this form to sign up. Once signed up, you’ll have access to the feature flag and you’ll find it under the organisation ‘Preview Features’ menu. Turn it on and you’ll see the new Azure Resource Manager Service Connection types. You can find lots more information here.

How to configure Workload identity federation using the Azure DevOps Terraform provider

The Azure DevOps Terraform provider has been updated to support the creation of Workload identity federation Service Connections. The documentation can be found here.

The following example shows how to setup a Service Connection and User Assigned Managed Identity with Federated Credentials:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">=3.0.0"
    }
    azuredevops = {
      source = "microsoft/azuredevops"
      version = ">= 0.9.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azuredevops_project" "example" {
  name               = "Example Project"
  visibility         = "private"
  version_control    = "Git"
  work_item_template = "Agile"
  description        = "Managed by Terraform"
}

resource "azurerm_resource_group" "identity" {
  name     = "identity"
  location = "UK South"
}

resource "azurerm_user_assigned_identity" "example" {
  location            = azurerm_resource_group.identity.location
  name                = "example-identity"
  resource_group_name = azurerm_resource_group.identity.name
}

resource "azuredevops_serviceendpoint_azurerm" "example" {
  project_id                             = azuredevops_project.example.id
  service_endpoint_name                  = "example-federated-sc"
  description                            = "Managed by Terraform"
  service_endpoint_authentication_scheme = "WorkloadIdentityFederation"
  credentials {
    serviceprincipalid = azurerm_user_assigned_identity.example.client_id
  }
  azurerm_spn_tenantid      = "00000000-0000-0000-0000-000000000000"
  azurerm_subscription_id   = "00000000-0000-0000-0000-000000000000"
  azurerm_subscription_name = "Example Subscription Name"
}

resource "azurerm_federated_identity_credential" "example" {
  name                = "example-federated-credential"
  resource_group_name = azurerm_resource_group.identity.name
  parent_id           = azurerm_user_assigned_identity.example.id
  audience            = ["api://AzureADTokenExchange"]
  issuer              = azuredevops_serviceendpoint_azurerm.example.workload_identity_federation_issuer
  subject             = azuredevops_serviceendpoint_azurerm.example.workload_identity_federation_subject
}

The items of note are:

• We have to supply the client id of our service principal in the credentials block service connection, so it knows which service principal is configured with federation.


• We supply the string WorkloadIdentityFederation in the service_endpoint_authentication_scheme attribute to tell it the type of service connection we want to create.


• We use the workload_identity_federation_issuer and workload_identity_federation_subject outputs of our service connection to populate the federated credentials. This is a shortcut for getting this information, which you of course get from elsewhere if you prefer.

Once you run this Terraform and create these resources you’ll be ready to use the Service Connection in your Azure DevOps Pipeline.

How to use Workload identity federation in an Azure DevOps Pipeline with the Terraform task

We have updated the two most popular Terraform Tasks to support Workload identity federation, these are:

• Microsoft DevLabs Terraform: DevLabs Terraform


• Jason Johnson (formerly Charles Zipp) Azure Pipelines Terraform Tasks: Azure Pipelines Terraform Tasks

The following example shows how to use the Microsoft DevLabs task in an Azure DevOps Pipeline:

 jobs:
    - deployment: deploy
      displayName: Deploy with Terraform
      pool: 
        vmImage: ubuntu-latest 
      environment: dev
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self
              displayName: Checkout Terraform Module
            - task: TerraformInstaller@0
              displayName: Install Terraform
              inputs:
                terraformVersion: 'latest'
            - task: TerraformTaskV4@4
              displayName: Terraform Init
              inputs:
                provider: 'azurerm'
                command: 'init'
                workingDirectory: '$(workingDirectory)'
                backendServiceArm: '${{ variables.serviceConnection }}'
                backendAzureRmResourceGroupName: '$(BACKEND_AZURE_RESOURCE_GROUP_NAME)'
                backendAzureRmStorageAccountName: '$(BACKEND_AZURE_STORAGE_ACCOUNT_NAME)'
                backendAzureRmContainerName: '$(BACKEND_AZURE_STORAGE_ACCOUNT_CONTAINER_NAME)'
                backendAzureRmKey: 'terraform.tfstate'
              env:
                ARM_USE_AZUREAD: true # This environment variable tells the backend to use AzureAD auth rather than trying a create a key. It means we can limit the permissions applied to the storage account and container to least priviledge: https://developer.hashicorp.com/terraform/language/settings/backends/azurerm#use_azuread_auth
            - task: TerraformTaskV4@4
              displayName: Terraform Apply
              inputs:
                provider: 'azurerm'
                command: 'apply'
                workingDirectory: '$(workingDirectory)'
                commandOptions: '-auto-approve -var="resource_group_name=$(AZURE_RESOURCE_GROUP_NAME)"'
                environmentServiceNameAzureRM: '${{ variables.serviceConnection }}'
              env:
                ARM_USE_AZUREAD: true

Right now you are probably thinking “how is this any different to what I do now?” and you’d be right to think that because there is no difference. The Workload identity federation implementation is abstracted away into the choice of Service Connection type. The task knows based on the type of Service Connection how to authenticate to Azure and set the relevant environment variables for you.

If you want to know how you can do it yourself outside of the terraform task, you can see an example of using the Azure CLI task here and here.

Conclusion

We’ve shown you how to configure and use Workload identity federation for Azure DevOps, we want you to SIGN UP FOR THE PREVIEW and start using it right away.

If you want a more in depth example, you can refer to this sample repository.

Thanks for reading, feel free to ask questions.

ADX Web UI updates – August 2023

by Contributed | Sep 10, 2023 | Technology

This article is contributed. See the original author and article here.

Introducing the new Get Data Experience: Streamlining Your Data Ingestion Journey

We’re thrilled to unveil a brand new Get Data Experience – the next generation evolution of Ingestion Experience in Azure Data Explorer (ADX)! Designed with simplicity and efficiency in mind, this update streamlines the way you bring data into ADX. Whether you’re a seasoned data professional or just starting your data exploration journey, this new user experience is crafted to empower you every step of the way.

Dive in today and explore the new Get Data Experience! Azure Data Explorer

Read more Introducing the New Get Data Experience: Streamlining Your Data Ingestion Journey – Microsoft Community Hub

Supporting various auth methods for clusters’ connections

By allowing users to set up connections with alternative credentials, we now provide seamless experience for managing clusters from various user accounts or Azure AD directories.

When adding new cluster connections, if you have multiple user accounts and want to authenticate with a different account, or your account is linked to multiple Azure AD directories, you can follow the optional steps described in this document to create the connections.

Once connected, you can switch between clusters associated with different credentials within a unified interface, without a need to repeatedly sign in and sign out or switch directories.

In the above image The HomeCluster connection uses different credentials from those of the signed-in user, as indicated by the small icon of a person in the upper-left corner.

Heatmap – new visual in ADX dashboards

We’re happy to let you know that we just released a new Heatmap visual.

Heatmaps are graphical representations of data using color. They are most commonly used to provide a clear view of numerical values.

To learn more about heatmap visualization in ADX dashboards, read this document

Azure Data Explorer Web UI team is looking forward for your feedback in KustoWebExpFeedback@service.microsoft.com

You’re also welcome to add more ideas and vote for them here – https://aka.ms/adx.ideas

Read more:

• ADX Web July updates – ADX Web UI updates – July 2023 – Microsoft Community Hub

How To Use Cache for Re-platform to Azure

by Contributed | Sep 8, 2023 | Technology

This article is contributed. See the original author and article here.

Overview

Moving to Cloud is a crucial part of digital transformation as business grows. As a leading Cloud provider, Azure provides intuitive, guided, and repeatable support for migrating an on-prem application to Azure cloud. You can learn more at Reliable web app pattern – Azure Architecture Center.

To ensure a web application runs performantly and resiliently, you can use Azure Cache for Redis. This blog zooms into caching best practices and guidance in the Reliable Web App Pattern.

Moving In-Memory Cache to Distributed Cache in Azure

Suppose your online order web app saves shopping cart items in a user’s session data in memory. As you migrate a web application from on-prem to Azure Cloud, caching in-memory no longer works because the virtual servers may scale-in or shut down to save cost. In such cases, in-memory data will be gone. Distributed caching persists cached data by decoupling cache from the web server instances to support scalability and resiliency. In addition, if you were self-hosting Redis Cache, re-platform to use Azure Cache for Redis removes operational overhead from self-hosting. Azure resources located within the same data center have negligible network latency, and the in-memory nature of Azure’s Cache service ensures accessing data is fast.  

Azure Cache for Redis is the 1^st party caching solution in Azure. Developed in partnership with Redis Inc, Azure Cache for Redis provides the unparalleled up to 99.999% SLA with Enterprise SKUs, data replication across geographic locations, and scenario-drive cost effective hosting options to meet your business needs.

Patterns and Best Practices to Use Distributed Caching in Azure

To help customers successfully re-platform from on-prem to Azure, the Reliable web app pattern offers reference architecture scenarios to guide the process. Currently, the Reliable Web App Pattern for .NET and Java are available. Without losing generosity, we will look at the recently announced Java support for how to apply caching when migrating an application.

We recently announced GA for the Java version of Reliable Web App pattern, which is a set of architectural recommendations and guided, repeatable process with Reference Architecture applications to ensure customers can successfully migrate to Azure. You can learn more at Reliable web app pattern for Java – Plan the implementation – Azure Reference Architectures. In the example reference application, an online training web app written in Java Spring Framework is transformed to run on Azure. Figure 1 shows a screenshot of the web application, which is a real-world and production-ready training web application that shows a series of educational tutorials. The playlist of video tutorials might be different for each user and can be cached for quick access and saving a user’s training progress.

Figure 1: Java sample application homepage that shows training video playlist

In the reference architecture caching is applied to multiple scenarios such as logged in user settings, security settings, and displaying the playlist on the homepage as shown in Figure 1. Let’s look at how smooth it is to transition from local cache to Azure with our example.

Per Figure 2, initializing Redis in a Java application only takes a few lines of code, and the configuration is very flexible. You can find it at RedisConfig.java.

Figure 2: Initializing Redis client in a Java Spring web application.

Java Spring Caching abstraction allows tag annotations to be used for indicating if a method’s return value should be cached and how. In Figure 3, the tag annotations hide all the details on interacting with Redis Cache and allows developers to focus on business logic. Referring back to the video playlist shown in Figure 1 above, in its implementation from the PlaylistService.java, the playlist and playlist per user are cached for saving user progress and performantly and query-efficiently loading the result next time.

Figure 3: Java Spring Caching Abstraction for caching method return results.

Deploying the application to use Azure Cache for Redis is straight forward. Just point the app configuration to the right Azure Cache for Redis endpoints to get your app working! Follow the README.md instructions to deploy the app.

Use the Cache-Aside pattern for data consistency

As a user’s playlist is part of the session data and is saved in cache, what if the overall playlist gets updated? How do we make sure information in cache stays consistent with the backend database?

The cache-aside pattern guarantees application data consistency. It would attempt to read from cache every time, upon a cache miss it reads from the database and put the value in cache for the next read, and upon an update in database all related cache records will be cleared to keep data up-to-date. Figure 4 illustrates how the cache-aside pattern keeps data from cache to the backend data store to be consistent. You can learn more at Cache-Aside pattern – Azure Architecture Center.

Figure 4: cache-aside pattern keeps cache and datastore consistent

Referring to our Java sample application, the Spring Caching Abstraction hides the details as this algorithm is a highly repeatable process.

Next steps

You can learn more about the .NET reference application at Introducing the Reliable Web App Pattern for .NET – .NET Blog. Read more about the Reliable Web App Pattern at Reliable web app pattern – Azure Architecture Center.