Azure DevOps Workload Identity Federation with Azure Overview. NO MORE SECRETS!

Summary

This video explores leveraging workload identity federations in Azure DevOps to securely authenticate and authorize service connections without relying on secrets. It highlights the drawbacks of traditional app registration methods with secrets and introduces using OpenID Connect with Azure Active Directory (AAD) to establish a federated identity and generate access tokens. The process streamlines security, simplifies maintenance, and grants specific pipelines controlled access to service connections representing app registrations. Additionally, the video covers converting existing secret-based service connections, bulk conversion scripts, and utilizing managed identities as an alternative for those without app registration permissions.

Takeaways

• 💻 Azure DevOps can leverage Workload Identity Federations to securely authenticate service-to-service communications, eliminating the need for storing secrets.
• 🔑 Traditionally, app registrations and service principles in Azure AD (ENT) facilitated authentication, requiring secrets for service connections in Azure DevOps.
• 🛠️ With Identity Federation, the reliance on secrets is removed, enhancing security and simplifying maintenance by using OpenID Connect for authentication.
• 📚 Azure DevOps automatically integrates with Azure AD, simplifying the initial setup for OpenID Connect-based authentication.
• 🛡️ Workload Identity Federation service connections in Azure DevOps eliminate the need for secrets by establishing a federation link to app registrations.
• 📝 Managed identities offer an alternative to app registrations, useful when permissions to create app registrations are restricted.
• 📈 The process involves creating a federated credential for the managed identity, specifying issuer URL and subject identifier.
• 🔧 Azure DevOps supports converting existing service connections to use Workload Identity Federation, streamlining the transition to a more secure setup.
• 🔨 Role-Based Access Control (RBAC) in Azure ensures that the app registration or managed identity has the necessary permissions on target resources.
• 📊 Managed identities and service principals enable Azure DevOps pipelines to authenticate without secrets, relying on tokens issued by Azure AD.

Q & A

What is the purpose of using workload identity federations in Azure DevOps?

The purpose of using workload identity federations in Azure DevOps is to securely authenticate services without the need for secrets, allowing pipelines to interact with Azure resources securely and efficiently.

What role does Azure Active Directory (Azure AD) play in the authentication process between Azure DevOps and Azure?

Azure Active Directory (Azure AD), formerly known as Entra, acts as the identity provider that binds Azure DevOps and Azure together, facilitating the authentication process by trusting app registrations and issuing tokens for secure interactions.

How does the traditional authentication method using service principals and secrets work in Azure DevOps?

Traditionally, Azure DevOps uses an app registration in Azure AD to create a service principal, which is then configured with a secret. This secret is used by a service connection in Azure DevOps to authenticate and interact with Azure resources.

What are the drawbacks of using secrets for authentication in Azure DevOps?

Using secrets for authentication in Azure DevOps poses security risks, as it requires storing and managing sensitive information, which could be misused if compromised. It also involves additional management tasks, such as secret rotation and expiry handling.

How does OpenID Connect improve the authentication process in Azure DevOps?

OpenID Connect improves the authentication process by allowing Azure DevOps to authenticate using identity tokens instead of secrets. This method leverages a standard protocol for authentication, reducing the need for managing secrets and enhancing security.

What is required to create a new workload identity federation-based service connection in Azure DevOps?

To create a new workload identity federation-based service connection, one needs permission to create an app registration in the Azure AD tenant. This app registration will be linked to the service connection without requiring a secret.

How does Azure DevOps authenticate using workload identity federation and OpenID Connect?

Azure DevOps authenticates using workload identity federation and OpenID Connect by issuing an identity token from Azure DevOps, which is then validated and exchanged for an access token by Azure AD, allowing secure access to Azure resources.

Can existing service connections using secrets be converted to use workload identity federation?

Yes, existing service connections using secrets can be easily converted to use workload identity federation, enhancing security by eliminating the need for secrets and simplifying maintenance.

What alternative is available in Azure DevOps if creating app registrations is not permitted?

If creating app registrations is not permitted, managed identities can be used as an alternative in Azure DevOps. This allows for secure authentication without needing to manage app registrations or secrets.

What are the benefits of using workload identity federation in Azure DevOps?

