►
From YouTube: Let's learn sigstore
Description
►►►Connect with me ►►►
► Discord: https://discord.gg/q97CAcq5
► Twitch: https://www.twitch.tv/saiyampathak
► YouTube: https://youtube.com/c/saiyam911
► GitHub: https://github.com/saiyam1814
► LinkedIn: https://www.linkedin.com/in/saiyampathak/
► Website: https://saiyampathak.medium.com/
► Instagram: http://instagram.com/saiyampathak/
► https://twitter.com/saiyampathak
A
Hello,
everyone
and
welcome
to
day
two
of
the
cicd
week.
My
name
is
sam
pathak
and
I
am
a
cncf
ambassador
working
as
a
director
of
technical
evangelism
at
cevo
building
the
next
gen
cloud
platform,
a
lot
of
amazing
things
coming
up,
so
we
should
watch
out
that
space.
Just
before
we,
you
know
things
get
started.
People
often
ask
me
in
every
stream.
Like
you
know,
what
are
the
prerequisites?
Do
I
need
to
know
kubernetes
and
all
that
stuff.
A
So
if
you
want
to
learn
cube,
kubernetes
plenty
of
resources
out
there,
the
best
one
I
recommend
is
the
one
that
I
created,
which
is
co
academy
free
of
cost.
So
it
is
co.com
academy,
no
credit
card
required
to
learn
all
there
are
more
than
50,
plus
video
lectures
that
you
can
curated
for
kubernetes
that
you
can
learn.
I
think
that's
pretty
much
enough
for
for
learning
communities
to
get
started
and
building
out
stuff
out
there.
It
also
helps
you
prepare
for
your
certifications.
A
Then
yesterday
we
had
jason
and
we
talked
about
techton.
We
talked
about
tecton,
you
know
the
task,
the
pipelines,
the
chains
which
we'll
explore
today
as
well,
and
we
also
went
through
some
of
the
demos
and
yeah
how
you
can
contribute,
join
the
slack
and
all
things
and
pretty
pretty
good
stream.
I
saw
some
of
the
tweets.
Thank
you
for
that
and
it
was.
A
It
was
really
good,
so
the
next
one
today
is
on
six
store,
so
it's
basically
supply
chain
security
and
the
project.
You
know
the
project,
six
store
some
of
the
tools
tooling
around
supply
chain
security,
how
we
can
implement
that
and
bunch
of
other
things.
So
I
would
welcome
you
all.
You
know
to
join,
ask
questions
and
you
know,
make
it
more
interactive
as
interactive
as
possible.
So
again,
there
is.
A
There
are
five
swags
to
be
one
thanks
to
the
cd
foundation,
and
you
know
I'll
post
the
link
in
the
chat
make
sure
you
fill
that
form
and
yeah.
Obviously,
who
are
joining
live
I'll
put
you
on
the
screen
because
you
have
joined
live,
so
it
makes
sense
to
have
you
here
make
sure
to
fill
that
form
so
that
you
know
we
can
pick
just
random
numbers
in
the
end
and
the
name
associated
with
that
number
just
twins
as
as
simple
it
is.
A
So
it's
basically,
I
think
a
pair
of
socks
you'll
get
some
code
or
something
like
that.
I
don't
know
how
it
will
work,
but
five
winners
per
stream
is
something
that
I
can
pick
that
I
know
so
we'll
do
that.
Another
thing
is
make
sure
you
are.
You
know
good
with
each
other
in
the
chat
and
to
the
speaker
and
the
presenters
just
make
sure
you
know
the
conversation
is
pretty
healthy.
It's
we
are
all
here
to
learn.
A
We
are
friends,
so
just
make
sure
it's
good,
and
apart
from
this
I
have
dan
with
me.
So
I
think
that
that
enough
is.
That
is
all
enough.
I
can
say
right.
I
have
dan
with
me
so
we'll
be
talking
amazing,
stuff
around
supply
chain
security,
six
store
plenty
of
stuff
why
it
is
important,
but
what
why
it
is
important
now
why
we
are
hearing
supply
chain
security.
There
is
a
supply
chain.
Security
talks
at
kubecon,
wired
is
coming
up
again
and
again
people
are
using
it.
A
A
It's
so
bad
make
sure
you
subscribe
to
the
channel,
because
that's
what
keeps
me
going,
you
know
you
have
to
subscribe
to
the
channel
if
you
are
seeing-
and
if
you
are
new,
then
there's
a
lot
of
cloud
native
content
out
there
and
make
sure
you
share
the
streams
as
well
with
your
friends,
so
that
other
people
can
benefit
as
well.
So
this
is
the
second
day
of
ci
cd
week.
We
are
here
to
learn
supply,
chain
security
and
six
store.
B
Sure
thanks
a
lot
for
having
me
and
yeah
like,
like
you
said
a
second
ago,
please
subscribe
to
the
stream,
so
you
can
keep
doing
this,
make
sure
to
support
him
share
this
too.
So
everybody
knows
what
we're
talking
about
today.
Yes,
my
name
is
dan
lawrence.
I
am
one
of
the
maintainers
of
the
city
store
project
which
we're
going
to
be
doing
some
demos
of
and
talking
about
and
stuff.
B
Today,
I've
also
done
a
bunch
of
other
open
source
work
over
the
last,
probably
five
or
six
years
and
things
like
the
kubernetes
community.
I
started
the
mini
cube
project
years
and
years
and
years
ago,
when
that
first
got
going.
That
was
actually
the
first
go
code.
I
ever
wrote
I'm
so
sorry
it
was
so
buggy
early
on
everybody.
That
was
that
was
me,
learning
go
and
then
I
got
pretty
worried
about
supply
chain
security.
B
So
I
helped
on
the
techton
project,
which
we
just
heard
about
yesterday
from
jason
hall
and
a
bunch
of
other
projects
in
that
space,
and
most
recently
is
the
sig
store,
one
which
we
started
earlier.
This
kind
of
late,
2020
early
2021,
is
really
when
it
took
off
in
part
just
because
of
the
huge
rise
in
interest
in
supply
chain
security
which
we'll
go
over
a
bit
on
kind
of.
Why
that's
happening
now
and
why
it's
such
a
big
topic,
but
six
door
is
actually
pretty
not
complicated,
but
a
pretty
broad
project.
B
So
there's
a
couple
different
areas
to
it.
So
it's
not
just
one
thing
which
makes
it
a
little
bit
hard
to
understand,
so
we
can
go
over
the
different
components
of
sixth
or
how
you
can
put
them
together,
how
you
can
use
them
separately,
all
that
stuff
to
protect
your
software
supply
chain
yeah.
So,
with
that
we
can
get
started.
B
B
B
B
Normally
we
like
it
when
graphs
go
up
and
to
the
right,
but
in
this
case
up
and
to
the
right
is
scary,
not
not
good,
we're
seeing
a
whole
bunch
of
attacks.
Even
you
know
every
week
that
goes
by,
we
see
a
bunch
of
new
ones,
particularly
in
open
source,
which
is
why
companies
are
starting
to
get
worried
about
this
and
why
attackers
are
all
getting
very
excited.
B
This
one
has
a
bunch
of
things
on
typo,
squatting,
malicious
code,
injection
and
tool
tampering.
Those
are
the
three
types
of
attacks
that
sauna
type
classified
as
next
generation.
Typo
squatting
is
a
kind
of
tricky
scary.
One
we've
seen
it
a
bunch
on
pi,
pi
and
npm,
and
even
docker
hub,
where
people
will
try
to
trick
you
into
installing
something
with
a
typo
in
the
name
or
some
of
those
like
unicode
bi-directional
characters.
B
So
if
you
copy
paste
something,
you
might
be
getting
a
docker
image
or
a
package
that
is
not
actually
the
one
that
you
think
it's
going
to
be
a
lot
of
times.
These
packages
contain
malware
that
tries
to
steal
credentials
from
your
home
directory
if
you're
running
it
on
your
laptop
or
install
and
run
crypto
coin
miners
in
a
production
data
center
or
even.
A
B
Some
of
the
the
weirder
type
of
squatting
ones
aren't
even
actually
typos
but
kind
of
more
social
engineering
that
we
see
a
lot
like
if
your
company
has
a
library
published
called
like
company
hyphen,
api
client,
or
something
like
that,
somebody
might
abbreviate
your
company
name
or
leave
it
off
completely
or
put
it
at
the
end.
Instead
of
the
beginning
stuff,
like
that
to
really
trick
people
and
make
it
hard
to
know
what
the
correct
version
is.
B
A
I'm
trying
to
get
them
all
in
my
head,
like
all
this
stuff,
but
yeah
from
from
the
dangers
that
you
are
telling.
You
know
the
type
of
squatting,
malicious
code,
injection
and
tool
tampering
and
the
the
problems.
I
mean
the
occurrences
of
them,
how
they
have
like
increased
and
they
are
increasing,
like
anything.
So
people
are
targeting
this
so
that
actually
needs
the.
You
know.
Explanation
like
we
need
something
we
need.
Something
to.
You
know
tackle
these
issues.
B
Yeah
and
it's
it's
hard
because
there's
no
single
issue
and
no
single
fix
for
all
of
it,
so
that's
kind
of
why
it
can
be
a
little
bit
overwhelming.
I
like
this
slide
too.
This
is
actually
from
a
presentation
I
just
gave
last
week
at
the
linux
foundation
members
summit.
There
should
be
recordings
of
the
whole
thing
that
we
can
link
after,
but
I
really
like
this
slide
too.
B
This
shows
not
just
the
you
know,
number
of
attacks,
but
the
number
of
organizations
that
actually
self-reported
as
being
attacked,
so
majority
of
organizations
actually
get
were
affected
by
a
supply
chain
attack
last
year
in
2020
64,
and
I'm
guessing
that
some
of
that
36
was
affected
and
just
didn't
notice
it
yet.
So
this
is
probably
a
lower
bound
or
a
lower
estimate.
This
is
pretty
scary,
like
how
many
other
types
of
attacks
hit
a
majority
of
software
organizations
in
one
year.
B
This
is
kind
of
why
it's
such
a
big
deal
for
everybody
at
a
broad
level.
I'm
not
sure
if
I
have
a
great
slide
for
this,
but
I
like
to
try
to
break
down
the
problem
into
two
different
areas
and
this
side
kind
of
shows
some
of
it.
I
guess
there
are
two
different.
You
know
problems
I
like
to
say
with
open
source
software
supply
chain
security.
B
One
of
them
is
kind
of
this
whole
typo
squatting
tampering
malicious
code
injection
one
where
you
might
not
actually
be
running
the
code
that
you
think
you
are,
somebody
might
have
tampered
with
it.
Somebody
might
have
tricked
you
into
running
a
different
version
of
the
code
or
somebody
might
have
stolen
somebody's
credentials
on
github
or
on
npm,
or
something
like
that
and
tricked
you
into
running
malicious
code.
B
B
The
other
half
of
the
problem,
the
other
big
area
which
I
think
is
kind
of
separate
I
mean
requires
being
dealt
with
separately,
is
just
even
if
you
know
what's
in
your
supply
chain,
then
you
know
what
all
of
your
dependencies
are.
Those
dependencies
might
have
bugs
they
weren't
put
there
by
an
attacker
on
purpose.
B
One
of
the
big
attacks
that
got
a
bunch
of
attention
last
week
was
the
ua
parser
javascript
library
for
parsing
user
agents.
An
npm
was
compromised
and
a
malicious
version
was
pushed
because
the
maintainers
credentials
were
stolen
on
npm,
so
that
one
affected
like
a
huge
percentage
of
downstream
packages
on
npm
because
of
how
widely
it
was
used
and
the
amount
of
reuse
that
happens
in
that
ecosystem
yeah.
So
anything
there
before
I
jump
into
six
store.
A
Yeah,
so
that
that
is
good,
like
you
know
how
why
supply
chain
security
is
important,
I
think
by
now
everybody
should
have
a
fair
amount
of
understanding,
especially
the
malicious
code
is,
is
pretty
pretty
scary,
so
I
think
the
maintainer
should,
you
know,
keep
their
credentials
safe
because
you
are
the
ones
who
will
be
pushing.
You
know
something
out
there
and
the
binary.
If
it's
wrong,
then
nobody
can
help
right.
People
trust
you.
B
A
B
Yeah,
so
there's
a
bunch
of
work
happening
here.
Let
me
jump
to
this
website.
Quick,
open,
ssf.org,
the
open
source
security
foundation
is
doing
a
bunch
of
work
to
help
secure
open
source
and
supply
chains
in
general.
So
this
is
a
kind
of
sister
foundation
to
the
cncf.
This
is
part
of
the
linux
foundation
and
it's
kind
of
triggered
with
addressing
all
open
source
supply
chain
risk
beyond
just
cloud
native,
and
so
there's
a
bunch
of
work
happening
here.
B
You
can
learn
more
at
openssf.org
or
on
github
at
github.com
ossf
that
has
a
bunch
of
different
repositories
and
ways
to
get
involved
and
help
out.
One
of
the
projects,
I'm
just
going
to
point
to
here
is
pretty
popular.
Is
the
scorecard
project
so
this
project,
it's
got
a
really
cool
goose
logo,
as
you
can
see
here,
like
everything
else
in
the
open
ssf
this
project
lets,
you
run
a
scorecard
check
and
there's
a
lot
of
different
websites
that
serve
these
scores
too.
B
Somebody
else
can
still
push
code
and
improve
patches
all
the
way
out
to
using
static,
analyzers
and
fuzzing
and
stuff
like
that.
That
are
all
just
kind
of
best
practices
that
you
know
you
should
do,
but
you
might
forget,
unless
you're
regularly
running
one
of
these
tools,
there's
even
a
bunch
of
stuff
that
you
might
not
think
of
that.
This
tool
can
detect
like
properly
setting
permissions
and
scopes
on
your
github
actions.
So
if
one
of
those
is
compromised,
it
can't
you
know,
get
right
permissions
and
take
over
your
entire
repository.
B
So
I'd
highly
encourage
you
to
run
this
tool
on
any
open
source
projects
that
you
maintain
or
contribute
to,
as
well
as
things
that
you're
thinking
of
taking
a
dependency
on
it
can
be
pretty
insightful
and
help
you
catch
some
obvious
mistakes
early
on,
in
addition
to
that
is
kind
of
the
same
store
project.
So
let
me
jump
back
over
here.
This
is
the
main
one
we're
going
to
be
talking
about
today
at
seekstore.dev
or
github.com
sigstor.
B
So
this
means
a
bunch
of
tooling
some
really
cool
services
that
we
operate
as
well
to
issue
code,
signing
certificates
for
free
and
some
transparency
logs
to
kind
of
put
all
of
this
stuff
on.
So
you
can
look
it
up
later
and
make
sure
that
somebody
isn't
trying
to
trick
you
or
do
some
targeted
attacks,
or
something
like
that.
B
B
B
You
don't
know
anything
about
where
it
came
from,
and
the
kind
of
funny
part,
though,
is
that
with
open
source
code,
when
you
just
run
npm,
install
foo
or
pip,
install
bar
or
something
like
that
and
grab
a
random
package,
it's
not
actually
that
much
different
than
taking
that
flash
drive
and
plugging
it
in
you're
still
taking
code.
You
have
no
idea
where
it
came
from.
B
You
have
no
idea
who
wrote
it
and
you
don't
even
really
know
what
it
does
yet
until
you've
downloaded
it
in
a
lot
of
these
cases
and
you're
running
it
on
your
laptop
or
worse,
you
might
be
running
it
as
root
inside
of
some
docker
container.
The
thing
gets
deployed
into
your
production
environment.
It
gets
way
more
permissions
than
it
would
have
on
your
laptop.
B
So
what
we
try
to
do
with
the
start
of
stick
store
is
kind
of
think
about
it
backwards.
So
what
if
we
could
make
it?
So
that
you
could
find
some
random
package
laying
on
the
ground
on
a
sidewalk
on
some
flash
drive
and
actually
trace
that
back
to
where
it
came
from
what?
If
we
give
maintainers
tools
to
kind
of
sign
and
publish
those
signatures
and
keys
somewhere
securely,
so
that
their
users
could
look
that
up
and
trace
all
of
the
stuff
back
so
that
you
could
actually
decide.
B
A
B
Awesome
yeah,
so,
let's
jump
forward
here.
This
slide
is
great.
On
stick
store
and
outside
website
is
great.
On
sigstor.dev,
there
are
kind
of
three
main
parts
here:
city
store.
There
are
some
tools
to
sign
things.
You
could
sign
anything
you
want.
You
can
sign
a
tarball,
you
can
sign
a
text
file.
You
can
sign
a
readme.
You
can
sign
an
npm
package.
You
can
sign
a
container
image.
B
B
The
signatures
are
only
as
good
as
the
security
of
the
keys,
so
the
transparency
log
also
gives
people
some
pretty
nice
tooling
to
detect
all
the
usages
of
their
keys.
And
if
you
see
something
in
there
that
you
didn't
expect-
and
you
didn't
mean
to
sign
or
something
like
that
for
your
project,
you
know
something
bad
happened,
and
you
know
the
exact
thing
that
got
signed
that
shouldn't
have,
so
you
can
quickly
tell
your
users
to
stop
trusting
that
thing,
because
your
keys
or
your
account
got
stolen.
Somehow.
B
So
you
put
all
this
together,
there's
some
pretty
easy
ways
to
get
free
certificates
and
keys
that
you
don't
have
to
worry
about
kind
of
disposable,
they're
very
short-lived,
so
you
can
delete
them
after.
In
fact,
they
never
even
get
written
to
disk
in
most
places
and
then
look
up
signatures
for
stuff
later.
B
A
B
Yeah
so
est
and
assist
your
you
know:
static,
analyzers
and
dynamic
analyzer
tools,
six
store
uses
some
of
these
right.
Six
store
uses,
static,
analyzers
codeql
and
you
know
golem
and
all
that
stuff
and
even
some
fuzzing
for
our
own
tools
but
they're,
not
kind
of
part
of
the
you
know
in
the
scope
of
what
six
door
would
offer
to
other
people.
You
can
kind
of
run
those
directly.
We
have
some
nice
formats
actually
based
on
in
toto.
B
B
A
B
Awesome
yeah,
so
let's
take
a
look
at
cosine
itself,
so
the
cosine
repo
is
here:
github.com
sig
store
slash
cosign.
This
is
kind
of
the
easiest
way
to
get
started
with
a
lot
of
the
sig
store,
tooling.
It's
designed
for
signing
container
images,
but
it
can
sign
a
bunch
of
other
things
too.
I'll
show
how
that
works.
There's
even
some
pretty
cool
tooling
for
storing
other
things.
Like
a
you
know,
random,
binary,
executable
or
something
like
that
inside
of
a
container
registry.
B
If
you
want
to
distribute
stuff
that
way,
there's
some
nice
benefits
of
that
so
design
four
containers,
but
not
exclusively
for
containers
so,
depending
on
what
you
want
to
do,
this
still
might
be
the
right
tool
for
you.
So
take
a
look
start
with
repo.
If
you
want
to
contribute,
there's
a
bunch
of
maintainers,
it's
a
very
active
community.
We
try
to
be
very
welcoming,
but
we
can
jump
down
to
the
getting
started
information
here.
B
The
first
thing
that
you
might
think
of
when
starting
with
signing
is
key
management,
and
you
know
normal
kind
of
getting
private
keys,
looking
at
them
distributing
public
keys
and
all
that
stuff
and
there's
dozens
of
ways
to
do
that.
I
don't
think
anyone
is
correct
or
perfect,
so
instead
we
try
to
support
all
of
them
in
cosine.
B
B
All
right,
so
I've
got
the
cosine
tool
here,
we're
going
to
generate
a
key
pair,
which
I'll
show
the
help,
because
there's
a
bunch
of
different
options
here
too,
a
little
big.
The
basic
flow,
if
you
just
run,
generate
key
pair
with
no
flags.
Is
you
get
a
key
on
disk
which
is
awesome?
You
can
use
that
key
to
sign
stuff
and
verify
things,
but
cosine
is
also
integrated
with
pretty
much
every
kms
or
key
management
system.
B
You
can
find
support
the
azure
key
vault,
the
aws
kms,
the
google
cloud,
one
hash
accord,
vault
you
can
use
yuba
keys
if
you
have
one
of
those
that
supports
it,
there's
a
bunch
of
different
options
here,
there's
even
a
really
cool
version
to
work
with
the
tactile
stuff.
Jason
was
showing
yesterday
where
it
generates
the
key
directly
into
a
kubernetes
secret
right
here.
So
it
never
even
touches
your
disk
here.
B
You
just
type
this
give
it
the
name
of
the
namespace
and
secret,
and
you
end
up
with
a
kubernetes
secret,
all
set
up
and
ready
to
go,
which
is
pretty
cool
and
useful
if
you're,
using
like
a
tekton
or
some
of
the
build
packs,
integrations
that
work
inside
of
a
cluster
and
stuff
too
same
thing
for
github
repositories
or
gitlab
repositories.
This
can
create
the
secrets
right
inside
of
those,
I
will
do
the
basic
one
though
get
started
and
I'll
show
you
what
these
keys
look
like.
B
B
So
this
is
pretty
basic.
This
uses
the
elliptic
curve
signing
algorithm
or
ec
dsa.
It's
right
there
in
the
go
standard
library.
So
we
design
this
to
be
as
simple
as
possible
and
you
can
just
kind
of
use
it
with
go
without
needing
any
external
dependencies.
So
these
are
pretty
short.
You
can
copy
paste
them
around.
This
is
the
thing
that
you
want
to
distribute
to
your
users,
so
they
can
verify
your
signatures
now
I'll
show
the
private
key
too.
B
B
B
B
Of
course,
we're
supposed
to
use
dash
dash
key
now
awesome.
So
now
it's
signed
and
we
have
a
signature
up
there.
Next
to
that
image,
I
couldn't
kind
of
show
what
that
looks
like
and
how
it's
stored
in
the
registry
as
well,
if
you're
familiar
with
the
crane
tool,
it's
really
good
for
copying
images
around
looking
at
manifests
and
that
kind
of
thing,
if
you
want
to
dive
into
the
oci
spec,
so
I'll
show
what
that
looks
like
quickly
here.
There's
a
tool
called
sign.
Triangulate.
B
B
So
let's
look
at
that
image
now
you
can
see
what
this
looks
like
with
that
djq
to
make
it
pretty
it'll,
probably
be
a
little
long
yeah.
So
this
is
a
standard
oci
image
manifest.
That's
what
this
session
tells
us
here
in
order
to
make
this
work
and
be
backwards
compatible
with
all
the
different
oci
registries.
We
make
it
look
like
an
image
because
that's
supported
by
everything.
Instead
of
being
an
image,
though,
that
you
can
run
each
layer
here,
stores
signatures.
B
So
that's
what
this
tells
everything
right
here.
You
should
be
able
to
docker
pull
this
thing,
but
you
can't
dock
or
run
it
right,
because
these
aren't
tar
balls,
they
contain
layers,
they
would
get
unpacked
into
your
file
system
each
one
of
these
is
a
signature.
I
actually
signed
this
twice
once
yesterday.
I
didn't
clean
up
before
this,
so
we
have
two
different
signatures
in
here
and
we
should
be
able
to
verify
with
the
key.
B
Since
I
created
a
new
key,
we
should
see
only
one
signature
that
passes
verification,
since
I
just
created
that
key.
We
haven't
used
it
before,
so
one
of
these
will
be
invalid
and
the
other
one
will
be
valid.
Let
me
do
our
verification,
so
let's
type
that
in
here
this
time,
instead
of
the
secret
key,
we
do
the
public
key
and
then
the
same
image
name
as
before.
Let
me
find
it
cool.
B
B
A
Yeah,
I
think
the
basic
flow
is
clear,
like
you
generate
a
key
pair
and
there
are
a
bunch
of
options
where
you
can
have
that
key
pair,
and
then
you
sign
that
image
and
people
can
verify
that
using
the
public
image
that
it's
is
it
signed
by
you
or
you
know,
is
it
is
it
tempered?
So
I
think
that
the
flow
is
pretty
neat.
How
can
we
kind
of
extend
this
to
a
proper
use
case?
So
that's
that
would
be.
You
know.
B
Yeah
great
questions,
so
you
want
to
start
with
kind
of
integrating
this
into
a
build
system.
Typically,
jason
showed
some
stuff
on
tekton
yesterday
and
in
tecton
we
actually
tried
to
make
that
automatic,
so
technical
detect
images
you
build
and
assign
them
automatically,
which
is
pretty
cool,
but
we
can
work
up
to
that
one
and
show
some
kind
of
simpler
flows.
B
I
mentioned
that
you
can
check
these
keys
right
into
a
registry
and
it's
safe
to
do
that.
I've
got
or
right
into
a
repository.
I've
got
one
here
in
github.com
d
lawrence
sign
container.
This
is
a
little
kind
of
hello
world
example
showing
the
simplest
possible
flow
that
makes
sense
for
signing
a
container.
If
you
have
something
built
from
one
github
repository
in
github
actions
and
published
like
ghcr.io,
then
this
one
works
pretty
well
the
id
here
is
you
just
check
them
both
in
we've
got
the
key.
B
We've
got,
I'm
sure
we
have
the
private
key
here.
We
have
the
public
key
this
one's
encrypted,
so
you
have
to
worry
about
it
and
then
the
secret
to
decrypt.
That
key
is
stored
in
a
secret
inside
of
github
actions,
and
this
is
basically
what
gets
set
up.
If
you
do
the
generate
keypair
github
version
that
we
just
added,
and
so
this
builds
images
in
github
actions.
I
think
we
played
around
with
some
new
features.
That's
why
they're
all
those
failing
ones,
but
the
signature
should
all
be
published
here,
the
action
itself.
B
Let
me
try
to
find
that
code.
This
is
set
up
to
publish
a
new
image
based
on
every
ci
build.
So
after
every
something
gets
built
after
something
gets
pushed
to
the
main
branch.
We
do
a
build
and
sign
that.
Then
we
also
assign
things
a
little
bit
differently
for
releases,
so
this
is
pretty
much
the
simplest
way
to
do
it.
We
have
a
we
log
into
ghcr.io
here
using
one
secret,
and
then
we
take
the
other
secret,
which
is
the
password
to
decrypt
the
key
and
run
cosine
sign
with
that.
B
So
this
is
another
little
feature
that
helps
you
build
up.
The
actual
workflows
you
were
just
asking
about,
which
is
the
dash,
a
or
kind
of
an
annotation
flag
to
cosine,
sign
and
verify
this
lets.
You
add
kind
of
arbitrary
key
value
pairs
into
that
signature,
so
these
things
are
actually
signed
as
well.
So
here
we
add
git
sha
equals
the
you
know
commit
so
in
addition
to
signing
the
container
we're
signing
a
little
key
value
pair
explaining
what
commit
this
was
built
at
by
github
actions.
B
The
other
cool
thing
here
is
that
this
also
can
help
users
figure
out
the
right
public
key
to
verify
against,
because
the
git
commit
is
in
here
and
the
key
is
also
stored
in
the
repository.
If
you
want
to
change
or
rotate
these
keys.
For
some
reason,
you
can
do
that
just
by
switching
them
out
in
the
repository
and
then
you
get
a
new
commit
and
everything
will
be
signed
with
that
new.
B
A
Yeah
before
that,
so
you
said
like
we
can
easily,
you
know,
there's
no
harm
in
storing
the
private
key
as
well,
because
that's
that's
not
a
problem
because
there's
a
secret
which
is
there
to
decrypt
this
particular
key.
So
there's
no
harm
in
in
storing
that.
So
I
think
that
that's
also
a
point
because
github
actions
can
use
that
to
sign
that
image,
because
that
is
the
reason.
A
So
you
have
it
over
there
so
that
github
action
from
every
comment
it
can
build
and
it
can
sign
the
image
and
you
know
have
that
digest
also
signed
using
the
dash
a
I
believe
there
was.
It
was
a
flag
over
there,
so
I
think
that's
pretty
cool,
so
that's
the
one
basic
flow
that
people
can
use
in
there.
You
know
in
the
tops
world
that
integrating
with
github
actions
so
and
next
people
want
is
the
fancy
stuff.
B
Yeah
cool
time
for
some
fancy
stuff,
so
some
of
this
is
still
experimental,
so
we're
gonna
have
to
set
a
flag
here,
called
cosine
experimental
equals
true
or
1,
or
something
like
that:
2
1.,
all
right
cool.
So
now
this
flag
is
turned
on.
We
have
access
to
all
the
experimental
features
like
the
transparency
log
and
our
certificate
authority.
B
So
I
showed
in
this
example
that
it's
actually
not
too
hard
to
work
with
keys,
but
you
still
have
the
keys
laying
around.
If
you
lose
the
keys,
you
have
to
go,
tell
everybody
about
it!
You
have
to
tell
everybody
to
stop
trusting
the
old
one,
all
that
terrible
stuff
we've
seen
that
managing
keys
is
always
pretty
hard
to
do
correctly
for
developers.
Anybody
that's
lost
access
to
an
account
because
of
two-factor
auth,
or
something
like
that
knows
exactly
what
I'm
talking
about
here.
So
in
cosine.
B
We
also
support
this
awesome
mode
based
on
the
certificate
authority
we
run
and
our
transparency
logs
called
keyless
signatures.
Let
me
find
the
documentation
explaining
how
this
works
so
what's
easier
than
simple
keys.
Well,
no
keys!
So
if
we
turn
that
mode
on
and
now
sign
the
image
again,
one
more
time
make
sure
let
me
clean
up
those
signatures
first,
just
to
make
it
easier
to
see
what
happened.
We
can
do
that
with
crane.
B
B
So
those
things
should
be
cleaned
up.
It
won't
verify
anymore
now
we're
starting
fresh
and
we're
going
to
sign
with
no
keys
at
all
right
now,
with
the
experimental
mode
turned
on.
This
should
just
work,
explain
how
it
works
in
a
second,
but
there's
no
keys
anymore,
nothing
on
the
command
line,
telling
you
what
keys
to
use
instead
cool
some
stuff
got
printed
to
the
terminal
really
quickly,
and
then
my
browser
popped
open
with
some
login
screens.
So
we'll
go
back
and
I'll
explain
what's
happening
here.
B
So,
if
you're
familiar
with
something
like,
let's
encrypt,
to
manage
certificates,
which
you
might
be
if
you're
using
kubernetes,
it
works
in
a
very
similar
way
with
when
you're
setting
up
let's
encrypt
and
getting
a
certificate
from
them,
your
web
server
or
ingress
controller
or
whatever
you're
using
in
your
cluster
first
generates
a
random
key
pair
right
in
memory.
So
this
works
just
like
before,
except
instead
of
writing
it
to
disk
they
stay
in
memory,
the
entire
time
you
can
see
that
happens
here,
generating
ephemeral,
keys
line.
B
Then
what
you
do
is
you
take
that
public
key
and
you
want
to
send
it
up
to
the
certificate
authority
to
get
that
turned
into
a
certificate
for
you.
So
that's
what
happens
here
with
let's
encrypt
this
happens
using
the
acme
protocol.
Ac
me,
you
can
look
that
up,
but
it's
a
way
to
tell
let's
encrypt,
you
want
a
certificate
with
this
specific
public
key
for
this
domain
and
then,
let's
encrypt
or
whatever
other
acme
enabled
ca
you're
using
it
does
a
little
challenge
before
it
gives
you
that
certificate.
B
It
has
to
prove
that
you
own
that
domain
and
you
actually
have
control
of
it.
So
there's
a
bunch
of
different
challenge
types,
but
they
typically
consist
of
something
like
adding
a
random
string
to
a
dns
text
record
at
that
domain
or
adding
some
fields
to
a
header
that
would
be
served
by
like
a
robot
that
hits
a
url
or
that
kind
of
thing.
So
the
idea
is,
if
they
give
you
some
random
string,
and
you
can
make
it
appear
at
that
domain,
then
that's
proof
that
you
own
it
with
six
store.
B
We
do
basically
the
same
thing
except
we're.
Gonna
sign
this:
instead
of
for
a
domain
we're
going
to
assign
this
based
on
your
email
address,
because
that's
kind
of
the
lowest
common
denominator,
best
form
of
identity
available
to
developers
in
open
source,
you
sign
your
git
commits
with
email
addresses.
That's
how
you
log
into
github.
That's
how
you
work
in
projects.
B
Your
reputation
is
kind
of
based
on
your
email
account
and
how
you
sign
commits
over
time.
So
that's
what
we
do
here
as
well:
let's
encrypt
had
to
make
up
a
whole
new.
Oh
sorry,
I
waited
too
long
I'll
restart
this.
Let's
encrypt
had
to
make
up
a
whole
new
protocol
called
acme
for
their
challenge,
because
this
didn't
exist
before,
but
for
people
and
for
email
addresses.
There
is
a
pretty
well
known
format
here,
and
a
challenge
system
already
called
open
id
connect.
B
B
B
At
the
same
time,
if
you've
heard
stuff
like
certificate
transparency,
that's
how
you
can
protect
against
somebody
issuing
search
for
the
wrong
domain.
We
do
the
same
thing
for
email
addresses
here
and
we
log
all
this
into
transparency
logs
to
make
sure
it's
secure
and
that
people
aren't
pretending
to
be
you.
So
all
that
happened
quickly.
We
never
touched
a
key.
Nothing
ever
got
written
to
disk
and
we
signed
this
image
with
our
email
address.
B
B
A
A
As
per
car
loss,
so
you
are,
you
are
just
getting
the
certificate
and
you
are
using
the
kind
of
email
authority
over
there
and
pairing
up
the
ephemeral
keys
with
that
certificate
and
then
getting
getting
it
signed.
And
when
you
verify
you
can
see
the
issuer
and
the
subject,
and
you
know
home
trust.
So
I
think
that's
that's
pretty
interesting.
There
are
a
couple
of
questions
which
might
be
related
to
the
previous
one.
So
does
cosine
uses
gcr
only
or
it
supports
aws
other
cloud
cloud
registry
as
well.
B
Yeah,
so
let's
find
the
full
list,
so
there's
a
couple
different
things
there.
Let
me
show.
So
this
is
the
entire
list
of
all
of
the
registries
that
cosine
has
been
tested
and
works
against,
so
aws
ecr,
gcr,
docker
hub
azure
acr.
You
know
this
huge
list,
the
only
one
we
know
that
it
doesn't
work
with
so
far
is
actually
quay.io.
B
It
works
in
the
open
source
version
of
quay
which
you
can
find
on
github,
but
the
fix
that
they
needed
to
make
it
work
hasn't
been
deployed
to
the
hosted
or
managed
version
of
clay
running
quay.io,
yet
so
yeah.
This
is
probably
you
know
fewer
registries
than
it
actually
works
on.
These
are
just
the
only
ones
I
found
to
test
it
against.
I
think
we're
probably
missing
a
few
here,
but
it
should
work
basically
with
any
registry.
The
other
aspect
which
I
guess
you're
getting
is
the
kms
system
one.
B
B
A
B
Yeah,
so
the
keyless
flow
is
awesome
and
it's
really
great
for
people.
One
of
the
other
cool
features,
though,
which
we
just
did
a
couple
of
blog
posts
on,
is
that
you
can
also
use
that
keyless
flow
now
with
automated
systems
like
tecton
chains
or
even
github
actions,
because
that
open
id
connect
protocol
that
you
typically
think
of
is
for
people
when
you
click.
B
That
button
also
works
with
automated
systems
too,
and
there
are
a
bunch
of
different
examples
of
this,
but
it
works
pretty
well
with
if
you're,
using
gke
or
google
kubernetes
engine
there's
a
feature
called
workload
identity
where
each
pod
can
get
access
to.
You
know
just
a
an
identity
token,
it's
called
that's
the
same
thing
that
you
send
up
to
six
star
to
get
a
certificate.
B
You
can
get
one
of
those
for
a
workload
running
in
kubernetes
using
workload,
identity
aws
has
a
version
of
it
that
works
too.
With
workload
identity,
federation,
everybody
speaks
that
same
protocol
and
instead
of
getting
a
certificate
for
a
person,
you
would
get
a
certificate
issued
to
kind
of
that
exact
workload.
B
B
B
B
They
give
this
to
you
and
then
your
github
actions
can
authenticate
as
that
action,
and
so
again
we
can
sign
now
without
keys.
You
don't
need
keys
in
here
at
all,
and
this
gets
signed
with
a
kind
of
string
that
says
which
repo
it
was
in,
exactly
which
github
workflow
and
even
which
commit
that
it
ran
at,
and
so
this
and
this
is
all
handled
by
github.
So
let
me
find
I
guess
we
can
just
try
this.
I
don't
know
if
I
deleted
the
signatures
since
I
ran
this.
B
So
if
you're
a
person
you
can
sign
with
your
email
address,
if
you're
an
automated
system
running
in
any
environment
that
supports
open
id,
connect,
tokens
or
id
tokens,
you
can
do
that
as
well.
So
here,
instead
of
the
email
address,
we
get
this
url
showing
exactly
where
this
was
built
at
with
the
commit-
and
this
is
all
signed
and
verified
by
github
in
this
case,
so
you
can
see
the
repo
it
came
from
no
keys
had
to
be
managed
or
anything
the
exact
file
that
ran
build.aml.
B
B
Yeah,
we
try
to
you,
know,
find
out
the
actual
hard
parts
about
signing.
It
turns
out
the
signing
itself
isn't
the
hard
part.
The
hard
part
is
really
the
key
management
and
distribution,
I'm
trying
to
make
that
as
easy
as
possible
here.
So
it's
awesome
that
everybody
supports
these
same
protocols,
because
you
can
do
this
across
different
systems.
B
The
example
I
had
here
and
we
can
run
through
some
of
this
stuff-
is
kind
of
putting
some
together
some
of
these
systems.
Let
me
see
if
I
have
a
slide
on
it.
I
think
it
was
from
this
demo
here,
no
down
a
bit
here,
we
go
yeah.
So
this
is
a
rough
diagram
on
the
demo
I
put
together
showing
kind
of
that
concept.
B
I
talked
about
before
of
finding
some
binary
on
the
ground
and
then
tracing
it
back
all
the
way
to
where
it
came
from,
I'm
going
to
run
through
some
of
the
commands
to
show
what
it
looks
like,
but
this
was
two
different
repositories:
two
different
github
organizations,
building
container
images
so
that
hello,
co,
one
is
the
second
one
in
the
chain.
You
know
that
comes
here
in
my
application
image,
the
from
line
in
that
the
base
image
that
gets
used
by
that
image
is
actually
distro-less.
B
So
this
the
distrolus
images
are
built
here
on
github.
These
are
built
using
google
cloud,
build
and
techton.
Actually
so
they're
built
twice
they're
built
reproducibly,
so
you
can
build
it
multiple
times
with
different
systems
and
you
get
the
same
digest,
which
is
a
pretty
cool
feature,
and
so
these
actually
get
built
by
two
different
systems
and
signed
by
both
of
those
systems
using
cosine
and
the
full
build
history
is
also
logged
and
signed
again
by
both
of
those
systems.
B
B
You
can
see
that
that
is
a
commit
yep.
That's
the
most
recent
commit
it's
the
same
thing
here,
so
we
know
that
the
final
image
the
hello
code
was
built
from
here
and
then
what
we
can
do
is
look
up
the
base
image
and
go
back
and
find
all
the
commits
that
went
into
the
base
image
too,
because
those
can
also
affect
your
supply
chain,
and
so
the
way
we
do
that
is
by
looking
at
the
image
itself
hold
it
here.
B
Let's
do
crane
manifest
awesome,
so
we
can
see
this
image.
It's
got
a
bunch
of
layers.
This
is
basic,
go
code.
It
prints
out
hello
world
when
you
run
it,
but
what
we
can
see
here
at
the
bottom
is
this
extra
annotation,
which
just
got
approved
by
the
open
containers
initiative
to
specify
the
base
image
for
something.
So
this
is
in
the
manifest
and
we
can
see
it.
B
B
You
can
see
that
here
we
get
the
base
image
and
now
we
can
actually
look
up
how
that
base
image
was
built
using
just
the
sha,
so
this
is
going
to
show
us
on
the
transparency
log
features.
This
is
the
shot
256
as
the
base
image,
and
if
we
take
that
and
look
it
up,
we're
going
to
see
a
bunch
of
builds
here.
B
B
So,
let's
just
take
one
of
these
copy,
this
command,
so
I
don't
have
to
retype
the
whole
thing
and
make
it
pretty
and
we're
going
to
see
exactly
how
that
image
was
built
and
start
walking
back
the
chain
on
that
usb
thumb
drive
example
that
I
talked
about
before.
So
we
see
a
bunch
of
json
here
right
and
this
comes
from
tecton
the
tecton
chain,
stuff
jason
was
showing
yesterday
tekton
in
addition
to
signing
the
image
itself,
also
signs
this
big
payload
explaining
exactly
what
happened,
how
it
built
that
image,
what
went
into
it?
B
B
B
Change
that
here's
the
document
september
17th
that
that
image
was
built
from
on
the
distrolus
based
image,
which
is
pretty
cool.
We
can
see
the
steps
that
ran
as
well
the
exact
comm,
the
exact
containers
that
were
on
this
golang
one
and
how
all
of
this
was
generated.
So
we
can
mock
all
this
back
all
the
way
to
the
commits,
which
is
pretty
powerful.
A
Yep,
I
think
that's
that
makes
much
more
sense.
You
know
how
how
it
is
getting
used.
You
know
in
in
kind
of
a
scenario
which
actually
people
would
use,
so
that
makes
a
lot
of
sense
and
crane
crane
is
is
a
good.
You
know
is
looking
good
with
all
its
features.
People
actually
want
to
know
more
yeah.
Also.
What
about
the
record
cli
as
that
that
you
introduced
like
what
quantity.
B
Now
what
I
was
doing,
there
was
I'm
kind
of
just
dropping
down
to
the
recourse
cli.
Let
me
go
back
to
the
sig
store
page,
which
is
for
interacting
with
the
transparency
log
directly.
You
can
see
the
recoil
repo
here
if
you're
using
cosine.
You
normally
don't
have
to
worry
about
this
because
it's
automatic.
But
if
you
want
to
play
around
or
put
your
own
signatures
into
this
log
or
look
stuff
up
yourself,
then
the
recourse
cli
is
the
way
to
do
it.
B
So
that's
what
I
did
here.
I
did
a
recourse,
cli
search
or
yeah.
I
did
a
search
and
then
I
get
to
fetch
a
specific
entry.
So
with
the
search
this
command
basically
says
tell
me
everything.
That's
in
the
transparency
log
about
this
specific
artifact.
You
can
pass
in
a
file
if
you've
got
one
a
binary
or
a
github
commit
id,
or
something
like
that
and
it'll.
Just
tell
you
everything,
that's
in
the
log
about
that
commit,
and
you
can
look
through
those
and
see
if
there's
anything
in
there
that
you
like
or
don't
like.
B
You
can
also
search
for
your
email
address
and
see
all
the
signatures
that
you've
created
with
your
email
address
and
use
that
for
auditing
yourself.
So
yeah,
that's
the
kind
of
power
cli
for
interacting
with
the
transparency
log.
You
can
do
stuff
like
audit
the
log
and
see
how
many
entries
there
are.
B
So
we
have
800
and
thirty
nine
thousand
one
hundred
and
forty
six
entries-
and
this
shows
some
of
the
cool
merkle
tree
hash
stuff,
which
kind
of
you
could
talk
for
several
hours
about
how
transparency
logs
work
too
much
for
this
session.
But
every
time
you
run
this,
you
actually
do
a
proof
and
make
sure
that
the
log
hasn't
been
tampered
with
as
automatically
that's
this
line
here,
showing
that
the
log
is
healthy
and
we
haven't
tampered
with
it
at
all.
B
B
B
B
What
does
digest
revision
mean?
I'm
not
quite
sure
where
that
one
comes
from.
Revision
probably
refers
to
the
git,
commit
that
something
was
built
at
or
they
get
tagged
or
something
like
that
digest
is
like
the
typically
with
containers.
It's
the
sha256
colon
thing.
That's
used
to
address
the
container
image
if
the
container
image
changes
you'd
get
a
different
digest,
I'm
not
sure
if
that
answers.
The
question,
though,.
A
Awesome,
so
I
think
we
did.
We
discussed
a
bunch
of
stuff
today,
starting
from
you
know
the.
Why
and
the
watts
of
surprising
security
why
it
is
important
there
have
been
attacks.
I
mean
it's
a
proven
study
that
shows
the
graph
is
increasing
over
the
time
with
respect
to
the
attacks
that
are
coming
in
and
it's
it's
pretty
interesting
to
see
those
and
the
landscape
growing.
More
and
more,
you
shared
the
foundation,
so
that
has
a
lot
of
projects
which
are
there,
and
people
can
get
involved.
A
So
it's
kind
of
foundation
just
like
cncf.
There
is
one
for
the
you
know
or
the
supply
chain
security
which,
with
bunch
of
projects
that
you
can
get
involved
with
and
with
a
purpose
so
and
today
we
also
talked
mainly
talked
about
six
store.
What
it
does.
What
main
purpose
is
you
know
the
signing
verifying
monitor
and
then
you
have
your
cosign,
the
main
project
which
is
there
so
how
to
use
cosign.
A
A
You
know,
use
that
to
sign
that
every
time
and
then
more,
you
know
complex
workflows
and
then
the
experimental
feature,
which
is
good
you
know,
keyless
signing,
is,
is
kind
of
important
because
I
mean
people
do
not
want
to
rotate
the
keys
manage
the
keys.
So
if
you
can
just
sign
them
via
the
email,
you
know
just
like
getting
the
certificate
ccd
while
it
since,
let's
encrypt
so
you
can
do
kind
of
in
a
similar
manner.
A
A
B
Oh
man,
that's
a
great
idea,
I
think,
probably
the
best
place
where
people
have
been
sharing
that
so
far
is
in
the
sig
store
slack.
You
should
go
ahead
and
join
that
at
you
can
find
the
link
at
github.comcommunity
people
have
been
asking
questions
and
coming
up
with
good
recommendations
on
best
practices.
A
Yeah
awesome,
I
think
that's
that
would
be
nice,
so
we
can
have
a
place
where
people
can
actually
put
their
use
cases
how
they
are
using
it
so
that
other
people
can
also
adopt
okay.
This
is
also
one
use
case
that
you
know
people
can
use
cosign
for,
and
these
are
some
of
the
practices
that
they
are
following,
and
I
think
that
can
be
a
build
and
learning
activity
for
everyone
who
is
new
or
everyone
who
is
experienced,
and
you
know
kind
of
using
it
in
different
ways.
That
would
be
pretty
interesting.
A
Yeah
make
sure
you
join
the
slack
channel
so
so
that
you
know
you
can
you
do
not
miss
out
on
any
of
the
fun
that
is
happening
in
the
community?
You
know
how
people
are
using,
because
slack
is
of
the
place
for
for
the
activity
which
is
going
over
there
and
yeah
people,
people
and
you
can
see
all
the
positive
comments
which
are
there.
So
you
know
thank
you
so
much
dan
for
tuning
in
and
explaining
the
the
supply
chain.
Security.
A
The
right
way,
cosign
the
right
way,
multiple
demos,
starting
from
very
basic
to
the
advanced
use
case.
I
I
think
I
learned
a
lot
pretty
much,
so
I
am
hoping
that
people
watching
and
who
will
be
watching
later,
must
have
learned
something
new
today,
so
that
that's
pretty
amazing
stream,
as
expected
from
you
right.
Thank
you.
B
A
A
A
A
A
And
two
two:
is
you
raj?
I
awesome
awesome,
so
congratulations
to
all
the
winners.
You
will.
I
don't
know
we
might
contact
you
via
the
email
or
the
cd
foundation
or
myself
so
we'll
see
who
will
be
contacting
you
later
on.
So
thank
you
so
much
for
tuning
in
this
was
day
two
of
ci
cd
days
and
it's
it's
been.
You
know
really
great
to
have
you
all
and
thanks
to
dan,
for
tuning
in
and
explaining
about
co-science,
six
store
supplies
and
security,
awesome
demos.
A
So
thank
you
all
for
tuning
in
and
see
you
tomorrow,
we'll
be
learning
about
argo
cd
again
another
interesting
project
and
make
sure
you
subscribe
to
the
channel
and
send
you
know,
send
the
playlist
and
the
links
to
your
friends
as
well.
So
thank
you
so
much
for
the
session
see
you
tomorrow.
Thank
you
so
much
dan
for
tuning
in
have
a
nice
day
bye.
All.