►
From YouTube: Zero Trust Supply Chains with Project Sigstore and SPIFFE - Andres Vega & Jake Sanders
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Zero Trust Supply Chains with Project Sigstore and SPIFFE - Andres Vega & Jake Sanders
In order to ensure the trustworthiness of your software supply chain, maintainers must restate a number of assumptions. As opposed to inherently trusting build systems to serve accurate package metadata, we propose verification of every claim in the chain against the actors and tasks involved in the process. The combination of cryptographically verifiable identities with the use of transparency logs provides a novel approach to accomplish so and increase the security guarantees of your release artifacts.
Project Sigstore provides a toolkit to allow organizations to publish verifiable provenance about publicly distributed artifacts. This metadata is in turn stored on the Sigstore Binary Transparency Log (Rekor), signed and verified by use of Keyless Signatures (Cosign) and the Sigstore Certificate Authority (Fulcio), and stored in an OCI registry where it can be verified, discovered, and used in policy engines. Backed by SPIFFE’s reference implementation SPIRE, all cryptographic operations are rooted in a strongly attested universal identity control plane for distributed systems.
This presentation will demonstrate how a zero trust supply chain architecture can be applied to build systems, through the use of Sigstore and SPIRE for a Federated, Verifiable, Zero-Trust Supply Chain. Additionally, TektonCD will be used as the example build system and in-toto as the example provenance format.
A
A
Ev
you're
new
to
the
spiffy
project.
The
community
was
involved
and
the
authoring
of
a
book
with
everything
from
planning
architecting
implementing
operating
spiffy
Inspire
deployments
at
scale,
borrowing
from
the
experience
of
practitioners,
who've
deployed
Spire,
ranging
from
highly
regular
regulated
Industries
to
web
scale
companies.
The
book
is
available
online
on
at
spiffy.io
slash
book.
A
B
A
I
am
Andres
I
work
at
control,
plane,
control,
plane
as
a
offensive
security
company
specialized
on
cloud
native
security.
We
do
all
sorts
of
engagements
ranging
from
threat,
modeling,
pen,
testing
security
architecture
and
automation,
if
we're
here
to
help
with
any
of
your
security
needs
and
attacking
and
defending
kubernetes.
A
Also
I
am
on
the
steering
committee
of
the
specific
project
I've
been
involved
in
the
Pro
in
the
project
approximately
for
five
years
and
different
aspects
of
product
program
and
project
management,
I,
authored
the
spiffy
security
assessment
and
preparation
of
the
project
moving
from
sandbox
to
incubation
I.
Also
let
the
preparation
of
due
diligence
from
moving
from
incubation
to
graduation
I've
also
participated
in
a
few
other
efforts
through
cncf
tax
security.
It's
nice
to
see
fellow
tax
security
members.
Here
we
recently
published
a
supply
chain
security,
best
practices
guide.
A
It
is
available
in
the
tax
security
repo
and
as
a
addendum
to
that.
As
a
sequel,
we
also
wrote
down
a
reference
architecture
of
a
secure
software
Factory.
All
of
these
resources
are
open
source
I.
Invite
you
to
check
that
out
gave
us
feedback.
If
it's
something
useful.
If
there
are
gaps,
we'd
love
to
hear
from
you,
so
let's
get
into
the
subject.
What
is
a
software
supply
chain?
Jake?
Well,.
B
A
supply
chain
is
everything
from
creating
the
code
to
checking
out
the
code
to
building
the
code,
to
deploying
the
code
and
everything
else
you
might
want
to
do
with
it,
and
why
would
it
be
important
to
secure
it
because
mean
people
like
to
you
know
mess
with
your
software
at
every
sort
of
step
of
the
way,
I
sure
I,
probably
don't
have
to
tell
anyone
in
the
room
that
you
know.
Software
supply
chain
is
a
big
issue
these
days.
B
Basically,
what
the
industry
has
had
to
deal
with
is
not
really
having
a
good
foundation
to
build
upon
in
order
to
secure
every
piece
of
the
software
supply
chain
that
they
might
need
to,
but
now
we're
getting
things
like
the
executive
order.
That
is
mandating
that
you
know.
People
working
with
the
government
have
to
have
certain
certain
levels
of
supply
chain:
Readiness
we're
seeing
a
whole
bunch
of
initiatives
from
all
sorts
of
companies,
including
you
know,
Google,
and
things
like
store
just
in
order
to
deal
with
it.
B
A
It
has
a
full-time
job
to
keep
up
with
the
threats
the
community
LED
an
effort
pioneered
by
Santiago
Torres
Arias
from
Purdue
to
catalog
Cloud
native
supply
chain
compromises.
This
is
available
in
the
tax
security.
Arapahoe
links
are
on
the
screen.
Here's
the
snippet
the
list
is
much
more
extensive,
is
a
good
breakdown
to
develop
understanding
of
the
threats
we're
faced
with
and
how
adversaries
may
attempt
to
exploit
vulnerabilities.
A
If
we
look
at
high
profile
compromises
that
have
occurred
since
there
is
the
common
denominator
of
man
in
the
middle
attack,
exfiltrated
credentials
as
the
entry
vectors
of
how
attackers
gain
a
foothold
and-
and
why
is
that?
How
did
that
precipitate?
Well
with
the
cloud
the
perimeters
have
operated,
as
we
have
larger
number
of
endpoints
communicating
across
security
boundaries,
communicating
across
platform
and
Cloud
boundaries.
All
of
this
traffic
is
is
exposed.
The
perimeter,
as
I
said,
is
non-existent.
It's
a
really
brittle
barrier
for
anyone
to
gain
a
foothold
onto
it.
A
A
These
secrets,
this
key
material,
must
be
secured,
so
you
encrypt
that
and
encrypting
it.
You
need
a
decryption
key,
and
now
you
have
yet
another
secret.
You
need
to
protect,
and
this
is
a
problem
of
infinite
regression.
Turtles
all
the
way
down.
You
end
up,
ultimately
having
a
collection
of
keys
some
end
up
in
paper.
You
end
up
putting
these
on
a
physical
Secret
store,
probably
even
a
bank,
to
ensure
the
confidentiality
of
that
in
order
to
protect
it.
Now
it's
not
a
great
model.
A
A
It
has
very
little
utility
of
the
life
cycle
is
as
close
down
to
zero
as
possible,
and
it's
dynamically
rotated
based
upon
that,
the
community
gathered
and
evaluated
a
best
practices
of
large-scale
organizations
that
were
further
down
the
road
of
solving
this
problem.
We
externalize
these
best
practices
and
codify
them
on
their
disability.
Specification
spiffy
stands
for
secure
production,
identity
framework
for
everyone.
It
defines
a
set
of
interfaces
and
documents
for
managing
the
life
cycle
of
identity
and
how
to
distribute
the
scheme
material
and
for
services
to
cross-authenticate
to
one
another.
A
A
A
It
does
create
an
identity,
control
plane.
It
creates
an
identity,
abstraction
that
you
can
rely
to
do
high
velocity,
pki
and
not
have
to
worry
about.
How
do
I
teach
my
app
to
do
TLS?
How
do
I
teach
my
app
to
talk
to
this
other
servers
securely
if
I
have
a
kubernetes
spot
that
needs
to
talk
to
a
Lambda?
How
do
I
exchange
this
identity
document
for
an
SDS
and
how
van
I
am
roll,
binding
and
move
away
from
managing
that
material
manually?
A
A
There
is
a
specification
for
the
API
or
how
are
applications
to
retrieve
and
this
credentials
there's
the
trust
bundle
that
is,
the
collection
of
public
keys
to
authenticate
the
far
end
of
a
call
and
Federation,
which
is
how
to
exchange
how
to
exchange
these
sets
of
keys
across
different
platforms
over
oidc
Federation
and
the
interest
of
time.
Since
we
start
a
little
late
I'm
not
going
to
dwell
too
much
on
trust
domains,
the
slides
will
be
available
online.
A
You
can
reference
the
trust
main
section
now
moving
on
to
the
software
implementation,
that's
what
a
typical
Aspire
deployment
looks
like.
You
have
a
Spire
server
that
manages
the
registry
of
all
of
those
identities
and
it's
concerned,
and
it's
concerned
with
the
issuance
it's
concerned
with
a
rotation
of
root
certificates.
A
Also,
and
the
second
key
component
in
the
architecture
is
the
Aspire,
the
Spire
agent,
which
serves
the
workload
API
to
containers
to
any
application
that
you're
attempting
to
spiffy
enable
the
API
that
the
agent
exposes
when
a
workload
gets
instantiated
and
has
no
notion
of
who
it
is.
Who
is
it
supposed
to
talk
to
comes
up
confused?
Who
am
I
goes
from
something
that's
never
been
seen
before
the
infrastructure.
How
does
this
transition
to
something
that
we
understand?
Well,
what
it
is
have
the
terminate's
identity
with
certainty.
A
Therefore,
we
can
Fair
Access
Control
that
process
of
introspecting
the
application
gets
initiated
by
the
workload
API
you
see
here,
Colonel,
kubernetes
and
docker.
The
the
workload
API
ensures
that
the
calling
workload
what's
the
sdid.
What
is
the
user
group?
What
do
we
know
from
cubelet?
What's
the
name
space?
What's
the
service
account
if
it's
running
on
a
Docker
container?
What
are
the
environmental
variables?
What
are
the
labels?
A
What's
the
image
ID,
if
you're
running
on
a
cloud
platform,
it
can
interrogate
say
if
it's
AWS
the
instance
metadata
API,
to
determine
what
VPC
what
availability
Zone
and
if
all
those
attributes
match
policy,
then
the
identity
gets
issued.
It's
credential
and
passed
on
through
the
workload
API
now
having
given
you
that
overview
of
spiffy
Inspire
I'm
going
to
pass
it
on
to
Jake,
to
talk
about
project
six
store
problem
solves
and
where
does
it
intersect
with
spiffy
inspire
all.
B
Right
so,
as
I
mentioned,
six
stores
raison
d'etre
is
helping.
You
solve
the
most
fundamental
issues
in
creating
you
know
a
cryptographic
route
of
trust,
and
actually
you
know
using
it
so
the
you
know
actual
root
of
dress
itself,
the
services
that
are
built
on
top
of
that
and
the
tooling
which
rely
on
which
relies
on
those
services
in
order
to
actually
make
attestations
about.
You
know
what,
how
and
that
how
artifact
was
built.
B
B
So
basically,
the
fundamental
the
core
projects
of
Sig
store
are
fulsio,
which
is
our
like
sort
of
general
purpose
certificate,
Authority.
Think
of
it
a
bit
like,
let's
encrypts,
but
for
binaries,
there's
recore,
which
is
our
transparency
log
it.
The
transparency
log
allows
us
to
do
something
very
interesting:
we've
been
very,
very
magical
which
is
keyless
signing,
which
is
to
say
you
create
a
key
pair.
You
sign
an
artifact
with
it.
B
B
Those
Turtles
are,
like
I,
said
the
root
of
trust,
full
Co
and
recore,
which
are
built
on
top
of
it
and
then
finally,
the
uses
that
you
put
them
to
so
a
couple
of
the
most
popular
utilities
that
we
have
put
out
currently
are
cosine
and
get
sign.
One
you
know
cosine
is
to
sign
container
images
and
also
add
attestations,
s-bombs
Etc
to
your
container
eye
like
to
your
container
images,
so
that
you
can
make
you
can
make
attestations
about
them
at
runtime.
B
And
this
this
is
where
oh
and
there's
also
good
sign,
which
is
pretty
self-explanatory.
You
can
sign
your
git
commits
good
stuff.
You
know
it's
always
been
really
difficult.
I,
don't
know.
If
any
of
you
have
had
to
manage
pgp
keys
in
order
to
like
get
old
old
style,
get
signing,
work
or
yeah.
It's
awful
use
a
good
sign
instead
and
do
it
you
should
do
it.
It's
super
easy!
Try
it
out
if
you
don't
like
it
money
back
but
the
way,
but
this
is
where
spiffy
comes
in.
B
If
you
really
really
really
want
to
make
it
easy
and
already
have
like
a
spiffy
fire-based
architecture.
Well,
Sig
store
loves.
You
too.
We
support
spiffy
identities
through
oidc.
If
you
happen
to
be
using
Spire,
they
have
a
reference
implementation
of
an
oidc
server
that
allows
you
to
translate
your
verifiable
identity
documents
into.
You
know
actual
identity,
tokens
and
you
know
a
test
identities
in
the
actual
spiffy.
You
know
parlance,
so
you
can
see
you
have
like
your
your
domain,
your
organization.
B
You
know
this
is
an
example
of
a
six-store
policy
controller
configuration.
So
it's
a
testing
the
identity
of
someone
that
assigned
a
container
image
in
this
case,
you
know
cluster
it
this
domain
in
this
namespace
with
you
know
the
service
account
that
kind
of
thing,
so
everything
you
would
expect
from
a
spiffy
ID.
It
just
works.
You.
A
Know
I
said
know
your
customers,
we
say,
know
your
robots.
We
want
to
make
sure
that
every
single
component
carrying
out
a
task
in
your
CI
CD,
has
been
strongly
attested
has
gone
through
that
workload.
Attestation
process
has
a
granular
canonical
identity
that
we
can
reason
about
understand
every
single
subject,
an
object
that
encompasses
the
the
build
pipeline.
B
So
this
is
where
a
demo
of
that
would
actually
go,
but
the
demo
Gods,
apparently
my
sacrifice
to
them,
was
found
wanting
and
I
was
smote.
So
here's
a
basically
a
basic
architecture
of
what
was
supposed
to
go
on
I'm
turning
the
demo
into
tutorial.
So
if
any
of
you
guys
would
actually
like
to
you
know,
put
this
into
practice
with
like
a
spiffy,
you
know
existing
spiffy
architecture.
B
B
It
is
using
this
verifiable
identity
document
within
the
workload
or
like
it.
It
has
access
to
the
Aspire
agent
that
work.
Sorry,
the
workload
has
access
to
this
by
our
agent
is
using
that
identity
to
like
ask
for
a
signing
certificate
from
Full
Co.
Full
Co
then
goes
back
and
asks
the
oidc
server.
That
you
know
is
the
Authority
for
these
identities.
Did
this
actually
come
from
you?
Yes,
all
right,
full
Co
will
meant
a
certificate.
The
cic
server
sends
it
to
recore.
Recore
gives
its.
B
You
know
its
own
transparency
log
entry,
then.
Finally,
the
cic
system
will,
and
basically
all
of
all
of
this
operations
with
full
Co
recore
and
the
OIC
oice
server
and
the
container
registry
all
happen
within
like
the
context
of
cosine,
so
like
a
single,
a
single
command
within
the
context
of
your
CI
CD
system
will
handle
all
that
for
you,
but
the
signature
is
good
at
container
registry.
B
That
part
is
done
once
the
workload
actually
wants
to
be
deployed
to
a
cluster.
That
is,
you
know,
being
managed
by
this
policy
controller.
You
do
a
cube.
Color
apply,
Dash
F,
you
know
some
pod.
The
policy
controller
will
resolve
that
image
to
its
digest.
It
will
look
for
the
signatures
on
that
Digest.
B
It'll.
Look
for
the
look!
Look
at
the
policies
like
the
one
described
in
the
previous
page.
It
will
look
at
the
signatures
for
that
image.
You'll,
say:
okay,
this
image
was
was
signed
by
the
workload
associated
with
this
spiffy
identity,
and
that
was
attested
by
this
identity.
Authority,
the
oice
server
all
good
and
we'll
let
it
run
so
that
that's
a
lot
of
work
for
like
all
of
two
commands
that
are
the
core
of
the
demo,
but
unfortunately
not
anyway.
So
here's
some
further
reading.
B
The
first
link
is
a
link
to
the
what
would
have
been
the
demo,
but
it
is
now
turning
into
a
tutorial.
If
you
follow
that
repo
I
promise
I
will
create
a
release
once
it
is
like
fully
ready,
I'll
actually
take
the
time
to
explain
all
of
the
pieces
and
how
they
fit
together.
So
if
you
already
have
a
pre-existing
infrastructure
that
you
would
just
like
to
put
Sig
store
into,
hopefully
that
will
be
a
good
resource
for
you.
B
C
If
you
can
go
back
to
your
demo
slide,
I
want
to
understand
which
component
is
actually
doing
the
digital
signing
and
which
is
actually
attaching
generating
and
attaching
what
do
you
call
them
attestations
here
and
I
understand
that
policy
controller
is
actually
validating
that,
but
in
the
process
where
my
code
is
getting
pushed
starting
from
that
point
to
the
you
know
to
the
repo,
how
is
it
getting
signed?
How
is
it
getting
attestation
attached
to
that
and
all
that
stuff
in
this
diagram
right.
B
So
you
could
just
imagine
that,
like
somewhere
within
the
CI
CD
system,
you
just
pretend
that
some
workload
has
access
to
the
cosine
binary
like
it
builds
a
container
image.
It
pushes
the
container
image.
Then
it
says
cosine
sine
that
image
and
that's
when
all
of
the
rest
of
this
stuff
happens.
That's
when
it
goes
out
and
gets
the
signing
certificate
from
Full
co
go
go
ahead
and
goes
ahead
and
asks
the
OS
oidc
server.
If
you
know
this
thing
is
real:
okay,
full
Co
gives
you
your
signing.
B
B
Finally,
you
know
once
all
of
that
is
done,
the
cosine
will
bundle
that
all
up
into
this
signature
manifest
upload
is
the
container
registry
in
like
a
well-known
area.
You
know
in
the
same
repository
as
the
image
that
you
have
pushed,
then
it's
all
done.
That's
like
the
that
could
be
the
end
of
the
cice
system,
but
usually
like
the
cd
part.
Is
you
know
after
cosine
sine
it
would
do
cubicle
apply
and
you
know
tell
the
cube
API
server
to
you
know,
then
pull
that
image.
B
That
so
like
at
a
station,
you
know
implying
stuff,
like
you
have
sent
it
through
like
a
vulnerability
analyzer,
for
instance,
what
you
can
do
at
the
same
time
is.
You
can
also
use
cosine
to
quote
unquote,
attach
attestations
like
that
which
are
just
like
a
special
flavor
of
certificate.
It's
just
a
certificate
with
you
know
a
more
interesting
signature
kind
of
so
the
really
the
only
difference
between
the
two
is.
You
know
what
commands
you
use
in
order
to
create
them,
but
you
can.
A
Every
single
one
of
these
components
has
been
pre-attested
by
spire,
so
the
moment
you
you
bring
up
the
setup
you
see
on
screen.
Each
of
these
would
have
called
the
local
workload
API
gone
through
that
selection
of
does
the
policy
match
in
order
for
these
workload,
for
this
workload
to
be
issued
an
identity,
that's
all
performed
by
Spire
agent,
that
generates
the
CSR
that
gets
sent
to
Spire
server
Spire
server
science
dead,
the
key
materials
propagated
back.
A
D
Sorry
here
so
clearly,
your
talk
here
was
about
the
code
and
the
progression
of
that
through,
but
I'm
just
curious,
assuming
you're,
using
an
oidc
system
for
authentication.
What
do
you
do,
then,
for
say
the
CI
system,
which
is
actually
building
the
images
that
are
being
loaded
into
the
Registries
and
say
Yes
it?
You
need
to
authenticate
that
the
code
going
into
those
is
good.
But
what
does
the
CI
system
itself
do?
D
B
B
D
You
know,
Shane
is
part
of
what
goes
into
I
mean
clearly
it
would
go
into
the
log,
but
is
that
also
part
of
the
signing
process?
In
other
words,
if
you
go
into
the
container
and
look
at
the
image,
is
there
some
kind
of
signatory
of
the
CI
and
that
chain
entirely
back
without
having
to
go
to
the
transparency
log
so.
B
Full
Co
actually
has
to
trust
the
oidc
server.
You
know
the
public,
the
public
instance
that
we
have
put
out
it
trusts.
You
know
Microsoft,
GitHub,
Google
and
a
I
think
one
exactly
one:
spiffy
based
public
oidc
endpoint
and
like
if
you
are
implementing
a
public
oidc
identity
Authority
there
is
a
utility
in
in
the
full
Co
repo
that
will
allow
you
to
create
a
PR
to
add
yourself
to
it.
B
But
the
alternative
is
just
standing
up
full
Co
on
your
own
and
that's
what
I
was
doing
for
the
demo
and
just
like
trusting
it
in
the
config.
So
you
you
know.
Obviously
you
have
like
the
the
SSL
route
of
trust
is
its
own
separate
thing,
but
you
also,
you
know,
add
a
configuration
for
like
this
is
the
specific
in
and
like
a
list
of
endpoints
that
I
trust
and
as
long
as
the
end
point
is
like
the
issuing
authority
in
the
identity.
Token.
B
E
B
That's
an
excellent
question
and
no,
they
are
not
so
like
I
said
you
have
to.
Oidc
providers
are
explicitly
trusted
in
the
config
for
full
Co.
There
is
one
like
a
trusted.
Oadc
providers
of
record
that
you
know
our
public
good
instance
uses
like
I
said
those
are
like
Google
Microsoft's
GitHub
et
cetera,
but
you
must
explicitly
trust
it.
There's!
No!
B
B
Sorry
one
thing
one
thing
I
did
not
include
in
this:
oh
actually,
yes,
I
did
okay,
so
you
can
see
that
the
you
have
you
may,
and
you
absolutely
should
explicitly
trust
an
issuer
in
your
like
client-side
policy,
like
the
specific,
the
specific
providers
that
are
allowed
for
you
know
in
in
Sig,
store's
own.
You
know,
you
know,
representative
full
Co
instance
are
just
things
that
make
sense
and
are
not
problematic,
but,
like
I
said
you
can
stand
up
your
own
and
you
can
do
anything
with
it.
B
E
So,
just
to
make
sure
I
understand
this.
So
let's
say
that
I'm
running
something
like
Pi
Pi,
slash
warehouse
for
the
python
Community,
where
anybody
can
go-
and
you
know,
get
an
account
and
do
things
like
this.
So
you're
saying
that
at
the
moment
that
as
a
developer,
I
decide
that
I'm
going
to
use
oidc
with
this,
then
how
does?
How
does
Pipi
slash
Warehouse,
indicate
that
then
that
identity
has
to
come
from
Google
and
couldn't
come
from
GitHub,
for
instance,
or
is
that
something
is
that
level
of
isolation
possible?
B
Yeah,
no
is
that
level
of
isolation
is
totally
possible.
It's
it's
in
the
issuer,
so
it's
like
you
know.
When
you
get
an
identity
token,
the
issuer
is
one
of
the
fields
in
you
know
this
gigantic
ugly
jot.
So
it's
it's.
There
is
an
ambiguity
unless
you
really
want
it
and
it
is
totally
totally
possible
to
you
know
narrow
down
the
like
explicitly
say:
no,
only
I,
only
these
identities
come
from
here.