►
From YouTube: Scrutinizing SPIRE to Sensibly Strengthen SPIFFE Security- Matt Moyer, Heptio & Evan Gilman, Scytale
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! 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
Scrutinizing SPIRE to Sensibly Strengthen SPIFFE Security - Matt Moyer, Heptio & Evan Gilman, Scytale
SPIFFE (Secure Production Identity Framework For Everyone) is an open source standard for giving identities to services in dynamic and heterogeneous environments. SPIRE is an implementation of SPIFFE that provides a solid bedrock for secure infrastructure -- at least that's what we hope! In this talk, we'll attempt to rationalize that notion. We’ll introduce a formalized threat model for SPIRE and show how it helps suggest practical security improvements. First, we'll introduce the components of SPIFFE and show how applications can use it to build secure service-level authorization systems. Then we'll show how the components of SPIRE work together to enforce useful security properties. Finally, we'll walk through our findings and show some of the incremental improvements we've made to strengthen SPIRE.
To learn more: https://sched.co/GrZZ
A
Hello,
everybody
how
you
doing
today,
it's
quite
out
there
yeah,
so
we're
here
to
talk
a
little
bit
about
the
spiffy
inspire
project.
Some
security
assessment
mat
myself
and
a
few
others
did
over
the
last
year.
So
my
name
is
Evan
Gilman
I'm,
an
engineer
at
Scytale
and
I'm
working
actively
on
the
spiffy
inspired
projects
pretty
much
full-time.
Now,
there's
previously
enough
sorry,
a
pager
duty,
doing
automation,
traffic
management
and
things
along
those
lines
and
was
a
network
engineer
in
academia,
previous
life
and
I'm.
Here
with
Matt
today,
my.
B
B
So
if
you
do
know
about
spiffy,
you
know
that
security
is
one
of
the
key
components
for
why
you
would
use
Biffy.
It's
not
the
only
one,
but
it's
one
of
the
one
of
the
key
ones.
So
what
we
really
want
to
do
is
understand
what
are
the
expected
security
properties
of
a
spiffy
system
and
then
how
close
are
we
to
sort
of
meeting
those
expected
properties?
Where
are
there
gaps.
A
Yeah,
it's
definitely
an
important
thing
to
get
right,
so
in
doing
so,
it's
really
important
to
validate
these
decisions
early
on
before
it's
too
late
to
correct.
So
we
want
to
make
sure
we're
kind
of
just
heading
in
the
right
direction
here.
In
order
to
do
this,
we
embarked
on
a
somewhat
lengthy
security
assessment
where
really
we
were
just
interested
in
studying,
like
this
with
aspire
security
model,
trying
to
describe
its
properties
and
then
to
analyze
the
overall
design
for
weaknesses
in
delivering
on
those
properties.
A
This
effort
was
kicked
off
in
December
2017
I
was
led
by
Justin
coppice
who's
here
today
and
was
participation
from
myself
for
Matt
and
from
Enrico
were
community
members
who
raised
their
hand
and
volunteered
to
put
a
lot
of
time.
I
put
a
lot
of
time
in
basically,
and
the
goals
of
this
effort
were
first
to
understand
the
expected
security
properties
of
us
with
the
implementation,
like
what
properties
are
important,
giving
given
Spivey's
mission
in
a
second,
we
wanted
to
explore
different
classes
of
vulnerabilities
like
given
the
properties
that
we
know
are
important
to
spiffy.
A
So,
of
course,
like
any
well
scope
project,
you
had
a
couple
of
non
goals
as
well.
We
were
really
interested
in
finding
like
specific
implementation,
vulnerabilities
things
like
bugs
and
authorization
checks,
etcetera
or
kind
of
out
of
scope
for
this
assessment.
Instead,
we
wanted
to
focus
on
the
overall
design
and
architecture
of
the
spire
system
and
the
specification
step
we
were.
We
also
were
not
interested
in
like
formally
proving
anything.
So
this
is
definitely
not
a
formalized
threat
model,
as
some
people
might
be
familiar
with.
B
Sure
so
we're
gonna!
This
is
we're
gonna
go
through
today.
What
we
really
hope
is
that
when
you,
when
you
leave
this
talk,
you're
going
to
feel
comfortable
talking
about
what
are
the
expected
security
properties
of
spiffy
and
whether
that
means
you
feel
more
comfortable
with
an
existing
installation
that
you're
doing
or
you
feel
more
comfortable,
proceeding
down
the
path
of
adopting
spiffy
in
some
capacity
or
maybe
understanding
this
biffy's
expected
security
properties.
Don't
work
for
your
use
case.
B
Any
of
those
is
fine,
so
we're
gonna
start
off
with
a
quick
intro
to
what
is
spiffy.
How
does
spiffy
work
also,
what
is
spire,
how
to
spire
work
I'm
going
to
talk
about
what
are
the
expected
properties
of
the
system?
This
is
sort
of
the
meat
of
the
presentation.
We're
gonna
talk
about
how
we
came
up
with
that
list.
What
was
our
methodology
and
then
finally,
Evans
gonna
present
some
findings.
A
Spiffy
stands
for
secure
production,
identity
framework
for
everyone
right
and
what
spiffy
actually
is
a
specification
more
accurately.
It's
a
specification
set
right,
it's
more
than
one
specification,
and
the
goal
of
these
specs
is
to
provide
this
idea
of
notion
of
interoperable
and
portable
worklet
identity,
which
is
platform
agnostic,
and
in
order
to
do
that,
we
define
an
identity
namespace
and
we
Devine
like
a
set
of
documents
and
interfaces
and
together
those
things
are
used
to
publish,
consume
and
authenticate
these.
These
were
clearly
identities,
but
I.
A
Think,
like
the
the
most
important
thing
to
kind
of
drive
home
here
is
our
spiffy
is
not
code.
Spiffy
is
simply
a
specification.
So
let's
take
a
look
at
some
of
the
major
components
of
spiffy
and
the
first
is
what
we
call
the
spiffy
ID.
That's
basically
a
structured
string,
you
can
see,
is
it's
a
URI
and,
and
it
can
be
kind
of
thought
of
as
like
a
username
for
workloads,
that's
divided
into
two
parts.
A
This
first
part
here
is
called
the
trust
domain
and
the
second
part
is
is
called
the
path,
and
so
in
this
example,
the
trust
domain
is
prod
example,
and
foo
is
the
path.
A
trust
domain
nominally
represents
an
issuing
authority.
So
usually,
what
you
see
is
a
trusted.
Man
is
generally
tied
to
a
set
of
signing
keys
and
any
identity
issued
within
this
trust
domain
is
signed
and
authorized
by
this
issuing
authority.
A
Next,
we
have
something
called
a
speck,
verifiable
identity
document,
this
s
food
for
sure-
and
these
are
each
are
basically
just
digitally
signed
documents
that
prove
ownership
of
a
particular
identity
or
a
spiffy
identity.
There's
already
lots
of
documents
out
there
and
in
common
use,
and
so
there's
a
really
no
need
for
speed
to
invent
new
ones.
A
A
Finally,
we
need
a
way
to
kind
of
standardize
the
way
that
these
essays
are
issued
and
consumed
like.
Where
do
they
come
from?
How
do
I
get
one?
Should
I
find
it
on
disk
where,
where
can
I
locate
my
identity
and
identity
documents
and
so
to
solve
this,
but
he
includes
a
specification
called
the
spiffy
workload
API
the
workload
API
is
a
node
local
API
that
workloads
use
to
retrieve
their
identity
and
their
documents.
And
crucially,
this
API
is
is
not
authenticated,
and
this
is
really
really
important
because
it
solves
this.
A
This
bootstrap
problem,
some
people,
call
it
the
secret
0
problem
or
secure
introduction,
but
it
allows
workloads
to
have
no
a
priori
knowledge
of
their
identity.
So
you
basically
deploy
a
workload.
The
first
that
comes
up
the
first
thing
that
does
is
it
talks
to
this
API
doesn't
have
to
know
anything
else.
The
API
says:
I
know
you
here
your
keys
and
here's
your
cert
and
you're
off
to
the
races.
A
So,
in
summary,
there's
three
major
components
in
this
specification
set
as
it
exists
today.
There's
a
spiffy
ID,
there's
these
s,
bibs
these
documents
and
then
there's
this
workload
API
part
and
together
these
things
form
this
kind
of
foundational
identity
layer
that
can
span
heterogeneous
software
stacks
and
platforms,
because
they're
not
fundamentally
bound
to
those
things,
they're
independent.
A
So
now
that
we
understand
a
little
bit
more
about
what
spiffy
is
have
a
quick
look
at
spire
spire
is
also
an
acronym.
It
is
short
for
the
spiffy
runtime
environment
as
fire
is
an
open-source
implementation
of
the
spiffy
specification
set.
It's
basic
mission
in
life
is
to
light
up
that
workload,
API
and
and
also
make
it
manageable,
and
so
to
do
this.
A
A
So
basically
how
that
works
is
that
when
a
workload
starts
up
as
I
mentioned,
it
calls
this
workload.
Ap
is
basically
the
first
thing
and
the
age
and
then
reads
a
special
socket
option
off
the
kernel
that
results
in
the
process.
Id
of
the
caller.
The
agent
then
uses
this
process
ID
to
interrogate
the
kernel,
find
out
more
about
that
particular
workload.
A
A
So,
as
I
mentioned,
the
the
assigning
keys
are
centralized
and
that's
kind
of
an
important
property,
because
it
prevents
a
single
compromised
agent
from
being
able
to
mint
arbitrary
identities,
and
that
gives
us
one
of
the
really
important
security
properties.
At
least
I
think
that
Matt
will
talk
a
little
bit
about
later
in
the
assessment,
and
so
in
addition
to
signing
these
s
feds.
The
server
also
maintains
this
identity
registry.
So
basically
understands
how
to
map
these
various
workload
properties
that
the
agents
are
discovering
to
an
actual
spiffy
ID.
A
This
mapping,
if
you
will,
is
maintained
what
we
call
the
registration
API.
So
there's
like
this
registry
of
identity,
mappings
essentially,
and
this
API
can
be
accessed
by
humans,
the
CLI
utilities,
or
it
can
be
maintained
by
an
automated
system
with
scripts
or
an
Orchestrator,
or
something
like
this,
and
these
workloads,
these
50
ideas
get
registered
with
what
we
call
an
entry,
a
registration
entry.
The
entry
consists
of
quite
simply
just
the
spiffy
ID,
those
properties.
We
discussed
what
what
is
this?
A
A
Of
course,
this
system
like
this
is
quite
sensitive,
security,
wise
and,
as
I
mentioned,
it's
really
important
to
validate
these
architectural
decisions
early
on
in
the
process.
That's
the
motivation
for
undertaking
all
this
stuff
we're
talking
about
today,
so
now
that
we
have
a
little
bit
more
background
about
spiffy,
inspire
and
I'm
this,
particularly
just
by
our
architecture,
I'm
gonna,
pass
it
off
to
Matt
he's
going
to
share
some
of
the
security
properties.
We
expect
from
a
system
like
this,
as
well
as
what
kind
of
properties
are
really
critically
important.
Yeah.
B
So
hopefully,
you've
got
a
general
kind
of
picture
from
evan
that
this
is
the
complicated
system.
Right.
It's
a
distributed
system,
a
lot
of
heterogeneous
components.
You
have
different
nodes
nodes,
have
a
concept
of
kind
of
a
blast
radius.
You
have
heterogeneous
workloads
running
on
nodes
and
the
security
properties
are
kind
of
subtle
right.
There's
certain
certain
cases
where
we
expect
the
system
to
fail.
If
you
compromise
the
server,
the
server
has
the
signing
keys
for
the
trust
domain.
B
So
to
sort
of
explore
this
space,
we
thought
about
several
different
dimensions
and
the
first
dimension
we
thought
about
is:
what
is
the
attackers
goal?
What
is
it
they're
trying
to
get
out
so,
for
example,
a
kind
of
like
the
most
basic
attack
in
a
system
like
this
is
I
want
to
impersonate
another
workload,
another
node
agent
or
the
server
I
am
NOT
that
entity,
but
I
want
to
pretend
to
be
that
entity.
Another
one
is
I
might
want
to
just
shut
down
part
of
the
system,
and
maybe
that
would
take
down
your
production
website.
B
B
Similarly,
I
might
want
to
have
a
legitimate
identity.
So,
let's
say
I'm
a
work
load
I
have
a
legitimate
identity.
I
want
to
modify
the
permissions
associated
with
my
identity
in
some
part
of
the
system,
and
this
comes
into
play,
particularly
because
the
spire
server
is
doing
authorization
based
on
spiffy
IDs.
It's
using
this
authorization
that
authorization
logic
to
decide
sort
of
which
node
agents
are
allowed
to
issue
which
identities
so
there's
sort
of
an
opportunity
for
that
to
get
out
of
whack.
B
B
B
It
turns
out
you're
gonna
have
a
bad
day
if
your
spire
server
is
compromised,
but
it
could
be
that
one,
a
single
node
agent
is
compromised
could
be
that
a
single
workload
is
compromised,
and
so
we
wanted
to
consider
all
of
those
cases
in
our
analysis
and
then
the
final
dimension
that
we
looked
at
is
what
kind
of
superpowers
do
you
have
as
an
attacker.
So
if
every
piece
of
software
worked
perfectly
and
had
no
bugs,
it
would
be
pretty
really
pretty
easy
to
reason
about
the
security
properties
of
the
system.
B
But
we
know
in
reality
that
code
is
broken
and
it's
broken
all
kinds
of
weird
interesting
ways,
most
of
which
we
can't
really
predict.
But
what
we
tried
to
do
was
come
up
with
some
plausible
vulnerability
and
vulnerability
classes
based
on
the
type
of
that
we
use
to
build
spire
how
much
pieces
of
code
are
accessible
to
different
attackers,
and
so,
for
example,
we,
the
spire
server,
is
written
in,
go,
there's
a
bunch
of
go
code
that
deals
with
attacker
supply
data.
One
of
those
is
the
CSR
parser
CSR
is
a
certificate
signing
request.
B
It's
an
ASM
dot,
one
format,
it's
kind
of
a
tricky
binary
format.
You
know
the
it's
this
parser
and
go
is
written
in
a
memory
safe
language,
so
it's
probably
not
going
to
have
a
certain
set
of
buffer
overflow
vulnerabilities,
but
maybe
either
something
weird
we
don't
understand,
or
maybe
there's
a
bug
that
combines.
You
know
something
wrong
in
the
CSR
parser
with
something
wrong
in
the
go
runtime
for
example.
B
Similarly,
we
we
have
to
use
the
goes
x.509
certificate
parser
we
have
to.
We
have
to
run
that
on
bites
that
are
supplied
by
an
attacker
before
we
know
who
they
are
so
that
can
be
dangerous
and
then
there's
a
whole
set
of
other
kind
of
pieces
of
the
protocol
stack
that
end
up
being
involved
in
servicing
requests,
and
this
is
code
that
sort
of
handled
that's
code.
That
is
run
before
the
request
is
authenticated.
B
The
spy
agent
relies
on
some
sort
of
sandbox
mechanism,
usually
Linux
containers,
it's
reasonable
to
suppose
that
there
could
be
vulnerable
--'tis
in
that
mechanism,
and
we
want
to
know
how
those
would
affect
the
system
assuming
an
attacker
has
that
that
superpower
we
also
want
to
account
for
cases
obviously
where
an
attacker
can
manipulate
network
traffic
in
kind
of
arbitrary
ways.
We
also
considered
a
class
of
vulnerabilities
where
you're
able
to
submit
some
sort
of
malformed
a
certificate,
signing
request
or
a
certificate.
B
It
might
not
get
you
remote
code
execution,
but
it
gets
you
some
sort
of
weird
certificate
and
and
we're
just
kind
of
supposing
that
this
is
a
class
of
vulnerabilities
without
understanding
anything
about
really
what
the
properties
of
this
might
be.
We're
just
saying
that
hey,
maybe
something
weird
could
have
in
here,
let's
think
about
what
would
happen
if
there
was
something
weird
here
and
then
finally
kind
of
a
pretty
easy
attack
for
anyone.
This
is
an
attack
you
can
do
by
accident
is
overwhelming
part
of
the
system
with
requests.
B
We
also
considered
a
class
of
vulnerabilities
where
we
thought
we
fixed
something,
and
we
didn't
so.
We
have
some
sort
of
security
control
in
spire.
That
should
have
mitigated
a
particular
problem,
but
something
was
broken
with
that
control,
so
either
it
could
be
bypassed
or
it
didn't
work
in
some
case.
B
So,
with
these
three
dimensions,
we
became
state
space
explorers.
We
really
like
wanted
to
explore
every
possible
combination
of
these
States
say
you
know
as
an
attacker.
How
could
I,
what
could
I
do
with
this
set
of
superpowers
if
I
start
on
this
node?
What
kind
of
states
kind
of
the
system
into,
and
what
do
we
expect
aspire
to
do
in
that
state?
And
why,
like
which
security
controls
inspire,
are
relevant?
To
that
case?
Are
they
adequate?
B
Are
there
any
kind
of
weird
bypasses
we
can
think
of,
and
this
is
really
an
exercise
than
in
discussion
like
we
really
spend
a
lot
of
time
just
talking
about
this,
so
it
involved
a
lot
of
talking,
and
this
is
where
we
kind
of
gonna
drop
the
curtain
after
level
with
you.
You
all
came
to
a
talk
about
a
spreadsheet.
B
So
one
thing
we
estimated
was
how
severe
is
an
attack
on
different
parts
of
the
system
and
different
types
of
attacks.
So
we
looked
at,
for
example,
the
full
compromised
attack.
My
goal
as
an
attacker
is
to
run
code
on
this
component.
How
bad
is
that,
if
it
happens
to
your
server
real
bad?
How
about
is
that,
if
that
happens,
to
an
individual
container,
not
nearly
so
bad
right,
and
these
are
not
supposed
to
be
exact
numbers.
This
is
like,
like
Evan
said
at
the
beginning.
B
How
bad
is
it
if
you
hit
a
certain
cell
to
make
this
matrix
and
how
likely
is
it
that
you're
gonna
have
the
set
of
vulnerabilities
you
need
to
to
get
to
that
state?
We
were
able
to
do
kind
of
a
joint
ranking,
so
this
is
like
every
cell
in
this
matrix,
which
ones
are
the
worst.
So
if
you're
over
here
on
the
left
hand
side
of
this
this
chart,
that
means
the
impact
is
pretty
high.
So
this
is
pretty
bad
for
you.
B
If
this
happens
to
your
production
network
and
the
capabilities
an
attacker
needs
to
to
get
to
that
state,
are,
we
think
relatively
likely
to
happen,
and
likewise,
if
you're
over
on
the
on
the
far
right
hand
side
of
this
scale
either
the
attack
doesn't
really
matter
that
much
because
it's
it's
not
gonna,
really
impact
the
operation
of
the
system
or
requires
a
vulnerability
that
we
think
is
gonna,
be
really
rare
and
again.
This
is
just
based
on
our
kind
of
collective
wild
guess
so.
I'm
gonna
turn
things
over
to
Evan.
A
Like
that,
what
what
did?
What
did
all
that
talking
and
spreadsheet
learning
give
us
I
think
that
there
are
a
couple
pieces
of
things
that
popped
up
pretty
clearly
and
immediately
after
analyzing
all
this
data
that
we
compiled
the
first
thing
was
rate
limiting
and-
and
this
is
not
like
really
a
surprise
that
it
was
required.
The
surprise
actually
was
more
kind
of
in
the
magnitude
of
that
final
score.
That
was
computed.
A
A
Second
thing
that
we
found
was
that
CSR
person
that
Matt
was
talking
about
you
know.
Csr's
is
a
relatively
standard
way
for
fulfilling
a
request
for
a
new
x.509
certificate.
So
when
we
were
designing
spire
originally
we
didn't
really
put
much
thought
into
it
so
that
all
the
agent
needs
a
cert.
So
you
know
we're
gonna
use
a
CSR
for
that.
But
after
some
discussion
we
kind
of
realized
that
the
CSR
processing
code
is
a
source
of
vulnerability
vulnerability,
particularly
on
that
you
know
the
libraries
to
prostitue
parsing
process.
A
These
CSRs
are
not
anywhere
close
to
as
well
exercised
as
the
x.509
libraries
are,
for
instance,
undergoing.
We
further
realize
that
the
semantics
of
the
CSR
gives
aren't
really
required
for
spire
security
or
functionality
at
all.
So
as
a
result,
even
though
the
CSR
related
vulnerabilities
were
not
not
necessarily
the
very
very
top
of
the
list,
they
they
weren't
even
significant
and
reflecting
on
this
and
realizing
that
we
don't
actually
need
this
thing.
A
We're
under
discussion
right
now
to
remove
CSR
processing
altogether
from
the
spire
architecture,
but
overall
I
think
there
weren't
any
like
giant
surprises
here,
we
definitely
identified
a
few
things
that
we
can
improve,
but
we
generally
achieved
the
security
properties
that
we
were
aiming
to
achieve
with
this
architecture.
Of
course,
that's
not
to
say
that
there
aren't
any
problems
you
know
there
there.
Certainly
we
might
have
overlooked
things,
but
certainly
this
kind
of
first
path
is
first
passes
a
very
reassuring.
A
One
took
a
long
time
to
do
this,
as
you
know,
we
mentioned
once
or
twice,
but
now
that
we
have
these
tools.
We
have
these
matrices.
We
have
this
scores.
We
have.
We
understand
like
how
to
approach
this
problem.
It's
really
easy
to
kind
of
keep
this
up.
So
as
the
project
evolves
over
time,
these
spreadsheets
can
be
updated
and
the
scores
can
be
updated
and
maintained
and
which
will
allow
us
to
like
measurably
track
the
security
posture.
A
The
spiffy
inspired
projects
over
time,
which
I
think
is
ultra
ultra
cool
and
if
so
he
aspire
is
important
to
you,
then.
Certainly
this
data
I
think
would
also
be
of
interest
and
important
to
you
and
and
hopefully
can
help
you
to
guide
decisions
that
you
make
in
your
deployment
and
implementation
of
spiffy
or
aspire
systems.
I
know
that
we
have
certainly
found
it
very
helpful
to
have
around
we're.
A
Also
looking
for
more
volunteers-
or
there
was
just
four
of
us
that
worked
on
this
thing
and
it
was
a
ton
of
work,
and
you
know
part
of
the
scoring
exercise
and
everything
requires
different
perspectives
to
be
involved
in
different
opinions.
To
be
ejected,
so,
if
you
guys
are
interested
in
helping
out
on
this
front,
we
would
love
to
have
you
have
some
more
eyes
on
this
assessment
and
poke
holes
or
wherever
you
possibly
can,
and
if
you're
interested
in
helping
out
either
in
this
security
assessment
or
or
anything
else.
A
If
you
just
even
looking
for
more
information,
please
do
join
the
slack
organist
if
you
stock
organization,
any
and
all
questions
are
welcome
about
this
or
anything
else,
really
we'd
love
to
see
you
there.
You
can
also
find
a
lot
of
information
on
our
github
repos.
The
the
spire
repo
here
in
the
middle
is
the
one
with
the
spire
code
base
and
then
the
bottom
one
here,
spiffy
spiffy
is
the
one
that
has
all
the
spiffy
specifications
as
well
as
information
about
the
community.
Regular
calls
things
along
those
lines.
A
C
B
C
Right
so
the
general
technique
that
we
used
in
this.
The
way
we
did
things
with
threat
models
and
other
types
of
refinement
of
threat
categories
is
a
technique
that
we
invented
called
ABC
that
we've
used
in
a
couple
of
other
ways
and
I'm
very
happy
to
provide
more
information
about
this,
where
you
have
a
publication
coming
out
about
it
and
would
be
happy
to
talk
more
about
it.
So,
please
reach
out
to
to
me
or
to
anybody
on
the
team
here
and
they'll.
Get
you
in
touch
with
me
about
it.
A
big.
B
Part
of
this
project,
who
was
you
know
a
lot
of
this
knowledge,
existed
like
in
Evans
head
and
some
of
the
people
who
had
worked
really
deeply
in
the
code.
We
really
wanted
to
get
it
out
out
of
Evans
head
into
a
spreadsheet
so
that
we
can
bring
more
people
onto
the
project
to
my
own
people,
who
might
bring
a
different
skill
set
with
formal
methods
or
other
ways
of
thinking
about
the
problem.
B
Yeah
I
would
say
the
specific
spreadsheet
is
very
specific
to
to
spire,
because
the
the
kind
of
the
what
I
called
attacker
superpowers,
that
kind
of
vulnerability
classes
were
really
things
that
specifically
applied
to
spire
and
the
specific
code
that
makes
up
spire.
The
methodology
in
general
is
generally
applicable
and
you
can
look
up
some
of
Justin's
papers
on
other
systems.
Yeah.
A
You
may
be
able
to
draw
some
commonality
with,
like
you
know,
attacker
starting
position,
different
components,
classes
of
vulnerabilities
I'm
like
okay,
like
how
do
you
score
them,
which
components
get
scored,
and
how
did
this
course
come
together?
All
that
stuff
might
be
applied
generally,
rather
than
specific
to
aspire,
but
the
values
of
those
things
are
pretty
spire
specific
and
I
know
that
Justin
has
been
working
with
CNC
F
on
on
trying
to
kind
of
come
up
with
a
generalized
model
for
this.
A
B
Think
it's
also
good
know.
We
could
really
hit
a
lot
of
nuances
and
actually
changed
our
methodology
throughout
this
project.
So
like
something,
we
kind
of
discovered
about
a
third
of
the
way
through
was
that
the
way
we
were
thinking
about
attacker
starting
positions
and
and
desired,
attacker
States
wasn't
quite
nuanced
enough.
B
So
there's
there's
this
idea
and
we
simplified
it
a
little
bit
for
the
slides,
but
the
difference
between
having
compromised
at
workload
and
attacking
a
workload
on
the
same
node
versus
attacking
a
workload
on
another
node,
and
we
expect
in
general
that
nodes
can
be
sort
of
isolated
into
these,
like
sort
of
blast
zones,
and
so
it's
not
as
big
a
deal.
It
should
not
be
as
big
a
deal
to
compromise
another
workload
in
your
same
zone
as
it
is
to
compromise
something
in
another
zone.
A
So
the
question
is:
are
there
any
special
considerations
for
bootstrapping?
The
spire
agent
is
a
clearly
introduced
it
to
the
spire
server.
Absolutely
I
left
it
out
of
this
talk,
because
I
didn't
think
that
it
was
very
important
for
for
the
scope
of
the
review
that
we
were
doing,
but
the
same
kind
of
way
that
I
talked
about
row
code
at
the
station.
There's
also
a
concept
of
no
data
station
which
leverages
platform
providers
and
other
things
like
this
in
order
to
validate
the
identity
of
the
caller
when
it's
not
or
a
local
process
for.
A
No,
it
said
the
question
was
we
were
saying
that
the
CSR
is
a
potential
source
of
vulnerability
and
that
maybe
we
could
remove
it,
and
does
that
mean
that
we're
looking
to
move
away
from
x.509
entirely
and
preferred
jot?
Instead,
the
answer
I
think
there
is
definitely
no.
But
what
we
found
was
that
the
spot,
the
spire
server
knows
what
identity
is
supposed
to
be
issued
and
the
format
of
that
certificate.
A
So
definitely
exile
online
I
think
is
still
kind
of
like
the
main
US
Fed
format
and
the
one
that
we
would
recommend,
above
all
else
when
it's
possible
to
use
it.
But
we
just
the
the
guarantees
and
properties
that
the
commonly
used
CSR
process
follows,
doesn't
really
buy
us
much,
and
so
we
might
as
well
cut
it
out.