►
From YouTube: Keynote: Cloud & Cloud Native Identity and Access Management: Challenges & Opportunities
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Keynote: Cloud & Cloud Native Identity and Access Management: Challenges & Opportunities - Aradhna Chetal, TIAA; Greg Blana, Consultant; Nathanael Coffing & Craig Thomas, Leader C2 Labs
With the adoption of Cloud & Cloud Native technologies and workloads becoming more distributed, the challenge still remains in achieving zero trust. Organizations struggle to enforce rules and policies within today’s complex and heterogeneous multi-cloud hybrid IT environments. Gartner predicts that by 2023, 75% of cloud security failures will result from inadequate management of identities, access, and privileges. Externalizing access decisions/policies from application code, consistently enforcing access policies, leveraging attributes in the access decision making enables fine-grain authorization decisions and provides greater control over data security. In this session, we will discuss different challenges and solutions for Identity and access management in hybrid cloud native environments to achieve continuous identity assurance.
A
A
A
B
D
D
A
B
B
You
know
various
networks
and
shared
ident,
no
shared
identities
across
those
networks,
and
it
seems
like
a
million
passwords.
You
know
still
largely
focused
on
the
user
rather
than
processes
and
services
and
and
rely
on
the
user
in
this
password.
That
continues
to
be
social
engineer,
continues
to
be
least
common
denominator
from
for.
A
B
Across
these
various
systems,
so
you
often
get
this.
You
know
we
made
a
change
wait
until
tomorrow
and
try
it
again
or
wait
until
that
runs
at
the
end
of
the
week
versus
real
time.
Go
you
know
and
get
logged
in
or
get
the
additional
permissions
that
they
need
and
then
we've
got.
You
know
this
lack
of
skills
in
iam,
especially.
B
Ever
changes,
you
know
this
skill
gap
that
we
see
and
dealing
with
certificates
today,
still
very
manual.
You
know
separate
monitoring
if
they're
good.
We
continue
to
see,
even
in
microsoft
and
others,
these
certificates,
that
expire
and
cause
problems
across
the
board
and
now
with
regulations
and
other
things,
hspd
12
give
cards.
Smart
cards
tokens,
yuba
keys,
adaptive
off,
I
guess
it's
just
kind
of
all
over
the
board
and
organizations
continue
to
struggle
with
that,
both
from
an
end
user
perspective,
as
well
as
from
kind
of
an
I.t
administration
perspective.
B
Also
im's,
not
a
core
part
of
the
project
planning
right,
and
so
we
have
cyber,
has
gotten
better
at
being
baked
in
and
network
architects
are
baked
in,
but
having
this
iam
as
part
of
this,
this
project
planning-
and
this
I
am
board
of
hey.
If
you're
going
to
bring
on
a
new
project
or
a
new
system,
it
has
to
support
this
identity
structure,
lack
of
modern
enforcement
points.
As
we
look
across
containers
and
other
things,
you
know,
how
do
we
enforce
identities?
B
B
C
C
Absolutely
you
know
what
what
we've
really
seen
over
the
last
you
know
four
or
five
years
with
the
advent
of
distributed
services.
Microservices
kubernetes
right
is
the
the
need
for
a
workload
identity
and
that's
really.
Where
spiffy
arises,
you
know
generating
that
common
identity
framework.
You
know
for
everyone,
it's
really
what
the
definition
of
spiffy
is
right
and
you
know,
and
the
beauty
of
that
is
now
we
have
what
we
think
of
as
service
identity.
C
How
data
is
flowing
in
between
those
three
disparate
entities
right
being
able
to
authenticate
them
strongly
being
able
to
pass
that
authentication
on
and
then
being
able
to
authorize
exactly
what
is
being
passed
down
to
them?
And
that's
really
what
we're
seeing
kind
of
emerge,
particularly
in
that
hybrid
and
multi-cloud
world,
is
we've
got
developers
building
the
net
new
and
we've
got
kind
of
a
lot
of
the
the
legacy
more
traditional
items.
You
know
that
might
still
be
on
prem,
or
at
least
a
bit
or
maybe
have
been
re-platformed
into
your
cloud.
C
A
Thank
you
very
much,
so
I
have
a
follow-up
question,
but
still
there
are
traditional
identity
and
access
management
on
on-premise
for
enterprises
and
this
disparate
identities
and
management
systems.
They
still
cause
a
lot
of
integration
issues.
So
do
you
have
any
ideas
as
to
how
we'll
mesh
them
together.
C
Yeah,
so
what
we've
seen
in
2012
2013
right
is:
we
saw
the
advent
of
oauth
and
oitc,
and
what
that
was
designed
to
do
is
separate
apart,
your
user
authentication
away
from
your
service
identity
and
your
service
authorization
right
literally.
It's
oauth
is
designed
for
delegated
authorization
and
so
by
by
decoupling,
those
right
now
you're
able
to
continue
to
use
your
existing
idps,
use
a
standard
based
way
of
federating
them,
whether
that's
oidc
or
whether
it's
something
like
saml
now
aggregate
all
of
that
as
identity
context.
C
Right
and
then
you
start
sharing
that
identity
context
into
what
you
can
almost
think
of
as
your
service
idp,
which
is
a
combination
of
oauth,
client
ids,
as
well
as
obviously
spiffy
identifiers
being
able
to
correlate
those
and
now
you've
got
a
very
secure
way
of
authenticating
your
user,
and
that
could
be
mfa.
It
could
be
adaptive
authentication,
it
could
be
even
legacy
user
id
password
and
carrying
that
over
into
your
service
identities,
which
now
also
have
their
own
strong,
authentications
again
using
things
like
oauth
client
identities
or
using
spiffy.
A
Thank
you,
nathan.
Well,
my
next
question
greg.
I
want
to
talk
to
you
a
little
bit
about
claims
of
air
and
externalizing
claims
of
their
applications
and
externalizing
access
decisions
out
of
the
application,
and
this
has
been
a
concept
that
has
been
discussed
in
the
industry
quite
a
bit,
but
I
haven't
seen
a
whole
lot
of
progress
made
in
this
space.
So
do
you
want
to
shed
some
light
on
this?
Please.
D
D
I
think
I
just
saw
a
very
recent
release
of
osp
top
10
for
web
app
authentication
or
web
applications
and
authentication
broken
authentication
went
to
the
top,
so
it's
definitely
a
problem.
I
also
think
that,
as
we
see
I'm
an
optimist,
I
think
we're
going
to
see
gains
in
our
ability
to
protect
ourselves
with
zta
technologies.
That
sort
of
thing
it's
going
to
become
more
and
more
enticing.
To
go
for
that
low
hanging
fruit,
we're
going
to
go
to
the
front
door
and
knock
on
it
and
say
hey.
D
D
In
this
sort
of
scenario,
maybe
I
would
look
at
the
industry
and
say:
okay,
I'd
like
to
point
my
fingers
at
the
standards
bodies,
they're
not
giving
us
answers,
but
I
think
you
know
we
all
here
are
aware
that
nist
has
been
giving
us
answers
for
getting
close
to
20
years
now
and
and
they've
been
evolving.
Those
answers
quite
well
as
security
technologies
evolve,
and
so
I
can't
really
blame
the
lack
of
answers.
D
I
could
look
at
vendors
and
say:
they're,
not
they're,
not
giving
us
the
solutions
they
are.
We
had
our
first
go
around.
You
know
with
exact
mole.
I
think
there
were
concerns
there
about
performance,
etc,
but
as
we
move
into
cloud
native
the
opportunities
to
sidecar
some
of
these
capabilities,
I
think
eliminates
that
concern,
and
so
you
know
what's
the
problem.
Why
are
we
still
moving
rapidly
towards
a
a
dark
picture
around
access
control?
We
we
just
need
to
have.
D
We
need
to
be
able
to
go
out
and
do
a
quick
scan
on
the
internet
or
talk
to
someone
who
maybe
just
got
out
of
school
and
not
get
three
or
four
or
five
answers
as
to
how
we
should
be
stepping
up
our
access
control
scenario.
We
should
all
be
speaking
from
the
same
playbook
and
I
think
until
that
happens,
we're
going
to
continue
to
see
this
problem
get
worse.
A
But
at
the
same
time,
externalizing
access
from
applications
in
traditional
applications
is
a
hard
problem.
It
requires
investments,
it
requires
development,
work,
green
field
applications.
I
agree
that
it's
easier
to
implement,
but
why
have
we
not
seen
a
migration
in
this
direction
and
nathan?
Could
you
shed
some
light
on
this
as
to
whether
it
is
being
adopted?
I
I
haven't
seen
much
success
with
this.
C
Yeah
well
so
there's
a
couple
things
there
right.
So
it's
a
multi-part
question,
so
it
is
being
adopted
by
forward-looking
organizations.
But
it's
it's
it's
few
and
far
between
to
your
point
now
you
know,
I
think,
what's
happening
is
you
know,
we've
been
kind
of
caught
in
between
you
know
a
rock
and
a
hard
place
or
our
legacy
equipment
and
what
our
developers
are
building
today
and
there
hasn't
been
a
good
bridge
built
right.
C
So
you
know
if
we,
if
I
go
and
talk
to
a
traditional
iam
person
right
he's
still
worried
about
how
do
I
add
iag
to
sap
right,
try
trying
to
think
of
kind
of
a
an
older
application
right.
How
am
I
going
to
do
role
management?
All
these
things
and
those
are
those
are
defined
and
known
problems
that
have
existed
for
you
know
last
decade
and
a
half
and
they
really
have
no
idea
right.
C
What's
going
on
in
the
developer
landscape
today,
meaning,
if
you
know
if
the
typical
identity
person
went
and
looked
and
said:
oh,
my
goodness,
you
guys
are
rolling
out
apis
that
have
no
concept
of
user
identity
that
are
leaking
data
and
all
these
other
things
have
no
real
authorization
built
in
much
less
externalized
authorization
built
in.
They
would
pull
their
hair
out
right
and
that's
why
we
see
you
know
development
slowed
down
so
often
by
security,
because
there
hasn't
been
a
good
model
built
for
how
to
pull
kind
of
these
two
very
disparate
worlds.
C
Together,
it's
not!
I
can
re-platform
in
the
cloud.
It's
literally,
I
have
to
rethink
how
I'm
going
to
address
identity,
a
user
identity
start
incorporating
service
identity
and
building
a
robust,
externalized
authorization
to
connect
with
those
with
those
different
pieces.
Look
like,
and
it's
only
been
you
know
in
the
last
couple
of
years
that
we've
started
to
see
this
start
to
emerge
in
the
industry.
There's
been
some
standards
out
there.
You
know
oidc
oppa.
C
Well,
I
hope
it's
not
standard,
but
cncf
incubator
project
right
and
spiffy
that
can
be
used
to
interconnect
kind
of
these
three
big
or
these
different
disparate
pillars.
However,
right
it's,
it's,
the
technology
is
not
quite
there
yet
and
we
need
much
more
automation.
I
mean
we're
working
with
customers
now
that
you
have
tens
of
thousands
of
containers
and
each
of
those
containers
ends
up
having
its
own
unique
identity
right.
C
That
now
also
needs
to
be
able
to
corroborate
and
authenticate
the
user
identity
or
the
requester
identity
or
the
service
identities
coming
in
from
other
sas
or
other
partners
right.
So
it
builds
a
fairly
complex
landscape
in
exactly
what's
transpiring
and
you've
got
to
use
authorization
kind
of
at
this
governing
body
right,
that's
ensuring
that
only
the
right
data
is
going
to
the
right
services
after
then.
C
Identity
right,
they'll
get
this
s
vid.
That
is
a
very
strong
concept
and
a
very
short-lived
certificate
that
provides
the
actual
workload.
The
carbon,
essentially
its
own
identity,
now
to
communicate
right
and
to
start
authorizing,
can
service
a
talk
to
service
b
or
can
request
or
actually
get
data
from
this
service
right.
A
couple
other
things
need
to
happen.
One
we've
got
this
oidc
framework.
We've
got
this
oauth
framework
that
need
to
be
interspersed
right,
so
oidc,
that's
how
the
user
is
going
to
authenticate.
C
We'll
just
say
the
user
is
a
requester
in
this
instance.
So
I
go
and
I
authenticate
my
user.
I
get
an
oidc
token.
I
take
my
svid
token
coming
from
my
spiffy
identifier
from
the
service.
Now
I
use
that
and
correlate
that
espe
token
with
an
oauth
client
identity,
because
more
than
more
often
than
not,
I'm
actually
going
to
speak
over
an
api.
C
So
once
I
do
that
now
I
have
a
correlated
spiffy
identifier,
s-vid
certificate,
and
I
have
an
oauth
client
id
that
my
service
now
has
access
to.
So
as
a
user,
I
can
take
another
oauth
client
right,
that's
on
my
device
or
or
and
make
an
api
call
with
it
that
then
gets
passed
through
to
that
service.
They
can
mutually
authenticate
each
other
strong
authentication
and
I
can
start
applying
authorization
policies.
Now.
Authorization
also
looks
very
different
than
it
did.
You
know
a
few
years
ago.
C
It
used
to
be
we're
only
concerned
about
what's
happening
inside
of
our
network
right.
We
pretended.
We
had
this
great
strong
perimeter
and
everything
inside
the
perimeter
was
okay.
Now,
as
I
move
to
distributed
services,
that
perimeter
actually
moves
right
to
the
edge
of
the
api
or
the
edge
of
the
service
itself,
so
authorization
needs
to
be
not
just
can
service
a
talk
to
service
b
and
not
just
what
can
user
x
do
within
that
service?
Or
what
does
that
service
look
like
to
that
user,
but
also
with
privacy
consent?
C
C
Israel
is
a
much
richer
set
of
tools
that,
when
they
all
work
together,
right
can
accomplish
this
in
a
very
automated
seamless
manner
and
then
wrap
a
rich
layer
of
governance
around
it.
However,
like
if
you're
just
on
day
one
you
got
to
start
somewhere,
you
have
to
say
I'm
going
to
start
with
giving
my
workloads
identity.
Hence
let's
I'm
going
to
start
using
spiffy
and
using
things
that
are
out
of
the
box.
C
You
know
within
things
like
istio
and
then
I'm
going
to
carry
that
forward
and
tie
it
together
with
my
olaf
and
then
I'll,
carry
that
forward
and
tie
it
together
with
my
existing
idps
and
usually
idc,
and
then
I'm
going
to
start
protecting
that
data
based
upon
authorization
policies
that
are
aware
of
the
context
of
the
service,
meaning.
Is
it
passing
financial
data?
Is
it
regulated
data?
C
Is
it
privacy
data
and
then
perform
authorization
policies
right
on
top,
so
it
all
has
to
work
together
in
a
very
cohesive
manner,
and
we
do
now
have
the
tools
right
available
to
us
to
start
building
these
options.
However,
we
have
not-
or
most
companies
have
not
actually
started
that
path
in
a
in
a
rich
manner,
we'll
do
it
for
a
project
or
two,
but
they
certainly
haven't
done
it.
You
know
at
a
cloud
center
of
excellence
or
an
api
architecture,
point
of
view.
A
B
C
A
Yeah
my
concern
would
be
the
dynamic
nature
and
the
volume
of
transactions
right
and
whether
stu
is
able
to
keep
the
scale
up
right
for
all
the
dynamic
interactions
that
services
need
to
have
or
predefined
policies
that
you
can
set
the
sto
mesh
with.
And
then
you
know
what
transactions
are
going
to
communicate
to
those
channels
and
rest
you
can
use
sidecar
proxies.
C
C
You'd
like
to
share
well
yeah
yeah,
so
so
it's
definitely
scaling
out
and
stay
scaling
out
in
very
big
ways,
meaning
tens
of
thousands,
if
not
hundreds
of
thousands
of
transactions
per
second,
as
well
as
tens
of
thousands
of
containers
right
and
so
what's
happening.
Right
is
obviously
all
that's
not
in
a
singular
istio
cluster
or
in
a
singular
istio
server,
a
single
kubernetes
cluster,
a
singular
istio
service
mesh
right.
C
So
you
have
to
start
federating,
which
is
part
of
the
the
more
recent
s
vid
work,
I'm
sorry
spiffy
work
federating
in
between
your
different,
you
know,
kubernetes
clusters
or
istio
service
meshes
right
to
start
to
share
that
data.
However,
by
by
up
leveling
it
kind
of
one
notch
and
saying:
okay,
it's
going
to
be
api
communication,
or
at
least
at
least,
let's
start
identifying
it
with
api
communication
and
tying
oauth
right.
C
We've
seen
oauth
scale
massively
already
and
being
able
to
start
to
incorporate
that
as
the
defining
body
for
delegated
authorization
you
know,
can
the
services
talk
to
each
other?
What
data
can
the
services
see
as
well
as
now
with
the
the
latest
grant
spec,
with
an
oauth
you're,
able
to
start
tying
together,
rich
policy
with
how
data
is
being
released
and
how
services
are
into
communicating?
So
we
have
the
frameworks
there.
We
have
seen
it
scale
up
to
millions
of
services,
even
with
you
know,
even
more
users
accessing
it.