►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
PolicyReport CRD: Manage Admission Control, Runtime, and Scan Reports! - Anushka Mittal & Mritunjay Sharma, Nirmata; Frank Jogeleit, Lovoo GmbH; Stephen Adeniyi
Policies help secure and automate Kubernetes. To standardize and simplify the management of policy reports across multiple tools, the Kubernetes Policy WG created a reusable PolicyReport Custom Resource Definition (CRD). In this session, Anushka, Mritunjay, and Stephen who are all LFX mentorship graduates will discuss the PolicyReport CRD and demonstrate adapters for policy and verification engines like Falco, kube-bench, KubeArmor, Kyverno, and Trivy to produce standardized policy reports. Frank will then present Policy Reporter, a Web UI with dashboards for policy reporting and integrations with Slack, Discord, Grafana, Teams, and Elasticsearch. You will learn how to easily manage policy results across admission controls, runtime, and vulnerability scanning leveraging the powerful CRD capabilities of Kubernetes.
A
Hello,
everyone
wow.
This
is
loud
welcome
to
valencia,
welcome
to
the
conference
and
welcome
to
hopefully
the
last
session
for
today.
So
yeah,
let's
go
yeah.
It's
been
an
exhausting
five
days.
Let's,
let's
wrap
this
with
a
huge
ban.
So
today
we
will
be
talking
about
policy
report
crd
and
how
you
can
manage
your
admission,
control,
runtime
and
scan
reports,
and
that's
amazing.
So
before
we
get
into
the
technical
part
of
the
adapters
and
the
policy
reporters,
let's
maybe
go
through
a
quick
round
of
introduction.
So
today
we
have
four
panelists.
A
A
B
C
Hi
everyone
welcome
to
our
talk.
My
name
is
brittan
jay
and
I
also
belong
from
india.
Currently
I'm
a
finally
a
computer
science
engineering
student
of
bachelor's
in
technology
from
india
and
I'm
also
an
intern
with
nirmata,
currently
I'm
contributing
to
kyberno
other
than
that.
Previously.
Last
year
I
worked
with
jim
bugwadia
as
a
part
of
lfx
mentorship
to
build
cubans
adapter,
which
we
are
going
to
talk
about
in
today's
talk.
But
before
we
move
on
to
the
adapters,
let's
discuss
what
was
the
foundation
and
motivation
behind
the
formation
of
policy
working
group
anushka?
A
Definitely
so
you
know,
their
policies
are
an
important
feature
and
we
have
earlier
seen
a
lot
of
scattered
support
for
policies
on
different
levels
of
maturities.
So
the
purpose,
the
motivation
behind
policy
working
group
was
basically
to
provide
an
overall
architecture.
You
know
one
platform
to
discuss
current
implementations
of
policy
as
well
as
discuss
future
implementations
and
future
proposals.
So
with
this
we
were
able
to
provide
a
universal
view
of
policy
architecture
in
kubernetes.
A
Let's
also
talk
about
policy
report
crd.
This
is
what
our
adapters
that
we'll
discuss
in
a
while
are
based
on
so
policy
reports,
crd
to
tell
you
the
motivation,
imagine
having
a
huge
cluster
with
multiple
policy
engines
and
getting
a
lot
of
outputs
if
they
aren't
unified,
it
might
just
be
a
big
hassle.
A
That's,
that's
lovely,
that's
a
lovely
question,
so
you
can
see
here.
We
have
a
few
points
overview
of
how
this
fits
into
kubernetes
architecture.
So
there's
a
policy
information
point
right
here:
that's
where
you
get
the
information
from
your
policy
engines
that
followed
by
the
policy
decision
point
where
your
policy
reports
policy
engines
policies
with
there.
You
can
see
interaction
between
the
policy
administrator
administration,
point
policy
decision
point.
This
is
where
you
want
to
decide
what's
next
and
that's
where
the
administer
administrator
sits,
and
you
know,
reviews
these
policies
that
are
unified
after
this.
A
Whatever
here,
whatever
happens
here,
the
decisions
taken
are
enforced
in
the
last
policy
enforcement
point.
Now
that
was
a
very
brief
introduction
to
policy
report,
crd
policy
working
group
and
the
overall
architecture.
We
will
now
move
on
to
the
qr
adapters
that
we
built
and
we
have
luther
going
with
the
first
adapter
called
cube
bench
adapter.
C
Now
that
we
know
about
what
is
policy
report,
custom
resource
definition,
let's
talk
about
one
of
the
first
adapters
that
was
built
on
top
of
it.
So
before
we
talk
about
what
is
cube
bench
adapter,
let's
talk
about
what
is
q
pins,
so
q
pinch
is
a
tool
that
was
built
by
aqua
security
and
what
it
does
is
that
it
it
helps
us
run
cis
security,
benchmark
checks
for
the
kubernetes
cluster
that
we
are
running,
whether
they
run
on
aks
or
eks
or
any
other
clusters.
C
So
those
checks
are
performed
by
cubebench
and
what
does
it
give
it
gives
us
just
results,
but
how
to
take
these
results?
How
to
move
forward
with
these
results
is
something
that
we
are
going
to
discuss
how
we
solve
with
that
cube
bench
adapter.
So
what
are
we
solving?
What
are
we
solving
now
before
cube
bench?
Adapter
is
a
simple
process.
That's
defined
in
cube
installation,
and
it's
like
you,
you
have
your
communities
cluster
running.
You
apply
the
animals
of
that.
C
That
is
provided
by
cube
bench
in
their
documentation
and
you
get
the
results,
but
that's
a
very
manual
process
and
you
are
not
able
to
move
ahead
after
results.
What
what?
What?
What
do
you,
if
you
want
to
have
like
more
fine
grain
control
after
those
results,
if
the
cluster
admins
need
that
that
is
what
our
adapter
tries
to
help
with
and
not
only
try
to
help
with
it,
but
it
tries
to
abstract
that
entire
manual
process
by
making
it
up
being
inside
a
nested
job.
C
So
if
we
see
now
in
the
diagram
now
that
entire
process,
which
was
a
manual
process,
has
been
abstracted
by
the
cube
rinse
set
up,
and
not
only
that
the
policy
report,
the
working
group
that
has
defined
the
policy
report
custom
resource
definition,
it
has
been
mapped
with
the
results
that
we
get
from
cube
bench
and
on
mapping.
What
we
get
after
after
after
after
the
mapping
that
we
get
is
the
cluster
policy
report
or
the
policy
report
which
can
help
us
in
policy
admission
controls.
C
How
did
we
solve
it?
How
how
how
we,
how
what
were
the
stages
of
solving
it?
So
the
first
is
the
first
stage
was
that
we
already
had
the
customer
resource
definition
defined,
of
course,
but
we
needed
a
client
code
talk
to
them
to
to
to
create,
update
or
delete
the
objects
of
the
custom
resource
definition.
We
had
the
custom
resource
definition,
but
we
wanted
their
objects.
So
the
first
step
was
that
creating
the
client
code
after
creating
the
client
code.
C
The
next
big
step
was
mapping
because
we
need
to
know
how,
because
both
are
different
data
structures.
The
cube
and
json
is
a
totally
different
data
structure
and
policy
report.
Custom
resource
definitions
have
different
types
of
mappings
and
json
defined.
That
was
a
good
process.
That
was
a
really
brainstorming
process
where
we
mapped
on
what
we
need,
how
what
kind
of
stores,
what
kind
of
properties?
C
Where
are
things
fitting
in
and
after
that,
it
was
all
hemi
file,
I
would
say
using
a
single
command
hem
command,
we
can
now
run
the
adapter
and
it
it
can
be
scheduled
as
a
cron
job.
So,
of
course,
for
the
demo,
we
are
not
going
with
the
one
month
or
one
week,
cron
job
which
is
used
in
production.
Use
cases
but
yeah
for
here
in
the
demo.
Next
we
are
going
to
see
the
demo.
C
It's
it's
a
schedule,
cron
job
for
two
minutes
where
we'll
be
seeing
a
live
example
of
how
we
can
generate
a
cluster
policy
report
with
the
cube
bench
adapter.
So
it's
a
single
one,
hem
command.
After
that,
the
only
prerequisite
required
was
that
you
have
a
humanities
cluster
so
locally.
We
are
testing,
so
it's
just
kind
cluster.
It
will
define
or
it
will
automatically
apply
the
custom
resource
definitions
that
we
have.
And
after
that
now
we
wait
for
the
jobs.
C
So
if
we
can
fast
forward
a
little
bit
so
that
we
can
see
the
jobs
a
little
bit
more
earlier
yeah,
it
takes
two
minutes
because
we
have
scheduled
it
for
two
minutes
but
yeah.
So
this
this.
This
is
the
cube
bench
this,
the
third
one
that
we
are
seeing.
This
would
have
been
happened
running
manually,
but
that's
happening
now
inside
the
job
itself.
C
So
it's
a
nested
job
actually
and
after
the
jobs
are
done,
we'll
be
able
to
get
our
first
cluster
policy
report
and
after
the
creation
of
cluster
policy
reports,
if
we
don't
change
the
name,
it
will
just
keep
on
updating
it
with
the
results,
whatever
the
results
that
we
get.
So
we
are
getting
our
first
results
as
we
can
see,
and
we
can
also
get
the
yamas
which
later
on
will
be
used
by
his
policy
report,
viewer
so
yeah.
That
was
the
demo
from
my
site.
Next,
we
have
trivia.
D
D
Okay,
so
this
is
just
a
quick
introduction
about
myself.
I'm
a
kubernetes
engineer,
intel,
that's
grammatics,
so
I'll
be
talking
to
you
about
trivia
data.
So,
first
of
what
is
truly
trivia
is
a
comp
is
a
is
a
simple
compressive
scanner
for
vulnerabilities
in
container
image
file
systems,
good
repository
as
well
as
configuring
issues,
trivia
data
is
created.
Is
it
too
created
by
the
aqua
security
team?
D
And
yeah
so
I'll
be
talking
to
you
more
about
your
adapter,
which
is
going
to
be
the
next
slide.
What
is
trivia
that
the
as
the
name
implies?
Trivia
adapter,
is
the
combination
of
both
3d
scanner
and
adapter,
which
is
the
policy
report
crd,
so
what
it
does
is
to
take
is
to
take
in
our
container
images
scan
them,
which
we,
I
mapped.
The
results
with
the
policy
report
then
then
reported
the
result
with
the
as
a
policy
report.
D
So
that's
as
a
quick
architecture
of
what
trigger
adapter
does
so
once
we
scan
what
we
want
to
scan
our
port
once
once
trigger
data
detects,
our
port
trivia
takes
charge
which
is
going
to
scan
our
container
image,
then
map
the
results
from
triggering
to
the
policy.
Crne
then
report
the
results
with
the
policy
reports,
as
a
policy
report,
so
I'll
be
showing
you
a
quick
demo.
D
Next
and
in
this
demo,
I've
already
installed
trivia
data
locally
on
my
system,
and
I
have
a
kubernetes
cluster
running
my
system,
which
is
which
has
a
port
and
the
container
image
is
running
as
well
in
the
port,
so
I
will
be
scanning
the
container
image
with
trivia
adapter
then
seeing
the
results
for
more
visualization
for
more
for
more
on
visibility,
I'll
be
seeing
the
results
with
the
policy
report.
I
hope
that's
good
and
yes,
there's
a
link
for
you
to
run
for
you
to
know
more
about
trigger.
That
is
a
link.
D
A
So
with
that,
we
can
move
on
to
the
falco
adapter
hello
again.
So
yes
for
the
next
part
of
the
presentation,
we'll
be
looking
at
the
falco
adapter
that
was
built
last
year.
It
was
just
released
in
falco,
sidekick
2.25.
So,
let's
start
with
some
background,
that's
about
falco
and
falco
sidekick.
So
what
is
the
falco
project?
The
falco
project
is
an
incubating
cncf
runtime
security
tool
right.
It's
the
de
facto
kubernetes
thread
detection
engine.
A
A
Moving
on
to
falco
sidekick
falco
sidekick
acts
as
a
middleware
between
falco
and
whatever
output.
You
need
from
falco,
yeah,
more
or
less
so.
Falco
would
basically
give
out
five
types
of
outputs.
Falco
sidekick
takes
the
http
output
and
you
know
sends
it
forward
to
whatever
type
of
output
that
you'd
want.
A
That
could
be
well
any
of
the
ones
that
I've
mentioned
here,
and
many
more
policy
report
is
another
another
output
to
falco
sidekick.
So
if
you
have
to
use
it,
you
just
simply
install
it
and
enable
it
to
be.
You
know
true,
while
installing
falco
so
yeah
moving
on
to
the
falco
policy
report,
adapter
falco
policy
report
adapter
the
overall
architecture
looks
somewhat
like
this.
A
Where,
on
the
top,
you
can
see
the
extended
architecture
of
falco,
how
it's
giving
out
alerts
via
an
http
output
that
falco
sidekick
is
accepting
how
falco
adapter
fits
in
falco
adapter
takes
that
output
in
your
cluster.
That
already
has
these
crds
policy
report
and
cluster
policy
report
installed.
It
maps
the
falco
output
to
the
crd
and
helps
in
generation,
as
well
as
updation
of
multiple
policy
reports.
This
is
done
in
a
n
plus
one
fashion,
that
is
n,
name,
space,
specific
reports
and
one
cluster-wide
report.
A
This
is
one
of
the
cool
things
about
falco
policy
adapter,
the
next
one
being
you
know,
multiple
falco
sidekicks
and
a
huge
cluster.
Each
one
has
a
unique
name:
that's
nice!
The
best
thing
about
this
I
find
is
the
configuration
options,
because
any
end
user
would
want
to
optimize
personalize
the
kind
of
events
they
see
in
their
policy
reports.
You
know
the
number
of
events,
the
priority
of
events
and
what
events
would
they
call
as
high
priority
or
low
priority?
You
can
configure
all
of
this
through
policy
adapter
and
finally,
you
get
falco
outputs.
A
There
are
different
fields,
they're
being
mapped
to
policy
report
crt,
so
there's
this
sort
of
agreed
upon
mapping
between
them.
Next,
let's
dig
into
a
quick
demo
that
will
show
you
how
your
falco
sidekick
with
policy
reporter
turned
on
looks
policy
report
turned
on
looks
like
so
I
have
a
cluster
running.
I
have
the
crds
installed
and
this
is
how
the
logs
would
look
when
your
policy
reports
being
created
a
namespace
specific
report
or
a
well
cluster-wide
report
following
this.
A
A
A
B
Yeah,
thank
you.
So
now
we
saw
what
tools
can
generate
this
policy
reports
and
how
they
look
like
in
a
yaml
format,
but
yeah
how
to
work
with
this
kind
of
cid.
I
will
present
you
policy
reporter
and
what
it
is
and
what
was
the
motivation
so
policy
reporter
is
a
tool
to
add
observability
and
monitoring
possibilities
to
your
cluster
security.
B
Based
on
this
presented
policy
report,
crd,
the
motivation
came
from
different
disadvantages.
I
encountered
myself
while
working
with
it
in
mostly
context
of
kyvono,
so
one
div
one
problem
was
for
me.
If
you
have
a
cluster-wide
policy
which
violates
namespace
scoped
resources,
you
have
many
resources
across
many
namespaces,
so
it's
very
hard
to
find
all
results
that
relates
to
a
single
policy.
B
Also,
you
have
the
problem
that
a
single
policy
report
can
contain
many
results
for
different
policies
and
resources,
and
if
a
new
violation
occurs,
it's
not
that
easy
to
find
it,
and
it's
also
very
hard
to
find
all
results
for
a
dedicated
resource
to
help.
With
this
kind
of
issues,
policy
reporter
provides
different
features.
So
at
first
you
can
send
new
violations
to
different
tools.
B
So
how
does
this
work
policy
reporter
consists
of
three
components
which
are
installed
as
you
configure
it?
We
have
the
core
component,
which
is
responsible
for
watching
over
the
policy
report,
crd
and
converts
it
into
a
metrics
endpoint
as
a
rest
api,
and
it
is
also
responsible
to
send
your
new
violations
to
the
configured
tools
I
mentioned.
B
B
If
you
want
to
find
out
more
about
policy
reporter
and
you
want
to
try,
try
it
out
with
more
possible
configurations
check
out
the
policy
reporter
github
repository
under
the
kyvono
organization.
It
has
also
a
link
to
a
dedicated
documentation
where
you
can
find
all
informations
relates
to
it.
So,
let's
start
with
a
demonstration.
B
So
at
first
you
see
the
mentioned
policy
reporter
ui.
We
have
a
overview
dashboard,
which
shows
you
all
violations
found
in
all
policy
reports
in
your
cluster.
You
have
that
grouped
by
namespace,
and
you
have
also
a
counter
for
your
cluster
policies
and
under
it
you
have
much
more
informations
and
details
about
your
violations
by
tool.
For
example,
we
have
also
kivono
in
this
environment,
where
you
see
your
kibona
violations.
B
If
you
want
to
know
what
happened
or
what
was
wrong
in
your
configuration,
you
can
click
on
an
item
and
see
the
error
message
of
this
report.
We
can
also
see
the
results
provided
by
the
mentioned
adapters
of
fico,
for
example,
where
you
see
a
policy
about
attach
exec.
Also,
here
you
see
the
error
message
and
also
the
provided
metadata
over
the
output
fields,
yeah
and
also
the
cube
bench
informations,
but
that's
just
an
overview.
If
you
want
to
see
all
informations
from
a
report,
you
have
dedicated
pages
for
the
source
of
a
policy
report.
B
Just
have
a
look
at
the
cube
bench
thing,
so
we
can
also
group
them
by
other
informations,
like
rule
which
makes
more
sense
for
cubebench,
so
we
have
all
results
that
are
related
to
the
api
server.
Now,
if
you
want
to
see
only
the
failed
ones,
you
can
just
filter
the
table
and
you
see
the
failed
one.
You
can
also
filter
for
the
warnings,
and
so
you
can
just
grab
all
violations
you
are
interested
in.
B
Already
in
your
grafana,
which
are
labeled
with
policy
reporter
and
yeah,
you
get
almost
the
same
information
as
in
the
ui,
with
the
different
filters
and
overviews
and
yeah.
You
have
one
source
of
truth.
As
always
before,
then
we
have
a
locks
page
which
works
as
a
demonstration
of
the
real-time
notification
stuff.
So
if
we
just
run
a
short
engines
which
will
violate
against
some
kiverno
rules,
they
will
just
show
up
in
this
locks
here
a
few
seconds
later
and
you
see
okay
at
this
time,
the
new
plot
violates
against
four
policies.
B
This
is
an
example,
as
I
said,
you
can
use
this
with
grafana
loki
or
elasticsearch
or
other
tools,
like
slack,
which
makes
more
sense
in
the
production
environment.
So
the
last
slides
are,
as
I
said,
kylo
specific.
You
get
an
overview
about
your
running
policies,
how
they
are
configured,
you
can
show
some
yaml
configuration
and
you
have
a
detailed
page
where
you
also
see
the
results
related
to
this
policy.
C
Now
that
we
know
what
happened
or
what
has
happened
in
the
past,
let's
talk
about
what's
in
the
store
for
the
future.
So,
as
you
mentioned,
as
we
talked
about
these
kind
of
adapters,
there
was
another
adapter
that
one
of
my
mentees
with
jim
bill.
He
was
also
there
with
us,
but
he
had
just
left
hardik,
so
he
built
cuba
adapter.
It
was
recently
incorporated,
so
it
was
recently
completed,
the
other
that
is
in
the
process,
and
we
are
going
to
build
it
later
as
a
gatekeeper
other
than
the
policy
reports
growing
adoption.
C
What
we
have
is
that
we
also
plan
for
the
mapping
of
the
the
the
cluster,
the
custom
resource
definitions
to
oscill,
and
not
only
that
but
entirely
automating
the
entire
process
using
a
cli.
So
that
is
one
of
the
other
features
that
we
are
that
are
in
the
plans
in
the
outlook.
The
other
two
things
that
we
are
planning
is
on
the
kubernetes
control
catalog.
C
So
it's
it's
more
like
again
mapping
of
all
the
security
configurations
that
we
tried
to
see
fitting
in
our
communities
cluster-
and
yes,
absolutely
we
all
are
here,
so
we
all
want
that.
You
all
be
a
part
of
the
future.
So
next
is
that
how
we
can
come
in
touch
with
the
community
that
we
work
with
the
policy
working
group
that
we
work
with.
C
So
this
is
our
mailing
list,
slack
channel,
github
and
community,
so
to
help
us
building
this
community
make
even
better
I'm
looking
forward
to
see
you
all
in
the
community
channels
and
now
that
we
know
about
the
community.
I
know
that
this
is
the
last
talk,
after
that
we
will
be
most
probably
going
to
our
homes
so
yeah
before
going
home.
Let's
get
stay
connected,
let's
stay
in
touch.
A
E
F
E
B
So
in
the
grafana
dashboard
there's
not
much
filtering
in
the
ui
or
general
for
the
violation
pushes
I
mentioned,
you
have
the
possibility
to
create
channels
and
filters.
So
you
you
are
able
to
send
different
or
violations
from
different
name
spaces
or
set
of
namespaces
to
different
cheap
channels,
for
example.
So
they
are
notified
that
when,
in
their
working
environment,
something
happened.
F
Thanks
for
the
talk,
so
is
so,
for
example,
for
search
manager.
We
have
our
own
policy
approver
and
our
own,
like
certificate
responsible.
Would
we
be
able
to
build
independently
our
own
policy
reporter
to
work
with
this?
With
this
with
this,
what
was
the
resource
and
policy
report
resource?
Would
we
be
able
to
independently
develop
our
own
integration,
for
this
is
my
question.
B
C
Report
right,
the
only
thing
that
will
change
will
be
the
mapping.
We
already
have
the
client
code
for
you,
it's
in
the
communities
working
group
repository
you
just
need
to
import
that,
and
after,
depending
on
the
policy
engine
that
you
have,
you
can
independently
build
it
and
contribute
to
it.
Yeah.