►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Multi-Cloud Workload Identity With SPIFFE - Jake Sanders & Charlie Egan, Jetstack
Within a single cloud provider, accessing secured APIs using your own workload identity is simple. Cloud SDKs used by application developers know how to retrieve identities and credentials from the cloud environment for each workload based on its context. A cloud administrator can then assign permissions to these identities which allow access to the required APIs. This is seamless for developers - simply calling an API in their code just works, while behind the scenes the network call is cryptographically authenticated / authorized. Unfortunately for the user, this identity is cloud-specific. With few alternatives, this often leads to long-lived credentials being mounted into workloads instead. This is less secure and harder to use. This presentation will show an alternative solution which combines features of open source CNCF projects Kubernetes, cert-manager, cert-manager-csi-driver-spiffe, cert-manager-trust and spiffe-connector to expand your SPIFFE trust domain to any cloud.
A
So
hi
everyone
it's
great
to
be
here
personally
kubecon
and
thanks
for
sticking
around
with
us,
like.
I
know
it's
late
on
a
friday
and
everyone
just
wants
to
go,
but
we're
here
to
talk
to
you
about
multi-cloud
workload,
identity
with
spiffy,
I'm
jake.
I
am
one
of
the
site
manager,
maintainers
interested
in
all
things,
identity
and
x509.
B
We
think
spiffy's
really
great
and
we're
interested
in
trying
to
encourage
more
adoption
in
the
in
the
technology
and
that's
why
we're
doing
this
talk
during
a
company
hackathon.
At
the
end
of
last
year,
we
worked
on
a
project
that
allowed
was
based
on
using
spiffy
ids
to
improve
the
developer,
experience
for
cross-cloud
identities
or
use
of
cross-cloud
apis
for
cross-cloud
workloads
and
the
work
that
we're
presenting
today
is
based
on
that.
B
So
we're
going
to
have
a
presentation
where
we're
going
to
explain
about
how
we
think
about
workload,
identity
and
what
that
means
for
us
and
then
we're
going
to
have
a
short
and
explain
what
we've
built
and
have
a
short
demo
of
that
and
you'll
also
be
able
to
get
we'll
also
share
a
link
to
our
code.
At
the
end,
if
you're
interested
in
having
a
look
yourselves,
it's
a
proof
of
concept,
but
the
code
will
be
there.
B
So
what
do
we
think
about
workflow
identity?
What
what
is
a
workload
identity?
So
an
identity
is
a
way
for
a
workload
to
prove
who
it
is,
prove
its
authenticity
to
other
workloads
and
other
anything
that
it
may
be
communicating
with.
So
we
believe
that
a
workload
identity
workload
should
be
issued
this
identity,
just
by
existing
just
by
running
in
a
cluster
just
by
running
anywhere.
It's
not
something
that
it
should.
B
So
contrasting
this
to
what
we
often
see
people
doing
with
even
with
kubernetes
workloads
is
they're
putting
secrets
in
there
in
their
deployments
they're,
including
secret
tokens,
to
talk
to
other
services
like
we.
We
believe
that
those
aren't
identities
and
identity
is
a
different
thing.
An
identity
is
something
that
you
have
just
by
existing,
so
yeah
the
problem.
B
B
So
we
talked
about
how
we
don't
want
workloads
to
have
a
secret
in
order
to
go
and
work
out
who
they
are
or
to
have
to
call
someone.
We
don't
want
them
to
have
to
do
anything.
They
should
find
their
identity
available
to
them
or
their
identity
is
available
to
them
without
them
even
needing
to
know
where
it
is.
B
So.
What
what
do
we
have
at
the
moment
you're
running
in,
for
example,
in
a
single
cloud
provider?
What
do
you
have
available
to
you
in
a
kubernetes
environment
that
looks
like
this
that
looks
like
workload
identity,
so
many
of
you
will
be
running
in
gke
and
eks
clusters.
Aks
clusters
manage
kubernetes
offerings.
These
have
all
got
something
that
looks
a
bit
like
what
I've
just
described:
the
workload
identity,
definition
that
we've
just
described
it's
possible
for
a
workload
which
is
running
in.
B
What's
good
about
these
identities.
Is
that
they're
easily
consumed
by
cloud
sdks?
If
you're
talking
to
a
google
cloud
storage
bucket,
the
google
cloud
sdk
is
able
to
make
use
of
that
workload,
identity
and
the
workload
doesn't
need
to
know
that
it's
using
the
workload
identity,
it
could
be
using
a
service
account,
but
the
sdk
works
that
out
for
the
developer
and
the
developer.
Experience
is
quite
good.
B
Yeah
developers
also
don't
need
to
worry
about
because
of
that
developers.
Don't
need
to
worry
about
how
they're
going
to
get
a
key
into
their
service
account
key
or
some
aws
credentials
into
their
workload
so
that
they
can
talk
to
the
things
they
need
to
talk
to
so
yeah
they,
so
they
don't
need
to
do
anything
extra
there.
The
other
thing
that's
nice
about
these
identities
is
that
they're
automatically
rotated,
so
there's
no
hassle
when
you
want
to
go
and
you
don't
need
to
when
a
key
is
exposed
for
some
reason.
B
But
we
see
a
problem
with
these
identities
or
with
with
that,
if
we
don't
see
that
as
sufficient
to
solving
this
workload
identity,
problem
of
making
or
this
goal
of
trying
to
make
sure
that
all
workloads
have
an
identity,
these
identities
are
proprietary
and
they
are
most
useful
and
most
easily
used
in
your
the
cloud
that
the
workload
is
resident
in.
It's
easy
for
me
to
use
my
gke
workload
identity
to
talk
to
google
apis,
but
although
it
is
available,
identity
federation
is
still
another
thing
to
configure.
B
B
So
the
identity
is
is
one
of
many
identities
and
it's
not
universally
accepted
yeah,
and
so
what
this
what's
frustrating
about.
This
is
even
though
we've
got
something
that
looks
like
workload,
identity
and
we
even
call
it
workload,
identity,
we're
still
back
to
that
same
problem
of
a
workload
having
many
identities
and
managing
many
identities.
B
So
we
we
see
that
and
then
we're
back
to
creating
additional
secrets
and
credentials
outside,
so
that
we
could
talk
to
other
services
that
we
need
to
talk
to
talk
to
that
database
or
talk
to
that
random
thing.
That's
still
left
on-prem
and
that's
a
security
issue
where
developers
are
managing
these
secrets
in
their
deployment
pipelines
in
different
ways,
potentially
insecurely
and
in
a
large
environment,
large
multi-tenant
environment.
It's
really
hard
to
keep
track
of
it.
B
Of
course,
the
other
thing
about
those
extra
those
extra
credentials
which
have
been
managed
is
that
they're
not
cryptographically,
identifying
the
the
workload
anymore
they're,
just
as
we
see
it
just
another
password
that
could
be
if
the
misconfiguration
were
to
happen.
Another
work
picked
up
by
another
workload
and
used
such
that
identity
is
actually
available
to
anybody
who
has
the
secret,
and
we
see
that
as
a
big
problem.
B
So
what
we
would
really
like
to
see
is
that
there
was
a
production
ready
standard
for
workload,
identity
where
workloads
could
have
a
single
identity
to
talk
to
everything
they
needed
to
talk
to,
regardless
of
where
that
was
whether
it
was
a
cloud
provider
or
another
open
source
tool
or
another
workload.
That
was
had
been
a
custom
workload
in
your
organization.
B
A
It's
open
specification
and
reference
implementation
inspire
to
authenticate
securely
between
services
over
untrusted
networks
without
using
passwords
or
api
tokens.
So
if
you
think
back
to
our
first
slide,
I
think
that's
the
first
thing
that
we
said
then
the
spiffy
spec
defines
a
spiffy
id
and
the
spiffy
verifiable
identity
document.
So
these
are
standardized
identity.
A
spiffy
id
is
looks
a
little
bit
like
a
url.
A
It's
a
specially
crafted
x
509
certificate,
so
it
has
a
very
specific
format
but,
more
importantly,
you
can
use
it
to
cryptographically
identify
the
bearer
of
the
holder
and
again.
This
is
what
we
believe
is
the
unforgivable
document
that
should
represent
our
identity
and,
finally,
if
you're,
using
your
svid
or
svid,
to
perform
a
tls
handshake
mutual
tls.
It
means
that
both
entities
on
each
side
of
the
connection
should
be
reasonably
sure
that
the
identity
on
the
other
side
is
who
they
say.
They
are
so
yeah.
A
A
So
we
can
take
all
that
knowledge
in
cncf
and
we
are
happy
that
it
won't
become
proprietary
at
any
point,
so
happy
to
drive
adoption
of
it
and
I
think
we're
not
alone
in
this.
Lots
of
people
are
starting
to
think
about
using
it
and
getting
getting
traction
at
these
talks
at
least,
and
we've
seen
a
few
customers
at
jet
stack
talk
about
it
as
well.
A
So
how
do
we
take
svids
and
make
them
cloud
native
so
as
a
maintainer
of
the
manager
project?
I'll
just
tell
tell
you
about
that
too.
So
slap
manager
is
a
cncf
sandbox
project,
it's
dedicated
to
all
kind
of
cloud
native
x509
certificate
management,
but
it's
a
kind
of
umbrella
organization
that
encompassing
several
projects
and
I'm
kind
of
lucky
enough
that
I
spend
a
good
time
a
good
amount
of
my
work
time
being
allowed
to
contribute
to
it
and
the
first
opponent
we
need
is
set
manager
itself.
It's
a
kind
of
very
popular
cuventis
operator.
A
A
So
we've
got
certain
azure
and
now
we
need
svids.
So
we
need
our
workload
identity,
so
we
have
something
called
csi
driver
spiffy.
This
is
kind
of
officially
in
the
spiffy
project.
Now,
if
you
scroll
down
on
spiffy.io
you'll
see
it,
we
said
earlier
that
workloads
should
not
have
to
do
or
know
anything
to
get
their
identity.
A
A
So
a
csi
driver
is
a
way
of
exposing
a
file
system
to
a
pod,
and
so
it's
part
of
the
volume
setup
of
your
pod.
It
will
happen
before
your
workload
starts
and
the
cubelet
tells
you
your
identity
as
part
of
starting
a
pod,
because
by
deploying
something
on
kubernetes,
you've
explicitly
told
the
cubelet.
I
want
you
to
start
this
pod
and
so
we're
kind
of
pre-pod
startup
and
we
generate
a
let's
see
we
get
the
csi
driver
called.
We
generate
an
in-memory
private
key.
A
A
We
have
something
called
approval
policy
which
might
integrate
with
what
you're
already
using
for
your
kind
of
compliance,
but
you
could
insert
policy
at
this
point
and
then
yeah.
Your
identity
is
available
in
the
pod
before
the
workload
starts
and
the
final
part
of
kind
of
any
mutual
tls
is
you
need
the
trust
bundles
for
your
trust
domain.
A
A
A
So
we're
kind
of
we
like
swifty
a
lot
and
we're
trying
to
drive
adoptions,
but
if
you
look
out
in
the
ecosystem
right
now,
most
mostly
the
most
the
most
users
of
sofia,
ids
are
just
using
it
to
configure
mtls
between
envoy
instances,
which
is
great
for
the
service
measures
that
are
already
using
envoy.
They
can
adopt
spiffy,
ids
and
all
of
your
service.
A
Mesh
traffic
will
be
completely
encrypted
and
validated
like
this
works
with
istio
and
console
connect
and
kuma,
and
all
the
other
projects
that
are
on
spiffy.io,
but
while
they're
using
spiffy,
it
doesn't
increase
adoption
of
the
svid,
because
it's
an
opaque
implementation
detail
like
by
default.
Your
you
talk,
unencrypted
connections
to
your
envoy,
sidecar
envoy.
Does
the
encryption
and
verifying
of
the
other
end,
which
is
another
envoy
which
decrypts
it
and
then
just
passes
it
to
you
without
any
context.
A
So
for
our
kind
of
mini
demo,
we
proof
of
concept
we
set
out
to
recreate
the
state-of-the-art
cloud
provider
experience
that
charlie
talked
about
where
you
just
call
apis
and
they
know
who
you
are,
but
we
want
to
use
a
standard
identity
document
on
different
services
like
spiffy
id,
but
the
developer
experience
has
to
stay
the
same.
It
has
to
be
seamless
to
use,
so
they
should
just
continue.
Writing
the
same
code,
they've
always
written
and
call
their
cloud
services,
and
it
just
works.
A
A
A
We,
like
our
csi
driver,
so
we're
using
that
in
this
demo
the
sidecar
will
automatically
pick
up
the
svid.
It
will
talk
to
the
spiffy
connector
server
and
exchange
it
for
very
short-lived
cloud
credentials
and
write
it
in
the
kind
of
well-known
location
that
the
cloud
sdks
are
already
expecting
potentials
to
be,
and
we
and
then
you
just
call
the
cloud
apis
and
it
works,
and
we
know
that
you
can
do
this
kind
of
already
with
kubernetes
service
account
identity
federation.
A
A
A
B
B
So,
let's
first
look
at
the
spiffy
connector
server
deployment,
so
the
spiffy
connector
server
is
it's
just
a
deployment?
It's
a
single
single
replica
but,
it's
importantly,
is
configured
with
an
acl
or
a
list
of
acls.
So
here
we
can
see
that
our
example.
What
we're
calling
match
principle
matches
the
spiffy
id
of
our
example
application.
B
So
you
can
see
that
that
application
or
workload
is
able
to
get
certain
sets
of
credentials.
So
first,
it's
able
the
first
type
of
credential
it's
able
to
get
is
a
google.
I
am
service
account
key
from
the
google.
I
am
service
account
key
provider
with
an
object.
Reference
to
this
service
account
that's
running
in
my
personal
gcp
project.
B
The
server
is
also
configured
with
its
own
ssbid,
so
the
server
knows
how
to
find
its
svid
by
looking
somewhere
at
looking
at
a
a
mounted
set
of
files.
So
that's
also
set
in
the
in
the
service
configuration
and
that's
so
that
the
workload
knows
to
trust
the
server
and
we'll
see
that
in
just
a
second,
the
deployment
itself
is
is
fairly
fairly
simple.
It's
it's
just
a
spiffy
connector
server.
We
we
make
use
of
this
config
file.
I've
just
talked
you
through.
B
The
other
thing
that
the
server
does
have
is
the
server
has
does
have
some
credentials
such
that
it
is
able
to
go
and
mint
those
short-term
credentials.
So
we've
moved
that
away
from
the
the
the
long-lived
cloud
credentials
away
from
the
developer
workloads
into
the
specific
connector
server
in
our
example,
and
then
so
that's
what
what
you're?
B
Also
seeing
here,
as
you
can
again,
as
you
can
see,
the
the
spiffy
id
is
also
included
as
a
volume
mount
and
this
this
biffy
ideas
are
made
available
to
the
server
using
the
csi
spiffy
integration
that
we
have
with
set
manager.
So
that's
how
that's
that's,
how
both
the
server
and
the
workload
are
getting
their
s50
ids
and
these
volumes,
as
you
would
expect
for
the
cloud
provided
credentials.
B
The
application
that
we're
running
is
a
simple
application
which
is
going
to
move
files
from
one
cloud
to
another.
You
might
imagine
some
in
other,
more
complicated
multi-cloud
workload
example,
but
that's
what
it's
doing
in
our
cases.
What
the
imagine
that
there's
some
use
case
that
we
want
to
move
files
periodically
or
whatever
between
two
two
different
clouds,
so
the
configuration
that
the
developers
have
written
is
here.
B
They
are
exposing
a
service
where
people
are
instructing
the
application
on
a
given
port
and
they
are
talking
between
two
different
buckets
in
the
cloud
provider,
and
these
are
configured
here.
These
are
the
two
bucket
names
and
it's
also
configured
as
a
simple
deployment
in
in
this
deployment.
We
have
two
containers.
B
We
have
the
example
application
which
runs
and
serves
the
application,
and
it
has
some
some
volume
mounts
to
to
share
the
which
are
shared
with
the
sidecar
which
it
uses
to
access
the
short-lived
credentials,
which
are
collected
by
the
sidecar
and
just
before,
you're
wondering
like.
Oh,
hey,
look,
you
know,
you
said
you're
going
to
make
the
developer
experience
better,
like
this
looks
like
something
that
the
developer
would
need
to
configure
themselves
like.
B
You
could
perhaps
imagine
if
you
were
to
use
something
like
this,
that
a
mutating
web
hook
would
inject
configuration
or
sidecars,
as
you
are
familiar
with
for
other
tools.
So
it's
included
here
to
help
you
understand.
What's
going
on
like
mutating
webhook
would
be
rather
magic
and
I
felt
that
it
was
clearer
just
to
show
what
it
would
look
like.
So,
alongside
the
workload
is
the
spiffy
connector
sidecar
and
the
spiffy
connector
sidecar
is
configured.
B
B
B
B
B
B
B
It
says
that
it's
starting
a
credential
manager
for
this
particular
workload
and
the
it's
got
both
google
cloud
and
aws
credentials
and
they've
been
saved
in
the
respective
paths.
So
that's
the
end
of
the
terminal
demo
I
just
want
to
as
a
as
proof
of
concept.
I
want
to
show
you
this
application
actually
doing
something.
I'm
going
to
try
and
I
seem
to
have
sorry,
I'm
back
in
kind
of
lag.
B
B
There
you
go
and
now
back
here.
Let's
just
make
this
window
the
right
size
as
well,
and
we
can
go
to
the
next
slide.
Yeah
great.
So
hopefully,
what
we
have
shown
with
this
proof
of
concept
is
an
example
use
case
where
spiffy
ids
are
used
as
first-class
citizens.
We
we
appreciate
that
you
may
have
other
ways
of
solving
this
problem,
that
that
aren't
as
awful
as
we
told
you
they
might
be.
B
But
what
we
really
wanted
to
show
here
was
that
spiffy
ids
can
be
useful
and
you
can
use
them
and
they
can
form
like
valid
paths
and
channels
of
communications
between
workloads.
So
it's
been,
and
it's
been
really
interesting
to
we've
had
with
jake
and
myself.
My
colleagues
at
jet
stack
have
been
staffing.
B
The
cert
manager
booth
this
week
and
we've
had
lots
of
people
coming
to
us
and
talking
about
these
fantastically
complicated
systems,
they
have
for
getting
certificates
for
different
host
names
into
different
workloads
in
different
clusters,
because
they're
all
meant
to
have
the
same
identity
and
then
but
they're
all
running
in
all
these
different
places,
and
it's
kind
of
like
oh
well,
you
know
have
you
thought
about
using
a
different
kind
of
identity?
How
do
you
feel
about
using
spiffy,
and
so
it's
actually
really
validated
and
other
discussions
we've
had
this
week
have
really
validated.
B
You
know
that
people
are
looking
for
some
kind
of
standard
here,
so
yeah
we've
got
all
sorts
of
ideas
about
what
we
want
to
do
with
this
stuff
like
this
is
a
toy
example.
It
was
an
example
that
you
know
jake
myself
and
our
colleague
josh
here
in
the
front
row
did
as
part
of
a
company
hackathon
in
a
few
days.
B
You
know,
I'm
excited
by
authorization
as
well
like
what
could
you
do
if
you
knew
the
identity
and
like
process
the
query
such
that
certain
identities
were
allowed
to
access
certain
tables
or
to
perform
certain
operations
within
the
database
yeah?
You
can
imagine
a
world
where
things
accept
spiffy
everywhere
like.
Why
should
I
need
a
gcp
key
in
the
first
place
like?
Why
can't
I
just
talk
spiffy
spiffy
straight
to
gcp
or
straight
to
any
cloud
provider
or
even
any
api.
B
So
so
yeah,
that's
that's
it!
That's
what
we
wanted
to
talk
about
thanks,
very
much
for
listening
and
for
staying
around
this
late,
I'm
conscious!
It's
been
a
tiring
week
for
me
and
jake,
and
it's
been
a
tiring
week
for
many
of
you,
I'm
sure.
So
thanks
for
coming
at
the
very
end
to
listen
to
us
plug
specifically
for
a
little
bit
just
before
we
go
on
and
hopefully
have
some
questions.
B
If
you,
if
you
want
to
chat
to
us,
you
you
can
those
are
our
work,
emails
we're
also
on
on
twitter.
You
can
you
can
find
us
or
chat
to
us
at
the
end.
We'd
also
like
to
say
a
quick
thanks
to
our
colleague,
josh
who's
got
the
camera
in
the
front
row.
Josh
not
only
worked
with
us
on
the
initial
my
colleague
sit
around
was
waving
at
me
from
the
back
thanks.
B
Itaram
josh
not
only
worked
this
on
that
the
hackathon
project
where
this
came
from,
but
has
also
been
important
in
building
so
manager
and
cert
manager,
csi
spiffy,
which
is
the
kind
of
the
fundamental
infrastructure
that
we
see
as
being
an
important
step
in
making
spiffy
workload,
identity
really
work
on
kubernetes
environments,
so
yeah.
I
promise
there
would
be
code
there's
a
link.
The
first
link
is
the
spiffy
connector
that
we've
presented.
There's
the
example
application
and
things
is
all
in
there.
You
know,
I.
B
A
Come
come
talk
to
us
like
we
really
want
to
drive
a
world
where
spiffy
is
used
and
the
pragmatic
way
of
doing
that
is
to
build
more
support
into
other
things.
So
we'd
love
to
collaborate
with
you
and
just
yeah
come
chat
to
us,
we're
we're
on
the
kubernetes
slack
in
certain
manager,
dev
channels,
but
we're
also
on
the
spiffy
slack,
which
is
probably
a
better
place
for
it.
Just
yeah
come
chat
to
us.
D
I
would
like
to
ask,
because
maybe
I
lost
that
part,
how
does
the
server
which
actually
may
run
per
cluster
one
per
cluster
so
to
say,
acquires
these
credentials
from
the
cloud
provider
itself?
I
understood
that
the
connector
connects
to
the
server,
but
I'm
missing
the
bit
where
the
server
grant
gets
the
credentials
from
there.
A
D
A
A
B
You
would
you
would
see
the
the
short-lived
credential
that
was
issued
by
the
server,
I
suppose,
which
you
could.
You
would
have
an
audit
log
showing
you
that
the
spiffy
connector
server
had
issued
you
a
credential
additional
credential.
Then
the
credentials
used
in
that
way,
but
yeah
like
it's,
it's
not
ideal,
but
it's.
It's
meant
to
just
be
an
example,
really
use
case.
Yeah.
A
Yeah
I
mean
we
said
already.
Our
ideal
situation
is
that
the
cloud
provider
just
speaks
fifties
and
we
wouldn't
have
this,
but
we
also
no
one's
going
to
use
50.
If
you
can't
use
it
right
now,
so
we're
trying
to
drive
up
adoption
and
then
get
people
to
notice
and
then
start
implementing
native
support.
A
So
I
actually
haven't
looked,
but
it's
while
we've
been
looking
at
the
ecosystem
in
general.
Well,
while
most
things
say
that
you
can
authenticate
with
mutual
tls,
they'll
be
doing
some
parsing
of
the
common
name,
basically
just
for
identity,
which
is
not
the
same
as
what
a
svid
looks
like.
So,
even
if
things
claim
that
they
speak
mgls,
it
doesn't
really.