►
From YouTube: Advancements in Kubernetes Workload Identity for Azure
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee,
but
please
add
all
of
your
comments
and
questions
to
the
chat
box
on
the
right
hand,
side
and
we
will
get
to
as
many
questions
as
we
can
at
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
A
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs.
Page
community.cncf.io
under
online
programs
they're
also
available
via
your
registration
link
and
the
recording
will
be
on
our
online
programs
youtube
playlist
on
on
youtube.
With
that
I'll
hand
it
to
anish
and
ernest
to
kick
off
today's
presentation.
B
C
Hey,
I'm
manish,
I'm
part
of
the
same
team,
so
we're
part
of
azure
container
compute,
tab
security
team,
and
then
we
maintain
a
couple
of
open
source
security
projects.
I
think
some
of
them
that
you've
heard
is
azure
workload,
entity
secret,
store,
csi
driver
and
kubernetes
kms.
B
So
yeah
in
today's
presentation,
we're
gonna
touch
on
our
projects,
a
depauw
identity
and
workload,
identity
and
we're
going
to
talk
about
pros
and
cons
for
each
project
and
initially
just
going
to
do
a
quick
demo
on
workload,
identity
and
last
but
not
least,
I'll
also
talk
about
the
road
maps
and
some
resource
that
folks
can
check
out
after
the
presentation
to
learn
more
about
the
projects.
B
B
B
You
can
think
of
manage
identity
as
a
surface
principle,
but
without
the
client
secrets.
This
is
beneficial
because
users
don't
have
to
be
concerned
about
leaking
the
client
secrets,
because
there's
no
more
client
secrets
and
the
users
don't
have
to
manually
rotate
the
client
secrets
anymore
and
yeah.
Let's
apply
these
concepts
to
kubernetes,
let's
say
you're
kubernetes
developers
and
on
azure
and
your
kubernetes
applications
wants
to
access
some
azure
cloud
resource,
for
example,
fetching
a
secret
from
azure,
key
vault
or
downloading
of
files
from
azure
storage.
B
However,
as
I
mentioned
earlier,
you
can
you
can
only
attach
manage
identity
on
the
vm
level
or
or
your
kubernetes
cluster
level,
and
once
you
assign
the
manage
identity
to
your
clusters,
all
the
applications
within
the
clusters
will
have
the
same
access
to
the
same
set
of
azure
resource,
which
is
not
very
ideal.
In
some
situations
you
might
want
to
restrict
a
particular
application
to
only
be
able
to
fetch
secrets
from
a
key
vault,
but
not
be
able
to
access
some
unauthorized
resource.
B
So
this
is
where
adp
identity
comes
in.
Not
only
does
it
help
developers
assigned
managed
identities
to
individuals,
kubernetes
notes
using
the
concepts
of
kubernetes
crds,
but
it
also
acts
as
a
gatekeeper
to
make
sure
that
our
kubernetes
applications
are
using
the
correct,
managed
identity
that
they're
supposed
to
use.
B
B
Finally,
the
developers
will
create
their
pods
with
that
particular
label
defined
in
our
binding
crds,
and
once
the
pot
is
created,
a
depo
identity
will
assign
the
manage
identity
defined
in
azure
identity,
crds
to
where
the
pod
is
scheduled,
and
once
the
assignment
is
complete,
the
pod
can
start
accessing
azure
resource
with
azure
sdk
and
under
the
hood.
Azure
sdk
will
fetch
and
access
token
from
our
instant
metadata
service
or
imds,
and
that
piece
of
traffic
is
intercept
by
aadpod
identity
and
we'll
make
sure
that
the
token
request
is
valid.
B
B
Imds
will
return
the
token
back
to
the
pod
and
the
pod
can
access
whatever
azure
resource
they're
supposed
to
access,
and
with
this
model
it
was
fine,
but
we
do
have
some
limitations
that
prevent
us
from
scaling
further
first
identity
assignments
operations
generally
takes
around
10
to
40
seconds
to
complete,
so
that
means
applications
won't
be
able
to
access
azure
resource
for
around
40
seconds
if
the
identity
is
not
previously
assigned
to
the
underlying
azure
node.
B
Next,
it
only
supports
the
linux
workload
and,
with
the
increase
in
developers
running
containerized
windows,
workload
on
azure,
we
tried
to
prototype
pod
identity
for
windows,
but
we
didn't
have
any
luck
with
it
and
last
but
not
least,
over
the
past
years
we
have
encountered
some
imds
caching
issues
which
causes
some
of
some
of
our
users
to
not
be
able
to
fetch
tokens
in
their
applications
and
with
that
being
said,
azure
workload
identity.
The
next
generations
of
aed
pod
identity
will
address
all
of
these
concerns
that
I
just
mentioned.
B
It
doesn't
require
identity
assignment
operations,
it's
cloud
agnostic,
meaning
this
solutions
will
work
in
any
clouds
and
any
environments,
including
your
local
environment,
and
it
also
works
on
your
windows
workload
out
of
the
box,
and
it
doesn't
rely
on
imds
to
fetch
access
token.
B
B
So
how
do
we
turn
our
kubernetes
clusters
into
an
identity
providers?
Well,
the
concept
of
identity
in
kubernetes
is
not
anything
new.
In
kubernetes,
a
surface
account
represents
a
identity
that
workload
can
use.
Kubernetes
administrators
can
set
our
back
rules
to
against
the
surface
accounts
to
control
what
their
workload
can
access
within
the
clusters.
B
The
job
of
the
mutating
web
hook
is
to
intercept
any
workload,
admissions
requests
from
the
users
and
project
the
surface,
account
token
to
our
containerized
workload
file
system
and
it
also
inject
several
environment
variables
as
well,
and
by
having
a
mutating
web
hook,
users
don't
have
to
manually
change
their
workload
to
manifest
to
support
this
new
authentication
flow.
So,
let's
look
at
how
we
glue
these
three
main
components
together.
B
The
webhook
will
intercept
the
admission
request
that
wants
to
use
the
workload
identity
project
and
it
will
automatically
project
the
surface
account
token
to
the
file
system,
as
well
as
a
couple
of
environment
variables,
and
our
workload
can
now
leverage
our
latest
and
greatest
azure
sdk
to
access
our
azure
resource.
The
benefits
of
using
azure
sdk
is
that
it
helps
abstract
the
token
exchange
steps
and
under
the
hood,
azure
sdk
will
read
the
environment
variables
and
the
projected
surface
account
token
in
our
file
system
and
pass
those
parameters
to
azure
active
directory.
B
Aad
will
then
verify
the
authenticity
of
the
tokens
and,
if
it
is
valid,
aad
will
return
an
access
token
back
to
our
azure
sdk
and
with
a
valid
access
token.
We
can
now
access
any
resource
in
a
cloud
and
yeah.
As
you
can
see,
we're
now
able
to
eliminate
everything
we
mentioned
a
couple
slides
ago.
Users
don't
have
to
wait
40
seconds
for
the
identity
assignment
operations,
and
this
solution
is
cloud
and
os
agnostics,
so
it
works
in
any
environment.
B
C
Thank
you.
Ernest
okay,
so
we've
been
working
on
azure
workload,
identity
for
a
while
now
and
we're
really
excited
to
have
this
finally
available
for
our
users
to
try
out.
This
is
based
on
the
new
workload
identity
federation,
which
is
currently
under
preview.
C
So
as
part
of
this
demo,
what
we're
going
to
see
is
we're
going
to
see
workload,
identity
in
action
with
azure
ad
applications,
I'm
a
fan
of
live
demos,
but
just
for
this
purpose
of
the
live
webinar,
what
I've
done
is
I've
done
a
recording.
So
what
we're
going
to
do
is
run
through
the
recording
and
then
I
will
talk
through
what
is
going
on.
So
as
part
of
this
demo,
what
I've
done
is
I've
created
a
aks
cluster
with
this
new
flag
called
enable
oidc
issuer.
C
So
this
is
a
one
node
aks
cluster
and
it
is
running
kubernetes
version
v122
and
I've
already
enabled
the
odc
issuer
on
this
cluster.
So
this
oidc
issuer
feature
is
currently
in
preview.
On
aks,
when
you
create
a
new
cluster
or
update
an
existing
cluster
with
enable
oidc
issuer
flag,
an
issuer
url
will
be
set
up
for
your
cluster.
C
C
So
this
is
what
my
oidc
issuer
url
looks
like
right
and
then
the
issuer
url
is
actually
part
of
the
aks
cluster
properties.
So
that
means
you
can
query
it
with
azak's
show
command.
So
when
we
do
azak
show
here
we
can
see.
This
is
my
cluster
issuer,
which
has
the
ftdn
and
basically
a
unique
cluster
id
for
each
cluster.
C
So
what
exactly
is
on
this
issuer
url?
So
there
are
two
things
right.
The
first
thing
is
the
oidc
discovery
document.
C
This
is
the
standard
discovery
document
which
has
the
issuer
url,
and
then
it
also
has
the
json
web
key
set
uri
the
url,
where
the
public
signing
keys
are
available,
and
apart
from
that,
a
couple
of
other
fields
which
is
required
for
by
the
oidc
spec
and
then
now,
when
we
try
to
query
the
jwks,
the
json
web
key
set,
we
can
see
that
this
has
the
public
signing
keys,
that's
used
by
the
cluster,
so
the
private
signing
keys
are
available
in
the
cluster.
C
C
So
the
next
thing
that
we're
going
to
do
in
this
cluster
is
we're
going
to
deploy
the
mutating
web
hook
that
we
talked
about.
It
simplifies
config
for
the
deployments
for
the
purpose
of
this
demo.
What
I've
done
is
I've
installed
the
mutating
web
hook
using
help
charge
from
our
open
source
repo,
but
when
this
is
natively
integrated
in.
B
C
C
C
C
This
means
you
can
use
the
same
pod
spec,
that
you're
using
in
different
cloud
providers,
and
you
can
just
deploy
that
in
azure,
without
making
any
native
making
any
changes
specifically
to
run
work,
product
manager,
workload,
identity
is
based
on
projected
service
account
that
we
talked
about.
How
is
this
different
from
default?
Service
accounts
so
projected
service
account.
C
C
C
This
password
gets
created
by
default,
but
this
at
least
for
workload
identity
is
never
used,
so
you
can
actually
get
into
the
portal
manage
the
app
registration
and
delete
the
password,
because
this
client
secret
is
never
used
anywhere
with
workload
identity.
C
The
next
thing
that
we're
going
to
do
for
the
demo
is
we're
going
to
create
a
namespace
within
the
cluster,
so
we're
going
to
call
it
wi
demo
app
and
the
main
part
now
that
we
need
is
to
create
the
annotated
service
account.
So
in
this
service
account
annotations,
we
are
using
the
client
id
of
the
azure
ad
application
that
we
created
in
the
previous
step
and
then
in
the
labels.
We
have
azure
workload
entity
use
true.
C
C
The
next
thing
that
we're
going
to
do
is
we
talked
about
federated
identity
credential.
So
we
need
to
establish
a
trust
between
the
azure
ad
application
that
we
created
in
the
first
step,
and
then
the
service
account
issuer
and
the
subject
so
we're
going
to
tie
all
of
it
together
and
say:
hey
trust,
this
token
that
I
send,
which
has
all
of
this.
So
there
are
a
couple
of
ways
to
add
this
federated
int
credential.
C
You
can
do
it
with
ac
rest,
there's
also
support
for
it
coming
soon
with
azure
cli
and
there's
also
support
for
doing
this
with
ui.
So
for
this
demo,
what
we're
going
to
do
is
we're
going
to
do
it
with
ui.
C
C
So
when
you
click
on
that
and
say,
add
credential,
I
you
can
pick
which
scenario
you're
using
this
federated
credential
for
so
this
works
with
github
actions
which
is
being
deployed
and
that
needs
to
access
azure
resources.
Kubernetes
this
particular
scenario:
we
are
using
kubernetes,
so
here
the
first
thing
we
do
is
we
add
the
cluster
issuer
url,
which
is
the
issuer
url.
C
We
saw
for
the
cluster
that
I'm
that
I
have
the
namespace
here
is
the
name
space
where
the
workload
is
going
to
be
deployed
and
the
service
account
is
and
then
the
service
account
name
is
the
service
account
that's
going
to
be
used
by
the
pod
and
then,
as
you
can
see,
when
you
populate
the
namespace
and
the
service
account
name,
the
subject.
Identifier
gets
auto-generated.
C
The
audience
field,
as
you
can
see,
is
a
standard
field
that
we're
using
for
all
kubernetes
workload.
So
this
is
not
something
that
has
to
be
explicitly
configured
by
the
user,
but
if
you
need
to
override
that,
then
you
could
do
that
as
well.
C
So
we're
going
to
create
the
federated
entity
credential.
So
what
this
means
is
now
there
has
been
a
trust
that
has
been
established
between
your
azure
ad
app
and
service
account.
The
next
thing
we're
going
to
do
is
we're
going
to
create
a
workload
pod
which
references
the
service
account
so
just
to
show
how
simple
it
is
to
deploy
an
application.
What
we're
doing
here
is
we're
just
using
our
cube,
tpl
run
command
and
then,
if
you
as
you,
can
see
we're
using
the
azure
cli
image
in
the
service
account,
we
are
referencing.
C
So
now
that
the
port
is
created,
the
next
thing
that
we're
going
to
see
is,
let's
see
what
has
been
injected
into
this
pod.
So
these
are
the
environment
variables
that
we
talked
about.
So
there
are
four
environment
variables.
The
azure
authorities
host
is
the
endpoint
where
we
need
to
fetch
a
token
from
the
client
id
is
you
got
is
from
the
client
id
annotation
in
the
service
account.
C
Next,
let's
see
what
other
changes
the
mutating
webhook
made
and
the
on
the
pod
that
was
deployed
so
the
first
set
of
changes
is
the
new
environment
variables
that
we
looked
at.
That
was
added
by
the
mutating
webhook
and
then
the
next
thing
is
the
projected
service
account
token.
C
So
it's
called
azure
identity
token
and
it's
a
projected
service
account
token
volume
and
we
are
defaulting
to
the
audience
that
we're
using
as
standard
across
kubernetes
workloads
and
the
expiration
seconds
is
set
to
the
lowest
possible
value
so
that
that
cubelet
will
renew
the
token
at
80
of
expiry.
C
Then
the
next
thing
that
we're
going
to
do
is
try
to
get
an
access
token,
with
the
federated
token
that's
available
in
the
month,
so
we
are
executing
into
the
pod
and
then
the
first
thing
we
are
going
to
do
is
we
are
doing
an
easy
login.
So,
as
you
can
see
here,
we
are
using
all
the
environment
variables
that
have
been
injected
from
using
the
webhook.
C
So
there
is
no
specific
value
that
I'm
hardcoding
here
and
then
there
is
this
new
federated
token
flag
in
easy
login,
where
you
can
actually
pass
the
federated
token,
which
is
the
projected
service
account
token.
So
when
we
do
ac
login
now
using
all
the
values
that
have
been
injected
with
web
book,
we
can
see
that
we
are
able
to
successfully
login
and
when
we
run
az
account
get
access
token.
So
now
this
is
where
we
can
confirm
that
we
were
able
to
exchange
a
kubernetes
service.
Account
token
for
a
valid
aed
token.
C
Okay,
so
now
that
we've
looked
at
the
demo
and
then
we've
also
understood
the
changes
that
we've
made
in
work,
azure
workload
entity,
it's
very
simple
in
terms
of
configuration-
and
then
it
also
gets
rid
of
all
these
limitations
that
we
had
in
port
identity.
C
So
just
to
have
this
integrated
in
more
and
more
solutions,
because
it's
zero
trust
and
then
it
doesn't
require
a
client
secret.
We've
been
working
on
integrating
workflow
identity
with
some
of
the
projects
maintained
by
our
team
and
our
sister
teams.
So
the
first
one
is
a
first
integration
is
with
azure
keyword
provider
for
secret
storage,
csi
driver.
C
C
The
secret
store,
csi
driver
is
a
cigarette
sub
project
which
supports
multiple
providers
today
and
azure
keyword
is
one
of
them,
so
we
have
workload
identity
integrated
with
that,
which
means
you
can
fetch
secrets
from
keyword
without
any
kind
of
secrets
that
we
talked
about,
and
then
the
second
one
is
ratify,
so
ratify
enables
validation
of
supply
chain
artifacts
such
as
image
signatures
and
s-bonds,
so
ratify
recently
added
support
for
workload
entity
federation
using.
C
And
then,
in
terms
of
the
road
map
where
we
are
with
azure
workload
entity
today,
so
we
did
the
open
source
project
launch
which
was
done
in
jam.
This
is
for
the
mutating
web
hook
and
also
based
on
our
experience
from
pod
identity,
something
that
we
learned
was.
We
want
to
help
our
users
by
automating
some
of
the
operations.
So
for
this
purpose
we
also
developed
a
new
cli
tool
called
azure
workload,
entity
cli,
so
we
launched
all
of
this
in
jam.
C
C
C
So
what
we
have
in
plans
next
is:
we
are
working
with
aad
on
workload,
identity,
federation
with
managed
identity.
We
know
most
of
our
users
today
use
managed
identities,
both
identity,
so
we
know
that
it's
critical,
and
that
is
what
we
are
working
towards
right
now.
We
are
testing
and
we
are
hoping
to
have
something
available
soon
for
users
to
try
out
once
we
have
managed
identity.
This
would
be
feature
complete
with
what
pod
identity
supports
today.
C
So
the
next
stage
would
be
to
have
a
public
preview
on
aks
as
a
managed
add-on
for
workload
entity
and
based
on
the
feedback
on
public
preview
and
other
consumption.
The
next
thing
we
would
do
is
we
would
eventually
move
the
project
to
ga.
B
Thanks
anish,
what
a
great
demo
and
that
concludes
our
presentations
and
here
is
a
quick
list
of
resources
that
you
can
check
out.
That
includes
our
documentation's
website
for
pod
identity,
as
well
as
workload
identity,
and
there
is
also
one
url
that
you
might
be
interested
in
checking
out,
which
is
the
federation
with
azure
ad.
This
basically
explained
in
detail
the
architectures
of
federated
identity
credentials,
which
is
what
oracle
identity
is
based
on
and
yeah,
and
that's
all
we
have
thank
you.
A
Okay,
if
anyone
has
questions
go
ahead
and
pop
them
in
the
chat
daniel,
we
will
have
the
presentation
attached
to
the
webinar
recording.
So
if
anish
and
ernest
can
just
send
that
to
me
this
final
version
as
soon
as
we're
done,
I
will
make
sure
that's
attached
when
you
click
your
registration
link.
A
C
Yeah
I
mean
in
terms
of
ga
we
are
working
towards
getting
managed
identity
support
out
in
public
preview.
So
once
that's
available,
the
workload
entity
federation
with
azure
ad
apps
might
go
into
ga,
but
I
think
hopefully
we're
targeting
end
of
this
year
to
have
something.
But
if
you,
if
you
need
concrete
timelines,
then
we
can
follow
up
with
you
again
on
github
issues
or
maybe
some
internal
threads.
C
And
then,
if
there
are
any
other
feature,
requests
or
anything
that
you
would
like
to
see
in
addition
to
what
we
support
today
with
workload
entity
federation,
that
makes
it
easier
to
be
able
to
use
it
with
your
workloads.
Please
feel
free
to
open
a
github
issue.
Add
what
you
need,
then
we
can
follow
up
with
aad
and
see
if
this
is
something
that
we
can
prioritize.
A
If
anyone
else
has
any
questions,
I
think
you
know
where
to
hit
them
up
and
if
y'all
could
send
me
that
deck,
then
I
will
make
sure
everything
is
posted
online
later
this
afternoon
and
thanks
again,
everyone
and
join
us
next
week
for
another
live
webinar
and
we
can
go
a
little
early
today,
thanks
again.