►
From YouTube: The Common Configuration Scoring System for Kubernetes Security - Julien Sobrier, Octarine
Description
The Common Configuration Scoring System for Kubernetes Security - Julien Sobrier, Octarine
The Common Vulnerability Scoring System (CVSS) is widely used to score vulnerabilities found in docker images. But how do you score the risk level of an entire workload, with its runtime configurations, network configurations, Pod Security Policy, privileges and capabilities added, etc.?
Julien will explore the Kubernetes Common Configuration Scoring System (KCCSS), an open-source framework to calculate risk scores for Kubernetes workloads, and kube-scan, an open-source scanner that implements the KCCSS. Based on CVSS, it categorizes risks associated with each runtime setting while considering how settings affect one another, and offers a global risk score for each workload—not just for individual settings. Attendees will learn how the KCCSS works, how it’s being used by end users for DevSecOps, and best practices for bullet proofing their own K8s applications.
A
Thank
you
for
joining
this
call
about
the
kubernetes
command
configuration
scoring
system.
I'll
start
with
a
brief
introduction
about
myself.
My
name
is
trent
sobreyer,
I'm
now
part
of
vmware
more
important.
If
you
want
to
contact
me,
if
you
have
more
questions
about
the
kccss,
this
talk
or
anything
about
communities
can
contact
me
at
jsobrier,
vmware.com.
A
So
you'll
probably
see
in
this
slide
a
lot.
If
not
you
will
the
short
definition
of
kubernetes
is
that
it's
a
an
orchestrator
for
containers,
but
we
all
know
it's
much
more
than
that.
It's
defined
the
entire
infrastructure
for
your
cloud
defines
how
you
provision
network
load,
balancer
storage,
how
you
get
get
access
to
the
containers,
what
kind
of
privileges
you
give
to
your
container,
our
back
secret
management,
etc?
A
There
are
over
30
security
settings
that
directly
impact
the
the
risk
associated
with
your
workload.
There
are
things
like:
are
you
breaking
isolation
between
containers
by
sharing
the
same
p,
the
ipc
or
sharing
the
host
file
system?
Do
you
enable
some
of
the
capabilities
that
give
you
potential
network
mind
in
the
middle
or
enable
network
sniffing?
A
A
Writeable
first
system
privileged
containers.
What
kind
of
level
of
access
do
you
have
to
the
api?
Can
a
port
create
other
pod
or
access
secrets,
the
different
capabilities
that
might
lead
to
easier
container
escape?
For
example,
do
you
have
a
way
to
make
sure
that
container
is
not
changing?
Second
policy
is
unboxing
and
then,
if
you
add
more
layers
like
service
meshes
also,
another
set
of
security
features
like
encryption
identity
that
you
can
enable.
A
How
do
you
know
that
this
set
of
settings
enabled,
together
for
the
same
workload,
for
example,
is
actually
worse
than
the
other
set
of
of
settings
where
maybe
some
of
the
attributes
of
the
workloads
like
network
sleeping
ability,
ability,
shadows
network
nor
might
be
remediated
or
mitigated
by
the
fact
that
you
have
encryption
coming
from
your
service
mesh
and
what
we
saw
is
when
we
ask
devops,
you
know
what
is
the
most
risky
workload
you
know.
Where
is
what
was
the
easiest
way
for
an
attacker
to
get
into
your
cluster?
A
Workloads,
so
we
decided
that
we
needed
a
way
to
give
a
clear
picture
that
we
can
update
in
real
time
of
the
risk
associated
with
each
workload.
So
we
look
for
a
framework
that
will
give
us
three
things:
three
main
goals,
so
one
is
give
a
score.
You
know
from
zero
to
ten,
for
example,
for
each
workload,
so
you
can
clearly
see
what's
dangerous,
what's
not
and
order
them
and
look
at
your
most
risky
workload.
First,
we
also
wanted
to
make
it
clear
how
the
risk
is
calculated
know.
A
Where
does
the
risk
come
from
and
what
can?
What
are
you
actually
risking,
though?
Are
you
risking?
Maybe
that
explication?
Are
you
risking
bringing
down
your
applications,
so
we
wanted
all
the
details
to
to
be
part
of
the
framework
and
finally,
once
you
know,
what's
now
potentially
dangerous,
you
want
to
fix
it
or
to
remediate
it.
So
we
want
the
framework
to
be
able
to
tell
you
what
are
the
steps
that
you
can
take
to
reduce
your
risk.
A
So
we
didn't
want
to
reinvent
the
wheel,
so
we
look
at
the
other
security
framework
that
are
being
used
out
there
and
there's
a
couple
of
them
like
the
cvss,
the
common
variability
scoring
system.
If
you
are
scanning
docker
images,
you'll,
probably
see
vulnerabilities
being
found
in
your
images
and
being
scored
with
a
cvss
framework,
which
is
a
great
way
to
describe
the
risk
associated
with
each
vulnerability
and
also
describe
it
in
terms
of
impact
blast
radius.
How
easy
it
is
to
expose
it
remote
or
local
access
is
required,
etc.
A
And
finally,
the
last
framework
we
looked
at
that's
very
interesting
is
the
common
configuration
enumeration
system
cc
and
what
it
is
is
a
checklist
of
checks
that
you
need
to
apply
to
make
sure
that
your
software
is
secure.
So
you
have
a
checklist
for
apache,
for
example,
a
checklist
for
different
os,
like
credits,
and
you
can
basically
follow
the
rules
one
by
one
and
ensure
that
your
software
is
secure.
A
A
A
It
shows
the
impact
to
integrity,
confidentiality
and
availability,
each
of
them
being
scored
from
non
low
medium
to
too
high,
and
what
we
try
to
do
here
is
really
describe
exactly
what
is
the
risk?
So
if
you
have
a
workload
which
it's
sharing
the
host
network,
you
know
you
have
two
main
things
one
is
you
bind
the
ip
address
to
the
host
network,
which
is
a
public
ip
address,
might
be
exposed
to
the
internet
and
the
other
one.
A
A
Then
we
explain
how
easy
it
is
to
exploit
it.
So
do
you
need
you
know
special
tools.
Do
you
need
other
type
of
access
to
be
able
to
take
advantage
of
these
specific
settings,
or
is
it
just
easy
to
do?
The
second
one
is:
is
it
the
attack?
Vector?
Is
it
remotely
exploitable
potentially
or
does
it
require
local
access?
A
And,
finally,
the
scope
is:
what
can
you
potentially
compromise
through
this
risk?
Can
you
compromise
just
the
container,
or
can
you
expand
and
compromise,
maybe
the
hose
that
the
container
is
working
on
or
maybe
even
the
entire
entire
cluster,
so
each
role
is
described
in
the
same
way
with
different
values,
different
score
for
each
of
these
attributes?
A
Other
types
of
setting
other
types
of
risk
and
an
example
is,
if
you
enable
encryption
through
service
match
the
fact
that
you
have
encryption
remediate
issue
reality
to
sniffing
traffic
to
man
in
the
middle
and
it's
very
similar
to
to
a
risk.
We
describe
the
heights
meter,
getting
impact
to
integrity,
confidentiality,
availability,
whether
it's
mitigating
remote
attacks
or
local
attacks,
and
whether
it's
protecting
just
a
container
or
the
entire
pod,
and
same
way
as
we
try
to
be
very
specific
in
what
this
remediation
or
this
rule
is
really
really
doing.
A
A
So
we
look
at
the
impact
score,
so
the
highest
impact
you
have
on
the
three
attributes:
availability,
confidential
integrity,
the
higher
impact
score
you
have,
and
then
you
have
the
exploitability
score
and
let's
now
basically
tell
you
how
easy
it
is
to
exploit
this.
This
attack-
and
you
add
the
two
of
them
and
you
get
a
score
from
0
to
10..
So
the
first
step
is
to
create
a
risk
from
0
to
10
for
all
the
settings
that
apply
to
a
workload.
A
Then,
from
this
list
of
risk,
we
want
to
compute
a
risk
for
the
workload
itself
and
what
we
do
is
we
look
at
a
common
type
of
risk,
meaning
arrays
that
have
the
same
attack,
vector
same
scope
and
we
basically
say
our
equivalent
and
we
take
the
maximum
score
for
all
of
them.
So
if
you
have
two
arrays
that
are
the
same
attack
letters,
so
both
of
them
are
remote
and
same
scope,
both
of
them
are
impacting
the
container.
A
So
if
you
have
a
risk
that
has
high
impact
on
confidentiality
and
matching
remediation,
that
has
a
low
impact
on
confidentiality,
then
you
subscribe
subtract
lower
from
high
and
you
now
get
a
medium
risk
and
you
do
that
for
all
three
attributes
of
ability,
integrity
and
confidentiality,
and
you
get
a
modified
risk
and
you
actually
take
these
risks
as
part
of
the
formula
to
to
to
calculate
your
overall
risk.
So
you
compute
the
list
of
mitigated
risk
and
you
apply
the
same
formula
for
the
overall
workload
configuration
so
now.
A
A
A
You
have
additional
information
in
the
wiki
about
the
goal
of
the
project.
Now,
how
can
you
make
your
own
role,
the
scoring
formula?
So
if
you
want
to
go
to
more
details,
just
type
github
kccss-
and
you
will
find
this
repository
same
thing
for
cubescan,
we
have
a
github
repository
where
you
get
all
the
instructions
to
install
cubescan
in
in
your
cluster.
A
So
what
the
web
ui
here
shows
is
the
mapping
basically
of
your
workloads
settings
with
kccss,
and
you
see
the
workload
score
here
so
here
we
go
from
seven
for
the
highest.
We
don't
have
a
ten
and
we
go
down
to
zero
and
pretty
much.
No,
no
is
there.
We
do
have
a
toggle
to
show
or
hide
the
system
in
space
like
the
q
proxy
containers
that
you
may
not
be
able
to
do
anything
about
the
scan
is
been,
it's
been
done
on
demand.
A
A
So
if
you
want
to
get
more
information
about
where
the
values
come
from,
you
just
click
on
the
score
here
and
you
see
all
the
risk
and
remediation
that
apply
to
that
workload.
So
we
see
that
it
has
a
natural
capability,
it's
privileged,
but
also
exposed
potentially
to
the
outside
for
shareholders
network.
A
A
That's
it
for,
for
the
demo,
I
encourage
everybody
to
try
it
at
home
so
to
to
conclude
a
few
few
words
about
what
we
plan
on
doing
next,
so
we're
always
looking
at
improving
the
formulas.
One
of
the
area
of
improvement
right
now
is
how
we
match
risk
with
remediation.
We've
been
adding
a
lot
more
information
and
metadata
about
risk
and
remediation,
and
that
should
allow
us
to
better
match
risk
with
remediation.
A
A
We
also
are
putting
more
information
about
things
like
cis
benchmark,
the
meter
attack
framework,
and
I
think
it's
very
very
interesting
because
it
it
should.
You
know
it's
a
different
way
of
looking
at
your
risk.
So
you
can
see
you
know
what
best
practices
you're
not
applying
with
a
cs
benchmark.
You
can
look
at
what's
not
stages
of
attack
you're,
most
susceptible
with
the
mitral
attack
framework.
So
we
want
to
expand
the
use
of
this
framework
and
give
you
as
much
information.
A
So
one
of
the
goal
that
I
have
is
no
an
easy
way
for
you
to
show
what
are
the
all
the
different
communications
that
are
available
and
how
they
will
impact
or
not
impact
your
risk.
So
you
know,
if
you
turn
on
encryption
for
insta
phone
up
or
how
would
it
look
for
your
for
your
security
posture?
Will
it
improve
all
of
your
workload?
Maybe
some
of
them
know.
A
A
A
If
you
have
security
tools
or
practices
that
you
are
using
for
communities
now,
you
can
represent
a
role
that
will
show
you
how
it's
improving,
for
example,
your
security
posture,
how
the
how
the
security
tool
that
you've
deployed
are
remediating
some
of
the
issue
or
potential
issues.
So
it's
it's
easy
to
extend
and
it
should
be
easy
to
create
new
results.
A
Improve
or
augment
the
kccs
framework
to,
for
example,
look
at
custom
labels,
all
the
things
so
it
is
it
is,
it
is
possible.
There
is
a
lot
of
improvements.
We
need
to
do
there,
so
the
idea
is
that
each
each
role
is
represented
with
a
json
pass
query
for
looking
at
the
specific
configuration
and
its
volume.
It's
not
done
yet.
So
that's
that
I
need
to
put
more
explanation
on
the
weekend
on
how
to
do
that.
A
How
often
are
the
rules
updated,
so
they
actually
haven't
been
updated
in
a
while.
I
think
the
last
update
was
two
three
months
ago,
just
before
octarine
got
acquired,
but
we
we
hope
to
make
more
more
changes.
The
the
new
rules
that
we
are
looking
for
are
a
little
bit
different
from
the
other,
so
we're
looking
at
what
we
call
environment
rules,
that's
looking
at
more
than
one
workload
at
the
time.
A
A
Question
about
how
you
know
how
how
difficult
it
is
to
create
the
overall
risk
is
you
you
do
have
to
to
to
rate
all
individual
race
again.
The
idea
is
naturally
to
do
it
manually
because,
yes,
looking
at
30
different
settings
manually
and
and
creating
individual
risks
for
that
and
creating,
then
the
overall
risk
is
quite
hard.
So
that's
why
you
know
you
have
tools
like
cube
scan,
but
it's
also
in
the
repository
a
couple
of
node.js
tools
that
allow
you
to
do
that
out
of
scan
without
doing
it
manually.
A
A
So
it
is,
you
know
an
additional
layer
of
your
of
your
security
model,
so
you
have
what's
inside
the
container
and
then
you
have
how
the
configure
how
the
container
is
configured.
So
it's
it
doesn't
look
at
specific
cvs,
but
it
is,
you
know,
an
additional
layer
of
information
and
it's
looking
at
a
different
layer
of
security
than
image
scanning
question
about
whether
it
run
on
target
or
not.
I
don't
think
we've
tried.
So
I'm
not
sure
if,
if
it
will
work
with
with.
A
A
A
The
formula
that
take
the
the
the
three
and
create
create
a
score
for
the
impact,
and
then
I
encourage
you
to
look
at
the
at
the
wiki.
There's
more
information
there
and
there's
a
program
that
does
that
then
there's
the
exploitability
score,
which
looks
at
the
attack,
vector
the
scope
and
the
likelihood
of
exploit
and
two
of
them
sum
together,
is
the
individual
risk
for
each
setting
so
again,
very,
very,
very
similar
to
to
cbss.
A
A
We
we
described
each
impact
and
we
try
to
to
you
know,
show
what
is
the
exact
risk
to
confidentiality,
integrity
and
ability,
and
you
know
we
make
the
decision
on
whether
the
risk
is
high,
low
or
or
unknown
for
each
of
them,
and
but
obviously
you
can.
You
can
take
the
rules
and
you
know
if
you
feel
like
we
said
that
there
is
too
low
or
too
high
for
for
for
for
a
setting.
You
can
change
it
yourself.