The benefits of using workload identity federation in Azure DevOps include improved security by avoiding secrets, simplified management without the need for secret rotation, and streamlined authentication processes using standard protocols like OpenID Connect.

Outlines

00:00

👨‍🏫 Introducing Azure DevOps Workload Identity Federations

The speaker introduces the topic of workload identity federations in Azure DevOps. He explains that when services need to authenticate with each other, an identity must be established to validate that the service is allowed to act on behalf of a certain identity with roles on the target resource. The traditional approach involves creating an app registration in Azure AD (now known as Entra) that gives a service principal with a secret. This secret is then used in Azure DevOps to create a service connection, which is configured with the app registration details and secret. The pipeline is given permission to use this service connection, which sends the details to Entra to generate an access token. The pipeline can then use this access token to perform operations against the Azure Resource Manager. However, managing secrets is not ideal as it raises security concerns and requires ongoing maintenance like rotation.

05:01

🔑 Leveraging OpenID Connect for Secure Identity Federation

The speaker introduces OpenID Connect as a secure alternative to using secrets. OpenID Connect is an authentication protocol built on top of OAuth 2.0, which is an authorization protocol. OpenID Connect provides proof of identity through JSON Web Tokens (JWT) that are signed by the issuer. Azure DevOps is already integrated with Entra (formerly Azure AD), allowing for an OpenID Connect federation to be leveraged. This approach creates an app registration behind the scenes, but this app registration is linked to a specific service connection through a federated credential. There are no secrets or certificates involved, just the federated credential. The speaker explains the details of the issuer URL, subject identifier, and audience used in the federation.

10:05

🔄 Workload Identity Federation Workflow

The speaker walks through the workflow of using workload identity federation. First, the pipeline is granted permission to use the specific service connection. The pipeline then requests a token from Azure DevOps, which acts as the local identity provider. Azure DevOps generates an identity token and returns it to the pipeline. The pipeline then passes this identity token to Entra (Azure AD) and requests an access token. Entra validates the identity token by checking the well-known OpenID Connect configuration endpoint to verify the certificates used for signing. Once validated, Entra creates and returns an access token to the pipeline. The pipeline can then use this access token to perform operations against the Azure Resource Manager endpoint using the permissions granted to the associated app registration.

15:06

🛠️ Setting Up Workload Identity Federation

The speaker explains the process of setting up a workload identity federation service connection in Azure DevOps. Creating a new service connection defaults to using workload identity federation, and the user can select the target subscription, management group, or resource group. Granting access to specific pipelines rather than all pipelines is recommended. Existing service connections using secrets can be converted to use workload identity federation with the click of a button or through a bulk conversion script. If the user cannot create app registrations, they can use managed identities instead. The speaker demonstrates how to add a federated credential to a managed identity and the necessary information needed from the managed identity and Azure DevOps to set up the federation manually.

20:07

🎯 Advantages of Workload Identity Federation

The speaker concludes by emphasizing the key advantage of workload identity federation: eliminating the need for secrets. Just as passwordless technologies are preferred for users, eliminating secrets for service-to-service authentication is a more secure approach. Workload identity federation allows pipelines to be granted specific permissions to use certain service connections, which can then be used to obtain an access token from Entra (Azure AD) with the appropriate roles granted to the associated app registration or managed identity. This approach removes the need to manage and maintain secrets, improves security, and simplifies maintenance.

Keywords

💡Workload Identity Federation

Workload Identity Federation is a concept that allows Azure DevOps pipelines to authenticate with Azure resources without the need for secrets or certificates. It leverages OpenID Connect to provide an identity token that can be exchanged for an access token to perform operations against Azure Resource Manager. This approach eliminates the need for storing and managing secrets, improving security and simplifying maintenance. The video discusses how to configure Workload Identity Federation in Azure DevOps and the benefits it provides over the traditional method of using app registrations with secrets.

💡OpenID Connect

OpenID Connect is an authentication protocol built on top of OAuth 2.0. It provides a standardized way for applications to prove their identity, known as authentication, as opposed to OAuth 2.0, which is primarily about authorization. OpenID Connect uses JSON Web Tokens (JWTs) to convey claims about the identity of the user or application. In the context of the video, OpenID Connect is used by Azure DevOps to issue identity tokens that can be validated by Azure Active Directory (Azure AD) and exchanged for access tokens, enabling secure communication between Azure DevOps and Azure resources.

