►
Description
Kubernetes Policy WG CNCF Security SIG Policy Team Meeting 2021-04-28
A
A
A
B
C
B
A
A
C
B
B
B
A
A
A
B
All
right
so
looks
like
the
only
item
we
have
on
the
agenda
today
is
to
go
through
the
policy
white
paper
outline.
So
we've
discussed
this
in
a
few
prior
meetings
and
I
think
the
intent
was
to
get
to
a
point
where
we
have
an
outline
and
then
we'll
transfer
the
outline
into
a
repo
or
a
folder
in
our
git
repo,
where
we
can
kind
of
collaborate
and
pick
on
different
sections.
B
So
here's
what
some
of
us
you
know
worked
on.
We
had
a
breakout
session
also
last
week
and
came
up
with
in
terms
of
the
so
I
kind
of
went
and
cleaned
up
a
few
of
the
things
moved
a
bunch
of
the
notes
and
other
kind
of
placeholders
into
the
detail
section
but
and
we
can
revisit,
but
what
the
outline
looks
like
at
this
point.
B
You
know
something
like
this.
I
think
there's
about
three
main
sections,
and
maybe
there
needs
to
be
one
more
which
we
can
talk
about
I'll
mention
what
I
was
thinking
of
there.
It
seems
like
the
main
sections
would
be
the
scope
of
where
the
policy
applies
right.
So
we
talked
about
the
cluster
components.
B
Container
images,
resources,
resource
configurations,
the
runtime
of
the
cluster
components
itself,
and
then
we
had
a
placeholder
for
multicluster
right
to
see
if
there's
anything
that
needs
to
be
called
out
there,
and
so
that's
in
the
policy.
You
know
I
just
titled
that
scope
or
policy
scope.
We
can
sort
of
change
these
and
get
more
feedback.
B
Then
there
was
an
architecture
or
how
it
works.
Sort
of
details,
type
of
section
right,
which
I
think
jaya
has
mostly
kind
of
filled
in
the
major
components
which
we
would
be
looking
at.
So
there's
the
definition
language.
The
authoring
point
like:
where
are
these
policies
managed
and
stored
like
upstream
githubs,
repo
or
some
other
management
plan?
B
E
Hello,
this
is
radna,
I
just
joined
sorry,
I
was
late.
I
I
do
think
we
need
to
expand
this
mappings
and
integration.
Section
detection
is
important
right
when
a
policy
violation
happens,
so
a
subsection
under
the
mappings
and
integration
or
a
separate
chapter
on
detection
or
policy
violations
or
changes
that
are
happening
can
be
detected
on
from
a
cyber
perspective.
A
I
I
agree
I
was
wondering:
do
we
need
looking
at
the
outline
level
jim
do
we
need
kind
of
like
a
policy
life
cycle
which
would
include
like
the
the
detection
of
policy
violations
or
policy
enforcement?
I'm
just
wondering
is
there?
Is
there
right,
maybe
there's
an
overview?
Maybe
it's
just
a
a
sentence.
Maybe
it's
just
a
a
diagram,
but
do
we
kind
of
need
to
like
enumerate
the
phases?
So
you
know
policy
definition,
policy,
deployment,
policy
enforcement
policy,
violation,
detection
policy,
not
violation
detection.
I
don't
know
what
the
right
word
is
success.
A
B
Right
yeah,
so
there
was
some
aspect
of
a
life
cycle
in
these
you
know
components,
but
maybe
we
could
in
the
architecture,
perhaps
there's
a
component
section
and
then
there's
a
life
cycle.
You
know
to
show
both
and
then
some
mappings
and
integration
yeah,
I'm
not
sure
what
exactly
the
intent
of
that
was,
and
I
don't
that
to
your
point-
I'm
not
sure
if
detection
would
fit
in
there
or
if
it
should
be
in.
B
E
Integration
with
the
steel
layer
as
well
right,
every
kubernetes
might
have
some
kubernetes
implementations
will
have
istio
mesh
right
service
mesh
and
if
we
don't
want
to
call
istio,
that's
fine,
but
some
integration
of
policies,
because
you
don't
want
to
have
conflicting
policies
at
different
layers,
so
I
think
mappings
and
integrations
we
should
specify
which
all
integrations
are
really
focusing
on.
I
mean
from
a
cyber
perspective.
These
things
make
sense,
definitely
but
which
all
integrations
are
we
addressing.
B
B
E
F
Yeah
hi,
this
is
jaya.
I
think
the
mapping
and
integrations
was
more
focused
on
things
external,
like
jim,
was
saying
to
kubernetes
right.
So
if
you
have
a
customer
who
is
who
has
existing
tools
that
they
use
to
manage,
you
know
compliance
or
other
processes
right
that
they
have?
How
do
you
integrate
this
architecture
into
that
right?
So
so
that
was
the
focus.
There
is
something
like
service.
F
B
A
B
Right,
okay,
yeah!
No,
that
that
makes
sense,
so
we
just
need
to
understand
what
what
we
want
to
cover
in
each
section.
I
think
here
really
the
the
goal
was:
okay,
now
that
we
have
these
policies,
we
have
the
reports,
the
violations,
who's
going
to
care
about
them,
and
how
do
we?
You
know
kind
of
use
them
right.
D
E
E
A
Right,
I
think
the
the
the
idea
well
a
lot.
I
mean
you're,
absolutely
right.
Most.
Cyber
security
today
is
detective
and
remediation
based,
you
know,
and
vulnerability,
based
in
particular
in
a
lot
of
cases
but
yeah.
I
think
there
is
an
evolution
towards,
especially
in
kubernetes
you're
you're,
a
state
based
system
right,
your
declarative
system.
So
if
you,
if
you
declare
your
policy
correctly
and
that's
enforced
by
the
infrastructure
as
code,
then
your
you,
you
in
a
sense
shouldn't,
have
any
vulnerabilities.
You
shouldn't
have
any
violations
right.
D
A
D
No,
I'm
not
against
that.
I
I'm
I'm
not
questioning
that.
What
I'm
saying
is
that
the
the
point
I'm
trying
to
make
is
that
I
see
that
orthogonal
right.
What
I
mean
is,
irrespective
of
what
policies
we
have
in
the
life
cycle.
We
talked
about
from
a
policy
perspective
right
whether
you're
authority
enforcer.
D
You
can
do
this
enforce
this
through
three
mechanisms.
Right,
you
can
put
that
ahead.
I
mean
we're
talking
about
the
cicd
pipeline
and
that
as
a
use
case,
for
example,
that
is
a
preventative
type
of
mechanism
least
in
most
cases,
then
you
can
have
detective.
We
have
not
talked
about
corrective
at
all
right
sort
of
the
gitops
based
remediation
workflows.
D
My
so
my
question
is:
should
we
expand
this
to
aradhana's
point
to
cover
these
other
things,
because
if
you
just
call
out
detection,
I'm
just
trying
to
understand
what
does
that
mean
right?
What
does
that
mean
for
preventative
sort
of
policies
and
correctives?
Do
we
explicitly
call
out
that's
why
even.
E
A
D
D
D
A
Know
I
I
absolutely
agree
with
the
terms
I'm
literally
trying
to
wrap
my
brain
around
like
at
the
kubernetes
level,
because
I
mean
you
know.
The
goal
of
this
white
paper
is
to
kind
of
get
a
little
bit
under
the
the
details
and
and
drill
down
into.
How
do
you
actually
implement
this?
You
know
not
prescriptively
here's
the
code,
but
you
know
taking
it
along.
D
Policy,
typically,
an
access
controller
termination
control
is
a
very
classic
example
of
detective
policy.
Right
you
have
turned
the
user,
the
user
continues
to
have
role
bindings
right,
rr
super
and
when
access
right
into
a
cluster-
and
you
want
you-
are
trying
to
evaluate
if
those
access
are
valid.
That's
an
example.
The
second
thing
could
be,
for
example,
that
you
have
a
cluster
and
you
do
not
have
logging
enabled
on
that
cluster
right.
You
don't
have
stack
drivers,
you
don't
have
azure
log
analytics,
so
things
like
this
right,
which
is
post
facto,
we
are
you're.
F
E
Both
both
are
fine
and
and
one
one
comment.
I
have
that
there
jaya
and
raj
is
that
a
great?
If
we
have
those
detective
policies,
then
we
should
have.
We
should
identify
how
those
those
detections
are
remediated.
Is
there
automation
being
built
around
that
as
well?
So
I,
I
think,
detection
and
maybe
detective
policies
can
be
a
subset
of
the
detection
itself,
right
they
they're
kind
of
correlated
and
then
for
those
detective
policies.
D
D
B
B
Would
I
would
add
to
that,
though,
is
what
we're
seeing?
Is
that
really
every
policy,
even
a
policy
which
is
intended
to
be
enforced,
needs
detection
because
there's
always
use
cases
where
you
you
want
to
do
the
additional
runtime
scan
right?
So
I
don't
think
it's
such
a.
You
know
concrete
categorization
in
that
sense,
because
as
you're
rolling
out-
and
this
goes
back
to
what
robert
was
saying
with
versioning
and
drift-
so
let's
say
there's
a
new
cv.
B
Now
you
want
to
roll
out
a
policy
there's
existing
workloads
in
most
cases,
you're
not
going
to
bring
down
those
existing
workloads
but
you're
going
to
detect
if
those
violate
the
new
policy
and
you're
going
to
take
some
remediation
action
which
could
spend
some
time.
So
I
think
both
it's.
What
we're
seeing
at
least
with
caverno
policies
is,
you
are
going
to
run
every
policy
even
if
it's
configured
to
block
it
still
has
a
component
where
it
will
detect
workloads
which
violate
that
policy.
B
E
F
Why
you
have
the
gatekeeper,
for
example,
has
both
admission
as
well
as
audit
correct,
use
cases
right
so
yeah.
That
makes
sense,
and
I
I
agree
with
our
other
on
the
remediation
aspect
right.
I
think,
whenever
possible.
Obviously
you
know
not.
Every
policy
can
auto
remediate,
but
if
there's
a
way
to
do
it,
that's
an
option
that
we
need
to
think
about
yeah.
B
And
that
remediation
could
also
be
in
a
separate
system.
So
maybe
this
is
this
is
just
you
know.
It's
detected,
you
remediate
and
your
git
or
upstream
repo
and
you
push
changes,
but
there
needs
to
be
some.
You
know
kind
of
guidance
on
remediation
for
once.
Violations
are
reported
things
like
that:
yep,
okay,
so
yeah
now
this
looks
good.
I
think.
B
Okay,
so
integrations.
We
briefly
mentioned
things
like
service
mesh.
Are
those
just
part
of
kubernetes
workloads
or
should
we
I
mean?
I
understand
it's
not
a
application,
it's
more
of
a
infrastructure
component,
but
it
is
in
in
some
ways
it's
a
bunch
of
crds
right,
so
is:
do
we
need
to
give
that
special
treatment,
or
do
we
just
say
it's
a
kubernetes
resource,
it's
covered
as
part
of
any
resource
policy.
A
F
B
F
B
So
yeah
you're
very
right,
like
how
do
I
know
if
my
cni
is
even
working
right,
because
I
may
have
all
the
network
policies
configured.
But
if
my
cni
has
a
issue
yeah,
I
don't
know
right
so
I
yeah
and
that
that
is
slightly
more
difficult.
Those
type
of
things
are
harder
to
audit
right
because
you
would
actually
need
something
like
sona
boy
or
another
runtime
tool,
which
is
doing
behavioral
tests
to
make
sure
that
things
are
working
as
expected.
B
B
D
D
Project
will
help
or
if
you're,
talking
about
regulatory
or
maybe
not
regulator,
compliance
if
you're
talking
about
a
sort
of
industry,
compliance
right,
security,
compliance,
something
like
we
see,
ideas
or
high
trust,
I
think
it
will
be,
and
then
we
can
obviously
expand
that
to
others
right.
But
I
think
the
more
specific
we
are
the
better
it
is.
B
D
E
A
C
A
C
Gonna
strongly
disagree
because
devops
is
supposed
to
always
include
security
in
the
pipeline
and
the
reason
people
you
know
started
using
the
devsecops
term
is
because
it
keeps
getting
forgotten.
So
so
a
devops
pipeline
should
include
security
scanners
and
it
should
include
a
security
dashboard
for
managing
the
results.
So
it's
if,
if
you're
doing
security,
only
on
the
upside
of
of
devops
you're
missing,
I.
C
B
C
F
C
A
A
B
So
we
have
called
that
out
as
our
primary
audience.
So
from
you
know,
from
the
mappings
point
of
view,
I
think
the
way
at
least
I
was
thinking
of
it
is
everything.
We're
saying
is
targeted
to
the
devsecops
team,
but
then
they
have
to
realize
that
there's
these
other
mappings,
including
perhaps
central
security
which
needs
you
know,
periodic
reports
or
some
visibility
into
what's
going
on
in
the
kubernetes
world
right,
at
least
that
seems
like
the
view
we
have
taken
here
like
we're
going
from
the
practitioners
out.
C
C
B
B
C
B
Yeah
that
would
be
good
to
call
out
and
see,
like
you
know,
give
it
so
we
we
had
a
discussion
on.
I
think
what
we
decided
is.
We
could
potentially
reference
projects,
especially
cncf
projects,
but
ideally
we'll
just
stay
away
from
company
write
any
any
product
or
even
perhaps
projects
because
things
change
and
once
the
paper
is
out,
we
don't
want
to
kind
of
look
like
there's
any
favorites
or
anything
like
that.
Right,
yeah.
F
F
B
Yeah,
so
what
we
can
do
is
we
will?
You
know
we
can
formalize
this
outline
or
just
at
least
create
the
sections
in
a
git
repo,
and
we
like
we'll
just
use
markdown
for
authoring.
The
other
thing
we
could
also
do
is,
I
don't
know,
and
robert
and
aradna,
I
think
both
of
you
also,
you
know,
work
with
security.
So
would
it?
Is
it
too
early
to
kind
of
get
feedback
on
this
outline
or
should
we
also
have
a.
E
Lead
meeting
on
friday,
so
I
will
share
this
there
as
well,
because
I
give
update
leads
on
this
policy
working
group-
okay
and
we
can
share
in
the
next
wednesdays
meeting
today,
it's
kind
of
too
soon
to
put
it
on
the
agenda,
but
we
can
start
working
on
this.
While
that
is
happening
right,
nothing
is
stopping
us
from
making
progress
here
right
exactly.
C
E
C
A
C
B
E
B
B
C
A
In
my
mind,
I
mean
this
isn't
like
the
defining
mission,
but
I
kind
of
think
it.
The
the
cncf
security
is
kind
of
like
the
over
arching,
like
all
things
cloud
native
right,
we're
kind
of
at
the
middle
ground.
Of
you
know,
policy
applied
to
kubernetes
and
related
stuff,
and
then
the
cube
security
is
super
focused
on
you
know,
almost
at
the
api
level
layer,
that's
at
least
how
I
organize
it
in
my
brain.