►
From YouTube: OCB - Kyverno: Kubernetes Native Policy Management Ritesh Patel and Jim Bugwadia (Nirmata)
Description
Kyverno is a policy engine designed for Kubernetes. With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies. This allows using familiar tools such as kubectl, git, and kustomize to manage policies. Kyverno policies can validate, mutate, and generate Kubernetes resources. The Kyverno CLI can be used to test policies and validate resources as part of a CI/CD pipeline.
Kyverno is a CNCF Sandbox Project, and in this OpenShift Commons Briefing, Nirmata's Ritesh Patel and Jim Bugwadia will give introduction to the project, a demonstration, walk us thru the road map and answer your questions.
A
B
Hey
folks,
I'm
british
patel
vp
products
and
co-founder
at
nirmata.
B
Right
so,
let's
dive
into.
B
Talk
about
you
know:
kevorno
kivano
is
an
open
source,
kubernetes
native
policy
management
solution.
That's
now
a
cncf
sandbox
project.
So
here's
the
agenda,
we'll
you
know
dive
deeper
into.
Why
kevarno?
What
does
it
solve?
Why?
Why
did
we
feel
there
was
a
need
for
something
like
kiverno
and
then
jump
into
the
technical
details
of
how
it
works.
B
Now
we
do
have
some
use
cases
that
we
can
go
over
to
give
you
folks
of
you
know
an
idea
of
the
kind
of
problems
you
can
solve
using
kvarno.
B
I
will
discuss
some
of
the
other
tooling
around
kubernetes,
which,
more
specifically,
that
nirmata
offers
to
help
help
ease
the
the
you
know:
management
of
kiberno
policies
and
and
reporting,
and
then
jump
into
a
demo,
followed
by
a
quick
roadmap
and
q
a
so
let's,
let's
jump
right
into
it,
kiberno!
Actually,
you
know
you
may
kind
of
wonder
what
what
does
keyword
do
mean
and
kevin
actually
means
governed
it.
It's
a
it's
a
play
on
it's
in
greek.
B
Basically,
it's
governed
and
you
know
obviously
kubernetes
the
origin
of
kubernetes.
The
word
is,
is
from
greek,
so
we
thought
it
would
be
appropriate
to
kind
of
use
kiberno,
as
as
as
as
the
name
of
this
project,
because
kiberno
is
essentially
a
policy
engine
for
kubernetes
and
policy
engine
is
used
typically
to
to
to
govern
or
for
compliance
of
various
aspects
of
of
kubernetes.
B
So
that's
why
the
name
kiwano
kuberno,
the
is
a
kubernetes
native
policy
engine
which
means
that
it
understands
kubernetes
resources,
kubernetes
patterns,
so
it
actually
is
aware
of
of
kubernetes
communities
constructs,
and
it's
been
it's
it's
designed
in
a
way
that
it's
familiar
to
kubernetes
users,
and
essentially
there
is.
There
is
no
learning
curve.
B
So
let's
take
a
step
back
and
understand.
Why
do
we
need
policies
and
kubernetes?
What
are
policies?
And
you
know
how
do
they
help?
So,
if
you're
familiar
with
kubernetes
kubernetes,
you
know
you
can
configure
lots
of
different
resources,
whether
it's
you
know
your
infrastructure
for
kubernetes,
whether
your
app
applications
or
workloads
running
in
kubernetes
and
all
of
the
configuration
is
essentially
done
using
you
know
yaml
right
and
it
gets
fairly
complex.
Some
some
configuration
files
could
could
be.
B
You
know
a
few
hundred
lines
and
and
the
the
challenge
there
is
now.
How
do
you
ensure
that
the
configuration
can
be
managed
and
is
secure?
There
are
also
you
know,
external
tools
that
that,
for
example,
helm
and
customize
that
tweaked
existing
configuration
to
adapted
to
environments.
B
So
that's
what
that's,
how
your
configuration
could
change
the
the
the
end
configuration
that
ends
up
in
the
cluster
may
be
different
from
from
the
source,
depending
on.
Where
is
where
your
your
resources
are
deployed,
so
you
know
in
kubernetes
there
is,
there
are
ways
to
to
configure
admission
controllers
and
that's
where,
as
a
best
practice,
a
lot
of
the
validation
for
configuration
as
well
as
any
modification
or
mutation
of
configuration
can
happen,
and
that's
that's.
B
Why
that's
the
kind
of
the
best
place
where
policies,
if
any,
can
be
or
should
be
applied?
So
what
what
kiwano?
What
policies
do
is?
Essentially
let
you
govern
or
or
ensure
that
the
configuration
that's
being
you
know
applied
to
kubernetes
is
secure.
B
It
follows
your
best
practices,
you
know
follows
the
standards
and,
and
kiberno
is,
is
an
engine
which
does
that
without
the
user
or
the
developer
or
the
cluster
operator
having
to
build
something
from
scratch
or
build
something
custom
for
their
environments.
B
B
So,
given
the
policies
are
declarative
and
very
easy
to
manage
the
and
and
when
these
policies
are
applied,
they
generate
policy
results.
Basically,
these
are
you
know,
violations
or
any
kind
of
any.
You
know
any
policies
that
are
violated
kind
of
are
reported
in
in
the
results,
so
that
it's
also
is
kubernetes
native.
These
policies
are
can
be
of
different
types.
You
know
you
could
have
a
validating
policy
which
can
either
be
in
audit
mode
or
an
enforced
mode
or
or
they
could
actually
mutate.
B
An
existing
configuration
by
you
know
changing
parts
of
parts
of
the
configuration
or
they
could.
The
policy
could
generate
new
configuration
if
it's,
if
in
cases
where
this
configuration
is
required
or
it's
it's
missing,
and
that
gives
you
a
lot
of
flexibility
to
kind
of
ensure
that
the
configuration
of
your
kubernetes
applications
and
resources
are
configured
correctly.
B
The
being
kubernetes
native
kiberno
supports
all
of
the
kubernetes
resource
types
and
can
also
support
custom
resources
right
so,
which
is
a
huge
benefit
so
that
you
know
now.
You
can
use
cuban
across
the
board
without
having
to
worry
about
which
resources
are
supported
and
which
are
not,
and
you
know,
being
again
being
kubernetes
native
kiberno
leverages
and
understands.
You
know
some
of
the
common
patterns
used
in
kubernetes,
like
label,
selectors
tables
and
selectors
annotations,
owner
references
and
and
and
things
like
that
right.
B
So
that
really
makes
it
very
easy
for
somebody
to
to
you
know,
start
with
kiwano
and
start
using
it
with
kubernetes.
B
Now,
just
a
little
bit
of
background
on
the
project
itself.
So
cubano
today
is
an
open,
is
open
source
and
a
cncf
sandbox
project
it
it
got
the
it
was
added
to
sandbox
projects
in
november
last
year
and
since
then,
we've
been
tracking
the
downloads,
and
it's
almost
approaching
two
million
downloads
in
you
know
about
three
and
a
half
months
right,
which
is
which
is
huge
it.
It
went
to
one
million
downloads
about
three
or
four
weeks
ago,
and
now
we
are
almost
there
at
two.
B
You
know
two
million
downloads.
So
seeing
a
lot
of
you
know
interest
in
the
community.
B
You
know
a
lot
of
folks
are
looking
at
it
and
and
like
the
simplicity,
ease
of
use
of
kubernetes
and
and
then
there
are
other
projects
in
in
cncf
and
in
the
community
like
open
policy
agent
which
which
which
do
policy
management,
but
cuberno
kind
of
because
of
its
simplicity,
has
been
gaining
a
lot
of
a
lot
of
interest
and
and
a
lot
of
users
so
definitely
do
check
it
out.
B
If
you
know
you're
interested
so
question,
when
we
talk
about
kubernetes
question
that
comes
up,
is
you
know
how
is
given
or
different
from
open
policy
agent?
And
here
are
some
points
of
differentiation.
You
know
open
policy
agent
was
was
actually
predated.
Kubernetes
was
built
as
a
general
purpose
policy
engine
and
then
adopted
or
adapted
to
kubernetes,
whereas
cuberno
itself
is
designed
for
kubernetes.
B
B
There
is
a
project
called
gatekeeper
which
which
works
or
integrates
with
open
policy
agent
that
simplifies
or
that
tries
to
adapt,
kubernetes
resources
and
and
to
define
policies,
but
ultimately,
the
underlying
enforcement
and
all
the
all
of
the
the
policy
processing
everything
happens
based
on
in
based
on
policies
written
in
rego,
also,
a
few
other
things
about
kiberno,
which
are
not
necessarily
available
or
possible
with
opa
oppa
gatekeeper.
B
So
kiwano
is,
is
you
know,
secure
by
default?
You
don't
need
to
call
out
any
external
systems
for
any
processing,
and
you
know
because
it's
an
admission
control
path.
This
is
very
important
and
also
a
few
other
scenarios
that
kiwano
enables
are
around.
You
know
just
a
noun
kind
of
the
if
this
is
in
that
paradigm,
where,
if,
if
you
s,
if
a
particular
configuration
you
know,
if
you
check
for
a
particular
configuration
and
if
it
exists,
you
can
actually
write
policies
to
do
certain
things.
B
These
are
very
easy
to
do
in
kubernetes
and
being
kubernetes
native
and
given
the
policies
are
also
kubernetes
native.
It
lends
itself
very
well
to
tools
like
you
know,
customized
helm,
and
can
you
you
can
use
githubs
to
actually
apply
policies
across
your
clusters,
so
really
just
in
a
nutshell.
There
are
several
benefits
that
that
you
get
with
kiwano
in
terms
of
ease
of
use,
as
well
as
the
other
capabilities.
B
Let's
dig
a
little
bit
deeper
in
in
terms
of
you
know,
at
a
high
level,
from
from
the
policy
perspective
for
kubernetes
and
we'll
go
a
little
bit
more
details
into
how
current
policies
are
defined,
but
here
this
is
just
to
show
it
if
kind
of
the
difference
between
given
cubano
and
oppa.
On
the
left-hand
side,
you
see
the
kubuna
policy,
which
is
you
know
if
you
are
familiar
with
kubernetes
and
have
used
kubernetes
resources
like
deployment
spots.
This
will
be
very
familiar
to
you.
B
It's
very
you
know
straightforward
in
terms
of
writing
these
policies.
There
are
certain
keywords
like
match
and
validate
and
we'll
talk
about
those
a
little
bit
later,
but
overall
in
this
policy
just
validates
and
checks.
If
you
know
the
file
system
is
read
only
on
the
right
hand,
side,
you
see
the
same
policy
written
in
in
indigo,
and
this
is
this
would
be
something
that
you
would
use
in
oppa.
So
this
will
just
quickly
show
slight
difference
between
kiwano
and
and
oppa.
B
So
next
we'll
talk
about
how
kiwano
works
I
mentioned
earlier.
Kimono
is
a
policy
engine
that
runs
inside
the
cluster
and
it
registers
you
know
as
an
admission
controller
and
then
it
every
request
that
comes
in
through
the
api
server
is
is
processed
through
kiberno
and
the
policies
that
are
configured
in
in
kiberno
are
applied
to
to
these
requests.
B
So
it
kiwano
gets
an
admission
review
request.
It
applies
these
policies,
the
policies,
depending
on
on
the
configuration,
may
generate
certain
events
or
a
policy
policy
violation,
and
then
the
response
is
sent
back.
If
the
policy
is
configured
as
as
audit
only
then
it's
clearly
the
the
it's
just
in
a
kind
of
like
a
report-only
mode
and
there's
no.
B
The
request
itself
is
not
blocked,
but
if
the
policy
is
configured
as
as
as
a
you
know,
to
configure
to
validate
and
block,
then
the
the
request
can
also
be
blocked
if
the
earth
the
policy
fails.
So
this
is
really
at
a
high
level
how
kubernete
works
in
kubernetes.
B
B
You
could
use
label
selectors,
namespace
selectors,
as
well
as
user
roles,
groups
and
so
on,
and
then
you
have
the
the
the
various
actions
that
cubano
that's
either
validate
mutate
or
generate
so
so
these
are
the
high
level
blocks
and
we'll
talk
about
each
of
these
blocks
in
the
next
few
slides
just
to
map
the
the
the
structure
we
saw
earlier
here
we
have
the
same
kind
of
the
kubernetes
policy,
showing
the
same
structure
where
you
have
on
the
top
line
number
eight.
B
We
have
the
the
match
block
where
in
this
case
it's
matching
all
resources
of
kind
pod
and
then.
D
B
Line
number
12
we
have
validate
block,
which
actually
does
the
you
know,
does
the
validation
for
the
for
every
port,
and
in
this
case
it
checks
if
the
security
context
run
as
non-root
etc.
B
So
validate
policy
is
essentially
it
kind
of
matches,
the
fields
that
are
defined
in
the
validate
block
and
and
determines.
If,
if
your
configuration,
you
know,
matches
the
matches
of
fields
and-
and
you
know
it
is
it's
validated
for
it-
validates
the
configuration
by
matching
all
of
the
fields.
So
in
this
case
you
could
have
patterns,
you
can
match,
you
know
for
existence
of
fields
you
can
match,
for
you
know
with
operators
you
can
have
you
can
check.
B
If
values
is,
you
know
greater
than
equal
to
or
not
equal
to,
so
a
lot
of
the
there's
a
lot
of
flexibility
in
terms
of
doing
various
types
of
matching
in
in
in
these
policies,
in
the
backwards
for.
B
So,
for
example,
here,
if
you
want
to
let's
say,
add
a
port
or,
or
you
know,
insert
like
a
secret
name,
you
can
do
that
by
specifying
the
patch
in
the
policy,
and
you
can
even
do
that
conditionally.
So
you
can.
Even
you
can
only
add
a
configuration
if
it's
not
there
or
if,
if,
for
example,
you
can
even
have,
if
then
condition
where,
for
certain
port
names,
you
can
use
forces
for
certain.
Only
if
port
names
start
with
certain
string,
you
can,
you
know,
add
the
add
the
value
and
so
on.
B
So
this
gives
you
again
a
lot
of
flexibility
to
to
manipulate
incoming
incoming
configuration
and
it's
actually
very
important.
There
are
use
cases
where
you
know.
If
you
want
to
add
certain
labels
on
on
every
resource
or
or
on
specific
resources,
you
can
now
ensure
that
that's
done
by
creating
a
mutate
policy
a
lot
of
times.
These
labels
could
be
used
by
other
tools
for
security,
for
networking,
for
monitoring
and
so
on.
B
So
so
you
know,
given
through
mutate
policies,
allows
you
to
address
some
of
those
use
cases,
and
then
the
the
final
type
of
policy
is
a
generate
policy
where
you
can
actually
generate
certain
resources,
so
so,
on
the
the
example
here,
on
the
right
hand,
side
kind
of
shows
how
you
can
generate
a
network
policy
to
deny
all
traffic.
This
could
be
your
default
network
policy
for
your
name
space,
and
it
can,
you
know
it
would
be
created.
B
Maybe
anytime,
a
new
namespace
is
created,
so
there
is
a
usually
a
trigger
which
can
trigger
the
generate
of
of
these
these
resources.
In
this
case,
we
get
generating
a
network
policy,
and
it
could
also
you
could
use
to
clone
existing
resources,
and-
and
this
essentially
allows
gives
you
flexibility
to
ensure
that
you
know
certain
required
resources
like
network
policies,
quotas
limits,
things
of
that
sort
are
always
available
in
your
in
your
cluster
or
for
your
applications.
B
When
these
policies
are
configured
once
these
policies
are
configured
and
and
as
they
are
processed
based
on
based
on
incoming
requests,
there
are
violations
that
that
can
be
generated.
So
here
is
an
example
in
kubernetes
to
see
the
policy
result.
So
on
the
top,
you
see
an
example
of
showing
the
on
of
the
policy
results
for
a
particular
namespace
in
this
case
default
namespace,
which
shows
that
you
know
nine
policies
were
passed
and
one
failed
and
you
can
get
get
more
granular
details.
B
B
B
So
this
was
a
quick
overview
of
some
of
the
features
that
there's
lots
of
advanced
features
that
are
being
built,
and
you
know
this
is
an
ongoing
kind
of,
as
community
comes
up
in
more
use
cases
we're
building
more
and
more
features.
B
So
we
talked
a
little
bit
about
you
know
some
of
the
anchors
operators,
like
you
know,
compare
competitors
and,
and
if
then
else
and
so
on,
you
can
also
have
variables.
You
can
actually
point
to
certain
certain
parts
of
your
config
using
jmes
path.
James
pat
and
you
can
also
look
up
data
external
data,
you
know
from
from
config
map
or
through
api
calls,
and
this
let's
this
allows
you
to
kind
of
and
check
or
trigger.
You
know,
violations
by
checking
data
that
may
not
be.
A
B
Of
the
incoming
request
and
or
part
of
part
of
the
the
resource
configuration
you
can
also
set
up
deny
rules.
One
thing:
that's
interesting
is
auto
generation
of
partner
controller
rules.
So
if
you
have
policies
for
parts
they
automatically
get
applied
to
port
controllers,
like
deployments,
stateful
sets
jobs
and
so
on,
and
then
finally,
kuberno
can
also
be
run
in
offline
mode.
B
So
if
you
don't
there's
a
command
line
for
qrno
which
can
be
used
offline
so
that
you
can
actually
check
check
for
violations
in
your
configuration
if
it's
in
gate-
or
you
know,
before
your
config
check,
for
your
violation
before
your
configuration
is
applied
to
to
your
cluster.
So
that's
definitely
useful.
You
know
you
want
to
don't
want
to
wait.
Till
till
the
configuration
is
in
your
cluster
to
check
you
can
check
up
front
address
those
issues.
Applying
your
resource
changes
to
your
cluster.
B
B
B
There's
also
kubernetes
enables
you
to
find
gray
and
r
back
so
based
on
you
know,
for
example,
when
namespaces
are
created,
you
can
also
create
some
of
the
roles,
role,
bindings,
etc,
depending
on
the
namespace
name
or
labels,
or
any
other
criteria.
B
Kubernetes
enables
multi-tenancy
in
in
kubernetes
again
through
some
of
the
automation,
by
generating
our
back
rules
by
generating
network
policies
can
generate
quotas,
and
you
know
we're
also
working
with
various
stakes
to
kind
of
enable
this
enable
more
secure
multi-tenancy
across
within
within
kubernetes.
You
know
for
for
your
applications.
B
Auto
labeling
is
a
use
case.
We
talked
about
earlier.
Also.
First,
we
are
seeing
patterns.
Like
you
know,
side
cars
being
used
in
for
various
various
tools
like
you
know,
for
for,
for
example,
for
service
management
or
sidecar.
It's
very
common
to
use
side
cars.
There
are
other
scenarios
like
if
you
want
to
mount
certificates
or
or
if
you
want
to
you
know
fetch.
You
know
continuously
fetch
data
from
some
v.
B
Some
end
point
for
things
like
that:
you
know
side
cars
are
being
used
like,
for
example,
even
for
you
know,
wall
certificates
and
so
on,
so
kiwano
also
can
can,
because
it
can
mutate
existing
interpretation.
You
can
create
side
cars
using
kibana,
so
you
don't
have
to
write
a
new
operator
to
do
that
and
then,
finally,
you
can
have
very
conditional
rules
like
if
this
and
that
for
kubernetes
and
that
opens
up
a
whole
set
of
use
cases.
B
And
you
know
we're
happy
to
kind
of
if
you
have
other
use
cases
that
we
have
not
covered
or
we've
not
seen,
be
great
to
hear
about
those
and
see
how
we
can
help
with
using
your
name.
B
One
area
where
you
know
we
really
see
a
lot
of
interest
today
is
around
you
know:
pod
security
in
the
past
bot
security
policies
have
been
defined
using
psps,
but
psps
have
been
marked
for
deprecation
by
by
the
community,
and
there
are
other
options
on
alternatives
being
discussed,
and
we
are
part
of
those
discussions.
B
But
today,
if
you
want
to,
if
you
are
interested
in
in
the
port
security
policies,
kiberno
provides
a
very
easy
way
of
of
achieving
that.
We
already
have
a
set
of
policies.
You
know
in
our
on
the
kubernete
website
on
the
in
which
kind
of
address
all
of
the
requirements
of
you
know
for
for
part
security,
and
they
are
based
on
on
levels.
B
You
know
like
we
like
the
like,
psps
and
and
some
of
the
discussions
that
are
happening
in
the
community,
so
it
would
be
all
it
should
if
you're
interested
in
alternatives
to
psps.
For
while
you
know
communities
working
on
you
know
the
next
iteration
of
psp,
it
would
be
great
to
check
out
kiwano,
and
let
us
know
if
that
addresses
the
security
needs.
B
So
before
we
jump
into
the
demo,
the
one
thing
I
want
to
quickly
touch
on
is
you
know,
as
as
cuberno
gets
used
in
kubernetes
and
it's
as
it's
more
white
widespread.
B
You
know
we're
seeing
some
requirements
around
managing
policies
at
scale
across
clusters
across
multiple
clusters,
ensuring
you
know,
consistent
deployments
and
and
so
on,
and
so
we've
created.
You
know
a
cloud-based
solution
at
nermata
to
help
manage
policies
at
scale.
So
through
nirmata
you
can
actually
deploy
policies
across
clusters.
You
know
using
githubs,
but
there's
concept
of
policy
groups.
B
You
can
define
different
policy
groups
like
say
for
port
security
or
for
multi-tenancy,
and
then
these
groups,
these
policy
groups,
can
be
applied
either
automatically
to
new
clusters
or
they
can
apply,
be
applied
to
specific
clusters.
B
So
you
can
manage
it
very
easily
instead
of
having
to
deal
with
each
cluster
individually
right
and
then
the
ongoing
challenge
of
keeping
your
policies
up
to
date
and
automating.
That
deployment
can
also
happen.
B
You
know
very
easily
with
with
the
our
integration,
with
kimono,
with
the
integration
of
pneumatic
one
and
then
q1
generates
a
lot
of
violations
right
so,
depending
on
the
size
of
your
clusters
and
the
number
of
pods
and
the
number
of
applications
running
you
could
have
tons
of
you
know:
policy
violations,
failures
and
so
on
and
policy
reports
are
available
in
the
cluster.
B
But
through
our
integration
with
kimono
through
you
can
actually
get
a
very
granular
report
of
of
the
violations
and
not
just
get
the
report,
but
then
also
understand
what
the
what
the
problem
is
and
then
you
know
either
get
get
help
on
remediating
that
problem
or
filing
you
know
the
tickets
to
kind
of
get
that
problem
immediate,
you
know
from
the
application
owner
and
so
on.
So
through
the
integration
we
complete
the
the
full
life
cycle
and
of
managing
kubernetes
policies
and
and
getting
visibility
into
kubernetes
violations.
B
Next,
we'll
jump
into
the
demo,
so
I'll
stop,
sharing
and
let
jim
take
over
from
here.
C
C
C
All
right
is
my
screen
being
shared
or
not
yet.
A
Not
yet,
let's
see
what's
what's
going
on
here
and
no
worries,
I
can
edit
this
little
segway
out.
If
we
use
the
video-
and
here
we
go
okay,
perfect
now,
I'm
seeing
a
black
screen
with
your
recycle
bin.
C
C
We'll
look
at
you
know
like
ritesh
mentioned
pod
security
policies
get
a
lot
of
attention.
So
we'll
start
with
those
see
what
kiberno
can
do
in
that
area
and
then
also
look
at
some
more
advanced
policies.
So
I'll
just
go.
You
know
just
again
going
to
the
caverno
site
if
I
go
to
documentation
and
I'll
we'll
click
on
installation,
so
we
see
there's
a
bunch
of
different
ways
to
install
there's
a
helm
chart,
but
for
this
what
I
want
to
do
is
just
install
using
a
command
line.
C
So
we
can
kind
of
look,
take
a
look
behind
the
scenes
and
see
what's
going
on
right,
so
I'm
just
going
to
copy
this
command,
which
is
a
single
line
to
pull
down
all
the
ammos
from
the
kiberno
git
repo
and
install
into
my
local
cluster
right.
So
if
I
do
cuddle
get
namespace
you'll
see,
I
I'm
just
using
docker
for
windows
here
and
on
this
I'm
going
to
run.
C
You
know
this
command
line
that
we
copied
and
have
it
installed,
kiran
alright,
so
we
see
there's
a
bunch
of
crds.
That's
all
of
these
that
came
in
about
like
six
or
seven
different
crds,
including
policy
reports.
One
interesting
thing
I
want
to
mention
about
policy
reports
is:
these
are
not
unique
to
caverno.
In
fact,
the
policy
reports
are
being
developed.
C
You
know
in
in
collaboration
with
the
workgroup
policy,
the
policy
working
group
in
the
kubernetes
community
and
the
intent
is
to
make
these
same
crs
available
to
any
other
tool
that
wants
to
report
policy
results,
including
you
know,
in
in
a
kubernetes
cluster
right.
So
this
provides
a
standard
way
of
reporting
policy
violations,
independent
of
the
engine
or
the
tool.
That's
producing
it
and
there's
some
work
being
done
to
take.
You
know
things
like
cookbench
and
also
adapt
it
to
these
policy
reports.
C
Falco
is
being
discussed
as
another
candidate,
etc.
So
so,
once
these
cr
these
are
installed.
We
also
see
that
kiberno
created
a
service
account,
there's
also
a
few
other
things
done
and
what's
also
interesting
is
there's
some
web
ups
created
right.
So
now,
if
we
look
at
our
namespaces
again,
we
should
see
a
cabrno
namespace.
C
If
I
do
you
know
minus
and
giverno,
and
if
we
let's
say
do
pods,
we
should
see
that
we
have
a
single
pod
running,
which
is
what
we
expect
at
this
point
right.
So
now,
let's
go
ahead
and
you
know
I
don't
have
any
policies
and
if
I
do
will
get
cpal,
which
is
short
for
cluster
policy,
it
will
say
I
don't
have
any
resources,
because
the
crd
is
installed.
C
I
can
actually
now
use
something
like
poop
cuddle
explained
and
I
can
say
policy
so
qivarnam
both
has
a
cluster
policy
which
is
cpal
and
just
policy
which
is
a
namespace
policy
and
if
I
say
policies
back,
it
will
tell
me
you
know,
because
it's
integrated
again
with
kubernetes.
I
can
see
right
here
what
I
can
put
into
a
policy.
So
I
see
I
have
a
background
option,
which
is
a
boolean.
C
I
have
a
set
of
rules
in
the
policy
like
ritesh
was
explaining,
and
then
I
have
a
validation
failure,
action
which
can
be
set
to
either
enforce
or
audit
right,
and
if
you
go
further
so
on
it's
very
straightforward
and
of
course,
if
you
have
your,
you
know,
visual
studio
code
or
other
things
integrated
with
kubernetes,
you
get
all
this
help
and
you
know
schema,
etc
now,
also
in
your
ide
right,
so
makes
it
easy
to
write
policies
check
the
syntax
things
like
that.
C
But
here
I
can
see
that
this
is
the
description
of
rules,
but
so
far
I
don't
have
any
policies
I
just
have
kiverno
installed.
So
let's
go
ahead
and
you
know
get
some
policies
right.
So
I'm
going
to
go
back
to
the
kiverno
site
and
we'll
click
on
policies,
and
I
see
I
have
pod
security,
best
practices
and
other.
So
let's
go
to
pod
security
and,
like
ritesh
mentioned
here,
the
way
these
policies
are
organized
is
based
on
the
pod
security
standards.
C
C
You
know
the
pod
security
controls
into
three
categories,
so
there's
privilege
pods,
which
is
basically
unrestricted,
there's
baseline,
which
is
you
know,
used,
is
typically
used
as
a
default,
so
this
is
minimally
restrictive
and
then
there's
restricted,
which
is
the
highest
level
of
security
itself
right
and
then
it
lists
every
control
within
the
pod,
security,
security
context,
structures
and
the
allowed
settings
etc.
C
For
those
now
the
you
know,
the
the
cap,
which
is
being
developed,
which
is
most
likely
going
to
be
called
pod
isolation
policies,
is
also
going
to
be
based
on
pod
security
levels.
So
again
it's
important
in
part
security
standards.
C
So
it's
important
to
kind
of
keep
these
in
mind
and
then
you'll
be
able
to
apply
these
these
one
of
these
levels
to
name
spaces
in
this
upcoming.
You
know
cap,
which
will
be
pod
isolation
policies,
so
anyways
going
back
to
the
kivarna
policies.
As
you
see,
they
are
organized
to
default,
so
this
is
actually
baseline.
C
It
got
renamed
from
default.
So
this
is
the
baseline
setup
policies
and
this
is
restricted.
If
I
go
into
default,
we'll
see
you
know
each
policy.
That's
in
a
part
of
this,
if
I
click
on
any
one
of
this
like,
for
example,
let's
say
the
required
default
proc
mount,
so
it
is
checking
it
both
for
init
containers
and
containers
that
if
a
proc
mount
is
specified,
it
has
to
be
default.
It
cannot
be
changed
from
that
setting
right,
but
there's
other,
of
course,
several
other
policies.
C
If
we
go
back
to
you,
know
the
restricted
and
look
at
some
of
the
more
stronger
or
the
tighter
control
policies.
You'll
see
things
like
require.
You
know
that
run
as
non-root,
which
is
pretty
important
for
non-privileged
pods,
to
make
sure
both
init
containers
as
well
as
containers,
are
always
run
as
a
non-root
user
right.
So
let's
go
back.
You
know
to
this
main
pod
security
page
and
what
we
have
over
here.
It's
showing
me
a
one
line
command,
so
it
uses
customize.
C
It
pulls
down
policies
from
this
git
repo
and
then
it's
just
using
coop
cuddle
to
apply
them
right.
I'm
gonna
take
that
and
let's
see
what
happens
if
we
apply
to
our
cluster,
so
I'm
gonna,
you
know
it's
a
this,
takes
a
few
seconds
to
pull
down
all
of
the
ammos
and
once
that's
down
what
we
should
see
is.
It
will
apply
into
our
cluster
itself
right.
C
So
we
see
about
like
about
10
or
so
policies
got
applied,
and
if
we
go
back
and
look
at
the
cluster
policies,
we
should
see
that
these
are
now
enforced.
Now,
what's
interesting
is
if
I
go.
Let's
actually,
you
know
look
at
this.
If
I
go
to
one
of
these
policies,
if
you
notice,
when
I
was
browsing
through
the
policies,
most
of
them
are
written
at
the
pod
level
right,
but
as
ruthesh
mentioned,
one
of
the
things
kiverno
does
by
default
is
because
it
understands
the
relationship
between
part
and
part
controllers.
C
It
will,
let's
take
a
look
at
that.
You
know
root
policy.
Ki
verno
will
automatically
generate
policies
for
different
part
controllers
and
of
course
you
can
control
this
setting.
So
if
I
say
coop
cuddle
get,
you
know,
let's
say
cpal,
I'm
gonna
do
this
and
do
minus
yaml,
and
then
I'm
gonna
just
to
kind
of
get
better.
We'll
use.
C
Google
neat,
which
is
a
really
handy
plug-in
if
you
want
to
remove
things
like
you
know,
which
you
don't
want
to
see
like
all
of
the
metadata
and
the
or
the
owner,
references
things
like
that
from
the
yaml,
so
you're,
if
you
notice
what
happened
is
when
I
applied
this
policy,
it
was
just
written.
The
rule
was
written
to
match
a
part,
but
in
addition
to
a
pod,
what
happened
is
kiverno
automatically
generated
policies,
for
you
know
most
of
the
standard,
pod
controllers
and
again
this
can
be
you
know
tuned.
C
C
This
other
one
is
for
all
of
these.
You
know
the
more
standard
quad
controllers,
as
we
see
so
pretty
neat
that
I
have
now
all
of
this
installed.
So
let
me
try
and
run
a
simple
workload.
You
know,
I
think
I
have
an
nginx
pod,
so
I'm
just
going
to
say,
create
minus
f,
and
let
me
check
if
this
is
in
my
temporary
yeah.
So,
okay,
so
immediately,
kiwano
is
saying
and
because
these
policies
were
set
to
enforce
it's
saying
that
running
as
root
is
not
allowed.
C
So
now,
let's
try
something
a
little
bit
more
intrusive
right,
so
I'm
gonna
actually
use
this
site,
which
is
pretty
handy.
If
you
haven't
seen
it
it's
the
site
is
bishop
fox
and
it's
called
bad
pods
and,
as
the
name
suggests,
these
are
pods
which
are
misbehaving
right,
so
pods
which
are
misconfigured
to
allow.
You
know
all
sorts
of
I
guess
to
basically
be
open
where,
if
you
want
to
you
know,
you
know,
allow
post
bid
or
access
to
host
network
or
other
namespaces.
C
All
of
that
is
fairly
open
right.
So
here
I'm
going
to
go
into
let's
check
and
see
so
this
the
you
know
which
one
we
want
to
do:
let's
go
into
everything
allowed,
which
is
probably
the
worst.
You
can
do
right
and
we'll
take
a
quick
look
at
the
yaml,
we'll
actually
go
to
the
deployment
just
to
see
how
that
works,
and
you
know
we'll
look
at
it.
So
this
is
basically
alarming.
You
know
different,
it's
saying,
privilege,
true,
it's
mounting
host,
which
is
also
a
bad
thing
to
do.
C
It's
all
and
then
allowing
all
of
our
you
know
whole
name
spaces
to
true
right.
So,
let's
grab
that
and
what
we
want
to
do
is
we'll
go
to
the
raw
ammo
and
we'll
run
that
in
our
cluster
right.
So
I'm
going
to
now
do
kubeco,
create
minus
f
and
we'll
give
it
that
whole
ammo
and
see
what
happens
so
now
we
see
a
lot
more
warnings
or
a
lot
more.
You
know
errors
coming
back
from
our
admission
controller,
which
is
what
we
expect.
C
C
So
this
is
how
you
know
straightforward
and
simple:
it
can
be
to
you
know,
to
set
these
policies.
These
policies
are
very
flexible.
You
can
tune
them
based
on
you
know,
like
rotation
is
explaining
a
lot
of
different
selectors,
and
you
know
I
have
some
examples
in
here.
So
this
is
actually
a
different
policy.
It
mutates
or
this
is
generating
a
network
policy.
But
if
you
look
at
another
policy
like
which
also
can
mutate
things,
so,
let's
yeah
this
is
a
example
of
a
mutate
policy.
C
It
matches
also
pods,
but
you
can
write
your
your
selectors
based
on
several
you
know,
constructs
including
namespace
labels,
etc,
right
so
very
flexible,
very
simple.
You
know
to
apply
some
of
these
one.
The
other
thing
I
want
to
quickly
show
is
how
you
know
you
know.
Ritesh
also
mentioned
some
features
like
being
able
to
select
and
get
external
data
right.
So
very
often
you
want
to
write
a
policy,
but
you
want
to
then
you
know
leverage
data
from
things
like
config
maps,
which
are
very
natural
in
kubernetes.
C
In
fact,
you
know
in
in
the
community.
One
of
the
policies
that
I
was
just
working
with
somebody
to
develop
is
to
make
sure
that
workloads
workload
identities
are
protected
based
on
the
image
name.
So
you
know
what
the
author
did,
which
is
pretty
nice,
is
use
the
config
map
to
make
sure
that
a
certain
service
account
can
only
be
used
for
certain
images
right
and
they're
managing
this
the
data
through
a
config
map,
but
then
it's
a
very
generic
policy
to
do
that.
C
Another
common
example
is,
to
you
know,
make
sure
your
ingresses
are
unique
within
a
particular
in
a
cluster
right.
Your
host
names
for
your
ingress,
I
should
say,
are
unique.
So
kiverno
has
this
ability
to
use
jamespath
and
also
to
do
api
look
calls.
So
this
is
a
combination
of
using
those
two
features
so
just
going
through
the
structure
of
the
policy,
this
policy
matches
ingresses
and
then
there's
a
context
which,
where
you
can
populate
different
data
in
different
variables.
C
So
here
what
it's
doing
is
it's
saying
it's
doing
a
call
to
you
know
to
the
api
server,
which
is
this
api
call
construct
it's
getting
all
the
ingresses
from
the
api
server
and
then
it's
applying
this
james
path
on
it
to
extract
out
all
of
the
hosts
and
then
it's
checking.
If
that
host
is
you
know
the
host
from
the
request
object,
it
is
already
is
included
in
that
list
of
existing
hosts.
It's
going
to
deny
the
operation
right
so
fairly,
complex
logic,
but
pretty
straightforward.
C
You
know
once
you
kind
of
get
the
hang
of
how
this
is
structured
and
the
interesting
thing
is,
you
know
if
you
use
scoop
cuddle
and
you
know
just
through
the
command
line.
All
of
this
can
be
tested
very
easily,
so
I
can
do
cuddle.
I
think
it's
get
minus
this
raw
yeah.
So
if
you
do
coop
cut
I'll
get
minus
finished
raw.
C
So
here
I
don't
have
any
ingresses
in
this
cluster,
but
you
can
kind
of
see
what
that
looks
like,
and
even
if
you
want
to
test
the
james
path
expression,
you
can
use
jp,
which
is
the
command
line
for
that,
and
if
I
go
back
to
my
policy,
let's
grab
what
this
looks
like
and,
of
course,
if
I
had
some
ingresses,
this
would
maybe
make
more
sense.
But
if
I
apply
this
right
now,
it
will
come
back
with
an
empty
string
right
because
there's
no
there's
nothing.
C
So
it
just
came
back
with
an
empty
list
over
here.
As
you
see,
if
I
had
any
ingresses
with
hosts,
it
would
show
me
a
list,
a
string
list
of
those
ingressos
and
then
in
my
policy.
What
I'm
doing
is
I'm
checking
to
make
sure
that
the
host,
which
is
coming
from
the
request
object,
is
not,
you
know,
already
used
within
the
cluster.
C
So
this
is
a
simple
example
which
shows
again
how
you
can
combine
some
of
these.
The
other
thing
you
know,
which
is
very
interesting,
is
there's.
You
know,
policies
I
think
ritesh
mentioned
also
for
multi-tenancy.
C
I
can
show
a
few
examples
of
you
know.
Those
what's
we're
seeing
is.
First
of
all,
you
know,
adding
labels
to
namespaces
is
is
a
very
common
use
case
and
there
is
a
you
know,
there's
a
session
that
you
know
I'm
going
to
be
doing
along
with
adrian
ludman,
who
leads
a
hierarchical,
namespace
controller,
a
project
that's
also
being
developed
in
in
the
community.
C
We're
going
to
be
doing
this
at
the
cloud
security
day
for
kubecon
eu,
where
we're
going
to
talk
about
how
kiverno
and
agency
can
work
together
and
manage
both
namespaces
and
then
hnc
allows
you
know
subname
spaces
within
a
namespace,
so
how
you
can
kind
of
allow
that
to
those
controls,
so
you're
anyways
in
this
policy.
It's
it's
pretty
straightforward.
C
It's
saying
that
if
there's
a
namespace
created,
except
by
cluster
admins
or
by
the
hnc
manager,
go
ahead
and
inject
like
the
user
info
and
then
you
can
also
do
more
complex
things
like
you
could
say.
Okay,
maybe
I
want
three
types
of
name
spaces.
I
want
a
small,
medium
large
and,
based
on
that
now,
I'm
going
to
configure
you
know
different
quotas
and
different
things
for
my
tenants
right
for
my
users,
so
all
of
that
can
be
fairly
easily
done.
C
You
can
also
generate
very
fine-grained
roles
and
permissions,
so
only
the
the
the
person
who
requested
that
namespace
the
owner
will
get
permissions
to
then
delete
that
namespace
things
like
that
can
be,
then
you
know
generated
on
the
fly,
so
these
are
cavernous
policies
to
do
those
kind
of
things.
So
we'll
share
this
repo.
Once
once
you
know
we
we
have
this
finalized
for
the
session,
but
this
is
just
a
quick
example
of
how
now
you
can
use
the
power
of
you
know,
leveraging
labels
and
then
based
on
automatically
generating
different.
C
You
know
configurations
for
those
namespaces
and,
of
course
you
can
also
add,
like
validation,
logic,
to
make
sure
that
only
the
the
right
settings
like
in
this
example
it
was
requiring
that
each
namespace
only
have
a
certain
you
know
can
only
be
used
with
a
certain
suffix
right,
so
dash
sm
or
medium
or
large,
and
if
it
doesn't
have
those
it
would
be
rejected
itself.
C
So
these
kind
of
things
you
know
you
can
combine,
you
know
validate
mutate
and
generate
to
get
exactly
the
right
behaviors
you
want
for
your
cluster
and
once
these
policies
are
set,
they
could
they're
very
much
data
driven.
So
you
know
the
configurations
itself
can
be
easily
automated
in
there
okay.
So
one
last
thing
I
wanted
to
show
you
know
before
we
switch
is
you
know
in
kievano?
C
I
think
like
radish
also
mentioned,
and
as
we
were
looking
at
there's
this
ability
to
you
can
create
it,
creates
policy
reports
and
something
our
one
of
our
community
member
created
and
has
made
available.
This
is
also
an
open
source
project.
He
created
something
called
a
policy
reporter
which
takes
this
policy
report
and
also
provides
a
nice
graphical
ui
on
it.
He's
also
got
the
ability
to
push
this
to
grifana,
loki
and
elasticsearch
and
create
other
notifications,
but
really
nice
example
of
how
you
know.
You
can
now
view
this
graphically.
C
You
can
share
this
inside
a
single
cluster,
so
just
wanted
to
highlight
that
so,
if
you're,
looking
for
a
single
cluster
tool
to
you,
know
visualize
these
policy
reports
and
even
create
notifications,
when
these
get
created
definitely
check
out
this
policy
reporter
project-
and
you
know
we're-
there's-
also
work
in
progress
by
the
way
to
take
more,
give
or
no
metrics
and
push
these
to.
C
You
know
to
prometheus,
which
could
then
be,
of
course
displayed
in
various
uis
and
dashboards
like
the
fauna
and
others
as
well,
but
this
is
more
focused
on
the
policy
report.
The
other
work
that
we're
starting
now
is
to
build
to
to
push
engine
metrics
and
engine
statistics
out
as
well
all
right.
So
let
me
stop
there.
C
I
know
we
have
about
five
minutes
left
for
the
hour,
so
would
love
to
see
if
there's
any
other
questions,
thoughts,
comments
that
we
can
help
answer
and
you
know
again
like
there's
plenty
of
documentation
and
if
you
want
to
reach
out
to
us,
feel
free
to
reach
out
on
the
kiberno
slack,
which
this
is
the
on
the
kubernetes
slack,
the
commander
channel
itself.
A
Well,
that
was
one
thing
I
was
actually
noticing.
Is
that
your
documentation
is
awesome
so
congrats
on
that,
because
I
think
that's
one
of
the
things
that
drives
communities
and
really
helps
people
adopt.
We
have
a
couple
people
on
the
call
that
that
had
some
questions,
paul
murray,
if
you
want
to
pop
yourself
out
of
mute
and
onto
the
screen
and
kirsten
newcomer.
E
Yeah,
so
I
heard
a
lot
about
pods.
I
didn't
hear
whether
you
can
write
policies
around
custom
resources,
so
like
say
that
I
have
a
custom
resource
for
my
own
bespoke
controller
that
creates
pods.
It
contains
something
that's
like
pretty
close
to
a
pod
spec.
Can
I
write
a
kyber
node
policy
on.
C
It
absolutely
yes
yeah,
so
one
of
the
things
right
from
the
beginning
cavanaugh
has
supported
is
you
know,
also
full
custom
resources
and
it
does
help
if
the
custom
resource
schemas
are
structural.
E
Okay
and
how
about
if
I
have
like
an
aggregated
api,
can
I
write
policies
against
apis
that
another
api
server
might
bring
in.
C
E
C
A
There's
one
question
chris
kirsten
in
the
chat
mikey's
asking:
do
you
need
a
cni
to
enforce
the
policies.
C
So
for
network
policies:
yes,
if
you're
generating
a
network
policy,
you
will
still
need
a
cni
to
provide
that
runtime.
You
know
kind
of
to
make
sure
that
you
know
the
right.
Segmentation
exists
on
the
network
layer,
but
for
other
policies
like
pod
security,
etc.
A
C
Yes,
so
there
is
a
there
is
a
ordering
in
in
you
know
the
admission
control,
so
the
validate
will
occur
to
you
know
at
the
end,
so
all
of
the
mutation
logic
will
occur
and
then
once
that's
done,
then
you
get
a
chance
to
sort
of
validate,
there's
also
a
way
to
reinvoke
admission
controllers
so
cavernous
by
default,
when
it
installs
itself,
it
tries
to
be
the
last
admission
controller
to
receive
so
there
are,
you
know
there
are
some
customers
who
will
use
both
opa
and
cabrano.
D
Great
thanks,
so
I
I
had
kind
of
a
question
about
network
policy
generation
as
well.
How
do
you
inform
the
generation
of
that
network
policy?
Are
you
using
config
data
to
to
inform
that
or
is
there
a
you
know,
or
is
that
optional
kind
of
how
do
you
decide
on
on?
What's
going
to
be
in
that
policy,
that's
generated.
C
Right
yeah,
so
the
few
things
right
so
the
trigger
to
generate
the
policy
could
be
the
creation
of
a
namespace
could
be
the
setting
of
a
label
or
as
a
setting
of
an
annotation
itself.
So
one
pattern
is
if
you're
using.
If
you
want
some
variations,
and
you
want
to
control,
you
know
like,
for
example,
what
exactly
gets
generated
you
could
use
labels
and
based
on
labels
generate,
you
know,
have
templates
for
different
types
of
network
policies,
and
that
would
be
yeah.
One
quick
way
of
you
know
of
changing
that.
C
You
can
also
do
things
like,
because
caverno
can
look
up,
the
namespace
can
match
namespace
selectors.
You
can
say
that
if
for
certain
namespaces
and
if
there
is
an
annotation
on
that
namespace,
then
based
on
that,
maybe
you
want
to
trigger
a
different
network
policy.
So
then
you
would
have
two
different
generate
rules,
one
for
each.
So
you
know
a
few
different
ways
of
managing
those
kind
of
variations
and
handling
that.
D
Great,
thank
you.
That's
helpful
and
I
know
we're
pretty
much
right
at
the
top
of
the
hour.
I'm
actually
I
have
two
questions,
but
but
I'm
gonna
pick
one
of
them.
Do
you
have
thoughts
on
kind
of
policies
or
ways
that
we
as
a
community,
might
move
forward
to
kind
of
apply
policies
to
respond
to
events
in
the
runtime.
C
Yeah
great
question
right
and
something
that
we
have
been
thinking
about,
there's
been
discussion
also
in
the
policy
working
group
about
what
other
triggers
so
admission,
controls
and
configuration
changes.
Of
course
I
want
one
trigger,
but
it
would
be
very
interesting
to
also
have
a
set
of
you
know
defined
run
prime
triggers
there's
also
discussion.
C
You
know
about
authorization
checks
right,
so
somebody
in
the
community
was
asking
about.
You
know
that
there's
a
self-subject
review
request
that
gets
sent
out
from
the
api
server
when
when
there's
an
authorization
check,
so
you
know
for
having
some
more
granular
policies
on
that.
C
But
yeah
to
your
point
like
if
there's
other
runtime
events,
even
those
could
be
potentially
used
for
triggers,
but
it's
something
that
it's
not
supported
right
now
in
cabrino,
but
we're
very
open
to
that
and
interested
in
hearing
more
about
the
use
cases
and
how
that
could
be
standardized.
A
All
right
well,
thank
you
guys
for
coming
today.
It's
it's
wonderful
to
have
these
upstream
talks
on
mondays,
because
I
I
really
didn't
know
that
much
about
caverno.
Before
this
that
way
I
was
pretty
opa
centric
in
my
understanding
of
policy
management
and
such
so
it's
really
helpful
to
to
have
the
context
set,
and
so
I
think
everybody
appreciates
that,
as
well
as
jim
awesome,
deep
dive
and
demo
there
today
too
so
well
definitely
you're
in
the
sandbox.
A
Now,
yes,
the
road
ahead,
more
more
production
users,
more
people
using
it
more
feedback
on
it.
Hopefully
incubation
and
graduation
into
the
you
know
the
real
world
today,
sometime
soon.
A
And
we'll
definitely
get
you
back
on
as
it
matures
and
we
get
further
down
the
path
and
congratulations
on
on
getting
into
the
sandbox
and
getting
it
to
this
state
again,
if
you're
interested
in
this
topic,
these
guys
are
pretty
active
in
some
of
the
sigs
and
the
cncf
as
well
as
I,
as
I
mentioned
earlier,
the
documentation
is
rock
solid,
so
good
on
that.
A
That's
as
a
community
person,
that's
one
of
my
key
tests,
whether
we
can
keep
something
going
forward
and
definitely
when
you
get
a
new
release,
new
features,
new
functions,
reach
out
to
us,
ritesh
and
jim
and
we'll
have
you
back
so
good
work?
Good
luck
and
thank
you.
Thank
you
thanks
again
for
sharing
the
information
with
us
today.