►
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.
SPIFFE: In Theory and in Practice - Evan Gilman & Andrew Harding, VMware
Please join us on the maintainer track to learn more about the SPIFFE vision, it's components, and how it fits into the cloud native landscape. In this session, we will do a short intro and deep dive on SPIFFE, followed by a Q&A. This will be an informal session - please bring your questions and use cases! We'll discuss recently completed works, where the project is headed, and how SPIFFE compares/contrasts to other seemingly similar options. Finally, stick around after the session for an extended meetup with the maintainers and other SPIFFE users.
A
A
A
If
you
have
any
questions
along
the
way,
anything
like
that,
please
feel
free
to
raise
your
hand,
you
know
we'll
stop
we'll
talk
that
kind
of
stuff
we're
also
we've
we've
also
doing
a
little
bit
different
presentation
for
you
today,
both
in
terms
of
of
material,
so
you'll
see
some
stuff
here.
You
probably
have
never
seen
with
regards
to
spiffy,
and
we
also
like
purposefully
did
not
practice
this,
because
we
wanted
to
feel
natural
and
and
personal.
B
Yeah,
so
that's
our
agenda
for
today
we're
going
to
talk
about
the
vision
of
spiffy
kind
of
give
the
high
level
overview.
You
know,
so
the
the
experience
level
of
the
audience,
the
attendees
is
probably
going
to
be
varied.
So
we're
going
to
give
a
give.
You
know
an
overview
of
the
spiffy
vision,
what
it's,
what
it's
around
for
like
what
it's
trying
to
solve,
where
it
fits
in
and
like
other
technology
stacks
and-
and
you
know
the
it's
it's
it's
a
part
of
the
puzzle.
B
Where
does
it
fit
inside
that
puzzle
and
what
other
pieces
are
generally
involved?
We're
going
to
give
an
overview
of
the
different
points
of
the
spiffy
specification,
including
like
a
deep
dive
into
the
spiffy
id
and
trust
domains
and
federation,
and
then
we're
going
to
kind
of
recap
on
the
you
know:
whole
picture
the
whole
the
whole
spiffy
surface
and
what
it
brings
to
the
table,
and
you
know
we
listed
q
and
a
at
the
end,
but,
like
evan
said,
we
want
to
keep
this
like
very
casual,
very
relaxed.
B
If
you
have
a
question
just
like
yell
raise
your
hand,
our
moderator
is
going
to
do
the
same
thing
for
the
virtual
attendees,
like
we
want
to
talk
about
the
things
you
want
to
talk
about,
so
we
have
some
materials
prepared,
but
you
know
we're
okay,
with
wherever
the
discussion
moves.
To
be
honest,
so
don't
be
afraid.
Raise
your
hand,
we're
here
to
talk.
A
A
The
main
challenge,
when
you
have
this
kind
of
stuff,
at
least
from
security
perspective,
in
my
opinion,
is
when
you
need
to
talk
across
these
boundaries
like
how?
How
exactly
does
that
occur
right
and
not
just
like
the
physical
communication
like
okay?
How
do
I
address
this
thing?
How
do
I
find
it?
How
do
I
discover
it?
How
do
I
authenticate
it?
A
Let's
do
a
scheme
that
that
is
not
like
anchored
to
a
particular
technology
or
a
particular
provider,
and
if
we
can
do
this,
just
provide
a
stable
notion
of
identity,
a
way
to
prove
identity
across
these
boundaries
right
all
of
a
sudden.
Everything
above
it
starts
to
stabilize
too
so
that
security
policy
we're
talking
about,
starts
to
stabilize,
because
you
have
this
stable
identifier
that
you
can
reference,
and
you
can
have
this
policy
go
across
multiple
platforms
without
having
to
change
or
manage
it
to
be
specific
to
one
place
or
another.
A
You
also
find
other
things
like
tracing
observability
debugging,
all
these
kinds
of
things
stabilize
as
soon
as
you
have
like
a
call
stack
that
traverses
these
platforms.
You
know
how
do
you
identify
each
one
of
those
service,
hops
and
threads?
So
you
once
you
have
this
kind
of
notion
of
stable
platform,
agnostic
identifier.
B
So
you
know-
and
we
will
talk
about
the
spiffy
specification
step,
we'll
get
down
on
the
details.
Ultimately,
like
I
haven't
mentioned
what
it
provides.
You
is
kind
of
like
this
uniform
identity,
substrate
and
you're,
going
to
get
a
cryptographically
verifiable
document,
and
that's
that's
what
spiffy
brings
you.
B
So
spiffy
is
just
like
one
small
piece
of
this
puzzle.
We
bring
the
authentication
layer,
we
bring
the
identity
layer
to
to
to
the
to
the
puzzle,
and
you
know
there's
things
that
you
have
to
do
on
top,
that
you
have
to
actually
use
that
identity.
So
sometimes
you'll
have
workloads
that
are
spiffy,
aware
those
can
talk
directly
to
the
spiffy
workload
api
and
obtain
their
materials.
And
then
you
know
they
themselves
will
engage
in.
B
You
know
mutual
tls,
for
example,
to
establish
that
authenticated,
secure
channel
to
another
workload
or
in
your
control
plane.
You
might
decide
to
to
offload
that
tls
connectivity
to
you
know
a
proxy
sidecar
like
envoy
or
ghost
tunnel
or
whatever
you
know,
and
so
we'll
bring
the
authentication
with
spiffy.
You
need
to
actually
use
those
documents
and
do
do
the
secure
connections
in
between
workloads.
You
can
layer
authorization
on
top
of
that,
whether
that's
with
opa
or
with
something
else
right.
B
You
know
you
can
you
can
bring
on
protocols
like
grpc.
You
know
the
right
on
top
of
that
tls
channel,
you
know
and
do
secure
workload
communications
that
way,
but
yeah
it's
up
to
you
and
there's
a
lot
of
flexibility
in
what
you
end
up
doing
with
the
identity
you
receive
from
from
a
spiffy
implementation.
A
I
I
would
just
quickly
add
to
real
kind
of
really
important
part
on
this.
That
is,
as
we
get
questions
about
often
is
authorization
in
particular
the
spiffy
project,
cause
authorization
kind
of
out
of
scope
for
what
we're
doing
right.
What
we
are
doing
is
we're
providing
this
kind
of
stable,
uniform
identity
that
then
you
can
build
authorization
on
top
of
right,
so
it
is
a
whole
nother
problem
space
that
is
very,
very
deep
in
its
own
right.
A
We
have
a
bit
of
a
slide
on
this,
but
not
exactly
so
I'll,
just
say
quickly.
Now:
spiffy
aims
to
identify
what
we
call
a
workload
right.
So
spiffy
is
like
cryptographic,
identity
for
workloads.
What
is
a
workload?
And
you
know
it's
it's
a
bit
of
an
overloaded
term
and
an
overloaded
question
as
well.
A
You
know,
I
think
different
different
people
on
different
shops
have
different
requirements
for
that.
The
most
common
thing
that
we
see
is
we
see
spiffy
identify
like
on
the
service
right.
So
if
you
could
think
that
I
have
a
kubernetes
cluster
and
there's
a
deployment
and
there's
you
know
five
pods
servicing
this
deployment,
you
know
the
typical
pattern
that
we'll
see
is
like
a
spiffy
id
will
be
assigned
to
that
deployment
and
the
pods
within
that
deployment
will
all
receive
the
same
spf
id.
A
A
They
do
this
for
auditing
and
observability
purposes,
forensics
things
like
that,
but
it
does
make
things
a
little
bit
more
complicated.
So
I
I
hope
that
answers
the
question.
What
we
aim
to
identify
is
we
have
to
identify
workloads.
However.
However,
you
view
that-
and
we
have
some
later
science
talking
about
ways
that
you
may
like
naming
conventions
and
ways
that
you
may
arrange
this
based
on
what
you're,
what
you're
trying
to
address.
A
Okay,
my
turn:
what
is
this
okay,
so
yeah?
This
is
the
the
overview,
the
spec
overview,
so
we're
just
gonna.
I
think
kind
of
run
through
a
few
like
the
really
important
ones
here,
just
to
kind
of
orient
everyone
how
they
fit
together
and
then
we're
gonna
choose
a
few
in
deep
dive.
So
the
first,
the
first
spec
here
is
the
spiffy
id
spec
is
like
the
most
basic
one.
A
C
A
And
then
there's
the
svid
and
the
svid,
it
stands
for
spiffy,
verifiable
identity
document,
and
this
is
the
way
that
you
prove
identity
to
someone
else
right.
It's
usually
like
a
signed
document
of
some
sort
with
a
spiffy
id
in
it
right.
Maybe
there's
a
public
key
in
there
too,
that
the
workload
holds
on
to
the
the
we
try
our
best
to
not
like
reinvent
anything
here
for
a
number
of
reasons.
Number
one
inventing
new
documents
like
this
is
difficult
number
two.
A
It
requires
like
a
net
new
investment
from
the
users,
so
we
try
to
choose
documents
that
are
already
widely
adopted
and
well
understood,
work
as
much
as
we
can
with
off-the-shelf
software
and
things
like
that.
So
the
two
supported
svid
types.
We
have
right
now
x509
and
jot,
and
you
know
I
I
don't
know
how
many
people
are
familiar
with
these
two
things,
but
x59
is
generally
useful
for
for
tls.
A
A
Then
we
have
this
document
that
has
the
name
in
it
and
there's
a
signature
over
it.
Well,
that's
cool.
All
my
workloads
are
supposed
to
get
one
of
the
things.
How
do
they
get
it?
So
that's
that's
what
the
workload
api
is
all
about.
It's
api
that
is
like
a
node
local
api
and
this
api
is
actually
unauthenticated,
and
this
is
like
a
super
critical
aspect
of
it,
because
what
that
does
is
it
allows
a
workload
to
pop
up
without
having
any
prior
injected
secret
or
token
or
anything
else.
A
This
workload
can
kind
of
pop
up
and
say
here
I
am
and
the
spiffy
magic
will
kind
of
figure
out.
Okay,
I
know
who
you
are:
here's
your
spiffy
id.
You
know
you're
off
to
the
races,
let's
see
what
else
about
the
overcoat
api,
so
I
guess
the
the
main
reason
that
we
have
a
thing
like
this
right.
People
ask
you
know
why
don't
you
just
put
them
on
desk
or
why
I
have
this
api
and
all
this
jazz
and
I
think,
there's
two
primary
reasons
for
that.
A
The
first
is
around
structure
and
rotation
and
control.
So
you
know
we
provide
over
this
workload
api
as
we
provide
you,
your
svid.
We
may
provide
private
key
associated
with
those
essays
like
the
case
of
x509
right,
and
we
also
provide
the
ca
search
that
are
keys
and
key
material
that
is
needed
to
validate
other
asvids
and
there
and
that
key
there
may
be
multiple
keys
if
you're
talking
about
multiple
domains
and
things
like
this
and
so.
A
If
you
want
to
put
them
on
disk,
it
gets
complicated
because
now
you're
into
the
world
of
like
ad
hoc
naming
and
what
you
know,
how
do
you
name
the
files?
How
do
you
group
these
things
together?
Is
there
a
directory?
Is
there
this?
What
happens
when
you
want
to
rotate
them?
These
things
rotate
all
including
root
cas
all
rotate
and
if
you've
ever
worked
with
epoll
or
anything
like
that,
you'll
know
pain
there.
A
A
So
this
whole
spiffy
thing
is
supposed
to
be
platform
agnostic
right.
If
we
tie
this
the
retrieval
of
these
s-vids
to
a
platform-specific
api
like
a
kubernetes
api
or
something
like
that,
then
all
of
a
sudden
who
loses
this
portability
that
we're
trying
to
build
in
the
first
place
right
so
the
portability
is,
is
another
major
major
aspect
of
this
respect.
Do
you
want
to
do
the
rest?
I've
been
talking
a
lot.
C
B
B
So
if
you
look
at,
if
we
we'll
get
into
the
details
of
the
spiffy
id,
but
spiffy
idea
is
essentially
composed
of
two
parts,
it
has
a
trust
domain
and
it
has
some
sort
of
entity
underneath
that
trust
domain
and
the
idea
is
that
a
trust
domain
itself
is
this
cryptographic
boundary
with
a
set
of
unique
signing
authorities
within
it
for
issuing
the
identities
from
that
trust
domain,
and
so
we
have
a
specification
around.
Like
you
know,
what
does
the
trust
domain
name?
Look
like
like
what
you
know
what
sort?
What
is
this?
B
A
B
Okay
and
then
the
last
kind
of
specification
we'll
talk
about
today.
This
is
sometimes
we
call
the
federation
api,
the
it's
actually,
you
know
just
federation
specification
within
spiffy
and
and
that
defines
what
we
call
the
bundle
endpoint,
and
this
is
an
endpoint
that
a
party
can
talk
to
to
obtain
the
spiffy
bundle
for
a
given
trust
domain,
and
this
is
to
empower
federation
right.
So
you
can
get.
B
You
know,
multiple
trust,
domains
obtaining
the
spiffy
bundles
for
each
other
and
then
they're
able
to
authenticate
the
identities
that
are
minted
in
in
you
know
in
the
other
trust
domain.
So
we,
this
is
a
pretty
basic
specification,
we'll
get
into
the
details
of
of
that
later,
but
it's
yeah,
it's
not
anything
super
complicated,
it's
basically
just
an
http,
endpoint,
https
endpoint!
It's
got
to
be
authenticated.
It
must
be
authenticated
that
you
can
talk
to
to
get
this
bundle
material.
So
this
specification
is
all
about.
B
So
I'll
take
this
one,
since
I
already
kind
of
talked
about
it
already.
This
is
your
spiffy
id
right,
so
it's
a
uri.
It's
it's
pretty
much
like
a
username,
except
for
your
workload
or
your
service,
and
it
is
scoped
by
a
trust
domain
and
like
we
talked
about
before
the
trust
domain
is
going
to
going
to
be
the
have
the
set
of
authorities
that
are
going
to
be
signing
identities.
You
know
for
that
trust
domain
this
this
ur
is,
you
know
the
uri
spec.
B
I
don't
know
if
you've
ever
dug
into
it.
It's
ginormous,
it's
huge!
It's
it's
a
mess,
yeah
way
bigger
than
it
should
be,
and
there
are
some
interesting
things
that
fall
out
of
the
the
the
inherent
complexity
of
that
specification
and
what
so,
we've
tried
to
take
this
uri
spec
and
carve
out
a
nice
safe
space
for
a
spiffy
id.
Within
that
specification
we
did
similar
things
for
x,
509
and
jot.
B
We
don't
allow
the
full
range
of
expression
on
the
characters
that
are
allowed
inside
uris,
but
you
know
a
spiffy
id
is,
is
really
kind
of
this
thing
that
you
get
you
get
to
decide
for
yourself
within
your
organization,
what
makes
sense
and
like
what
this
id
should.
Look
like.
Okay,
so
after
you
get
that
that
spiffy
scheme
on
there-
and
you
define
your
trust
me
and
after
that,
it's
it's
anyone's
business.
B
What
you
do
right
so,
but
we
do
have
some
some
guidance
as
we've
seen
people
craft,
spiffy
ids
over
the
years
and
and
maybe
take
some
routes.
You
know
we
formed
some
opinions
and
and
and
maybe
some
guidance
around
how
you
might
want
to
shape
your
spiffy
ids
in
order
to
avoid
a
certain
class
of
problems.
A
All
kinds
of
creative
uses
we've
seen
I'll
do
this
when
I
get
outside
so
so,
we've
got
a
couple
of
these.
We
get
a
lot
of
questions
around
this
like
what
how
do
I?
How
do
I
name
things
like
turns
out?
That's
really
hard,
so
I
I
would
say
I
thought
it
would
be
useful
too,
to
kind
of
provide
a
couple
like
pro
tip
best
practice
type
things
here.
A
A
You
know
in
the
spec
itself
we
have
a
section
that
is
like
yeah,
like
the
the
path
of
this
thing
can
be
whatever
you
want,
whatever
makes
sense
for
your
org,
and
we
gave
some
examples
of
how
how
you
might
do
it.
One
of
those
examples
there
just
has
like
a
guide.
It's
just
like
the
trust
domain
and
then
a
good
after
that,
and
then
you
know
the
intent
is
well.
A
You
can
do
this
if
you
want
and
you
go
use
that
guide
to
look
something
up
or
whatever,
but
you
know
you
lose
that
you
lose
that
nice
property
of
like
it's,
it's
readable
like
I
can
look
at
it
and
and
like
have
meaning
to
it.
You
know
espec.
So
all
those
cases
I
was
talking
about
before
around
observability
and
things
like
that
kind
of
go
away.
If
you,
if
you
go
in
that
direction,
so
you
want
to
kind
of
of
keep
it
readable.
A
You
don't
want
to
like
overload
it
with
a
bunch
of
data.
What
I
see
people
do
quite
often
is
that
they
they
say
like
well.
I
have
these
policies
that
I'm
trying
to
enforce
and
they're
like
super
expressive
and
there's
like
15
different
pieces
of
information
that
I
need
in
order
to
like
evaluate
this
policy
right
and
so
then
they
go
off
and
say:
okay.
Well,
what
should
my
naming
scheme
be?
Then?
A
This
is
like
real
slippery
slope
and-
and
I
think
that
the
the
you
will
always
have
this
idea
right.
You'll
always
have
this
idea
that
you
know
you're
making
decisions
based
on
the
shape
of
the
spiffy
id
right,
not
just
like
some
opaque
string,
but
I
I
would
strongly
recommend,
like
strike
a
balance
with
that
data.
You
know,
don't
don't
try
to
overload
it
with
a
bunch
of
stuff
that
you
may
not
need
may
need,
may
not
need.
A
Instead,
what
you
want
to
do
is
you
want
to
choose
like
the
most
basic
things
that
are
going
to
be
like
super
super
static,
like
things
that
are
not
really
going
to
change
much
they're,
like
innate
properties
of
this
of
this
workload
or
thing
you're
trying
to
address
right.
That's
what
I
would
recommend
to
include
and
and
you'd
kind
of
draw
the
line
there
and
things
that
are
more
dynamic.
You'll
want
to
put
elsewhere
right.
B
You
know
where
you
have
unless
you,
unless
you're
really
good
at
like
centralizing,
authentication
or
authorization,
then
you
have
a
bunch
of
processes
like
receiving
these
safety
ids
and
trying
to
like,
pluck
out
different
parts
and
apply
policy
to
these
different
parts.
It
gets
very
complicated
you
you
end
up
getting
really
coupled
to
the
authorization
logic,
and
if
you
don't
centralize
it,
then
now
you
you've
got
a
bunch
of
people
doing
this.
B
Today
you
know
organization
who
had
you
know,
gone
down
one
route
with
their
spiffy
id
with
their
naming
and
they'd
gone
a
little
too
complex
and
when
they
decided
to
like
bring
that
back
in,
it
was
a
large
amount
of
effort
to
try
and
like
shift
and
migrate
back
to
a
simpler
scheme
which
ended
up
being
better
for
them
in
the
long
run.
But
it
takes
effort.
B
So
if
you
get
the
more
specificity
you
like
shoving
these
ids,
you
know,
for
example,
you
could
go
hog,
wild
and
and
start
throwing
like
network
locator
information
inside
the
spiffy
idea
of
where
this
workload
is
not
what
this
workload
is
and
if
you
ever
go
and
change
where
that
workload
lives,
then
something
like
the
idea
is
changing
and
you've
got
to
like
update
your
authorization
policy,
etc.
So
you
really
want
to
focus.
A
Yeah-
and
I
would
I
would
even
add
that
you
know
in
terms
of
like
pattern
and
convention,
you
know
I
one
of
the
things
that
we've
seen
is
that
istio
being
like
very
early
spiffy
adopter
chose
naming
convention
that
worked
for
them
right
and
that
naming
convention
was
the
you
know,
slash
sa
service,
account
value
or
ns
name,
space
value,
slash
s,
service,
account,
value
and
most
people.
A
lot
of
people,
I
would
say,
have
become
familiar
with
spiffy
through
istio
and
the
inten.
A
The
impression
that
has
been
left
is
like
this
is
the
canonical
way
to
format
a
spiffy
id
right,
and
that's
that's
really.
I
think
an
important
point
to
understand
is
like
there's
not
canonical
way,
and
it
doesn't
mean
that
you
cannot
like
borrow
those
patterns.
You
know
for
one
reason
or
another,
like
you
absolutely
can,
but
you
should
also
understand
that
those
patterns
are
not
going
to
work
for
everyone
right.
A
You
pluck
a
workload
out
of
kubernetes
and
drop
it
somewhere
else.
What
meaning
does
this
convention
have
anymore
right?
Namespace
of
service
account,
so
it
should
be
understood
that
the
convention
that
you
choose
will
not
apply
universally
it'll
make.
It
may
be
good
for
you,
but
it
may
not
be
good
for
next
person.
That
means,
when
you
want
to
talk
to
next
person
with
spiffy
you're,
going
to
get
an
id
that
is
shaped
totally
different
than
the
one
that
you're
used
to
right,
and
that
is
that
is
a
problem.
A
So
I
I
think
I
saw
you
there
call
I'll
get
you
right
in
a
second.
So
that's
like
understand
that
this
is
a
thing
that
is
not
going
to
apply
to
everyone,
and
so,
when
you
build
authorization
on
top
of
spiffy,
you
want
to
strive
for
not
like
trying
to
pluck
this
thing
apart
and
make
all
this
sense
of
it
right.
Instead,
you,
you
should
really
try
to
strive
for
like
a
straight
string.
A
Compare
if
possible,
it
is
like
the
safest
way
to
do
this,
and
it
is
also
the
way
that
that
will
ensure
that,
like
in
the
future,
you
don't
run
into
bad
interrupt.
Problems
like
everywhere
expects
this
convention,
but
now
I
need
to
federate
with
a
business
partner.
They
have
a
totally
different
convention.
Okay.
Now
it's
really
simple
for
me
to
just
say
in
addition
to
my
regular
policy,
also
accept
this
explicit
spiffy
id
right,
so
you
can
kind
of
stay
out
of
trouble.
A
Well,
I
think
that
addressing
a
node
was
kind
of
more
of
a
spire-ism.
You
know,
I
think,
by
far
and
away
the
most
popular
convention
is
the
one
that
istio
set
forth
years
back.
I
I
I'm
hesitant
to
say
that
that
is
like
the
best
one.
It's
just
the
most
popular
one,
you
know,
and
and
istio
has
had
his
fair
share
of
problems
of
of
communicating
with
workloads
that
are
not
on
kubernetes
because
of
exactly
this
thing
and
they
have
got.
A
A
It's
not
to
say
that
the
convention
is
bad.
It's
just
to
say
that
if
you,
if
you
choose
a
convention
and
then
go
down
the
path,
thinking
like
this
is
my
convention
right.
That's
when
you
start
to
to
get
into
trouble.
It
should
be
that
you
just
understand
that
there
can
be
spiffy
ideas
that
do
not
conform
to
your
convention
and
that
your
stack
should
be
equipped
to
handle
when
that
time
comes.
B
Five
slides
left
and
two
and
a
half
minutes
so
seriously
yeah.
So
I
think
this
next
one
will
skip.
We
really.
We
talked
about
trust
domains.
I
think
at
length
this
slide
really
quick
was
just
kind
of
showing
you
kind
of
kind
of
what
the
spiffy
bundle
looks
like
it
doesn't
have
all
the
information
in
the
spiffy
bundle.
Specification
like
this
is
just
a
standard.
A
So
there's
we
saw
trust
domain
and
a
trust
domain
kind
of
usually
has
like
this
one-to-one
relationship
with
pki.
If
you're
talking
about
a
trust
domain,
it
probably
has
its
own
pki
that
bundle
that
you
saw
is
kind
of
how
we
capture
those
keys.
And
so,
if
you
have
the
bundle
for
a
trust
domain,
then
you
can
validate
identities
from
that
trust
domain
right.
So
then
the
question
is:
how
do
you
get
those
bundles?
How
do
you
get
those
keys
for
validation?
A
That's
what
we
call
federation
or
orbit
one
point.
So
here's
like
quick,
quick
diagram
of
kind
of
the
way
that
it
works,
and
we
it's
really
really
basic.
We
just
swap
these
bundles
across
and
we'll
have
a
next
slide
on
exactly
how
that
happens,
but
once
these
two
swap
their
bundles,
then
they
can
exchange
us
fibs
and
be
validated
right.
This
is
actually
how
it
works.
It's
super
basic.
A
Okay,
he
said
we
got
five
minutes
back
there,
so
so
so
it's
actually
not
very
complicated
and
you,
and
if,
if
you're
familiar
with
odc
jwks,
you
may
have
noticed
that
these
bundles
are
jw
ks
formatted.
So
it's
the
same
spec
that
oidc
uses
it's
literally
just
a
json
document,
so
each
one
of
these
trust
domains
exposes
this
hdps
endpoint
that
serves
up
this
json
document
and
so
long
as
you
know
how
to
find
it
and
authenticate
it.
A
You
can
pull
the
sucker
down
and
you
can
validate
identities
from
that
other
trust
domain
and
the
bundle
slide.
Can
you
back
up?
Actually,
if
we
have
some
time
back
up
for
pun
to
the
bundle
slide
yeah,
so
you
see
here's
a
spiffy
refresh
hint
set
onto
the
bundle.
This
is
supposed
to
give
the
caller
an
idea
of
when
they
should
check
back,
because
we
mentioned
that
these
things
rotate
and
spire
in
particular-
has
support
for
root
rotation
all
the
way
down
to
leaf.
So
they
do
change
over
time.
A
A
You
can
slide
back
forward
now,
yeah
yeah,
so
so
that's,
basically
it
right
and
you'll
have
software
in
each
one.
That
kind
of
is
configured
to
go,
hit
these
things
and
bring
them
down
and
distribute
them
now.
The
way
that
these
bundles
are
distributed
through
your
infrastructure
is
like
not
defined
by
spiffy
right.
So
you
know
you
build
some
software
that
goes
out
and
does
this
automation.
It
goes
and
grabs
this
bundle
and
it
pushes
it
down
your
workload.
Some
and
your
workloads
pick
it
up
and
use
it
right.
A
The
thing
that
we
do
define
as
that
workload,
api
right,
so
the
api
that
the
workloads
hit
to
get
these
bundles
and
their
svids
and
all
the
other
stuff,
but
how
the
plumbing
between
that
workload,
api
and
this
stuff
up
here
is
on
that.
That's
the
spiffy
implementation
really
right!
So,
if
you've
ever
heard
of
spire
as
far
as
50
implementation,
it
does
all
that
plumbing
from
you
know,
bundle
and
signing
all
the
way
down
to
your
workload
and
providing
that
api
and,
like
connecting
all
of
these
dots
right.
A
Finally,
the
way
that
you
do
spiffy
auth
it's
important-
we
didn't
talk
about
that.
I
don't
think
so
when
you
run
into
one
of
these
s-vids
right
and
you
want
to
validate
it
like
the
very
first
thing
that
you
do.
Is
you
look
at
the
spiffy
id
there's
something
right
here,
so
these
are
like
workloads?
If
you
will
so
we
have
like
a
food
trust
domain
and
the
bar
trust
domain
right.
So
when
somebody
calls
you,
let's
say
tls
and
they
present
you
a
client
cert.
A
The
very
first
thing
that
you
do
is
you
look
at
the
spiffy
id
and
you
say:
okay,
what
trust
domain
is
this
from
and
then
you
say:
okay,
do.
I
know
this
trust
domain.
Do
I
recognize
it
and
the
way
that
you
do
that
is
say
well.
Do
I
have
a
bundle
for
this
thing
right
and
if
you
do
have
a
bundle,
then
you
know
how
to
authorize
authenticate
and
if
you
don't
then
you're
not
federated,
then
this
thing
is
not
not
going
to
authenticate
them.
A
So
this
is
one
thing
that
we
have
been
kind
of
like
pushing
forward
slowly,
because
that
type
of
validation
is
not
something
that
is
found
in
a
lot
of
places.
We
have
spiffy
libraries,
which
will
do
this
kind
of
validation
for
you
on
tls
and
jot
and
other
things,
but
envoy
was
recently
grown
support
to
do
this
kind
of
validation
as
well
through
tls
custom
validator.
A
B
B
A
B
Using
to
pull
the
bundle
from
each
other
and
that'll
establish
our
federation,
you
got
workloads
inside
each
trust,
domain,
they're,
connecting
to
the
workload
api
and
over
that
workload,
api
they're
obtaining
their
svids
and
their
bundles.
You
know
not
only
the
bundle
for
their
own
trust
domain,
but
because
these
two
are
federated,
it
can
receive
the
bundle
for
the
other
trust
domain.
B
You
know
and
then
those
workloads
within
the
trust
domain
can
can
authenticate
with
each
other
over
mtls
right
and
because
the
federation
workloads
across
trust
domains
can
also
authenticate
each
other
over
mtls,
and
so
you
know,
and
those
aspects
contain
the
spiffy
ids
of
the
workloads
so
that
we
have
a
strong.
You
know
uniform
notion
of
identity
that
we
can
again.
This
is
just
a
piece
of
the
puzzle
we
can
like
layer,
authorization
on
top
of
and
other
things
anything
else.
You
want
to
say
about
that.
Evan.
A
I
think,
on
one
of
the
earlier
slides
we
had
some
stuff
on
like
how
to
think
about
modeling
trust
domains.
Yeah.
I
don't
know
we're
probably
like
a
little
out
of
time
for
that,
but
like
30
seconds
yeah,
just
leave
that
one
on,
I
guess
and
yeah
strong
security
isolation.
I
can
be
summed
up
that
way,
right
like
any
time
that
you
have
that
you
have
a
security
domain,
that
you
want
very
strong
isolation
between
the
two.
A
A
A
So
yeah,
I
think
that's
it.
You
want
to
put
up
the
last
slide.
Actually,
the
last
slide
has
some
learn
more
stuff
yeah.
So
we
have
website,
of
course,
and
github
repo,
and
our
slack
is
super
active.
I
highly
recommend
if
you're
interested
continue
conversation
join
us
there.
All
maintainers
hang
out
there
aspire
developers
hang
out
there
all
sorts
of
folks,
and
so
yeah
we've
tried
our
best
to
to
not
do
any
spire
talk
we're
actually
both
fire
maintainers
as
well.
It's
sometimes
difficult
to
wear
both
hats.