►
From YouTube: Hands-on Introduction to sigstore | Rawkode Live
Description
In this episode, Dan guides us through everything we need to get started with Project sigstore.
🍿 Rawkode Live
Hosted by David McKay / 🐦 https://twitter.com/rawkode
Website: https://rawkode.live
Discord Chat: https://rawkode.live/chat
#RawkodeLive
🕰 Timeline
00:00 - Holding screen
01:15 - Introductions
03:00 - What is Project sigstore?
11:30 - Signing & Verifying Container Images with cosign
34:00 - cosign: keyless mode
41:00 - Transparency Logs with rekor
55:00 - Using Kyverno for Signed Image Policies
👥 About the Guests
Dan Lorenc
OSS Supply Chain Security at Google!
🐦 https://twitter.com/lorenc_dan
🧩 https://github.com/dlorenc
🌏 https://www.danlorenc.com/
🔨 About the Technologies
sigstore
sigstore is a Linux Foundation project.
sigstore is a project with the goal of providing a public good / non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing, backed by transparency log technologies.
sigstore will seek to empower software developers to securely sign software artifacts such as release files, container images, binaries, bill of material manifests and more. Signing materials are then stored into a tamper resistant public log
sigstore will be free to use for all developers and software providers, with sigstore’s code and operation tooling being 100% open source and maintained / developed by the sigstore community.
🌏 https://sigstore.dev
🐦 https://twitter.com/projectsigstore
🧩 https://github.com/sigstore
##SupplyChain
A
A
First,
we've
got
a
little
bit
of
housekeeping
before
we
dive
into
project
six
store
supply
chain
for
kubernetes
containers
and
other
things.
Now
the
housekeeping
involves
first
subscribing
to
the
channel,
if
you're
not
already
subscribed
to
the
rockwood
academy.
Please
do
so
now
click
the
bell
and
you
will
get
notifications
and
alerts
for
all
new
episodes
as
we
explore
the
cloud
native
landscape
together.
A
A
A
B
Sure
yeah,
I'm
a
software
engineering
lead
at
google.
I
work
on
our
open
source
security
team,
so
my
job
for
the
past
couple
of
years
has
been
trying
to
make
it
easier
to
build
open
source
software
securely,
make
it
easier
for
google
and
all
of
our
customers
to
use
it
securely
and
not
have
to
worry
about
these
nasty
supply
chain
attacks
that
keep
happening
and
are
all
over.
The
news.
A
B
Yeah
it's
a
good
question,
so
sleekstore
is
a
little
complicated
of
a
project.
It's
got
a
bunch
of
different
components
and
a
bunch
of
different
entry
points,
depending
on
exactly
what
type
of
software
you're
trying
to
build
or
consume,
or
anything
like
that.
So
we're
going
to
start
with
all
these
intros
with
the
cosine
tool.
The
cosine
tool
is
called
cos
ign
and
it's
designed
to
make
signing
and
verification
of
container
images
really
really
easy
here,
we'll
start
there,
because
this
is
a
cloud
native
stream.
B
So
let's
encrypt
that
out
a
few
years
ago
to
make
it
easy
and
free
to
get
ssl
certificates,
because
before
that
they
were
expensive
and
hard
to
get,
and
so
people
weren't
doing
it.
So
web
traffic
was
insecure.
They
made
it
free,
easy
and
automatic,
and
now
something
like
98
of
all
web
traffic
is
encrypted,
because
people
want
to
do
the
right
thing.
If
it's
easy
and
free,
we
see
the
same
thing
in
open
source
code
and
software
supply
chains.
Today,
where
there
are
some
kind
of
existing
code
selling
systems
but
they're
really
expensive.
B
It's
like
500
bucks
to
get
a
certificate
to
sign
your
code
to
ship
it
for
different
operating
systems
and
platforms.
So
most
people
just
don't
do
it,
especially
in
large,
open
source
projects
where
you
know,
there's
not
even
a
business
that
could
be
verified
and
that
kind
of
thing
behind
these
projects.
B
So
we've
got
a
certificate
authority
that
we're
going
to
be
playing
around
with
today
to
get
some
code
signing
certificates
issued
based
on
your
email,
address
a
bunch
of
different
tools
inside
of
cosine
2,
to
sign
images
with
yubikeys
and
kms
systems
and
kubernetes
secrets,
and
all
that
fun
stuff.
So,
depending
on
exactly
how
you're
getting
the
image
who's
producing
and
who's
signing
it,
we've
got
tools
and
flags
and
features
for
all
of
that
here
that
we'll
be
walking
through
and
then
we'll
be
explaining.
How
kind
of
the
six
store
infrastructure
makes
all
this
possible.
A
Awesome
quite
a
lot
there
we
could
probably
dive
into
them.
I
think
the
the
first
thing
I
wanted
to
see
like
what
the
fuck
the
deal
with
prices
of
search
10
years
ago
I
mean
I
remember,
working
for
sorry.
I
don't
mean
to
swear
it's
only
afternoon
here,
but
I
remember
working.
You
know
10
years
ago
even
longer
and
you
had
to
go
buy
all
of
these
stairs
and
there
were
like
500
plus.
A
If
you
went
with
a
reputable
company
to
get
your
website
delivered
over
ssl
as
it
was
back
then,
but
and
now
it's
just
something
that
if
anyone
knew
the
development
has
let's
encrypt
available,
it's
just
an
absolute
game
changer.
So
it's
really
cool.
I
wouldn't
complain
about
it.
I
won't
run
up
a
ev
series
either
I'll
leave
that
for
another
day,
but.
B
A
Yeah,
but
we
are
talking
about
supply
chain
right
and
that's
one
of
the.
I
think
we've
seen
that
a
lot
over
the
last
12
months.
I
mean
how
many
supply
chain
checks.
I
mean,
I
only
know
what
I've
seen
in
the
news,
which
is
probably
the
more
high
profile
ones,
but
I'm
assuming
you
may
have
more
visibility
into
what's
actually
going
on
in
the
ecosystem.
Right
now
like
this
is
a
really
prominent
problem
right.
B
Yeah
they've
been
happening
for
years.
They've
been
accelerating,
I
think,
for
a
couple
reasons:
open
source
is
getting
more
and
more
widely
used,
which
is
great
for
open
source,
but
more
companies
are
using
it.
Not
all
open
source
has
a
lot
of
people
working
on
it.
A
lot
of
people
looking
at
it.
Unfortunately,
there's
kind
of
this
misconception
that
if
it's
on
github
and
the
project
has
a
bunch
of
stars,
then
there
are
going
to
be
no
bugs
inside
of
it
as
a
maintainer
of
a
bunch
of
projects
with
a
bunch
of
github
stars.
B
I
can
tell
you
that's
incorrect.
All
of
my
code
has
bugs
all
of
the
code
you're
using
has
bugs
in
it
and
so
yeah
the
supply
chain
attacks
either
through
you
know
bugs
that
are
put
in
unintentionally
or
the
scarier
ones.
Where
people
kind
of
take
over
github
accounts,
they
steal
credentials
to
container
registries,
are
coming
they're
coming
quick.
B
C
B
Tampered
with
changed
any
of
those
packages
in
there
they're
not
really
signed
today,
so
nobody
would
have
known.
Thankfully
he
reported
it
got
these
issues
fixed,
got
the
github
actions
locked
down
a
little
bit,
but
that
would
have
been
a
really
really
scary
one
there's
a
similar
one.
I
think
it
was
even
the
same
person
actually
with
microsoft.
Vs
codes,
github
repository
got
right,
permissions
to
branches
there
that
would
have
triggered
releases
and
pushed
out.
You
know
malicious
versions
of
vs
code.
B
B
B
B
That's
pretty
cool
in
some
ways,
but
it's
also
scary,
because
anybody
that
spent
time
on
the
internet
knows
that
not
everybody
on
the
internet
is
a
nice
person,
so
you're
taking
code
from
you
know,
potentially
bad
people
and
running
it
and
even
worse,
you
don't
even
know
where
the
code
is
coming
from
for
the
most
part,
if
you're
docker
pulls
some
container,
you
have
no
idea
where
that
came
from.
If
the
code
even
actually
came
from
the
repo
with
it.
B
It's
paired
to
the
you
know,
docker
registry
or
anything,
and
so
that's
kind
of
around
transparency
and
not
actually
understanding
what
our
supply
chains
are
and
that's
the
angle
we're
trying
to
address
with
six
doors.
So
if
you've
got
a
container,
you
can
figure
out
exactly
how
it
was
built.
What
code
went
into
it?
B
What
build
steps
were
run
that
kind
of
thing
that
doesn't
make
it
secure?
It
just
means
you
understand
the
supply
chain,
that's
kind
of
the
first
step
in
securing
your
supply
chain.
There
could
still
be
malware
checked
into
that
github
repo,
but
today
you
can't
even
find
the
github
repo
to
look
for
malware
in
most
of
these
cases.
B
So
the
second
half
of
open
source
software
and
security
is
that
it's
software
and
it
has
bugs
some
intentional,
some
unintentional,
so
64
isn't
going
to
secure
everything
completely
right.
There
could
still
be
bugs
there
could
still
be
cves,
but
at
least
we're
hoping
to
give
you
the
tools
to
understand
what
versions
of
code
you're
running
where
it
came
from
that
kind
of
thing.
So
you
can
start
addressing
that.
Second
problem.
B
That's
a
really
really
good
way
to
put
it
yeah
and
it's
controversial,
and
it
comes
up
a
lot
about.
You
know
that
strategy
of
how
often
should
I
be
updating
that
kind
of
thing,
I'm
on
the
opinion
that
yeah
you've
got
to
be
updating
frequently
it
does
put
you
at
risk
in
some
cases,
it's
a
lot
of
work.
B
It's
tough,
but
I
think
you
just
have
to
be
doing
these
updates
otherwise
you're
behind
you're
going
to
get
hit
with
these
cvs
that
are
found
years
later,
and
then
you
can
get
yourself
into
a
position
where
you've
got
years
of
code
to
try
to
update
all
at
the
same
time,
which
is
really
tough.
It's
it's
really
bad.
It's
embarrassing!
When
you
get
hit
with
one
of
those
two,
the
forgot
to
update
struts,
that's
been
running
here
and
now.
Everybody's
credit
card
date
has
been
leaked.
B
A
Nice
well
easier
and
less
scary
sounds
good
to
me.
So
why
don't
we
dive
in
and
get
started?
Then?
Let
me
pop
up
my
screen
share.
We're
still
here.
We've
got
the
six
other
website
here
and
you
suggested
that
we're
going
to
start
by
taking
a
look
at
the
cool,
sound
project
first
to
play
around
with
some
container
image
scanning.
So
we'll
do
that
right
away
to.
A
A
B
B
This
all
just
works
with
any
docker
registry
you're
going
to
be
playing
around
with
today,
there's
a
quick
little
demo
that
you
know
kind
of
scrolls
there
showing
the
simplest
way,
but
there's
about
37
different
ways
to
kind
of
generate
and
manage
the
keys
that
we're
going
to
be
using
for
signing
stuff
here.
This
is
the
simplest
one.
It
just
kind
of
throws
one
in
a
file
on
your
disk.
So
that's
probably
the
one
we
should
start
out
with.
If
you
want
to
give
it
a
try,
but
we've
got
some
other
cool
ones.
B
B
A
C
A
B
Something
I
can't
remember
what
it
was,
but
they
switched
it
over
to
ghcr,
so
the
github
container
registry,
so
homebrew
uses
an
oci
registry
to
store
all
of
the
binaries
for
mac
stuff,
just
because
it's
free
and
it's
everywhere,
and
it's
really
easy
to
put
stuff
in
it.
So
these
aren't
containers
you're
installing
with
homegroup
for
the
most
part
but
they're
just
kind
of
hijacking
and
using
oci
registries
anyway,
which
is
cool.
A
A
A
So
we
got
a
couple
of
comments
already
so
kevin
or
the
it's
saying
looks
really
similar
to
how
rpm
works.
I'm
not
sure
how
rpm
works
myself,
but
I'll
trust.
You
take
your
judgment
there.
Kelly
jack
is
telling
me
to
use
next.
I
can't
because
I
stupidly
upgraded
to
the
macos
beta
and
now
nothing
works
except
my
streaming
software,
so
they
tuned
for
a
little.
A
B
B
Good
question
yeah,
so
it's
probably
referring
to.
I
have
a
little
toy
admission
controller.
I
was,
I
wrote
to
just
kind
of
learn
how
builder
and
the
new
admission
controller
stuff
the
sdk
is
all
put
work
together.
I
called
it
cosigned
c-o-s-I-g-n-e-d
to
check
the
make
sure
it
is
resigned.
I
you
know
didn't
write
tests.
The
code
barely
works,
I
stuck
it
up.
There
didn't
want
to
put
it
into
the
real
estate
store.
B
I
think
I
wasn't
sure
if
people
would
use
it
if
it
was
worth
spending
more
time
on,
but
then
people
started
filing
bugs,
of
course,
you
know
which
happens
with
open
source
and
running
in
production
and
all
that
scary
stuff.
I've
got
to
figure
out
if
I
want
to
take
it
down
or
actually
move
it
over
into
the
org.
A
A
A
B
A
C
A
B
B
Hopefully,
it'll
match
yeah
there
we
go
cool
all
right
so
now
you've
got
two
new
files
on
disk
here
which
I'll
explain
quickly
and
we
can
show
to
people.
This
uses
cosign
uses
digital
signatures,
which
means
you
get
two
different
keys.
There's
a
public
key
and
a
private
key.
The
public
key
is
the
one
you
publish
you
distribute
that
one
widely
anybody
that
wants
to
check
your
images
can
check
the
signatures
against
that
public
key.
So
if
you
just
want
to
cap
that
we
can
see
what
it
looks
like.
B
Cool
yep,
so
that
this
is
the
public
key,
that's
it!
It
uses
elliptic
curve
cryptography.
If
you're
into
that
and
some
details
here
but
yeah
we
picked
some
good
defaults.
There
are
no
real
flags
here.
We
only
support
a
couple,
different,
algorithm,
combinations
and
stuff.
Like
that,
that's
the
public
key,
it's
pretty
small!
That's
the
thing
you
have
to
publish
and
send
around
to
let
people
check
against
now.
Let's
take
a
look
at
the
secret
key
too.
So
I
said
this
is
secret,
but
it's
encrypted
with
that
password.
B
A
B
B
B
B
B
It
depends
what
you
have
access
to
and
what
you're
trying
to
convey.
I
guess
there
are
a
bunch
of
different,
you
know
reasons
to
sign
things
and
it's,
but
there's
a
lot
of
confusion
around
exactly
what
you're
trying
to
express
with
the
signature
really
at
the
base
level.
All
it
means
is
that
whoever
had
access
to
that
private
key
signed
the
thing
doesn't
mean
it's
good,
it
doesn't
mean
it's
safe.
B
You
can
also
use
something
like
a
yubikey.
There
are
some
commands
for
that.
If
you've
got
one
instead,
which
means
that
people
can't
steal
that
from
you,
unless
they
actually
take
the
token,
so
you
don't
have
to
worry
about
losing
it.
The
kms
stuff
is
great.
If
you're
in
a
cloud
environment,
it's
better
than
storing
the
password
somewhere
else
in
a
secret
manager
or
that
kind
of
thing,
but
there's
some
downsides
there
too,
which
is
like
how
many
times
have
people
screwed
up.
B
I
am
on
their
aws
cluster
or
their
gcp
environment,
or
whatever
you're
kind
of
trading
off,
not
having
to
lose
the
key
with
making
sure
that
you
get
the
iam
and
the
r
back
and
all
those
rolls
right
so
that
you
know
you
don't
make
it
too
broad.
So
people
can
start
using
the
key.
So
there's
some
trade-offs
either
way.
B
Awesome
yeah,
so
all
the
credentials
the
docker
users
are
set
up
in
this
kind
of
global
credential
helper
file.
That's
pretty
well
understood,
so
most
tools
just
know
how
to
work
with
that
once
you've
done
the
docker
log
and
stuff
awesome,
it's
not
signed
let's
well.
Naturally,
we
should
probably
just
verify
that
first
before
we
move
on
and
jump
in
and
show
exactly
what
happened.
Yes,
let's
try
the
other
half
there.
You
can
type
cosine
verify
and
then
you'll
see
all
the
different
options
we
have
here.
A
I
know
I
picked
a
different
version
there.
I
just
wanted
to
see
what
happened
all
right,
so
it
says
so.
First
of
all,
when
I
use
the
version
that
wasn't
signed,
we
just
get
some
sort
of
name
unknown,
so
it
doesn't
know
that
something
in
this
oci
registry
exists
a
signature,
I'm
not
sure
how
those
signatures
work
with
the
registry,
but
maybe
it's
not
important.
A
B
B
B
So
we
hide
these
things
inside
of
the
registry,
the
signatures
and
what
we
do
is
with
a
cool
little
naming
convention,
which
should
make
sense
in
a
second.
So
the
image
we
signed
was
clustered
colon,
v1
or
sorry
v2,
and
the
way
a
registry
works
is
that
there
are
tags
and
digests.
They
refer
to
an
image.
The
tag
is
kind
of
mutable,
it's
just
a
string,
but
it
points
to
a
fixed
sha-256
digest
for
that
image.
B
They
can't
move
around
the
way
we
find
the
signature
for
an
image
is
that
we
take
that
digest
the
thing
that
can't
move
and
we
turn
that
into
a
tag
and
attack
a
little
suffix
there
at
the
end
of
the
dot
sig.
So
if
we
want
to
find
the
signature
for
clustered
colon
v2,
we
first
resolve
that
to
a
digest
and
that's
what
the
cosine
triangulate
commanded
and
then
we
turn
that
digest
into
a
tag
with
the
colon.
Instead
of
the
at
sha256
thing
there,
and
then
we
add
the
dot
sig.
B
B
Cool
and
then,
if
you
have
jq,
you
could
pipe
it
to
that.
So
it's
more
readable
cool
perfect.
So
this
looks
like
a
normal
docker
image
or
an
oci
image.
You
can
see
it's
got
the
layers,
except
instead
of
having
you
know,
a
tire
ball
that
would
unpack
into
your
system.
We
just
cram
a
little
signature
in
there
instead,
so
that
that
annotation
is
the
signature
is
just
that
base64
encoded
string,
the
meq
thing.
B
If
you
take
that
and
look
at
it,
it's
just
the
random
bytes
that
were
generated
by
the
signing
algorithm
and
then
the
layer
itself
is
a
blob.
You
can
see
the
digest
for
it,
and
that
is
the
little
payload
we
signed.
So
when
we
did
verify
up
above,
we
got
that
json
that
spit
out
on
that
last
line.
That
is
the
thing
we
signed
so.
B
B
B
So
if
you
go
back
to
your
sign
command,
you
can
add
in
dash
a
and
just
make
up
a
little
probably
have
to
put
it
before
the
image
name,
because
that's
just
a
positional
yeah
perfect,
if
you
just
do
foo
equals
bar
whatever
you
want
to
do,
you
could
put
in
a
git
commit
you
could
put
in
a
release
version
here.
You
could
put
in
anything
kind
of
more
meaningful
than
just
signing
the
image
itself.
You
could
say:
lgtm
equals.
B
C
B
Verify
now
pretend
you
wanna,
you
know
only
check
things
with
foo
equals
bar.
You
can
add
that
into
the
dash,
a
and
it'll
only
show
you
ones
with
that
matching
thing.
So
people
built
up,
you
know
pretty
good
workflows
with
this
to
sign
specific
releases
and
then
check
specific
releases
or
you
can
put
in
container
vulnerability
scans
or
anything
else.
You
kind
of
want
to
write
up
in
your
policy
engine.
A
I'm
curious
right
like
this
is
a
random
image
that
I've
pushed
to
register
in
the
past,
but
I
mean
I
have
no
idea
really
if
that
was
even
still
my
image
like
what
would
be
the
actual
workflow
that
we
would
encourage
people
to
use
requesting,
should
they
build
it,
sign
it
and
then
push
it
to
the
registry,
or
do
they
build
a
picture
to
register
and
then
saying
that
like?
Would
you
recommend
there.
B
B
Your
build
system
usually
knows
the
digest
of
the
image,
and
so
you
just
have
the
build
system
sign
it
at
the
same
time.
So
if
your
build
system
gets
hacked
or
something
like
that,
you're
not
really
protected,
but
as
soon
as
it
leaves
that
build
system.
You
at
least
know
that
that
image
is
the
same
one
that
left
the
build
system.
There's
a
github
action.
We
have
a
cosign
installer
that
throws
it
into
a
github
action.
B
If
you
want
to
use
that
and
then
because
github
actions
gives
you
those
cool
personal
access
tokens,
then
you
don't
even
need
to
set
up
author
anything
like
that,
if
you're
pushing
and
signing
stuff
in
ghcr,
depending
on
your
build
system,
you
can
plug
in
other
stuff.
Techton
cd
is
a
kubernetes
native,
see
a
cd
platform
that
actually
has
built-in
support.
B
Some
other
companies
in
kind
of
regulated
industries
and
financial,
stuff
and
healthcare
need
to
make
sure
that
you
know
two
people
have
approved
each
change
that
goes
to
prod
that's
kind
of
a
different
flow
and
a
lot
of
people
there
use
like
two
different
yubikeys
and
two
different
people
have
to
sign.
The
image
is
the
very
last
step,
so
that's
kind
of
like
it's
been
built,
that's
been
tested,
it's
been
in
our
qa
environment
for
a
while.
Now
we
have
to
have
two
out
of
these.
B
You
know
seven
people
sign
it
with
their
own
yuba
keys
as
the
last
step,
so
you
can
kind
of
build
up
workflows
with
you
know,
different
levels
of
signatures
coming
from
different
places.
There's
no
real
one
size
fits
all
approach,
but
I
think
for
most
people
they
want
that
first,
one
of
just
signing
the
stuff
that
left
their
build
system.
A
A
B
C
B
B
Yeah,
that's
another
good
question
with
this
flow.
What
we
did
is
we
stored
the
signatures
right
in
the
same
repository
as
the
image,
so
literally
right.
Next
to
them
we
did
the
triangulate
command
so
yeah.
You
need
that
permissions
to
push
to
that
one
that
doesn't
work
for
some
people
where
they
don't
want
their
developers
to
have
permissions
to
these
registries
only
their
build
systems.
B
So
there
are
some
flags
to
kind
of
redirect
and
store
them
in
a
different
one,
so
it
still
uses
that
same
naming
convention,
except
instead
of
you,
know,
ghcr
slash
raw
code.
It
would
be
something
like
ghcr
raw
code
signatures
and
you
would
say
I'm
going
to
store
all
my
signatures
here,
so
my
devs
can
push
to
there,
but
not
to
the
bucket
where
the
containers
themselves
are
stored.
C
B
Yeah
another
good
question,
the
yubikey
stuff,
depending
on
your
os
and
your
platform,
sometimes
needs
some
native
c
libraries
to
actually
work
correctly
with
the
drivers
on
mac
and
windows.
I
believe
it
just
kind
of
works.
There
are
some
go
build
tags
for
linux,
where
you
do
need
to
have
some
special
dependencies
installed.
It
doesn't
run
by
default
on
stuff
like
alpine,
so
we
publish
two
different
builds
for
linux.
B
Yes,
we
actually
store
all
the
signatures
in
the
same
blob,
so
yeah
triangulate
just
points
to
the
blob
thing
that
has
all
the
signatures.
When
we
saw
the,
if
you
do
the
crane
manifest
again
command,
we'll
see
now
that
there
are
going
to
be
two
layers
the
first
time
there
is
just
one
layer,
so
all
the
layers
just
kind
of
get
appended
up
into
this
list.
B
So
it
shows
you
the
address
for
all
of
those
and
then
we
kind
of
go
through
and
verify
them
against
the
key.
We
did
both
of
these
signatures
using
the
same
key,
but
you
could
imagine
two
different
people
with
two
different
keys
assigning
it
and
you
would
kind
of
see
all
those
appended
up
and
we'd
filter
through
them,
as
we
do
verify.
C
A
B
B
Let's
do
this
is
the
cool
experimental,
keyless
mode
that
I
like
to
call
it.
We
just
did
some
signing
with
keys,
but
now
we're
going
to
do
something
with
out
keys,
so
we
need
to
turn
on
the
experimental
flag
first
and
often
why
it's
experimental
still
in
a
minute
and
all
that
stuff,
but
it's
an
an
environment
variable
so
do
export
cosine
underscore
experimental
equals
one
yep,
all
caps
perfect!
B
B
A
B
Oh
perfect,
yeah,
it
popped
open
on
browser
window,
so
we're
gonna
go
through
here
and
do
kind
of
the
open
id
dance.
And
if
you
see
what
was
back
in
the
terminal,
sorry
to
make
you
keep
switching,
but
what
we
actually
did
here
is
we
generated
a
key
in
memory.
This
is
generating
ephemeral,
keys
and
now
this
is
the
ca
piece.
B
We
do
the
same
thing
here,
except
for
an
email
address,
there's
already
a
bunch
of
protocols
for
that
open
id
connect
is
the
one
we
use
here.
So
we
prove
you
have
that
email
address
and
we
give
you
a
certificate
for
that
email
address
instead
of
a
domain
name.
So
whatever
the
email
is
on,
the
github
login
you
just
did
will
be
in
a
certificate.
So,
instead
of
signing
with
a
key
now
we
signed
with
an
email
address.
B
B
B
If
you've
heard
of
let's
encrypt
and
certificate
transparency,
we
kind
of
copy
that
same
thing,
all
the
certificates
that
we
issue
through
this
service
get
logged
to
a
transparency
log,
which
is
a
really
cool
data
structure,
where
it's
append
only
and
people
can
kind
of
verify
that
and
check
and
monitor
it.
So
the
entry
there
is
33319
that'll
only
ever
go
up.
Your
certificate
is
in
that
log.
The
signature
is
in
that
log
and
you
can
look
at
it
and
it
will
never
get
tampered
with
and
it
will
be
there
forever.
B
The
way
the
merkle
trees
and
fancy
computer
science
works,
and
so
what
that
lets
you
do
is
it
protects
you
against
our
service
getting
hacked
right.
If
our
service
got
compromised
or
hacked,
we
could
start
issuing
certificates
for
your
email
that
you
didn't
request.
We
could
just
kind
of
bypass
the
open
id
thing
which
approved
you
requested.
It
so
this
lets
people
monitor
the
log
for
any
certificates
issued
for
their
email
address.
If
they
see
something
in
there,
they
say
hey.
I
didn't
sign
a
container
that
day.
They
know
something
bad
happened.
B
They
also
know
the
exact
container
that
got
signed
too.
So
it's
not
just
something
bad
happens.
They
know
hey
somebody
stole
my
email
account.
They
stole
my
password
because
I
accidentally
broadcast
it
live
on
the
stream,
and
I
started
assigning
containers
with
my
name
and
you
can
figure
out
the
exact
ones
that
they
signed
and
tell
people
not
to
use
those.
B
B
Yeah,
so
this
is
a
really
good
way
to
do
it
as
a
user.
If
you're
trying
to
sign
with
an
email
address,
it's
a
little
harder
to
set
up
for
demos
here
today,
but
if
you're
familiar
with
projects
like
spiffy
inspire,
they
use
that
same
protocol.
The
openid
connect
one
to
do:
certificates
and
keys
for
machines.
B
So
you
set
up.
You
know,
nodes
and
pods
in
your
cluster
with
those
identities
instead
of
an
email
address,
it
looks
like
spiffy
colon,
slash
and
then
some
name
you
make
up
for
your
domain
name
and
then
the
machine
and
everything
itself,
and
so
those
services
can
go
through
the
same
flow
too,
where
every
time
they
want
to
sign
something
they
authenticate
with
their
spiffy
id
and
we
give
that
machine
a
certificate.
So
we
can
use
that
to
sign
stuff
in
that
short
time
window.
B
B
B
Out
that
you
know
transparency,
logs
and
immutable
ledgers
and
storing
data
in
something
that
can't
be
deleted
and
bring
out
a
lot
of
you
know
gdpr
and
legal,
and
you
know
what
happens
if
people
sneak
bad
stuff
in
there,
we're
not
allowed
to
host
and
that
kind
of
thing
those
risks.
So
it's
it's
good
from
a
code
and
a
stability
standpoint
we're
just
trying
to
work
through
and
get
approvals
from
all
the
lawyers
and
stuff
like
that.
B
To
stand
this
up
and
let
that
data
stay
around
and
figure
out
what
we
would
do
if
something
really
really
bad
ended
up
in
there
there's
nothing
brand
new
to
solve
the
certificate
of
transparency.
People
have
been
dealing
with
this
for
years.
We've
just
got
to
get
through
that,
so
hopefully,
in
the
next
couple
of
months,
we
can
take
that
off
once
we
figure
out
the
playbooks
for
what
we
do
in
some
really
bad
situations.
B
Yeah,
so
we're
going
to
get
another
tool
that
I
don't
think
is
in
brew
yet,
but
we
can
download
it
and
build
it,
and
everything
like
that,
but
yeah
so
you'll,
see
when
you
did
that
check.
Cosign
did
the
verification,
yeah
existence
of
the
claims
and
the
transparency
log
is
verified
offline,
so
cosine
did
it
automatically
when
we
did
the
verify,
but
we
can
kind
of
walk
through
the
steps
to
do
it
manually.
If
you
want
to
get
the
record
tool
installed,
see
if
we
have.
I
think
we
have
brew
for
this.
C
B
C
B
B
That's
the
hash
of
that
json
object.
We
signed,
there's
that
signature
there
and
then
there's
the
public
key.
So
that's
going
to
be
the
certificate,
so
you
copy
paste
out
that
long
thing,
base64
encoded.
You
can
tell
from
the
equal
signs.
That's
my
trick.
You
should
be
able
to
see
some
more
stuff
I'll
put
the
copied
right
that
didn't
work.
B
B
C
B
C
A
B
One
word
yeah
cool
yeah,
so
this
is
the
first
time
you
hit
the
law
you
now
stored
stuff
at
that
length.
If
you
ever
hit
it
again
in
a
couple
years
from
now,
then
it'll
make
sure
that
nothing
in
the
log
up
until
now
was
tampered
with
so
you're
helping
you're
doing
your
part
for
searching
though
we
can
do.
This
is
kind
of
what
you
might
want
to
do
to
look
through
it
for
things
with
your
email
address,
there's
a
search
command.
C
B
Perfect,
so
nobody's
been
stealing
your
password,
you
know
before
yeah,
so
that's
how
all
that
stuff
works.
There's
a
bunch
of
cool
stuff
with
timestamps
and
everything
to
also
help
protect
and
limit
the
blast
radius.
If
you
do
lose
your
signatures,
but
it
starts
to
get
pretty
complicated,
so
that
was
all
the
three
parts
of
sigstor.
Just
the
plain
keys
kms
systems
where
you
can
start
using
transparency
logs
and
certificate
authorities.
A
B
B
A
B
Yeah,
so
that's
a
that's
a
tricky
one,
we're
trying
to
figure
out
too.
We
store
that
right.
We
have
those
three
oidc
providers,
it's
github,
microsoft,
google,
those
are
the
only
three
we
support,
they're,
pretty
big
and
trustworthy.
We
hope,
but
we
do
want
to
figure
out
how
to
log
that
info
and
make
it
available
just
in
case
something
bad
does
happen.
The
problem
there
is
that
the
info
they
give
you
back
usually
has
some
long
number
in
there,
which
is
kind
of
fixed
and
can
be
a
privacy
concern.
B
Also,
if
you
change
your
email
address
on
google,
that
number
usually
stays
the
same,
and
you
can
start
to
people
can
start
to
do
some
scary
stuff,
like
correlate
things
across
email
addresses,
so
we've
got
to
figure
out
how
to
store
it
and
make
it
available
without
leaking
people's
privacy.
So
we
stored
ourselves
for
a
retention
period
just
in
case.
Something
goes
wrong
to
do
some
incident
response,
but
we
don't
publish
that
in
the
logs
yet
because
it's
a
little
bit
scary.
B
Yeah,
so
we
run
those
two
services,
the
ca
and
the
transparency.
Log
kind
of
is
a
public
good
instance.
So
the
six
store
community
hosts
and
manages
those
it's
set
up
as
a
transparency
log.
So
you
don't
really
have
to
trust
it.
You
can
audit
it.
You
can't
really
do
anything
bad
without
it
going
on
to
that
log.
In
case
something
does
happen,
but
it
does
require
you
to
hit
these
external
services.
So
there's
some
other
modes.
B
You
can
set
up
inside
like
an
organization
to
host
parts
of
that
yourself,
so
you
don't
need
to
be
constantly
going
outside
of
your
firewall
to
get
certificates
or
to
log
data
to
the
log.
For
the
most
part,
it's
just
hashes,
so
you're
not
really
leaking
tons
of
proprietary
information
in
a
shot,
256
hash,
but
still
sometimes
you
don't
want
to
be
even
allowing
outgoing
network
connections,
so
you
can
run
parts
of
it
yourself
too.
A
B
Yeah,
so
that
that
was
a
that
was
our
root
key
ceremony.
Basically
so
yeah
the
full
coca
and
even
the
recore
log
itself
has
to
assign
a
bunch
of
things
to
make
the
proofs
work
and
everything,
and
we
need
a
bunch
of
our
own
keys
in
order
to
do
that,
and
so
keys
are
hard
to
manage
they're
scary
people
lose
them,
and
so
what
we
we
did
is
we
followed
the
protocol
defined
by
the
update
framework
or
tuff,
which
is
another
graduated
cncf
project.
B
So
if
any
one
of
us
loses
ours,
the
other
four
can
fix
it
for
them
and
assign
a
new
key
as
long
as
we
still
have
three
of
them
at
any
given
time
we're
good.
So
that
was
that
event
we
did.
It
was
the
the
first
one
where
we
all
had
to
kind
of
take
them
out
of
the
box
the
first
time
and
establish
that
root
of
trust
that
now
we
can
use
the
update
framework
to
make
changes
to
and
iterate
on
going
forward.
B
All
right
there's
one
more
thing
here
right
I
talked
about
the
signatures.
They're
kind
of
they
can
just
store
basic
information
about
the
container,
which
is
cool.
If
you
sign
in
a
build
system,
that's
nice,
but
what
we
can
actually
do
is
storm
more
than
just
the
container
name.
We
can
store
stuff
about
how
it
was
built.
B
So
let
me
get
you
a
quick
command
to
run
and
this
works
with
our
integration
in
the
tecton
build
system,
but
there's
nothing
really
a
pecton.
That's
special
here
we
have
the
tecton
build
system
generate
payloads.
Basically
that
explain
exactly
how
something
got
built
like
a
container.
So
it's
not
just
the
container.
B
B
C
B
B
Cool,
so
this
is
the
last
release
we
just
did
last
week.
So
instead
of
just
signing
the
containers
that
were
part
of
this
technolon
release,
you
can
see
that
we
signed
these
giant
they're
called
atta
stations,
and
this
shows
all
the
info
about
how
the
thing
was
built,
and
that
goes
into
the
transparency
log
too.
B
So
if
you
start
there
at
the
top,
if
all
you
have
is
the
container
id
for
the
tekton
release,
that's
the
shot.
256
thing.
Sorry,
the
next
text
box
yeah.
So
if
you've
got
that
running,
you've
got
the
shot
256
for
a
container.
You
can
search
that
in
the
transparency
log
using
that
search
command.
So,
instead
of
an
email
now
we're
just
going
to
look
up
everything
we
know
about
that
shot.
B
B
This
build
yeah,
that's
exactly
how
it
was
built,
see
the
parameters
that
went
into
the
tecton
task
run.
These
are
all
the
strings,
the
key
value
pairs
where
the
thing
was
fetched
from
in
the
kubernetes
cluster
that
long
bash
script,
because
native
technology
is
based
on
bash
and
tarballs
and
yaml
the
exact
container
steps
that
were
used.
We
had
crane
running
in
there.
You
can
see
the
digest
all
that
stuff.
So
if
something
got
compromised
in
any
of
these
things,
we
have
all
the
tools
to
kind
of
trace
all
the
way
back.
C
B
A
B
B
It's
not
a
huge,
huge,
huge
amount
of
data
right.
It's
not!
You
know,
petabytes
of
data
that
we've
got
in
here.
So
it's
not
it's
nothing.
It's
kind
of
going
to
push
the
bounds
of
sql
technologies,
but
yeah.
We
do
need
to
set
up
ways
to
kind
of
rotate
and
cut
off
the
log
and
then
start
a
new
fresh
one.
But
still
let
you
kind
of
search
back
through
the
historical
ones.
B
Supply
chain
stuff
is
a
little
different
because
yeah,
you
run
code.
That's
you
know.
Maybe
a
couple
years
old
you
might
probably
shouldn't
be,
but
people
do
that,
so
we
can't
deprecate
things
as
quickly
as
you
can
with
certificates
or
once
they
expire,
you
don't
care
about
them
anymore.
Yeah
it'll
grow
until
we
you
know,
freeze
it
and
stick
them,
publish
the
archives.
That
kind
of
thing.
B
Yeah,
a
lot
of
organizations
do
are
trying
to
figure
out
how
to
or
to
run
them.
It's
not
always
the
best
fit
mirroring
our
log
and
verifying.
It
is
great,
that's
awesome,
because
we
can
get
kind
of
multiple
copies
of
it
that
are
independent
around
the
world,
but
a
lot
of
organizations
trying
to
run
them
internally
doesn't
necessarily
make
the
most
sense,
because
the
log
only
works.
B
If
you
have
people
auditing
it
and
checking
you
and
if
you're
all
on
the
same
team,
you're
kind
of
checking
yourself
and
you're
not
really
getting
any
of
those
benefits,
it's
easier
to
just
use
a
plain
database
in
that
in
that
case,
because
you
do
get
a
bunch
of
complexity.
That
only
makes
sense
if
you
do
have
people
that
are
kind
of
being
skeptical
and
making
sure
you're
not
screwing
up.
B
B
Yeah,
so
it's
done
through
the
there's
a
little
sub
project
called
tecton
chain
so
that
you
install
next
to
your
tekton
cluster
and
you
just
start
getting
this
stuff
signed.
It
can
store
stuff
in
any
database.
You
want
to.
It
doesn't
necessarily
have
to
be
the
transparency
log,
so
you
can
throw
it
into
bigquery
or
dynamodb
or
any
of
those
document
databases
to
do
kind
of
more
querying
on
later.
B
This
is
similar
to
in
total
yeah,
so
that
format
is
actually
from
in
toto.
That's
another
cncf
project.
The
internal
project
defines
a
bunch
of
formats
for
kind
of
describing
the
supply
chain
step.
If
you
think
of
a
build
step
as
a
bunch
of
inputs
came
in,
did
a
bunch
of
stuff
on
those
inputs
and
then
a
bunch
of
outputs
came
out.
You
know
those
three
things
and
toto
is
a
really
good
set
of
formats
for
describing
those
things
in
ways
that
you
can
link
back
together
and
check.
B
Good
question:
I
could
not
get
my
cluster
and
caverno
and
policy
engine
all
set
up.
That
was
kind
of
what
I
wanted
to
do
next
for
sure
you
can
set
up
verification
there,
yeah
not
quite
sure.
What's
going
on
my
cluster
got
all
screwed
up
over
the
weekend
and
I
didn't
get
it
working
in
time.
But
if
you
look
at
the,
maybe
you
could
see
the
docs.
I
know
they're
working
on
a
release.
That's
supposed
to
go
out
any
day
now
to
explain
how
all
that
works.
B
B
B
B
Yeah,
so
if
you
scroll
down
yeah
there,
we
go
with
cosine.
So
if
you
get
this
installed
and
set
up
from
ahead
because
they
haven't
quite
done
the
release,
yet
I
think
that's
where
I
screwed
up.
I
was
installing
an
actual
release.
Instead
of
this
draft,
then
you
can
kind
of
define
a
new
verific
image,
verification
crd
and
put
in
some
public
keys
and
it'll
block
you
from
deploying.
B
A
B
Yeah
and
so
then
you
can
set
it
up
to
there's
the
enforce
or
alert.
You
know
your
actions,
so
you
might
want
to
block
it.
You
might
just
want
to
send
an
email
to
someone
and
warn
them.
You
might
just
want
to
log
it
there's
a
couple
different
setups.
You
can
do
there,
but
that
because
you
can't
accidentally,
you
know
there
have
been
a
bunch
of
kind
of
typo
attacks
where
you've
fat
finger
and
typed
the
wrong
name
of
an
image
from
docker
hub
and
now
you're
grabbing,
something
from
somebody.
B
You
don't
know,
because
you
put
two
o's
in
the
mongodb
container.
Instead
of
one
and
people
set
up
coin
mining
and
all
sorts
of
terrible
stuff
like
that,
so
a
bunch
of
different
reasons.
You
might
want
to
do
this
type
of
policy,
but
if
you
get
that
set
up
in
your
ci
system,
it's
all
signed,
then
you
know
that
your
proud
environment
is
locked
down
the
stuff
that
came
from
that
ci
system.
B
A
B
Nope
so
yeah
they-
I
don't
know
if
I
made
it
into
this
version,
but
you
can
see
some
discussion
around.
You
can
put
email
or
oitc
accounts
somewhere
too
and
locked
down
to
that.
Rather
than
just
the
keys-
and
I
think
my
little
admission
controller
people
were
talking
about
earlier-
can
do
that
too,
with
a
config
map
or
you
could
put
in
keys
or
email
addresses,
whatever
kind
of
combination
there.
You
want
to
verify
against.
A
All
right
awesome,
very
cool
feature,
I'm
assuming
that
I
think
you
mentioned
gatekeeper
earlier,
so
the
upper
projects
are
probably
working
on
similar
support.
I'm
assuming
cube
warden,
probably
going
to
have
another
policy,
and
that
worked
with
all
of
this.
It's
nice
to
see
that
support
coming
from
the
broader
cognitive
ecosystem
as
well.
B
Yeah
I've
been
trying
to
get
it
working
in
kubora.
I
thought
it
was
going
to
be
so
easy
because
this
is
all
written
in
go
and
you
can
compile
go
to
wasm
and
you
can
get
that
running
warden,
but
the
the
go
wasm
support
isn't
quite
there
yet
and
you
can't
do
a
bunch
of
stuff
you
need,
and
in
that
so
yeah
it's
soon.
It's
not
kubordin.
It's
it's
go
and
wasm,
unfortunately,
so
the
spec
that
we
have
for
coastline
explaining
how
this
works
is
stable
too.
B
B
A
A
So
I
mean
that
was
all
pretty
self-explanatory.
Like
running
those
commands,
there
was
nothing
too
daunting
there.
It
was
all
pretty
nice
which
just
shows
that
it's
a
pretty
great
developer
experience
and
does
this?
Can
I
use
cosign
for
like
it
doesn't
have
to
be
container
images
right,
I'm
thinking
of
other
open
source
projects,
I've
got
where
we
release
binaries.
Can
I
sign
these
binaries
and
publish
to
that
log.
B
Yeah
yeah,
I
don't
know
how
we
blanked
on
that
yeah,
the
all
the
cosine
stuff
itself
on
the
github
revo
is
side
with
cosine,
so,
instead
of
sign
container,
there's
a
sign
blob
command
where
it
just
kind
of
spits
out
the
signature.
It's
really
easy
to
do
that.
The
challenge
is
like
how
to
where
you
put
those
signatures
and
there's
no
standard
great
place
for
it.
So
for
us
we
just
put
them
in.
B
You
know
that
github
releases
page
and
you
can
check
those
with
cosine
two,
the
cool
part
is
a
lot
of
things
are
moving
to
the
container
registries.
Like
we
talked
about.
You
know,
opa
lets
you
put
bundles
there
envoy
and
istio
and
I'll.
Let
you
put
wasm
modules
into
a
container
registry,
so
yeah
you
can
sign
binaries,
you
can
sign
all
sorts
of
other
packages,
but
it's
kind
of
cool
to
see
everything
moving
and
converging
on
the
container
registries
anyway.
B
At
the
same
time,
the
other
one,
though
I
think
you
mentioned
in
your
tweet
today
chat
about
was
the
s
bombs,
the
software
bill
of
materials
and
stuff.
So
there's
a
ton
of
different
tools
and
formats
for
generating
those
and
working
with
those
but
they're
huge
documents
that
you've
got
to
upload,
store
and
sign.
Somehow
too
so.
Cosine
has
some
commands
for
working
with
those
and
we
can
upload
those.
B
It
works
the
same
as
our
signatures,
there's
just
a
funny
little
naming
convention
where
you
just
put
a
dot
s
bomb
at
the
end,
instead
of
a
dot
signature
and
then
it
looks
like
an
image.
So
you
can
sign
that
too,
and
you
can
point
that
at
an
image
and
download
the
s-bombs
for
your
image
and
that
kind
of
thing.
A
All
right,
okay,
I'll,
ask
you
one
more
question:
if
anyone
in
the
chat
has
anything
they
want
to
ask
dan
before
we
finish
up
for
today,
drop
it
in
the
comments.
You've
got
a
couple
of
minutes,
I'll,
throw
two
questions
at
you,
then
so
the
first
one
would
be
like.
Do
you
see
this
being
something
that
would
be
integrated
with
a
platform
like
sneak?
A
B
Yeah,
I
hadn't
thought
of
it
that
way,
yeah
once
this
stuff
is
stored,
you
know
things
like
snake.
Can
you
know,
show
it
and
render
it
in
the
ui?
Actually,
the
cncf
hardware
registry
is
working
on
that
now
kind
of
rendering
these
and
putting
little
lock
green
check
marks
next
to
things
that
are
signed
and
aren't
signed
at
the
registry
level.
We
didn't
just
started
working.
B
I
think
last
week
on
kind
of
the
reverse
integration,
though,
which
is
how
you
might
store
these
sneak
or
trivia
scans
in
a
registry
4
container,
it's
a
little
bit
different
than
something
like
an
s
bomb
because
they
go
out
of
date
right
just
because
something
had
no
vulnerabilities.
Today
it
doesn't
mean
nine
months
from
now.
It
has
no
vulnerabilities.
B
These
things
get
found
over
time.
So
there's
kind
of
like
a
time,
snap
approach
that
you
would
put
in
there
saying
it
had
no
vulnerabilities
today
and
then
you
might
have
an
admission
controller.
That
says,
I
want
to
only
allow
stuff
to
run
that
I've
checked
within
the
last
30
days
or
something
like
that.
So
you
can
kind
of
combine
those
scanners
with
time
stamps
and
signatures
to
make
sure
that
you're
constantly
checking
them
and
don't
have
to
worry
about
forgetting
an
image.
That's
sitting
running
in
your
cluster.
B
B
If
you
don't
want
to,
I
mean
that's
really,
just
more
making
sure
we
have
a
playbook
to
do
if
something
makes
its
way
into
that
log
and
we
do
have
to
delete
and
move
things
forward
for
other
reasons
a
couple
weeks
ago.
Actually
there
was
a
fun
issue
with
certificate
transparency,
where
cosmic
ray
flipped
a
bit
and
screwed
up
the
merkle
tree.
If
anybody
saw
that
yeah,
they
traced
it
down
the
right
data
went
into
the
log
and
one
bit
was
flipped
and
it
kind
of
invalidated
the
whole
merkle
tree
and
some
people
piecing.
A
B
No
not
yet,
I
don't
think
so.
Nothing
direct
carlos
has
been
working
on
a
bunch
of
our
release.
Engineering
stuff,
carlos
is
awesome.
I
don't
know
if
he's
listening
today,
actually
he's
on
vacation,
but
yeah
go
release.
Her
has
some
scripting
modes
where
he
can
kind
of.
You
know
an
escape
hatch
to
do
other
stuff.
So
he's
got
some
of
those
demos
working
but
yeah.