►
From YouTube: SPIFFE Project Updates - Evan Gilman
Description
SPIFFE Project Updates - Evan Gilman
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
Yeah
so
tell
us,
he,
you
know,
did
a
a
really
great
kind
of
tour
of
you
know,
spiffy
and
the
capabilities
that
that
it
has
and
and
talk
a
little
bit
about
the
problems
that
we're
trying
to
solve
there.
You
know
there
is
this
other
project,
which
is
the
sister
project
called
spire,
that
is
the
soft,
a
software
implementation
of
spiffy.
A
So
what
I'm
here?
What
I'm
here
right
now
to
give
is
just
an
update
on
the
spiffy
project
alone.
So
not
not.
You
know
too
focused
on
spire
augustine,
we'll
give
a
update
on
this
fire
project
next.
So
this
is
more
just
about
kind
of
like
the
spiffy
specifications
and
and
all
the
things
going
on
in
the
spiffy
community
in
particular.
A
So
as
umer
mentioned,
my
name
is
evan
gilman,
I'm
a
maintainer
on
both
the
spiffy
inspire
projects.
I've
been
around
those
projects
for
quite
some
time
now,
almost
four
years.
So
it's
effectively
the
beginning
of
the
project
and
the
first
update
that
I
wanted
to
share
with
you
in
the
context
of
spiffy
today
is
about
the
what
we
call
the
technical
steering
committee
or
the
tst.
A
Space
and
we've
seen
them
firsthand
and
and
understand.
What
is
what
is
needed
in
order
to
solve
it
well,
but
over
time,
the
steam
gained
in
the
project,
the
contributors
and
everyone
else
kind
of
gained,
a
lot
of
understanding
of
the
problem,
space
and
and
what
works
and
what
doesn't
work.
And
so
over
time.
As
this
happened
and
adoption
grew.
You
know
that
that
original
role
of
the
tsc
became
less
important
and
they
became
less
engaged
on
a
day-to-day
basis,
but
still
there,
you
know
it's
still
this
group
this.
A
This
technical
steering
committee
group
has
still
kind
of
codified
us
in
the
project
governance,
but
in
this
state
that
they
were
in
where
they
weren't
being
relied
on
on
so
much
and
the
and
the
purpose
that
they
were
originally
trying
to
fulfill
is
not
not
as
important
as
it
used
to
be.
You
know
we
have
to
kind
of
ask
at
some
point.
You
know
is
this:
is
this
body
still
needed
and
if
it
is
still
needed,
then
then
what
is
it
needed
for
or
what
should
the
responsibilities
of
that
group
be?
A
You
know
we
have
some
rough
ideas
of
of
what
that
group
should
be.
You
know
it's.
First
of
all,
it's
the
only
group
with
that
kind
of
sits
over
the
top
of
both
the
spiffy
project,
the
spire
project
and
all
the
libraries
and
helpers
and
other
kinds
of
things
that
fall
under
this
big
spiffy
umbrella
and
because
of
that,
they're
positioned,
really
well
to
give
feedback
to
those
individual
projects
to
coordinate
across
them
and
also
to
do
like
gap
recognition.
A
You
know,
and
things
like
that,
where,
where
are
things
not
being
filled
that
we
need
to
fill
so
you
know,
we
think
that
this
group
is
still
valuable,
but
in
order
for
it
to
to
deliver
that
value
that
we
think
that
it
could
deliver,
we
need
to
formalize
a
lot
of
these.
You
know
responsibilities
that
I
just
described.
B
A
You
know,
so
the
group
that
we
have
serving
on
the
tsc
today
is
still
the
kind
of
original
group
from
the
very
early
days
of
spiffy,
and
once
we
have
this
new
charter,
you
know
we'll
be
in
a
position
to
say
look
is
this:
is
this
group
composition
still
ideal
and
and
if
not,
what
should
it
look
like
you
know?
Should
there
be
vendors
as
part
of
this
group?
Should
there
be
users
as
part
of
this
group,
both
of
those
things
or
none
of
those
things?
A
So
all
of
that
is
being
explored
right
now
and
we're
still
we're
we're
kind
of
in
the
early
early
stages
of
of
getting
all
of
this
stuff
codified
in
order
to
push
it
through.
The
the
existing
tsc
group
has
stepped
up
their
meeting
cadence
and
we
hope
to
have
that
that
work
wrapped
up
by
early
next
year.
A
Next,
we
have
a
couple
of
new
sigs
and
sig
stands
for
a
special
interest
group,
and
these
are
like
long-lived
groups
of
people
who
each
each
group
has
their
own
kind
of
specific
focus.
They
don't
necessarily
have
a
goal.
You
know,
there's
it's
not
like,
like
there's
no
real
kind
of
like
finite
life
cycle
applied
to
it.
It's
it's
more
to
kind
of
handle
the
ongoing
concerns
and
areas
of
focus
in
the
spiffy,
inspire
projects
and
and
the
related
sister
projects.
A
We
have
two
new
sigs
that
have
formed
in
the
last
six
months.
First,
we
have
one
that's
called
sig
community
and
the
focus
of
that
sig
is
the
nurture
and
growth
of
the
spiffy
community.
You
know
so
it's
it's
everything
from
you
know,
organizing
events
and
webinars,
educating,
educating
people
about
spiffy,
inspire
to
you,
know
the
blog
posts
and
twitter
accounts
and
all
that
kind
of
stuff
and
all
the
other
outreach
tools
that
we
use
to
to
communicate
with
the
community.
A
If
you
go
there
on
the
readme
you'll
find
information
about
about
all
of
these
recurring
calls
how
to
join
them.
The
mailing
lists
calendars,
all
that
kind
of
stuff.
So,
if
you'd
like
to
join
the
next
community
call,
you
can
find
information
there.
Similarly,
the
tsd
that
I
was
just
speaking
about
those
calls
are
also
public
and
the
call
information
can
be
found
on
the
readme
there.
A
Next,
we
have
on
the
estate
called
sigspire
and
that
zig
is
focused
on
primarily
aspire
development
and
not
not
necessarily
kind
of
like
day-to-day
stuff
and
not
really
kind
of
to
be
used
as
a
help.
Channel
more
is
kind
of
like
a
strategic
channel,
a
venue
where
we
can
discuss
various
proposals
to
the
spire
project
coming
in
from
the
community
to
give
a
high
bandwidth
discussion
between
the
maintainers
and
and
the
spire
users
to
share
thoughts
and
ideas
about
the
roadmap
and
the
things
along
those
lines.
A
A
There
are
a
lot
of
questions
about
federation
and
calcius
talk,
and
this
is
like
a
really
important
concept,
because
what
it
does
is
it
enables
communication
to
happen
across
these
different
trust
domains.
This
concept
of
different
authorities
or
different
sources
of
trust,
there's
always
going
to
be
more
than
one
and
maybe
not
in
the
same
company
organization,
but
between
companies
or
it
can
also
be
in
the
same
company
or
organization.
A
How
you
do
this
is
actually
like
loosely
described
in
an
existing
specification.
An
existing
spiffy
specification
called
the
trust
domain
and
bundle
specification
and
spire
actually
already
implements
spiffy
federation,
so
you
might
be
asking
like.
Why
do
we
need
a
new
document
for
this,
and
the
reason
is
because
the
existing
definition
that
we
have
in
the
trust,
domain
and
bundle
spec
is
not
very
strong.
A
So,
what's
left
in
this
work
so
far,
is
you
know
I
would
call
the
existing
like
what
we've
got
so
far
to
be
feature
complete.
It's
been
feature
complete
for
quite
some
time.
What
we,
what
we're
working
on
there
now
is
primarily
like
the
structure
of
the
document,
the
clarity
of
the
text.
You
know
making
sure
that
this
is
not.
A
You
know
all
the
questions
have
been
answered
and
that
kind
of
stuff-
and
so
we're
on
kind
of
like
this
last
push
right
now
to
get
it
out
the
door
and
get
it
done,
and
so
we've
stepped
up
the
cadence
of
that
call
as
well.
We
now
meet
weekly
again
if
you'd
like
to
get
involved
in
that
work,
you
can
find
the
call
information
at
the
github
repo
and
we
hope
to
be
done.
A
We
hope
to
be
done
with
the
spec
in
fairly
short
order
and
then
looking
forward
once
that's
completing
out
the
door.
We
have
a
couple
things
on
on
the
radar
for
six
spec
we've
received
a
lot
of
questions
from
the
community.
About
claims
currently
allows
claims
to
be
set
on
its
svids,
and
by
allow
I
mean
it
doesn't
really
like
forbid
them.
It
also
doesn't
say
that
you
have
to
use
them
and
it
also
doesn't
define
them.
So
what
we're
exploring
now
are
our
use
cases
to
try
and
figure
out.
A
Next,
there's
a
fairly
strong
desire
for
what
is
loosely
known
as
token
2.0,
and
you
know
if
I
were
to
describe
this,
it's
it's
it's.
Basically.
What
we're
looking
for
is
we're
looking
for
something
like
a
jot,
we're
looking
for
a
security
token
that
can
be
transmitted
at
layer
7
at
the
application
layer,
so
it
can
punch
through
proxies
and
things
like
that,
like
kelsey
was
talking
about,
but
we're
looking
for
something
with
with
with
better
properties.
You
know,
so
I
think
jot
falls
short
and
two
different
ways
right
now.
A
Another
thing
that
we're
that
we're
looking
at
is
how
we
can
delegate
signing
of
these
tokens
so
right
now
in
order
to
get
a
token,
you
have
to
go
to
a
centralized
authority
to
get
one
signed
for
you.
This
comes
with
performance
implications,
it
comes
with
availability,
implications
and
all
of
those
things
we
manage
and
inspire.
But
it's
not
ideal.
So
you
know
we're
exploring
methods
and
ways
that
we
might
be
able
to
have
those
minting
and
signing
operations
be
distributed
such
that
we
can
get
better
better
performance
and
availability
properties
out
of
it.
A
A
Is
pretty
hypothetical
at
the
moment?
You
know,
there's
still
a
lot
of
a
lot
of
exploration
to
be
done
there
and
we're
not
quite
sure
what
that's
gonna
look
like.
But
one
thing
we
know
is
that
there's
a
lot
of
interest
on
both
within
spiffy
maintainership
and
from
the
community
as
well
and
finally,
maybe
just
speaking
for
myself
a
little
bit,
I
think
we
could
take
a
short
break.
A
B
A
Development
work.
Well,
I
I
mentioned
that
the
federation
is
actually
already
available
inspire
and
the
implementation
that
spire
has
is
is
very,
very,
very
similar
to
what
the
spec
that
we're
working
on
now
and
if
you
go
and
look
at
the
existing
trust
domain
and
bundle.
Spec
you'll
see
that
we
actually
talk
about
how
federation
can
be
accomplished,
and
we
point
you
in
the
right
direction.
A
It's
hard
for
me
to
say,
like
I
said,
we
stepped
up
the
cadence
to
try
and
get
without
the
door
sooner
either
later,
but
we
are
rolling
into
the
holidays.
You
know,
so
it
would
be
nice
to
see
it
before
the
end
of
the
year,
but
we'll
see.
In
the
meantime,
I
recommend
you
go,
read
the
trust
domain
and
bundle
spec.