Azure DevOps Workload Identity Federation with Azure Overview. NO MORE SECRETS!
Summary
TLDRThis 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
👨🏫 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.
🔑 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.
🔄 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.
🛠️ 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.
🎯 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.
Mindmap
Keywords
💡Workload Identity Federation
💡OpenID Connect
💡Service Connection
💡App Registration
💡Managed Identity
💡Federation
💡Identity Token
💡Access Token
💡Well-Known Configuration
💡Role-Based Access Control (RBAC)
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
تصفح المزيد من مقاطع الفيديو ذات الصلة
Functionality and Usage of Key Vault - AZ-900 Certification Course
API Authentication with OAuth using Azure AD
Understanding Resource Specific Consent for Microsoft Graph and SharePoint Online
An Illustrated Guide to OAuth and OpenID Connect
Upgrading SharePoint apps from Azure Access Control service to Azure Active Directory
Managing access for Cymbal Superstore’s cloud solutions
5.0 / 5 (0 votes)