Federate Azure DevOps with AWS Using OpenID Connect for Secure CI/CD

  • Thread Author
In the modern age of CI/CD (Continuous Integration and Continuous Deployment), achieving seamless integration between tools used across cloud and development ecosystems is crucial. Azure DevOps, a powerful platform supporting continuous delivery pipelines, now offers a game-changing capability: Federating into AWS using OpenID Connect (OIDC). This new tool can streamline operations, tightening up security by eliminating static credentials.
Mathieu Bruneau’s detailed exploration outlines how Azure DevOps users can federate into AWS accounts via OIDC as part of his latest AWS blog post. Let’s dive head-first into the nitty-gritty, unpack what this means, and provide you with actionable insights. For our WindowsForum.com audience, I’ll spotlight the technical implementation while also interpreting key terms for clarity.

What’s All the Buzz About?

Azure DevOps Pipelines and AWS Toolkit for Azure DevOps have finally teamed up with OIDC federation! This advanced feature, supported by AWS Toolkit for Azure DevOps version 1.15.0+, allows developers to obtain temporary security credentials to AWS resources directly from Azure DevOps without managing static AWS credentials.
The move to support federated logins is a step forward from traditional long-lived IAM (Identity and Access Management) keys, ensuring improved security through minimized exposure of credentials. It also aligns with industry best practices for security, such as the Principle of Least Privilege and reducing operational burdens like periodic credential rotations.
No more static keys? Sign me up. But wait—there’s some assembly required!

So… What Exactly Is OpenID Connect?

Before we dissect the implementation steps, let’s digest what OpenID Connect (OIDC) brings to the table:
  • Authentication Protocol: Think of OIDC as a lightweight layer on top of OAuth 2.0. It’s designed to let users authenticate using their login credentials from a trusted identity provider (in this case, Azure DevOps).
  • Federation: OIDC Federation creates a bridge between Azure DevOps and AWS by establishing trust, allowing workloads or applications to communicate securely without pre-shared credentials.
  • Temporary Credentials: These are ephemeral (short-lived) permissions given to Azure DevOps agents to interact with AWS—like a backstage pass that expires after the show.
Instead of juggling hardcoded IAM credentials for AWS operations, the AWS Security Token Service (STS) dynamically generates temporary access tokens using a trust relationship baked into OIDC.
In easier terms: OIDC gets rid of the weak links (static credentials) for a robust, compartmentalized, and automation-ready authentication strategy.

High-Level Walkthrough of the Federation Process

Here’s a high-level look at what you'll accomplish implementing OIDC between Azure DevOps and AWS:
  • Azure DevOps Pipelines Outputs OIDC Tokens: Azure DevOps emits short-lived tokens that can be used to authenticate workload activities.
  • AWS STS Issues Temporary Credentials Based on Tokens: AWS validates the token using pre-configured roles and trusts, then spins up time-bound credentials for the certified workload.
  • Access AWS Resources Securely: With tokens now becoming temporary AWS credentials, your Azure DevOps pipelines can deploy to AWS Services like Amazon S3, Lambda, or DynamoDB.
No manual key. No rotation worries. Just seamless integration.

Detailed Implementation: A Step-by-Step Guide

The original blog described a multi-phase implementation process. Here’s a WindowsForum breakdown with added clarity for newcomers and experts alike:

Step 1: Prerequisites

Before you start, ensure you have the following:
  • AWS IAM Permissions: You’ll need permissions in AWS to CreateRole, ListOpenIDConnectProviders, and CreateOpenIDConnectProvider. Consult your AWS Admin.
  • AWS Toolkit for Azure DevOps (v1.15+): Install this from the Visual Studio Marketplace.
  • Azure DevOps Access: You should have permissions to create service connections and pipelines.
  • Organization GUID from Azure DevOps: Trust me, you’ll need this ID.

Step 2: Set Up Your Azure DevOps Pipeline

  • Go to Project Settings > Service Connections in Azure DevOps and create a new service connection for AWS.
  • Check the Use OIDC option during setup and use a target role name like azdo-federation.
The goal here is to have Azure DevOps output a token that can later validate a claim via OIDC.

Step 3: Configure an OIDC Identity Provider in AWS

At this point, use your Organization GUID from Azure DevOps to set up your AWS OIDC provider:
  • Log into the AWS IAM Console → Select Identity Providers under Access Management.
  • Create an OIDC Identity Provider with the following:
  • Provider Type: OpenID Connect.
  • Provider URL: [[URL='https://vstoken.dev.azure.com/%7BOrganizationGUID%7D%5B/ICODE%5D(https://vstoken.dev.azure.com/%7BOrganizationGUID%7D%5B/ICODE']https://vstoken.dev.azure.com/{OrganizationGUID}(https://vstoken.dev.azure.com/%7BOrganizationGUID%7D%5B/ICODE[/URL])].
  • Audience: api://AzureADTokenExchange (a fixed value for Azure DevOps).

Step 4: Create an IAM Role for AWS Federation

Roles, folks, are the MVP here. They act as gatekeepers to AWS resources:
  • Choose Web Identity Federation as the trusted option for this role.
  • Include a trust policy that limits permissions to a specific pipeline service connection in Azure DevOps. An example might look like this:
JSON:
{
"Version": "2012-10-17",
"Statement": [
[CODE]{
"Effect": "Allow",
"Principal": {
[ICODE]"Federated": "arn:aws:iam::123456789012:oidc-provider/vstoken.dev.azure.com/{OrganizationGUID}"[/ICODE]
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
[CODE]"StringEquals": {

  "vstoken.dev.azure.com/{OrganizationGUID}:aud": "api://AzureADTokenExchange",

  "vstoken.dev.azure.com/{OrganizationGUID}:sub": "sc://{OrganizationName}/{ProjectName}/{ServiceConnectionName}"

}
}
}[/CODE]
]
}[/CODE]
  • Replace placeholders like {OrganizationGUID} with real values.
  • Attach permissions to the role only as needed (remember the Principle of Least Privilege).

Step 5: Test the Federation

  • Run your Azure DevOps pipeline with a script that invokes aws sts get-caller-identity.
  • The success result should contain AWS-provided credentials, proving the federated workload.

Real-World Usage & Capabilities

Once federation is up and running, your Azure DevOps pipelines can:
  • Deploy Applications to AWS: Push Lambda functions, S3 buckets, or Heat Templates via AWS CLI.
  • Integrate Other Tools: Combine with tools like Terraform to provision infrastructure dynamically.
  • Fine-Tune Permissions: Limit temporary credentials’ privileges based on job-specific requirements.
What’s even better? Say goodbye to forgetfulness around rotating keys! OIDC handles the lifecycle automatically.

Security Advantages

This setup doesn’t just make life easier—it adds layers of security:
  • Ephemeral Credentials Means Reduced Exposure: Tokens expire, preventing misuse after their execution window.
  • Centralized Management: Control access directly in your Azure DevOps pipeline definitions.
  • Streamlined Auditing: AWS CloudTrail allows tracing OIDC usage for compliance reporting.

Wrap-Up

Integrating Azure DevOps with AWS via OIDC isn’t just a convenience—it’s a paradigm shift. It eliminates redundant IAM keys while strengthening security. If your workflows span both platforms, this setup should be high on your to-do list.

Questions for the Forum:​

  • Has anyone tried OIDC for federated access before? What challenges did you face?
  • How is AWS handling multi-cloud integration in your experience?
Let’s kick off these discussions below—The WindowsForum community is here to delve deeper into multi-cloud innovations!

Source: Amazon Web Services How to federate into AWS from Azure DevOps using OpenID Connect