►
From YouTube: Behold: A New Way to Deploy Pod Security Policies Using Kyverno! - Abhinav Sinha, Nirmata
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Behold: A New Way to Deploy Pod Security Policies Using Kyverno! - Abhinav Sinha, Nirmata
Since its genesis, Kubernetes has been the go-to container orchestration solution for enterprises in need of scalable containerized applications implemented on microservices architecture. Any application that is deployed within Kubernetes is executed through one or more Pods, which makes Pod security not just a major concern, but a necessity for Kubernetes clusters, and even more so for business-critical applications. To fulfill this need, Kubernetes introduced PodSecurityPolicy (PSP) in its v1.3 release. However, PodSecurityPolicy was officially deprecated by Kubernetes in v1.21 and has been entirely removed in v1.25, which was a step taken due to some major issues encountered by users throughout the years of its use which could not be addressed without introducing breaking changes. But the removal of PSP in Kubernetes v1.25 does not mean that it’s an end for Pod security. It has been replaced by the new Pod Security Admission (PSA) controller, which utilizes the Kubernetes admission control webhooks. However, it comes with some serious drawbacks as well. In this session, Abhinav will be discussing the usage of Kyverno for deploying Kubernetes policies and demonstrate the new way of deploying PSPs with requirement-specific exceptions following the release of Kyverno 1.8.0.
A
Thank
you
so
much
welcome
everyone.
It's
nice
to
just
kind
of
have
my
very
first
conference
as
an
international
one,
so
I'm
quite
excited
for
that
and
I'm
really
looking
forward
to
at
least
kind
of
sharing
some
knowledge
that
I
have
gained
over
the
past
one
or
two
years
about
cloud
and
kubernetes
itself,
and
also
about
the
developmental
knowledge
that
I've
gave
gained
so
far
with
my
internship
at
nirmata.
A
So
a
little
bit
about
me,
I'm,
a
software
engineering
intern
at
narmata
and
currently
I'm
also
a
CSE
senior
I'm,
still
studying
in
college
and
I'm
in
a
final
year.
Right
now,
pursuing
my
computer
science
degree
from
KR,
Magnum,
University
and
I
have
also
been
the
Linux
foundations,
LFX
mentee
at
the
cluster
API
provider,
AWS
project,
which
falls
under
the
kubernetes
Sig
cluster
life
cycle
and
I'm.
A
Also,
the
Creator
and
the
maintainer
of
Cabernet
AWS
adapter,
which
was
just
recently
released
just
around
the
time
of
AWS
re,
invent
and
I've,
also
been
the
former
Secretary
of
computer
Society
of
India
krmu
chapter.
So
let's
get
started
well.
When
we
talk
about
pod
security
itself,
we
know
what
security
is,
but
when
it's
about
pod
security,
there
are
different
levels
of
complexities
when
it
comes
to
Containers
right.
A
So
if
we
need
to
access
specific
host
services,
for
example,
Linux
Services,
we
might
not
want
to
because
it
might
be
very
risky
for
any
unintentional
access
being
provided
to
any
kind
of
image.
So
please,
let
me
know
if
anybody
has
any
kind
of
questions
if
any
terminology
gets
complex,
because
it's
a
beginner
stock
and
I'll
be
very
happy
to
even
address
your
questions
Midway.
A
A
But
now
they
have
been
deprecated
in
the
v
version
1.21
and
finally,
they
were
entirely
removed
from
the
version
1.25
of
kubernetes,
but
this
removal
did
not
just
come,
as
is.
There
was
also
a
pod
security,
admission
controller,
which
was
introduced
in
kubernetes,
V
1.25
and
it
essentially
just
kind
of
enforces
whatever
standards.
We
have
right
now,
Port
security
standards
and
it
creates
policies
out
of
those
and
only
deals
with
those
standards
as
a
specific
like
enforcements
within
your
kubernetes
clusters
right.
A
A
So
there
might
be
a
privileged
standard,
which
is
extremely
not
recommended,
because
you
basically
provide
all
the
access
to
your
resources
using
this
this
mode
privileged
mode,
and
then
there
is
the
Baseline
mode,
so
Baseline
mode
is
essentially
the
kind
of
policies,
the
kind
of
standards
that
are
enforced
whenever
you
create
any
generic
kubernetes
Pawn
right.
So
if
you
just
use
the
cube
Kettle
run
command,
then
you
are
basically
creating
pods,
which
are
following
the
standard
Baseline
profile
of
quad
security
sandals,
and
then
there
is
restricted
mode.
A
It
is
actually
heavily
restricted
and
we
will
kind
of
see
what
these
look
like
when
it
comes
to
the
actual
kubernetes
implementation
later
on.
But
now,
let's
see
what's
a
pod
security
admission
controller,
so
an
admission
controller
in
kubernetes
essentially
means
that
Whenever
there
is
any
kind
of
a
resource
admission
within
the
cluster
itself.
A
There
might
be
a
few
web
hooks
which
would
be
looking
at
the
resources
right,
so
these
web
books
might
be
able
to
either
validate
whatever
the
payload
was
when
the
resource
was
kind
of
getting
into
the
cluster
itself,
and
then
they
with
we
can
basically
make
some
decisions
on
the
basis
of
whatever
payload
consists
right.
So,
for
example,
if
let's
say
there
is
a
specific
mode,
then
the
webbook
will
see
for
so
before.
Before
getting
to
the
more
itself,
we
also
have
namespaces
so
Port
security
standards.
A
In
case
of
Port
security,
admission
controller
itself
is
applied
on
a
namespace
scope
right.
So
the
way
to
implement
this
is
by
adding
a
label
to
the
namespace
itself,
and
this
essentially
it's
the
same
format
as
I've
mentioned
over
here.
So
it
would
be
part,
hyphen,
security,
dot,
kubernetes,
dot,
IO
slash
mode,
and
this
mode
has
to
be
anything
between
infos
or
audit
or
Bond.
A
So
these
are
the
only
acceptable
values
for
the
mode
and
then,
in
the
case
of
level
we
would
mention
which
kind
of
pod
security
standards
we
want
to
apply
for
that
entire
namespace.
So
you
cannot
apply
these
standards
for
specific
pods
right.
You
will
have
to
apply
this
on
the
entire
namespace,
so
all
the
pods,
all
the
containers
that
are
present
in
that
entire
name
space
would
be
affected
by
this
part.
A
A
Okay,
I
can
see
four
or
five
hands.
That's
great.
It's
even
a
better
session,
so
in
Greek
means
to
govern
now.
What
we
mean
by
governance
and
kubernetes
is
that
we
are
essentially
having
control
over
what
resources
are
making
way
into
our
kubernetes
clusters
right
and
then
we
can
make
decisions
on
the
basis
of
those
resource
specifications
and
by
this
implementation.
A
There
are
other
implementations
for
like
policy
enforcement
and
kubernetes
such
as
oppa
gatekeeper,
but,
as
you
might
have
heard
of
it,
it
also
requires
the
usage
of
a
Rigo
language
that
is
very
specific
to
Oppa,
but
Opa
definitely
has
a
lot
of
different
use
cases.
It's
not
just
restricted
to
kubernetes,
but
if
it
comes
to
the
ease
of
use,
kevano
is
definitely
a
step
ahead
of
it
because
it
just
requires
yaml.
There's
nothing
else
and
you
can
essentially
audit
or
enforce
the
policies.
A
So
by
audit
we
mean
that
we
will
have
an
entire
log
of
whatever
resource
has
tried
to
make
their
way
into
the
cluster,
and
we
also
have
like
three
different
kind
of
rules
and
and
I
forgot
to
mention.
Enforce,
enforce,
essentially
just
entirely
rejects
the
admission
of
a
resource
in
the
cluster.
If
it
does
not
follow
whatever
no
policy,
we
have
written
okay.
So
it's
very
restrictive.
If
you
have
just
one
specification
that
is
misconfigured
in
your,
for
example,
kubernetes
spot,
then
it
will
just
not
allow
the
creation
of
that
part
itself.
A
A
Then
there
is
a
mutate
rule.
Mutate
rule
is
pretty
cool.
Actually,
if,
let's
say
you
have
any
kind
of
resource
that
you
forcefully
want
to
modify
on
the
spot
as
it
as
and
when
it
tries
to
make
their
way
into
the
cluster,
you
can
simply
modify
its
specification.
Whatever
specification,
you
want
right
and
on
the
basis
of
that
payload
itself,
whatever
it
is
getting
from
the
kubernetes
API
server,
it
will
be
able
to
make
that
decision.
A
Just
in
the
way
of
like
whatever
policy
you
define,
and
then
there
is
a
generate
resource
brew
and
you
can
also
generate
resources.
For
example,
if
there
is
a
specific
resource
that
requires
the
creation
of
a
secret
of
a
kubernetes
secret,
you
can
just
kind
of
see
if
this
is
that
specific
resource
and
you
can
generate
a
new
resource
or
a
new
secret
on
the
basis
of
that
kubernetes
resource
which
we're
trying
to
validate
and
then
yeah.
A
It
is
essentially
able
to
verify
any
oci
images
and
attestations
that
are
associated
with
the
kubernetes
spot,
so
you
can
also
verify
whether
or
not
this
is
an
image
that
you
want
to
be
associated
with
a
pod
or
any
kind
of,
let's
say
or
even
a
deployment.
So
one
of
the
cool
things
about
Kevin
is
that
you
also
don't
need
to
worry
about
whether
you
have
to
write.
A
If
you
are
trying
to
write
about
write
a
rule
about
pod
or
a
deployment,
you
can
use
autogen
controllers,
which
are
very
specific
to
keyword
itself,
and
it
will
create
specific
Auto
generated
rules
for
whatever
pod
controllers
we
have.
So
if
you
create
a
rule
for
a
pod,
then
it
will
be
automatically
applied
to,
for
example,
replicasets
or
deployments.
So
that's
one
one
cool
thing
about
kibano,
so
let's
just
try
to
understand
the
architecture
of
kevano
at
a
very
high
level.
A
Just
we
as
I've,
already
told
that
an
admission
controller
keeps
an
eye
on
on
whatever
resource
is
getting
into
the
cluster.
So,
on
the
basis
of
that
payload,
the
admission
web
hook,
cable
has
an
admission
Web
book.
Actually
there
are
multiple
web
books
in
kibano,
but
essentially
in
kubernetes,
there
are
two
kinds
of
web
books
which
are
the
mutating
workbook
and
the
validating
my
book.
A
The
validating
takes
care
of
any
kind
of
validation
that
is
to
be
performed
on
the
resources,
and
the
mutating
network
takes
care
of
like
modifications
in
that
resource
and
in
this
case
the
admission
controller,
the
cable,
no
admission
controller,
it
utilizes
the
kubernetes
webworks
to
kind
of
make
such
decisions
and,
on
the
basis
of
that,
it
is
able
to
create
change,
rcrs
or
policies
or
generate
triggers
so
on
and
so
forth.
So
this
is
like
a
very
high
level
architecture
of
it.
You
don't
really
need
to
understand
all
of
this.
A
A
So
here
we
have
a
really
standard
sample
policy,
I'm,
not
sure
if
you're
I
hope
everybody
is
able
to
see
the
content
here.
So
let's
try
to
understand
what
we
have
here
step
by
step.
The
API
version
for
a
caberno
policy
is
just
kibano.io
V1
and
the
kind
would
be
cluster
policy
in
this
case,
although
we
have
two
kinds
of
policies
in
kevano,
one
is
a
cluster
policy
and
the
other
is
just
policy
which
refers
to
any
namespaced
policy.
A
Next,
we
have
the
metadata.
You
can
see
a
lot
of
different
annotations
here.
These
are
not
at
all
required
if
you
just
want
to
try
out
Kevin
for
the
first
time
these
just
kind
of
provide
you
with
additional
information
about
that
specific
policy
and,
for
example,
you
can
categorize
what
this
specific
policy
is
related
to
it's.
So
in
this
case,
it's
a
best
practices
policy
from
the
kivano
website
itself,
and
we
can
also
provide
a
description
if
that's
needed,
then
let's
get
back
to
the
actual
real
deal.
A
That
is
the
specification
of
equivalent
policy.
So
here's
what
the
real
action
happens
and
this
we
have
a
validation,
failure,
action
where
we
have
set
it
to
audit
and
in
case
of
audit
mode,
it
will
just
create
events
and
policy
reports
for
any
kind
of
events
that
happen
which
are
not
really
intended.
A
Then
we
have
background
mode,
so
background
mode
basically
ensures
that
it
is
able
to
keep
track
of
this
of
any
previous
resources
that
have
existed
in
the
cluster
to
be
checked
even
after
this
policy
has
been
applied
at
a
later
stage
right,
then
we
have
the
rules
that
we
need
to
Define
for
our
policy,
so
a
policy
need
not
contain
just
one
rule.
It
can
contain
many
rules,
so
in
this
case
there
is.
A
That
is
why
it
is
a
list
of
rules
present
here,
so
we
just
have
one
rule
mentioned
here
that
is
check
for
labels
and
this
policy
just
checks
for
the
existence
of
this
label.
Here
that
is
app.kubernetes
dot,
IO,
slash
name
as
long
as
this
label
is
mentioned.
It's
it's
present
in
the
in
the
metadata
of
any
pod.
So
you
can
also
see
that
we
are
currently
matching
against
all
the
resources
that
have
a
kind
of
pod.
You
can
also
mention
multiple
resources
here.
It
just
does
not
need
to
be
a
part.
A
It
can
also
be
a
namespace.
It
can
also
be
a
deployment
you
can
mention
as
many
resources
you
want
in
the
kinds
list
and
it
will
validate
all
those
lists,
all
those
resources
for
this
namespace,
and
that's
that's
basically,
the
purpose
of
this
policy,
it's
as
simple
as
writing.
Just
plain
yaml
for
deploying
your
first
kubernetes
keyword,
no
policy.
A
A
A
It's
called
an
anchor
and
there
are
only
about
five
or
six
of
these
anchors,
which
are
used
for
comparing
the
values
or
like
validating
the
values
within
fields
and
their
children
fields
in
in
any
kind
of
like
a
specification.
So
in
this
case
it's
just
trying
to
see
if
any
init
container
exists
then
proceed
to
its
child
elements,
and
if
the
child
elements
exist
named
as
security
context,
then
look
for
its
children
as
well,
and
if
privileged
this
privileged
field
exists,
then
it
needs
to
be
false.
A
A
Now
there
is
a
new
rule
that
is
implemented
in
kibano
after
the
version
1.8
release,
and
this
is
known
as
the
Pod
security
validation
rule
earlier.
There
was
no
such
rule,
that
was,
that
was
dedicated
towards
just
part:
security
standards
or
Port
security
policies.
But
with
this
rule
we
are
able
to
even
make
it
a
lot
more
fine-grained,
a
lot
more
granular
to
implement
pod
security
standards,
because
Port
security
standards
by
themselves
do
not
provide
you
with
any
such
way
to
make
any
modifications
in
the
standards
that
are
already
defined.
A
So
this
is
where
kevano
comes
in.
It
also
gives
you
the
ability
to
kind
of
accept,
make
exceptions
for
or
exclusions
for,
different
control
names.
So
what
is
the
control
name?
What
are
the
restricted?
Fields
I
will
basically
get
you
through
it
as
well,
but
this
is
essentially
the
syntax
of
any
pod
security
rule
in
kibano,
so
in
the
Pod
security.
So
the
the
parent
field
here
is
the
validate
field
which
falls
under
the
kivano
cluster
policies
pack
itself
and
in
the
Pod
security
field.
A
In
this
example,
for
the
same
previous
syntax,
we
have
a
baseline
profile.
This
Baseline
profile
is
using
is
being
used
for
all
the
latest
kubernetes
versions,
and
then
we
are
just
trying
to
exclude
the
control
name
for
capabilities,
and
what
these
capabilities
are
it's
very
specific
to
just
Linux
distributions.
It
essentially
tells
you
what
host
capabilities
you
want
the
system,
the
kubernetes
part
to
have.
In
this
case
we
are
modifying
the
capabilities
for
for
this
specific
profile.
That
is
Baseline
profile
and
we
are
adding.
A
We
are
making
modifications
to
the
restricted
field
which
is
mentioned
as
any
containers.
So
this
aesthetic
asterisk
represents
the
wild
card
symbol.
Any
any
container
that
is
present
with
a
security
con
context
capability,
the
ad
capability
within
the
security
context
it
it
is
allowed
to
have
any
value,
such
as
a
kill,
set
GID
and
set
uid.
So
these
are
the
different
values
that
we
are
making
exceptions
for.
Apart
from
this,
every
other
values
will
be
excluded
like
they
will
be
validated
against,
and
so
I
guess
it's
time
for
a
demo.
A
All
right,
so,
in
fact,
let
me
just
use
the
terminal
that
might
be
more
appropriate
yeah
so
for
the
demo
I'm,
not
using
any
kind
cluster
or
many
Cube
cluster
I'm,
just
using
an
eks
cluster.
There's
no
specific
reason
for
that,
except
that
my
system
might
cry
a
lot
for
resources
which
it
might
not
have
right
now.
It
happens
a
lot
so
I'm
just.
A
All
right,
so
there
is
no
other
resource
on
the
system.
If
you
want
to
install
cable,
no
there's
a
very
beautiful
documentation
out
there
on
the
kibana
website
itself.
You
can
just
go
to
the
documentation
and
there
are
installation
steps
in
my
case,
I'll
be
specifically
using
the
Helen
chart
for
kevano
yeah.
So
you
just
have
to
add
the
repository
for
kevano
handshot
and
you
will
be
good
to
install
it
as
well
and
it
seems,
like
my
system
has
already
started,
trying
for
some
reason:
yeah,
okay,
so.
A
A
A
And
yeah
it's
running
now,
so,
let's
just
try
to
so
now
that
we
have
already
installed
cabinet.
First,
let
me
demonstrate
how
the
actual
pod
security
policies
work
in
terms
of
like
the
Pod
security
admission
controller
itself.
So,
if
I
want
to
enforce,
we
are
not
dealing
with
K1
right
now
we
are
just
using
the
native
kubernetes
part
security
admission
controller.
If
we
want
to
enforce
the
admission
controller
right
now,
all
we
need
to
do
is
we
just
need
to
create
a
namespace?
A
A
So
now
our
pod
has
been
labeled,
so
if
I
just
run
the
nginx
image
in
the
Baseline
namespace,
it
won't
show
any
kind
of
policy
violations.
But
let's
say
that
if
I
create
this,
this
resource,
which
is
a
pawn
that
has
a
security
privileged
mode,
enabled
basically
so
privileged
mode
means
that
you
will
be
able
to
access
all
the
resources
all
the
host
resources
of
this
pod.
So
if
I
just
try
to
apply
this
pod,
I'm
pretty
sure,
okay,
once
again,
I'll
just
copy
this.
A
A
So,
if
I
set
this
to
false,
let's
see
what
happens
now,
it
should
work
pretty
pretty
fine
and
it's
credited
so
the
problem
with
this
is
that
it's
very
much
rigid
in
terms
of
whatever
capabilities
or
whatever
kind
of
standards
are
being
enforced
here.
So
if
I
just
show
you
the
Pod
security
standards,
these
are
pretty
much
well
defined
already.
You
cannot
customize
these.
If
you
are
kind
of
enforcing
these
standards
on
any
namespace,
then
they
have
to
follow
these
different
practices.
A
For
example,
in
case
of
privileged
pods,
you
don't
need
to
take
care
of
anything,
it's
basically
just
giving
the
key
to
your
door
to
any
kind
of
Thieves
or
stranger.
That's
that's
how
privileged
it
makes
your
pods
or
resources,
but
in
case
of
Baseline
it
has
some
different
practices
or
values
defined
for
the
different
control
names.
So
we
have
already
seen
control
names
in
kubernetes,
cable,
no
policy
specification
earlier.
A
Yeah
all
right,
so
it
has
some
restricted
fields,
and
these
are
the
restricted
fields
that
we
have
seen
earlier
in
the
kivano
policy,
and
these
are
the
allowed
values
so
essentially
in
this
control
name,
we
are
just
restricting
all
these
fields
to
these
specified
values.
If
there
is
any
other
value
for
this
host
process
control
or
like
for
these
fields
within
any
pod
specification
in
kubernetes,
then
only
these
values
are
allowed
and
if
you
try
to
set
it
to
true,
then
it
will
fail
immediately.
A
So
this
is
the
Baseline
profiles,
just
one
control
name:
there
are
multiple
control
names
across
different,
restricted
Fields.
So
that's.
Why
that's
why
it's
pretty
much
rigid?
You
cannot
make
any
changes
to
these
existing
standards
and
that's
how
it
is
implemented
in
kubernetes
as
well,
but
in
case
of
cable.
No,
as
we
mentioned
that
we
can
make
it
a
lot
more
fine-grained.
So,
let's,
let's
have
a
look
at
what
a
kiber.
A
A
Then
we
could
see
that
there
are
two
failed
resources
here,
and
this
is
essentially,
if
I,
if
I
even
know,
yaml
this,
then
we
can
also
see
that
there
are
these
two
failing.
Resources
also
contain
this
field
policy.
So
it's
an
indication
that
our
policy
has
worked,
but
it's
only
in
audit
mode
right
now.
That's
why
it
has
not
taken
any
action
if
it
was
enforced,
then
let's
also
see
what
would
happen
if
it
was
enforced.
A
Now,
let's
have
a
look
at
the
Pod
security
policy
that
we
talked
about
earlier,
so
in
its
current
state.
If
we
don't
include
the
commented
section
of
it
right
now,
it
will
work
pretty
much
the
same
as
the
Baseline
profile
does
so
here
we
have
the
Pod
security
Rule,
and
in
this
we
have
specified
the
level
of
pod
security
that
is
Baseline,
and
then
we
have
the
version
that
is
latest.
So
if
we
apply
this
cluster
policy.
A
And
then
I
try
to
apply
the
policy.
Then
kevano
is
the
one
that's
making
the
decision
that
this
part
is
not
allowed
in
the
cluster
itself.
So
that's,
basically,
the
demonstration
of
the
Pod
security
rule
in
Cabernet
there's
a
lot
more
detailed.
There
are
a
lot
more
detailed
policies
out
there
on
the
kibernough
website
itself.
If
you
want
to
have
a
look
at
the
policies,
then
you
can
just
go
to
the
policy
section
on
the
kibano
website.
We
have
tons
of
different
policies
uploaded
over
here.
A
Those
are
all
created
by
the
kibino
community
and
if
we
just
look
have
a
look
at
it,
we
have
two
37
different
policies
created
by
the
community,
which
is
always
going
to
be
increasing
by
the
way.
Now,
let's
have
a
look
at
what
we
have
remaining
I'm,
pretty
sure
there's
nothing
else
remaining
for
the
demonstration.
A
C
C
Interesting
presentation:
hi,
my
name
is
kentaro
I'm
from
Japan
and
yeah.
Actually,
the
build
security
policy
is
already
I.
Think
AI
is
a
really
big
problem
and
I
was
a
previous
company.
I
was
a
developer
and
then
the
support
security
policies
is
deprecated
and
then
yeah
interest.
So
sorry,
my
main
question
is
the
which
is
about
the
best
migration
software
is
the.
Is
the
keyboard
no
or
open
Percy
agent?
C
Or
you
know
the
cloud
native
service
of
many
policy
post,
Security,
Services
and
today
I
really
interested
in
the
Care
Bear,
no
I
I'm
not
Hands-On
later
yet
so
I'm
trying
I
would
like
to
try
to
use
it,
but
so
how
do
you
think
the
cable
or
Oba
or
other
sources,
which
is
the
good
one
to
determine
the
benefits
of
services?
If
you
know
that
yeah,
that's.
A
As
for
what
is
the
most
appropriate
policy
engine
to
use
right
in
case
of
Kevin
o,
it's
definitely
a
lot
more
easier
to
use
when
compared
to
Opa,
because
nobody
wants
to
learn
anything
new
in
order
to
apply
what
they
already
know.
They
just
have
to
implement
it
in
a
way
that
is
acceptable
by
kubernetes
itself.
Right
so
Kevin
know
just
utilizes
those
web
hooks
that
we
talked
about
I'm,
not
entirely
sure
how
oppa
is
implemented
as
a
developer.
A
So
I
cannot
speak
for
the
internal
complications
or
like
features
that
are
present
over
there,
but
in
case
of
Kevin
I'm,
pretty
sure
that,
as
compared
to
other
policy
engines,
I
believe
that's
the
only
only
policy
engine
we
have
right
now
which
allows
us
to
create
policies
in
just
kubernetes
native
fashion,
and
there
are
also
increasing
use
cases
for
kevono
as
and
when
the
community
demands.
So,
just
as
I
mentioned,
even
the
image
verification
rule,
that's
again
increasing
that
that's
being
supported
by
the
help
of
cosine,
also
created
by
chain
guard.
A
So
we
we
Implement
cosine
in
our
kivano
development,
just
to
verify
the
image
verification
as
well
as
for
the
part
security
part
I,
believe
that
was
your
question
right
for
part
security.
Definitely,
we
are
still
working
on
making
it
a
lot
more
like
appropriate
to
make
it
production
ready
right
in
case
of
K1,
but
it
was
just
recently
released.
I
believe
it's.
A
It
might
need
some
Community
contributions
as
well,
I'm,
not
entirely
sure,
because
I'm
not
right
now
on
the
kivano
development
team,
but
as
for
pod
security
standards
themselves
or
Port
security
policies,
it's
definitely
a
good
option.
If
you
want
to
get
started
with
implementing
Port
security
policies
in
your
clusters
and
make
it
a
lot
more
like
you
just
want
you
just
don't
want
to
learn
new
like
redundant
things.
You
you
just
want
to
know,
you
just
want
to
implement
whatever
you
are
already
aware
of
right.
A
A
In
that
talk,
they
have
pretty
much
tried
to
bring
up
all
the
differences
between
kivarno
and
the
Pod
security
policies
or
the
particularity
admission
controller
as
well,
and
there
are
also
a
different
comparisons
present
on
the
nimata
website
itself
and
also
on
Chip's
website
neon
mirrors
as
well.
So
you
can
just
kind
of
find
all
the
different
comparisons
made
by
someone
who's
more
qualified,
as
I
am
to
do
that
comparison.
Yeah.
A
A
B
A
Yeah,
so
it's
again
a
really
good
question
and
there
was
one
recent
change
in
kevano
made
by
one
of
our
create
maintainers.
We
are
basically
so
earlier.
What
was
happening
was
we
were
keeping
track
of
policy
reports
in
just
one
yaml
file
or
like
one
custom
resource.
That
is
the
policy
reports
itself.
A
It's
either
policy
report
or
the
cluster
policy
report
itself,
and
we
were
not
splitting
those
in
any
fashion
just
as
of
recently,
but
now
we
have
made
some
modifications
in
how
kevano
policy
reports
are
implemented
and
we
are
now
splitting
them.
We
have
provided
people
with
the
ability
to
split
policy
reports
per
namespace,
so
you
could
have
different
policy
reports
for
different
name
spaces
as
compared
to
like
having
just
one
single
policy
report
and
that
containing
all
the
details
of
whatever
admissions
were
made
in
the
previous
requests.
A
So
that's
one
optimization
we
have
done
previously.
As
for
the
performance,
I
think
there
were
some
issues,
but
we
have
resolved
most
of
the
performance
issues
in
our
previous
pull
requests.
I
cannot
provide
an
exact
Benchmark
as
I.
Don't
have
any
graphs
to
show
you
right
now,
but
yeah.
There
have
been
some
improvements
in
the
previous
pull
requests
that
were
made
on
the
K10
project,
at
least
from
whatever
right
now,
yeah.