►
From YouTube: Sigstore demo with cosign
Description
sigstore developer Dan Lorenc provides a demo on the different signing methods available in cosign.
A
Hey
everyone:
my
name
is
dan
lawrence
and
I'm
going
to
be
doing
a
couple.
Demos
of
the
cosign
container
signing
tool
which
is
developed
as
part
of
the
sig
store,
open
source
project,
cosign
and
sig
store,
are
both
available
on
github
cosign
is
at
github.com.
Cosine
cosine
is
designed
to
let
you
sign
containers
easily,
I'm
going
to
support
a
couple
different
workflows
that
I'm
going
to
go
through
today.
A
The
first
one
is
using
a
standard,
fixed
public,
private
key
pair
that
you
generate
with
the
tool
I
mean
protect
that
private
key
and
you
distribute
the
public
key
second
flow.
I'm
going
to
go
through
is
using
the
experimental,
keyless
mode
where
coastline
can
allow
you
to
sign
and
verify
container
images
without
having
to
use
or
manage
keys.
This
is
enabled
by
using
some
of
the
other
components
of
the
sigstor
project,
which
I'll
explain
as
we
go
ahead.
A
The
very
first
step
before
you
can
start
signing
and
verifying
things
with
cosine
is
to
generate
your
key
pair.
You
don't
have
to
use
any
other
tools
for
this.
Cosine
supports
it
for
you,
so
we
can
do
cosine
generate
key
pair.
They
prompt
us
for
a
password
to
encrypt
that
key,
so
we
don't
have
to
worry
about
leaving
on
disk
type
that
in
confirm
and
we're
all
set.
A
So
I'll
show
you
what
these
keys
look
like,
I'm
going
to
print
out
the
private
key
to
my
terminal
it's
encrypted,
so
we
don't
have
to
worry
about
people
stealing
this
or
trying
to
use
it
unless
they
also
have
the
password.
You
can
store
this
on
disk.
You
can
store
this
in
a
git
repository.
You
can
check
it
and
do
a
public
open
source
project.
A
In
fact,
that's
how
we
sign
our
cosign
releases
today,
there's
a
key
in
our
get
repo
that
you
can
see
and
look
at
the
part
that
you
need
to
verify
something
signed
with
cosign
is
the
public
key.
So
let's
take
a
look
at
what
that
looks
like
this
is
just
a
standard
public
key
it's
stored
in
a
typical
x509,
pkix
format.
It
works
with
any
other
tools.
A
A
So
if
people
have
access
to
the
image,
they
can
also
find
the
signatures
for
it.
You
don't
have
to
set
up
any
extra
storage
or
figure
out
how
to
distribute
your
signatures,
so
the
image
has
been
signed
and
the
signature
is
up
there.
Now
we
can
verify
again
with
the
public
key,
just
passing
that
same
image
name.
So
we're
going
to
do
cosign
verify
we'll
use
the
public
key
this
time.
A
We'll
need
a
password
because
the
public
key
is
unencrypted
and
we
performed
a
whole
bunch
of
checks
on
that
signature,
which
are
printed
out
here
with
the
signature
blob
or
the
signature
payload.
This
is
this
kind
of
json
string
printed
out
at
the
bottom.
If
you
do
that
same
thing
again,
but
pipe
at
the
jq
and
show
you
a
little
bit
better.
What
that
looks
like
painter
image,
isn't
a
real
physical
thing
that
you
can
sign.
Instead,
you
have
to
assign
some
kind
of
representation
of
it.
A
The
canonical
representation
of
a
container
image
is
this
sha256
digest?
So
that's
what
we
sign
and
we
could
just
sign
this
string,
but
by
wrapping
up
in
some
json
we
have
some
opportunities
to
include
some
extra
metadata
that
we
might
want
to
protect.
As
part
of
that
signature,
let's
show
what
some
of
those
use
cases
might
be.
We
can
use
those
with
the
cosine
sine
dash
a
flag,
I'll
reset
and
get
back
to
the
top
of
my
terminal
and
we'll
get
started.
There
then
sign
dash
key.
A
Now
I'll
pass
in
some
annotations
here,
that's
the
dash
a
flag.
We
can
do
foo
equals
bar
for
just
a
random
one.
We'll
do
the
rest
of
the
image
name.
Some
actual
use
cases
here
might
be
adding
the
git
commit
that
the
container
is
built
at
a
timestamp.
Something
like
that.
All
this
metadata
gets
put
into
the
signature
itself,
so
you
can
verify
it
later
awesome,
so
we
signed
and
uploaded
the
signature
again
to
gcr.
Now,
if
we
verify,
we
should
see
two
signatures
attached
to
the
image
you
can
sign
image
multiple
times.
A
One
of
them
won't
have
that
foo
equals
bar
annotation
and
the
other
one
will
awesome.
So
we
can
see
that
we
stuck
that
here
in
the
optional
section.
Now,
if
you
want
to
do
some
complex
workflows
to
use
those
annotations
to
actually
verify
things,
you
can
pass
that
same
dash
a
flag
into
the
verify
command.
A
So
let's
do
that
here
batch
a
for
equals
bar.
Now
it's
going
to
check
that
the
true
equals
bar
annotation
is
there.
We
can
only
see
one
if
it
all
works.
Yes,
awesome!
So
we
only
see
that
second
signature
here,
let's
get
back
up
to
the
top,
so
you
can
use
that
annotation
to
kind
of
build
up,
complex
workflows.
You
can
do
things
like
time,
stamping
and
protocols
like
the
update
framework,
if
you
want
to
by
using
these
optional
fields.
A
So
that's
the
basic
mode
for
cosine
with
fixed
key
pairs.
You
can
do
some
extra
fancy
stuff
like
store
the
key
pairs
in
a
kms
system
like
gcp,
kms
or
something
else
if
you
want
to
and
we're
working
on,
adding
hardware
support
for
things
like
yubikeys
going
forward,
but
now
I'm
going
to
show
some
of
the
cool
experimental
features
that
make
cosine
work
really
well
with
the
rest
of
the
sig,
store
components
and
simplify
things,
even
more
so
they're
experimental.
So
we
have
to
turn
on
an
experimental
flag
here.
A
A
The
signatures
are
entered
into
our
recore
transparency
log,
which
serves
as
both
a
discovery
mechanism
for
those
signatures
and
a
way
to
get
those
signatures
timestamps.
So
we
know
kind
of
exactly
when
they
happened
and
when
they
were
entered
and
incorporated
into
that
transparency
log.
So
we're
going
to
see
a
bunch
of
output
and
I'll
explain
what
each
of
those
means
as
we
go
ahead.
A
A
No
sign
sign
just
the
image
name,
no
keys
awesome.
So
we
see
what
happened
here.
The
terminal
I'll
put
some
text
pretty
quickly
and
then
it
popped
me
up
to
my
browser
to
do
standard
open
id
connect
flow
before
I
click
go,
let's
jump
back
here
and
I'll
kind
of
show
what
happened.
I
said
this
is
keyless
mode,
it's
not
entirely
keyless
and
we
do
have
to
generate
some
keys.
You
just
don't
have
to
worry
about
them,
so
the
serverless
people
get
to
call
that
technology
serverless.
A
Even
though
they're
actual
servers,
we
get
to
call
this
keyless.
So
we
generated
this
ephemeral
key
pair,
and
now
we
exchanged
that
public
key.
We
sent
that
up
to
our
certificate
authority,
our
full
seo
root
certificate
authority
for
code
signing,
and
we
asked
it
for
a
certificate
that
certificate
binds
the
public
key,
that
we
generated
to
an
identity
now
in
open
source
and
normal
development.
Your
identity
really
is
your
email
address.
That's
how
we
communicate
that's,
how
we
build
up
a
reputation
in
open
source
community
over
time.
A
A
We
come
back
to
the
terminal
and
we
see
some
more
text.
We
signed
it
with
the
private
key
that
was
generated
up
here.
This
is
ephemeral.
Again,
it
never
touched
our
disk.
We
don't
have
to
worry
about,
losing
it
or
leaking
it
or
having
someone
steal
it.
We
signed
the
image
we
pushed
it
here
and
then
we
also
uploaded
it
to
our
recore
transparency
log
and
we
got
this
index
here.
A
A
This
is
what
gets
entered
into
the
transparency
log.
It's
all
the
components
required
to
verify
a
signature.
We
have
the
hash
itself.
This
represents
the
hash
of
that
json
payload
I
showed
before,
which
has
the
hash
of
the
container
inside
of
it
again,
and
then
we
have
the
signature
content.
That's
right
here.
These
are
just
the
signature
bytes
that
get
generated
when
you
do
the
sign
operation
and
then
the
public
key
itself.
A
So
this
public
key
is
what's
present
in
the
certificate
that
was
issued
based
on
the
open
id
connect
flow.
So
the
other
interesting
part
that
I
mentioned
is
the
time
stamping,
because
these
keys
are
ephemeral.
We
need
to
ensure
that
they're
only
valid
for
signing
for
a
very
short
period
of
time.
We
use
20
minutes
today,
just
to
handle
clock,
skew
and
queuing
times
inside
of
our
transparency
log.
A
But
what
we
really
want
to
assert
is
that
the
signature
is
entered
into
the
transparency
log
when
the
certificate
was
valid
in
that
20
minute
time
period,
and
so
that's
why
we
have
this
important,
integrated
time
field
here.
This
is
just
a
standard,
unix
timestamp,
if
you
can
do
the
math
in
your
head,
you'll
see
that
it
was
around
905
the
time
right
now
when
I
ran
that
command,
let's
do
a
verify
and
show
how
all
these
components
end
up
getting
used,
cosign
verify
again,
no
keys.
A
A
All
right,
so
a
bunch
of
stuff
happened
here
this
time
we
actually
did
these
extra
checks
here
at
the
bottom,
we
checked
that
the
signature
was
integrated
into
the
record
transparency
log.
When
the
certificate
was
valid.
We
checked
the
signature
itself
assigned
by
a
key,
and
then
we
fetched
that
certificate
and
made
sure
the
certificate
was
actually
valid.
It
wasn't
self-signed,
it
wasn't
a
random
certificate.
It
was
actually
signed
by
our
root
ca
service.
A
Then,
finally,
we
extract
the
common
name
from
the
certificate.
You
might
be
used
to
this
being
some
kind
of
server
host
name,
but
in
this
case
it's
my
email
address,
so
we've
proven
here
is
that
this
signature
on
this
image
was
created
by
somebody
with
access
to
this
email
address
at
that
specific
time.