💡Service Connection

A Service Connection in Azure DevOps is a configuration that provides the necessary details for a pipeline to authenticate and connect to external services or resources, such as Azure Resource Manager. It contains information like the app registration, subscription details, and authentication credentials. The video discusses how traditional service connections relied on secrets or certificates, while Workload Identity Federation allows for the creation of service connections that leverage OpenID Connect for authentication, eliminating the need for secrets.

💡App Registration

An App Registration, also known as a Service Principal, is a representation of an application or service in Azure Active Directory (Azure AD). It is used to grant permissions and access to Azure resources. In the context of the video, traditional service connections required creating an App Registration with a secret or certificate. With Workload Identity Federation, an App Registration is still created behind the scenes, but it is linked to the service connection and does not require a secret. This improves security and simplifies maintenance.

💡Managed Identity

Managed Identity is a feature of Azure that provides an automatically managed identity for Azure resources, such as virtual machines or Azure Functions. Managed Identities are essentially Service Principals that do not require storing and managing credentials. The video mentions that if a user does not have permission to create App Registrations, they can use Managed Identities and configure Federated Credentials to leverage Workload Identity Federation without the need for secrets.

💡Federation

Federation, in the context of the video, refers to the process of establishing a trust relationship between Azure DevOps and Azure Active Directory (Azure AD). This allows Azure DevOps to issue identity tokens that can be validated and trusted by Azure AD. Federation enables the exchange of identity information and authentication between different systems or domains without the need for shared secrets or credentials. It is a key component of Workload Identity Federation, which eliminates the need for storing and managing secrets in Azure DevOps.

💡Identity Token

An Identity Token is a type of security token issued by an identity provider, such as Azure DevOps in the context of Workload Identity Federation. It contains claims about the identity of the subject, such as the application or service that is requesting authentication. Identity tokens are signed and can be validated by the recipient, in this case, Azure Active Directory (Azure AD). They are used to exchange authentication information between different systems and are a fundamental part of the OpenID Connect protocol.

💡Access Token

An Access Token is a type of security token that is used to grant access to protected resources. In the context of the video, Azure Active Directory (Azure AD) issues access tokens to Azure DevOps pipelines after validating the identity token received from Azure DevOps. These access tokens contain information about the permissions and roles assigned to the app registration (Service Principal) and allow the pipeline to perform operations against Azure Resource Manager, such as deploying resources or managing configurations.

💡Well-Known Configuration

Well-Known Configuration is a standardized way for OpenID Connect providers to publish their configuration details, such as supported scopes, signing keys, and endpoints. It is accessible through a well-known URL format, typically `https://<issuer>/.well-known/openid-configuration`. In the video, it is mentioned that Azure Active Directory (Azure AD) can use the Well-Known Configuration to validate the identity tokens issued by Azure DevOps and verify the signature using the published signing keys. This allows Azure AD to trust the identity tokens and issue access tokens accordingly.

💡Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) is a method of controlling access to resources based on the roles assigned to users or applications. In the context of the video, the app registration (Service Principal) created for the Workload Identity Federation service connection is granted specific roles within the Azure subscription or resource group. These roles determine the permissions and allowed actions for the app registration. RBAC is used to apply the principle of least privilege, granting only the necessary permissions for the pipeline to perform its required tasks.

Highlights

Introduction to Azure DevOps and its integration with Azure using service connections.

Explanation of traditional app registration and service principle in Azure AD for Azure DevOps.

Issues associated with using secrets for service connections, such as security risks and management difficulties.

Introduction to the concept of workload identity federations to eliminate the need for secrets.

How OpenID Connect and OAuth 2.0 are leveraged for secure authentication without secrets.

Detailed walkthrough of converting traditional secret-based service connections to workload identity federation.

Step-by-step guide on creating new workload identity federation based service connections.

Explanation of automatic and manual configurations for workload identity federation.

Benefits of workload identity federation, such as improved security and simplified maintenance.

Use of managed identities as an alternative to app registrations when necessary.

How to grant specific pipelines permission to use new service connections securely.

