►
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.
SPIRE Project Updates - Ryan Turner, Uber Technologies, Inc.
A
Hello:
everyone,
my
name,
is
ryan
turner
and
I'm
a
software
engineer
at
uber
and
maintainer
on
the
spire
project,
and
today
I'm
excited
to
talk
to
you
about
some
updates
with
the
project
that
I'd
like
to
share.
From
the
last
time
we
got
together
at
production
identity
day
in
north
america,
in
november
of
2020.
A
So
first
I'd
like
to
just
share
some
statistics
about
the
project
as
of
early
september
this
year.
This
is
between
last
production
identity
day
and
this
september,
so
we've
released
11
new
versions
of
spire.
In
that
time,
we've
deployed
out
49
new
features
into
the
repo
and
59
bug
fixes
and
improvements,
and
a
total
of
339
pull
requests
were
merged
in
the
last
year,
and
this
is
just
awesome.
A
This
is
like
way
up
from
last
year,
so
it's
super
exciting
to
see
the
growth
and
momentum
of
the
projects
and
in
total,
we've
had
48
contributors
over
the
past
year.
So
that's
really
great.
That's
also
up
from
last
year.
So
thanks
everyone
who
has
been
active
in
the
project
and
contributed
new
pull
requests,
those
who
have
filed
issues.
You
really
drive
the
direction
of
the
project
forward
and
we're
really
all
appreciative
of
that.
A
A
So
this
year
we
were
really
focused
on
trying
to
release
a
1.0
version
of
spire
and
a
1.0
version
for
us,
as
maintainers
of
the
aspire
project,
really
signified
a
stable
and
secure
release
that
really
showed
that
the
project
solves
a
core
use
case.
That
applies
to
many
organizations
in
the
software
industry
and
we
felt
like
coming
into
this
year.
A
A
But
basically,
once
those
vulnerabilities
were
reported,
we
sort
of
had
to
re-evaluate
our
direction
and
make
sure
that
we
were
achieving
the
objectives
that
we
had
laid
out
for
a
1.0
release.
A
So
back
in
march,
we
actually
released
several
versions
of
spire
to
patch
some
of
the
security
vulnerabilities
that
we
reported
as
part
of
the
security
audit
and
that
took
place
in
march.
A
We
we
felt
like
around
july.
It
was
a
good
time
to
to
actually
declare
this
project
a
1.0,
and
so
we
actually
did
release
a
1.0.0
version
of
spire
in
july
of
this
year.
A
So
we
actually
commissioned
a
security
audit
by
a
firm
to
a
firm
called
tier,
53
and
they're
a
really
great
reputable
security
research
firm
and
they
started
looking
into
the
project
around
february
of
this
year
and
they
did
a
full
like
in-depth
white
box
analysis
of
the
project.
A
And
so
they
were
really
looking
through
the
source
code
and
all
different
kinds
of
potential
attack
vectors
and
in
general,
the
the
project
was
found
to
be
pretty
well
designed
in
their
words.
But
there
were
a
couple
of
vulnerabilities
that
they
found-
and
this
was
all
focused
on
the
0.12.0
release,
which
was
the
latest
release
at
the
time
that
they
were
performing.
The
audit.
A
So
there
were
one
high
and
two
medium
vulnerabilities
that
they
discovered
and
we
took
these
vulnerabilities
very
seriously.
They
were
initially
only
reported
back
to
the
maintainers
of
the
spirit
project.
We
have
a
security,
vulnerability,
reporting
process
which
is
described
in
the
github.
A
Essentially,
these
kinds
of
security
vulnerabilities.
We
ask
anyone
who
finds
them
to
to
send
an
email
to
the
security
email
address
that
we
have
on
the
github
repo,
which
gives
maintainers
an
opportunity
to
evaluate
whether
or
not
there
is
a
vulnerability
and
what
the
potential
impact
of
that
is
as
well
as
developing
some
patches
to
try
to
fix
those
vulnerabilities
and
figuring
out
what
affected
versions
are
out
there.
A
So
these
are
the
two
vulnerabilities
that
we
filed
cves
for
you're,
more
than
welcome
to
go
onto
the
github
repo
we've
published
github
security
advisories
for
both
of
these
vulnerabilities,
which
describe
the
issues
in
a
lot
more
depth
and
also
refer
to
the
fixes
which
were
applied
to
all
the
affected
versions.
A
So
I'll
just
briefly
cover
what
the
vulnerabilities
were,
that
the
audit
uncovered.
So
the
first
one
here
legacy
node
api
allows
impersonation.
So
there
was
there's
a
an
existing
set
of
apis
that
came
out
before
the
current
v1
api
layer,
which
was
introduced
in
late
last
year,
and
one
of
those
apis
was
called
the
node
api.
A
This
was
something
that
the
spire
agent
used
to
attest
itself
to
the
spire
server
and,
in
a
sense,
prove
it
so
that
it's
a
valid
agent
in
the
infrastructure,
and
there
was
one
path
available
where,
if
an
actor
was
able
to
obtain
an
agent
as
vid
meaning
it
was
able
to
successfully
attest
to
the
server,
it
could
potentially
request
s-vids
for
identities
that
it
wasn't
allowed
to
serve
based
on
the
registration
metadata
registered
in
spire
server.
A
A
So
in
the
uri
specification
there
there's
no
restriction
on
like
unicode
characters
or
selected
characters
that
are
like
punctuation
marks
and
such
that
those
kinds
of
characters
can
be
represented
through
this
percent
encoding
mechanism,
and
I
there
it
turns
out
that
it's
really
hard
to
uniformly
handle
those
kinds
of
sequences
and
uris
across
different
languages
across
different
libraries.
A
A
So,
as
I
said,
we
released
new
versions
with
fixes
for
all
these
vulnerabilities
and
we
published
the
results
of
the
vulnerabilities
and
patches
into
the
spire
github
and,
if
you're
interested
in
reading
through
the
audit
itself,
that
is
also
published
as
a
pdf
on
the
readme
file
for
the
spire
repository
in
github.
A
Okay,
so
I
want
to
kind
of
walk
through
the
releases
in
the
last
year
and
just
highlight
some
of
the
notable
accomplishments
in
the
project.
So
let's
go
ahead
and
start
with
the
0.12.0
release,
which
came
out
last
december.
A
A
The
agent
sync,
essentially
it
it's
an
operation
where
the
agent
very
frequently
every
five
seconds
requests
all
of
the
registrations
that
it's
eligible
to
serve
identities
for
on
the
host
it's
running
on
and
that
operation
used
to
take
a
lot
a
lot
of
time
with
a
larger
number
of
agents
or
a
larger
number
of
registrations
inspire
because
it
was
using
dynamic
database
queries
that
were
not
very
efficient.
A
A
And
then
in
0.12.2,
this
was
released
in
april
of
this
year
and
some
of
the
noteworthy
things
to
point
out
here,
there's
a
new
server
key
manager,
plugin
created,
which
uses
aws
key
management
service.
So
this
allows
you
to
manage
all
of
spire's
private
keys
and
signings
in
a
key
management
service
in
aws
there
was
also
a
new
plugin
added
for
the
spire
server
to
use
gcpcas
as
the
upstream
authority.
A
A
One
of
the
major
things
that
happened
was
that
there
was
a
big
refactoring
of
how
the
protobuf
definitions
are
managed
in
spire,
previously
spire
used
to
be
a
single
repository
with
two
go
modules:
one
was
the
core
spire
module
and
the
second
was
a
protobuf
module.
A
A
A
We
also
added
support
for
versioned
plugins.
So
if
we
need
to
change
the
plugin
interfaces
inspire,
we
have
an
effective
way
to
do
that
now
through
versioning.
There's
also
support
added
for
a
cert
manager
upstream
authority
plug-in.
So
if
you
wanted
to
use
cert
manager
as
your
chain
of
trust
for
the
upstream
for
spire,
that's
now
possible,
there's
also
new
commands
added
to
the
spire
server
cli
for
banning
agents
and
counting
some
of
the
resources
tracked
by
spire,
like
agents
and
entries
and
bundles,
which
used
to
be
kind
of
an
expensive
thing
to
calculate.
A
A
A
So
if
you
have
workloads
which
need
to
verify
svids
but
themselves,
don't
really
need
to
use
svids
for
authentication
to
other
workloads,
though
you
don't
need
to
register
those
verification,
workloads
anymore,
inspire.
You
can
use
this
unauthenticated
unregistered
api
to
just
obtain
the
bundles
also
on
the
server
and
the
agent
now
implement
the
standard
grpc
health
service.
So
this
improves
the
health
check
story.
First,
buyer.
A
In
1.0.1
we
added
an
ldiv
id
based
tpm
node,
tester
plugin,
which
basically
uses
a
proof
of
possession
and
proof
of
residency
challenges
to
verify
that
a
host
is
issued
by
or
has
a
tpm
that's
issued
by
a
trusted
vendor.
So
this
improves
like
private
cloud
kind
of
attestation,
if
you're
using
tpms
and
then
we've
also
had
no
data
station
for
aws
vms
across
multiple
aws
accounts
using
aws.
I
am
role
assumption
in
1.0.2.
A
We
added
experimental
support
for
defining
authorization
policies
in
the
server
using
opa,
so
this
kind
of
changes,
the
mechanism
that
the
server
uses
to
authorize,
inbound
callers,
there's
also
audit
logging
added
to
the
server
api
layer,
so
all
calls
to
server
apis
are
now
audit
logged
support
for
the
spiffy
certificate.
Validator
was
added
to
the
envoy
sds
v3
api
inspire
agent
to
enable
federated
spiffy
authentication,
and
we
there
were
also
support
added
to
the
kubernetes
workload
registrar
for
identity
templates
for
spiffy
id
pads.
A
There
is
ongoing
work
to
provide
a
new
api
which
allows
like
a
trusted
process
to
delegate
the
to
delegate
svids
to
other
workloads
running
on
the
same
host
in
the
past.
This
has
only
been
contained
within
this
fire
agent,
but
now
we're
allowing
like
trusted
proxies,
for
example,
to
be
able
to
do
this
kind
of
issuance
of
identity
as
well.
A
We're
exploring
ways
that
we
can
do
better
verification
of
binary
signing
to
use
things
like
tough,
for
example,
and
then
we
want
to
provide
ways
to
connect
to
gcp,
using
secret,
less
authentication
with
oidc
federation
and
in
the
long
term,
we're
looking
at.
How
do
we
effectively
do
key,
revocation
and
forced
rotation
of
identity,
also
secret
list
off
to
azure,
with
oidc
federation,
continuing
to
iterate
on
our
health
check
subsystem
and
improve
our
error
messages
to
be
more
actionable?