►
From YouTube: Kubernetes SIG Security 20210311
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
everyone
to
yet
another
kubernetes
sig
security.
I
am
delighted
to
see
so
many
great
people
here.
We
have
a
lot
of
neat
things
to
share
today,
so
I
guess
we
can
jump
right
in
savita.
What
do
you
want
to
tell
us?
How
is
docs
coming.
B
So
we
last
week
we
discussed
about
the
hardening
guide.
I
think
it's
in
a
good
place
right
now
it
has
all
the
basic
stuff
and
we
can
get
started
so
depending
upon
the
highlights
include
that
we
will
be
creating
a
k
website
issue
with
all
the
areas
identified
and
depending
upon
rory's
availability.
B
C
Yeah,
that's
that's
dead
on
yeah,
so
I'm
hoping
I
will
so
I'm
going
to
create
the
google
doc
for,
like
we've,
got
a
brainstorming
guide
which
was
linked.
I
think
in
last
time's
notes
in
here,
and
the
idea
now
is
to
like
explode,
that
into
a
proper
google
doc
with
all
the
actual
sections
and
then
yeah
savvison
says
we're
gonna.
Look
at
trying
to
break
that
up
and
say
you
know.
C
People
can
contribute
different
areas
and
that
process
yeah,
I'm
hoping
to
get
time
to
start
that
off
next
week
and
then
we'll
get
everyone
to
jump
in.
A
The
tall
trim,
docks,
awesome,
yeah
I'll
I'll,
just
say
that
kind
of
process
seemed
to
work
really
well
for
sig
security,
with
the
like
cloud
native
basic
security
white
paper
that
they
put
out
recently,
you
know
they
they
did
it
with
like
a
brainstorming
time
and
then
once
they
had
an
outline
written,
then
various
folks
agreed
to
contribute
to
different
sections
of
the
outline
and
that
process
seemed
to
be
really
effective
for
them.
B
Wonderful,
I
saw
it
very
successful
and
then
I
also
realized
that
it's
not
just
on
one
person.
It's
divided
and
more
knowledge
will
be
shared
and
we
can
have
conversation
stuff
like
that.
So
yeah.
A
Do
you
want
to
do
you
want
to
go
next
and
tell
us
about
what
happened
with
the
conversation
with
lori.
B
Yeah,
so
I
brought
the
topic
about
the
security,
the
security
reviews
to
the
secret
release
meeting
like
a
month
ago.
Sorry
I
couldn't
follow
up.
B
So
one
of
the
things
that
came
up
was
that
it
can
be
discussed
when
a
feature
is
proposed
and
if
the
and
then
it
could
be
an
opt-in
process
and
if
the
leads
determine
they
can
recommend
that
if
it's
needed
or
not
so
that's
where
it
could
fit
in
and
and
stephen
talked
about
a
little
bit
about
the
scope
and
how
they
are
so
they
are
in
the
whole
revamp.
B
They
are
revamping
the
process
and,
as
everyone
knows,
the
announcements
opt-in
process
now
and
they
are
making
this
nice
tool
and
they
are
also
having
different
kind
of
tracking
like
it's
entry
out
of
three
or
whatever.
So
I
have
linked
the
scope
issue
there.
They
encourage
us
that
we
can
add
our
thoughts
in
where
it
could
fit
in
or
attend
a
participate
in
one
of
the
meetings
and
bring
it
up.
Unfortunately,
the
enhancements
of
project
meeting
the
new
time
also
collides
with
the
work
conflict
for
me.
B
So
I
I'm
not
able
to
go
to
that.
One
to
talk
more
about
it
and
laurie
created
a
nice
mirror,
project
build
and
probably
she's
gonna
add
about
security
reviews.
There
I
followed
up
and
I
think
I'm
gonna
create
a
thread
on
release
so
that
all
of
us
can
pitch
in
there
about
this.
I
know
I
just
kept
talking
awesome.
B
So
if
anyone
would
like
to
represent
this
and
then
if
anyone
gets
to
go
to
the
enhancements
project
meeting
and
gets
to
talk
about
this,
I
they'll
be
nice
or
we
can
all
follow
up.
Asynchronously.
A
Yeah,
if,
if
somebody
could
be
so
kind
as
to
look
at
the
kubernetes
calendar
and
put
a
link
in
the
notes
to
when
the
enhancement
sub-project
meeting,
is
to
make
it
a
little
easier
for
the
rest
of
folks
to
figure
out
whether
they
can
actually
go
and
do
that
be
awesome
ian,
do
you
have
a
moment
to
tell
us
about
psp.
D
I
might
so
we,
a
breakout
group
comprised
of
sig
auth
and
some
folks
from
sig
security
have
been
meeting
up
to
discuss,
psp
replacement
and
what
comes
next,
and
at
this
point
I
think
that
we've
come
up
with
an
idea
that
everybody
likes
jordan,
liggett
demoed
it
at
the
breakout
meeting
yesterday.
D
So
I
think
at
the
end
of
that
meeting,
we
decided
that
we
were
going
to
ship
it
to
a
cap,
so
we're
going
to
kept
it
and
write
that
and
that's
very
exciting.
E
I
am
happy
to
kind
of
walk
through
the
proposal.
If
that
would
be
useful
here.
It's
also,
I
think,
linked
in
the
agenda,
so
feel
free
to
take
a
look
yourself.
The
one
thing
I
would
add
is
I.
I
am
very
optimistic
that
it's
going
to
go
to
kepp,
as
is,
but
I'm
going
to
send
out
a
survey
to
the
sigoth
and
sig
security
mailing
lists.
E
Just
asking
for
you
know
any
outstanding,
big
concerns
about
this
approach
before
we
move
to
the
cap
process,
so
keep
an
eye
out
for
that.
Jordan
wanted
to
re-record
his
demo.
So
that's
the
only
reason
that
hasn't
gotten
out
yet
but
yeah.
Then
I'm
optimistic
that
we
won't
have
any
big
outstanding
issues
there.
We
can
iron
out
some
of
the
technical
details
in
the
kep
process.
E
In
the
kep
process
and
then
yeah,
so
I
think
the
the
plan
is
if
we,
if
we
proceed
to
cap,
we'll
open
the
cap
and
then
probably
also
get
started
on
the
pod
security
policy,
deprecation,
blog
post
and
now
that
we
can
talk
about
kind
of
what
the
path
forward
looks
like
and
then
work
on.
Getting
that
kept
approved
and
hopefully
get
an
alpha
implementation
into.
A
A
Yeah
anybody
anybody
have
anything
that
they
want
to
talk
about.
With
respect
to
this
right
now,
yeah,
the
the
doc
is
the
doc
is
there,
but
we
could
do
like
a
two
minute.
This
is
the
gist
of
what's
in
the
dock.
If
people
would
like
that.
A
A
A
Good
and
so,
and
so
yeah
that
seems
like
this
seems
like
a
good
thing
and
it
seems
like
the
hardest
part
about
it
is
the
testing
and
the
roll
out,
because
you
know
the
pause
container
is
one
of
those
things
that
is
so
simple.
You
can't
break
it
and
if
you
do
break
it,
the
whole
world
is
broken
and
so
yeah,
if
you
think,
that's
if
you
think
that's
cool,
go
ahead.
That
pr
is
linked
here.
A
Another
thing
that
especially
docs
people
may
be
interested
in
is
the
kubernetes
website
pr25735,
which
is
clarifying
some
steps
in
the
documentation
about
how
to
get
certs,
and
apparently
there
were.
There
were
some
bits
in
there
that
were
missed,
such
that.
If
you
were
an
expert
already
familiar
with
the
process,
you
could
follow
it
successfully.
But
if
you
were
not
already
an
expert
familiar
with
the
process,
you
would
get
kind
of
stuck.
A
So,
if
folks
want
to
have
a
look
at
that,
that
is
a
thing
and
the
third
one
for
people
who
are
really
interested
in
api
design
and
the
you
know
ability
to
more
finely
control
certificates
that
are
being
asked
for
out
of
the
kubernetes
certificate.
A
Signing
features,
there's
a
pr
here
to
add
fields
to
the
csr
in
order
to
control
certificate
lifetime
and
there's
a
couple
of
options
that
are
being
talked
about
about
how
to
how
to
make
that
look
like
what
fields
should
be
asked
for,
because
you
can
either
ask
for
when
you
want
your
certificate
to
be
done,
or
you
can
ask
how
long
you
want
your
certificate
to
live
for
and
in
like
normal
human
time
scales
like
back
when
I
got
a
komodo
website
certificate
for
my
apache
server.
A
The
difference
between
those
two
didn't
really
matter
because
it
was
measured
in
like
years,
but
with
some
of
the
some
of
the
automated
certificate
issuance
workflows
that
people
have.
If
you're
issuing
a
certificate,
that's
good
for
a
matter
of
hours,
then
the
difference
between.
I
want
it
to
be
good
for
this
long
and
I
want
it
to
be
good
until
then
can
actually
be
a
meaningful
difference
to
you,
because
one
includes
the
lag
time
required
for
your
cert
to
get
issued
and
the
other
doesn't.
A
So,
if
that's
your
thing,
go
and
check
it
out
and
having
gone
through,
those
luke
has
come.
Let's
see,
did
luke
make
it
on.
F
A
Luke
has
come,
and
luke
is
gonna
tell
us
about
something
that
is
super
cool.
F
Cool
okay,
I'm
gonna
share.
Okay,
I've
got
audio.
F
Bear
with
me
share
screen:
okay,.
G
F
F
Okay,
is
that
good,
look
good,
great,
okay,
so
sixth
law,
so
some
of
you
might
have
already
heard
about
the
project.
There
was
a
little
bit
of
a
media
frenzy
a
couple
of
days
ago,
because
we
announced
that
we're
launching
under
the
linux
foundation,
but
we've
been
working
on
this
for
a
few
months
now
and
it's
essentially
coupling
software
signing
with
transparency,
essentially
transparency
log.
So
so
we're
going
to
what
you
know,
what
constitutes
software
signing
and
transparency,
so
open
source
supply
chains?
F
F
Over
these
you're
you're
a
knowledgeable
audience
I'll
kind
of
skip
past
this,
so
we've
been
a
few
of
us
be
looking
up.
You
know.
I
know
lots
of
people
have
been
looking
at.
What
can
we
do
to
help
here?
Okay,
so
so,
rather
than
reinvent
will,
is
there
any
existing
technologies
out
there
that
we
can
adapt
and
utilize?
F
They
would
generate
a
csr
they'd
say:
hey
mr
ca.
Please
sign
my
certificate
signing
request.
I
own
this
domain.
The
ca
would
then
do
some
checks.
All
of
this
would
happen
behind
closed
doors.
You
know
they
would
perform
some
sort
of
validation,
perhaps
done
by
human.
F
Perhaps
an
automated
system
would
do
the
check
and
then
they
go
yep
you're
good.
There's
your
signed
certificate.
Then
the
browser
comes
along
and
says:
hey
ca.
I've
got
you
in
my
browser
root
store.
I
want
to
go
to
bigbang.com.
Are
we
good?
He
says
yep
we're
good
and
then
you
get
the
green
padlock
and
everything
looks
great
okay.
F
F
F
So
we
then
look
at
certificate
transparency.
So
now
we've
got
this
certificate.
Transparency
log
same
flow
happens
again,
big
bank.
Can
you
sign
yeah?
Let
me
check
there,
you
go,
there's
your
signature
and
then
we
have
the
browser,
but
the
difference
now
is
this:
ca
submits
for
inclusion,
the
certificate
chain
into
the
transparency
log,
and
it's
a
public
transparency
log.
So
now
the
browser
will
have
a
an
except
expect.
F
Excuse
me
expect
ct
in
the
header:
okay,
which
means
it
will
request
to
see
if
the
certificate
is
in
the
transparency
log.
If
it's
not,
then
a
majority
of
the
browsers
will
kick
back
with
some
sort
of
red
screen
of
warning.
Okay
and
at
the
same
time,
people
can
then
monitor
these
logs.
So
you
have
these
systems
called
monitor,
so
they
will
monitor
for
instances
of,
for
example,
domain
names
that
they
have
occurring
within
the
certificate
transparency
log.
F
So
if
they
were
to
query
the
log
and
they
found
a
domain
had
been
signed
and
it
wasn't
them,
then
they
know
right.
Something
has
happened
here
and
then
you
have
non-repudiation,
because
this
is
based
on
that
certificate
chain.
So
you
can
effectively
see
a
certain
ca
sign
this
certificate
signing
request,
so
you've
got
undisputable
proof
that
a
particular
ca
has
signed
something
that
doesn't
belong
to
them
or
to
a
domain.
It
doesn't
belong
to
the
person,
that's
requesting
the
signing.
So
that's
sort
of
a
very
quick
overview
of
certificate.
F
Transparency,
they're
run,
let's
encrypt
run
one
cloudflare.
Quite
a
few.
Other
people
run
certificate
transparency
logs,
so
we
thought
you
know.
Could
we
do
the
same
thing
for
software
signing
software
transparency?
F
So
we
started
to
work
on
this
a
few
months
ago
and
so
for
software
transparency.
You
can
then
ask
questions
such
as
is
someone
else
using
my
private
key
to
sign
artifacts,
so
you
can
search
for
your
public
key
in
the
transparency
log.
If
the
key
is
compromised,
you
can
look
at
the
blast
radius,
so
you
can
find
artifacts
that
are
signed
by
a
particular
keeper.
Okay,
that
has
been
compromised.
F
You
can
ask
questions
such
as
who
signed
a
particular
release
based
on
the
digest
of
that
artifact,
and
then
you
can
ask
questions.
Like
is
everybody
else
in
the
same
as
me,
so
you
might
have
a
targeted
attack
where
there's
some
sort
of
hostile
mirror
or
packaging
system
compromise,
which
is
pro
which
is
serving
you
a
release,
that's
different
to
what
everybody
else
is
getting.
So
you
can.
Then
you
have
a
a
party
that
you
can
attest
to
to
see
what
else
is
available?
Okay
and
then
also.
F
So
we
we
sort
of
had
a
look
around
while
we
were
doing
this
at
different
projects
and
their
their
sign-in
infrastructure,
but
the
one
to
the
left
is
tails
os,
which
is
the
linux
distribution
that
edward
snowden
used
and
it's
used
by
people
that
are
journalists
and
they're
sharing
sensitive
materials,
etc.
Okay
and
they're
everything's
on
a
wordpress
site.
So
obviously
all
of
this
can
be
compromised
and
swapped
out
to
the
right
is
from
the
node.js
project.
F
F
Some
possibly
might
not
even
be
in
contact
anymore
and-
and
I
just
want
to
point
out
we're
not
this-
isn't
blaming
the
victim
here,
they're
doing
the
best
with
what
they
have.
Essentially,
you
know
they're
trying
to
they're
trying
to
do
the
right
thing.
Okay,
but
it's
obviously
problematic.
F
So
we
thought
you
know,
let's,
let's,
let's
build
a
software
transparency
log
which,
which
we've
done
now
so
this
is
a
project
called
recall.
So
it
is
obviously
it's
an
open
source
project.
You
can
go
and
stand
up
the
server
yourself.
We
have
client
tooling,
where
you
can
submit
a
sign
in
manifest
a
signature,
public
key
or
digest.
F
Okay,
and
you
can
then
do
inclusion,
proofs
and
various
operations
to
to
check
the
integrity
of
the
the
tree
using
the
cli
that
we
have,
and
these
instances,
like
I
say,
they'll-
be
completely
auditable
by
third-party
monitors
and
and
we've
got
some
folks
from
purdue
university
that
are
developing
on
a
monitor
at
the
moment.
So
that's
that's
the
the
recall
project.
It's
in
the
six
store
or
six
store
is
our
overall
umbrella
name
space,
and
then
we
have
the
various
projects
under
there.
F
F
They
place
that
into
the
log.
It's
not
actually
the
object.
That
goes
in
we'll
see
what
goes
in
shortly
and
they
can
then
monitor
the
log
for
other
people's
signing
a
particular
artifact,
because
the
artifact
has
a
digest.
They
can
look
at
other
people
using
their
key,
which
suggests
a
key
compromise
and
then
likewise,
users
can
then
check
against
the
targeted
attack
and,
for
example,
somebody
like
red
hat
could
check.
Is
anybody
utilizing
their?
You
know,
artifacts
that
have
their
digest
or
their
keys,
their
gpg,
keys
and
so
forth?
F
So
that's
currently
what
we
have
now
like.
I
said
it's
very
simple
overview
and
there's
quite
a
bit
more
to
it
than
this,
but
that's
that's
practically
where
we
are
at
the
present.
So
with
the
manifests.
Essentially,
as
you
can
see,
it's
json,
okay,
so
you're
not
putting
the
the
the
blob
into
the
tree.
Okay,
what
you're
doing
is
you're
putting
in
a
manifest
okay,
and
these
are
highly
sort
of
customizable
and
extensible,
so
they
support
multiple
sign-in
tools,
so
pgp
x509
and
mini
sign.
F
Okay
and
then
essentially
you
you
send
across
the
url
to
where
the
artifact
is.
You
could
also
source
it
locally:
okay,
a
public
key.
Now
this
is
on
a
url,
but
again
it
could
be.
You
could
point
to
it
locally,
on
your
your,
your
disk,
so
to
say
using
a
command
line
flag
and
then
the
artifact
that's
been
signed,
and
this
goes
up
to
recall,
which
then
performs
a
sign-in
validation.
F
F
F
F
So
anybody
that's
not
familiar
with
merkle
trees.
This
is
essentially
how
the
transparency
log
works.
You
have
the
manifest
goes
into
the
tree.
So
at
the
bottom
you
have
what
we
consider
leafs,
okay
and
each
leaf
is
concatenated
and
hashed
until
you
construct
an
eventual
root
hash,
which
is
a
snapshot
of
the
current
state
of
the
tree.
Okay,
they're,
nothing
new.
I
think
their
first
utilization
was
bittorrent.
So
if
you've
got
star
wars.mpeg,
that's
been
shared
out
between
seeds
and
what
have
you?
They
would
split
that
into
a
hundred
file
parts.
F
Each
file
part
would
be
hashed,
they
would
compute
a
merkle
tree
okay
and
then,
as
you
receive
those
file
parts,
you
can
perform
an
inclusion
proof
to
make
sure
that
some
particular
seed
or
what's
the
name
of
the
ones
that
don't
share
bandwidth
very
well.
I
can't
remember
somebody
might
remember
somebody's
not
taken
a
corrupted
part
and
trying
to
corrupt
the
overall
file.
Okay,
git
uses
a
type
of
local
tree
and
blockchain
transactions,
I
believe,
are
signed
using
some
sort
of
local
tree
hash
implementation.
So
they
are
around.
F
This,
isn't
like
a
newly
baked
crypto
algorithm,
okay,
so
kind
of
a
very
high
level
architecture
to
the
left.
You've
got
your
your
creators,
okay,
so
your
developers,
your
build
systems,
your
tools
and
they
generate
these
manifests
and
we're
format
agnostic.
So
we
typically
deal
with
json.
F
If
you
really
want
to
go
there,
you
could
use
xml,
okay,
and
these
are
sort
of
pushed
to
recall-
and
I
should
mention
at
this
point
when
you,
if
you
were
to
integrate
with
recall
it's
a
restful
api.
We
use
open
api,
so
there's
a
swagger
ui,
so
you
don't
have
to
work
out
how
to
compute
inclusion,
proofs
and
all
of
that
sort
of
stuff.
That's
abstracted
away
behind
our
api
and
then
you
would
have
your
auditors.
F
So
these
would
be
your
package
managers,
security,
researchers,
perhaps
anti-virus
vendors
and
they're
monitoring
the
log
for
integrity
and
looking
for
certain
behavioral
patterns.
Okay
and
then
you
have
your
clients,
so
the
ones
that
ingest
and
consume
artifacts-
okay
and
they
can-
then
perhaps
you
know,
construct
their
own
policy
and
and
make
sure
they're
not
going
into
any
sort
of
replay
or
targeted
attack.
F
So
this
is
recall:
okay,
like
I
said,
a
plugable,
pko
interface
and
pluggable
formatting.
We
call
it
manifest
agility.
Okay,
so
there's
plans
to
support
various
types
and
yeah,
so
we
are
kind
of
live
with
this.
We
have
a
a
public
instance.
That's
running
we're
in
a
kind
of
a
soft
launch.
We
say
soft
launch
as
in
there's
no
guarantee
that
we
can
retain
the
data,
because
we
are
still
sort
of
refining
things
and
we
might
find
bugs.
But
I'd
say
the
maturity
of
the
project's.
F
Very,
very
good:
now
you
know:
we've
we've
had
an
established
instance,
that's
running
for
some
time
and
there's
been
been
very
few
problems,
so
problem
solved,
no
because
nobody's
signing
stuff
still
so
we've
got
this
transparency
log,
which
is
great,
but
it's
not
really
that
useful
if
nobody
really
uses
it.
So
we
sort
of
did
some
due
diligence
in
this
space
and
came
up
with
this
idea
of
sig
storm.
So
it's
kind
of
this
is
an
extension
of
recall
where
we
introduce
these
new
components,
and
this
is
what
we're
hacking
on
at
present.
F
So
we've
solved
the
transparency
part,
but
very
few
projects
signed
software
releases.
Current
signing
tools,
don't
scale.
How
are
people
going
to
do
a
web
of
trust
and
sign
each
office
keys
when
we've
got
a
pandemic
region
outside
none
of
this
works
well
in
automation
or
devops.
You
know
you're
managing
your.
A
F
Keys
and
so
forth,
it's
just
it
just-
doesn't
really
work
to
the
current
sort
of
situations
and
systems
that
we
have
and
not
only
do
very
few
bother
to
sign
even
less
bother
to
verify.
Okay.
So,
like
I
said
we
did
some
due
diligence
and
the
linux
kernel.
It's
tofu
trust
on
first
use
a
lot
of
projects.
The
public
keys
are
on
a
readme,
perhaps
or
a
wordpress
site,
sorry
to
say:
kubernetes
are
not
signing
anything
at
all,
and
you
know
we've
been
talking
to
you
folks
about
that.
F
F
Sometimes
it's
you
know
these
things
are
very
optional,
so
it's
a
very
dotted
landscape.
Okay,
so
really
we
come
back
to
this
thing
of
signing
should
be
simple,
but
really
it's
far
from
that
now
a
little
caveat.
F
There
are
your
kind
of
very
security
savvy
people
that
have
a
you
know:
hsn
or
a
ub
key
and
they're,
very
comfortable
handling,
gpg
keys
and
so
they're,
not
really
the
audience
that
we're
looking
at
here.
It's
it's.
It's
everybody
else
that
was
trying
to
maintain
oss
projects,
and
so
they
have
problems
of.
Where
do
I
store
my
private
key?
Do
I
need
to
buy
yubikey?
How
do
I
set
it
up?
F
F
Everything
is
public
and
transparent,
so
anybody
can
query
around
signing
signing
materials
or
digests
or
an
identity
as
well
as
we'll
get
onto
shortly,
and
this
was
all
available
as
a
non-profit
public
good
service.
F
So
what
could
we
use
so
about
time
to
move
off?
Pgp
really
start
implementing
a
x509
and
benefiting
from
pkix,
okay
and
cas
could
be
provided
for
free,
pretty
much
using
the
let's
encrypt
model
and
we
issue
to
an
individual
or
an
identity.
An
entity
based
on
an
open
id
open
id
connect.
Okay,
so
cas
will
be
publish,
cas,
will
publish
issued
logs
to
a
t
log,
and
then
individuals
can
monitor
for
forged
misused
certs.
F
So
that's
where
I
have
a
terse
there,
because
I
will
go
into
that
a
bit
better
shortly,
so
I'll
kind
of
skip
over
this
one.
This
we
could
go
into
if
anybody's
interested.
We
could
dig
dive
this.
You
know
you
could
you
could
be
up
with
us
after
the
call,
I've
got
a
simplified
version
of
this
that
I'll
go
through
so
far
left
we've
got
our
developer.
F
F
We
have
our
signature
transparency
log
at
the
bottom,
which
is
recall
that
we
already
have
we've
got
the
certificate,
transparency
log
and
we're
going
to
use
the
existing
one.
That's
used
for
ct,
so
most
of
our
development
now
is
on
the
web
pki
and
the
open
id
dance
that
we
do
to
to
grant
a
scope
of
an
identity
and
so
forth.
So
what
would
happen?
Is
a
user
will
generate
a
private
keypair?
Okay,
these
will
be
ephemeral
short-lived.
F
They
don't
even
need
to
touch
the
disk
okay,
they
will
send
a
challenge:
okay,
encrypting
their
email
address,
and
they
will
then
be
presented
with
a
an
open
id
connect
grant,
okay,
which
they
will
then
go
through,
and
at
this
point
they
prove
that
they
are
the
well,
they
don't
prove
they're
the
owner,
but
they
prefer
they
prove.
They
have
access
of
an
identity
service
provider
account
we'll
get
on
to
account
compromise
a
little
bit
later.
Okay,
and
if
that
passes,
then
what
happens
is
a
signed.
Cert
is
submitted
from
the
web
pk.
F
I
saw
a
a
a
search
okay,
but
it
contains
the
email
address
which
is
not
from
the
user,
that's
from
the
identity
service
provider,
and
that
goes
into
the
certificate,
transparency
log,
and
we
pass
one
back
to
the
client
in
case.
They
want
to
keep
a
local
store,
okay
and
then
they
will
then
sign
their
artifact
and
the
signature.
Public
key
and
a
digest
will
go
into
the
signature,
transparency
log.
So
this
is
pretty
much
what
we
already
have
with
recall
that
we
went
through
before
okay.
F
Thing
about
this
is
the
keys
can
be
thrown
away,
there's
no
need
to
sort
of
manage
the
keys.
Everything
is
short-lived
certificates
and
those
can
be
dropped.
Okay
and
then
we
have
a
trust
room.
Okay,
so
now
we've
got
a
certificate
in
the
transparency
log,
the
maps
to
the
public
key
of
the
keys
that
are
also
used
to
sign
the
artifact,
which
is
also
in
the
transparency
lock.
So
we
got
a
map
from
the
sign-in
event
to
the
identity,
which
is
in
an
immutable,
append
only
transparency
log.
F
So
then
you
have
the
trust
route
of
blue
kinds.
Bigbang.Com
signed
a
public
key
sorry
signed
a
digest
using
this
particular
public
key
at
a
specific
time.
Okay,
and
now
just
to
go
back
to
the
account
compromise,
somebody
could
hack
my
account
okay,
but
others
can
start
to
monitor
for
instances
of
my
account
signing
something
that
they
don't
typically
sign.
So,
for
example,
if
somebody
started
signing
kubernetes
releases
that
isn't
a
release
engineer,
you
know
that
that
could
be
flagged
up.
F
Okay
and
if,
at
the
same
time
you
could
monitor
for
instances
of
your
email
appearing
in
a
certificate,
transparency
log,
you
need
a
secondary
account,
but
email
accounts
are
not
expensive.
Okay
and
then
you
can
almost
do
like
a
have.
F
I
been
post,
so
you
can
get
a
system
to
monitor
the
log
so
that
if
an
instance
of
your
email
is
used
as
part
of
the
oidc
dance
and
the
certificate
parry
back
and
forth
from
the
inclusion
into
the
transparency
logs,
you
then
know:
oh
crap,
somebody's
compromised,
my
account
and
they're
signing
things
as
me.
So
again,
you've
got
this
transparency,
so
we
haven't
solved
the
whole
universe.
F
We
can't
always
block
a
tax,
but
we
have
transparency
now,
whereas
at
the
moment
there
is
no
transparency,
there's
a
lack
of
people
signing
and
when
they
do
sign.
If
a
key
compromise
has
happened,
it's
very
difficult
to
know
about
that,
whereas
now
we
actually
got
the
means
to
to
look
for
that
behavior.
F
So
so
this
is
what
we're
working
on
at
the
moment
now.
Based
on
this,
you
can
then
start
to
sort
of
build
your
own
policy,
so
you
could
effectively
for
a
particular
release,
okay
of
an
artifact
or
a
container,
or
you
know
a
build
manifest
or
a
tab.
Or
what
have
you?
You
could
sort
of
almost
build
up
a
policy
where
I
expect
these
three
people
to
sign
off
on
this
particular
release
or
container,
and
I
expect
it
to
happen
between
a
certain
time-
perhaps
release
date.
F
Okay,
so
that's
a
very
simple
example,
and
you
can
then
utilize
the
transparency
logs
to
construct
that
that
sort
of
policy
and
have
cryptographic
guarantees
again
that
are
recorded
in
the
transparency
log.
So
what
we're
expecting
and
hoping
to
happen
is
once
we
have
this
infrastructure
in
place.
F
Others
can
then
start
to
utilize
our
own,
our
apis
to
construct
policy
engines,
okay
and
there
has
been
a
dan's
been
playing
around
with
opa
and
doing
some
interesting
stuff
there
as
well,
and
he's
done
some
really
good
work,
which
it's
really
worth
another
session
on
around
container
signing
that
utilizes
all
of
this
infrastructure
as
well.
The
oidc
connect
the
the
transparency
logs,
the
web,
pki
and
so
forth,
so
we're
under
the
lf.
It
happened
a
couple
of
days
ago,
okay,
but
we're
quite
a
small
group.
F
You
know
we
work
in
very
much
excuse
the
pun,
but
we
do
work
in
quite
an
agile
way.
We
like
sort
of
pathfinding
and
iterating
as
we
go
along
okay
and
we
plan
to
launch
this-
let's
encrypt
star,
so
we're
not
under
let's
encrypt,
but
we
speak
to
those
folks
quite
regularly.
They
give
us
good
feedback
based
on
their
experience,
running
the
let's
encrypt
program
and
they
were
really
supportive
of
what
we're
doing
you
know.
F
Josh
said
this
is
really
good.
This
is
really
good
to
see
somebody
tackling
this
space
and
and
they
they
believe
we're
doing
it
the
right
way.
So
so
it's
looking
good
so
far,
but
we
haven't
solved
anything,
there's
lots
of
things
to
solve
and
I'm
sure
lots
of
people
will
point
out
holes
and
we
need
to
scratch
our
heads
and
go
back
to
the
drawing
board.
You
know
fully
expecting
that,
and
this
is
our
our
domain
6stor.dev.
F
So
from
there
you
can
reach
our
repositories,
you
can
find
our
slack
channel
and
then,
in
the
slack
channel
you
can,
you
know,
reach
everybody,
and
if
you
want
to
stand
up
for
transparency
log
and
play
around
with
it,
we
can
support
you
doing
that.
If
you
want
to
help
contribute
that'd
be
wonderful,
you
know
we
can
show
you
more
or
less
how
to
bring
up
a
development
environment
and
so
forth,
and
currently
so
it's
everything's
open
source.
F
So
not
only
the
code
and
the
tooling,
we
want
to
make
the
operations
open
source
as
well,
so
we
have
ivan
who's
on
I'm
pretty
sure
I
saw
on
the
call
he's
working
on
a
kubernetes
operator,
okay
and
then
we
have
a
k8
deployment,
yaml
and
so
forth.
So
this
is,
we
have
this
running
in
gke
at
the
moment
and
so
the
actual
operational
aspects
as
much
as
we
can.
We
want
to
make
that
a
community
thing
as
well
we're
already
under
soft
launch.
F
As
I
said,
there
is
a
public
recall
that
people
can
play
around
with
okay
and
we're
also
under
active
development,
so
things
are
moving
pretty
fast
again,
just
to
iterate
the
point:
it's
free
to
use
non-profit
and
it's
a
public
good
service,
and
the
current
members
are
myself
from
red
hat,
there's
also
ivan
and
bob
on
the
call
we've
got
dan
lawrence
from
google
and
then
from
purdue
university.
F
We
have
santiago,
you
might
know
from
the
in
toto
project,
so
he's
got
involved
in
he's,
got
some
interns
that
are
working
on
a
monitor
and
past
couple
of
days.
It's
we've
had
a
lot
of
people,
it's
been
quite
an
influx
to
our
our
slack
workplace
as
well,
so
various
people
get
taken
an
interest
in
the
project
and
starting
to
learn
find
their
way
around,
and
so
I've
got
the
old
kind
of
you.
So
you
know
that
could
be
you.
You
could
be
interested
at
the
moment.
F
F
So
that
brings
me
to
the
end.
So
I
guess
you
might
have
some
questions
now.
I've
also
got
dan
bob
and
ivan
here,
so
my
voice
is
going
a
bit,
so
they
can
help
with
answering
as
well.
So
hopefully
that
all
made
sense,
but
I
just
need
to
work
out
how
to
stop
sharing
now.
F
G
So
I
guess
I'll
add
one
thing
that
might
be
really
relevant
to
this
group.
What
other
people
think
of
questions
I
am
also
responsible
for
building
and
releasing
the
distrolus
base
images
that
get
pulled
in
and
adjusted
somehow
into
the
kubernetes
upstream
releases,
and
so
a
lot
of
this
was
designed
just
to
give
me
more
confidence
in
those
releases
and
to
try
to
protect
them
and
prevent
bad
things
from
happening
to
those
images.
G
So
I
do
want
to
start
signing
those,
probably
not
the
first
thing.
We
start
testing
some
of
this
stuff
out
on
but
soon
and
then
provide
instructions
and
help
figure
out
how
people
that
do
take
those
distrol
space
images
can
verify
the
signatures.
A
Yeah
I'll
definitely
say
at
the
very
least.
Thank
you
so
much
for
coming
and.
A
F
So
I
guess
the
silence
might
be
it's
just
quite
a
lot
to
take
on
it's.
I
don't
know
how
new
everybody
is
to
transparency
logs,
but
we
really
had
to
graph
to
get
our
heads
around
them
at
first.
F
A
F
Slack
invite
so
so
let
me
just
quickly
get
that
up
and
I'll
put
that
into
chat
I'll
copy.
F
H
I
heard
the
question
luke
yeah
I've
seen
them
I've
been
following
this.
You
presented
this
in
the
cncf
security
as
well
or
record
thingy.
Yes,.
H
Yeah
yeah
yeah
and
I'm
looking
to
the
website
and
the
github:
do
you
recommend?
Is
there
any
place?
Where
imagine
let's
say
I'm
the
maintainer
of
a
github
project?
Is
there
open
source
and
is
there
any
place
in
your
website
or
github
that
you
say
these
are
the
step-by-step
things?
How
you
can
do
it
in
like
this,
how
you
sign
and
where
will
be
the
best
place,
to
find
the
examples.
F
Yeah,
so
the
stuff
that
we
have
at
the
moment
is
is
more
for
people
to
play
with
the
prototype
okay.
But
if
you
go
to
the
website
there
is
there's
a
a
link
to
the
different
repos
and
they
have
readme's
in,
but
I
know
for
the
container
signing
stuff
dan's
done.
Quite
a
lot
of
documentation
has
got
some
pretty
good
stuff
working
there.
F
H
Yeah,
I
was
just
curious
to
see
some
examples,
sure
sure
yeah.
G
Examples
kind
of
really
depend
on
what
you're
trying
to
sign
from
the
git
repo.
So
it's
a
container
image.
We've
got
some
really
good
examples.
I
just
pasted
one
in
chat
here
if
it's
an
arbitrary
binary,
it's
simple
but
you're
kind
of
on
your
own
for
distributing
the
signatures
and
stuff
like
that
with
the
containers
we
piggyback
on
the
container
registry
and
store
them
right
next
to
it.
So
signing
is
easy.
F
F
G
I'll
at
least
talk
through
the
little
example
I
just
posted.
Let
me
figure
out
how
to
share
my
screen.
I
need
to
be.
G
I'll
start
here,
this
is
the
example
I
just
published
like
right.
At
the
start
of
this
meeting,
I
made
a
little
self-contained
example
of
a
signed
container,
that's
built
and
released
with
github
actions
on
docker
hub.
So
this
has
everything
you
need
if
you
want
to
start
signing
containers,
this
doesn't
do
the
transparency,
log
or
pki
bits
yet,
but
I
might
explain
how
you
can
work
around
that
for
now.
G
So
there's
a
simple
docker
file
here.
It
just
takes
an
image
and
doesn't
really
do
anything
to
it,
and
this
gets
built
with
a
github
action.
Every
time
something
gets
merged
to
main
a
build
happens.
The
container
gets
built
and
pushed
to
dockerhub
here
and
it's
tagged
with
the
commit
it
was
built
at.
Obviously,
none
of
this
is
verifiable
and
stuff
today,
but
it's
still
a
general
best
practice
to
do
stuff.
This
way,
then,
as
the
release
gets
tagged,
we
do
another
build
and
tag
the
image
with
that
release.
G
So
that's
the
basic
ci
deployment
setup
and
then
we
add
in
signing.
So
we
check
in
a
simple
key
pair
here,
which
you
can
generate.
We've
got
little
animations
in
the
other
repo
how
to
generate
this
key
pair,
but
there's
a
public
key.
That's
what
it
looks
like
and
an
encrypted
private
key.
So
that's
here,
so
you
can
just
check
this
right
into
a
repo.
It's
fine!
You
need
a
passphrase!
You
set
up
to
use
this
and
during
the
build
we.
G
Install
the
cosign
tool,
which
does
container
signing
set
up,
docker
hub
credentials,
build
and
then
here's
the
command
that
does
all
of
the
magic.
This
signs
with
the
password
which
I've
set
up
as
a
github
action
secret
and
then
pushes
that
signature
up
to
docker
hub.
So
you
can
see
the
verification
what
that
looks
like
here.
G
I
have
one
release
tag
which
is
v0.1.1.
This
is
the
little
json
payload
that
gets
generated
for
a
container
image.
It's
got
the
sha
of
the
image
inside
of
it.
So
that's
how
you
know
it
is
signing
that
image
and
then
it's
got
these
optional
key
value
pairs
you
can
add
in
so
for
ci
builds.
It's
set
up
to
add
in
that
git
commit,
so
you
can
see
which
git
commit
the
container
is
built
at.
So
even
though
we
tag
it
with
that,
that
tag
is
mutable
and
anyone
can
change
it.
G
Nobody
can
change
this
because
that's
part
of
the
signed
payload
for
the
release
builds.
We
do
the
same
thing
except
we
also
add
in
the
git
tag,
so
you
can
tell
from
the
container
which
release
it
should
have
been.
What
commit
it
was
built
from
and
all
that
stuff,
the
cool
little
meta
part
here,
why
you
don't
have
to
worry
about
key
management
as
much
is
because
the
keys
are
just
checked
right
into
the
repo
with
this
workflow.
G
G
So
this
stuff
all
works,
pretty
well,
there's
some
experimental
parts
to
start
publishing
to
the
transparency,
log
and
get
certificates,
and
all
of
that
stuff
too.
But
if
you're
doing
something
simple
like
this,
then
you
can
give
this
a
try.
Now,
you'd
see
the
release.
G
Some
instructions
here
too,
on
how
that's
all
set
up,
but
it's
all
automated
with
just
a
couple:
github
actions,
three
least
job,
and
then
the
commits
the
code
for
all
this.
Is
it
six
door
cosine
and
there's
some
cool
animations
that
took
me
forever
to
figure
out
how
to
make
I'm
explaining
the
overall
flow.
How
you
get
the
key
pair
that
kind
of
stuff.
G
G
G
Yeah,
I
forgot
I'm
not
there's.
This
is
an
error
pushing
to
the
container
registry
itself.
Nothing
else
yet
forgot
to
log
back
in.
G
Cool,
so
I
this
is
the
sign,
command,
I'll
pause
and
take
a
break.
I
didn't
pass
in
any
keys
here
because
there
are
no
keys.
I
call
this
keyless
signing
it's
not
really
keyless,
but
if
the
serverless
people
get
to
call
that
server
list,
we
get
to
call
this
keyless.
G
What
happens?
Is
we
generate
an
ephemeral
key
pair
in
memory,
so
the
keys
never
touch
disk.
They
never
leave
the
machine
they're
only
in
existence.
For
you
know
the
time
they're
in
memory,
we
use
those
to
get
a
signed
certificate
from
our
root
ca
and
that's
what's
happening
now.
So
to
get
that
signed
certificate,
we
send
a
request
up.
G
G
Before
take
this
no
keys
again,
no
public
keys
anywhere.
These
get
looked
up
from
the
transparency
log,
so
we
don't
have
transparency.
Log
checking
turned
on
right
now,
so
we
didn't
check
the
expiration
time,
but
we
did
find
the
certificate.
It
was
tied
to
my
email
address
here
and
we
can
see
that
it
signs
the
container
image
itself.
G
G
A
A
Yeah
yeah:
this
is
cool
thanks
a
lot
with
the
last
bit
that
we
have
here.
Does
anyone
else
have
anything
that
they
would
love
to
bring
up
to
the
group
as
assembled.