►
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
Deep Dive: SPIFFE - Scott Emmons & Emiliano Bernbaum, Scytale
SPIFFE (Secure Production Identity Framework For Everyone) is an open source standard for giving identities to services in dynamic and heterogeneous environments. SPIRE (SPIFFE Runtime Environment) is an implementation of SPIFFE that can be deployed to attest service workloads and the infrastructure that runs them. Is it best to deploy SPIRE components in daemonsets, statefulsets, or regular container deployments? How should configmaps be used to configure the SPIRE server and agent? How is the SPIRE agent deployed and configured so the workload API is available to service containers? What is the recommended mechanism for persisting SPIRE data for resiliency and security? In this deep dive, we’ll discuss these best practices plus more suggestions and recommendations for deploying SPIRE in Kubernetes.
https://sched.co/MPk9
B
A
Name
is
Liliana
Birnbaum
and
I
also
work
for
Saito.
So
today
we're
you
know
cutting
to
cover
a
couple
of
things.
I
mean
the
main
thing
we're
going
to
talk
about
is
deploying
spire
on
kubernetes
and
Scott's,
going
to
give
a
demo
showing
that.
So
you
know
during
coop
con
we've
had
we've
had
a
couple
of
talks
today.
Evan
and
Sean
Crampton
had
a
really
great
talk
about
zero
trust,
the
back
and
forth.
A
So
since
last
coop
con
what
we've
really
done
it
is.
We
went
back
and
concentrated
on
on
getting
spire
running
on
kubernetes
and
that's
what
a
lot
of
the
work
that
we've
been
doing
for
the
last
I
would
say
four
months
and
some
of
the
things
that
we
did
is
we
created
a
SATA
tester.
So
a
SATA
tester
is
using
the
service
account
token
from
from
kubernetes,
and
really
it's
for
virgins
of
kubernetes,
that
don't
support
that.
A
Don't
have
the
token
volume
projection
and
things
like
eks
or
an
older
version
of
kubernetes
and
with
the
SATA
tester.
It
gives
you
the
ability
to
to
use
the
PKI
in
kubernetes.
You
don't
have
to
write
node
attestation
policies
that
are
relying
on
the
the
infrastructure
that
you're
running
on,
for
instance,
AWS
security
groups,
that
you
could
write
a
test
search
for
that
and
then
the
other
thing
we've
done
is
we
actually
created
another
a
tester
for
for
peace
at
tokens
and
that's
really
four
versions
of
one
12
and
higher
and
peace
at
will.
A
A
So
another
thing
I
want
to
talk
about
is
initio
Citadel
plugin
that
we've
we
have
right
now
and
review
it
hasn't
hasn't
been
merged
in,
but
it's
an
experimental
CA
module
and
what
we
really
wanted
to
do
with
with
this
do
is
have
spire,
be
a
CA
plugin
into
Citadel.
So
we
what
we're
trying
to
what
we're
showing
is
off
mesh
expansion
off
of
an
SEO
mesh.
A
So
you
could
have
a
workload
in
sto
talked
to
a
workload
outside
of
Ischia
using
spire
as
a
bridge
for
that,
so
we're
not
gonna
do
a
demo
of
that.
But
if
anyone's
curious
we
definitely
will
share
that
I
hadn't
put
the
URL
for
it,
but
it's
out
there
so
I'm
gonna
just
go
over
how
we
do
this.
So
what
we're
doing?
What
we're
showing
here
is
just
initio
deployment
with
a
with
two
workloads.
A
First,
we
have
to
get
a
secret,
so
we
have
to
get
a
bearer
token
out
of
the
kubernetes
api
and
and
a
bundle
to
to
basically
go
back
and
talk
to
the
token
review
api
and
again.
This
is
our
our
experimental
first
shot
at
this.
So
what
happens
is
that
the
envoy
tries
to
get
his
kiss
s
vid
and
I
kind
of
skipped
over
it,
but
the
the
tasks
API
is
already
attested
to
the
spire
agent.
It's
already
gotten
his
identity
and
that's
been
delivered
to
the
Envoy
running
in
the
in
the
docker
container.
A
So
what
what
the
spires?
Basically,
the
this
geo
node
agent,
will
talk
to
the
spire
C,
a
plug-in
client,
which
will
then
communicate
back
to
the
spire
server
using
our
our
node
API.
So
that's
how
we
could
communicate
back
into
the
spire
server
and
send
the
CSR
requests
back
to
spire
and
once
we
receive
that
spire
will
use
the
the
service
account
token,
at
the
bundle
that
it
received
to
authenticate
back
to
the
token
review,
API
and
then
it'll
present
the
token
that
was
delivered
from
the
CA
client.
A
If
that's
verified-
and
you
know,
if
that's-
if
that's
a
valid
token,
then
we
will
do
the
CSR
request
and
then
we
will
deliver
the
s
feedback
to
the
Envoy
proxy
inside
of
the
mesh,
and
now
you
could
talk
the
task.
App
could
now
talk
to
the
tasks
API
and
again
we,
you
know
we
ran
this
outside,
but
you
could
easily
run
the
Speier
server
and
all
of
that
inside
of
the
mesh
and
just
have
a
spire
agent
outside
of
the
mesh.
A
B
It
that's,
not
a
requirement,
but
it
really
depends
on
what
configuration
you
have
setup
because
fire
is
is
pretty
adaptable
and
configurable
for
different
environments
for
kubernetes,
most
likely
you're
going
to
require
a
persistent
volume
for
the
data
dated
or
a
volume
claim.
Template
in
stateful
set
is
a
really
powerful
way
to
let
kubernetes
just
sort
of
manage
that
volume.
So
you
don't
have
to
provision
it
separately.
I
know
I'll,
go
into
a
little
bit
more
detail
on
that
in
a
production
environment,
spire
server
requires
a
shared
database.
B
Currently
Postgres
in
my
sequel
are
are
supported
and
scaling
out.
Spire
services
is
really
fairly
easy.
You
just
need
some
sort
of
load
balancer
or
round
robin
DNS.
Maybe
there'll
be
more
more
ways
to
do
this
in
the
future,
but
those
those
do
work
today,
but
one
thing
you
do
need
to
be
a
the
certificate
store
is
eventually
consistent.
It's
not
synchronous
and
what
that
means
is,
if
you
bring
up
a
brand
new
spire
server,
that's
completely
new,
that's
not
using
a
shared
file
from
previous
or
sorry
sheriff
volume.
B
From
a
previous
instance,
none
of
the
agents
are
going
to
know
about
that
server.
It's
not
going
to
trust
the
bundle,
so
it
takes
some
time
for
that
bundle
to
get
propagated
to
the
existing
agents
so
that
they
can
trust
it,
and
so
because
of
that,
you
just
need
to
make
sure
that
you
deploy
servers
and
rule
them
out
and
I
in
a
kind
of
slow,
inconsistent
manner,
because
you
don't
want
to
strand
your
your
agents
for
deploying
the
agent.
That's
a
little
bit
more
rigid.
It's
always
going
to
be
a
daemon
set
in
kubernetes.
B
It
may
require
local
storage
for
the
data
Durr.
That
depends
really
on
the
a
tester.
That's
in
use
and
I'm
gonna
go
into
a
little
bit
more
detail
on
that
shortly
and
then,
finally,
we
need
to
expose
the
agent
workload.
Api
UNIX
domain
socket
mouthful
into
the
workload,
and
this
is
it's:
it's
not
tricky,
but
there
are
things
a
couple
things
you
want
to
know
about.
B
First
of
all
make
sure
that
you
are
exposing
in
the
directory
not
just
the
socket
file,
because
otherwise
what
happens
is
if
the
agent
crashes
and
restarts
you're
going
to
strand
all
of
your
workloads
on
that
node,
because
it's
not
the
same
file
anymore.
So
this
is
kind
of
what
the
configuration
looks
like
for
that.
B
This
looks
exactly
the
same
except
for
two
things:
we've
flipped
read-only
to
true
and
type
two
directory,
so
we
don't
want
to
work
load
to
be
able
to
create
any
files
in
that,
and
we
don't
want
the
workload
to
be
able
to
create
the
directory
right,
because
you
wouldn't
want
a
rogue
workload
masquerading
as
the
spire
agent
and
don't
worry,
even
though
it's
read-only
is
true.
The
workloads
can't
connect
to
that
UNIX
domain
socket
and
and
write
to
it.
B
So
I
mentioned
no
data
to
attestation
and
kind
of
how
that
affects
potential
persistence
of
the
data
der.
So
there
are
several
different
noted
testers
that
you
can
use.
We
have
the
ones
that
Emiliano
mentioned
there
that
are
specific
to
kubernetes.
The
service
account
token
and
projected
service
account
token.
But
even
though
you're
running
in
kubernetes
it
doesn't
mean
you
can't
necessarily
use
the
cloud
provider
of
testers
if
you're
running
a
managed,
kubernetes
you're
going
to
be
your
hands,
are
going
to
be
tied
a
little
bit
more.
B
If
you're
just
running
on
your
own
instances,
there
isn't
generally
nothing
that
prevents
you
from
using
the
cloud
provider
specific
testers.
But
one
thing
you
need
to
be
aware
of:
is
you
probably
are
going
to
need
a
local
data
Durr
and
buy
local
data
doreen
local
to
the
node
right,
so
a
host
path,
type
of
type
of
storage,
and
the
reason
for
that
is
that
the
cloud
provider,
our
testers
once
an
agent
has
attested
you
can
never
attest
again
as
that
agent,
you
need
some
persistent
state
and
the
reason
for
that.
B
So
for
the
kubernetes
of
testers.
How
do
we
verify
that
the
agent
is
who
the
agent
says
is
to
the
to
the
server
there's
two
methods
that
are
available?
We
can
verify
with
a
token
certificate
or
or
public
key
or
use
the
token
review
API.
If
you
have
a
new
enough
version
of
kubernetes
and
the
token
review
API
is
all
that's
available.
If
you're
running
on
google
kubernetes
engine,
for
example,
both
both
of
the
attest
errs
support
either
method.
As
of
0.8
and
then,
as
Emiliana
mentioned,
the
new
kubernetes
bundle
notifier
plugin.
B
So
with
this
with
this
plugin,
we
can
replace
both
the
bootstrap
certificate
and
the
upstream
CA.
So
the
bootstrap
certificate
is
a
static
certificate
that
the
agent
uses
the
first
time
it
starts
up
to
connect
to
a
spire
server
to
to
get
the
TLS
handshake
started.
An
upstream
CA
is
an
option.
It's
not
a
requirement.
It's
never
been
a
requirement.
It
was
an
option
where
you
can
use
another
signing
Authority
and
instead
of
just
having
that
being
a
self-signed
certificate
with
the
bundle
notifier
you
can
kind
of
replace
both
of
those
just
with
the
notifier.
B
And
what
happens
is
that
the
bundle
is
now
stored
in
a
config
map
and
that's
completely
managed
by
the
spire
server
via
kubernetes
api,
so
that
actually
is
never
even
mounted
into
spy
on
spire
server
as
a
config
map.
It
just
acts
a
spire
server,
just
modifies
it
directly
through
the
kubernetes
api,
their
version
using
kubernetes
object
versioning.
So
we
can
make
sure
that
that
it
doesn't
get
corrupted
that
way.
B
That
config
map
is
mounted
read-only
into
the
spire
agents
and,
if
you
are
using
this,
this
plugin
the
spire
server
data
dirt
does
need
to
be
on
a
persistent
volume
because
there's
some
state.
That's
that's,
really
important.
There
talk
a
little
bit
about
registration
entries
for
for
for
spiffy
right,
so
you
want
to
put
some
thought
into
how
your
workload
nodes
will
be
grouped
when
I
when
I
first
started
playing
around
with
spire.
It
really
wasn't
clear
to
me
how
do
I
organize
my
spiffy
identities,
how
do
I
organize
things
so
that
everything
gets
attested?
B
B
If
you
find
yourself
creating
manual
entries
that
are
using
very
specific
node
or
specific
information
like
a
node
UID,
that's
kind
of
a
good
indicator
that
your
might
want
to
take
a
different
approach,
because,
if
you're
creating
many
manual
entries
on
something,
that's
like
that
massive
thing
that
probably
won't
be
around
very
long-
it's
probably
not
not
the
way
you
want
to
go
now.
If
you're
doing
automated
type
of
registration,
then
this
is
a
this
is.
This
is
a
different
situation
right,
because
if
you
use
the
automated
registration
it
handles
all
of
that
for
you.
B
So
let's
just
take
a
really
simple
example
of
two
workloads,
and
we
know
that
those
workloads
are
gonna,
be
part
of
this
kind
of
set
of
nodes.
So
the
next
thing
we'll
do
is
map
that
into
our
spiffy
namespace,
so
we'll
create
something
called
my
cluster
IO
nodes
that
will
represent
all
of
the
nodes
that
that
the
workload
will
be
running
on
and
then
for
each
of
the
workloads
we
have.
B
My
cluster
do
slash
workload,
slash
a
in
workload,
slash
B,
so
that
kind
of
creates
our
hierarchy
and
our
groupings,
and
then
that
directly
translates
into
these
registration
entries.
So
for
the
for
the
nodes,
entry
we're
gonna,
we
create
a
node
entry,
it
doesn't
have
a
parent.
We
specify
this
50
ID
that
we
just
do.
B
We
just
mentioned
nodes
1
and
then
set
up
a
selectors
for
our
piece
at
a
tester
which
we'll
be
using
in
in
the
example
and
similarly
for
the
workloads
we'll
we
can
translate
those
directly
in
the
parent
is
going
to
be
our
my
cluster.
Do
nodes
entry,
these
50,
IDs
gonna,
clearly
be
whatever
our
workload
is,
and
then
we're
going
to
have
some
set
of
selectors
that
are
appropriate
for
for
the
workload
all
right.
B
A
B
B
B
So
the
first
thing
to
note
is
you
saw
this
a
few
a
few
slides
ago.
This
is
setting
up
the
socket
that
is
used
for
the
workload
API,
and
here
is
the
entry
to
inject.
The
projected
service
account
token.
So
you'll
see
that
it
we've
set
it
to
expire
after
7,200
seconds
and
then,
as
we
mentioned,
we
have
a
little
bit
more
controls
over
a
kind
of
traditional
service
account
token
and
that
we
can
specify
an
audience
of
who.
B
B
B
This
is
a
certificate
that
that
spire
agent
uses
to,
on
its
first
connection,
to
spire
server
and
now
we're
gonna
use
the
bundle
notifier
for
that
and
then
here,
just
as
the
server-side
had
its
configuration
for
that
piece
at
a
tester,
spire
agent
has
its
configuration
as
well,
and
we
just
use
the
same
cluster
name,
and
then
this
is
the
path
where
that
projected
service
account
token
gets
injected
into
all
right.
So
let's
apply
this
so
first,
let's
get
this
running.
B
B
Let
us
look
at
that.
Config
map
that
was
empty,
so
you'll
see
now
that
it
has
kind
of
format
funny
anyway.
Anyway,
now
you
can
see
that
there's
a
bundle
CRT
in
that
config
map,
so
spire
server
has
injected
in
the
bundle
certificate
and
and
made
that
available
to
the
agents
now
I
mentioned
that
scaling
spire
is
is
easy,
so
let's
do
it
all
right
now,
now
we
have
two
Spyder
servers
running
now:
I'm
lying
a
little
bit
I'm,
not
using
a
database.
B
Remember
earlier,
I
said
that
in
a
production
environment
we
need
a
shared
database,
so
I
haven't
done
that
here.
So,
let's
go
ahead
and
kill
that,
let's
so
I
want
to
show
one
thing:
if
you're
not
familiar
with
the
way
persistent
volume
claims,
work
you'll
see
that,
even
though
we've
scaled
down
to
only
one
instance
of
spire
server,
there's
still
two
volumes
here
and
with
the
persistent
volume
claims
in
a
save
Ville
set.
If
I
was
to
scale
that
back
up
to
two
two
servers,
it
wouldn't
create
a
new
volume.
B
B
Okay,
let
us
look
at
a
client.
So
now
we
want
to
deploy
a
client
workload
to
see
that
we're
able
to
get
an
S,
FID,
I'm
kind
of
lazy
here,
so
we're
just
going
to
use
the
spire
agent
container
only
instead
of
running
the
spire
agent,
we're
just
going
to
run
sleep
so
that
we
can
exec
into
it
and
and
run
some
commands.
So
let
us
apply
that
guy.
B
Okay,
so
we're
getting
an
error
here:
no
identity
issued
and
that's
really
simple.
This
is
expected
because
we
haven't
had
created
any
registration
entries
all
right.
This
workloads
not
allowed
to
run
it's
not
allowed
to
get
an
S
fit
and
in
fact
we
haven't
even
created
our
note
entry,
so
our
agent
really
isn't
even
attesting
correctly.
So
let's
look
at
what
that
registration
entries
will
look
like
that
will
create.
If
you
remember
my
earlier
diagram
with
the
tree,
these
are
exactly
those
really
one
one
side
of
that
tree.
B
So
we
created
a
note
entry
for
the
cluster.
We
create
a
selector.
So
again,
if
you
remember
within
the
spire
agent
and
server
configurations,
I
had
demo
cluster
in
there.
So
this
this
matches
that
we've
attested
to
be
a
member
of
that
cluster
and
then
for
the
workload.
It's
very
similar
we're
going
to
have
a
parent
which
is
the
previous
entry,
the
cluster
nodes
we're
going
to
give
it
this
spiffy
ID,
and
then
we're
going
to
use
this
selector.