►
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
Okay,
so
welcome
to
Cloud
native
live
where
we
dive
into
the
code
behind
cloud
ready,
I'm,
almost
and
I'm
a
census
Ambassador,
so
I
will
be
your
host
tonight
and
every
week
we
bring
a
new
set
of
presenters
to
Showcase
how
to
work
with
Cloud
native
Technologies.
A
They
bring,
they
will
build
their
things
and
they
will
break
things
and
they
will
answer
your
questions
in
today's
session,
I'm
stoked
to
introduce
Jim
and
Chip
who
will
be
presenting
on
kubernetes
policy
as
code
with
given
this
is
an
official
live
stream
of
the
CSF
and
as
such
is
subject
to
the
CNF
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
question
that
would
be
in
violation
of
the
code
of
conduct.
Basically,
please
be
respectful
to
all
of
your
fellow
participants
and
presenters
with
that.
A
B
Very
good,
thank
you,
sir
here
and
thanks
everyone
for
joining,
so
welcome
to
this
session.
B
Today,
we're
gonna
talk
about
policy
as
code
with
giverno.
So
let
me
let
me
pull
up.
You
know,
we'll
start
with
just
a
couple
of
quick
slides
to
set
the
background
and
then
we'll
dive
in
into
some
Hands-On
demos
to
Showcase.
You
know
some
of
the
details
and
best
practices
and
things
within
kuberno.
B
So
some
of
you
may
know
caberno
is
a
cncf.
You
know
incubating
project.
It
is
a
policy
engine,
that's
designed
for
kubernetes.
So
what
we
wanted
to
do
is
focus
really
on
how
you
know
some,
how
how
policies
get
used
in
the
real
world
right
and
we'll
talk
a
little
bit
about
why
policies
are
even
necessary,
but
then
dive
in
into
showing
how
you
can
you
know,
use
a
toolkit
like
giverno
as
part
of
your
overall.
B
You
know
not
just
within
your
clusters
at
runtime,
but
also
as
part
of
your
delivery
process
in
your
CI
CD
pipeline
and,
as
you
are
kind
of
doing,
continuous
delivery,
or
even
you
know,
leveraging
infrastructures
code
with
projects
like
whether
it's
terraform
or
cross
plane
or
other
things
right.
B
We'll
look
at
how
you
can
test
things
with
the
governor,
CLI
and
also
you
know,
we'll
show
a
slightly
Advanced
use
case
of
applying
validating
admission
policies,
which
is
a
newer
feature
in
in
the
current
versions
of
kubernetes,
with
the
kuberno
CLI
and
then,
after
that,
your
Chip
is
going
to
Deep
dive
into
some.
B
So,
let's,
let's
kind
of
talk
quickly
about
why
policies-
and
you
know,
and
especially
white
policies
for
kubernetes
itself
right.
So
if
you
kind
of
think
about
it,
kubernetes
is
perhaps
one
of
the
first.
You
know
platforms
where
which
brings
together
different
roles
like
developers,
security
and
operations
within
an
Enterprise
right
and
when
you
are
deploying
something
to
kubernetes.
B
Typically,
it's
as
a
resource
manifest,
and
these
manifests
contain
a
lot
of
different
details
which
have
you
know
different
folks
in
an
organization
might
be
interested
in
different
aspects
of
those
manifests,
so
developers
care
about,
of
course,
like
what
image,
what
you
know,
how
many
instances
different
things
of
their
application
operations,
May
care
about?
How
that
you
know
pod
or
deployment,
gets
placed
on
different
nodes.
What
type
of
cluster
it
runs
in?
B
What
other
backing
services
are
available
and
to
some
extent
how
that
you
know
is
secured
and,
of
course,
security
wants
to
know
everything
is
safe
and
sound,
and
you
know
the
pods
are
configured
correctly,
there's
no
chance
of
a
container
Escape
thanks
to
that
nature
right,
so
policy
serves
as
a
contract,
which
brings
all
of
this
together.
Now,
of
course,
you
could
write
a
policy
in
a
document
and
you
could
review
it
and
try
to
enforce
it
in
a
manual
manner.
B
But
if
you
once
you
move
to
policy
as
code,
that
contract
becomes
a
digital
contract
which
you
can
apply
Automation
and
best
practice
tools
to
enforce
across
your
environments
and
automate
at
scale
right.
So
it's
all
about
with
Cloud
native
with
kubernetes.
It
gives
us
that
toolbox,
where
you
can
now
start.
You
know
applying
policy
as
code
at
various.
B
You
know
points
in
your
the
life
cycle
of
your
applications
of
your
workloads
of
your
clusters
of
your
infrastructure
and
that
becomes
extremely
powerful,
bringing
together
all
of
these
different
concerns
within
an
Enterprise,
so
kevano
as
I.
You
know
mentioned
briefly
earlier.
It's
a
policy
engine
designed
for
kubernetes,
there's
no
programming
language
to
learn
as
you're
using
caverna
policies
and
we'll
take
a
look
at
some
of
those
examples
and
there's
several
different
capabilities
in
kivarno
right.
B
The
most
common,
of
course,
is
validating
different
configurations,
validating
different
behaviors
that
you
might
want
in
your
clusters.
There's
also
the
ability
to
mutate,
different
resources,
and
this
is
important
because
not
everything
you
know.
Of
course,
all
of
us
are.
You
might
be
familiar
with
things
like
git
Ops,
and
we
want.
You
know
our
resource
states
to
stay
in
in
git
as
much
as
possible,
but
there
are
things
that
have
to
be
dynamically
changed.
Much
like
a
pod
controller
can
launch
a
pod
mutating
policies
act.
B
As
you
know,
an
In-Place
updates
for
specific
things,
which
you
might
want
to
do,
whether
it's
again
for
security
for
operations,
for
other
reasons
as
you'll
see
in
some
of
the
demos
within
your
workloads-
and
this
works
very
well
with
Git
Ops,
because
the
state
that
you
store
and
get
can
be
different
and
through
things
like
server-side
apply,
you
can
apply.
Mutating
admission
controllers
can
change
specific
settings,
and
you
can.
You
know
signal
that
to
your
git
Ops
controller.
To
not
be
you
know,
kind
of
reward
or
not
interfere
with
those
settings.
B
There's
also
generate
policies
which
are
allow
you
to
generate
brand
new
resources,
and
this
is
another
extremely
powerful
capability
where,
for
example,
based
on
a
trigger
like
a
namespace
creation
or
a
service
getting
deployed,
you
can
generate
supporting
resources
for
that
particular
application,
workload
or
other
construct
that
you
are
working
with
with
caverno
there's
also
built-in
support
for
image
verification.
B
So
you
can,
you
know,
validate
image
signatures,
which
is
becoming
extremely
important
for
software
supply
chain
security
and
just
making
sure
that
the
images
that
are
deployed
to
your
cluster
are
actually
valid
images
and
not
something
that
a
malicious
actor
or
some
random
user
is
trying
to.
You
know
deploy
onto
your
cluster
and
then.
Finally,
one
of
the
newer
features
is
cleanup
policies,
so
you
can
now
use
caverno
through
policy.
Settings
to
you
know
automatically
clean
up
resources,
whether
it's
for
cost
management
and
tie
that
into
your
overall
finop
strategy.
B
The
the
picture
years
quickly
just
shows
how
caverno
operates,
and
this
is
in
the
webwork
mode.
So
every
of
course
every
operation
in
kubernetes
goes
through
the
API
server.
As
you
know,
the
API
server
for
will
first,
of
course,
authenticate
where
that
request
is
coming
from
and
if
the
user
is
authorized
to
perform.
That
request
and
after
that,
the
request
goes
through
mutating,
as
well
as
validating
admission
control
and
that's
where
caverno
kicks
in
right.
B
So
to
receive
leaves
every
request
for
based
on
your
configured
policy
set
from
the
API
server
can
apply
policies
to
it
and
can
either
validate
mutate,
generate
resources
based
on
things
in
the
API
request
itself,
so
lots
of
different
use
cases.
You
know,
as
you
can
imagine,
that
caverno
gets
used
for
and
and
very
quickly
as
you
kind
of
take
this
mindset
and
look
at
what
you
can
secure
and
automate
through
governo.
B
More
and
more
use
cases
keep
emerging
right
so
starting
with
basics,
of
course,
like
pod
security,
a
lot
of
you
might
know
that
now
with
kubernetes,
you
know,
1.25
pod
security
policies
are
no
longer
officially
supported,
they're
removed
completely
in
kubernetes.
You
need
to
replace
them
with
either
the
building
pod
security
admission,
which
provides
some
limited
controls
at
a
namespace
level
or
you
need
you
know,
admission
controllers
like
give
or
know
to
be
able
to
enforce
a
full
set
of
pod
security
policies
and
we'll
take
a
look
at
some
of
that.
B
You
can
also.
You
know,
of
course,
secure
different
things
in
your
workload.
You
can
set
up
granular,
rbac
and
even
generate
permissions
on
the
fly,
as
things
are
happening
as
namespaces
are
getting
requested.
Etc
a
segmentation.
Isolation
of
workloads
is
extremely
important
and
some
other
use
cases
right
and
similarly
for
operations,
as
well
as
for
cost
management,
Resource
Management
there's
a
lot
of
different.
You
know
different
things
you
can
do
with
kivano
and,
and
the
thing
is
once
folks
who
are
experts
in
managing
kubernetes.
B
You
know
because
of
the
ease
of
use
of
caverno.
What
we
typically
see
is
once
you
get
started
with
caverno,
you
end
up,
you
know,
typically
having
about
50
to
80
different
policies
within
your
clusters
across
some
of
these
concerns
itself.
B
A
By
now,
okay
yeah
yeah
go
ahead.
Please
check
it.
Okay,
so
first
question
was
like
yes2
versioned
policy.
Artifact.
Do
you
have
resources?
How,
however,
no
fits
into
policy
as
code
Beyond,
just
kubernetes
is
was
one
question.
Let
me
yeah
show
you
here
as
well.
So
yeah.
B
So
yeah,
if
I
understood
correctly,
the
question
was
how
caberno
fits
into
policies
code,
Beyond,
kubernetes
or
was
it
you.
B
So
that's
a
great
question
right.
So,
as
we
you
know
initially
mentioned,
caberno
was
built
for
kubernetes,
but
more
and
more
kubernetes
for
Stuff
itself
is
being
used
for
several
different
things.
Right,
kubernetes
gets
used
for
ISE
kubernetes
gets
used
for
CI
CD
with
projects
like
tecton
projects
like
cross
plane.
You
can
even
provision
Cloud
infrastructure
with
kubernetes,
so
all
of
that
kuberno
can
do
very
well
in
terms
of
applying
policies.
B
Now,
if
you
have,
you
know,
use
cases
like
if
you're
using
things
like
terraform,
we
are
you
know
in
this,
as
we
cover
the
roadmap.
There
are
some
exciting
features
coming
up
where
caverno
policies
will
you
will
be
able
to
apply
also
to
other
Json,
configs
and
data
that
you
will
be
pulling
from
these
type
of
external
systems,
so
that
will
extend
the
you
know
and
further
broaden
the
use
cases
for
caberno.
A
Okay,
so
I
guess
another
question
coming
up,
so
we
have
recently
had
to
rip
out
Kevin
from
a
cluster
because
it
was
adding
about
500
Ms
latency
per
partition,
request
any
plans
to
work
on
optimizing,
the
creation
path.
B
Absolutely
so,
I'm
not
sure
what
version
that
test
was
done
with,
but
you
know
every
release.
We
keep
further
improving
and
you
know
reducing
the
latency
required,
and
that
depends
a
lot
on
the
policies
that
configured.
So,
if
you
have
things
like
wildcard
permissions,
every
request
will
go
into
caberno
right.
If
you
have
you
know,
a
precise
policy
set
based
on
your
match,
exclude
caberno.
Will
dynamically
configure
your
web
of
configurations
to
only
receive
those
requests,
so
there's
a
lot
of
different
things.
B
You
can
do
to
fine
tune
that
and
with
release
1.10,
which
is
our
latest
release.
We've
also
split
out
some
of
the
background
controllers
and
tasks
from
the
admission
controller,
which
further
helps
with
you
know
that
processing
time
and
keeping
the
latency
roll.
So
typically,
what
we
measure
for
is
it
it
should
take
a
few
milliseconds
and
you
know,
feel
free
to
reach
out
on
the
camera
slack
channels.
In
the
community
day,
we
have
test
results
which
we
Benchmark
with
every
release.
A
Okay,
we
have
also
took
two
more
questions,
so
I
think.
Do
we
Audio
Lab
to
take
those
questions
right
now
or
after
the
actually
start
presentation,
because
questions
are
coming
up.
Yeah.
A
Yeah
I
guess
we're
waiting
for
wait
for
later
would
be
better
because
there
were,
like
their
personal
queries,
I
guess
much
more
yeah,
okay,
okay,.
B
Yeah
so
just
kind
of
going
back
to
policy
as
code,
and
this
term
obviously
gets
used
quite
a
bit,
but
to
explain
you
know
what
we
you
know:
I
want
to
kind
of
look
for
as
you're
looking
at
policy
for
CO
as
code,
so
anything
as
code
means
applying.
You
know
software
development
or
coding
best
practices
to
that
domain
right.
So
when
we
talk
about
policy
as
code
is,
how
do
we
treat
policy
artifacts
and
policy
definitions
declarations
themselves
as
much
as
possible
as
code,
so
to
do
things
like
Version
Control?
B
Do
things
like
code
reviews
use
the
same
tools
that
we
use?
You
know
our
Ides
get
other
kind
of
tools
we
use
for
coding
to
incorporate
policy
you
know
and
to
use
policies
in
that
same
manner.
So
the
three
things
you
know
that
are
really
important,
then
there's
obviously
others
as
well,
but
three
things
that
are
important
is
Version
Control
to
make
sure
that
you
are
able
to.
You
know,
store
these
artifacts
and
including
things
like
diff,
and
you
know,
code
reviews
Etc.
You
can
do
through
Version
Control,
that's
important,
being
able
to
test.
B
You
know
and-
and
you
know
we'll
take
a
look
specifically
at
that
and
then
to
automate
how
you
apply
policies
in
your
pipeline
and
we'll
see
how
the
kivano
CLI
helps
with
this
right.
So
let
me
switch
over
to
my
you
know,
screen
over
here,
my
shell
and
what
I'll
do
is
just
just
to
kind
of
quickly.
First
of
all
show
I
set
up.
B
So
super
simple
and
at
this
point,
because
I've
installed
kivano
if
I
look
at
my
you
know
what's
running
here,
I
have
four
deployments
the
admission
controller,
a
background
controller,
a
cleanup
controller
and
reports
which
manages
the
reporting
subsystem.
So
all
of
these
by
the
way,
are
tunable
right.
So
you
can
now
scale
these
separately.
You
can
size
them
or
you
can
turn
some
of
these
off
if
you
don't
require
them.
B
So
the
first
thing
I'm
going
to
just
quickly
show
you
know
for
books,
so
it
might
not
have
ever
seen
Kevin
operations
if
I
kind
of
do
just
you
know
in
this
I'm
not
gonna
actually
run
anything,
but
in
my
cluster
everything's
open
right
so
right
now
so
I
can't
basically
run
any
I
can
run
any
pod,
whether
it's
secure
or
not,
and
of
course,
if
I
just
run
like
nginx,
it's
insecure
by
default.
B
So
now,
if
I
just
do
you
know
so
I
want
to
apply
some
policies,
but
what
I'm
going
to
do
is
apply
policies
which
are
coming
from
a
git
repo
right.
So
this
could
be
my
own
private,
git,
repo
and
I
want,
as
my
cluster
come
up
so
now,
of
course,
as
you're
automating
this.
What
you
would
want
to
do
is
you
will
use
like
Argo,
CD
or
flux
or
some
other.
B
You
know
way
of
deploying
and
automating
this,
but,
as
you
see
it's
extremely
easy
now
to
just
you
know,
even
spin
up
a
test
cluster
apply
policies
from
any
one
or
more
git
repos,
and
now,
if
I
do
you
know
check
what's
running
on
my
cluster
if
I,
let's
just
do
a
get
C
Paul,
C
Paul
is
short
for
cluster
policy.
I
see,
I
have
a
number
of
pod
security
policies
because
I,
you
know,
pointed
to
a
git,
repo
and
I'll
show
what
this
git
Repro
has
I'm.
B
So
now,
if
I
try
to
run
that
same
part
again,
which
let's
say
you
know
will
we
know,
was
insecure
immediately,
Kevin
was
going
to
block
that
it's
going
to
send
events
which
you'll
see
you
know
in
your
cluster.
So
if
I
do
group
cuddle
get
events,
I
should
also
be
able
to
kind
of
see
that
kiberno
has
you
know
kind
of
put
some
policy
violation,
events
to
whoever
is
listening
to
them
and
I.
B
You
know
that
if
I
go
back
to
this,
you
know
it
shows
me
also
as
the
user
why
this
part
was
not
allowed
right.
So
here
what
I
did
was
as
I
applied
pod
security
policies
and
I
brought
these
particularly
policies
from
a
particular.
You
know
repository
as
you
saw
right.
So
this
is
the
get
repo
kiberno
maintains.
A
set
of
you
know
best
practice
different
pod
security
policies
on
our
website.
These
are
rendered.
B
If
you
go
into
policy-
and
you
know,
there's
almost
300
policy
samples
here
and
the
ones
that
I
specifically
pulled
were
from.
You
know
pod
Security
in
this
case
and
in
fact,
I
looked
at
you
know
at
the
enforce
mode.
So
let
me
show
you
in
my
IDE
what
exactly
that
did
right,
so
I'm
gonna
go
now
in
into
let's
go,
actually
pull
up,
give
or
no
policies
here.
B
B
You
know
set
the
info
a
validation,
failure
action,
so
every
caverno
policy
has,
you
know,
can
be
run
in
audit
or
in
in
Force
mode
and
I
want
to
set
that
to
enforce
in
this
case,
because
I
want
to
block
you
know
anything
which
is
insecure.
Now
you
can
further
customize
that,
and
you
can
say,
I
want
to
run
these
policies
to
not
only
you
know,
block
by
default,
but
I
want
to
override
that
and
for
a
certain
namespaces.
B
Let's
say
for
my
cni
I
want
to
run
that
in
audit
mode
because
I'm,
you
know
running
other
Security
checks
and
I.
Don't
want
that
workload
to
be
blocked
right.
Obviously
you
don't
want
the
cni
to
be
blocked
if
you're
kind
of
you
know
deploying
new
nodes.
Things
like
that
right,
so
those
type
of
customizations
now
are
super
easy
to
make
and
if
I
have
even
local
customizations.
B
So
if
I
kind
of
now
want
to-
let's
just
say
you
know,
if
I
go
into
my
policy
repo
and
over
here,
what
I'll
do
is
if
I
just
run
customize.
B
And
let's
run
out
the
build
command
and
what
I
want
to
do
is
I,
just
wanna
I'm
not
going
to
apply
this,
but
just
to
show
you
how
easy
it
is
to
now.
You
know:
do
some
of
these
things.
I
was
able
to
get
now
this
policy,
which
has
the
two
patches
that
I
wanted,
rather
than
just
the
one
kind
of
you
know
thing
we
wanted
to.
You
know,
set
up
front
right.
So
in
this
case
oh
I
didn't
save
this.
So
that's
why
the
namespace
didn't
show
up.
B
So
let's
run
that
again,
just
to
show
that
you
know
the
Imports
mode
now
has
this
particular
override
patch,
also,
as
you
can
expect
applied
right
so
with,
and
this
is
just
using
customize
now
yeah
I'll
also
kind
of
show
how
you
can
run
some
of
this
with
the
kivanos
CLI,
but
you
could
then
pipe
it
to
the
CLI
and
apply
this
of
course,
like
we
looked
at
in
the
first
example,
or
you
could
just
run
it
locally
to
test
it.
The
other
thing
I
want
to
show
is
all
of
these
policies
right.
B
So
every
policy
we
write,
there's
an
extensive
set
of
tests
that
we
also
provide
with
caverno
and
in
in
these
policies,
and
you
can
write,
of
course,
tests
for
your
own
policies,
which
is
another
policy
as
code
best
practice.
So
these
policies,
like
the
the
one
particular
one
which
I'm
running
over
here
so
let's
say,
require
run
as
non-root.
Here's
the
test
file
and
in
this
test
file,
all
I
need
to
say,
is
which
policy
I
want
to
apply
to
which
resource
and
what
is
the
expected
result
over
here?
B
Is
it
pass,
fail
or
skip,
or
something
else
right
and
you
can
have
you
know
as
many
Paul
policies
resources
Etc
in
your
desk
scripts.
So
that
way,
it's
very
easy
to
write
these
right.
So
now,
if
I
kind
of
do
the
same,
let's
say:
I'm
gonna
run
this
test
command,
so
I'm
running
the
kiverno
CLI
I'm
a
plugged
running
test
and
I'm
saying
how
do
I
run?
B
You
know
for
the
spot,
security
restricted,
because
maybe
I'm
tuning
that
I
want
to
run
some
tests
and
see
so
in
a
you
know
in
milliseconds
it
applied.
You
know
about
75
different
tests,
and
it
shows
me
that
everything's
passing
so,
let's,
let's
kind
of
make
something
so
fail
right.
So
if
I
say
maybe
because
of
a
bug
in
my
code
or
something
you
know,
I
I
want.
B
Instead
of
this
to
fail,
which
you
know
the
fail
is
what's
expected,
I'm
gonna
declare
this
test
case
should
pass,
and
if
I
have
an
issue
now
and
if
I
run
this
test
again,
what
I
would
expect
to
say
is
yeah.
This
test
case
failed
because
of
the
just
one
particular
you
know
scenario
where
in
fact,
the
result
that
kibrano
returned
back
was
a
policy
failure
instead
of
a
policy
pass
right.
So
super
simple
to
start
writing
these
tests
and
to
manage
these
tests
at
scale
which
allows
you
to
do
some
very
interesting
things.
B
The
last
thing
I
want
to
show
in
a
demo
and
then
we'll
take
some
more
questions.
If
there
are
any
before
I
hand
off
to
chip
is
also
how
the
governor
Paul,
you
know,
CLI
is
now
adapting
to
newer
features
in
you
know
that
are
coming
in
kubernetes.
So,
as
some
of
you
may
know,
I
think
in
kubernetes,
one
dot
I
believe
it
was
in
1.26
where
it
was
first
introduced
and
then
in
you
know,
a
1.28.
Now
this
is
a
beta
feature.
B
B
If
you
want
to
adopt
policy
as
code,
you
want
to
use
developer
tools
like
Ides
I
have
built-in
help
for
caverno
right
and
the
way
this
works
is
because
caberno
is
a
custom
resource
and
I
have
my
kubernetes
plugin,
and
this
help
is
just
automatically
pulled
up
and
shown
to
me
as
I'm
kind
of
doing
anything
in
my
IDE
itself.
But
here
what
this
you
know,
expression
using
a
language
called
cell
is
doing,
is
it's
checking
and
making
sure
that
my
pod
cannot
be
run
with
the
latest
tag
right
so
super.
B
You
know
very
simple,
and
obviously
you
could
do
this.
You
know
as
an
admission
Web
book,
but
why
not
run
this?
You
know
in
the
API
server,
if
possible.
Right
so
caverno
supports
that
and
you're.
What
I'm
about
to
show
is
I'm
actually
going
to
apply
this
validating
admission
policy
which
is
written.
You
know
in
with
cell
Expressions
to
a
resource
I.
B
Just
have
you
know,
you
know
deployment
resource
in
the
same
folder
and
I
can
now
test
this
in
my
CI
CD
pipeline
or
wherever
I
you
know
I
want
to
and
what
kuberno
did
is
as
it
applied
that
It
produced
the
policy
report
which,
by
the
way
is
you
know,
standard
or
a
API
that
we
are
the
policy
working
group
which
is
the
cncf
you
know
working
group
has
created
this
policy
report
API
from
format,
and,
it's
being
you
know,
proposed
to
be
promoted
to
a
Sig
level
API,
but
the
standard
report
that
it
produces
now
immediately
tells
you
or
tells
the
user,
if
they're
applying
this,
that
the
latest
tag
is
not
allowed
right.
B
A
Okay,
French,
that
was
awesome.
Actually
so
yeah
there
are
some
pushes
but
I
guess
those
questions
not
related
to
our
session.
Basically,
they
are
their
personal
ways,
so
I
guess
they
should.
What
would
what
they
should
do?
Is
they
should
contact
you
guys
through
slack
right
so
yeah.
B
Absolutely
and
we
do
have,
if
you
go
to
caverno
IO
to
the
community
link
right
on
top,
we
have,
you
know,
slack
channels
on
both
the
cncf
workspace,
as
well
as
the
kubernetes
workspace,
and
you
know
we're
pretty
active
over
there
so
feel
free
to
reach
out
over
there
or
just
you
know,
of
course,
create
a
GitHub
issue
required.
A
C
Everyone
all
right
glad
to
be
here
thanks
for
bringing
me
and
thanks
Jim
for
all
of
the
intro.
So
what
I
want
to
talk
about
in
this
section?
You
know
we
Jim
did
a
nice
overview
of
policy
as
code
as
it
pertains
to
coverino
what
that
actually
means,
how
you
can
go
about
doing
it
and
even
showing
some
newer
capabilities
that
will
be
releasing
in
111..
We'll
come
back
to
that
point,
but
I
wanted
to
flip
over
and
talk
about.
C
So
the
first
thing
here
is
this
concept
of
expiring
policy
exceptions,
and
let
me
step
back
a
little
bit
and
talk
about
policy
exceptions.
I
didn't
specifically
demo.
I!
Didn't
have
a
plan
to
specifically
demo
them,
but
a
policy
exception
is
a
construct
in
caberno
and
I.
Actually,
let
me
just
I
can
show
what
look
looks
like
I
policy
exception
is
a
specific
custom
resource
that
is
supported
in
caberno
that
allows
caverno
to
accept
any
resource
from
any
sort
of
policy.
So
the
general
use
case
for
this
is
something
like,
particularly
with
validation
policies.
C
You
have
a
validation,
Rule
and
you
want
to
exempt
some
sort
of
resource
from
that
validation
rule.
Let's
imagine
that
it's
maybe
that
image
policy
that
Jim
showed
just
a
moment
ago.
You
do
have
a
use
case
where
there
is
a
deployment
that
needs
to
run
with
an
image
tag
of
latest,
probably
not
super
likely
that
your
use
cases
specifically
that,
but
maybe
it's
something
else,
that's
related
to
that.
Rather
than
modifying
the
policy
to
say,
I
want
to
allow
a
deployment
named
Foo
to
circumvent
the
policy.
C
You
don't
want
to
touch
the
policy
using
this
policy
exception
custom
resource
you
can
create
basically
a
decoupled
way
to
allow
one
or
more
resources
to
be
exempt
from
a
policy.
So,
in
this
case,
I
want
to
exempt
a
specific
config
map
by
name
from
a
policy
called
require
labels
that
has
a
rule
called
check
for
labels
and
so
I'm
doing
this
in
a
separate
policy
exception.
C
Rather
than
modifying
the
policy,
I
could
modify
the
policy
and
and
do
this,
but
this
gives
you
a
decoupled
way
for
your
developers
and
other
users
using
policy
as
code
to
allow
things
by
policies
only
based
on
what
you
want.
So
this
works
just
fine,
and
this
was
released
in
caberno
1.9.
There's
a
lot
more
information
out
there
on
policy
exceptions,
you
can
go,
read
the
documentation,
it's
it's
a
pretty
cool
feature,
but
one
of
the
things
that
we
wanted
to
we
heard-
and
we
wanted
to.
We
could
do
something
about.
C
Was
this
notion
of
having
policy
exceptions?
Only
live
for
a
short
amount
of
time,
because
the
idea
with
policy
exceptions
is
so
long
as
the
policy
exception
exists,
whatever
the
the
definition
of
that
policy
exception
will
continue
to
be
enforced,
but
in
all
cases
that
may
not
be
really
ideal.
For
example,
going
back
to
that
policy
exception.
C
Let's
say
that
I
wanted
to
allow
a
resource
to
be
exempt,
but
only
for
a
day
or
a
week
or
whatever
the
case
might
be,
so
that
policy
exception
needs
to
go
away
after
that
point
in
time,
and
we
can
actually
do
that
in
caberno,
using
caverno
policies
and
also
coupled
with
a
new
angle
of
the
cleanup
policies
that
is
coming
in
the
next
version,
so
you're
actually
getting
a
a
sneak
preview.
In
addition
to
some
of
the
the
the
other
things
that
Jim
showed
around
validating
admission
policies.
C
C
So
that's
the
coverno
custom
resource
that
I
mentioned
and
we're
going
to
use
the
coverino
mutate
policy
and
actually
we're
also
going
to
involve
a
validate
policy
as
well.
We're
going
to
combine
those
together
to
get
this
idea
of
an
expiring
policy
exception
use
case.
So
the
flow
is
once
we
have.
The
policy
installed.
That's
going
to
validate
and
then
also
mutate,
the
policy
exception
we
want
to
watch
for
a
policy
exception
to
come
inbound.
C
Caberno
is
then
going
to
see
that
and
assign
the
label
for
cavernos
used
later
on
and
after
that
label
has
been
assigned
which,
just
for
demo
purposes
is
going
to
be
like
a
one
minute
timeout
or
something
it's
going
to
automatically
remove
that
resource.
So,
let's
flip
over
and
show
that
here
so
first
thing
that
we
need.
C
A
new
verb
called
watch,
because
we
need
to
be
able
to
watch
resources
that
have
that
label
so
that
we
can
then
remove
them
later
and
I've
already
created
this.
But
it
just
says
give
permission
to
coverno
Via
these
labels,
which,
by
the
way
this
is
another
nice
thing
about
Governor-
is
that
you
don't
need
to
modify
existing
cluster
roles.
You
can
just
create
your
own
cluster
role
to
augment
the
permissions
that
caverno
has
and
because
cavernos
supports
cluster
role,
aggregation
so
long
as
it
has
the
correct
labels.
C
C
So
I've
already
created
that
now,
let's
take
a
look
at
the
policy
here,
so
the
first
thing
that
I'm
doing
is
a
validation,
check
and
I'm
matching
on
policy
exceptions
and
I
just
want
to
apply
sort
of
guardrails
as
a
clinistrator
who
is
responsible
for
allowing
users
to
submit
policy
exceptions,
but
I
only
want
to
make
sure
when
they
submit
a
policy
exception
that
it's
only
for
a
single
policy,
because
a
policy
exception
could
exempt
a
whole
number
of
policies
with
a
whole
number
of
rules.
It
can
be
very,
very
wide.
C
You
may
not
really
want
that
in
a
lot
of
cases.
You
may
want
to
scope
that
down
so
that
it's
more
fine-grained
so
as
not
to
allow
someone
to
basically
counteract
an
entire
policy
if
you
will
so
I'm
enforcing
that
a
policy
exception
needs
to
only
be
for
a
single
policy
and
I'm
doing
that
with
as
I'm
highlighting
here
a
validate
rule.
So
this
is
one
policy
that
has
multiple
rules
in
it.
C
I'm
assigning
is
one
minute,
and
what
this
is
going
to
do
is
again
watch
for
policy
exceptions
and
if
it
sees
one
it's
going
to
mutate
it
and
it's
going
to
add
a
new
label
with
that
value
of
one
minute,
so
the
net
effect
is
and
if
I
go
back
to
my
diagram,
if
the
user
submits
a
policy
exception,
coverno
is
going
to
first.
Do
the
validation
check
and
make
sure
that
everything's
copacetic
with
that
and
then
it's
going
to
add
the
label
to
it
before
persisting
it?
C
C
The
cluster
policy
already
has
both
of
the
rules
that
match
on
the
policy
exception.
Now
here's
a
policy
exception
that
I'm
going
to
create
and,
as
you
can
see,
it's
only
for
one
single
policy,
so
it
will
pass
the
validation
check
and
what
I
expect
to
have
happen
is
once
I
create.
C
This
coverino
is
going
to
label
it
with
the
cleanup
label
value
and
then
without
having
to
do
anything
else,
including
in
case
it
wasn't
clear
having
to
write
or
use
an
existing
cleanup
policy,
we're
not
using
a
cleanup
policy
which
is
a
capability
of
earlier
versions
of
caverno.
We
just
simply
want
to
label
it
so
that
we
have
do.
We
don't
have
to
use
a
policy
to
match
on
it.
So
let's
try
this
I'm
going
to
apply
the
policy
exception
and
we
saw
that
it
was
created.
So
let's
get
that
back.
C
Okay-
and
we
saw
here
that
caverno
did
assign
the
label,
so
it
it
automatically
got
the
label
based
on
the
policy
which
we
defined
and
so
what
we
expect
to
have
happen,
then,
after
one
minute,
this
policy
exception
will
automatically
get
deleted.
C
So
if
we
get
policy
exceptions
right
now,
it's
there
with
an
age
of
30
seconds
and
if
we
wait
just
a
little
bit
longer,
caverna
will
automatically
behind
the
scenes,
because
it
now
has
permission
to
remove
only
policy
exceptions
for
now
once
that
expiration
date
has
been
reached,
it
will
remove
this
policy
exception.
So
you
can
imagine
right
now:
users
are
able
to
circumvent
the
policy.
C
That's
defined
in
the
policy
exception,
which
is
only
a
config
map
named
chipped
very
original
I
understand,
but
such
that
it
is,
they
can
submit
any
number
of
those
that
they
want
and
it'll
bypass
the
policy.
But
once
this
policy
exception
is
gone,
they
can
no
longer
do
that,
and
so,
if
I
get
a
policy
exception
back
now,
hopefully
I've
been
talking
long
enough
that
it
has
resulted
in
the
policy
exception
being
removed,
and
we
can
see
it
has
in
fact
been
removed.
I
didn't
need
to
do
anything
else.
B
C
Policy
and
let's
just
show
in
fact
that
I
only
have
one
cluster
policy
and
it's
the
one
that
I
just
created
which,
by
the
way,
if
you
didn't
know,
there's
this
Cube
control,
git
coverno
command.
That
will
give
you
all
of
the
coverno
resources
very
convenient.
If
you
want
to
see
that
everything
that
caverno
has
created,
let
me
just
pause
real
quick
here
to
address
a
question
that
I
saw.
C
Can
you
create
created,
submit
a
deleted
I'm,
not
sure
that
I
understand
I'm,
not
sure
I,
understand
the
question
here.
If
you
can
maybe
clarify.
A
I
guess
you
can
skip
that,
maybe
some
sort
of
spamming
I
guess
you
can?
Okay,
let's
keep
that
yeah.
C
Well,
if
it,
if,
if
you
do,
have
a
question
around
around
what
we're
presenting
we're
glad
to
glad
to
take
that,
but
that
is
the
that's
the
first
use
case
here,
expiring
policy,
exceptions,
and,
of
course
all
of
this
is
optional.
If
you
didn't
want
to
use
the
expiration,
if
you
wanted
to
use
just
a
policy
exception,
any
of
these
things
are
completely
optional
in
their
modular.
So
if
you're
only
interested
in
validation,
you
can
of
course
only
do
validation.
C
C
To
do
some
really
amazing
use
cases
that,
quite
frankly,
really
no
other
policy
engine
can
do
and
can
really
help
you
not
only
from
the
security
aspect
which
many
people
exclusively
associate
with
policy
engines,
but
also
operations
and
automation,
which
can
really
be
helpful
to
you
as
cluster
administrators
and
operators
in
your
day
job,
so
that
is
expiring
policy
exceptions.
The
Second
Use
case
that
I
want
to
show
which
involves
even
more
of
these,
coming
together
in
a
full-blown
system.
C
Is
this
concept
that
I
created
of
a
one-time
passcode
system
for
caverno,
and
so
rather
than
rather
than
showing
a
very
complex
diagram,
I'm
showing
another
complex
diagram
which
is
just
a
state
diagram
here?
But
but
but
what?
What
I
wanted
to
create
with
this
one
and
and
just
to
illustrate
kind
of
the
art
of
the
possible
I,
want
to
be
able
to
create
a
system
in
which,
rather
than
caberno,
blocking
everything,
or
rather
than
users
having
to
explicitly
create
a
policy
exception?
C
What
if
you
could
use
caverno
to
give
somebody
a
one-time
passcode
that
they
can
use
in
order
to
allow
just
that,
one
resource
to
circumvent
policy,
but
never
again,
and
so
I
wanted
to
set
out
to
see
if
we
could
do
something
like
that
with
caperna
by
combining
multiple
of
these
abilities?
In
fact,
this
is
something
that
we
can
do
so,
let's
just
walk
through
this.
So
the
idea
is
that
somebody
creates
a
bad
deployment,
and
maybe
this
bad
deployment
is
a
deployment
that
you
have
a
policy
that
says.
C
Containers
must
not
run
as
root,
which
is
a
fairly
common
one.
It's
part
of
the
Pod
security
standards,
but
you
wanted
to
allow
users
to
maybe
circumvent
that
based
on
a
one-time
passcode
that
was
that
didn't
need
any
external
dependencies
and
by
the
way,
this
whole
system
does
not
need
any
other
external
dependencies.
There's
no
other
applications,
internal
external,
that's
required!
This
is
all
driven
through
caverno,
so
you
wanted
them
to
be
able
to
bypass
a
policy
using
a
one-time
passcode.
So
the
flow
is
user,
creates
a
bad
policy
or
a
bad
deployment.
C
Caverno
is
going
to
check
based
on
a
policy
yep,
that's
a
bad
deployment,
so
we'll
deny
that,
but
here's
a
one-time
passcode
that
you
can
use-
if
you
want
to
you,
don't
have
to
use
it,
but
you
can
use
it
if
you
want
to
circumvent
the
policy
just
this
one
time,
so
the
user
will
be
able
to
see
in
the
message
request
and,
of
course,
I'll
demo
this.
So
this
will
become
real
in
just
a
moment
here,
but
the
user
will
be
able
to
see
all
right.
My
request
was
denied.
C
Oh
there's,
a
one-time,
passcode
okay.
Well,
let
me
add
that
one-time
passcode
to
my
deployment
in
the
form
of
a
label
and
I'll
resist
submit
that
again.
Caverna
is
going
to
check
that
it
sees
that
it
now
has
a
label
and
it's
going
to
check
if
the
code
is
valid.
If
the
code
is
valid,
it's
going
to
allow
the
deployment
and,
of
course
the
user
will
see
great.
My
deployment,
which
was
previously
getting
blocked,
is
now
allowed.
C
Now,
let
me
see
if
I
can
try
and
circumvent
it
again.
Let
me
try
and
reuse
the
same
passcode,
so
they'll
delete
deployment
and
we'll
try
and
create
it
with
the
same
passcode
caberna
is
going
to
see
nope
that
passcode
was
already
used,
blocked,
and
so
one
other
thing
that
that
we
can
layer.
In
addition
to
this
is
a
quota
system.
Let's
say
that
you
wanted
this,
but
you
also
wanted
to
use
a
quota
system
on
a
per
user
basis.
C
C
All
right
and
for
this
one
we're
actually
going
to
combine
a
bunch
of
different
policies,
now
I'm
not
going
to
bore
everybody
and
walk
through
these
policies
from
end
to
end,
because
there
are
several
rules.
There
are
several
there's
several
pieces
of
complexity
there,
but
I
do
want
to
show
a
couple
things
first
of
all,
is
that
we're
using
we're
using
a
multiple
validation
rules,
so
we're
validating-
and
this
is
the
bulk
of
the
policy
here.
C
C
Called
OTP,
which
is
going
to
serve
as
basically
the
config
file,
if
you
will
for
this
whole
system.
So
this
has
a
couple
things
one.
It
has
usernames
that
have
a
quota
associated
with
them,
so
I'm
chip
I
have
a
quota
of
five
one-time
passcodes
that
I
could
use.
I've
got
another
user.
Mark
he's
only
got
one,
so
we're
going
to
do
this
as
Mark,
so
that
we
don't
have
to
burn
up
five
and
then
we've
got
the
passcode
system
here.
C
So
these
are
all
passcodes
that
have
been
used
before
and
since
they've
been
used,
it's
marking
when
they
were
used
in
the
user
which
consumed
them.
So
this
really
allows
you
to
have
a
config
file
with
the
passcode
system,
but
also
use
it
as
a
fun
as
an
auditing
system
later
on
down
the
line.
If
you
wanted
to
see
what
what
were
all
my
codes
when
were
they
consumed
and
who
consumed
them?
C
So,
let's
just
try
this
out.
So
I've
got
all
of
the
caberno
components
that
are
already
installed
all
the
policies
and
also
a
cleanup
policy
which
is
going
to
reset
our
quota
system
for
us.
So,
let's
just
see
what
happens
here:
I'm
gonna,
try
and
submit
this
bad
deployment
for
right
now,
I'm,
not
using
this
OTP
label,
I'm
just
going
to
submit
it
as
is,
and
first,
let's
show
the
context
that
I
have
so
I
am
currently
using
this
context.
C
C
Our
policy,
which
is
an
enforce
mode,
says
you're
not
allowed
to
do
that,
but
this
policy
is
also
subject
to
the
one-time
passcode
system
and
by
the
way
all
of
this
stuff
is
in
a
blog,
and
we
can
provide
the
link
to
that
later
so
that
you
can
read
all
this
at
your
leisure,
you
can
use
the
try
out
the
policies
we've
got
all
this
documented
delete
a
try
to
apply
it
and,
as
you
can
see,
nope
the
policy
and
the
rule
said:
sharing
the
host
name.
C
Spaces
is
disallowed,
but
it
also
says
to
get
around
this.
You
may
use
a
one-time,
passcode
and
there's
our
one-time
passcode,
and
this
is
randomly
generated
upon
every
bad
resource.
So
let's
just
pick
that
up
and
try
it
so
I'm
going
to
put
this
as
the
value
of
a
label.
We
now
have
our
one-time
passcode.
C
Cool,
as
you
see,
the
deployment
was
allowed
because
the
one
time
passcode
was
valid
and
it
was
consumed.
So
let's
go
back
and
check
that
config
map
that
had
everything
in
it
and
see
what
it
did.
So
you
see
here
is
the
one-time,
passcode
and
because
I'm
Mark
and
I
just
used
it
it
added
when
that
was
consumed
in
my
username,
and
it
also
debited
the
last
credit
that
he
had
in
his
one-time
passcode
system
to
zero.
C
So
two
things
happen,
then
let
me
delete
this
and
if
I
try
and
reapply
the
same
bad
deployment
again
keeping
in
mind
that
I'm
still
mark
I
shouldn't
be
able
to
do
this,
and
it
tells
me
that
code
is
invalided
or
it
has
already
been
used
so
denied.
So
fine,
let's
see
if
I
can
circumvent
this
and
get
another
one-time,
passcode
and
disregard
my
quota.
So
I
have
a
new
one-time
passcode
here.
So
you
can
see.
This
is
a
different
code
that
was
automatically
generated.
C
All
of
the
stuff
is
generated
and
managed
entirely
by
caberno,
as
I
said,
there's
no
external
dependencies
involved
here.
This
is
all
self-driving,
so
we'll
go
and
we'll
try
and
put
this
new
one-time
passcode
there
and
we'll
once
again
try
and
apply
this
knowing
that
Mark's
quota
is
now
zero
and
you
can
see
here
even
though
the
code
was
valid,
that's
denied
because
the
quota
has
been
exhausted
and
you'll
need
to
contact
a
platform
administrator
to
either
increase,
increase
the
quota
or,
like
I
showed
earlier.
C
You
could
use
a
policy
exception
to
get
around
this,
so
that's
kind
of
the
gist
of
the
one-time,
passcode
system,
and
again
some
of
this
stuff
is
just
demonstrating
the
art
of
the
possible.
It's
probably
not
likely
that
you're
going
to
use
this
in
production
totally
understand
that,
but
it
does
illustrate
the
power
of
something
like
caverno
using
policy
as
code
and
I'll
just
quickly
flip
through
some
of
the
policies
that
are
here,
you
can
see.
C
So
one
of
the
capabilities
that
I'm
using
here
that
was
slightly
different
from
the
first
use
cases
I'm
mutating
an
existing
resource,
not
a
new
resource
caverno
is
the
only
policy
engine,
at
least
of
which
I'm
aware
that
has
the
ability
to
change
existing
resources
in
the
cluster
based
upon
another
admission
of
them,
so
very
powerful
stuff
that
you
can
get
with
just
mutating
for
existing
resources
and
here's
another
one.
That's
resetting
the
quota,
so
the
the
the
gist
of
this
is
policies.
C
Code
can
be
extremely
powerful,
can
unlock
a
lot
of
capabilities,
far
more
than
just
security
and
with
caberno
and
the
unique
capabilities
that
it
has.
You
can
weave
many
of
these
things
together
to
get
some
pretty
cool
use
cases
even
like
this
one-time
passcode
system,
however
potentially
impractical
they
may
be.
It
still
demonstrates
that
you
can
do
it
and
you
can
do
all
of
this
stuff
using
caberno
without
any
other
external
dependencies.
C
So
that's
that
for
the
use
cases,
let
me
flip
back
over
and
now
kind
of
close
out
with
some
upcoming
things
in
the
next
version
of
caverna.
Let
me
first
pause
and
see
if
there
are
any
questions
here,
I
don't
think
there
are
any
questions
cool,
okay,
so
that
is
it
for
the
the
could.
The
coverino
use
cases
feel
free
to
drop
a
question
in
if
you
have
any
questions
about
those
otherwise,
like
Jim
mentioned
many
places
to
come
and
talk
to
us,
but
what's
coming
in
111?
C
Well,
you
kind
of
saw
two
of
those
sneak
peeks
here
in
the
form
of
using
the
caberno
CLI
to
validate
validating
admission
policies
which,
by
the
way,
this
isn't
something
that
kubernetes
has
a
an
answer
for
so
that's
the
reason
why
that
we
put
that
into
the
Cabernet
CLI
and
also
I
showed
the
new
cleanup
label.
C
Both
of
these
are
features
that
are
coming
in
1.11,
so
kind
of
to
expound
on
that
Governor
111
is
going
to
have
more
extensive
support
for
validating
admission
policy,
and
specifically,
there
are
really
four
points
of
intersection
that
we're
looking
at.
One
of
them
is
what
Jim
demonstrated
the
ability
to
test
validating
admission
policies
by
the
caverno
CLI,
so
you
don't
need
to
use
another
CLI
and
in
fact
Corona
kubernetes
won't
have
one.
So
this
gives
you
the
ability
to
test
both
validating
and
emission
policies
and
coverino
policies
using
the
same
CLI.
C
You
don't
need
to
switch
between
multiple
ones
being
able
to
generate
policy
reports
from
validating
admission
policies.
This
is
a
really
big
one.
We
didn't
really
go
into
a
lot
of
detail
on
this,
but
Governor
creates
what
are
called
policy
reports,
and
these
are
another
custom
resource
that
are
in
the
cluster.
The
main
value
of
these
are
that
they're
decoupled
from
policies.
So
now
you
don't
have
to
worry
about
entitling
users
to
policies
or
the
kubernetes
audit
log
just
to
be
able
to
see
how
their
resources
are
doing.
C
Policy
reports
are
a
separate
custom
resource
in
caverna
1.11.
In
addition
to
caverno
continuing
to
generate
policy,
reports
from
caverno
native
policies
will
also
allow
you
to
generate
policy
reports
from
validating
admission
policies
that
may
be
in
your
cluster,
so
this
can
be
a
great
way
to
see
and
decouple
and
allow
things
like
rbac
to
entitle
your
developers
and
users
to
see
how
their
resources
are
doing
in
compared
to
validating
admission
policies.
C
The
third
thing
that
we're
going
to
allow
with
this
is
the
ability
to
write
caverna
rules,
natively
using
cell
so
sell
as
Jim
showed,
is
the
language
that
validating
admission
policies
must
be
written
in
if
you'd
like.
You
can
also
write.
Caverno
policies
using
cell
expressions-
and
the
fourth
point
is,
which
is
kind
of
are
related
to
the
previous
one
is
caverna,
will
act
as
a
controller
to
actually
generate
validating
emission
policies.
For
you,
if
they're
written
in
cell
and
if
they're
written
in
such
a
way
as
the
API
server
can
support
them.
C
So
validating
admission
policies
are
still
very
new.
There
are
many
gaps
that
they
have
compared
to
other
external
admission
controllers,
but
in
any
case,
if
you're
writing
them
in
such
a
way
that
they
are
compatible
with
the
API
server,
Governor
will
see
that
and
will
generate
and
manage
those
validating
and
Mission
policies
for
you
without
having
to
do
anything
else.
C
So
that's
what
we're
doing
in
1.11
for
validating
admission
policy,
support,
really
cool
stuff,
I
hope
you'll
check
that
out
and
by
the
way,
if
you
wanted
to
test
some
of
this
stuff
is
available
right
now,
so
there's
a
way
to
test
pre-release
code.
You
can
definitely
check
that
out
going
on
to
the
next
thing
there
per
resource
policy
reports,
so
I
already
explained
a
little
bit
about
policy
reports.
Today,
coverno
generates
policy
reports
on
a
per
policy
basis.
B
C
Resource
intensive
and
require
less
space
in
FCD,
so
we're
going
to
switch
over
and
start
using
per
resource
policy
reports.
This
would
be
a
policy
report
for
an
individual
resource
rather
than
one
that's
at
the
policy
level.
There
are
many
things
that
that
that
enables
more
details
will
be
coming
around
that
cosine,
2.0
and
notary
updates
for
those
that
are
using
caverno.
You
may
know
that
coverino
already
supports
image
and
image
signature,
verification
from
the
likes
of
six
door
cosine
and
with
the
latest
release
1.10.
C
Also,
the
notary
project
we're
going
to
extend
that
even
further
in
111
by
bringing
in
cosine
2.0
support
and
also
some
of
the
latest
updates
to
notary.
So
look
for
those
enhancements
in
111
and
the
last
point
there
is
something
that
I
also
showed
in
the
demo
clean
up
using
that
Reserve
label.
So
that's
that
cleanup.coverno.io
TTL
label.
C
You
saw
that
act
that
in
action,
so
you'll
get
that
in
1.11.
That
allows
you
to
assign
that
label
using
like
I
showed
either
a
cover,
no
policy,
somebody
can
self-assign
it.
You
can
have
it
and
get
whatever
you
want
to
do.
That
label
will
automatically
cause
caperna
to
clean
things
up,
and
with
that,
that's
all
that
we
have
for
you
here
and
for
additional
information.
Please
check
us
out
on
the
website.
C
The
website
also
has
links
to
community
how
you
can
get
involved,
how
you
can
get
in
touch
with
us,
how
you
can
start
being
a
contributor.
We
have
a
contributors
meeting,
lots
of
ways
to
get
in
touch
with
us
and
get
involved.
So
if
there
are
no
further
questions
thanks
a
lot
for
being
here
and
we
hope
to
connect
with
you
sometime
in
the
future
and
in
the
community.
A
Yeah
awesome
awesome,
so
I
guess
I
would
like
to
add
one
question
at
least
so.
The
question
is
like
what's
next
for
like
what's
next
on
the
Cuban
roadmap
right
like
how
a
person
can
get
involved
into
a
giver,
no,
for
it
can
be
a
student
or
a
professional,
or
something
like
that
who
is
new
to
this
kind
of
film?
What
do
you
say.
C
Yeah,
so
Jim
I
think
put
a
link
out
there
to
the
community.
The
community
has
a
lot
of
links
as
far
as
we
have
a
contributor's
guide,
with
a
lot
of
information
on
how
to
get
started
with
caberno.
Looking
at
the
code
base,
getting
your
development
environment
set
up.
C
There
are
a
lot
of
resources
around
there.
Obviously
slack
is
a
great
way
so
definitely
check
out
the
community
link
that
that
was
just
provided
and
take
a
look
at
some
of
those
resources
and
you
know
feel
free
to
connect
with
us
in
slack
a
lot
of
the
maintainers
are
there
and
very
interested
in
helping
out
new
contributors
so
check
the
guide
out.
Come
talk
to
us.
If
you
have
any
problems.
A
Awesome
I
guess
the
lot
of
people
that
a
lot
of
students
will
be
influenced
by
you
guys
and
will
contribute
to
over
slack.
Okay.
Thank
you
so
much
Jim
and
chip
for
the
awesome
session
and,
let's
now
end
the
session.
Okay.
Thank
you
so
much
again
for
giving
your
time
thanks.
Okay,
thank
you!
Okay,
bye,
then,
okay,
so
yeah!
So
let's
start,
let's
just
end
up
station
now.
Okay!
So
thanks
everyone
for
joining
the
latest
episode
of
cloud
native
live.