Detailed explanation of the token exchange process between Azure DevOps and Azure AD.

The role of issuer, subject identifier, and audience in the authentication process.

Conversion process for existing service connections to use workload identity federation.

Overview of the benefits of removing secrets and transitioning to a more secure, federated identity model.

Transcripts

hey everyone in this video I want to

talk about the Azure devops capability

to leverage workload identity

federations whenever we have any service

talking to another service it has to be

a to authenticate it needs some way to

validate it's allowed to act as a

certain identity that can be given roles

on that Target resource so in this

example what we're focusing on is we

have our azure

devops

and our Azure devops remember we have

the idea of pipelines and so we have

some

Pipeline and that pipeline is going to

be

performing certain types of task and

what I want to run that pipeline against

in this case is azure so over here I

have my Azure try and draw an Azure

logos good as I

can so it needs to act as some identity

that Azure knows about and can all be

authenticated with that would have

certain roles against subscriptions

resource groups whatever I

need and the identity provider that

binds all of these together is entra

formerly known as Azure ad so we have

our particular ENT tenant for our

organization and what we have

traditionally done is obviously in this

case both Azure devops and and aure they

integrate and they trust entra they

trust a particular

tenant and so what we would have is we

would create an app registration which

would then give us a service principle

in entra that would be leveraged by a

service connection that we could then

leverage so I could think about well

okay great we will go and create this

app registration so we'll say it's app r

one

but the key Point here is it has a

secret so we say hey it's got secret one

and then what I do in my Azure devops is

well I go ahead and create a service

connection and that service

connection is configured with this

details it's configured with hey app

regge one and it's configured with that

secret

and then I give the pipeline

permission to use that service

connection and then the flow is simply

okay well I want to be able to use that

so what would happen is well the PIP

line it can use the service connection

it knows the app registration now

there's other bits of detail about the

client ID Etc but fundamentally it knows

the detail to be able to use this secret

so it would send that detail to ENT so

it's sending hey at Bridge one it's

sending the secret this will now

generate an access

token give it to my Pipeline and now my

pipeline can take that access token and

use it

against the management endpoint for the

Azure resource manager and again this

app registration would be given certain

roles on

here and we can see this so if we

quickly jump over so if we go and look

if I look in my Azure devops environment

I have two service connections but we'll

look at this first

one and we can see it's got a certain

name ay devops for Dev and notice it's

giving us this little notification hey

you could convert this for improved

security and simplified maintenance but

we'll come back to that and what this

represents is this at registration which

again is a service principle but the key

Point here is it it has this secret it

has this certain secret which has a

certain value it has a certain expiry

date so there's a certain amount of now

work in terms of the rotation of that

the good news is there's somewhat

automated for us by Azure devops but it

exists like this is not an ideal

scenario to have these things existing

and so when we think about this all up

solution the idea of having this

secret we really just don't like it we

would like to get rid we give this a

frowny face because hey how do I Ure the

security someone else doesn't use that

secret and do something as that identity

against our Azure resource manager and

those resources and again I have to

think well it has a certain expiry

there's certain rotation so there's

management tasks associated with that

which in an Ideal World I really just

don't want to have to deal with um and

so what what can we do better and so the

most secure way is well let's just get

rid of this secret and that's the whole

idea of the identity Federation and so

let's look at what we can do with that

now we have our same actors again so I'm

going to have to quickly redraw so once

again we have the idea of aure over here

and I still can't really draw that logo

very

well once again we have our ENT

tenant and then once again we'll have

our Azure devops so we have the same

actors nothing is

changing with regards to the components

that are being

used but this time we want to try and

avoid having to have that secret that's

the key point point of this and so what

we're going to leverage now is open ID

connect so open ID connect sits on top

of aarf 2 ooff 2 is really an

authorization protocol we use it to say

hey I'm going to allow this certain

service to act on my behalf against this

target resource I own it's about

delegated authorization IE Facebook can

access my photos on this Photograph

cloud service well open ID connect is

all about authentication and providing

some proof of I am who I say I am it's

Al always ajon web token we say it as a

jot even though it's

JWT and it has header it has claims we

can crack this open and look at it but

it's going to provide authenticity from

the issuer by virtue of the fact it has

