►
From YouTube: Cloud Native Supply Chain Security with Tekton and Sigstore - Priya Wadhwa & Christie Wilson, Google
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.
Cloud Native Supply Chain Security with Tekton and Sigstore - Priya Wadhwa & Christie Wilson, Google
If you build software on Kubernetes and want to learn more about how to do it in a secure way, then this talk is for you! In this talk, Christie Wilson and Priya Wadhwa will provide a hands on overview to creating a secure zero-trust supply chain on Kubernetes. We'll show you how to use tools like Tekton, Tekton Chains and sigstore together to protect your pipelines and generate provenance for your builds. We'll also cover how the audience can integrate these tools with other projects like In-Toto and SPIRE to securely build, sign and verify software components today.
B
So
this
might
seem
like
it's
coming
out
of
the
blue.
Since
real
discussions
about
supply
chain
security
haven't
really
been
happening
until
the
past
couple
of
years,
but
the
reality
is
that,
even
if
it
wasn't
on
your
radar,
it's
been
a
big
problem
and
it's
definitely
something
you
should
be
paying
attention
to.
If
it
hasn't
affected
you,
yet
it
might
just
be
because
you've
been
lucky.
So
your
supply
chain
is
under
threat.
A
And
it
turns
out
that
these
supply
chain
attacks
are
far
from
theoretical.
There
are
more
and
more
of
them
all
the
time,
a
recent
report
released
by
sonotype
and
since
we're
recording
this
in
advance.
We
don't
know
if
other
people
have
been
mentioned
this
in
their
talk,
so
this
might
be
the
fifth
time
you've
heard
about
this,
but
this
recent
study
shows
that
there's
a
650
year-over-year
increase
in
supply
chain
attacks.
B
B
A
A
A
Tasks
declare
the
parameters
that
they
need
to
run
and
they
also
declare
the
results
which
they
produce
after
they
finish
together.
These
parameters
and
results
make
up
the
interface
of
each
task
we
on
this
slide.
You
can
see
an
example
of
a
task
that
declares
two
parameters:
an
image
and
a
docker
file,
and
it
declares
that
after
it
executes,
it
will
produce
two
results:
an
image
url
and
an
image
digest.
A
By
themselves,
tasks
don't
do
anything
in
order
to
actually
execute
them.
You
have
to
create
something
called
a
task
run
which
invokes
a
task.
The
task
run
provides
the
parameters
that
satisfy
the
task
runs
interface
and
in
the
status
of
the
task
run,
you
can
find
the
values
of
the
results
that
are
produced
when
a
task
executes.
A
So
in
this
example
task
run.
You
can
see
that
for
the
image
and
docker
file
parameters
that
the
task
declared
we're
providing
the
actual
values
of
the
image
we
want
to
build
and
where
the
docker
file
is
located
and
once
the
task
run
finished,
it
produced
two
results:
the
image
url,
which
is
the
same
as
the
one
we
intended
to
build
and
the
image
digest
of
the
image
that
was
actually
built.
A
So
what
this
means
is
that
if
you
can
observe
the
execution
of
a
task
run,
there's
some
things
that
you
know
you'll
know
when
the
task
run
is
completed.
You'll
know
what
happened,
because
you
can
see
the
task
and
the
steps
that
were
executed
and
then
via
the
task
results.
You
can
know
more
information
like
what
artifacts
were
produced
in
the
example
of
the
one
we
were
just
looking
at.
You
know
what
image
was
built.
B
Cool,
so
this
is
where
tecton
chains
comes
in,
so
at
this
point
you've
done
all
this
cool
stuff
that
chrissy
just
talked
about.
You've
run
your
task
run
and
you've
built
an
image
and
push
it
to
your
registry
and
at
this
point
touchstone
chains
comes
in,
so
you
can
think
of
tekton
chains
as
the
supply
chain,
security
manager
for
techton,
and
it
basically
runs
alongside
tecton
in
your
kubernetes
cluster,
but
it
acts
once
your
task
run
has
completed.
B
So
once
your
task
run
has
completed.
Tecton
chains
will
look
at
your
task,
run
and
it'll
try
and
see.
If
there's
any
artifacts
in
there
that
it
recognizes
so
examples
of
an
artifact
that
might
recognize
could
be
a
an
image
it'll.
Take
that
image
and
it'll
try
to
sign
it
and
it'll
also
generate
signed
provenance
for
your
entire
build.
B
So
how
does
chains
actually
sign
your
code?
So
this
is
where
something
you
might
have
heard
of.
Six
store
comes
into
play,
so
chains
actually
leverages
each
of
the
tools
and
services.
Six
store
provides
to
make
signing
your
software
really
easy.
So,
under
the
hood,
zig
store
uses
cosign
to
sign
both
images
and
out
of
stations.
B
It
uses
recore,
which
is
the
public
transparency
log,
provided
by
six
store
to
store
records
of
those
signatures
and
of
the
providence
attestations,
and
it
even
has
experimental
support
for
using
full
co,
which
is
the
six
store
certificate
authority
to
generate
certificates
for
software.
And
this
is
nice
because
it
allows
you
to
sign
your
software
without
having
to
set
up
keys
or
manage
public
keys.
B
Tecton
chains
does
improve
on
that.
A
little
bit
tucked
on
chains
is
constantly
observing
your
tecton
pipeline
waiting
for
your
task.
Friends
to
finish,
and
as
soon
as
they
finish,
it
attempts
to
extract
images
and
sign
artifacts
for
you,
but
unfortunately
there
actually
is
a
vulnerability
in
this
in
the
system,
and
the
reason
for
that
is
that
tecton
is
built
on
top
of
kubernetes
and
to
some
extent
we
are
also
trusting
kubernetes
when
we're
trusting
tecton.
B
The
problem
here
is
that
anyone
with
access
to
your
kubernetes
cluster
can
go
in
and
edit
a
task
run.
So,
for
example,
if
I'm
the
admin
of
my
kubernetes
cluster,
I
could
go
in
and
edit
every
task
run.
I
see
to
say
that
no
image
was
built
or
to
say
that
a
different
image
was
built.
Tucked
on
chains
will
pick
up
on
that
task
run
believe
whatever
it's
saying
and
attempt
to
sign
and
generate
provenance
for
that
image.
B
B
So
when
you
include
spire
as
part
of
your
entire
supply
chain,
you're
signing
you
can
use
signatures
to
attach
software,
but
you
can
also
use
signatures
to
attest
the
hardware
that
you
are
running
on,
so
it
provides
node
and
workload
attestations
and
basically
allows
you
to
prove
that
the
pod
that
you
ran
on
a
certain
node
is
actually
the
pod
that
was
run
so
with
spire.
We
can
be
sure
that
a
task
run
is
what
it
claims
to
be,
and
this
basically
eliminates
the
need
to
trust
the
task
run
in
and
of
itself.
A
A
A
Chain
levels
for
software
artifacts,
okay,
so
salsa
is
a
standard.
That's
all
about
creating
levels
that
allow
you
to
communicate
kind
of
what
level
your
supply
chain
is
at.
The
end
goal
is
that,
ultimately,
what
you
really
want
is
to
have
code
bases
that
are
auditable
and
can't
be
changed
by
one
person
that
are
used
to
define
both
the
source
code
that
you
build
and
the
way
that
you
build
it
along
with
verified
provenance
along
with
hermetic,
builds
and
changes
that
are
logged
and
reviewed
by
at
least
two
people.
A
So
all
of
this
sounds
like
an
awful
lot
and
that's
again
why
salsa
is
divided
up
into
levels,
because
you're
you're,
probably
not
going
to
get
to
the
highest
hermetic,
build
level
right
away.
But
this
way
you
have
somewhere
to
start
so
the
left,
the
levels
of
salsa
are
the
first
one
is
just
about
having
provenance
so,
basically
being
able
to
look
at
your
builds
and
knowing
where
everything
came
from
and
how
it
was
built,
but
not
necessarily
signed
level.
A
Two
is
all
about
having
that
provenance
but
having
it
signed
and
then
having
an
element
of
tamper
resistance.
So
the
actual
source
code
and
the
definitions
of
the
bills
themselves
are
all
hosted
somewhere
and
then
from
there
we
can
increase
the
levels
by
adding
non-falsifiable
provenance
and
then,
ultimately,
in
the
end
level,
four,
your
builds
are
hermetic
and
everything
is
reviewed
and
you
can
completely
trust
the
providence,
but
we're
not
going
to
go
that
far
today.
Let's
talk
a
little
bit
about
salsa
level,
one
so
salsa
level.
A
One
is
all
about
fully
automating
your
build
process.
This
means
that
all
of
you
you're
not
running
anything
manually,
you
have
some
kind
of
script,
that's
defined.
That
shows
exactly
what's
going
to
execute
and
every
time
you
create
an
artifact.
You
generate
provenance
for
that
artifact.
That
explains
how
it
came
into
being
the
next
level.
Up
from.
A
So,
what's
great
is
with
tecton
chains
as
long
as
you're
using
version
control,
which
you
definitely
should
be
but
taking
something
we
could
take
that
for
granted
for
a
moment
which
I
know
isn't
true
for
everyone.
So
if
you
want
to
start
somewhere,
definitely
start
with
version
control,
but
assuming
we've
got
version
control
in
play.
If
you
add
techton
chains,
you
can
get
salsa
level
2
right
out
of
the
box
and
then
with
the
addition
of
spire
as
prio
was
discussing,
you
can
actually
be
on
your
way
towards
salsa
level.
Three
priya.
B
It
okay,
I'm
going
to
do
a
quick
demo
now
to
kind
of
show
how
we
can
bring
all
of
these
tools,
tecton
chains
and
spire
together.
So
I've
already
got
a
cluster,
so
my
current
setup
is:
I
have
a
cluster
with
techdown
chains,
text
on
pipelines
and
spire
installed,
and
the
first
thing
I
want
to
do
is
create
a
task
run,
that's
going
to
build
and
push
an
image
for
me
and
then
we're
going
to
use
chains
to
kind
of
sign
that
image
and
generate
some
signed
provenance
for
it
as
well.
B
B
B
B
B
B
By
now,
change
should
have
probably
finished
running,
so
we
can
see
some
interesting
stuff
in
the
actual
task
run
description.
So
the
first
thing
is
this:
annotation
that
chain's
added,
which
is
just
that
it
was
actually
signed.
There
was
no
failure,
no
error,
as
chains
was
running,
and
it
actually
also
adds
a
second
annotation
which
points
to
a
log
index
in
the
record
transparency
log.
B
So
while
the
task
run
was
executing
when
we
created
when
we
stored
a
result
on
the
task
run,
we
actually
also
requested
a
signature
from
spire
to
kind
of
attest
that
this
is
that
this
result
is
correct,
and
this
is
actually
what
happened
so
for
each
result.
There's
an
associated
signature,
proving
that
the
result
is
correct.
B
We
also
have
an
estimate
which
is
kind
of
like
a
certificate
that
spire
provided
stored
as
a
result
and
we're
going
to
use
the
search
and
change
will
use
the
certificate
to
verify
the
signatures
of
the
results
against
the
results
themselves.
If
all
of
this
verification
checks
out,
that's
when
chains
knows
that
the
task
run
wasn't
modified,
that
nobody
went
in
and
changed
it,
and
so
chains
knows
that
it's
safe
to
sign
the
image
and
generate
the
signed
provenance.
B
B
It
should
be
in
the
tecton
change
namespace
and
it's
called
signing
secrets.
So
this
holds
the
private
and
public
key
pair
that
was
used
for
signing
and
I
actually
have
the
public
key
just
on
my
computer
as
well.
So
we're
going
to
use
this
to
verify
all
of
our
signatures.
So
the
first
thing
we
want
to
do
is
verify
the
image
itself,
and
hopefully
it
was
called
and
a
good
change
demo.
A
B
B
Okay,
great
okay,
so
against
the
public
key,
the
image
was
actually
signed
and
then
we
can
also
use
cosine
to
verify
the
provenance
was
signed
as
well
and
so
cosine
verify
attestation
should
work
as
well
great,
and
so
it
does
and
there's
some
information
about
the
payload
itself,
which
you
can
basically
forward
to
decode
and
see
what
the
attestation
itself
was
now
say.
I'm
a
consumer
of
this
image
and
I
need
to
learn
more
about
how
it
was
built,
or
I
want
to
know
like
what
techton
task
actually
built
this
image.
B
B
B
B
We
have
a
step
corresponding
to
every
single
step
in
the
task
itself,
so
we
have
the
step
where
we
created
our
docker
file,
the
canico
step
where
we
built
and
pushed
the
image
and
then
the
final
step
where
we
actually
wrote
the
url
to
the
result
and
some
information
about
when
the
build
was
started
and
when
the
build
was
finished.
So
this
is
kind
of
nice,
because
maybe
in
a
few
weeks
or
a
few
months
after
you
know,
the
task
has
been
deleted
from
your
cluster.
B
So
what
can
you
do
now
that
you've
listened
to
this
talk,
go
ahead
and
try
out
tekton
chains
if
you've
got
titan
running
in
your
cluster,
you
can
follow
along
with
our
getting
started
tutorial
or
our
signed
provenance
tutorial,
and
actually,
I
think,
if
you
do
everything
in
our
slime,
providence
tutorial
and
start
applying
it
to
your
actual
builds.
You
should
be
able
to
achieve
salsa
too
pretty
easily
yeah,
and
then
you
can
pin
this
cool
looking
metal
on
your
own
gala
repo.
It's
also
two
quickly.
Let's
go.