►
From YouTube: Webinar: How to keep your clusters safe and healthy
Description
Declarative configuration management in Kubernetes is powerful, but can also be a pain when you as a cluster administrator need to enforce best practice compliance across resources. Similarly, Kubernetes’ RBAC capabilities are powerful, but cannot be easily tweaked based on namespaces, labels, or other settings.
Kyverno is a Kubernetes policy engine that was designed to solve these problems, and much more, in an intuitive manner and Kubernetes-native manner. Join us to learn how to easily mutate, validate, and generate configurations to keep your clusters safe and healthy!
Presenter:
Shuting Zhao, Software Engineer @Nirmata
Jim Bugwadia, Founder and CEO @Nirmata
A
A
We
would
like
to
welcome
our
presenters
shooting
Zhou
software
engineer
at
nur,
Mata
and
Jim
LaGuardia
founder
and
CEO
at
nur
Mata,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
CNCs
and,
as
such
is
subject
to
the
CNC
F
code
of
conduct.
A
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
Please
also
note
that
the
recording
and
the
slides
will
be
available
later
today
on
the
CNC
F
webinars
page
at
CNCs,
IO,
slash
webinars.
With
that
I'll
hand
it
over
to
shooting
and
Jim
to
kick
off
today's
presentation,
take
it
away
Thank.
B
You
Kristy
and
thanks
everyone
for
joining.
So
what
we're
gonna
do
today
is
we're
gonna
cover
for
real-world
use
cases
and
show
you
how
workload
security
can
be
applied
to
them.
So,
first
we'll
talk
about
validating
kubernetes
configurations,
we'll
also
talk
about
how
you
can
manage
runtime
security
for
pods,
we'll
discuss
how
you
can
generate
configurations
using
cover,
know
the
policy
management
tool,
we're
gonna,
discuss
and
we'll
also
talk
about
how
to
apply
fine-grained
access
controls,
in
addition
to
kubernetes,
are
back
rules
using
caverno.
B
B
Making
sure
that
images
are
me
are
immutable
and
you're,
not
you
know
accidentally
or
inadvertently,
running
an
older
or
different
version
of
an
image
because
you're
using
a
mutable
tag
like
latest
restricting
images
to
certain
registries
where
you
perform
your
scanning
and
and
of
course,
we'll
talk.
You
know
pod
security,
which
is
a
very
important
aspect
of
the
runtime
security
concerns
within
your
cluster
you.
B
So,
let's,
let's
discuss
how
policy
management
can
solve
this
and
then
we'll
take
a
look
at
what
cover
no
specifically
also
provides
so
first
off
kubernetes
itself
is
a
very
pluggable
extensible
system,
admission
controllers
and
communities
can
be
extended
and
you
can
validate
or
mutate
different
API
requests.
So
typically,
policy
managers
tools
like
governo,
will
also
also
tools
like
OPA
gatekeeper
can
work
as
policy
managers
can
look
at
incoming
configurations
and
can
validate
configurations
based
on
policies
that
you
write.
So
there
are
general
purpose.
B
You
know
policy
management
tools,
but
these
require
learning
a
different
language
and
knowing
how
to
manage
policies
within
their
paradigm
within
their
domain.
Here.
What
we
have
done
with
Kavanaugh
is
we'll
look
at
is
governo
is
built
specifically
for
kubernetes
and
does
not
require
that
you
know
that's
deeper
learning
curve.
Also,
of
course,
you
know
it's
possible
to
write
your
own
admission
controllers,
but
doing
this
for
each
type
of
check
that
you
want
to
manage
becomes
a
non-trivial
effort.
B
So,
let's
talk
a
little
bit
about
what
caverna
exactly
does
right.
So
governo
is
a
policy
management
tool.
It's
an
open
source
project
developed
specifically
for
communities.
It's
not
a
general
purpose
policy
management
tool.
It
does
not
provide.
You
know
a
different
language
or
different
paradigm
for
managing
policies,
but
in
fact
uses
that
same
declarative
style
of
configuration
management
that
kubernetes
does
too
for
writing
and
managing
policies.
So
policies
are
custom
resources.
B
Policy
violations
are
also
custom
resources
and
caverna
works
really
well
with
different
kubernetes
concepts
and
patterns
like
we'll
see
what
pod
controllers
also
with
generating
events,
but
you
know,
but
also
scanning
things
within
the
communities
cluster
it
can.
It
can
work
extremely
well
where
to
introduce
given
or
into
your
existing
production
clusters,
becomes
a
lot
easier
right.
You
don't
have
to
impact
existing
workloads,
and
this
lets
you
roll
out
things
in
a
very
controlled
manner.
B
So
you're
exactly
half
caverna
works,
so
it
plugs
in
as
in
a
web
book
receiver
for
any
API
server
requests
and
it
handles
both
validation
as
well
as
mutation
by
box,
and
for
each
of
these
requests.
Governo
will
get
an
admission
review
requests
based
on
policies
that
you
configure
it's
smart
enough
to
optimize
that
configuration,
so
it
will
only
receive
requests
for
the
objects
and
for
the
types
of
you
know,
data
that
you
want
to
validate
and
then
keep
on.
B
Oh-
and
you
know,
based
on
the
policies
you
define
as
resources
in
your
cluster,
governo
can
validate
mutate
or
even
generate
new
configurations
based
on
these
policies
and
rules.
So
cavern
also
does
background
scanning
so
for
existing
workloads,
which
might
have
been
a
planning
before
you
introduced.
A
new
policy
rule
Kieren
will
scan
these
will
generate
policy
violations
so
either
you
can
put
a
policy
into
a
mode
to
block
a
resource
request,
or
it
can
generate
a
violation
and
report
that
which
you
can
get
through
coop
cuddle
or
any
other
reporting
to.
B
So
here's
what
a
policy
looks
like
in
key
burner
right.
So
it's
a
very
simple.
You
know
dead,
sort
of
declarative
style
configuration
a
policy
contains
several
different
rules
and
each
rule
will
have
a
match
and
exclude
clause.
The
match
will
define
you
know
which
resources
the
policy
the
rule
of
operates
on,
and
these
could
be
based
on
label,
selectors,
resource
names,
kinds,
namespaces,
lots
of
flexibility
given
also
automatically
Maps,
based
on
the
admission
request.
It
will
take
user
and
subject
information
map
that
to
the
set
of
groups
that
you
have
configured
in
your
cluster.
B
B
So
here's
an
example:
it's
a
simple
example
where
what
we're
trying
to
do
here
is
validate
that
your
pods
are
not
running
with
root
user,
enabled
right
so
to
do
that
in
a
pod
security
context.
You
can
either
check
this
at
the
pod
level
or
at
the
container
level,
and
this
rule
that
we're
looking
at
over
here
is
matching
for
resource
kind
pod,
and
then
it's
validating
that
using
the
any
pattern
syntax,
which
means
that
it's
an
or
for
either
of
these
type
of
declarations
and
it's
up
in
the
list.
B
So
each
checking
for
the
security
context
at
the
pod
level
and
making
sure
that
run
as
non-root
is
set
to
true,
or
it
will
check
that
at
the
container
level
and
their
condition
will
satisfy
this.
Rule
means
that
now
your
resource
passes
this
rule.
Otherwise
you
can
choose
to
block
or
a
reporter
violation
on
it.
B
You
so
just
a
quick
comparison
between
ki
Brno
and
some
of
the
existing
tools
and
a
question
we
get
is
you
know
when?
Should
we
use
something
like
oppa
versus?
When
would
you
want
to
use
a
tool
like
governo,
so
first
off
again,
kübra
know
is
very
specific
to
kubernetes.
If
you
need
policies
to
apply
to
more
than
communities
if
you're
managing
these
for
other
configurations,
general
purpose
tools
like
oppa,
are
extremely
powerful
and
extremely
capable
of
doing
that.
B
B
C
C
Alright,
so
first
let
me
switch
my
screen
to
the
manifest
in
order
to
deploy
Keira
no
to
your
cluster.
You
just
need
to
apply
this
install
that
llamo
to
your
cluster.
It
has
a
bunch
of
resources
defined
and
if
you
want
to
install
a
different
version
of
a
cluster,
you
just
need
to
update
the
image
here,
and
this
is
available
on
our
github
page,
but
today,
I'm
gonna,
using
this
most
recent
release
candidate,
so
I
just
update
the
image
tag
here.
C
Alright
Oh
quick
heads
up
of
my
cluster
I'm
using
a
116
cuvee
DM
cluster
here.
So
let's
first
create
the
kernel,
so
I'm
gonna
do
coop
gato
crate
F
installed,
oh
yeah
mo.
So
you
can
see
there
are
a
bunch
of
resources
being
created.
Let's
quickly
check
if
Quirino
is
running,
it's
in
the
namespace
running
as
a
deployment.
C
Ok,
so
now
you
can
see
the
pod
is
running
in
the
running
state.
Alright,
so
the
first
policy
I
want
to
show
today
is
a
validate
policy
which
can
use
to
validate
your
existing.
Configuring
were
close
configurations.
What
you
can
see
here.
This
policy
is
applied
to
pod
and
it
is
validating
the
allowed
images.
C
Registries
I
just
put
the
some
a
lot
of
image
registration
here,
but
you
can
always
customize
with
your
own
preferred
registries
alright,
and
we
have
this
for
their
action
flex
at
the
key
Renault
policy
to
enforce,
which
means
for
the
incoming
request
if
the
resource.
Well,
it's
the
policy.
The
creation
will
be
blocked
by
this
by
this
criminal
policy
and
on
the
right
hand,
side
of
my
terminal,
you
can
say
I-
have
as
a
whole
part
here
which
is
not
coming
from
the
allowed
allowed
registries
I
defined.
C
So
if
you
create
the
resource,
Colonel
would
block
the
creation
all
right.
Let's
first
apply
the
policy
to
your
cluster.
You
can
do
coop,
cuddle,
crate
after
misty
manifest
strict
image.
Registries,
don't
yamo
all
right,
then
the
I
think
the
pause
is
credit.
If
you
want
to
check,
you
can
do
cook,
auto,
get
clustered
policy,
and
then
you
will
have
the
list
of
the
policies
exist.
Right
and
I
already
have
a
few
were
close
running
in
my
cluster.
C
C
It's
saying
that
which
rule
is
violating
the
policy.
You
can
get
the
detailed
information
on
this
violation,
and
this
is
the
resource,
and
here
is
the
policy
right.
So
this
is
how
Kira,
no
policies
can
validate
your
existing
configurations,
but
now,
let's
take
a
look
at
if
you
create
a
new
resource,
wouldn't
happen
so,
as
I
show
to
you,
I
have
a
simple
pot
which
is
violate
the
policy
if
I
do
cookware.
Oh
great,
that
part.
C
Llamo
since
I
have
the
feather
action
set
to
enforce,
you
can
see.
The
creation
is
the
immediately
blocked
by
Kira
Nova
book,
and
this
is
why
we're
blocking
it
right.
So,
if
you
don't
want
make
your
policy
a
hard
rule,
you
can
always
edit
your
failure
action.
So
here
you
have
a
policy.
Let's
get
the
name
of
the
policy.
You
can
say.
Coop
cutter
will
add
it
cluster
policy
with
name
I'm,
going
to
change
this
trailer
action
into
audit.
So
that
means
it
will
not
block
the
resource
creation,
but
to
report
as
a
violation.
C
Let's
save
and
exit
and
then
let's
try
to
create
the
originals
again
okay,
so
this
time
you
can
see
the
Christian
is
allowed.
But
if
you
check
policy
violation,
you
will
get
one
more
which
is
created
on
the
pod,
be
justified
okay.
So
this
is
the
first
example:
I'm
gonna
I
have
to
validate
the
configurations
and
next
let
me
hand
off
to
Jim,
to
talk
about
the
pot
security.
B
Alright,
thank
you
yeah.
So
in
this
next
section
we'll
cover
you
know
what
key
burner
can
do
to
help
with
pots
security
itself
right
and,
as
everyone
probably
knows
or
should
know,
if
you're
running
kubernetes
in
production
is
pot,
security
and
configuring,
you
know,
runtime
security
is
very
essential.
However,
PSPs
pod
security
policies,
which
are
a
beta
feature
in
kubernetes,
are
difficult
to
configure.
They
have
some.
B
You
know,
entrance
problems
in
their
design
layer,
the
authorization
model
and
also
are
very
you
know,
or
almost
impossible
to
roll
out
on
a
production
cluster
without
impacting
the
production
workloads.
So
because
of
this,
you
know
pod
security
policies.
Psps
are,
you
know,
scheduled
to
be
deprecated
and
the
the
discussions
going
on
in
the
community.
There
is
a
proposal
for
pod
security
profiles,
so
we
definitely
recommend
if
you
know
for
folks
more
interested
in
this.
B
B
B
Yes,
so
some
examples,
your
you
know,
things
like
you
know
which
are
in
the
restricted
level
to,
for
example,
to
disable
privilege
escalation
to
require
you
know.
Read-Only
file
route
file
systems,
like
we
looked
at
in
a
previous
example,
disallow
use
of
host
file
systems.
Those
are
types
of
things
you
would
want
to
check
for
as
part
of
the
different
levels
so
Kyra
already
has
about.
B
You
know
15
to
20
best
practice,
policies
defined
which
are
in
the
git
repo,
and
we
will
you
know
we
will
continue
to
expand
the
available
best
practices
to
match
the
pod
security
profile
definitions.
So
basically
you
to
be
able
to
use
governo
to
be
able
to
audit
and
make
sure
that
your
pods
are
configured
at
the
right
security
level
for
your
cluster.
C
Alright,
so
for
the
demo
for
the
pod
security
context,
I
have
a
validate,
but
before
I
jump
to
the
example,
I
want
to
bring
up
a
use
case
and
the
problem
when
you're
using
the
passive
carry
policy.
The
operators
typically
want
the
policies
to
apply
to
all
parts,
independent
of
which
controller
crates
them.
So
the
best
way
best
practice
is
to
write
the
policy
at
the
pot
level.
C
But
the
problem
here
is
that
the
pot
are
typically
created
by
park
controllers,
so
the
error
recording
at
the
pool
controller
level,
for
example,
that
deployment
will
provide
you
a
better
user
experience.
As
you
will
know,
the
response
immediately
back
right,
and
so
the
proposed
solution
in
kernel
is
to
generate
auto,
generate
the
power
controller
policies
from
the
rules
that
are
defined
on
part
and
this
Auto
generator
is
enabled
by
default,
and
you
can
always
managed
by
the
annotation
to
either
disable
it
or
to
customize
your
or
to
define
with
your
customized
power
controllers.
C
Okay,
so
the
demo
I
have
for
this
is
to
validate
the
past
security
pub
contacts,
as
you
can
see
here,
I
have
a
validation
rule
applied
to
pod
and
I'm
in
trying
to
validate
the
security
contacts.
This
one
as
non-root,
set
to
true
both
at
the
either
at
the
top
level
or
inside
the
container
so
keeper
know,
has
this
anti-pattern
block
defined,
which
allows
user
to
define
multiple
patterns
right
and
also
here.
C
The
further
action
is
that
to
enforce,
and
then
I
have
this
annotation
to
say
that
I
want
to
auto
jet
I
want
Komuro
to
auto
generating
an
additional
rule
on
the
deployment
itself
right
on
the
right
hand,
side
of
my
screen
I
have
a
simple
deployment.
So
since
I
have
the
figure
actions
that
to
enforce
I
would
expect
Kira
know
to
block
my
resource
creation
immediately,
as
you
can
see,
I
have
I.
Don't
have
this
security
contacts
out
here?
C
Alright
remember:
I
only
have
one
rule
deport
defined
on
the
part,
but
in
this
case
Kiran
is
also
generally
the
rules
to
the
deployment,
and
we
have
the
prefix
oto-chan
to
indicate
its
generate
like
urinal,
and
you
can
see
in
the
spec.
The
contacts
is
converted
to
the
pot.
Template
stack
alright,
so
let
me
create
the.
Let
me
try
to
create
a
deployment.
I
would
expect
it
at
this
case,
Ximena
will
block
the
deployment
creation,
the
disallow
user
resources
right.
So
you
see
the
the
rule
on
deployment
is
actually
blocking
the
resource
creation.
C
C
C
B
Okay,
before
we
move
to
that,
there
was
a
question
in
the
Q&A
panel
on
port
security
policies
and
to
clarify
whether
caverna
will
replace
or
can
replace
PSPs.
So
the
the
intent
is
that
for
caverna
to
support
the
different
pod
security
profiles
that
we
quickly
demonstrated
and
showed
so
based
on
the
different
profile
levels
you
want
to
configure
for
your
cluster
governo
will
be
able
to
validate
and
provide
checks
for
those
in
terms
of
migrating
from
you
know,
PSPs
to
karana
policies
we
are
thinking
about.
B
You
know
whether
we
can
write
a
tool
to
actually
generate
cabrona
policies
because
they're
just
yeah,
molds
and
resources.
You
know
whether
we
can
generate
these
directly
from
PSPs.
That's
something
that's
being
discussed,
but
it's
not
something
we
have
committed
to,
but
happy
to.
Of
course,
if
there's
some
ideas
or
folks
want
to
contribute
to
that,
you
know
happy
to
do
that
in
the
context
of
our
project.
B
There's
also
another
question
on
whether
cavernosa
ports
sending
logs
or
enforcement
events
to
centralized
you
know
security
tools,
so
caverna
produces
policy
violations
as
shooting
showed
as
resources,
so
these
can
be
collected
by
any
anything.
That's
you
know
plugged
in
into
the
API
server
or
any
tool
that
can
you
know,
get
kubernetes
resources.
B
So
certainly
you
could
write
tools
which
will
receive
events
on
resources
on
given
our
policy
violations
that
and
as
you're
watching
those
these
can
be
then
shipped
off
to
a
central
logging
system,
as
required
you,
okay,
so
let's
dive
in
into
the
next
section
where
we're
gonna
cover.
You
know
what
kvarner
can
do
to
generate
configurations
right.
So
first,
let's
discuss
or
lets
you
know
frame
the
problem
that
we're
trying
to
solve
here
so
typically
in
kubernetes
when
you're
creating
a
resource
or
an
object.
B
You
know
that
resource
gets
created,
but
there
might
be
some
supporting
resources
around
it
that
also
need
to
get
configured
so
one
one
great
example
of
this
is
with
namespaces.
So
when
you
create
a
namespace,
perhaps
for
a
team,
perhaps
for
a
new
user
in
within
a
cluster,
you
may
also
want
to
create
things
like
roles
and
role
bindings
for
the
namespace
owner.
B
You
may
want
to
set
up
a
default
Network
policy,
which
is
a
good
best
practice
and
starting
with
something
like
denial
and
then
letting
the
namespace
owner
add
you
know,
constructs
or
allow
different
ingress
or
egress
rules
for
their
workload,
and
you
probably
also
and
again,
none
of
the
best
practices
to
set
up
a
quota
for
that
namespace
itself.
So
things
like
this,
you
want
to
generate
when,
as
soon
as
the
namespace
is
created,
there's
other
examples
where
you
might
want
to
generate
some
defaults
too.
B
So,
let's
give
our
node,
there
is
a
generate
rule
within
policies
that
you
can
use
and
the
way
this
works
is.
It
can
either
generate
configurations
based
on
an
existing
resource
so
based
on
an
existing
network
policy
that
you
have
in
your
cluster,
so
you
can
create
a
clone
of
that
or
you
can
copy
inline
data.
B
C
Sorry,
I'm,
a
mute
and
so
for
the
generate
policy
I
have
for
today.
I
have
two
policies,
and
the
first
one
is
what
Jim
has
showed
is
a
general
policy
which
triggers
on
the
namespace
creation
and
it
is
to
generate
the
default
network
policy
into
your
new
class.
New
namespace
and
the
second
general
policy
is
more
advanced
policy
that
is
to
achieve
like
to
grant
the
some
permissions
to
a
user.
C
So
in
my
setup,
I
have
created
a
user
job
which
only,
who
only
has
the
permission
to
create
the
namespace,
but
once
the
namespace
is
created,
this
generate
policy
will
create
a
cluster
role
here
and,
it
is
to
say,
I
want
grunts
John,
this
user
John.
This
is
the
delete
permission
for
namespace
for
the
targeted
namespace,
so
that
John
should
be
able
to
delete
the
new
created
namespace
and
the
second
rule
is
just
the
class
or
Oh
binding
which
binds
to
the
above
classroom
and
the
following.
C
Rules
of
this
January
policy
is
to
grant
John
the
attendant
where
the
namespace
anim
admin
role
to
user
John.
So
here
you
can
see
I
have
a
class
or
Oh
binding,
which
binds
to
the
class
or
role
admin
and
also
I
have
the
class
or
binding
to
go
into
the
edit
and
the
Vale
role.
So
in
this
case,
after
the
generate
policy
is
applied,
the
drop
this
user
John
will
have
the
namespace
access
or
the
will
become.
C
C
Okay,
so
let's
check
what
fermentation
John
has
picado
off
I'm
doing
a
coop
cutter,
as
can
I
Lee
East
and
twist
this
flag
asks
I'm,
saying
that
I
want
to
check
user
transformation.
C
C
C
Can
I
list
yes
John
now
you
can
see.
John
has
a
bunch
of
more
informations
and
the
one
we're
looking
for
a
particular
as
to
is
this
delete
formation
of
this
demo
namespace
right
so
now,
basically,
John
becomes
the
administrator
of
this
name
of
this
demo
namespace
and
if
you
want
to
further
and
verify
let's
Cupido
can
I
up
update
network
policy
Astro
right,
so
it
returned
yes
and
remember:
we
have
another
policy
to
generate
the
default
network
policy.
That's
verified!
If
that
is
being
created
successfully.
C
B
Yes,
in
the
last
section,
or
what
we
saw
is
how
kvarner
can
generate
new
configurations
based
on
existing
data
or
just
based
on
data
that
you
specify
in
your
policy.
But
what
you
probably
are
wondering
is
this
from
that
demo
is
now
that
you
know.
Let's
say
in
that
example:
John
was
the
owner
of
the
namespace.
They
have
access
to
all
of
the
objects
in
the
namespace.
What's
preventing
you
know
that
user
from
just
deleting
Network
policies
and
things
like
that
which
were
set
up
by
the
administrator
right.
B
So
that's
one
example
where
kubernetes
our
back
is
not
sufficient.
There
are
several
other
examples
that
you
know
we're
seeing
in
different.
You
know
different
real
world
examples.
Where
we're
you
know
our
back
operates
on
objects
with
n
as
well
as
API
requests,
but
that
sometimes
you,
what
you
want
to
do
is
specify
rules
which
can
be
applied
to
specific
namespaces.
Specific
users
object
types
things
like
that
which
cannot
be
covered
with
the
standard,
are
back
definitions
right.
So
in
this
case,
governo
can
help
and
we'll
take
a
look
at.
B
You
know
new
construct
that
we
have
introduced
with
relief
candidate.
One
one
six
where
what
kvarner
does
is
introduces
a
new
type
of
validation
rule
which
simply
denies
based
on
certain
conditions.
So
in
this
example,
what
we're
looking
at
is
if
your
resource
has
a
particular
label
and
in
this
case
the
label
happens
to
be
managed
by
key
brno.
So
it's
one
of
these
resources
generated
by
Kivar
know
what
you
can
do
is
you
can
then
prevent
certain
operations
from
being
applied
to
that
resource
right
so
again,
in
this
example,
we're
saying
the
request
operation.
B
So
that's
looking
up
the
admission
request,
looking
at
the
data
and
saying
the
operation
here,
if
it
equals
delete,
prevent
that
notice
that
we
also
have
added
an
exclusion
because
of
course
you
don't
want
to
prevent
everybody
from
this.
So
you
want
to
make
sure
that
your
cluster
admin
can
still,
you
know,
operate
on
that
and
can
still
perform
the
action
required,
but
the
admin
user
role
that
we
software
in
the
previous
example
should
be
blocked
by
this.
C
Okay.
In
the
last
generate
example,
what
I
have
shown
you
is
to
make
John
as
a
namespace
owner
or
the
namespace
administrator,
so
that
means
strong
can
basically
do
everything
within
the
namespace,
and
here
you
can
see
if
I
check
the
permission
on
update
the
network
policy.
It
returns
me
yes
right
so,
but
if
I
have
the
policy
denying
policy
critic
to
the
cluster,
which
means,
if
John
trying
to
update
the
network
policy,
we're
going
to
reject
that
update
request.
So
let
me
create
the
policy
first.
C
C
C
Okay,
so
you
see
the
response
that
this
a
big
request
is
blocked
with
this
policy
and
there
are
actually
two
routes
are
blocking
the
crust
right.
So,
let's
check,
if
I'm,
updating
this
label
with
the
cluster
at
noon,
you
see
the
label
is
inserted
successfully,
so
missed
89
policy.
Basically
you
can.
She
achieved
fine-grained
access
control
beyond
what
kubernetes
auerbach
this
alright.
B
B
So
you
can
start
with
like
an
auditing
mode,
see
where
you
might
have
some
problems
with
existing
workloads
and
then
slowly
migrate
to
enforcing
these
checks.
Caverna
also
supports
you
know
best
practices
for
pot
securities.
It
has
powerful
features,
like
you
know,
automatically
generating
rules
or
applying
rules
on
controllers
which
again
because
it's
native
to
kubernetes
it
allows
that
type
of
you
know
for
a
good
user
experience
for
kubernetes
administrators
as
well
as
end-users,
and,
as
you
saw
in
the
demos,
it's
extremely
simple
to
use
it
takes.
B
A
B
Yes,
oh
speaking
of
new
features,
we
saw
the
generate,
you
know
in
the
generate
policy
rule
in
action,
so
one
one
feature
request
that
we
have,
which
we
are
working
on
is
not
only
to
be
able
to
generate
configurations
but
to
keep
configurations
in
sync
with
the
source
right.
So
imagine
like
if
you
have
a
set
of
namespaces
that
you
want
to
manage,
or
if
you
just
have
some
common
configurations
that
you
want.
But
now,
if
you
change
that
common
configuration,
you
also
don't
want
all
the
generated
resources
to
be
updated.
B
So
that's
the
use
case
that
the
generate
and
sync
you
know
will
will
handle.
There's.
Also
another
important
you
know
feature
so
today.
Caverno
operates
an
admission
requests
and
can
look
at
any
data
within
the
admission
requests,
including,
as
we
saw
user
information
as
well
as
the
resource
information
in
the
admission
request,
but
another
use
case
to
extend
on
that
is
how
do
you
you
know
if
you
want
to
look
up
things
from
your
cluster?
If
you
want
to
check
things,
for
example,
you
know
what's
configured
and
then
make
a
decision
within
a
validation
rule.
B
That's
where
you
want
to
run
a
query
on
an
existing
resource,
so
Kevin.
Oh,
can
you
know
we'll
be
able
to
support
that
through
even
things
like
config
Maps,
so
this
allows
you
to
do
you
know
more
powerful
variable
substitution,
but
also
be
able
to
look
up
other
resources
through
jmes
path
like
syntax,
which
governor
supports
today
for
conditions
and
then
finally
adding
more
operations,
more
operators
like
even
doing
reg,
X
type
matching.
B
So
again,
the
philosophy
here
is
read,
you
know
we're
not
inventing
any
new
language
or
any
new
way
of
doing
things,
but
using
standard.
You
know
best
practices
widely
adopted
tools
like
jmes
path
for
JSON
processing
as
well.
As
you
know,
and
overlay
like
syntax,
like
you
saw
with
some
of
the
policies
itself.
C
Right
and
we'd
love
to
hear
any
feedback
from
you
or
the
use
cases
you
want
us
to
support,
feel
free
to
open
up
and
feature
requests
on
our
github,
repo
and
I'll.
Let
let
me
quickly
navigate
and
you
can
see
here's
the
basic
introductions
and
we
have
the
example
policies
and
even
more
like
on
how
you
getting
started.
C
This
kubera
know
how
you
write
the
policies
so
feel
free
to
check
it
out
and
if
you're
interested
or
you
want
to
discuss
with
us,
feel
free
to
join
this
like
channel
and
we're
also
planning
on
hosting
monthly
community
meeting,
so
that
we
can
give
you
the
community
quick
update
on
Kieran,
oh
and
maybe
the
demos
of
the
new
features
so
yeah.
Alright,.
B
A
couple
more
questions
in
the
Q&A
panel,
so
one
question
was
on
the
difference
between
open
and
and
caverna,
so
I
think
we
covered
a
lot
of
that
as
we
went
along
in
the
presentations
and
the
main
difference
is
how
you're
writing
in
managing
policies,
but
then
also
the
ease
of
use
and
the
fit
into
kubernetes.
So
you
know,
and
of
course,
if
you're
looking
for
a
general
purpose
policy
to
something
like
OPA
works.
B
Well,
if
you're
looking
for
something
community
specific,
you
know
give
given
or
try
and
that
because
it's
designed
for
communities
the
experience
here
is
a
lot
different
and
works
better
for
kubernetes
workloads.
Another
question
was
on,
you
know,
can
caverna
be
used
with
kubernetes
1.14,
and
I
think
we
had
some
issues
with
I'm
trying
to
remember
shooting
if
it
was
1.13
versions
or
so
there
were
some
problems
with
level
configurations.
Do
you
recall
often
which
portion
that
was
right.
C
B
B
Another
question
was
on
for
the
matching
of
resources:
does
it
allow
you
know
for
pods
to
be
selected
in
a
namespace
with
a
precise
label
where
you
don't
know
the
name
of
the
namespace
in
advance,
but
you
know
the
label.
So
yes,
given
our
supports,
you
know
label
selectors,
so
you
can
use
label
selectors.
Even
if
you
don't
know
the
name
of
the
namespace
up
front
and
another
interesting
thing
is
because
give
or
no
you
know
is
policies
are
just
first-class
resources.
You
can
also
generate
very
specific
policies,
as
namespaces
are
getting
created
right.
B
So
if
you
want
a
policy
to
just
apply
on
one
namespace,
when
that
namespace
is
created,
you
can
create
more
qivana
policies
through
a
caverna
policy.
It's
a
little
bit
of
you
know
it's
sort
of
inception
going
on
there,
but
that's
a
powerful
use
case
to
do
very
specific
matching
and
restrict
your
policy
scope.
B
A
We'll
just
give
folks
a
minute
here:
if
there
are
any
last-minute
questions
and
those
are
oh,
oh,
we
got
that
one.
Okay,
okay,
well,
I,
think
those
are
all
the
questions
and
thank
you
again,
shooting
the
and
Jim
for
a
great
presentation
today.
Thank
you
all
for
joining
us
I'd
like
to
remind
you
that
the
slides
and
the
recording
will
be
available
later
today
on
the
CNC
F
website.
We
look
forward
to
seeing
you
at
a
future
CN
CF
webinar
and
have
a
great
day
stay
safe.
Everybody.
Thank
you.
Bye
thanks.