a signature and there are well-known end

points I can go and check hey for this

issuer which certificates are they using

so I can prove hey it really is coming

through it says it is and GitHub I did a

video on this in the past about GitHub

and its use of open ID connect

Federation so I don't have to maintain

Secrets there well now we have it here

as well with Azure devops and so the

point is because Azure devops is so

integrated with ENT or Azure IDE as it

was formerly known already I don't

actually have to do anything in most

cases for that initial configuration so

what we have available to us is we have

this open ID

connect

Federation that we are going to

leverage and so how are we going to

leverage this now the point is we are

going to go ahead and we're going to

create a new workload identity

Federation based service connection and

so I'm going to say hey I want to

leverage this

new

um workload identity

Federation service

connection now when I do this it's still

now going to go ahead and

create an app registration that

represents this I.E behind the scenes

there is a service principal now what

that means is the person

creating this service connection has to

have the permission to create an app

registration in that tenant now I have

to do that anyway if I was using the old

Secrets based approach But realize hey I

have to have this permission now later

on we'll talk about well if I can't do

that there is a way to use managed

identity as well so we we'll come back

to that later on but what it's going to

do is it's going to go ahead and create

this app registration but this app

registration is now going to have a

federation

link to this particular service

connection uh and so let's take a look

at that so if we jump over we're now

going to look at this second um actually

let go back over here I have another

service

connection and notice on this service

connection it's telling me hey I am

using workload identity Federation with

open ID connect

and if I go and look at the app

registration for this well the first

thing we'll notice is there are no

secrets there's no certificate there is

no secret all we have is this Federated

credential and if we go and look at it

we'll see some interesting

things so the things we're going to

focus on here is the

issuer is voken dod. azure.com so what's

happening here is azure devops is going

to issue us this identity

token it has a subject identifier so

this is the name of my or the name of my

project and the name of my service

connection and when it's talking to

entra for know as Azure ad its

audience is the Azure ad token exchange

they're obviously not renaming that to

entra they probably never will um but

those are key pieces of information so

what this is telling is

for this app registration it has been

linked to this service connection now as

part of that remember so this is now an

issuer so this has the ability to issue

identity tokens and that issuer is this

vs

token

dodev do

azure.com

so this as part of that communication is

going to be the issuer and obviously it

had that

subject

identifier as well which had that

breakdown of those

components so now we have that key

information again it's going to go and

talk to hey I want to exchange this for

that Azure ad token

exchange so what will happen now if

entra receives an identity

token that hey comes from this issuer

has that subject ID that has been

configured and the audience is that

token exchange it can now go and give it

an access token so let's walk through

what that flow actually looks

like so once again I'm going to have a

pipeline nothing is changing there so

I'm going to go ahead and I've got my

particular

pipeline now one thing we have to do is

this particular service

connection

we're going to give

permission very rarely will we say hey

all pipelines can use it so we will at

very specific levels say hey this

pipeline is allowed to use this so if we

were to go back for a

second and have a look at the security

so I'm up here at the top clicking the

little three dots and then looking at

security we'll see the

option for hey no permitted

pipelines we have open access but we're

not going to do that instead if we click

plus I can select the particular

pipelines that I want to be allowed to

use this service connection which could

then act on that behalf so that's one of

the the key things we do we still have

full control over which particular

pipelines are allowed to do

this so what's going to now happen this

pipeline runs and there's tasks in there

that need to use that service

connection so what it's going to

do is it's going to talk to this as kind

of its local identity provider and it's

going to say hey um I need a token

please this is kind of step

one because it has permission to act as

that it's going to generate that

identity

token and return it to the

pipeline the pipeline will now take that

identity

token and it's going to go and pass

it to entra and what it's asking for now

is hey I would like an access

token but before this happens before it

gets the access token entra will

actually

validate now there are well-known end

points for the open ID connect so we

know it came the issue was at VST token.

d. azure.com and so what I can do is I

can go to that

URL and then we add onto it wellknown

openen ID

configuration and it tells us what what

do we

support So this scope is only open ID we

can see subject types and what we can

see

here is well this is the

detail about the actual certificates

that it's using so what entry is going

to do is go to that well-known point and

it can see all of the keys the

