►
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
A
So
thank
you
much
everyone
for
joining
in,
and
this
is
a
house
group
keeping
thing.
This
is
an
official
live
stream
of
the
cncf
and,
as
such,
it's
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
all
of
your
fellow
participants
as
well
as
presenters,
so
with
that,
let's
get
us
started
and
I'll
hand
it
over
to
jim
to
to
kick
us
off
today.
B
B
So
this
is,
you
know,
for
me,
just
kind
of
has
a
caveat
and
a
somewhat
of
a
disclaimer
like
so
obviously,
as
you
see
you
know,
probably
in
the
last
six
to
12
months,
there's
been
a
lot
of
headlines,
a
lot
of
news
on
supply,
chain,
security
and
and
topics
related
to
that.
So
this
is
something
that
of
course,
based
on
you
know,
customer
interests,
others.
B
B
A
B
So,
of
course
you
know
what
what's
also
as
part
of
that
what
happens
is
attackers
are
looking
for
the
easy
way
in
right
and
one
of
the
weak
spots.
Something
that
has
been
ignored,
unfortunately,
is
this
you
know
is
how
we
build
deliver,
deploy
software
and,
if
you
think
about
it
today,
you
know
if
you're,
building
any
any
commercial
or
open
source
software,
we
don't
think
twice
about
running
commands
like
you
know
whether
it's
pulling
a
helm
chart
or
updating
adding
a
dependency.
B
I
mean
we
might
find
something
that
looks
interesting.
You
know
on
github
or
some
other
version
control
system
and
we
add
it
to
our
dependencies
and
we
pull
that
in
right.
But
how
do
we
know
who
actually
built
that?
How
do
we
know
what
that
depends
on
things
like
that?
Are
often
you
know
just
an
afterthought,
because
there's
so
much
so
much
data,
I
mean
if
you
try
installing
any
package
on
any
one
of
our
systems.
B
B
There's,
of
course,
even
even
you
know,
at
the
government
levels
etc.
There's
something
which
is
often
talked
about
now
is
there's
been
an
executive
mandate
in
the
united
states
to
improve
this
aspect
of
our
software
development
practices
and
and
delivery
best
practices
right.
So
yeah
I
mean
I
think
there
are.
These
problems
can
be
mitigated
and
will
be
mitigated.
So
it's
a
matter
of
just
spreading
the
awareness,
the
knowledge
and
figuring
out
what
we
can
do
right
away.
B
Right
yeah,
so
a
few
things
I
would
like
to
introduce
right
and
again
this
this
topic
may
seem
daunting
as
you
first
look
at
it,
but
it
is,
you
know
it
is
approachable
and
there's
a
lot
of
good
work
and
you
know
things
emerging.
So
the
first
thing
we'll
talk
about
is
something
in
a
framework
called
salsa
or
supply
chain
levels
for
software,
architects
are
artifacts
and
that's
you
know
a
standard
which
was
originally
came
out
of
google
and
now
is
being
adopted.
B
You
know
fairly
widely
in
terms
of
a
reference
in
a
model
for
securing
different
aspects
of
your
supply
chain,
so
there's
different
levels
of
security
that
can
be
attained.
There's
you
know
various
audits
and
checks
in
place
and
various
controls
that
are,
you
know,
laid
out
so
we'll
go
through
some
of
that
I'll
talk
about
you
know.
Another
project
called
six
store,
which
is
in
fact
has
multiple
sub
projects,
cosign
being
the
one
that
we'll
look
at
live,
but
there's
also,
you
know.
B
Other
projects
which
are
part
of
six
store
and
six
store
is
a
linux
foundation.
Project.
There's
you
know
it
has.
You
know
sub
projects,
so
I
mentioned
cosign,
which
is
used
for
signing,
as
the
name
might
imply,
but
there's
also
recore,
which
is
a
transparency
log
which
becomes
an
important
part
of
the
supply
chain
security
puzzle
and
then
there's
you
know
full
co,
which
is
an
easy
way
to
manage
web-based
you
know
pki
and
web-based
identities.
B
B
So
we'll
briefly
talk
about
those
and
then
I'll,
you
know
to
switch
to
kiverno,
which
is
and
policy
engine
for
kubernetes
we'll
talk
about
where
cabernet
fits
in
into
this,
and
what
admission
controllers
can
do
in
this
whole
supply
chain
security
puzzle-
and
you
know
what
we'll
use
for
a
demo
is
I'll
start
with
the
repo.
This
is
a
just
a
simple.
B
B
Yep,
so
let's,
let's
go
to
salsa
first
right
and
great
great
acronym,
of
course,
and
what
it
stands
for
is
supply
chain
levels
for
software
architects,
as
it
says,
and
it's
also
you
know
it
has
four
different
levels
which
they
identify.
They
have
a
nice
picture
over
here
with
some
of
the
and
a
threat
model
for
different
things
that
could
potentially
go
wrong.
So
here
what
they're
showing
is,
if
you're
a
developer?
B
Obviously
you're
kind
of
you
know,
starting
with
source
code
and
then
you're
building
your
code,
and
once
you
build
your
code,
it
pulls
in
a
lot
of
dependencies.
Typically,
and
then
you,
you
know
once
you
build
your
software,
your
packages,
those
get
you
know,
pushed
to
one
or
more
in
a
deployment
servers
or
services
which
are
then
consumed
by
your
customers
right
or
your
end,
consumers.
B
So
there's
several
things
that
could
go
wrong,
which
they've
identified
as
various
threats
over
here
and
then
they
have.
You
know
different
guidelines
in
terms
of
what
you
can
do
to
mitigate
those
threats
right.
So
if
you
go
down
and
click
on
this
learn
more,
you
know,
salsa
defines
four
different
levels
of
you,
know,
trust
and
security,
and
the
first
is,
you
know
basically
you're
you're,
starting
with
something
it's
something
basic,
which
you
know
you're.
B
B
What
is
you
know
like
something
something
which
takes
takes
a
bit
more
effort
to
attain,
but
this
is
where
every
step
again
becomes
auditable
and
your
build
environment
itself
is
in
a
fully
automated
fashion.
Also,
but
at
the
same
time
you
have
it
has
a
verifiable
identity
which
can
be
then
again,
you
know
proven
at
the
time
of
consumption
right.
So
somebody
can
look
at
this
and
say
or
look
at
the
right
or
audit
the
right,
artifacts
and
verify
who
built
this
package
who
reviewed
it?
B
How
was
it
you
know
what
kind
of
dependencies
did
it
have
and
there's
so
you
know
there's
another
acronym
called
s
bomb
or
software
build
of
materials
which
is
also
there's.
You
know,
activity
in
terms
of
standardizing
those
which
becomes
important
to
have
that
as
an
artifact
be
able
to
put
that
into
some
trusted.
B
You
know
fully
fully
isolated,
well
protected,
as
well
as
fully
reproducible
right
and
there
are-
and
I'm
not
going
to
go
through
each
of
these
details,
of
course,
but
if
you
go
to
the
salsa
website,
all
of
this
is
fairly
well
defined.
In
fact,
just
this
morning
I
saw
there
was
a
good
blog
post
from
google.
B
You
know
from
the
security
team
at
google,
where
they
talked
about
attaining
different
levels
as
well.
As
you
know,
what
again
practical
things
that
can
be
done
to
start
mapping
to
each
of
these
levels,
but
it's
a
very
detailed
and
well
laid
out
framework
which
talks
about
again.
These,
like
different
levels
of
security
in
your
ci
cd,
build
process
as
well.
As
you
know,
discussing
what
are
some
of
the
best
practices
and
things
you
can
do
along
the
way
right.
So.
B
Right,
yes,
so
today
most
would
be
at
you
know,
level
one.
So
most
open
source
projects
will
have
some
automated
way
of
doing
bills.
They
will
have
you
know
the
build
logs
available
to
some
level,
so
there
is
most
would
be
at
level
one
or
two
and
very
I
would
say
the
majority
would,
you
know,
fall
into
the
level
one
where
there's
some
scripted
build
processes.
B
There
is
some
provenance
available,
but
even
this
is
not.
You
know,
overall,
as
an
industry,
we're
not
in
good
shape
here
right.
So
this
needs
to
be
improved
and
we'll
talk
about.
You
know
just
think
about
today.
If
you
pull
a
container
image
into
your
cluster
or
a
helm,
chart
right
to
it,
it's
such
a
high
level
of
abstraction,
because
as
a
user,
you
have
no
idea.
B
You
know,
okay,
well,
that
hum
chart
may
have
thousands
of
lines
of
yamls
and
now
there's
tools
like
kiverno
or
gatekeeper,
oppa
and
others
that
can
scan
and
verify,
and
you
know,
audit
those
configurations
before
admission,
but
you
know
that
hum
chart
also
has
images.
How
do
you
know
those
images
were
not
tampered
with?
How
do
you
know
those
images
again?
Where
is
the
provenance
just
show
how
they
were
built,
what
they
referenced?
So
there's
a
lot
of
work
that
needs
to
be
done
even
to
get
to
that
level.
B
One
right
so,
but
it's
possible
and
then
level
two
requires
more.
You
know
you
have
to
use
build
services
where
the
provenance
is
authenticated
and
six
store.
You
know
the
tools,
we'll
talk
about
start
getting
you
towards
that
level
too,
and
then
there's
of
course,
other
processes
which
have
to
be
improved
for
level
three
and
four.
A
B
All
right,
so
hopefully
that
gives
you
know
very
quick
but
brief
overview
of
salsa
and
certainly
would
recommend
folks
go
through
this
in
more
detail,
read
and
understand,
and
there's
again
some
great
work,
some
really
good.
You
know
posts
and
things
coming
about
which
are
you
know,
helping,
explain
this
and
break
this
down
into
more
practical
and
and
other
steps
which
can
be
implemented
right.
B
So,
let's
switch
then
to
sig
store,
which
is
a
really
exciting
project
if
you're
interested
you
know,
there's
of
course
there's
a
lot
of
details
on
the
community
and
the
community
meeting.
So
this
project
you
know
has-
and
it's
receiving,
as
you
can
see
over
here-
there's
lots
of
good.
You
know
things
being
said
about
six
store
and
what
it
can
do
for
supply
chain
security
itself
right.
It
started
with
collaboration
from
teams
so
luke
at
red
hat
dan.
B
At
you
know,
google
are
some
of
the
main
folks
behind
it.
You
know-
and
I
will
go
through
some
of
this
in
more
detail,
but
just
to
kind
of
show
what
the
project
does.
There's
there's
three
things
that
they,
you
know
three
sub-projects
in
six
store
which
are
important
to
know
about.
The
first
is
you
know,
signing
and
making
signing
easier
itself
and
cosign
is
the
primary
tool.
B
It
initially
started
out
as
being
a
signing
tool
for
container
images
and
oci
registries,
but
has
you
know
evolved
into
being
able
to
sign
almost
anything
right
and
it's
whether
it's
you
know,
you
know
blobs
whether
it's
hum
charts,
there's
work
going
on.
You
know
to
integrate
cosine
and
helm,
and
you
know
standardize
some
of
that
and
you
know
for
the
most
it
will.
You
know
these
signatures
again.
Cosine
gives
a
lot
of
flexibility
in
where
you
can
how
you
manage
these
signatures.
B
It
doesn't,
you
know
you
know,
sort
of
pin
the
signature
to
a
particular
location,
so
you
can
even
move.
You
can
have
your
signatures
in
a
different
oci
registry
than
where
your
images
are.
You
can
you
know
also
do
things
like
you
can
have
your
other
metadata
and
we'll
talk
about
the
importance
of
metadata
and
how
you
can
you
know,
build
attestations
out
of
those
and
also
manage
those
with
cosine
right.
B
So
that's
the
first
tool
to
kind
of
be
aware
of
and-
and
you
know
play
around
with
it's
very
easy
to
get
started
so
each
one
of
these,
of
course
like.
If
you
go
to
just
the
cosine,
get
repo
you
know
it
has
they
have
their
own
kind
of
getting
started
pages?
How
to
kind
of
install
and
and
use
this
so
and
it's
cosign
is
super
simple
to
you
know,
get
started
with
manage.
B
You
know
public
private,
key
pairs,
sign
images
and
try
out
right
so
once
once
the
signing
part
of
this
is
is
taken
care
of
there's
also,
you
know.
One
of
the
things
I
mentioned
and
maybe
should
have
pointed
out
when
we
were
discussing
salsa
is
there's,
there's
a
need
for
more.
You
know,
metadata
and
there's
other
projects,
also
existing
projects
like
intel,
which
is
another
linux
foundation,
project
which
act
as
metadata
repositories
right.
B
But
you
know
signing
what's
important
next
to
do
is
signing
this
metadata
and
creating
something
that's
known
as
an
attestation
out
of
it
right.
So
the
intel
project
has
a
format
and
there's
a
process
and
they're.
You
know
kind
of
going
through
the
work
of
standardizing
this
format
of
having
attestations.
B
A
B
Yes,
so
that's
a
good
question:
there
is
some
activity
where
you
know
there
are
just
like
with
pci
and
other
compliance
standards.
The
you
know,
auditors,
and
you
know
folks,
who
are
in
the
business
of
providing
these
compliance.
Certifications
are
also
adopting
salsa
as
a
framework
which
will
be
you
know,
auditors
will
be
able
to
inspect
that
just
like
with
pci.
For
example,
an
auditor
would
check
if
you're,
using
proper,
firewalling
and
you're
using
ssl,
and
things
like
that.
A
B
B
Absolutely
yeah,
so
you
know
the
what
I
was
mentioning
with
the
metadata
and
what
you
can
do
and
we'll
take
a
quick
look
at
an
example.
So
record
you
know,
becomes
this
transparency
log
where
it's
capturing
and
save
some
of
this
metadata
for
auditing
later,
and
it's
also
used
in
conjunction
with
you
know
what
I
mentioned
of
trying
to
make
signing
and
verification
a
little
bit
easier
across
organizations
and
teams
by
another
project
called
fulcio,
which
is
a
web-based
you
know,
pki,
which
allows
you
know
using
oidc
to
generate.
B
Sometimes
this
is
also
referred
to
as
keyless,
but
what's
happening
underneath
the
covers
is
full.
Co.
Has
you
know,
root
ca,
a
root
certificate
and
you
know
it
is
using
oidc
to
verify
the
identity
of
the
person
doing
you
know
providing
the
signatures
and
then
looking
you
know,
based
on
that,
it
will
generate
temporary
keys,
sign
and
record
that
in
the
transparency
log
in
recore,
which
can
be
then
later
audited
right.
B
So
it's
a
very,
very
smart
way
of
you
know,
making
managing
keys
a
little
bit
easier
and
making
sure
that
now
you
can,
you
know,
as
you're
scaling
the
usage
of
these
tools,
you
don't
you
can
rely
on
well-established
standards
like
oidc
to
be
able
to.
You
know
to
be
able
to
assign
I
you
know,
verify
identities,
generate
temporary
keys,
sign
and
then
also
be
able
to
kind
of
capture
this
in
in
a
transparency
log
itself
right.
B
B
So
that
was
the
second
topic
I
wanted
to
introduce
right.
So
we
talked
about
salsa,
we
talked
about
six
door
and
finally,
you
know
now
you
know,
let's
kind
of
bring
it
back
to
what
does
this
mean
for
kubernetes?
And
what
can
you
do
today?
So
I'm
gonna
briefly
meant
you
know
just
introduce
caverno
for
those
folks
who
may
not
be
aware
of
it
or
what
it
does
so.
Kivarno
is
a
policy
engine.
B
It's
an
cncf
project
which
is
a
policy
engine
for
kubernetes,
so
it's
similar
in
function
to
oops
shut
that
so
it's
similar
in
function
to
what
you
could
do.
You
know
with
oppa
gatekeeper,
except
it
doesn't
require
writing
and
managing
policies
in
regard
it
uses.
You
know,
kubernetes
custom
resources
for
policies
itself
and
it
will
you
know,
policy
results,
etc,
are
also
available
as
kubernetes
resources.
B
So,
just
briefly,
very
briefly,
looking
at
how
kinvernor
works,
it
acts
as
a
web
book-based
mutating
and
validating
admission
controller.
So
what
that
means
is
every
api
request
in
kubernetes
can
be
passed
to
kiverno
and
based
on
your
configured
set
of
policies.
Kiberno
will
then
either
allow
deny,
or
it
can
also
mutate.
B
B
The
use
of
cavern,
of
course,
is
for
enforcing
pod
security
or
enforcing
workload
security,
making
sure
that
your
namespaces
are
configured
correctly
just
managing
configuration
security
in
general,
even
simple
things
like,
for
example,
if
you
want
to
make
sure
this
example
is
saying
that
every
pod
and
kivarna
by
the
way,
automatically
applies
policies
which
are
you
know,
written
for
pods
it
can.
You
know,
map
those
two
pod
controllers,
so
every
pod,
you
know
independently
of
how
it's
created
here.
B
B
So,
let's
talk
about,
you
know
what
kiverno
can
do
you
know
and
how
it
works
with
you
know
cosine
as
well.
As
you
know,
some
of
the
other
tools
we
talked
about
right.
So
what
I'm
going
to
do,
and
here
we'll
I'm
going
to
go
back
to
my
image,
which
is
just
you
know
this
positive
there's
a
single
version.
It's
latest
and
you
know
in
my
you
know
as
we
can
and
let
me
pull
up
my
shell.
So
if
I
look
over
here,
you
know
I
have
basically
a
cluster
running
locally.
B
B
We
have
that
part
running
and
there's
no
checks.
Nothing
happening
right
now,
right
so
basically
we're
just
allowing
everything
into
our
cluster.
So
let's
you
know
delete
that
pod.
So
I
think
I
ran
it
in
default.
So
we'll
just
do
you
know
we'll
delete
that
one
part
and
we'll
go
back
right.
So
at
this
point,
what
can
I
do
to
start
signing
my
image?
So
the
first
thing
I
would
do
is
here
you
know.
B
I
have
a
couple
of
different
key
pairs
and
I'll
show
how
I'm
using
that
in
signing,
because
you
could,
you
might
have
you
know,
multiple
signatures
associated
to
a
single
image
and
you
can
then
have
kilo
policies
which
we'll
you
know
quickly,
look
at
which
you
can
then
use
to
verify
or
check
those.
So
I've
already
generated
a
key
pair
and
that's
you
know
if
I
look
over
here,
that's
in
cosine
dot,
key
cosine,
dot
pubs.
B
This
is
my
public
private
key
and
I
have
some
other
yamls
which
we'll
come
back
and
look
at
later.
But
what
I
want
to
do
now
is,
I
want
to
assign
my
image
and
I
want
to
see
what
cosine
does
when
I
sign
that
image
itself
right.
So
I'm
going
to
you
know
just
use
cosine
sine,
and
in
this
case
you
know
we're
going
to
use.
B
I
don't
want
to
sign
it
first
with
the
so
I
have
another
public
private
key
pair
in
in
under
keys,
but
I'm
just
going
to
first
sign
it
with
you
know
the
the
key
in
this
folder
itself.
So
basically
it
took
you
know
my
password
it.
You
know
it
said:
okay,
it
signed
something
and
that
that's
all
cosine
is
telling
me
right
now
right.
So
let's
go
back
to
the
git
repo
and
see
what
happened
over
there.
So
if
I
go
and
refresh
the
screen,
I
see
something
else
showed
up
right.
B
So
previously
that
was
just
latest,
but
now
it's
showing
me
that
there's
a
signature
which
ends
with
a
dot
sig-
and
it's
got
this
big-
you
know
sort
of
stream,
which
is
this
is
actually
the
digest,
and
it's
telling
me
that
look,
there's
a
signature
which
got
attached
into
this
now.
I
can
verify
this
signature
with.
You
know,
basically,
if
I
want
with
a
cosine
itself,
but
what
I
want
to
show
is:
how
do
you
verify
this
with
the
kimono
policy
right?
B
So
I'm
going
to
use
this
policy
here,
which
you
know
is
checking
and
right
now
this
policy
is
checking
for
multiple
keys.
So
basically,
what
this
policy
is
doing
is
it's.
You
know
looking
at
and
if
we
kind
of
start
from
the
top
it's
the
policy
name
is
check
image.
It's
saying
that
if
there's
a
failure
it
wants
to
enforce
so
kiberno
supports
two
different
modes:
it
can
either
audit.
B
So
it
will,
just
you
know,
create
a
policy
report,
but
it
won't
enforce
that
or
it
can
enforce
the
configuration
in
which
case
you
have
you
know,
it'll
block
that
container
from
getting
deployed
it.
Also
it's
saying
that
don't
run
this
in
the
background.
I
just
want
to
run
this
on
the
web
book.
It's
configuring
the
web
up
timeout
as
30
seconds,
because
we're
going
in
calling
you
know
we
will
check
the
signature
from
the
registry.
B
It's
saying
that
if
this
policy
web
book
fails,
it's
going
to
fail
closed
right,
so
it's
not
going
to
allow
images
or
things
to
go
by
if
this
webhook
doesn't
respond.
For
any
reason,
and
then
here
it's
saying
if
you
see
a
pod,
make
sure
that
every
pod
is
signed
by
two
keys,
but
I
don't
want
to
we
don't
we
just
signed
it
with
one
key.
B
B
You
know,
let's
say,
group
call
apply
and
from
here
I
have
the
policy
which
is
check
images.yaml
and
I'm
going
to.
You
know
just
create
that
policy
and
if
I
do
get
cpal
I'll
see
it's
here,
if
I
do
minuso
yamo,
it
should
show
me
that
policy
by
the
way,
kiverno
again
like
automatically
by
default,
it
will
create.
You
know
that
policy
for
the
standard,
pod
controllers-
you
can
manage
this.
B
B
You
know
this
positive
and
we
have
this
policy
in
place
which
is
saying
that
don't
allow
this
to
run
so
and
it's
saying
as
expected,
it
checked
for
the
signature
and
said
it's
not
found.
So,
let's
go
ahead
and
sign
it
again,
using
the
cosine
sine
command,
we'll
use
the
same
key
and
we'll
push
the
signature
back
into
our
repo,
and
once
that's
done,
if
I
run
pause,
two
I'm
expecting
at
this
point
that
you
know
the
part
gets
created
which
it
did,
and
you
know
it
should
automatically.
B
Also
one
other
interesting
thing
to
point
out
is
once
it
very.
You
know,
once
the
signature
is
verified,
what
kiverno
will
do
is
it
will
also
you
know
in
the
pod
yaml
it
will
replace
the
actual
tag
with
the
digest
and
what
this
does
is.
So,
if
you
just
grab
for
image
just
to
show
you
what
I'm
talking
about
when
I
ran
the
command,
I
just
gave
it
the
inner
tag
and
by
default,
of
course,
it
goes
into
latest.
B
But
here,
as
you
see
what
kiberno
did
is
once
it
verified
the
signature,
it
replaced
that
tag
which
is
mutable
with
the
immutable
digest,
and
that
also
you
know
kind
of
that
is
important,
because
otherwise
you
have
a
window
in
which
somebody
could.
Potentially,
you
know
you
know
if
they're,
if
there's
a
sophisticated
and
enough
attacker,
they
could
potentially
either
replace
the
digest
or
you
know,
if
you
just
pull
by
tag
your
image.
A
B
There
is
an
option
you
can
specify
a
different
registry
if
you
want
to
manage
your
signatures
in
a
central
registry
or
in
a
any
any
other
repo
you
can,
but
by
default.
Cosine
will
assume
that
it's
you
know
going
to
be
pushed
into
that
same
registry
there's
also
an
option
in
cosine,
and
this
again
speaks
to
its
flexibility
to
create
a
local
signature
right.
If
you
don't
want
to
push
it
anywhere,
but
by
default
it
will
push
it
back
into
that
same
oci
registry,
where
the
images.
A
B
B
A
B
A
A
B
Right,
yeah
yeah.
No,
that's
a
good
question
right.
So,
if
you
are
using
so
you're
today,
what
I'm
gonna
demo
is
just
using
public
private
keys
so
and
it
does
become
difficult
to
manage
keys
at
scale.
So
this
is
what
full
co
and
recore
are
solving
by
in
you
know,
by
removing
by
this
keyless
option
of
signing,
which
is
very
cool
because
you
can
just
with
your
oidc
identity.
B
So
that
is,
you
know,
those
are,
you
know,
marked
as
experimental
features,
but
soon
to
be
production
ready,
and
we
will.
You
know
we
can
do
more
demos
and
we'll
have
more
coverage
of
that,
and
kiberno
will,
of
course,
also
support
this
as
soon
as
it's
you
know,
ready
to
be
available
and
that
will
reduce
the
burden
of
managing
keys,
of
course,
in
in
a
larger
organization.
B
A
B
Yeah,
so
so
far,
just
to
kind
of
quickly
recap
what
we
have
done
is
we
saw
that
you
know
we
were
able
to
basically
apply.
You
know
policy.
We
signed
an
image.
We
verified
that
without
the
you
know,
without
the
signature,
the
image
was
blocked
and
then,
with
the
signature
now
you
know
we
are
able
to
run
that
image
right.
B
The
first
rule
here
is
saying
by
star,
so
it's
saying
for
every
image
must
be
signed
with
the
first
key,
but
then
it's
saying
that
only
images
in
a
particular
repo
are
signed
with
the
next
key
right.
So
you
could,
if
you're
kind
of
thinking
of
an
organizational
structure,
you
could
manage
your
keys
in
that
manner,
where
you
have
a
central
key,
which
requires
to
say.
Okay,
these
all
of
these
images
are
coming
out
from
my
orgs
and
then
you
could
have
also
a
group
specific
key
and
you
can
with
kiberno
policies.
B
B
So
I'm
going
to
just
go
ahead
and
apply
that
and
then,
if
we
now
try
to
let's
check
and
see
if
we
still
have
those,
I
think
the
part
was
running
so
we'll
delete
it
and
we'll
now
try
and
run
this
again
right
and
what
I'm
expecting
to
see
is
this
time.
It
says
that
one
of
the
images
is,
you
know
one
of
the
signatures.
Is
there
but
the
next
one.
It
says
you
know
it
failed
and
it's
saying
look
it
can't.
B
But
if
we
try
to
run
that
image,
what
we
should
see
is
at
this
point
we
can,
you
know,
run
the
image
because
both
signatures
now
are
present
in
our
you
know,
pod
itself
right
so
so
far,
so
good
we've,
you
know,
we've
been
able
to
now
sign
and
verify
the
signatures.
We've
seen
that
we
can
do
multiple
signatures,
but
that's
you
know,
that's
certainly
a
great
starting
point
and
it's
something
that
everybody
as
you
can
see.
It's
not
difficult
to
do.
B
It
should
be
something
that
everyone
looks
at
you
know
adopting,
but
the
next
step
would
be.
How
do
we
get
to
those
upper
levels?
The
next
level
of
the
salsa
framework
right
and
that's
where
it
comes
back
to
you
know?
How
do
you
now
start
producing
the
right
metadata
in
your
ci
cd
pipeline
and
you
know
start
verifying
that
metadata
as
part
of
your
policy
set
itself
right?
B
So
your
you
know
one
one,
quick
thing:
let
me
just
quickly
show
is,
if
you
let
me
see
if
I
can
find
this,
if
you
go
to
in
total
attestations,
this
is
the
definition
I
was
kind
of
mentioning.
This
is
there's
a
standard
work
in
progress
so
and
it
references
either
a
salsa
provenance
type
or
other
types
of
attestations.
You
could
attach
right
so
here
this
is
the
structure
of
a
you
know
of
a
in
total
attestation.
B
B
That's
you
know
I
should
mention
so
techton
chains
is
doing
a
great
job
at
producing
a
lot
of
these
attestations
and
making
sure
that
these
are
recorded
and
can
be
pushed
and
signed
and
pushed
into
either
an
oci
registry
or
into
a
transparency
log
which
can
then
be
audited
right.
So
here
like
this,
is
a
more
complex
example
of
an
attestation,
some
simpler
examples
and
we'll
you
know,
use
something
actually
we'll
use.
B
B
So
if
I
go
back
to
our
registry
now-
and
if
we
see
you
know,
if
you
look
at
that
positive
image,
I
see
there's
a
dot
att
file,
which
is
also
showed
up
right
and
what
that
is
is
it
contains
now
the
signed
attestation
and
you
can
have
several
of
these
right,
so
we
just
looked
at
a
simple
example
which
is
verifying.
You
know
that
that
image
has
this
particular
attestation.
B
So
then
what
do
you
do
with
this
or
how
do
you?
You
know?
How
do
you
kind
of
verify
this
at
admission
controls?
So,
let's
look
at
you
know
this
policy
which
we
will
apply
next.
So
if
I
have
this,
given
a
policy
which
is
saying
check
for
a
code
review,
the
first
thing
it's
doing,
it's
got
a
similar
verify
images
in
a
block
which
is
checking,
and
it's
saying.
Okay,
if
my
saw
my
image
is
coming
from.
You
know
this
particular
repo
and
it
has
this
public
key.
B
B
Of
course,
if
you're
putting
this
in
production,
you
might
want
to
put
this
in
a
config
map
or
make
this
a
little
bit
more
declarative
where
it
can
be
expanded,
but
the
basics
of
the
policy
now
are
we
want
to
check
for
this
particular
attestation
when
we
are,
you
know
running
this
this
image.
So
let's
apply
that
policy
and
see
what
happens
right.
It
should
run
because
we've
already
signed
and
pushed
that
attestation
and
just
to
prove
that
if
we
you
know,
maybe
we
can
change
that
attestation.
B
If
you
want
to
do
something
else
and
make
sure
that
it
fails
right,
so
we'll
first
go
ahead
and
delete
the
part
we
were
running
before
we'll
apply
this
policy,
so
we
want
to
do
its
check.
Review
is
the
policy
so
now
this
policy
is
created.
If
I
do
my
just
to
verify
that
the
policy
is
created
and
active,
I'm
just
going
to
do
get
cluster
policies.
It
shows
that
they're
both
set
to
enforce
and
they're
both
ready
right.
B
So
now
what
should
happen
is
we
are
you
know
we
not
only
did
we
verify
the
signature,
but
we
verified
that
attestation
and
just
to
prove
that
this
is
actually
you
know.
This
did
something,
let's,
let's
kind
of
change
something,
so
let's
go
ahead
and
delete
the
pod
first
and
what
I'll
do
is
I'll
edit.
This
policy,
you
know
just
in
my
cluster
itself
right.
So
what
we
can
do
here
is,
if
I
edit
this
policy
and
right
now
I
have
you
know.
B
B
So
this
is
a
simple
but
yet
powerful
example
of
how
flexible
you
know
these.
These
tools
can
be
and
the
power
of
cosine
and
using
kiberno
together
how
you
can
now
start.
You
know
not
just
creating
this
metadata
again,
tecton
or
github
actions
can
be
used
to
create
some
of
this
metadata,
but
then
you
can
sign
this
metadata,
push
it
into
your
oci
registries
and
start
verifying.
This
add
admission.
Controls
to
you
know
start
achieving
some
of
the
requirements
that
we
looked
at
in
the
salsa
framework.
B
A
Yeah
for
sure
really
great
stuff.
Thank
you.
So
much
there's
been
a
few
comments
and
a
few
questions
as
well,
so
we
can
get
them
now
so
so
there
was
a
kind
of
a
comment
and
two
questions
from
seeker
tech
he
starts
or
he
or
she
or
they
start
thanks
jim
for
taking
the
time
question
one.
What
do
you
recommend
as
a
guideline
of
private
registry
ea
the
standard
set
of
cubano
policies
that
we
can
apply,
be
default
based
on
security
exposure
and
then
question
two?
B
Yes,
a
great
great
set
of
questions
right,
so
you
know
so
in
terms
of
private
registry
there's
several
good
options.
You
know,
of
course,
out
there
and
there's
both
commercial
as
well
as
open
source.
So
I
I
don't.
You
know,
I'm
not
going
to
kind
of
name
any
particular
ones,
but
most
oci
and
cosign,
of
course,
has
a
list
also
of
registries
that
they
have
tested
with
verified
with.
B
So
if
you
go
to
kevon,
io
click
on
policies,
there's
about
80
or
so
best
practice-
and
you
know
other
policies,
of
course,
the
basic
to
start
with,
if
you're,
not
running,
psps
or
some
other
way
of
managing
pod
security,
definitely
start
with
the
spot.
Security
set
right
which
implements
the
pod
security
standards
and
gives
you
you
know
some
flexible
ways
of
managing
pod
security.
But
then
there's
several
in
best
practices.
You
should
look
at
and
see
what
makes
sense
to
deploy
and
manage.
B
A
Had
a
question
about
their
recordings
and
they
are
available,
as
pointed
in
the
chat
already,
which
will
help
them
on
their
kivernor
presentation,
october,
26th,
so
perfect,
timing
for
this
session.
I
think
and-
and
thank
you
so
much
for
joining
for
talking
through
these
things,
and
then
there
was
now
a
comment
from
duke
again:
mutation
policies
are
pretty
impressive
and
he
or
she
or
they
would
love
to
hear
more
about
them
in
the
future.
B
A
Great,
so
we
are
getting
to
the
end
of
our
time.
I
have
one
question
left
and
then,
if
there's
anything
else,
you
can
the
audience
can
ask
super
quickly,
but
after
we
have
to
start
wrapping
up
so
since
there
are
so
many
projects
and
tools.
Thank
you
so
much
for
the
really
great
overview
of
the
space,
but
it
can
get
a
bit
confusing
to
to
people
who
are
getting
started.
So
what
do
you
recommend
to
the
get
started
like
what
are
the
the
things
that
everyone
should
be
doing?
Yeah
right.
B
Yeah,
no,
it
is,
and
certainly
like
as
you're
approaching
this
space.
It
looks
a
bit
you
know
overwhelming
there's
so
many
new
names,
new
projects,
new
things
to
learn
about,
but
just
breaking
it
down
into
and
look
if
you
go
back
to
the
salsa
framework.
Look
at
that
picture
which
shows
and
every
for
any
software
you
have
to,
of
course
build
it
in
your
ci
cd
pipeline
and
then
you
have
to
you
know:
okay
you're
using
oci
registries
already,
and
then
you
want
to
verify
some
of
this
right.
So
there
are
for
that.
B
Cosine
is
certainly
emerging
as
one
of
the
key
projects
that
you
will
want
to
get
you
know
get
familiar
with
within
six
store.
Like
I
mentioned.
Full
co
and
record
are
also
very
interesting
projects,
definitely
take
a
look
at
those
and
you
know
kind
of
what
they
can
do
and
then
for
admission
controls
either
kiberno
or
opa
gatekeeper
are
both
cncf
projects.
I
mean
I'm
a
kiberno
maintainer,
so
I
did
all
of
the
demos
with
kiberno.
B
I
see
there
was
another
question
about
you
know
if
oppa
can
support
this,
so
there
is
ongoing
work
and
activity
for
oppa
and
gatekeeper
to
support
it
as
well.
So
you
know,
certainly
some
of
the
same
similar
validation
and
checks
can
be
done
there.
It's
a
slightly
different
approach
and
the
policies
will
look
different,
but
the
basics
will
be
covered
there.
A
Perfect,
so
we
preemptively
answered
the
last
question
from
the
audience
already,
that's
wonderful
and
as
noted
in
the
little
text
there
I
see
you
can
join
the
discussion
cloud
native,
live
cscs,
slack
channel
to
continue
the
discussions
and
I
think
jim
you
mentioned
that
you're
happy
to
talk
on
twitter
and
and
all
of
the
other
places
as
well.
So
please,
if
there's
any
questions,
I
think
engine
is
happy
to
take
more
discussions
going
further
as
well,
but
then
now
we
gotta
start
wrapping
things
up.
A
Thank
you
so
much
for
jim
and
thank
you
so
much
to
the
audience.
Thank
you
so
much
for
a
lot
of
questions
and
comments
really
great
to
see
so
many
here
today.
So
thank
you.
Everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
great
to
have
jim
here
talking
about
supply
chain
change,
security
with
kosan
and
cuber,
now
really
great
interactions.
Thank
you!
So
much
and
next
week
we
have
julie,
rosen,
presenting
introduction,
open
source
tool
to
test
kubernetes
deployment,
so
really
looking
forward
to
that
one.