►
From YouTube: Don't Mind the Gap: Securely Accessing Cloud Resources From Anywhere With SPIFFE/SPIRE - Evan Gilman
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Don't Mind the Gap: Securely Accessing Cloud Resources From Anywhere With SPIFFE/SPIRE - Evan Gilman, VMware
Of all the things you can do with SPIFFE and SPIRE, accessing cloud services from anywhere without having to generate, store, or manage API keys is a particularly powerful one. Without it, answering simple questions such as "How can I access an S3 bucket from Azure?" means solving for headaches like encryption at rest, tokens that never expire, and manual rotation processes. Unfortunately, this is still par for the course in many environments, but SPIRE is here to help.
In this session, we will go over the basics of identity federation with SPIFFE and SPIRE, which brings the "Sign in with Google" experience to cloud native workloads. We'll discuss how this approach compares to others, and demonstrate how you can use it to securely access AWS resources and more without a secret access key.
A
A
I've
got
20
slides.
It's
been
around
20
minutes.
If
folks
have
questions
anything
like
that,
please
feel
free
to
raise
your
hand
in
the
middle
of
the
talk,
I'm
happy
to
kind
of
stop
and
answer
your
questions.
Make
it
personal
I've
got
a
mic
up
here,
there's
a
mic
back
there
or
we
can
shout
or
we'll
figure
it
out.
A
So
we'll
talk
first
about
the
spiffy
Basics
kind
of
we
won't
go
over
all
of
spiffy,
but
we'll
go
over
the
things
that
are
important
to
understand
for
the
content
in
this.
In
this
presentation,
similar
thing
for
aspire
cover
kind
of
at
a
high
level.
Some
of
the
important
things
that
you'll
you'll
need
to
kind
of
make
sense
of
the
rest
of
the
talk
and
then
I'll
step
through
kind
of
like
three
examples
of
how
to
do
this.
A
A
So
without
further
ado,
you
can
dive
on
oops
wrong,
one
spiffy
basics.
The
first
thing
to
know
about
spiffy
is
a
spiffy
ID
and
I
apologize
I.
Some
people
here
tend
to
be
newcomers.
Some
people
tend
to
not
be
so
bear
with
me
the
spiffy
ideas
kind
of
what
it
sounds
like
it's,
basically
like
a
username
for
workloads
and
specifically
deals
with
workload
identity.
This
is
kind
of
like
the
core
thing
and,
as
you
can
see
here,
it's
it's
like
a
structured
string
is
structured
as
a
URI.
A
A
The
first
one
is,
of
course,
the
scheme
of
spiffy,
which
just
kind
of
States.
This
is
a
specific
ID.
The
second
is
this
piece.
We
call
the
trust
domain
and
Trust
domain
is
what
I
would
call
kind
of
like
a
security
domain.
You
use
a
one-to-one
relationship
between
a
trust,
domain
name
and
a
set
of
identity
issuers.
A
So
when
you
look
at
a
trust
domain
name,
you
should
immediately
know
okay,
it's
coming
from
kind
of
this
zone
or
these
set
of
issuers,
and
you
can
see
because
it's
part
of
the
ID
all
of
the
spiffy
IDs
are
qualified
by
this
trust
domain
name
and
then
the
final
piece
is
kind
of
the
name
of
the
service,
and
this
can
be
you
know
you
can
have
multiple
levels
in
there
the
same
as
a
regular
URI.
You
can
make
it
hierarchical.
You
can
make
it.
A
However,
you
want
the
spec
doesn't
say
much
about
restricting
kind
of
the
values
of
these
things.
This
is
a
little
bit
of
a
Choose
Your
Own
Adventure,
but
given
the
spiffy
ID,
you
can
kind
of
see
immediately.
You
know
which
authority
issued
this
identity
and
what
is
the
identity
of
the
workload
that
it's
supposed
to
represent
right?
The
name
of
the
workload
is
supposed
to
represent,
and
then
these
specific
ideas
they
get
encoded
into
a
document
specifically
supports
two
documents.
A
Then
we
have
this
thing
called
the
bundle.
The
bundle
is
that
collection
of
authority
Keys,
you
know
so
when
I
talk
about
a
trust
domain
and
there's
some
set
of
authorities
in
a
trust
domain
that
are
responsible
for
issuing
identities.
You
know
they
have.
These
authorities
have
a
set
of
public
private
key
pair.
A
A
A
A
That's
fairly
simply
just
this
collection
of
kind
of
bundle,
data
that
we
just
looked
at
and
you'll
keep
this
map
and
you'll
know:
hey
I
trust,
domain,
Foo,
there's
the
bundle,
Tresemme
bar
here's
the
bundle,
and
when
you
encounter
one
of
these
svids,
you
can
kind
of
do
this
lookup,
you
can
say:
okay,
this
test
fit
is
there's
this
Smithy.
Id,
therefore,
is
from
this
trust.
Domain
and
I
select
the
bundle
for
that
trust
domain.
A
To
do
the
validation
by
doing
it
this
way,
it's
a
lot
different
than
like
webpki,
which
has
kind
of
a
set
of
you,
know,
keys
and
search
handed
down
from
on
high.
That
are
good
for
anything
kind
of
thing.
Right,
spiffy,
like
delineates
this
and
says:
okay,
we
want
only
authorities
to
be
good
for
certain
aspects,
and
this
gives
the
kind
of
isolation
I
had
mentioned
earlier
security
domain.
You
know
if
one
of
these
trust
domains
is
compromised,
it
doesn't
automatically
translate
into
another
trust.
A
A
A
So
we
talk
about
circs
and
Trust
domains
and
all
this
stuff
like
who
is
signing
those
shirts,
you
know
and
where
do
I
get
them
from
all
this
kind
of
stuff?
That's
what
Spire
does
expires
written
and
go
it's
designed
to
run
in
as
many
environments
as
possible.
Spiffy
is
platform.
Agnostic
and
Spire
is
kind
of
like
what
should
I
say
like
the
darling
implementation
of
spiffy,
and
so
in
as
much
as
spiffy
is
intended
to
be
run
out
of
everywhere.
Aspire
is
as
well
runs
on.
A
So
these
are
the
kind
of
the
high
level
components
so
Inspire
Spire
has
a
server
or
component
and
an
agent
component.
The
server
component
is
the
piece
that
does
all
the
siding
just
got
the
keys.
It's
got
all
that
good
sensitive
stuff.
Then
we
have
these
agents.
These
agents
run
nominally
on
a
per
node
basis
and
they're
the
ones
who
are
actually
providing
the
identities
to
the
workloads.
A
One
of
the
really
important
things
about
spiffy
is
that
it
solves
this
problem
that
we
call
secure,
introduction
or
a
secret
zero
problem.
So
you
know
we
need
to
play
software
and
it
pops
up.
How
does
it
speak
to
the
first
system?
You
know
how
does
it
begin
that
first
authentication
process
a
lot
of
people
try
to
solve
this
through
injection
of
credentials.
Baking
things
in
the
containers
and
all
kinds
of
other
stuff
spiffy
doesn't
require
any
of
that.
It
has
this
concept
of
what
we
call
workload
API
and
that's
what
these
agents
provide.
A
A
It
kind
of
just
says:
hey
who
am
I
and
then
it's
the
spiffy
implementation's
job
in
this
case
Spire,
to
figure
that
out
and
the
end
result
of
that
process
is
the
issuance
of
an
identity,
and
so
when
we
talk
about
doing
this
without
any
kind
of
secret
being
necessary
or
token,
or
what
have
you,
you
kind
of
need
a
way
to
describe
things
right
and
you
need
you
need
to
declare
hey.
You
know.
A
Bob
is
Bob,
Alice
is
Alice,
so
Aspire
has
this
concept
of
registration
in
order
for
a
workload
to
get
an
identity
from
spire
it
must
first
be
registered
and
the
registration
is
basically
saying
like
hey
look,
we've
got
this
workloader,
her
name
is
Alice.
She
runs
generally
in
this
cluster
over
here.
This
is
her
General
shape
and
look
she's
this
tall
and
whatnot.
When
you
see
this
workload,
you
know
that's
Alice
and
you
give
her
the
Alice
identity.
A
A
It's
very,
very
simple:
HTT
HTTP
based
process,
regular
web
TLS
protection
around
it.
So
this
IDC
Discovery
provider
supports
acne.
So
you
know
you
can
deploy
this
thing.
It'll
come
up
and
you
know
it
can
grab
a
webpk
icer
and
it
can
kind
of
serve
these
Keys
up
for
you
in
a
public
fashion
and
then
what
it
does
is
in
this
massaging
here.
As
you
see,
the
oidc
spec
is
is
very
the
Smithy.
The
bundle
spec
is
very,
very
similar
to
the
oidc
key
spec.
A
A
You
know
if
we
replace
the
right
hand
side
with
just
AWS
AWS,
can
kind
of
stand
in
here
and
and
hit
this
by
our
server
and
grab
those
keys
and
do
validation
the
same
way
that
another
Spire
server
might
be
able
to
do
this
I.
Didn't
though,
the
diagram
I
have
here
doesn't
show
the
oidc
discovery
provider,
but
it
would
be
running
kind
of
in
this
diagram
collocated
with
the
Spire
server
as
a
part
of
his
pod,
or
something
like
that,
and
so
how
exactly
does
this
work?
A
There's
a
service
in
AWS
called
the
STS
I,
can't
remember
it's
simple
or
secure
token
service,
I'm,
pretty
sure
it's
the
last
two
and
what
it
enables
you
to
do
is
is
to
go
and
exchange
a
credential
for
an
AWS
credential.
So
what
we
can
do
using
this
endpoint
is,
we
can
come
to
it
with
a
spiffy
ID
with
a
spiffy
credential
and
we
can
exchange
the
spiffy
credential
for
a
time-bound,
temporary
AWS
secret
access
key
and
the
magic
about
this.
A
Is
that
hey
you
know,
spiffy
doesn't
require
you
to
like
store
secrets
on
disk
or
do
anything
it
does
all
the
stuff
at
runtime
doesn't
require
to
do.
Secrets
injection
Secrets
management,
anytime,
that
you
have
to
talk
to
S3,
for
example,
you're,
going
to
need
an
AWS
secret
access
key
and
there's
a
lot
of
pain
around
managing
these
things.
Oftentimes
they
don't
expire.
A
People
have
MFA
policies
on
their
account,
but
then
they
have
to
get
the
non-mfa
secret
access
keys
for
their
workloads,
because
how
do
you
do
MFA
with
your
workload,
all
these
kinds
of
pain?
So
the
way
that
we
do
this?
Is
we
create
this
mapping,
this
trust
relationship
in
AWS,
and
we
set
up
this
web
identity
provider
and
you
point
it
at
the
IDC
Discovery
thing
that
runs
next
to
your
Spire
server
and
once
you've
set
this
up.
You
can
then
create
this
mapping.
Like
I,
said
here
on
the
top.
A
You
can
see
that
there's
a
role
AR
on
so
here.
What
we're
saying
is
this
particular
AWS.
Im
role
is
mapped
to
this
particular
Smithy
ID
on
the
bottom
right,
spiffy
example.com,
that's
through
testdot,
and
so
when
somebody
hits
STS
and
they've
got
this
particular
identity
and
this
particular
audience.
This
is
with
jot
token.
By
the
way,
then,
the
caller
is
entitled
to
receive
temporary
credentials
for
the
role
described
at
the
top,
and
this
is
pretty
awesome
because
it
negates
the
whole.
Where
do
the
keys
go?
A
A
A
Is
you
drop
this
little
config
file
on
disk,
and
you
also
drop
this
if
the
AWS
assumeral
utility
on
disk
and
so
long
as
your
app
uses,
the
AWS
SDK
to
talk
to
S3
or
redshift
or
whatever
else
you're,
using
the
the
logic
to
hook
and
look
for
this
config
file
and
call
out
and
do
all
this
stuff
is
already
there.
So
these
apps
that
have
this
AWS
SDK,
they
can
be
running
anywhere.
They
can
be
running
on-prem.
They
can
be
running
in
azure,
you
name
it.
A
Then
they
don't
actually
have
to
be
written
with
the
spiffy
SDK.
They
can
just
use
the
regular
out
of
the
box,
AWS
SDK
with
this
little
helper
utility
and
what
this
helper
utility
does
is.
It
knows
how
to
talk
to
the
workload
API
grab
a
Smithy
identity,
go
talk
to
STS,
grab
the
temporary
STS
credential
and
then
return
it
back
to
the
app.
So
we
have
a
lot
of
people
who
have
migrated
apps
out
of
AWS
that
are
none
the
wiser
effectively,
because
none
of
the
app
code
has
to
be
changed.
A
They
have
a
service
that
you
can
go
to
and
again
it
knows
how
to
do
the
oidc
swap
and
you
can
bring
your
spiffy
drop
there
and
they
can
map
that
back
too.
An
Azure
identity,
this
blog
post
identity,
digest
blog,
is
an
excellent
blog,
Uday
I
believe
as
a
identity
architect
at
Microsoft
he's
been
there.
A
You
have
Aspire
server,
you
have
this
IDC
thing.
You've
got
a
workload,
it
comes
up,
it
gets
a
spiffy
ID.
It
goes
and
talks
to
this
endpoint
in
Azure
does
this
exchange.
It
gets
back,
Azure
creds
and
then,
with
the
Azure
credits,
you
can
do
whatever
it
wants.
Now.
You
know
that
kubernetes
cluster,
that
big
green
part
there,
like
I,
said
that
can
be
anywhere.
It
doesn't
have
to
be
in
Azure,
because
the
spiffy
identity
is
platform,
agnostic.
A
A
This
integration
actually
turns
on
a
proxy
and
this
proxy
steps
into
the
Google
metadata,
endpoint
and
emulates
effectively
emulates
the
answers
like
the
Google
metadata
endpoint
would
give
you
if
you
were
running
on
Google
Cloud
so
similar
to
the
AWS
thing,
or
software
can
kind
of
pop
up
it
already
or
you're,
using
the
gcp
SDK.
It
knows
it
can
talk
to
this
metadata
API
it
reaches
out,
and
it
finds
this
proxy
and
this
proxy
has
the
smarts
to
get
the
spiffy
identity
go
and
make
the
exchange
with
gcp
and
then
bring
back.
A
The
question
was
that
this
diagram
presupposes
that
trust
is
already
established.
I
think
that
you're
asking
about
that
screen
from
the
AWS.
Yes,
it
does
there's
a
configuration
that
you
need
to
do
in
gcp,
similar
to
AWS,
where
you
point
it
back
to
your
oidc
provider,
your
Spire
server.
There's
a
certificate
involved.
There
usually
webpki
certificate
involved
there.
So
this
this
diagram
presupposes
that
that
configuration
has
been
done
already.
A
The
the
direction,
so
the
questionnaire
is
the
direction
of
request.
Is
it
from
cloud
provider
to
Aspire
server
as
a
Spire
server
to
the
cloud
provider?
Well
in
terms
of
the
Spire
server,
it's
fire
server
to
the
cloud
or
cloud
provider
to
the
Spire
server,
so
the
cloud
provider
periodically
will
reach
the
Spire
server
grab
the
recent
public
Keys
pull
them
back.
A
So
you
can
see
you
know:
I
talked
earlier
kind
of
about
how
it's
it's
all
kind
of
a
similar
underlying
technology.
Here
that
enables
this
with
different
kind
of
nuances.
On
each
one.
You
know
different
Cloud
providers
decide
they
want
to
do
this
thing
differently,
and
so
the
way
you
can
figure
them
the
way
you
can
see
them
kind
of
subtly
varies
from
case
to
case.
However,
the
underlying
mechanism
is
relatively
universally
applicable.
A
lot
of
software
supports
this
kind
of
oidc
auth.
A
If
you
look
there's
like
a
little
logo,
it's
like
an
o
with
an
I
a
little
circle
thing.
A
lot
of
these
software
support
IDC
already
and
those
that
do
you.
It's
like
a
90
99
chance,
90
95
chance
that
it's
just
going
to
work
out
of
the
box
specifically
Aspire,
both
platform
agnostic,
they
can
run
anywhere.
Aspire
is
super
super
pluggable.
A
So
all
the
kinds
of
things
that
aspired
needs
to
rely
on
underlying
platforms
are
all
pluggable,
so
as
AWS
plugins,
there's
plugins
to
interact
with
Hardware
TPM
search
plugins
to
do
all
this
different
kind
of
stuff.
So
the
the
real
thing
here
is
that
you
know
a
lot
of
times.
Access
to
these
Services
has
been
kind
of
gated
by
where
you're
running
your
workload,
and
that
is
no
longer
if
you
want
to
use
the
Google
machine
learning
stuff
from
inside
your
data
center.
A
You
can
do
that
very
easily
and
you
don't
have
to
fool
around
with
any
of
these
keys
and
yeah.
So
that's
one
weird
trick
to
avoid
the
all
the
pain
and
management
around
kind
of
managing
these
tokens,
storing
them
encrypting
them,
injecting
them
all
this
stuff.
All
the
specific
identities
are
all
kind
of
short-lived
fast
rotated,
everything's,
fully
automated
from
the
root
down.
So
this
problem
kind
of
just
vanishes.
A
If
you
want
to
learn
more
about
this
stuff,
we
have
obviously
our
GitHub
repos.
These
are
a
couple
of
the
repos
I
talked
about
today
with
the
helper
utility
from
AWS
and
and
square,
and
also
the
helper
utility
from
Google
Cloud
platform
to
do
so.
If
you
asked
from
anywhere
that's
all
I
have
for
you
today,
open
up
for
questions.
I'll
leave
this
up
for
a
minute
post
on.
Take
pictures
and
I've
got
a
QR
code
for
talk
feedback.
Thank
you
for
coming.
It's
great
to
see
you
all.
C
Thank
you
yeah,
so
I'm
in
the
process
of
trying
to
cook
up
a
Spire
deployment
for
my
environment
right
now,
and
the
challenge
I'm
coming
I'm
encountering
is
that
the
list
of
trust
domains
keeps
growing
and
growing
and
growing,
and
so
there's
also,
it
appears
to
me
a
tight
relationship
between
trust
domain
inspired
deployment.
So
let's
say
I'm
gonna
have
50
trust
domains.
Now
I
have
to
manage
50
Aspire
server
deployments
yeah.
C
A
The
the
kind
of
exploding
trust
domain
problem
is
a
problem
that
I've
seen
a
number
of
times,
particularly
at
Shops
with
larger
scale.
You
know,
I
think
this
also
kind
of
comes
down
to
a
trade-off.
You
know
there
are
some
tricks
you
can
do
so.
The
first
thing
is
that
you
know
Spire
server
can
be
deployed
in
what
we
call
its
nested
model,
so
you
can
have
multiple
Spire
clusters
participating
in
one
larger
trust
domain.
A
Oftentimes
people
reach
for
many
trust
domains,
because
this
is
kind
of
like
the
easy
thing
to
do
with
their
model.
For
example,
if
I'm,
just
stamping
out
a
bunch
of
kind
of
like
equivalent
spy
kubernetes
clusters,
the
easiest
thing
to
do
oftentimes
is
just
say:
okay.
Well,
each
one
of
these
is
its
own
trust
domain.
A
There
are,
there
are
drawbacks
with
that.
You
know
this
Federated
auth,
we
talked
I
talked
about
earlier,
where
you
look
at
the
trust
domain
and
you
choose
the
correct
bundle.
I
mean
envoys
have
put
supports
this
natively.
Other
software
support
this
natively.
But
not
everyone
does
you
know,
engine
X
doesn't
and
a
couple
others
so
anytime
that
you
talk
about
this
Federated
author,
already
you're
kind
of
talking
about
the
cost.
A
The
the
other
piece
of
this
is
that
each
one
of
these
bundles
there's
a
size
and
when
you
have
a
lot
of
them,
they
get
quite
large
and
there's
a
lot
of
network
traffic
involved
in
that
and
the
agent
stuck
these
things
down,
and
so
you
know
we're
we're
exploring
ways
to
kind
of
make
this
problem
better.
We
do
have
like
the
largest
Spire
deployments,
are
over
a
million
agents,
so
they're
like
way
way
bigger
than
largest
kubernetes
deployments.
A
So
these
things
can
be
done,
but
we
tend
to
see.
Usually
these
really
large
deployments
go
for
like
two
three
four
trust
domains
kind
of
thing,
and
then
they
lean
on
kind
of
these
nested,
architectures
and
other
kind
of
tree-like
topologies
to
to
achieve
the
scale
and
and
reliability
that
their
deployments
need.
So
I
would
say:
I,
guess,
I,
guess
my
advice
would
just
be
like
hey.
You
know.
A
C
Yeah,
would
you
be
opposed
to
one
large
trust
domain
than
the
receiver
of
the
of
the
credential,
like
looking
at
the
latter
part
of
the
spiffy
ID
and
like
dissecting,
that,
because
it's
minted
in
so
like,
if
you
want
an
environmental
segmentation,
would
you
like?
Would
it
be
okay
to
have
one
large
domain?
But,
let's
say
a
receiver
is
only
in
like
a
staged
environment
and
they
could
look
at
it
a
bit
in
the
URI
to
say.
Oh,
this
is
staging
and
then
authorize
on
that.
A
You
definitely
want
to
check
the
workload
ID
I
mean
there
are
some
services
that
it's
okay
to
just
say
like
anything
from
staging,
but
in
general
you
really
want
to
check
the
workload
ID.
The
things
I
think
about
like
ntp,
DNS
things
that
are
like
centralized
Services.
You
know
that
make
sense
for,
but
I
would
recommend
like
the
the
trust.
The
trust
domain
name
should
be
part
of
your
authorization
policy,
but
so
should
the
workload
ID.
B
D
A
Value
of
Alexa
yeah
yeah,
one
of
the
problems
that
we
have
is
with
this
is
the
security
model.
So
Spire
is
designed
to
survive
node
compromise,
so
if
you
know
any
node
in
the
kubernetes
cluster
or
any
physical
note
or
otherwise
is
compromised,
the
security
model
is
such
that
you
know.
There's
an
agent
running
there.
A
The
security
model
is
such
that
you
cannot
just
take
control
of
this
agent
and
go
into
any
identity
you
want,
and
in
order
to
put
that
security
control
in
place,
you
kind
of
have
to
know
which
agents
are
authorized
to
Mint,
which
identities,
and
so
it's
difficult
to
kind
of,
say:
hey
this
agent
can
mint.
You
know
any
of
Foo
or
bar
namespace
identity,
because
you
still
kind
of
need
mappings
for
that
and
oftentimes.
A
A
You
know
in
in
kubernetes
we
have
what's
the
Spire
controller
manager,
which
is
a
controller
that
watches
deployments
as
they're
placed
and
will
automatically
manage
all
these
registration
entries
for
you
and
you
can
kind
of
annotate
or
label
these
deployments
with
specific
IDs
that
you
would
like
them
to
take
on,
and
so
some
of
this
overhead
is
is
negated
in
that
way,
but
I
think
there's
more.
We
can
do
and
right
now,
some
of
the
core
kind
of
core
design
and
security
principles
Aspire
make
it
difficult.
B
A
I
have
not
heard
of
this,
but
you
see
that
you
know
this
gcp
answer
was
written
by
Google.
Cloud
AWS
has
also
began
to
like
AWS
at
mesh
has
native
integration
with
Spire,
so
you
can
bring
your
spire
and
plug
it
into
AWS
app
mesh,
so
I
haven't
seen
Cloud
providers
directly
trying
to
pick
up
spiffy
off,
maybe
in
the
future
they
will,
but
we,
but
we
do
see
them
is
we
do
see
them
kind
of
engaging
and
making
this
story
better.
E
A
Part
of
this
stuff
is
saying
you
know:
here's
the
DNS
name,
you
are
expecting
webpki.
Some
of
the
clouds,
like
AWS,
for
example,
will
say
like
hey,
like
paste
in
the
thumbprint
of
the
actual
cert
that
you're
serving
over
there
and
we'll
validate
that
thing.
So
that's
how
the
trust
between
the
provider,
the
cloud
provider
and
the
oidc
on-prem
stuff.