►
Description
This month’s in-depth topic: Access Azure resources from software workload in different environments, no secrets necessary. When applications or services run in environments outside Azure, they need Azure AD application secrets to authenticate to Azure AD and access resources such as Azure and Microsoft Graph. These secrets pose a security risk if they are not stored securely and rotated regularly. Azure AD workload identity federation removes the need for these secrets in selected scenarios. Join this session to learn how you can use this capability to get rid of secrets in your scenario. Presenter Uday Hegde – Architect, Microsoft Identity | @udayxhegde. Recorded February 17, 2022.
Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube (Developer channel) and https://aka.ms/m365pnp/videos (Community channel)
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar
• Join us for the next Microsoft Identity Platform community call on March 17th at 9:00am PT
A
So
welcome
everyone.
My
name
is
day-
and
I
am
an
architect
in
the
microsoft
identity
team
and
the
topic
for
today
is
how
you
can
as
a
developer,
how
you
can
access
azure
ad
protected
resources
from
your
software
workloads
without
using
secrets-
and
this
is
possible
in
a
few
environments
and
we'll
walk
you
through
that,
and
we
call
this
feature:
workload,
identity,
federation.
A
So
the
second
scenario
is
how
to
use
50
when
you
know
again
within
a
kubernetes
cluster,
if
you
want,
or
even
outside
the
kubernetes
cluster,
to
access,
azure
resources
and
then
how
you
can
use
the
same
thing
in
github,
ci,
cd
with
github
actions
and
then,
finally,
if
you're
running
in
google
cloud,
how
you
can
access
azure
from
service
running
in
google
cloud,
so
first,
let's
just
define
workload
identities.
I
think
it
may
be
clear
to
many
of
you,
but
just
so
that
we're
all
on
the
same
page.
A
If
you
look
at
the
identities
in
azure
ad,
I
would
break
them
into
two
distinct
parts.
One
is
the
human
identities
which
we're
all
familiar
with,
which
we
use
every
day,
and
these
are
identities
that
employees
that
you
you
give
to
your
employees,
or
even
your
external
external
users
through
azure,
adb,
to
be
flows
or
even
through
our
b,
to
c
plus
for
your
customers
and
then
there's
a
second
form
of
identity
called.
A
You
know
what
we
would,
what
we
can
call
machine
identities
and
the
machine
identities
have
three
very
distinct
type
of
things
that
are
there.
One
is
devices,
and
these
are
all
handheld
devices
that
you
may
bring
into
your
work,
so
we
provide
policies
such
as
user
plus
and
known
device.
It
may
be
what
you
know:
it
may
be
azure
80
join
device
like
your
surface
laptop
or
it
could
be
an
iphone
which
is
well
managed
to
intune,
so
the
user
plus
device
is
a
flow
that
we
support
for
devices.
A
Iots
are
another
big
trend,
that's
happening,
they're
slowly,
coming
into
the
enterprise
and
there's
a
bunch
of
things
that
our
azure
iot
team
does
and
again
they.
There
are
identities
that
are
granted
to
these
iot
devices,
and
then
there
are
identities
for
software
workloads.
These
are
software
components
that
you
may
be
developing
that
your
developers
may
be
developing
in
your
companies
and
and
these
applications
web
apps
script
containers
sometimes
need
an
identity
to
go
and
access
other
resources,
so
workload,
identities
are
these
form
of
or
when
we
say
workload
identities.
A
We
are
talking
about
the
last
bucket
here,
which
are
identities
required
by
software
workloads
to
access
resources
just
like
users.
These
services
also
need
identities,
and
you
may
be
familiar
with
this
concept
of
service
principles
in
azure
ad
and
there
are
two
kinds
of
workload:
identities
or
service
identities.
Today,
one
is
the
managed
identities
which
is
in
azure.
We
have
this
notion
of
a
managed
identity
where
you
don't
have
to
manage
the
credentials
for
them.
A
So
what
is
the
problem
you
are
trying
to
solve
here?
The
big
problem
that
happens
all
a
lot
of
times
is
that
developers,
you
know
a
lot
of
cases
have
to
manage
secrets
on
their
own,
so
these
are
when
they
cannot
use,
for
example,
in
the
case
of
azure,
ad
and
azure.
If
a
developer
is
running
a
software
workload
in
an
environment
outside
azure,
they
cannot
use
management.
A
So
the
big
problem
that
many
developers
face
is
that
when
they
cannot
use
the
something
like
a
managed
identity
because
they
may
be
running
in
github
and
accessing
azure,
and
so
they
cannot
use
a
managed
identity
there.
They
may
be
running
in
a
kubernetes
cluster,
which
is
not
a
azure
compute
resource
it
may
be,
and
the
kubernetes
cluster
might
be
running
anywhere
in
on-prem.
A
Is
they
expire
and
when
they
expire,
your
service
goes
down
because
the
service
can
no
longer
access
those
azure
resources
or,
if
somebody
walks
away
with
the
secret.
So
if
somebody
gets
access
to
the
secrets
now
they
have
access
to
your
resources
and
that's
also
not
desirable.
So
for
all
of
these
things,
just
like
for
users,
we
are
trying
to
get
to
the
passwordless
world.
A
So
to
make
this
a
little
bit
more
concrete
for
you
I'll,
walk
you
through
a
kubernetes
of
how
this
would
work.
So
imagine
that
this,
like
humanity,
is
clustered
and
there
are
multiple
parts
running
and
these
parts
are
all
running
in
different
name
spaces.
Even
what
kubernetes
has
provided
is
the
ability
for
the
kubernetes
cluster
itself
to
become
a
token
issuer
and
issue
tokens
to
the
workloads
running
on
the
cluster,
and
you
can
also
have
the
kubernetes
cluster
publish
an
oidc
discovery
endpoint,
where
any
any
identity
provider
can
validate
tokens
issued
by
that
cluster.
A
So
I'll
walk
you
through
how
this
works
conceptually
and
then
we'll
look
at
a
few
more
details.
So
first
thing
is
you
set
up
a
cluster
with
oidc
federation
and
trust
on
azure
id
app?
So
every
cluster
you
know
if
you're,
if
you're,
using
a
managed
cluster
such
as
azure
community
service
or
eks
in
amazon
or
gke
in
google,
each
of
the
providers
have
their
own
way
of
how
you
can
make
that
cluster
an
oitc
provider
but
you're
managing
the
cluster
on
your
own
on-prem.
A
So
once
you
go
and
make
the
cluster
and
oic
provider
you
can
go
and
pick
an
azure
id
application
in
in
your
tenant
and
configure
it
to
trust
a
specific
service
account
in
this
cluster.
So
in
this
example
I'll
again
I'll
walk
you
through
every
specific
example,
but
here
I
said
for
this:
azure
ad
application
trust
this
issuer,
which
is
this
cluster,
and
this
particular
subject,
name,
which
is
the
service
account
in
a
namespace
in
a
kubernetes
cluster.
A
What
azure
ad
will
do
at
that
point
is
validate
that
the
token
is
valid.
It
goes
to
the
oidc
discovery
url,
for
that
issuer
and
checks.
Was
this
token
signed
by
that
issuer?
Is
it
still
within
the
time
stamp
that
is
marked
in
that
is
that
makes
it
valid,
and
it
also
checks
the
azure
id
application.
Saying
is
this
particular
issuer
and
subject
trusted
on
this
application?
A
A
So
this
is
the
flow
and-
and
so
you
can
use
this
today-
and
I
have
a
blog
post,
where
it
will
provide
you,
a
detailed
walkthrough
that
you
can
just
go
step
by
step,
but
there
are
really
four
parts,
and
I
have
a
very
quick.
I
will
inspect
a
few
things
in
this
presentation
today,
we'll
inspect
exactly
how
my
cluster
looks
like
and
all
of
that.
So
you
get
an
idea,
but
there
are
really
four
parts
to
get
this
working
into
it.
A
First,
is
the
cluster
administrator
has
to
configure
the
cluster
to
issue
tokens
and
make
it
an
oidc
disk
and
publisher,
oidc
discovery
endpoint,
and
they
do
this
either
by
using
a
tool
provided
by
one
of
the
cluster
managed
clusters
or
whether
for
the
cluster
they're
managing
they
can
pro.
They
can
follow
some
guidance
saying
how
they
can
go
and
do
step
number
one
when
they
do
step
number
one.
A
So
that's
the
flow
that
you'll
see
in
this
blog
post
as
well,
and
I
encourage
you
to
get
it.
You
know
if
you
want
to
try
it
out.
I
encourage
you
to
try
it
out.
What
I'll
do
now
right
now
is
just
walk
you
through
a
few
things
that
we
can
look
at.
So
you
get
it
it's
more
of
a
conceptual
walkthrough.
I
wouldn't
call
it
a
demo
just
because
you
know
we
don't
have.
You
know
a
lot
of
time
here
for
a
demo.
A
A
The
first
thing
is:
what
we'll
do
is
we'll
look
at,
so
we
look
at
this
cluster
that
I've
set
up,
and
if
you
look
at
this
cluster,
it
says
this
behavior
is
modified
by
a
preview,
because
I'm
using
the
preview
to
in
in
azure
community
servers
to
try
this
out
so
you'll
notice
that
one
of
the
things
in
this,
when
I
did
it
is
you
can
show
you'll
notice.
This
particular
part
which
says
oidc
issuer
profile
is
enabled,
and
the
issuer
url
is
this.
A
This
is
the
issuer
url,
so
this
kubernetes
cluster,
I
have
gone
and
gone
through
the
instructions
in
my
blog
post,
as
well
as
in
the
microsoft
documentation
as
to
how
you
can
enable
this
cluster
in
up
using
the
preview
that's
available
in
aks,
and
I
made
this
a
oidc
enabled
cluster
and
that
has
caused
this
to
go
and
publish
a
url
at
that
particular
endpoint,
which
provides
all
the
oidc
discovery
components
to
it
that
allows
azure
ad
to
go
and
validate.
Is
this
a
trusted
issuer
and
and
validate
the
tokens?
A
The
second
thing
we'll
do
is
we'll
look
at
the
azure
id
application
where
I
set
up
this
trust.
So
I'm
in
this
azure
id
portal-
and
if
you
look
at
this
portal,
I
can
now,
if
you
look
at
the
you
know,
and
I'm
on
an
application
in
the
azure
id
portal
called
code
samples,
federated
threats,
and
if
you
look
at
this
application
in
the
certificates
and
secrets,
tab,
you'll
notice
that
this
app
does
not
have
any
secrets.
A
A
This
is
my
namespace,
which
is
my
where
my
pod
is
running,
and
this
is
the
service
account
name
demo.
Sa
is
a
service
account
name
and
that
causes
azure
id
to
automatically
create
this.
The
subject
name
in
this
particular
format,
which
is
how
kubernetes
will
stamp
it
in
their
tokens.
Kubernetes
put
system
service
account
name
space
in
my
case
that
namespace
is
demo
k8
and
then
the
service
account
name
which
is
demo
8
sa.
A
A
So
one
of
the
things
that
the
microsoft
containers
team
has
done
is
published
open
source
components
that
allows
the
configuration
to
be
very
simple
for
a
developer,
because
normally
what
you
have
to
do
is
you
have
to
put
a
bunch
of
environment
variables
and
also
tell
communities
where
to
issue
the
token.
What
is
the
audience
in
the
token
how's
the
launch,
the
lifetime
of
the
token
there's
a
lot
of
configuration
you
have
to
do,
however,
there's
a
mutating
admission
web
hook.
A
A
So
this
is
my
visual
studio,
where
I
have
the
service
account
that
I'm
using
and
what
I
did
was,
I
said,
democate
is
my
namespace.
This
is
the
name
of
my
service
account
and
what
I
also
did
was
I
added
a
bunch
of
annotations
and
labels,
and
this
annotation
said
the
client
id.
This
is
the
id
of
my
application
that
I
just
showed
you.
This
is
a
client
id
that
this
service
account
is
connected
to
this
is
the
tenant
id
that
I'm
connected
to,
and
once
I
did
this
annotation,
what
happens?
A
Is
this
annotations
are
consumed
by
that
mutating
web
hook?
So
once
I
enabled
the
community
service
of
my
cluster
with
oidc,
I
also
ran
a
script
to
run
to
add
the
mutating
web
hook
on
my
cluster.
Again,
if
you
look
at
the
blog
post,
you'll
see
the
specific
steps
to
enable
that
what
happens
is
when
a
port
with
this
service
account
runs
on
that
any
node.
The
mutating
web
hook
automatically
looks
at
this
annotation
and
populates
the
necessary
parameters
required
for
that
port.
A
To
get
the
token,
so,
for
example,
this
is
what
my
deployment
looks
like
for
my
part
and
look
how
simple
this
is.
This
is
just
I
just
said.
This
is
my
image
and
I
just
said
this:
is
you
know
I'm
running
it
in
a
federated
environment?
This
is
all
the
things
I
I
needed.
I
did
not
have
anything
else
here
to
go
and
say:
where
is
the
token
issued
what
other
than
I
said,
I'm
using
this
service
account
now?
A
A
So
all
of
this
was
automatically
injected
by
the
mutating
webhook,
so
you
do
not
have
to
do
it
yourself
now,
of
course,
you
can
choose
not
to
use
a
mutating
web
hook
and
add
all
of
this
yourself,
but
what
the
mutating
webhook
did
was.
It
said
it
used
the
information
I
had
in
my
annotation
and
populated
the
client
id
the
tenant
id.
A
A
You'll
notice
that
it's
got
all
of
these
environment
variables
set
up,
especially
these
things.
These
are
all
configured
by
the
mutating
web
hook,
so
that
you
do
not
have
to
do
any
of
this
yourself
and
then
once
this
is
running
now.
My
code
here
can
then
get
that
token
and
use
that
to
get
access
to
azure
resources.
I'll
just
show
you
a
very
you
know
a
quick
example
of
how
that
even
looks
like
in
my
in
my
setup.
A
In
my
case,
you
are
familiar
with
azure
identity.
I
simply
said
just
go
and
use
the
default
azure
credential
and
that's
all
I
have
to
do
as
a
you
know.
We
have
different
types
of
credentials
for
you
I'll
show.
You
know
the
same.
The
same
code,
I'm
using
to
demonstrate
a
spf
credential,
a
kubernetes
credential,
and
all
of
that.
A
So
I
have
similar
examples
for
how
you
do
for
skippy
credentials,
gcp
credentials.
Those
are
slightly
different,
but
the
simplest
example
I
have
for
you
is
just
use
the
default
azure
credential,
if
you're
familiar
and
as
long
as
you're
and
and
you're
running
in
the
kubernetes
cluster.
All
of
this
works,
but
if
you're
running
in
gcp,
then
you
have
slightly
different
instructions
that
you
can
follow.
A
A
So
the
next
example
I
have
is
and
we'll
go
through
the
rest
more
quickly.
Now
that
we
have
firmly
understood
the
the
model,
the
pattern
remains
the
same.
All
you're
changing
is
what
is
the
trusted
entity?
So
swifty
is
another
piece
of
technology
that
some
customers
choose
to
use.
It
has
some
attractiveness
for
developers
so
we'll
just
go
through
this
flow.
So
in
the
case
of
smithy
you
can
use
the
you
know
slippery.
That
is
a
set
of
specs
for
standardizing.
A
What
kind
of
what
a
workload
identity
would
look
like
in
a
cloud
neutral
world
and
so
in
this
world?
What
you
can
do
is
you
can
stop
spire
is
the
implementation
is
a
reference
implementation
of
spiffing,
so
you
can
set
up
as
fire
server
and
enable
it
to
be.
You
know
to
have
the
oitc
discovery,
url
very
similar
to
what
we
saw
so
far
with
kubernetes.
A
You
can
be
running
the
fire
server
in
your
kubernetes
cluster
itself
or
in
a
different
kubernetes
cluster,
so
that
nice
thing
here
is
you
can
even
have
multiple
clusters
and
all
supported
by
a
single
spire
server,
and
the
model
is
very
similar.
Once
you
have
the
server
set
up,
then
you
can
go
and
say
you
can
have
a
service,
and
you
can
say
that
it
uses
a
workload
api
to
request
a
spiffy
jot
token
from
this
fire
agent.
A
So
in
this
particular
model,
the
same
service
I
ever
had
running
in
the
in
my
pod
would
request
it
for
a
token
for
my
spoofy
identity
that
was
assigned
to
me,
based
on
based
on
certain
characteristics
based
on
worked
out
registration,
it
got
a
identity
and
I
used-
and
I
got
a
job
token
for
that
identity,
and
then
I
exchanged
that
token.
I
sent
that
token
to
azure
ad,
because
I
already
gone
and
configured
my
azure
id
app
now
with
a
new
set
of
the
new
federated
credential.
A
It
says
the
issuer
is
the
spy
server
and
the
subject
name
is
the
spiffy
id
and
then
once
I
did
that
I
can,
when
I
send
that
token
to
azure
id
and
say
I
need
an
access
token
back
azure
edit
checks
again
is
this
goes
to
an
odc
discovery
url
for
the
expire
server
checks
that
the
token
is
valid.
It
also
checks
that
the
azure
id
application
has
the
has
this
trust.
A
It
also
makes
sure
that
the
token
is
within
the
lifetime
and
after
it's
satisfied
with
all
the
checks,
it
comes
back
with
that
access
token
for
spfe,
and
then
you
can
use
that
token
to
access.
Whatever
resources
is
available
to
that
azure
ad
application
and
some
customers
may
choose
to
use
flippy.
Just
you
know
it's
another
option,
the
attractiveness
for
people
it's
50
is,
they
may
be
running
on-prem.
They
may
be
running
in
multiple
places,
so
they
feel
that
there's
a
single
model
that
they
can
apply
to
multiple
things.
A
So,
while
it's
it's
a
little
bit
harder
than
just
turning
on
an
oitc
on
a
kubernetes
cluster,
it
may
meet
the
needs
for
depending
on
what
you're
trying
to
do.
It
also
provides
certificates
so
that
you
can
do
mutual
tls
between
your
services
running
the
parts,
supports
multiple
clusters
and
so
on,
and
from
the
perspective
of
the
workload
id
federation
for
us,
it's
very
similar
to
what
a
kubernetes
cluster
with
an
oitc
discovery.
Url
looks
like
for
us:
it's
left
a
different
format
of
the
spf
identity
and
the
server.
A
A
So
this
points
to
the
sp
server
that
I,
since
I
set
it
up.
I
provided
this
url
to
my
spire
server
and
this
is
the
issuer,
and
then
this
is
the
spp
identity
that
was
assigned
to
my
workload,
and
so
I
configured
the
trust
to
look
like
this
so
again
go
and
you
know,
there's
a
separate
block
for
spiffy
as
to
how
you
can
set
it
up
and
use
it.
If
you
just
want
to
try
it
out.
A
The
third
model
that
we'll
go
through
is
github,
so
github
is
one
of
the
things
that
a
lot
of
developers
use
for
they're.
You
know
setting
up
the
repositories
and
all
of
that
and
then
a
lot
of
devops
and
developer
teams
use
the
github
actions
to
go
and
deploy
once
as
they
take
in
their
code.
The
ci
cd
pipeline
kicks
in
to
go
and
deploy
that
service
into
the
deployment
either
in
azure
or
wherever
it
is
so.
What
happens
in
a
lot
of
cases
is
since
github
is
not,
you
know,
cannot
use
managed
identities.
A
Many
developers
have
to
go
and
create
a
service
principle,
give
it
access
to
their
subscription
and
then
take
the
secret
of
that
service
principle
or
that
app
registration
and
put
it
in
github
in
the
github
repo
as
a
secret,
and
so
a
lot
of
customers
are
worried
that
hey
you
know
what
that
secret.
Now
we
do
not
want
people
to
take
secrets
from
our
tenant
and
put
it
in
outside
resources
like
github,
because
they're
worried
about
you
know
the
security
consequences
of
that.
A
So
in
this
model,
what
we
allow
is
that,
if
you're
running
in
a
github
repo,
you
don't
need
to
have
that
copy
that
secret
from
azure
80
anymore,
and
so
let's
look
at
the
flow
that
happens
here.
So
when
you
go
to
github,
you
can
configure
again,
you
can
go
and
github
has
a
specific
format
for
the
subject.
Name.
Just
like
we
saw
what
was
in
kubernetes.
A
A
Then
you
write
your
actions
in
a
specific
way
that
tells
github
that
you
need
a
token
for
your
actions
workflow.
So
once
you
did,
this
github
starts
giving
you
a
token
and
then
that
token
has
all
the
information
that
you
are
configured
in
the
trust.
So
now
the
next
thing
you
do
is
you
say
you
use
azure
login
action.
Actually,
it's
azure
login
v1
action
support
it.
A
A
So
aws
is
one
place
where
we
are
still
looking
at
how
we
can
enable
this,
because
they
have
a
slightly
different
way,
how
they
issue
tokens
and
all
of
that,
and
so
that's
not
something
that
you
know
today.
What
happens
is
that
oitc
discovery
url
has
to
meet
expectation
that
azure
80
has
on
on
the
format,
so
we'll
keep
testing
other
providers
and
keeping
keep
adding
more
providers
and
more
scenarios
to
this
list.
A
But
these
are
the
things
we
have
tested
so
far
and
you
have
others
that
your
feedback
on,
let
us
know-
and
we
will
we
will
continue
that
journey
so
in
the
google
is.
What
happens
is
again
you
want
to
try.
You
want
to
enable
this
without
needing
secrets
and
in
google.
What
you
can
do
is
when
your
application
is
running
in
the
google
cloud.
You
can
ask
google
to
go
and
give
it
a
token
for
a
service
account
whose
keys
are
managed
by
google.
So
you
don't
need
to
manage
keys
again
in
the
google
cloud.
A
So
first
you
go
and
say
you
go
and
create
a
service
account
and
have
your
application
use
that
service
account
and
then
you
can
go
to
the
google
cloud
and
and
say
hey
what
is
the
identity
of
mine
that
service
account
and
once
you
know
that
you
can
come
to
azure
ad
and
say
on
this
application,
the
issuer
is
account.google.com
and
the
subject
is
whatever
the
you
know.
Google
has
this,
I
think
16
or
20
digit
num,
you
know
numeric
identity
for
a
service
account.
A
So
then,
you
can
go
and
get
a
id
token
from
google
in
your
code
and
then
use
that
and
then
use
our
identity,
sdk
libraries
to
go
and
exchange
that
to
an
azure
id
token.
So
very
similar
format.
You
got
an
google
token
and
then
the
identity
sdks
allowed
you
to
exchange
that
pass
that
token
to
azure
id
as
your
id,
then
checks
is
this.
The
is
this
app
trusted
on
this
particular
token
is
the
and
it
goes
to
the
google's
oidc
discovery.
Url
and
validates.
A
A
B
A
B
A
That's
a
great
question,
so
I
think
that
two
parts
here
one
is:
let's
go
back
to
the
portal
just
so
so
I
can
answer
this
question
properly.
So
if
you
look
at
this
portal,
if
I
go
to
certificates
and
secrets
when
I
do
client
secrets,
when
I
add
a
new
client
certificate,
it's
got
a
certain
expiry
time.
A
It
says
expires
after
six
months,
so
I
can
go
and
do
all
of
this
and
it
and
then
after
six
months,
if
I
did
nothing,
it
expires
and
then
my
and
if
I
have
a
service
running
it
breaks,
and
I
have
to
go
and
reconfigure
that
secret
and
all
of
that
in
this
flow,
this
federated
credential.
It's
not
a
secret
anymore.
There's
no
secret
here,
because
these
are
all
publicly
you
know
these
are
all
public
information.
A
So,
for
example,
this
is
just
an
idc
url.
This
is
a
identity,
so
there
are
no
secrets
here.
So
this
credential,
what
we
call
a
federated
credential,
never
expires.
So
this
is
as
long
as
you
keep
it
it's
there
and
it
never
expires.
However,
what
happens
is
in
the
flow
that
we
saw.
Let's
go
back
to
this
deck
in
the
flow
that
we
saw
here.
The
google
token
has
its
own
expiry
right,
google,
when
it
shows
a
token
they.
A
You
know
you
get
a
token,
probably
for
an
hour
or
so
so
when
you
pass
that
token
to
azure
id,
you
need
to
make
sure
that
you
get
a
token
that
is
reasonably
recent.
Otherwise,
if
you
take
a
token
from
google
and
then
exchange
it
a
few
hours
later,
then
azure
id
will
say
that
token
has
expired,
so
that
token
will
expire.
So
you
need
to
get
in
your
code.
A
You
need
to
get
a
token
at
the
around
the
time
when
you
need
that
and
you
may
need
to
make
that
exchange
and
then,
when
azure
ad
gives
your
token
back.
Even
that
token
has
a
lifetime
and
that
token
lifetime
is
typically
an
r,
but
you
can
configure
that
in
your
tenant,
and
so
let's
call
it
an
r
for
this
purpose
of
the
thing.
So
imagine
that
you
have
a
google
token
and
you
have
been
using
that
and
then,
after
about
an
hour
when
you
support
x5,
you've
got
to
get
an
azure
id
access
token.
A
C
C
You
know,
have
the
apps
only
for
their
bdc
tenants.
So
maybe,
if
you
go
back
to
your
azure
ad
tokens
for
kubernetes
pods,
your
flow,
the
very
the
first
flow
that
you
walked
us
through.
Sorry,
no,
nobody
there
you
go.
I
could
kind
of
cut
to
the
chase
here
so
see
that
step
two.
If
that
azure
active
directory,
is
actually
a
b2c
issued
token
like
step
two
four
three:
why
wouldn't.
A
That
work,
the
reason
it
wouldn't
work
is
because
what
you
know
from
the
azure
ad
side,
we
have
built
the
speech
to
make
sure
that
you
know
we
can
give
proper
guidance
because
we
could,
if
we
go
and
say,
hey,
look,
we
have
just
opened
this
up
and
everything
worked.
Then
you'll
have
no
idea
what
works
right.
Then
you
have
to
do
the
testing,
so
what
you
have
done
is
what
we
have.
A
C
C
A
To
we
have
to
be
careful
here
because
anything
is
possible
and
we
can
instead
of
telling
the
world
anything,
is
possible.
We
want
to
go
and
actually
make
sure
that
we
can
give
proper
guidance
on
how
this
works.
So
we
have
actually
gone
and
looked
at
how
we
can
enable
kubernetes
github
and
all
of
that
and,
like
I
said
even
for
you,
know,
aws,
I
can
imagine
how
it
works,
but
if
you
try
it,
it
won't
work
because
azure
id
has
not
enabled
it
yet
and
the
same
thing.
A
A
C
Yes,
currently,
most
of
the
folks
I
run
across
are
you
know,
managing
secrets
which
we
want
to
get
away
from,
and
they
have
a
separate
cluster,
even
namespace,
really
to
you
know
for
that
customer
facing
application,
and
then
they
have
their
customers
in
their
b2c
tenant.
So
they
just
kind
of
want
to
segregate
everything
over
into
that
area.
C
A
That's
a
good
question.
I
can
tell
you
already
that
you
know
before
you
test
it.
I
can
tell
you
already
that
it
is
not
supported
right
now,
but
but
that's
good
feedback.
Why
don't?
I
do
one
thing
we
will
go
and
you
know
actually
work
with
the
b2c
team
to
make
sure
that
we
can
go
and
validate
this
entrant
and
then
see
how
best
we
can
bring
that
guidance
out
for
you.
C
A
A
A
A
So,
for
example,
some
customers
may
not
want
the
developers
to
randomly
set
any
issuers
as
trusted
and
even
if,
even
though
the
developers
may
own
their
subscription,
so
we
are
looking
at
talking
to
the
it
admins
and
the
security
folks
to
say:
do
you
want
a
list
of
do
you
know
by
default?
We'll
allow
we'll
say
you
know
anybody
is
allowed
to
add
an
issuer
as
long
as
they
have
the
permissions
to
go
and
do
that
which,
inside,
in
a
certain
role
like
the
managed
identity,
contributor
role
or
the
app
admin
role.
A
But
in
addition,
we
want
to
make
sure
that
the
security
administrators
admins
they
can
go
to
a
tenant
and
in
the
tenant
level,
say.
I
only
want
these
issues
to
be
used
in
this
tenant,
and
then
we
can
enforce
policies
of
that
kind
so
that
if
a
developer
wants
to
go
and
configure
something,
they
have
to
go
and
convince
their
id
admin.
As
to
why
they're
secure
because
remember,
we
got
rid
of
secrets
that
a
developer
needs
to
manage
on
their
own,
which
is
a
hard
problem.
A
However,
now,
since
the
identity
provider
itself
is
now
you're
making
the
communities
itself
the
identity
provider,
now,
if
you
don't
manage
the
keys
on
that
identity
provider,
the
signing
keys,
then
that's
also
a
security
risk.
So
as
long
as
you're
using
a
managed
service
like
aks
or
eks
or
gke,
where
the
cloud
providers
are
managing
those
for
you,
then
it's
not
a
big
problem,
because
they
can
rotate
the
secrets
and
all
of
that.
A
So
I
think
those
are
the
places
where
you
may
have
to
convince
your
id
admin
saying
look,
these
are
this
issuer
is
managed
well,
it
is
managed
by
me
in
this
fashion
and
all
of
that,
and
that
may
convince
the
ip
admit
to
go
and
add
that
issuer
into
that
list.
So
we
are
thinking
about
policies
like
that.
So
if
anybody
has
feedback
saying
hey,
I
wish
we
could
do
this.
I
think
we
would
love
to
hear
that,
so
we
are
also
looking
at
how
we
can
make
this
built
into
the
azure
community
services
itself.
A
So
once
we
have
the
managed
entity
support,
we
also
have
this
capability
called
ford
identity,
which
is
a
github
project
which
is
which
is
an
aks
we're
going
to
update
that
to
use
the
azure
ad
workload
and
federation,
because
it's
a
more
native
model
without
having
to
create
custom
resource
definitions
and
all
of
that,
so
the
future
of
aks
you'll
see
this
built
into
cuba,
aks
itself,
so
that
when
you
say
turn
on
federation
and
turn
on
workload
and
entity
federation,
then
the
cluster
is
all
set
up
for
you.
Even
the
mutating
web
hook.
A
Everything
is
set
up
for
you,
so
you
don't
have
to
do
anything
at
all
and
then
you
can
just
run
your.
You
know
go
through
the
rest
of
the
flow
without
having
to
do
all
the
setup
that
I
that
I
walked
you
through
and
then.
Finally,
we
want
to
make
this
whole
federation
right
now.
It's
in
public
preview
for
azure
id
apps
manage
identities,
we're
still
working
on
it.
We
our
goal,
is
to
make
all
of
that
generally
available
so
that
you
can
put
this
in
production.
A
So
that's
mainly
what
I
had
for
today.
Thank
you
so
much
for
joining,
and
hopefully
this
was
interesting
to
you
and
as
I
mentioned,
if
you
have
any
feedback,
if
you
have
any
scenarios
that
I'm
not
covered
like
what
I
heard
about
azure
adb2c,
please
feel
free
to
jump
past
questions
right
now
or
even
feel
free
to
give
us
the
feedback
later
on.
Through
stephen.
A
That's
a
great
question,
so
there
are
two
ways
I'll
answer
this
question
for
you.
One
is,
since
that
token
is
valid,
so
once
you
get
it
so,
in
order
for
you
to
get
a
token
from
azure
ad
kubernetes
will
issue
a
token
to
you,
but
in
order
for
you
to
get
a
token
from
azure
ap,
you
need
to
be
connected
to
the
internet.
A
So
the
important
thing
to
understand
is
what
are
you
going
to
do
with
the
token
and
if
you're
trying
to
use
a
token
to
access
other
cloud
resources,
then
you
will
run
into
problems
if
you
don't
have
internet
connectivity.
So
that's
the
simple
answer,
but
here's
what
one
of
the
things
that
we
are
also
looking
at.
A
Imagine
that
internet
connectivity
is
not
the
problem,
but
imagine
that
regional
connectivity
is
a
problem,
for
example
you're
running
in
this
region
and
that
region
may
sometimes
lose
connectivity
to
the
rest.
You
know
that
if
that
has
connectivity
issues,
what
we're
looking
at
is
how
can
we
make
azure
adm
more
regionally
available,
so
you
don't
always
have
to
go
to
a
central
resource
like
azure
directory
and
get
that
get
these
tokens.
So
in
that
model,
what
happens
is
you
may
be
running
in
an
azure
region
somewhere?
A
Your
azure
storage
is
in
that
region
and,
let's
assume
that
region
for
some
reason
got
disconnected
from
the
other
regions.
Your
app
will
still
run
as
long
as
you
have.
You
know
that
you're
able
to
be
within
the
region,
you
can
access
the
azure
storage
within
the
region.
Your
kubernetes
cluster
will
get
a
token
from
that
regional.
What
we
call
sts
that
azure
regional,
azure,
ap
and
everything
will
work
within
that
environment.