►
From YouTube: CNCF Security SIG Policy Team 2020-07-22
Description
CNCF Security SIG Policy Team 2020-07-22
C
D
D
D
E
D
F
A
A
G
B
B
And
and
then
I'm
going
to
ask
daniel
to
actually
demonstrate
sort
of
what
we
have.
So
the
motivation
behind
our
starboard
project
was
to
say:
we
have
all
these
security
tools,
aqua
tools,
other
third-party
tools,
open
source
tools,
commercial
tools,
and
they
all
have
you
know
different
user
interfaces.
They
all
create
reports
in
different
formats
and
this
is
non-ideal
for
the
the
user.
B
So
the
idea
with
starboard
is
to
bring
the
reports
into
customer
resource
definitions
inside
kubernetes
and
we
have
starboard,
which
is
a
cubecontrol
plugin,
to
provide
a
common
cli
into
the
different
tools
and
we
started
off
with
four
different
types
of
security
report
that
we've
got
in
the
initial
release
of
starboard.
It's
very
much,
you
know
experimental,
but
you
know
that's
how
you
how
you
find
out
what
works
right
by
trying
it.
B
So
we've
pulled
all
those
different
tools
and
the
idea
is,
it
would
be
extensible
to
other
kinds
of
tools,
we'd
love
to
have
lots
of
different
security
tools
here
that
information
gets
populated
into
the
crds
and,
as
I'm
sure
daniel
will
show
you,
we
use
labels
to
associate
the
security
reports
with
the
kubernetes
resources
that
they
relate
to
so
hopefully
that
kind
of
set
the
scene
and
maybe
daniel.
I
can
ask
you
to
show
share
it
in
action.
H
H
H
I
have
already
done
that,
but
just
to
show
you
that
we
already
integrated
there.
So
this
is
the
the
main
interface
for
interacting
with
security
tools,
but
then,
instead
of
learning
each
and
every
tool,
its
interface
input
and
output
specification,
we
wanted
to
make
it
easier.
So,
for
example,
as
a
first
step,
you
need
to
initialize
the
start
board.
H
H
So,
as
you
can
see,
we
have
four
crds.
Some
of
them
are
namespace.
Some
of
them
are
cluster
scope.
If
we
walk
through
them,
it's
like
a
cis
kubernetes
benchmark.
Those
are
typically
run
on
nodes.
I
will
run
such
a
scanner
in
a
second,
so
you
run
it
on
a
node
since
node
a
native
resource
is
cluster
scope.
Also,
this
report
is
cluster
scoped.
H
H
There
is
no
such
a
built
in
resources
cluster
in
kubernetes,
but
anyway
this
will
be
like
a
namespace,
sorry
clusterscope
report
and
then
for
vulnerabilities.
The
better
name
would
probably
be
vulnerabilities
report,
but
this
one
is
namespace
right.
We
could
check
for
vulnerabilities
a
container
images
of
a
given
workload.
So
now,
once
we
initialize
the
the
starboard,
we
could
create
a
deployment.
H
So
now
we
are
asking
starboard
to
find
vulnerabilities
right
behind
the
scenes.
We
will
create
a
kubernetes
job
and
this
job
will
run
3d
a
containerized
version
of
3d
to
pull
an
image,
scan
it
and
create
an
instance
of
the
vulnerability
resource,
and
I
will
also
show
you
that
we
are
using
label
selectors
to
link
back
the
report
to
the
to
the
actual
controller.
H
H
H
So
those
are
the
labels
and
if
we
scroll
down
to
the
report,
that's
the
the
report.
Stanza
is
where
the
report
starts.
So
we
have
the
artifacts.
As
you
can
see,
we
have
scanned
the
engines
1.16,
we
use
3d
version,
0
9
1,
and
we
found
a
bunch
of
vulnerabilities.
It's
just
a
quick
summary,
but
then
you
can
also
scroll
and
see
what
other
details.
H
So
in
the
similar
way,
we
could
use
starboard
to
find
config
misconf
like
in
potentially
insecure
configuration
of
your
deployment
descriptor.
So
if
we
say
starboard,
polaris,
probably
we'll
make
change
it
to
some
like
similar
command
to
define
vulnerabilities
like
config
update,
but
for
now
it's
just
polaris
knock
off
better
name
and
also
we
are
working
with
fairwinds
folks
to
specify
the
deployment
it's
not
ready
yet
because
the
polaris
did
not
allow
us.
Polaris
is
scanning
the
whole
cluster,
all
workloads
across
the
cluster,
but
once
we
run
it,
you
will
see
the
reports.
H
H
You
will
see
that
there
is
a
oops.
You
will
see
that
there
is
a
report
and
a
polaris.
We
are
actually
reusing
the
model
that
fairwind
came
up
with
it's,
it's
checking
the
deployment
descriptor
at
the
pod
level
and
then
at
the
container
level.
So
since
I
created
a
deployment
with
a
single
container
called
engines,
we
have
a
set
of
container
checks.
For
example,
polaris
checks,
whether
the
we
are
using
a
deterministic,
not
the
latest
right.
H
Then
there
are
some
checks
for
security,
for
example,
whether
we
are
running
as
a
route
or
or
not.
So
there
is
a
bunch
of
settings
that,
usually,
by
default
by
default
in
kubernetes,
are
least
secure
right,
so
this
is
kind
of
a
host
port
set,
etc.
I
think
for
the
for
the
latest
list
of
all
the
checks
and
the
best
source
is
a
polaris
cli,
because
again,
as
I
said,
we
are
not
adding
any
additional
things.
We
are
reusing
what
they
output.
H
Some
checks
make
sense
at
the
pod
level,
such
as
host
paid
and
ipc
set,
so
those
are
reported
as
a
separate
section
before
moving
forward,
so
those
were
namespaced,
crds
and
namespace
check
checks.
We
we
can
scan
with
the
polaris
and
triggy
each
and
every
type
of
a
controller
it
can
be
stateful
set
demo
set
replica,
said
even
replication
controller.
H
We
also
have
an
extension
to
the
octant
octant.
Is
this
dashboard
from
vmware?
It
allows
us
to
display
this
information
in
maybe
a
little
bit
nicer
way
right.
Sometimes
this
terminal
output
is
not
very
readable,
especially
if
you
have
multiple
reports,
multiple
containers,
but
since
this
is
a
crd
and
we
use
a
kubernetes
api
to
read
and
write
data,
we
could
easily
extend
dashboards
with
ui
components
and
we
picked
octan
because
it
has
a
nice
plugin
api.
H
H
H
H
So
in
octane
I
can
also
see
the
I
can
also
display
the
cis
benchmarks
report
here,
since
this
is
a
work
worker,
node
q
bench
automatically
detects
that
it
is
a
work
worker,
known
and,
and
it
is
running
the
tests
appropriate
for
the
worker
node
for
cube
hunter
reports.
We
do
have
this
separate
ui
component
and,
as
you
can
see,
cube
hunter
found
three
low
vulnerabilities,
and
with
that
I
think
it's
all
from
the
cli
standpoint.
H
We
are
also
working
on
a
operator,
so
all
the
commands
that
I
was
demonstrating,
we
would
like
to
automate.
So
whenever
there
is
a
new
deployment
created,
we
could
run
the
scanner.
So
starboard
cli
is
a
kind
of
a
command
line
interface,
but
also
the
library
that
we
want
to
reuse
to
build
automation
around
that.
G
So
it
seems,
like
you
know,
the
the
goal
here
is
to
try
and
give
a
common
way
of
running
different.
You
know
security
tools
and
obviously
collecting
data
from
them
and
a
way
to
output
them
in
the
same
manner
right
so
because
the
alternative
would
be,
somebody
could
go
run
each
one
of
these
tools
separately,
but
this
gives
one
unified
interface
to.
Perhaps
I
don't
know
if
it
also
does
installation
of
these
tools
and
upgrades
things
like
that,
or
if
it's
more
about
just
running
and
then
gathering
the
data
from
these.
H
Tools,
I
think
we
wanted
to
focus
on
the
on
the
model
rather
than
how
these
tools
are
run.
So
essentially,
you
know,
the
most
important
part
is
to
find
a
common
schema
for
the
vulnerability
report,
because
we
found
many
integrations
and
I
think
we
started
with
a
hardware
which
is
this.
You
know
container
image
registry
and
then
we
had
the
same
challenge.
H
We
were
trying
to
define
a
vulnerability
model
or
model
for
the
vulnerability
report.
So
then
the
other
third-party
security
vendors
could
implement
their
scanners.
So
actually,
what
we've
done
as
a
first
step
in
the
in
the
starboard
poc
was
to
integrate
a
3d,
but
we
also
want
to
advertise
and
promote
this
model
and
saying
hey.
This
is
good
enough
or
maybe
generic
enough
okay
kind
of
a
common
denominator
for
all
the
vulnerability
scanners
that
you
could
plug
in
easily.
H
I
don't
know
clear,
encore,
maybe
some
commercial
scanners,
so
that
was
the
goal
not
how
to
have
a
generate
jobs
runner
but
have
a
common
model.
So
then
we
could,
you
know
sum
up
summarize
transform
this
model
right.
We
don't
have
to
learn
what
is
the
output
of
claire?
What
is
the
output
of
triggy,
but
we,
you
know
we
can
discuss
about
the
vulnerabilities
in
terms
of
this
common
model.
B
The
side
effects
of
taking
that
security
information
and
putting
it
into
kubernetes
native
resources
is
that
we
can
take
advantage
of
our
back
and
that's
something
that
our
customer
design
partners
have.
Really.
They
were
really
really
excited
about
because
they
can
basically
give
access
to.
You
know
a
developer
team
right.
G
Right
right,
so
certainly
making
that
accessible
makes
sense,
but
again,
like
from
the
output
and
what
you're
showing
here
so
there's
some
common
structure
to
the
reports.
But
then
each
scanner
or
each
engineer
is
plugging
in
its
own
custom
data
as
part
of
the
output
right.
So
is
that
correct?
In
terms
of
how
safe.
B
E
B
E
I
just
reached
out
on
slack
to
our
team,
because
I
think
I'd
love
to
have
them
collaborate
so
so
kind
of
what
they
did
was
very
similar
to
what
I'm
seeing
here.
It's
initially
focused
on
vulnerability
and-
and
it
initially
is
works
just
with
koi
and
claire,
but
the
intent
was
to
make
it
pluggable
for
any
scanner,
and
so
I
think
we
have
an
opportunity
to
leverage
each
other's
thinking
to
get
common.
H
D
H
It
looks
like
data
redundancy
and
it
was
very
tempting
to
store
it
at
the
cluster
level,
because
usually
you
will
maybe
have
in
multiple
name
spaces
the
same
image
with
the
same
digest
running
so
it
seems.
Maybe
this
is
wasteful,
but
on
the
other
hand,
if
we
make
it
cluster
scope,
we
don't
have
so
many
flexibility
to
giving
permissions
to
some
development
teams
to
check
what
kind
of
vulnerabilities
they
have.
H
So
the
the
operator
that
red
hat
team
has
is
actually
storing
the
vulnerabilities,
which
are
linked
not
to
the
workload
not
to
do
the
kubernetes
container,
but
they
are
associated
with
the
image,
digest
and
there's
a
kind
of
a
naming
convention
where
they're
using
like
a
to
name
the
resource
right.
So
that's
how
they
don't
use
the
label
selectors,
but
they
could
find
out
whether
the
given
image
was
scanned
or
not.
And
the
other
thing
is
that,
indeed,
you
need
a
registry
which
has
a
vulnerability
api
right.
H
E
Yeah,
no,
I
and,
and
honestly
I
was
not
deeply
involved
with
the
cso
with
the
container
security
operator.
So
definitely
sounds
like
I.
I
can't
imagine,
though,
that
red
hat
would
not
have
applied
our
own,
our
back
to
the
results,
because
everything
we
do
considers
multi-tenancy
in
the
cluster,
but
but
I
just
was
thinking
I'd
love
to
to
kind
of
have
the
folks
who
did
look
at
that
and
think
about
it.
E
B
B
Around
now
of
you
know
something
that
takes
the
summaries
from
all
the
reports,
perhaps
all
the
deployments
in
a
namespace
and
aggregates
the
results
and
knowing
things
like
how
to
interpret
the
the
summaries
from
each
of
the
different
types
of
reports
to
come
up
with
a
sort
of
single
view
of
this
namespace
has
an
issue
you
need
to
go
and
address
it.
You
know.
F
Yeah
this
is
jr,
so
I
think
I
agree
with
the
with
atlas,
and
so
the
way
I
look
at
it
is
there
are
different
controls
and
kristen
kind
of
drill
down
into
the
vulnerability
scanning
control
right.
That's
just
one
type
of
control.
There
are
several
others
and
it
is
good
to
agree
on
a
common
format
for
how
each
of
those
controls
provide
all
the
details.
F
You
know
whether
you're
using
trivia,
whether
you're
using
clear
you
know
whatever
scanning
tool,
you're
using
you're,
still
returning
the
results
in
a
format,
that's
easily
understandable
right.
So
I
think
I
think,
there's
value
for
both
both
the
summarization
view,
as
well
as
the
drill
down
view
right.
I
think
both
let's
go
responders
on
both.
G
G
One
other
interesting
thing
is
we
had
a
discussion
just
a
few
weeks
ago
and
what
are
the
different
categories?
And
you
know
for
now
we
had
security
as
a
large
placeholder,
but
I
think
what
you
just
showed
you've
done
a
good
job
of
like
categorizing,
the
different
tools
and
in
terms
of
whether
it's
vulnerability
scanning
configurations,
other
things
like
cis,
runtime,
benchmarks,
etc.
Right
so.
G
G
H
So
I
cannot
answer
that,
so
this
is
the
main
repository.
So
currently
it's
a
cli,
so
the
the
executable
binary
that
I
use
for
the
demo,
but
also
we,
if
you
want
to
implement
a
scanner
in
golang,
you
could
reuse
the
code
gun.
So
we
have
this
code
generated
right,
so
you
could
programmatically
create
instances
of
those
four
types
of
reports,
so
you
don't
need
to.
You
know,
do
the
plumbing
and
then
also,
if
you
don't
want
to
use
golang
for
some
reason.
H
We
believe
that
this
is
like
something
in
progress,
but
I
would
love
to
have
something
which
is
called
custom
security,
resources,
spec
and
that's
the
entry
point
for
you
right.
You
could
use
whatever
language
you
have
as
long
as
we
know
that.
Okay,
this
is
the
report.
This
is
a
the
payload
and
we
also
need
to
explain
a
little
bit
semantics
right.
All
these
things,
such
as
label
selectors
naming
conventions.
This
is
not
documented.
You
need
to
reverse.
H
G
You
know,
as
you've
shown
like
more
broadly
to
other
security
tools
as
well
is
what
parts
could
be
standardized
right,
some
of
the
machinery
around
launching
running
and
then
collecting
some
level
of
data
from
them
right,
and
we
decided
to
start
with
what
seemed
like
the
easiest
at
that
time,
which
was
you
know
the
the
final
output,
the
high
level
output,
but
yeah.
It
would
be
very
interesting
to
think
of
this
almost
as
a
so
coupe
cuddle,
of
course
allows
like
binary
plugins
with
crds.
G
You
know,
and
I
I'm
assuming
customer
custom
security
resource
definitions
is
meant
to
be
like
a
crd,
but
for
security
tools,
so
yeah.
That
would
be
very
interesting
to
explore
if
this
could
be
turned
into
some
kind
of
a
plug-in
model
where
anybody
can
come
and
contribute
engine
without
having
to
change
like
the
core
code
in
in
starboard
and.
B
H
Yeah,
and
also
I
wanted
to
mention
that
we
haven't
done
that
for
each
and
every
type
of
a
report,
but
at
least
for
the
vulnerabilities
we
also
have
an
open
api
spec.
So
that's
one
of
the
safety
nets
right.
So
if
there
is
someone
who
wants
to
integrate
with
starboard,
as
I
said
today
is
probably
the
only
way
is
to
do
it
programmatically,
we
don't
have
pluggable
interfaces,
but
at
least
we
have
done
this
part
of
all
right.
Let's
define
the
vulnerability
item,
because
each
time
there
is
integration,
we
are
already
inventing
the
wheel.
H
B
And
you
know
we'd
be
open
to
people
telling
us.
We've
missed
things
in
these
definitions.
It's
you
know.
It's
a
first
pass,
but
ideally
we'd,
be
able
to
different
tools,
would
be
able
to
reuse
the
same
definition.
So
we
don't
have
to
keep
having
you
know
lots
of
very
similar,
but
not
quite
the
same
right.
H
Yeah
and
maybe
last
comment
before
I
forget,
because
we
put
some
thoughts
into
the
number
of
crds,
whether
it
should
be
one
generic
map
of
maps
of
kind
of
thing,
and
when
I
look
at
that
was
like
realistically
how
many
cube
benches
do
we
have
we
have
one
from
aqua?
Maybe
there
is
a
one
from
docker
which
is
using,
I
think
some
shell
scripting,
so
there
are
two.
There
won't
be
too
many
third-party
tools
doing
the
same
thing.
I
don't
know
what
can
be
done
better.
H
Probably
it's
just
just
a
matter
of
maintaining
the
existing
tools
and
adding
checks
to
the
cis
benchmark
spec
for
vulnerabilities.
I
think
this
is
very
dynamic.
Let's
call
it
market,
so
I
expect
there
will
be
like
a
potentially
lots
of
third-party
integrations
for
config
audits,
something
with
polaris
fairways
folks
did.
I
think
it's
super
generic,
as
you
saw
it's,
you
know
just
checking
the
deployment
descriptor
like
a
pod
template
at
the
mainly
looking
at
the
security
context
of
the
pod
and
then
containers
right
so
also.
E
E
So
you
you
folks,
might
know
right,
because
aqua
and
red
hat
worked
together
a
fair
amount
that
that
openscap
is
is
a
key
way
for
us.
Government
customers,
a
key
scanning
tools,
gap
and
so
red
hat
is-
and
I
know
this
has
been
discussed
with
this
group.
Red
hat
is
investing
in
a
compliance
operator
that
will
do
openscap
checks
or
will
run
openscap
and
use
scap
content
to
do
various
types
of
compliance
checks.
So
that's
other
I'll
find
the
repo
eric.
E
B
G
E
B
B
E
B
E
E
E
But
you
can
say
I
want
to
run.
You
know
the
cis
open
shift
profile
or
I
want
to
run
the
nist
853
profile
and
the
reason
red
hat
invests
in
scap
is
because
it's
nist
certified
our
federal
customers.
U.S
federal
customers
accept
this
type
of
content,
and-
and
so
you
know
honestly,
nobody
would
want
to
use
scap
if
they
didn't
have
to.
G
G
Okay,
yeah
that
would
be
interesting
to
understand
and
compare
then
and
then,
as
you
were
saying
daniel,
then
look
at
the
results
and
see
what
the
commonality
is
and
similarly
for
configuration
tools.
I
I
agree
at
a
high
level
like
whether
it's
you
know
polaris
or
there's
caverno
or
there's
oppa
gatekeeper,
which
all
you
know.
I
think
all
of
them
also
can
act
as
admission
controllers
as
well
as
configuration
scanners
at
least
kevon
polariscan,
not
certain
about
gatekeeper,
whether
it
does
background
scans
or
not,
but
yeah.
E
C
B
H
H
Then,
if
you
want
to
integrate
with
things
like
stop,
or
maybe
some
more
generic
forms,
we
could
also
watch
the
custom
resources
that
we
have
created
right.
We
don't
have
to
do
this
in
this
first
reconciliation
loop
right.
We
can
keep
it
simple
and
then,
like
cascade
this
information
or
maybe
use
some
existing
upstream
tools
that
do
collect
this
data
from
the
cluster.
H
That's
why
we
don't
want
to
have
a
history,
and
I
think
it's
also
to
try
out
or
write
a
quick,
poc
and
testing,
whether
the
vulnerability
report
or
some
other
repo
that
we
have
today
fits
into
the
schema
that
you
already
write,
not
about
so
just
to
mention
that
I
think
we
can
play
and
see
how
it
works,
because
I
believe
that
at
the
end
we
might
have
this
type
strictly
typed
reports
for
some
use
cases,
but
it
doesn't
stop
us
for
having
something
generic.
They
cannot
absolutely.
G
H
H
Information,
so
just
just
as
a
right
as
a
it's,
for
example
like
in
polaris
today,
as
you
saw,
we
can
scan
the
whole
cluster
and
only
we
requested
a
change
like
an
enhancement
to
the
polaris,
to
allow
us
to
specify
a
single
workload.
So
then
it
makes
simpler
to
you
know,
configure
permissions
for
the
tool
etc.
G
Okay,
all
right,
I
think
that
sounds
like
a
good
next
step
to
see.
You
know
if
again,
the
policy
report
schema
that
we've
been
working
on
if
that
fits
in
into
you,
know
your
thoughts
and
view
of
a
high-level
model
to
aggregate
some
of
these
results,
and
we
could
try
them
out
across
some
some
of
the
categories
you've
defined,
and
certainly
this
is
very
much
work
in
progress
for
us
too,
so
happy
to
get
the
feedback
and
inputs
and
see
how
we
could
make
this
better
and
something
that's
usable
for
everyone.
G
So
one
thing
I
wanted
to
show-
and
this
is
in
actually
our
repo-
so
if
you
go
to
the
workgroup
policy
prototypes,
you
know
you
raj
from
my
team
figured
out
how
to
generate.
I
guess
api
docs.
So
this
was
something
that's
not
supported
right
now,
directly
in
coop
builder,
but
there
are
some
pr's
and
you
know
like
based
on
some
other
submissions.
What
we
were
able
to
do
is
actually
take
the
the
api
or
the
crd
definition
and
then
convert
it
into
a
more
readable
document
right.
G
So
this
is
here
it
to
it's
html,
as
it's
checked
in
into
the
repo
right
now,
so
you
have
to
kind
of
use
like
one
of
these
preview,
things
and
we'll
add
a
link
to
the
readme
page,
but
I
think
this
was
the
one
step
that
at
least
you
know.
I
wanted
to
make
sure
we
we
complete
before
we,
you
know,
lock
the
document
and
move
over
to
github
in
terms
of
managing
comments
and
changes
and
other
submissions.
G
So
at
this
point
you
know
we
have
the
basic
cr
in
in
github.
We
have
samples-
and
I
know
erica
someone
from
you
know.
Jaya's
team
also
submitted
a
sample.
I
have
a
sample
first
caverno
so,
and
you
know
what
we'll
start
collecting
is
more
samples,
so
definitely
daniel
and
liz.
If
there's
something
you
want
to
submit
for
starboard
and
how
it
could
you
know
fit
in
into
this
model
feel
free
to
just
create
a
pr
and
at
that
time
we'll
then
start
going
through,
and
you
know
we
can.
G
Any
any
thoughts,
questions
on
that,
and
you
know
this
of
course,
as
I
think
as
good
builder
sort
of
mature
or
adopts
like
this
document
standard
will,
I
will
you,
know,
reuse
or
switch
to
whatever
they're
supporting,
but
for
now
we're
just
using
someone
had
submitted
a
pr
to
this
tool
which
adapts
to
the
good
builder
model.
So
that
seems
to
work
reasonably
well
for
us
at
the
moment.
G
G
Right,
yes,
so
there
was
one
comment
I
think
you
had
submitted
on.
When
should
we
use
the
scope
versus
resource
yeah,
so
I
can
I'll,
I
can
add
in
some
I'm
trying
to
think.
What's
probably
the
best
thing
to
do
is
just
add
this
to
the
now
that
we
have
the
cr
and
the
ability
to
generate
documentation,
I'll
update
the
cr
itself
and
add
in
some
discussion
there
and
that
that
could
become
our
standard
sort
of
documentation
format
for
for
this.
G
G
D
We
have
which
howard
wasn't
able
to
make
it,
but
he's
at
least
back
in
active
a
little
bit
going
the
con
presentation
that
we
have
to
record
so
I'll,
be
getting
in
contact
with
him
about
that.
If
anyone
has
specific
items,
they
would
like
to
see
discussed
in
the
deep
dot
policy
deep
dive.
Let
us
know.