►
Description
Kubernetes Policy WG : CNCF Security SIG Policy Team 2021-03-03
B
A
B
C
D
D
C
A
Well,
yeah-
and
I
guess
our
first
topic
we
can
talk
about-
is
this
actually
related
to
that
and
just
the
organization
of
the
group
etc.
So
maybe,
let's
kick
things
off.
I
think
we're
almost
at
five
past,
and
we
have
you
know
quite
a
few
people
on
already
so
hi
everyone.
This
is
jim
and
let's
get
started
with
our
workgroup
meeting.
A
A
You
know
with
this
group
with
organizers
like
erica
and
howard
in
the
past,
but
seems
like
they
have.
You
know,
moved
on
to
other
responsibilities
or
are
not
very
active
with
the
group,
at
least
at
this
point.
So,
oh
you
know
I
reached
out
to
get
some
help
from
our
toc
liaison.
You
know
and
to
see
what
can
be
done
so
they're
gonna
also
find
out
and
reach
out,
and
you
know
see
if
there's
a
way
we
can
get
access
to
the
videos.
A
So
apparently,
each
work
group
should
have
their
own
kind
of
video
channel
which
helps
us
with
the
calendaring
and
things
like
that,
and
even
then
updating
meeting
invites
etc
would
be
a
lot
easier
for
us
right.
So
in
the
next
few
weeks
we'll
get
some
of
those
things
sorted
out.
So
that
way
we
just
have
a
path
moving
forward,
and
you
know
also
like
I
guess
it's
too
late
for
good
con
eu,
but
maybe
in
the.
C
A
There's
a
lot
going
on,
of
course,
with
you
know,
pod
security
policies
being
marked
for
deprecation
with
you
know
these
discussions
around
policy
engines
and
other
policy
tools
in
general.
So
I
think
there's
a
lot
of
good
things.
We
can
say-
and
you
know
talk
about
and
also
get
feedback
from
the
community.
A
C
C
B
A
B
D
Yeah,
I
think
jai.
This
is
your
talking
and
I
think
from
my
perspective,
I
think
you
know
I'm
passionate
about
policy-based
governance
across
the
stack
right
so
cuban.
It
is
definitely
one
piece
of
the
puzzle,
but
I
think
we
need
to
apply
this
throughout,
but
so
I
would
say
my
primary
interest
is
given
it
is,
but
it
goes
beyond
that.
E
A
Yeah-
and
I
totally
agree-
I
think
you
know-
obviously,
kubernetes
is
not
the
end-all
place.
Although
having
said
that,
I
think
for
projects,
it
seems
like
the
natural
place
to
start
and
then
kind
of
widen
the
scope
right
so,
but
we
do
want
to
make
sure
we
cover
other
systems
like
service
meshes
and
in
fact
you
know,
I'm
sure
most
of
you
have
seen
or
read
or
heard
of
the
cloud
native
security
white
paper.
We
can
use
that
as
a
framework
to
some
degree
to
organize.
D
Yeah,
the
other
thing
I
also
wanted
to
highlight
is:
I
know
this
group
is
under
the
sig
security.
From
my
perspective,
right
policies
or
security
policies
obviously
are
very
important,
but
policies
are
also
relevant
for
resiliency
and
other
software
engineering
aspects
right.
So
I
think
at
least
that's
the
way
you
know
we
are
approaching
it
right,
because
when
you
talk
about
standards
right,
I
think
it's
when
the
customer
wants
to
run
run
their
cloud
to
meet
standards,
they're,
looking
standards
across
the
board
right,
but.
D
You
know
I'm
not
I'm
not
particular
on
where
actually
this
all
fits
in,
I
don't
think
it's
you
know
as
long
as
the
word
gets
done
right,
I'm
I'm
not
going
to
insist,
it
has
to
be
in
one
argos
is
the
other
arc.
I
think
security
is
fine,
because
most
customers,
I
think
security-
is
the
first
one.
They
would
apply
this
to
anybody.
So
right.
A
Yeah
and
one
interesting
thing
which
wasn't
and
so
the
kubernetes
security
is
fairly
new,
and
this
I
I
didn't
even
realize
there
were
two
sig
securities.
Until
you
know
I
saw
the
kubernetes
security
and
then
there
was
a
cncf
security
and
I
think
robert
in
the
past,
you
were
always
mentioning
referring
to
the
cncf
one
and
I
could
never
find
it
on
the
kubernetes
slack
right,
and
so
I
think
that
was
confusing
for
me
in
the
beginning.
But
I.
A
What
they're
doing
and
they
collaborate
with
each
other
so
that
all
makes
sense,
but
yeah
we
can
decide
either
based
on
a
so
from
certainly
from
the
working
group.
Perspective
seems
like
a
broader
charter,
makes
sense
from
a
per
project
point
of
view.
We
can
decide.
You
know
whether
we
start
with
the
kubernetes
scope
and
then
add
on
other
tooling
and
other
support,
or
you
know
just
start
with
the
broader
scope.
In
some
cases.
B
A
B
Right
and
we
don't
have
to
get
in
the
weeds,
but
maybe
we
can
happy
to
take
it
on
the
slack,
but
I
think
from
a
governance
perspective,
I
guess
it
seems
like
we're
using
the
kubernetes,
github
and
repo
right,
but
we're
somehow
in
the
cncf
governance
framework.
So
I
guess
I'm
just
I'm
confused
as
to
like
who
are
we
right?
A
B
A
Yep,
it
makes
sense-
and
I
believe
this
in
our
at
least
the
initial
charter.
When
harvard
and
team
started
the
group,
you
know
they
had
listed
all
of
these
six
stakeholders,
so
architecture
of
multi-cluster
network,
node,
scheduling
and
storage.
So
I'm
assuming
there
was
some
discussion
with
all
of
these
sigs.
A
Interestingly,
security
is
not
listed
here,
which
you
know.
Obviously,
we've
been
working
closely
with
cigar
and
security,
so
yeah
so
anyways
we
we
can.
We
can
revisit
this.
You
know
with
guidance
from
so
kristoff
is
our.
You
know,
steering
committee
liaison
and
he'll
help
us
get
some
of
these
things
sorted
out.
B
C
B
Maybe
that's
just
visibility,
so
yeah,
I
think
you
know,
security
is
just
a
part
of
it
and
right
early
on.
We
did
talk
about
things
about
resource
policies
and
things
like
that.
So
that
said
from
a
practical
perspective,
if
you,
I
think
the
audience
that's
used
to
dealing
with
security
policy
is
the
audience
that
gets
it
first.
If
you
will.
A
Right,
okay,
all
right
so
more
to
more
to
come
and
motor
happen,
and
I
think
you
know
if
we
can
drum
up
some
interest
from
other
groups
on
some
of
these
projects.
Then
at
some
point
we'll
have
you
know?
Maybe
we
just
need
to
have
some.
I
don't
know
the
full
process,
but
kristoff
will
again
tell
us
so
that
I
think
there's
a
way
to
have
like
elections
or
votes
for
new
organizers
based,
and
we
should
you
know,
reach
out.
A
I
think,
there's
other
folks
interested
in
some
of
the
ascal
work
and
the
white
paperwork.
So
if
we
advertise
the
projects
based
on
that,
we'll
get
you
know,
so
I
think
for
each
project.
We
want
somebody
to
lead
that
and
then
we
want
organizers
for
the
group
who
can
do
the
overall
sig
collaboration
and
liaison,
and
all
of
that
right
so
we'll
have
to
get
that
sort
of
roster
in
place
at
the
right
time.
A
A
The
next
item
here
is
on
the
crd.
So
where
we
are,
is
you
know
right
now,
there's
a
few
pr
spending
and
we
were
stuck
because
we
had
nobody
to
be
able
to
review
and
merge
these
pr's.
But
now
robert
has
access,
and
so
ankai
took
all
of
the
work
that
you
did
and
you
know
resubmitted
that
on
the
golang
types.
So
that's
in
this
pr.
I
did
have
a
few
questions,
but
we
can
discuss
those
on
slack
or
if
we
can
come
back
to
that.
A
If
we
have
more
types
like
like,
I
had
posted
some
in
in
the
github
issue
itself.
So
maybe,
if
you
can
take
a
look
at
that
and
add
in
your
thoughts
but
the
if
you
can
get
this
pr
merged,
I
think
then
we
have
all
of
the
you
know.
The
work
that
you
did
to
for
aligning
this
with
pascal
at
least,
would
be
merged.
Yeah.
F
I
I
realized
we
missed
one
thing,
so,
yes,
we've
done
the
mapping.
I
have
all
also
to
check
against
the
schema
if
we
have
all
the
required
data.
So
if
we
use
the
data
to
generate
something-
and
if
we
do
not
have
all
the
required
data,
we
will
fail
the
the
validation
and
right.
We
cannot
use
the
the
oscar
object,
so
I
will
have.
I
have
that
to
do
as
well
to
make
sure
that
we
don't
need
to
add
anything
on
your
side
to
to
have
a
complete
validating.
Okay,.
A
A
Okay,
the
the
few
other
pr's
that
are
pending.
We
need
to
decide.
So
there
were
some
comments
on
the
on
the
document
about
adding
like
time
fields
and
adding
other
fields,
for
I
believe
it
was
like
resolution
and
things
like
that.
So
we
need
to
decide
if
we
need
those
or
we
don't.
I
think
time,
of
course
like
when
something
was
reported.
A
How
often
it
occurs
when
it
was
last
seen
that
is
required,
but
these
others,
I'm
not
sure
if
they're
required
and
how
we
would
use.
But
those
are
the
other
qpr's
that
are
pending,
which
we
have
to
decide
if
we
accept
them
or
not,
and
what
we
want
in
the
crd
versus
what
can
go
into
the
unstructured
data.
A
I
think
it
would
be
important
to
know
when
it
was
first
seen
as
well
and
then
so
first
scene,
timestamp
lasting
time,
sparing
and
how
many
times
in
that
you
know
has
it
been
seen,
is
the
three
things
right
that
was
suggested.
The
other
way
is,
of
course,
of
doing
it
as
like.
I
guess
start
and
end
is
also
first
and
last
or.
A
F
Yeah,
I
think
when
we
have
something
that
oscillates
right,
let's
say
that
it
changes
we
see
in
the
hour
and
comes
back
and
forth,
and
if
I'm
doing
this
over
one
week,
my
last
scene
first
scene
will
be
from
the
last
hour
because
that's
when
it
actually
changed
to
the
new
value
right.
So
I
I
lose
that
the
the
fact
that
this
I
have
a
an
issue
there
for
a
week
now,
because.
A
F
A
F
A
Right
so,
but
that
would
be
if
an
external
system
were
you
know,
pulling
and
putting
this
data
like
through
prometheus
or
something
again
like
the
intention
would
be
to
capture
the
current.
But
then
let
the
history
be,
you
know,
stored
in
some
external
system
in
a
histogram
or
other
metric
like
you're
suggesting
would
that
work.
F
Yeah
that
that's
what
I
try
to
I
think
we
try
to
achieve
here.
We
do
not
have
historical
data.
When
I
see
just
a
result,
we
don't
keep
historical
data.
Historical
data
would
be
kept
on
some
logging
tool
right
monitoring
tool
right
and
how
much
do
I
want
to
capture
within
a
given
sample
right
that?
That's
that's
the
question.
A
A
F
So
what
I
would
like,
as
a
as
an
admin
is,
is
to
have
this
in
the
summary.
So
when
I
have
the
summary
or
you
know,
or
maybe
even
that
that
occurrence
right
that
it,
it
tells
me
that
that
false
how
many
times
it
happened
right
in
in
the
past
14
days,
not
since
the
last
occurrence,
because
if
things
flip,
I
lose
that
that
that
was
the.
A
F
Yeah,
I
think
14
days
is
more
than
enough
right,
because
you
are
looking
at
the
spectrum
to
be
able
to
fix
something.
Maybe
even
maybe
48
hours
is
enough,
or
you
know
one
week
I've
seen
this
14
as
kind
of
a
magic
number
for
many
things.
That's
why
I'm
coming
up
with
that,
and
if
I
really
want
to
look
for
a
year,
I'm
not
going
to
look
at
the
current
sample.
F
A
D
One
of
the
things
I
want
to
kind
of
focus
on
is
you
know
we
have
all
these
various
policy
engines
right,
so
we
have
gatekeeper
and
then
we
have
qrno
and
I
wanted
to
see
how
we
can
at
least
create
some
positioning
or
you
know
how
to
bring
these
together
right.
So
because,
from
our
perspective,
within
red
hat,
we
are,
we
have
picked
up
gatekeeper
and
we
are,
we
have
incorporated
it
into
our
offering
and
we
want
to.
D
We
are
going
to
support
it,
etc,
right
and
then
I
jim
you
took
us
through
the
queue
now
right.
So
now,
I'm
kind
of
saying
you
know
how
does
that
relate
to
this
right
so
also,
I
wanted
to
share
how
our
policy
framework,
which
we
are
open
sourcing,
is
integrating
with
all
these
different
engines
and
by
the
way
we
have
created
a
policy
for
kiwano
now
so
so
I
think
I
think
so.
A
Yeah,
definitely
we
can,
you
know,
discuss
it
early
or
if
you
even
want
to
have
a
you
know,
and
maybe
there's
a
natural
sort
of
segue
into
this.
One
of
the
things
that
was
proposed
was
having
like
a
white
paper
with
some
positioning
document
and
policy
reporting
and
policy
tools.
Yeah.
Maybe
that's.
B
In
just
a
historical
context-
jim,
I
think
you
may
recall
this,
but
when
we
first
started
talking
about
the
policy
report,
it
was
actually
a
compromise
position
from
from
starting
this
conversation
that
we
absolutely
didn't
want
to
boil
the
ocean
and
try
to
spec
what
a
policy
engine,
interface
or
or
specification
should
look
like
without
a
little
bit
more
community
involvement,
and
we
decided
the
first
way
to
do.
That
was
to
kind
of
define
the
output
yeah.
D
But
I
like
this,
this
white
paper
right,
so
maybe
the
white
paper
can
we
can
specify
the
overall
building
blocks
of
the
pulse
architecture,
and
the
policy
report
becomes
one
of
the
pieces
right
and
then
I
think
I
think
I
love
to
contribute
to
that
one:
okay
cool.
Maybe
we
can
tee
this
up
in
the
next
call,
which
is
in
a
couple
of
weeks.
B
A
So
definitely
you
know,
let's
you
know,
go
through
what
I
started
capturing
in
the
white
paper
and
we
could
even
collaborate.
This
is
just
more
intended
to
be
a
working
document
at
this
point
to
see
what
do
we
want?
What
is
the
scope
of
the
white
paper
because
again,
if
we
make
it
too
large
it'll
just
take
longer?
D
A
All
right,
yes,
so
and
anka,
we
can
kind
of
discuss
this
more
offline
too.
My
only
concern
with
you
know
again,
adding
in
any
form
of
history
is
you
know
we
have
in
the
past,
tried
to
keep
the
report
just
to
current
information,
so
certainly,
if
there's
an
in
cluster,
prometheus,
etc.
That
could
be
looking
at
this
every
10
seconds,
every
minute,
picking
up
these
values
and
then
showing
any
historical
occurrences.
A
A
A
Right
so
that
that
was
the
thinking
and
it's
this
is
very
typical
in
monitoring
systems.
You
have
like
a
first
seen
last
scene
in
the
number.
So
let's
say
if
the
monitoring
system
is
collecting
every
five
minutes,
you're
just
saying
that
I
yeah
I
saw
it.
You
know
in
that
first,
in
a
when
it
was
seen
when
it
was
last
seen
and
occurrences,
but
I'm
I'm
fine
with
just
keeping
a
single.
F
You
assume
that
we
have
the
current
the
last
report
and
I
override
that
last
report,
but
I
can
still
use
the
information
from
the
last
report,
so
I
copy
the
first
scene.
I
I
update
last
seen
and
I
in
increase
increment
occurrences.
That's
that's
the
idea
here
right,
so
I
don't
have
any
other
support
other
than
that.
A
F
Good,
I
I
think
I
yeah,
I
think
it
makes
sense,
we
keep
it
simple
and
typically,
the
monitoring
system
will
have
alerts
associated
with
that,
so
we'll
need
to
have
more
in-depth
analytics.
So
if
that
type
of
flip
that
I
mentioned
occurs
will
not
be
detected,
you
know
at
at
the
policy
location,
it
will
be
detected
at
the
right.
Okay,.
A
F
B
F
A
F
F
F
F
A
All
right,
so
one
other
quick
update,
so
we
have
you
know
I
enrolled
in
the
linux
foundation
mentorship
program
and
this
gets
us.
You
know
an
a
mentee
or
an
intern
to
work
with
us
for
three
months
and
the
project
that
I
had
proposed
was
you
know,
taking
group
bench
and
writing
an
adapter
to
capture
the
results
and
produce
the
crd.
B
You
know
any
kind
of
current
activity
and
more
about
just
imposing
a
set
of
requirements
on
resources
and
they're
in,
in
particular,
their
kubernetes
support
is
pretty
minimal,
so
I
think
it
for
their
kubernetes
specifically.
I
think
they
would
generally
just
consume
reports,
so
I
don't
know
that
they're
going
to
be
a
good
producer,
but
but
that's
okay.
We
need
more
consumers
too
sure.
B
A
A
Yeah,
so
good
bench
and
falco
would
both
produce
yeah
reports
periodically
is
the
idea,
okay,
and
it
should
be
pretty
interesting
because
that
will
bring
get
cis
compliance.
You
know
into
all
of
those
would
be
now
available
as
reports
which
we
can
then
any
upstream
system
like
whether
it's
you
know
cloud
custodian
or
other
systems
can
pick
up
and
process.
A
You
know
having
covering
like
image
image
scanners
configuration
checkers
like
you
know
they
were
using
polaris.
I
believe,
and
then
you
know
runtime.
Of
course,
security
like
I've
listed
falco
here,
but
there
could
be
others
so,
and
I
put
you
know:
control
plane,
security
and
worker
node
security
with
cis
benchmarks
and
quick
bench
as
the
tool
there.
So
there's
some
interesting
set
of
things
and,
of
course,
now
with
supply
chain
security
concerns
as
image
signing
is
becoming
more
and
more
a
hot
topic
of
discussion.
A
F
F
So
I
added
as
part
of
the
the
the
policy
parameters
we
have
category.
We
have
severity
and
so
on
I
ordered
source
and-
and
that
can
be
the
version
in
git,
so
we
are
able
to
relate
to
that.
So
that
will
give
me
we
don't
need
to
update
anything
in
the
metadata,
because
once
I
have
git,
I
have
the
whole
history
who
updated
it.
Who
is
the
contact?
So
we
don't
need
anything
else.
Besides
that
version.
F
Now,
when
we
generate
that,
I'm
not
sure
if
the
the
policy,
the
the
check,
will
have
that
visibility
in
the
in
the
policy
version,
I'm
sure
if
the
policy
comes
already
with
that
information
to
use
it
in
result.
So
now
you
know
better
how
to
track
that,
but
I
think
if
we
just
keep
the
version
that
that
should
be
enough.
My
my.
A
Yeah,
so
certainly
you
know-
and
I
know
there
was
a
brief
discussion
on
also
on
slack
about
this.
The
question
is,
you
know,
yes,
git
would
be
a
best
practice
and
certainly
it
makes
sense
to
treat
policy
as
code,
but
does
that
match
the
reality
of
what
we
see
in
a
lot
of
enterprises,
and
you
know
so
for
the
policy
report.
I
think
it
would
be
good
to
have
that
option
to
to
have
some
fields
where
this
could
be
added.
The
question
is:
do
we
want
to
you
know?
A
F
A
Yeah,
so
even
with
opa
and
kiverno
I
mean
certainly,
yes,
you
can
store
those
in
git,
but
do
you
have
to
versus?
Are
you
consuming
them?
You
know
those
libraries
from
like
directly
from
like
say,
for
example,
I
don't
know
for
sure,
but
I
believe,
like
styra
also,
you
know
sells
like
subscriptions
and
they
can
release
libraries
right.
So
the
source
may
not
necessarily
be
a
git
repo
that
an
enterprise
is
managing.
A
F
We
can
have
the
the
source,
so
all
skull
today
allows
the
source
to
be
an
href
of
that
particular
sure
right.
So
not
necessarily
that,
but
I
what
I
think
the
point
is
that
we
need
to
have
some
kind
of
version
to
to
associate
the
validity
of
the
policy
that
we
the
result
of
the
of
the
of
the
check
right
with
the
validity
of
the
policy
itself.
A
And
there's
two
fields
we
have
already
in
each
result
right,
so
the
results
can
have
a
reference
to
a
rule
and
to
a
policy,
and
they
are
free
form
right,
they're,
just
text.
So
if
you
want
to
put
a
git
hash
in
there,
you
can,
if
you
want
to
put
a
url
in
there,
you
can.
If
you
just
want
to
identify
names,
you
can
do
that
right.
So
we're
not
really
mandating
what
goes
in
there,
because
different
engines
may
have
different
ways
of
managing
it.
F
F
B
B
A
A
So
maybe
we
just
you
know,
add
some
examples
in
the
description
and
and
broaden
this
description.
To
say
it
doesn't
have
to
be
a
name
could
be
some
way
of
uniquely
identifying
the
rule
and
the
version,
and-
and
I
guess
the
assumption
here
is-
policies
are
organized
as
a
set
of
rules,
but
we
can
even
change
that
if
we
want
right
and
combine
the
two
or
keep
two
separate
fields.
E
So
if
if
you
want
to
basically
simplify
this
at
a
very
high
level
and
say
here
is
the
policy
and
here
is
the
rule.
I
think
this
would
perfectly
work
right.
But
if
you
want
to
go
down
levels
of
complexity
like,
for
example,
how
you
typically
see
things
like
pci,
dss
laid
out
or
mislaid
out
right,
there
is
a
hierarchy
and
they
are
not
policies.
They
are
controls.
I'm
not
sort
of
saying
the
same,
but.
F
We
have,
we
have
the
barrage,
we
have
here
a
category,
so
I
think
that
provides,
I
think,
the
the
one
level
of
nesting
right
so
in.
If
I'm
looking
at
a
cube
right,
I
have
the
five
sections,
so
I
have
the
control
plane,
the
worker
node
etcd.
So
those
would
be
the
categories
and
then
we
seen
those
right.
I
have
the
the
various
rules.
E
F
A
F
It's
a
different
level
right,
it's
a
different
level.
So
if
you
think
of
the
cube
bench
right,
I
have
the
the
rules
right,
the
cis
benchmarks
are
rules
and
then
they
are
mapped
to
the
cis
controls.
So
the
control
is
an
another
level
of
detail
and
nist
controls
and
we
decided
that
the
policies
themselves
do
not
carry
are
control
agnostic.
I
just
checked
them
and
there
is
another
entity
that
will
have
the
knowledge
of
what
maps
to
what
that's.
A
All
right
so
yeah,
let's
let's
decide
on
that
and
you
know
we
can
streamline.
If
you
want
to
combine
into
one
field.
That
may
be
good
too
yeah,
but
I
don't
see,
I
don't
think
we
changed
anything
there.
It's
still
policy
and
rules
from
the
in
the
latest
commit,
but
if
we
want
to
we
can
you
know
again.
A
B
A
F
A
Okay,
so
maybe
what
we
should
do
you
know
anka
and
robert.
If
you
want,
we
can.
You
know,
set
up
a
separate
working
section
just
to
finish
up
on
the
crd,
and
you
know
like
if
you
do
that
either
later
this
week
or
early
next
week.
I
think
it'll
be
good
to
complete
this
and
get
it
merged
in
because
there's
just
a
few
things
pending
and
we
probably
just
need
a
30
minutes
or
hour
focus
time
on
this.
A
Okay,
all
right,
so
let's
do
that
and
you
know
I'll
propose
sometimes,
and
we
can
get
that
done
and
then
so.
The
next
thing
you
know
I
don't
want
to.
We
have
just
10
minutes
left,
but
just
to
kind
of
introduce
you
know.
So
in
our
last
meeting
we
talked
about,
potentially
you
know
doing
this
white
paper,
and
we
were
just
discussing
that
earlier
too.
So
I
did
send
out
a
draft
and
I
think
I
immediately
got
stuck
on
okay.
What
is
the
so?
It's
not
a
draft
for
a
white
paper.
A
Here
we
have
cis
benchmarks
and
the
tool
is
good
bench
for
container
images.
There's
a
bunch
of
image
scanners
like
claire
and
trivia
and
others
image
signing
yeah,
we'll
have
to
research
this
more
and
then
for
configuration
management.
There's
opa,
gatekeeper,
kiberno
polaris,
which
seems
to
do
only
scans,
not
not
admission
control.
A
So
anyways
we
need
to
decide
in
real
life.
If
here,
the
question
is:
do
we
want
to?
You
know
even
talk
about
specific
tools,
because
you
know
that
would
be
the
challenge.
If
we
don't
want
to
give
preference
to
one
tool
versus
another,
but
it's
nice
to
know
what's
available
and
what
fits
where
so,
there
is
value
for
users
right,
but
we
don't
want
to
kind
of
seem
biased
in
any
official
publication.
A
So
I
think
those
are
concerns
to
address
and
think
about.
So
I
would
strongly
recommend
if,
if,
if
you
haven't,
please
take
a
look
at
the
cloud
native
security
white
paper,
look
at
the
process
that
they
followed
and
we
need
to
decide
on
what
we
do
here.
The
first
question
is
who's
this
paper.
For
and
what
should
we
cover.
E
May
make
it
difficult
for
people
to
understand
right
again
when
I
say
people,
because,
for
example,
there
is
a
there
is
a
working
group
in
cloud
security
alliance
that
focuses
on,
let's
say
continuous
audit
metrics,
which
is
a
very
similar
charter
to
what
we
are
talking
about
here
right,
but
they
look
at
it
much
more.
Their
purview
is
very,
very
different
right.
I
mean
they.
They
look
at
this
much
more
holistically
at
a
cloud
solutions,
provider
and
based
on
their
star
certification.
E
E
E
A
No,
so
there's
no
central
registry
or
anything
like
that,
they
would
just
have
to
incorporate
the
policy
report
as
part
of
their
tool
chain
and
either
through
an
adapter
or
native
support
of
reports.
So
it's
all
of
these
tools
are
reporting
in
some
format.
Today,
the
question
is,
if
they're
running
in
kubernetes,
do
they
want
to
adopt
this
reporting
structure
or
come
up
with
their
own,
and
a
lot
of
tools
today
have
their
own
independent
structure
right,
like
good
bench
produces
json
can
produce
text
reports
things
like
that.
B
Why
and
then
what
am
I
trying
to
accomplish
with
all
this
right,
because
otherwise,
it's
easy
to
get
lost
in
the
details
of
exactly
how
we
hook
up
all
the
technology
parts,
but
I
thought
this
was
kind
of
a
good
chance
to
come
up
for
air
and
explain
it
to
kind
of
like
you
know
someone,
so
maybe
the
audience
isn't
the
cxo,
but
maybe
it's
the
person
writing
the
report
for
the
cxo
says
like.
Why
should
we
do
any
of
this
right
right?
B
A
Okay,
yeah
and
raj.
I
agree
with
your
point
on
the
scope.
I
was
thinking
along
much
the
same
lines
to
say:
okay,
what
could
be
something
tangible
and
like,
let's
say
if
we
were
to
say
we
want
to
get
something
published
in
three
months
right
taking
on
cncf
just
seems
like
a
fairly
ambitious
endeavor
in
three
months
or
in
a
quarter.
A
But
if
we
focus
on
kubernetes
and
describe
you
know
what
is
kubernetes
policies
like
we
can
start
with
some
list
of
categories,
give
sample
tools
based
on
for
certain
date
and
time
and
say
this
is
what
we
know
of
in
the
landscape,
but
then
also
talk
about
where
the
report
fits.
How
policy
engines
can
leverage
it
we
can.
We
can
go
into
more
details
around
that
if
we
just
focus
on
kubernetes.
B
I
I
think
it
has
to
be
rooted
in
kubernetes,
I
mean
as
a
substrate,
for
how
policy
I
mean
we're
implementing
this
for
kubernetes.
That
said,
I
think
you
know
the
ibm
tools.
You
know
cloud
custodian
all
these
have
a
more
right
holistic
view
of
the
enterprise,
so
I
mean
I
think
it's.
I
think
we
can
be
clear
that
this,
the
kubernetes
is
a
concrete
instantiation
of
everything
we're
talking
about,
but
that
the
design.
C
A
A
F
A
A
F
A
No,
so
that
would
be
so.
We
would
publish
the
crd
right
and
then
tools
would
write
or
we
would
you
know,
kind
of
sponsor
writing
adapters
for
various
tools
within
cncf,
but
then
the
mapping.
We
have
not
committed
to
saying
that
we
would,
you
know,
write
some
implementation
to
map
that
to
a
scale
it
would
be
up
to,
like
the
you
know,
other
operators
or
other
tools
to
do
that.
We
could
probably
have
another.
You
know
if
we
want
to
document
some
more
details
on
that
mapping.
We
can
but
that's
not
something.
B
F
Right
right,
where
am
I
going?
You
are
the
pr
my
goal
was
to
expose
natively
the
the
oscar
right,
so
the
the
we
have
right
now,
the
that
I
don't
know
it's
jason
or
right
in
in
with
the
fields
that
we
have
available,
and
you
know
to
have
the
the
similar
a
similar
observation
right
in
the
format
of
oscar
right
to
have
two
two
available.
F
B
B
E
But
I
I
think
anka
is
a
good
point.
I
think
the
point
here
is
that-
and
this
need
not
be
part
of
the
crd
and
I
think
that's
what
we
are
discussing,
but
it
has
to
be
an
helper
function
right
that
map
somebody
has
to
be
able
to
visualize
the
output
of
the
policy
crd
to
something
tangible,
and
I
think
what
I'm
hearing
is
that
what
she's
saying
is
something
tangible
is
the
oscar
format.
A
B
No
problem,
okay,
okay,
what
gave
me
clarity
rises?
I
was
looking
at
exactly
this
like
how
do
I
get
access
to
this?
The
reality
is
by
being
the
customer
resource
and
exposing
that
to
kubernetes
as
a
customer
resource,
you
already
get
all
the
benefits
of
a
concrete
data
element.
You
get
access
via
the
kubernetes
api.
You
don't
have
to
write
anything
special
because,
like
when
I
first
went
in
this
was
like
okay.
What
do
I
have
to
write
you
know?
Do
I
have
to
write
a
controller?
B
E
A
E
I
want
to
be
very
clear:
that's
not
what
I
said.
I
am
not
saying
that
the
output
should
be
in
an
ascal
format.
That's
not
at
all
what
I'm
saying.
I
think
what
I
heard
was
that
I
think,
which
is
what
jim
was
saying,
is
that
maybe
we
should
sponsor
some
helper
functions
right
for
people.
I
think
the
core
of
what
we
are
discussing
in
terms
of
the
crd
scope
is
perfectly
fine.
I
I
don't
think
there
is
any
disagreement.
E
B
I
guess
I
kind
of
I
mean
the
proof
is
in
the
pudding,
let's
I'll
I'll,
take
a
first
stop
at
the
the
code
to
do
that
and
let's
see
if
there's
enough
there,
I'm
just
assuming
that
that's
like
you
know
I
mean
I
guess
not
to
trivialize
it
too
much.
But
that's
like
you
know,
10
lines
of
code.
So
maybe
that's
a
helper
function.