certificates has been used for the

signing so that will let it confirm okay

yeah this this is

valid this is who it says it is so at

this point once it's done that

validation

now it will create the access

token return the access token and now

great now the pipeline can take the

access token and send

it along with its request to the

management. azure.com

I.E the endpoint where I'm going to

perform operations against the Azure

resource manager and again the key idea

here is this app

registration will be given Ro based

Access Control here so whatever that app

registration is at a subscription level

or Resource Group level whatever I want

there will be role-based Access Control

giving hey app registration because

that's who the token is this access

token is the app registration one that

service principle hey app regge has um

contributor for example again we always

think least privilege um the least rol

is required to do what it needs to do

but now it will be out to go and perform

those operations and so if we looked at

this we would see in the Azure

subscription we'll see those

various service principles in this case

have the contributor

right and that's the

flow now when I was going to go ahead

and create one of these if we went back

a

step so if I'm looking at all of these

if I just want to do a new service

connection and I want to talk to

arm it's default

is hey workload identity Federation

automatic and from there all I have to

do is Select well what is my target is

it subscription is it Management Group I

could optionally add in a certain

Resource Group so I I can select these

details give it a name a description

again I don't typically do this grant

access to all pipelines I would rather

go in and add it to the specific ones I

want but this would just go ahead and

create

that service connection and again that

would go and create the service

principle that app registration and it

would set up all of those Federation

goodness things for

me now what if I already

have ones that are using the secrets

today well exactly as you can see here

when I look at one of them it has a

convert button I can just hit convert

and it will convert it to use now that

workload identity Federation it's super

easy to do and if you look at the

documentation it even has

scripts that will walk through bulk

doing those conversions for you and

there's information all over the place

so there's kind of a learn

more and it talks about hey how we want

to use these

things and then it's got hey multiple

conversions with a script so it's all

there it's all uh trying to help you

with that now I did mention One

Challenge you may face is if you're not

allowed to create app

registrations and so additionally I can

use managed identities which is a

different type of it's just a special

service principle fundamentally and the

only thing different here is that if we

went ahead and looked if I look at a

managed

identity so I've got a user assign

managed identity and I'm just going to

look up one of them doesn't matter which

one we do have this option for Federated

credentials so I can go ahead and

add a Federated credential so I'm going

to select this other option but notice

it has hooks into GitHub actions and

kubernetes now notice it's asking for

the issuer URL and the subject

identifier notice by default it's

putting in the right hey we want the API

Azure ad token exchange and I would give

a name name for this credential so

there's really two parts to this I don't

know this issue a URL and subject

identifier

yet and there's also some information I

would need from this managed identity

because I'm going to need this sort of

tenant ID and the client ID data that it

gives me over here on the right because

all I have to do in Azure devops if I do

no I can

say well Cloe identity Federation

manual I would give it a name do

test and then it's giving me this is the

issuer so this is the issuer value what

I'd have to put in for the manage

identity this is the subject identifier

I would have to put

in I can then tell it the scope level I

want and this is where I would put in

the details from the managed identity

that client ID value and the tenant ID

that it showed me so I would populate

these values in kind of both the spaces

and now I'm using managed identity

instead of a service principal so I

still get all the benefit that there is

no secret that exists I'm not having to

worry about any of that but hey if I

can't create an app registration I can

use manage identity so there you have it

I mean fundamentally this boils down to

the fact that we don't like Secrets when

we think about for users we like

password list we want to get rid of that

password and use password list

Technologies well the same applies to

everything I want to get rid of Secrets

I have to store I have to worry about

the maintenance of and so instead of

this scenario where we have that secret

when we move to the Federation scenario

there is no secret we're using that open

ID connect Federation capability that

hey I'll get that identity token I can

exchange it once that's validated it's

been signed by the right place we can

specifically give certain pipelines

permission to use certain service

connections I can then give it to entra

it will give me an Access token and then

I get whatever roles I've granted that

service

principal so there's nothing hugely new

here than what we've done in the past

with service connections and Azure

devops it's just now we have this great

option to remove the secret and again we

can do that individual convert existing

ones or we can use the script to bulk

convert if I can't create app

registrations hey I can use manage

identities as well I hope that was

useful till next video take

care