►
From YouTube: Too Much to Choose – Making Sense of a Smorgasbord of Security Standard- Anais Urlichs & Rory McCune
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.
Too Much to Choose – Making Sense of a Smorgasbord of Security Standards - Anais Urlichs & Rory McCune, Aqua Security
As time goes by, there are an increasing number of security standards which Kubernetes cluster operators may be asked to comply with or get audited against. This talk will look at how Kubernetes security standards like the CIS benchmarks, DISA STIG, Pod Security Standards and the NSA hardening guide compare, where they compare and where they don’t. Additionally, we will also cover the recently released PCI guidance on container orchestration security. Once a standard has been chosen, the remaining pain lies in compliance. Luckily, the cloud native ecosystem provides several open-source tools to make it easier. We will look at using open source tooling to assess Kubernetes clusters against these standards. At the end of the presentation, the audience will gain a clear understanding of the benefits of each standard and the processes that can be adopted to comply with common requirements.
A
Hi
everyone
and
welcome
along
to
this
talk
thanks
very
much
for
coming
out
this
afternoon
to
hear
about
security
standards.
Yep,
as
ian
said,
this
is
our
talk
is
too
much
to
choose
making
sense
of
a
smorgasbord
of
security
standards.
Both
of
us
pick
the
title
before
we
realize
that
we
have
problems
saying
that
word,
so
we
will
try
not
to
say
smorgasbord
too
many
times,
but
we're
okay.
So
far,
so
who
are
we?
I
am
rumi
kuhn.
A
I
am
a
cloud
native
security
advocate
at
aqua
and
I
try
to
help
out
in
various
places
in
the
community.
One
of
the
reasons
I'm
doing
this
talk
or
is
very
excited
to
do
this
talk
is
one
of
the
things
I
do
is
help
maintain
the
cis
benchmarks
for
docker
and
kubernetes,
which
is
something
I've
been
doing
for
about
five
years
now
and
that's
kind
of
where
I
got
a
lot
of
ideas
before
this
talk.
B
B
Now
I
got
started
in
the
security
space
when
I
was
joining
aqua,
so
all
of
this
is
still
fairly
new
and
that's
also
why
I
got
really
excited
about
giving
this
talk,
because
it
gave
me
the
opportunity
to
dive
into
security
standards.
So
I
hope
to
take
you
along
and
that
you
find
out
talk
interesting,
cool.
A
So,
where
do
we
start?
You
know
I
actually
want
to
take
one
step
back
and
say:
why
do
we
start?
Why
do
we
actually
care
about
security
standards?
I
I
for
me
this
comes
from.
Well,
I'm
guessing
that
a
lot
of
people
here,
maybe
even
everyone
here-
is
running
their
workloads
and
their
applications
in
kubernetes
clusters
and
they're
running
production
environments
and
once
you've
been
running
a
production
environment
with
kubernetes
security
with
kubernetes
for
a
while
one
of
the
questions
someone
is
going
to
ask,
you
is
they're
going
to
say:
is
this
secure?
A
You
know,
you're
running
all
your
workloads.
If
what
you
got
secure
and
they
might
say
well
you're
going
to
tell
me
it's
secure,
but
how
am
I
going
to
prove
it's
secure
you?
Can
you
prove
that
this
is
secure
and
that's
where
security
standards
come
in
right
because
you
can
say
well,
it's
not
just
my
opinion
on
what
security
things
that
need
to
be
set
here.
This
is
an
authority
who
has
said
that
this
is
the
secure
way
to
run
this
platform.
A
So
we
said:
there's
a
smorgasbord,
let's
see
if
we
can
pick
out,
which
one
makes
most
sense
for
you
to
use
and
to
do
that,
we're
going
to
talk
about
how
they
work
and
why
you're,
myo
may
or
may
not
want
to
use
them,
and
then
an
ace
is
going
to
really
help
and
take
us
into
the
practical
side
of
this
about
securing
your
cluster.
You've
picked
your
standard.
Let's
talk
about
what
tools
and
techniques
you
can
use
to
actually
apply
that.
A
So
what
is
a
security
standard?
This
is
there's
lots
of
different
definitions.
This
one
will
work
for
this
talk
guidance
for
a
vendor
or
third
party
on
secure
configuration
and
hardening
of
a
product
or
service.
So
this
is
going
to
be
some
authority.
Maybe
it's
the
vendor
of
the
product.
Maybe
it
is
an
independent
third
party
who
are
going
to
say
this
is
how
you
secure
this.
This
is
how
you
make
this
a
secure,
because,
basically,
almost
no
software
products
come
out
of
the
box
super
hard
and
down.
A
They
tend
to
come
out
the
box
in
a
fairly
easy
to
use
model
and
kubernetes
is
no
different
right.
The
developers
and
the
kubernetes
project
obviously
want
you
to
have
a
good
first
experience
when
you
run
up
your
cluster
and
you
don't
have
to
spend
like
two
hours
taking
off
all
the
hardening
just
to
get
something
working
so
typically
you're
going
to
need
to
apply
more
security
in
order
to
lock
stuff
down,
so
we're
going
to
get
guidance
from
third
parties
on
how
to
do
that.
A
What
type
of
standards
are
there?
Because
when
I
was
looking
at
this
and
I've
been
thinking
about
this
for
a
while,
essentially
in
my
mind,
two
different
types
of
security
standard,
the
first
ones-
we've
got
are
checklists
right
and
you
can
spot
a
checklist
because
it
will
typically
have
specific
guidance
in
numbered
sections
with
specific
actionable
settings.
Like
you
will
set
this
setting
to
this
value,
it
will
have
a
fail
and
it
will
have
a
pass
so
it'll
have
audit
guidance
and
remediation
guidance.
A
So
that's
a
compliance
checklist
and
those
are
really
targeted
at
people
being
able
to
say
is
this
product
configured
in
a
way
that
complies
with
this
document
and
then
we
get
hardening
guides
and
a
hardening
guide
is
a
little
bit
different.
So
a
hardening
guide
will
cover
the
same
kind
of
area
as
a
compliance
checklist,
but
it
probably
isn't
as
prescriptive.
It
might
mention
key
security
stan,
you
know
flags
or
settings,
but
it
won't
mention
every
single
one.
You
know
it
might
just
talk
more
at
more
high
level.
You
should
look
at
this
area.
A
You
should
consider
this
area,
so
one
of
the
problems
in
assessing
against
a
hardening
guide
is
hardening
guides
are
typically
not
written
in
that
way.
They're
not
designed
to
be
pass
fail,
they're
more
designed
for
you
to
read,
think
about
and
apply
so
those
I
think,
most
of
the
ones
we're
going
to
talk
about
today
fall
into
those
two
categories.
A
So
what
do
we
have
for
kubernetes?
There's?
Actually,
a
variety
of
options,
which
is
our
smorgasbord.
We
have
the
nsa
guide
right.
I'm
sure
people
will
probably
have
seen
this
quite
a
lot
of
press
when
it
came
out.
The
nsa
have
produced
a
security
hardening
guide
for
kubernetes
there's
two
versions
of
this
1.0
1.1,
so
they're
keeping
this
up
to
date.
That's
a
hardened
guide.
We
then
have,
as
represented
by
the
vendor
logos,
vendor
hardening
guides.
A
A
A
This
is
a
cis
benchmark,
the
cis,
if
you
haven't,
come
across
them
center
for
internet
security,
they
have
a
wide
variety
of
these
benchmarks,
they're
vendor
neutral,
and
you
can
get
them
for
pretty
much
every
product,
but
a
lot
of
different
products
in
the
computing
it
ecosystem
will
have
a
cis
benchmark,
and
then
we
also
have
the
diesel
stick
so
and
the
dsa
have
come
up
with
a
essentially
compliance
checklist
which
is
really
targeted
at
their
users,
but
it's
similar
to
the
cis
benchmark
down
the
bottom.
There.
A
I've
got
the
logo
for
the
kubernetes
project.
Now,
at
the
moment,
the
kubernetes
project
itself
doesn't
have
what
I
would
call
like
a
fool
hardening
guide.
We've
got
lots
of
great
documentation
about
security
and
there's
stuff.
You
can
go
and
read
there,
but
it's
not
really
structured
in
the
way
of
a
hardening
guide.
With
that
said,
I'm
going
to
do
my
punt
for
sig
security
docs
right
now,
which
is
we
do
have
an
open
issue
to
be
starting
a
hardening
guide.
A
So
if
anyone
comes
away
from
this
talk
motivated
and
thinking,
you
know
what
I'd
really
like
to
see.
One
of
these
from
the
kubernetes
project,
we
will
be
loved,
we'd
love
to
meet
you.
We
have
six
security,
docs
meetings
regularly
totally
come
along
and
we'll
we'll
happy
to
help.
I
think
it's
like
broken
down
and
split
up.
I
think
we
can
totally
do
it
and
we've
already
got
some
good
starting
points.
A
One
option
you
won't
see
here
is:
you
won't
see
logos
like
pci
up
there,
so
a
lot
of
companies,
I'm
sure.
If
you've
been
on
the
floor,
they'll
talk
about
doing
pci
compliant
kubernetes.
If
you're
in
payments
industry
pci
doesn't
currently
have
any
kubernetes
specific
guidelines,
people
can
take
the
general
pci
and
they
can
apply
it,
but
that's
their
opinion
of
what
kubernetes
compliance
looks
like
in
pci.
A
There
is
a
pci
draft
document
which
has
been
in
draft
for
quite
a
long
time
now,
which
might
come
out
hopefully
this
year,
which
will
cover
that
gap.
So
there's
no
actual
pci
guidance
for
this
at
the
moment,
but
people
will
still
talk
about
that.
So
that's
kind
of
like
our
available
options.
What
we've
got
to
work
with?
A
So,
having
said
that,
which
of
these
should
you
choose
which,
if
any
of
these
actually
make
sense
for
you
to
apply
to
your
environment
now,
obviously,
if
you're
regulated,
that
question
might
be
answered
for
you
by
your
regulator,
they
might
say
we
expect
you
to
apply
x
or
y,
but
not
everyone
works
in
a
regulated
industry.
Not
everyone
has
that
so
there's
a
couple
of
questions
that
I
think
are
worth
talking
about
and
there's
also
a
couple
of
things
are
definitely
worth
knowing
about
the
standards
process.
A
A
Not
all
of
them
have
got
a
standard.
Cis
benchmark
covers
cube,
adm,
aks,
eks,
gke,
openshift,
okay,
which
is
oracle
and
ack,
which
is
alibaba.
So
if
you
are
doing
you
want
to
comply
with
cis
benchmark
and
you've
got
one
of
those
you
can
find
the
document
which
actually
applies
to
your
distribution.
If
you're
using
any
other
type
of
kubernetes,
you
can
still
try
and
use
the
cis
benchmark,
but
just
be
aware
that
some
of
the
findings
might
be
false
positives
and
they
might
be
false
negatives
because
it
is
not
designed
for
those.
A
So
things
like
file
paths,
you
know
we
will
say,
for
example,
admin.com
should
have
permissions
of
600
and
we
expect
to
find
that
in
etc.
Kubernetes
well,
if
you're,
not
using
the
distribution
that
puts
it
there
that
setting
and
check
doesn't
make
any
sense
at
all.
So
first
point
to
be
aware
of
is
cis
benchmarks,
careful
what
distribution
you're
using
diesel
stig
does
not
specify
its
distribution,
but
when
I
read
it,
it's
cubed
m
it's
fairly.
A
Nsa
is
generic.
It's
a
hardening
guide,
it's
not
a
compliance
checklist.
They
do
have
some
specific
file
paths,
but
typically
they
stay
away
from
that,
which
is
great
because
it
means
you
don't
have
to
worry
about
this
too
much
and
then,
of
course,
we
have
our
vendors
and
vendors
generally
is
only
their
distribution.
So
that's
one
challenge:
if
you
want
to
standardize
on
using
a
vendor's
hardening
guide,
is
the
hardening
guide
only
generally
really
applies
to
their
distribution
right,
microsoft
are
not
going
to
write.
A
You
know,
130
different
cis
or
style
checks
for
there
for
different
distributions,
they're
going
to
focus
on
aks
completely.
Understandably
right,
that's
their
that's
their
product.
So
that's
first
question:
is
your
distribution
covered
second
question?
Which
versions
of
kubernetes
are
covered?
This
one
is
important.
A
The
kubernetes
project
adds
new
features
and
removes
features
all
the
time
right.
If
we
think
about
some
of
the
things
that
used
to
exist
in
kubernetes
and
don't
anymore,
insecure
api
port
right
from
123,
I
want
to
say
definitely
124
the
insecure
api
port
settings
on
the
api
server
do
nothing,
they
don't
work,
but
if
you're
cis
benchmark
or
you
use
an
old
version
of
a
security
standard-
and
it
says
you
need
to
have
the
insecure
api
flag
set
to
nothing
to
avoid
it
being
set.
Well,
you
might
have
a
false
positive.
A
You,
your
person
runs
a
check,
they
say:
hey
you've
got
a
finding
for
this,
and
you
don't
have
a
funding
for
this,
because
that
setting
doesn't
exist
in
kubernetes.
That
version
pod
security
policies.
If
your
standard
talks
about
pod
security
policies,
it
doesn't
apply
anymore.
If
you're
using
later
versions
psp
is
deprecated,
foreign
is
should
be
removed
in
1.25.
A
So
it's
important
to
think
about
what
versions
of
kubernetes
are
supported
by
the
standard.
You
use
cis
benchmarks.
We
have
benchmarks
for
123
and
120.
Typically,
we
do
it
every
three
versions,
which
is
a
resource
issue.
If
someone's
thinking,
I
want
to
see
a
new
one
for
every
version
come
and
help
cis
is
an
open
community.
We
are
more
than
happy
for
someone
to
come
along
and
say
I
want
to
do
new
cs
benchmarks
for
every
kubernetes
version.
A
Undefined
includes
options
not
present
in
recent
releases,
so
I
would
recommend
be
very
careful.
You
do
have
to
use
the
diesel
stick.
I
found
at
least
one
check
that
references,
kubernetes
1.12,
so
challenges
they're
pretty
out
a
day.
This
is
a
big
challenge
in
standards
world
in
standards
world.
You
know
you
have
do
you
have
the
resources
to
go
back
every
four
months
and
we
update
the
standard.
A
Do
you
have
even
to
do
every
year
and
sometimes
a
lot
of
bureaucracy
in
changing
standards?
So
be
very
aware,
if
you're
going
to
use
that
one,
you
might
get
some
checks
that
make
no
sense
whatsoever
in
modern,
kubernetes,
nsa
harding
guide.
Again,
this
is
undefined
but
generally
up-to-date.
I
would
make
the
point
of
make
sure
you
use
version
1.1
of
the
nsa
guide
because
they
fixed
quite
a
few
out-of-date
issues.
They
got
a
lot
of
good
feedback
when
the
first
one
came
out.
A
Things
like
they
were
using
the
old,
insecure
versions
of
the
scheduler
and
controller
manager,
ports
which
made
no
sense
in
modern
kubernetes
again,
but
they
fixed
all
that
in
1.1.
So
if
you're
doing
an
nsa
thing
make
sure
you
use
you
one
for
one,
you
should
be
generally
fine.
I
don't
know
how
up
to
date,
they're
going
to
keep
that.
I
hope,
obviously,
that
they
will
maintain
that,
but
I've
not
have
any
insights
into
that
project.
A
So
last
thing
is:
what
areas
do
they
cover?
The
first
question
after
yourself
is
what
is
actually
covered
by
the
standard
I'm
using
hardening
guides
typically
can
cover
wider
areas
right
so
hardening
guide.
For
example,
the
nsa
guide
will
talk
about
security
incident
and
event
monitoring.
It
will
talk
about
threat,
detection
things,
which
you
can't
really
make
prescriptive
guidance
on
right.
I
can't
tell
every
company
in
the
world
this
is
what
you
should
do
for
siem
for
kubernetes,
because
that's
obviously
doesn't
make
any
sense.
How
could
I
do
that?
A
A
Configuration
benchmarks,
however,
typically
look
at
just
the
product,
so
the
cis
benchmark
looks
at
just
the
product.
The
docker
benchmark
looks
at
just
the
product
and
they
stand
alone,
so
the
docker
benchmark
assumes
you're
running
docker
standalone.
It
doesn't
assume
you're
running
docker
as
a
cri
in
kubernetes,
and
so
some
of
the
settings
again
don't
make
any
sense.
If
you
do
that
there
is
a
gap
currently
in
kubernetes,
which
is
that
there
is
no
cis
benchmark
for
container
d
or
cryo.
A
A
Cis
benchmarks
are
quite
limited.
They
do
things
you
can
set
in
kubernetes,
not
all
the
stuff.
You
need
around
to
make
a
complete
environment
based
on
kubernetes,
so
you
might
end
up
needing
to
like
you
know,
mix
and
match,
but
that's
kind
of
like
two,
the
kind
of
three
questions
I
would
be
asking
myself
when
I'm
thinking
which
of
these
things,
you
know
which
of
these
makes
sense
for
me.
B
So
how
do
we
actually
go
about
securing
our
cluster
and
choosing
a
tool
that
can
help
us
to
see
whether
we
are
compliant
with
one
of
those
standards?
Well,
the
standards
themselves.
They
don't
help
us
to
secure
our
environments.
It
should
start
far
earlier
when
we
are
in
our
development
process
that
we
integrate
with
different
tools
to
see
whether
or
not
we
have
certain
vulnerabilities
misconfigurations
present
in
our
environment
right.
So
we
can,
for
example,
integrate
different
tools
into
our
processes.
B
Another
way
to
go
about
it
is
to
adapt
our
current
processes,
our
workflows,
to
become
more
security
focused
as
well
as
assigning
ownership
within
our
team,
whether
those
are
specific
security
teams
or
we
have
somebody
within
our
each
engineering
team
focus
on
security,
but
ultimately
the
process
of
the
q
and
r
amendments
starts
way
earlier.
We
work
before
we
think
about
security
standards,
so
who's
responsible
for
actually
implementing
those
tools.
B
Well,
like
most
things,
it
depends
on
our
team
on
who's
responsible
for
it
who
has
to
know
how
who's
available
as
well
as
our
objectives.
One
thing
we
all
struggle
with
is
finding
somebody
who
has
the
necessary
know-how
to
actually
implement
those
tools,
understand
them
and
then
implement
them
and
build
upon
it
with
our
environment.
Another
other
obstacles
to
implement
security
standards
to
follow
security
standards
are
competing
priorities
between
different
teams,
so
one
team
might
want
to
check
whether
or
not
we
are
complying.
B
Another
team
might
just
want
to
go
about.
Let's
release
the
next
feature.
Another
thing
is
budgeting:
whether
you're
using
a
vendor
solution
such
as
aqua
security,
sneak
or
you're
building
an
in-house
team.
You
will
have
to
allocate
budget
and
other
resources
to
implementing
security
solutions
and
checking
for
security
standards.
B
B
So
those
are
the
issues
and
then
which
tools
are
actually
out
there,
which
tools
can
you
use
to
check
for
security
standards
for
your
compliance?
Well,
they
have
their
different
tools
and
they
differ
in
the
following
aspects.
So
the
first
thing
is
installation:
how
do
you
install
the
tool
inside
of
your
cluster?
How
do
you
operate
the
tool?
They
mainly
differ
between
cli
tools
and
those
are
different
to
your
usual
cli
tools.
Cli
tools
that
check
your
cluster
for
compliance.
B
They
will
install
kubernetes
resources,
usually
inside
of
your
cluster
and,
let's
say
across
different
tools
the
case
now
you
can
also
install
kubernetes
operators.
You
can
install
kubernetes
manifests
to
have
those
resources
living
within
your
cluster,
then
the
other
thing
is
the
way
that
those
cuban
resources
operate
within
your
cluster.
What
types
of
resources
are
there
are
those
jobs
running
inside
of
your
cluster?
Is
it
an
operator,
then
the
scan
coverage,
depending
on
which
tool
you
use?
B
You
will
get
a
different
output
outcome
ultimately
from
from
the
tool
from
those
scans
and
then
do
they
integrate
in
your
existing
environment.
What
tools
are
you
already
using
and
do
the
new
tools
integrate
with
them
and
then
the
focus
are
those
tools
focus
on
engineers,
on
cluster
admins
or
on
security
professionals.
B
Now,
let's
look
at
some
of
the
cii
tools
that
are
available
to
generate
ci
cis
reports.
The
first
one
is
cute
punch,
which
is
an
aqua
security,
open
source
tool
that
is
used
across
different
vendors.
That
also
were
also
built
upon
cube
bench
now.
Here
you
see
the
kubernetes
resource
that
basically
has
run
the
cas
report
scans.
So
with
cubebench,
a
cis
report
is
going
to
be
generated
for
each
node.
If
you
have
a
three
node
tester,
you
will
have
three
reports.
B
If
you
have
a
onenote
cluster,
you
will
have
one
report
and
then
you
can
describe
ultimately
each
report
and
you
will
have
a
kubernetes
resource,
so
cubans
really
generates
kubernetes
resources
inside
of
your
inside
of
your
cluster.
If
you
run
it
as
a
helm
chart
as,
for
example,
part
of
the
starboard
operator,
then
you
would
have
a
cod
cluster
resource
that
you
can
use
if
you
can
also
run
it
instead
for
the
c
cli,
but
in
this
case
we're
using
the
helm
chart
now,
who
you
know
is
what
an
operator
is.
B
Should
I
clarify
it
real
quickly?
Okay,
most
hands
go
up,
let's
just
clarify
really
quickly:
it's
basically
an
operator
automates
human
processes
within
your
kubernetes
cluster.
So
this
is
what
the
starboard
operator
will
ultimately
do.
It
will
continuously
scan
every
three
hours
or
so
your
cluster,
to
generate
those
reports.
B
Now
some
of
the
highlights
of
cubebench,
it
works
as
a
standalone
tool
or
you
can
use
this
part
of
the
operator.
There
are
multiple
different
installation
options.
You
can
also
run
it
as
a
kubernetes
shop
just
by
itself,
if
you
don't
want
to
use
the
entire
operator
and
it's
used
across
companies
now,
the
next
tool
is
cute
bacon.
B
It's
a
project
by
a
co-worker
of
mine
that
I
came
across
who's
here,
also
in
the
audience.
So
if
you
have
later
any
questions,
you
can
also
approach
him.
I
guess
so.
He
created
this
site
project.
Now,
it's
a
fairly
new
tool
from
what
I
could
see
when
I
was
doing
my
research,
which
means
that
you
can
also
probably
contribute
to
it
help
shape
it
now
it
creates,
or
it
has
specific
cas
scans
for
different
cloud
providers.
B
So
from
what
I
could
see,
the
goal
is
to
add
more
over
time
and
it
runs
either
as
cli
or
as
a
drop
inside
of
your
cluster.
Now,
moving
on
to
nsa
reports,
starboard
also
has
now
an
nsa
add-on,
which
basically
creates
cluster
compliance
reports
inside
of
your
cluster.
So
for
the
starboard
operator,
you
could
also
generate
nsa
reports
and
it's
the
same
thing
to
the
cis
reports.
It's
ultimately
a
custom
recess
definition:
that's
living
inside
of
your
human
needs
cluster.
Once
you
generated
it
and
you
can
query
it
like
other
kubernetes
resources.
B
Now
with
the
nsa
reports,
they
are
part
of
your
other
cluster
audit
reports
with
starboard
like
mentioned,
and
you
can
ultimately
because
it's
a
cuban
needs
research.
It
allows
you
to
integrate
the
reports
with
your
existing
tools,
like
other
communities
resources,
it's
not
a
separate
tool
that
you
have
to
use
and
maintain.
B
B
If
you
use
the
home
chart,
you
will
have
to
sign
up
to
their
hosted
ui
to
get
the
token
and
then
install
the
helm
chart,
but
you
can
also
use
it
for
the
cli,
and
this
is
the
default
output
that
you
will
receive,
but
you
could
also
get
a
really
detailed
output.
If
you
add
additional
flags
and
with
the
submit
flag,
you
can
push
the
reports
also
from
your
cli
to
their
dashboard.
B
Now
this
is
ultimately
the
resource
that
will
be
created
in
your
cluster.
There
are
several
jobs
that
will
run
every
once
in
a
while
to
perform
the
scans
so
ci
tool.
There
are
integrations
for
the
integrations
with
the
ui
possible
their
plans
from
cubescape
to
open
sourced
the
ui,
but
I'm
not
sure
if
that
will
be
also
a
hosted
version
or
if
you
can
also
self-host
it,
then
in
that
case,
then
another
thing
is
that
cubescape
is
producing
human
readable
output.
B
So
it's
it's
far
easier
to
see.
What's
going
on
versus
checking
out
the
custom
visual
definitions
from
within
the
cluster,
so
the
target
audience
is
a
little
bit
different.
It's
more
focused
on
engineers
and
cluster
admins
versus
security
professionals,
who
would
want
to
build
upon
the
the
scans
and
the
tool
itself,
so
it
I'm,
I
think,
personally,
that's
suitable
for
multi-class
environments.
B
If
that's
what
you
want
kind
of
out
of
the
box
open
source,
because
you
can
ultimately
install
every
cluster
and
then
aggregate
it
within
the
ui
now
other
decision
factors
that
you
might
want
to
take
into
account
like
mentioned
is:
how
much
does
this
tool
integrate
with
your
existing
environment?
Will
you
have
to
maintain
the
tool
itself,
or
can
you
actually
build
upon
it
and
integrate
in
your
existing,
for
example,
observability
stack.
So
this
is
a
screenshot
from
another
demo.
C
A
A
So,
for
example,
I
could
be
secure
because
ian
here
could
be
running
my
cluster
and
it's
going
to
be
secure,
but
if
he
doesn't
write
everything
down
it
might
not
be
compliant
because
someone
can
walk
in
and
go
I've
checked
all
the
things
have
been
done.
I
can
also
be
compliant
because
I
follow
a
checklist,
but
if
that
checklist
isn't
appropriate,
it
doesn't
cover
everything.
I'm
not
secure,
so
security
standards
are
helpful,
but
there
should
be
taken
as
something
you
use.
A
As
a
starting
point,
they'll
give
you
advice
about
where
you
can
go
the
sorts
of
things
you
should
consider.
I
always
recommend
against
where
possible,
taking
them
as
being
the
only
thing
you
do.
Don't
just
say,
I've
done.
The
cis
benchmark
I've
been
through
it,
I've
checked
or
crossed
everything
good.
My
security
is
done
because
it's
not
with
that
said.
A
I
also
recognize
that
you
work
in
people
work
in
compliant
environments
or
regulated
environments
and
you're
going
to
get
asked
to
prove
it
and
having
something
like
cis
benchmark
where
you
have
gone
through
and
said
which
of
these
apply
to
me
I'll
do
them,
which
of
them
don't
apply
to
me.
I
won't,
and
as
long
as
you
can
explain
that
to
an
external
security
auditor,
hopefully
they'll
take
that
as
being
a
reasonable
indication
that
you've
done
the
work
necessary
to
secure
your
environment.
A
It's
important
as
well
to
understand
with
the
tools
what
they
do
and
don't
do
for
you.
What
anise,
I
think
showed
was
you
know
these
tools
are
very
useful.
Then
they'll,
you
know
they'll
deploy
in
your
cluster
and
they
make
some
checks,
but
they're
limited
in
what
they
can
do,
depending
on
how
you
deploy
them.
So,
for
example,
if
a
tool
only
checks
the
kubernetes
api,
it
can't
do
checks
that
are
on
the
local
host.
A
It
can't
say
what
file
permissions
you've
got
because
the
api
doesn't
expose
that
information
so
again,
taking
a
bit
of
time
to
try
and
understand
what
these
tools
are
going
to
do
for
you,
but
also
what
they
won't
do
for.
You
will
make
the
whole
thing
more
useful,
and
I
will
give
you
an
idea
of
what
you
know
what
you
should
and
shouldn't
be
doing
so
yeah.
I
think
tools
can
definitely
be
helpful
in
that
regard.
A
A
A
I
want
to
say
that
I
know
that
trivia,
we
didn't
talk
too
much
about
trivia,
but
trivia
actually
has
just
added
support
for
doing
exactly
that
and
I'm
fairly
sure
cube
escape
does
as
well
what
what
you
can
get
a
scanner
to
do
to
check
the
security
context,
settings
of
all
your
workloads
and
to
see
which
of
them
aren't
optimal.
Obviously,
here
one
of
the
things
I
would
recommend
very
much
looking
into
if
you
haven't
already,
is
pod
security
standards,
which
is
a
generic
guidance
around
here.
A
All
the
settings
and
they've
got
some
ideas
about
levels,
but
yeah
you're
right,
I
would
say
things
like
trivia-
do
do
that
now
so
they've
added
that.
So
essentially,
if
you
think
about
like,
what's
actually
needing
to
be
done
here
from
a
technical
standpoint,
this
isn't
super
difficult
pull
yaml
check
yammo
for
setting
return
good
bad,
but
you
know
having
that
automation
means
you'd
have
to
do
it
yourself,
so
yeah,
definitely
true,
I'm
pretty
sure
cubascape
does
so
yeah.
They
do
cover
workloads
as
well.
E
A
A
I
think
there's
a
slight
concern
to
my
mind
now
that
you
know
I
can
blindly
say
it
covers
qba
and
a
couple
of
others,
but
there's
people
running
lots
and
lots
of
clusters
that
aren't
covered
the
challenge
is
you
know
we
need
someone
to
actually
go
through
and
do
the
rule
writing.
I
think
there's
some
engines
out
there,
but
the
rule
writing
I've.
All
seen
is
like.
Maybe
not
something
people
are
responding
because
it
does
get
I've
done
it
myself
a
bit.
A
It
does
get
a
bit
boring
when
you're
writing
rules
for
an
entire
product,
so
yeah,
I
think,
coverage
there
and
I
think,
maybe
as
well
since,
like
cross
cluster
coverage,
I
don't
the
open
source
tools
at
the
moment.
Don't
as
much
do
like
comparison.
You
know
this
cluster
is
better
than
that
cluster
or
this
cluster
over
time.
That
tends
to
be
more,
the
commercial
software
I
think
plays
at
the
moment
in
that
kind
of
like
long
term.
You
know
my
clusters
doing
like
this,
and
then
it
went
like
this
and
you
know
so.
F
Is
there
anything
on
the
kubernetes
side
to
make
it
easy
to
know
what
security
defaults
change
between
releases
and
those
security
relevant
settings,
so
that
if
you
are
running
ahead
of
the
benchmarks
that
are
provided,
as
you
just
mentioned,
it
yeah
it
takes
a
while
to
get
those
rule
sets
updated
so
that,
if
you're,
if
you're
trying
to
say
like
current
with
latest
kate's
releases,
you
could
update
your
compliance
benchmarks
to
get
to
a
line.
So.
A
So
they're
not
going
to
dig
into
the
code
and
like
yeah,
so
the
question
is
around
as
I've
got,
this
right
is
as
new
kubernetes
productions
come
out.
Is
there
any
way
of
keeping
up
to
date
with
the
new
defaults
and
change
settings
have
changed,
I'm
going
to
say
that
I
haven't
come
across
one.
I
hate
to
say:
I've
read,
release,
notes,
honestly
reading
the
release
notes
for
each
version,
because
typically
security
settings
will
be
mentioned
in
there.
A
I
know
that's
not
like
a
nice
answer,
but
that
I
I
personally
what
I
tend
to
do
is
read:
release,
notes
and
caps.
So
I'll
read
the
kept
coming
to
each
version
and
see
which
new
things
are
going
to
land
in
this
version
and
then
do
they
come
out
do.
Are
they
going
to
make
a
change
you're
right,
though
it
would
be
nice
if
that
was
perhaps
like
presented,
because
I
think
the
information
is
definitely
there
for
sure.
I
just
don't
think
that
it's
necessarily
like
summarized
in
a
nice
way,
so
yeah.
D
I'm
passing
the
mic
to
the
next
question:
ask
her
but
hi,
I
co-chair
sig
security
and
we
do
actually
in
the
most
recent
couple
of
releases
anyway,
have
as
part
of
the
release
blog
a
summarization
of
security
changes,
and
so
I
think
that's
the
thing.
We're
going
to
continue
to
do
next.
Question
person,
sorry
about
that.
G
Thank
you
very
much,
a
follow-up
question
to
the
first
one
regarding
workloads.
You
said
the
tools,
for
example,
starboard
scan
the
cluster
api
or
like
the
api
at
given
times.
I
think
it
was
three
hours
or
something
what
happens
with
workloads
that
ran
in
between
two
scans,
for
example,
like
one-off
jobs,
that
could
have
malicious
payload.
Are
they
picked
up
upon?
G
A
A
So
hopefully
you
know
there's
other
stages
that
you're
going
to
catch
that
because
you're
right,
otherwise
what
you
would
need
to
do
is
actually
have
something
which
reflexively
ran
and
in
terms
of
the
open
source
tools
back
to
the
question
about
gaps
in
open
source
tools.
I
don't
think
there's
one
that
will
reflexively
scan,
but
I
would
hope
that
everyone,
hopefully
everyone
who's
running
in
production,
is
running
admission
control.
If
you're
not.
D
C
B
C
C
B
B
And
you
don't
want
to
check
the
cluster
itself
or
the
cli
right
like
I,
for
example,
prefer
not
to
have
the
output
in
my
client,
and
I
would
have
to-
I
don't
know,
take
it
somewhere
else
from
there,
which
is
very
complicated
and
annoying.
So
what
I
would
do
is
I
would
integrate
into
an
existing
internet
dashboard
or
into
my
observability
tools.
That
would
be
my
ideal
case,
not
from
the
user
experience.