►
From YouTube: Hands-on Workshop: Batten Down the Hatches! A Cluster Security Journey - Steve Wade, KSOC Labs, Inc.
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Hands-on Workshop: Batten Down the Hatches! A Cluster Security Journey - Steve Wade, KSOC Labs, Inc.
Your career is really taking off and you’ve finally landed that security engineer role at the company of your dreams. At your first daily standup meeting, the Chief Security Officer welcomes you aboard and gives you your first major project to lead which is aptly named, “Operation: Cluster Lockdown”. In this hands-on workshop, the instructors will dive into the methods used to perform a successful real world Kubernetes security audit. Attendees will learn through instructor-led scenarios how to perform cluster / workload inventory, rapidly assess the security posture of workloads, enforce least privilege for end-users and service accounts, and comply with established compliance standards. Each workshop attendee will be provided with a pre-configured public cloud environment running real-world Kubernetes workloads. The tools and methodologies covered in this workshop will give attendees the real world experience to perform a rapid Kubernetes security posture audit in their own organization’s clusters.
A
A
So
what
we're
going
to
do
is
we're
going
to
I'm
going
to
take
you
on
a
journey
of
where
you
should
look
what
you
should
be
thinking
about
when
you're
performing
said
audit
and
then
finally,
what
defense
mechanisms
can
we
put
in
so
that,
once
we
have
a
good
understanding
of
how
secure
and
secure
our
cluster
is
when
new
workloads
and
new
resources
are
trying
to
be
deployed
to
our
cluster,
we
want
to
be
able
to
stop
the
bad
ones
from
getting
in
right.
You
don't
have
to
keep
repeating
this
order
over
and
over
again.
A
What
are
the
things
that
are
important
to
us
when
we're
performing
in
audit,
then
we're
going
to
talk
about
workload
hardening?
So
how
can
we?
How
can
we
make
the
workloads
that
are
currently
deployed
more
secure?
What
are
the
things
that
we
should
look
out
for
then
we're
going
to
move
on
to
our
back?
So
everybody
knows
you
know
our
back
anywhere
is
a
is
a
bit
of
a
mess.
A
B
B
B
A
Click
through
when
you
ask
when
it's
asking
about
the
cloud
show
click
Start,
Cloud
show
when
you
get
to
this
section
down
here.
This
is
the
important
piece,
so
there
is
a
repository
that
we're
going
to
clone
into
Cloud
shell,
that's
going
to
make
things
a
lot
easier,
so
don't
just
hit
confirm
you
need
to
scroll
down
click,
trust
repo,
hopefully
you'll.
Trust
me
that
I'm
not
going
to
go
and
do
something
Road
for
you,
hit
trust
repo
and
then
finally
hit
confirm.
B
A
A
Okay,
so
the
first
thing
we're
going
to
do
is
we
are
going
to
run
make
in
it.
So
what
make
in
it
is
going
to
do.
Is
it's
going
to
ask
us
to
authenticate
when
it
asks
you
to
authenticate
we're
going
to
go
through
the
the
flow
use,
the
same
credentials
that
are
on
your
piece
of
paper,
then
we're
going
to
install
some
default
workloads
and
a
couple
of
binaries
and
packages
that
we're
going
to
leverage
throughout
this
workshop
and
then
we'll
get
started
with
the
workload
and
asset
configuration.
A
A
A
A
B
B
A
A
A
A
A
A
So
the
first
thing
that
we
are
going
to
perform
is
an
asset
inventory,
so
we
want
to
know
what's
running,
what
are
we
dealing
with?
What
are
the
things
that
we
need
to
start
looking
at
from
an
audit
perspective,
so
I'm
not
going
to
go
down
this
list
extensively
of
the
things
that
you
should
be
looking
for.
However,
some
things
that
are
useful
and
I
would
recommend
you
look
for
is
the
version
of
kubernetes.
That's
currently
running
reasons
why
this
is
important.
There
are
cves
in
some
kubernetes
versions.
A
There
are
also
deprecations
as
well
in
some
of
the
API
specifications,
so
not
necessarily
a
security
thing
to
be
aware
of,
but
when
it
comes
to
upgrading
your
kubernetes
clusters,
it
can
be
an
important
thing
to
know
right.
So
if
there's
a
deprecated
API
you're
still
using
that
API,
you
upgrade
your
kubernetes
cluster
and
that
API
doesn't
exist.
A
The
first
time
you
deploy
your
resource,
it
will
work
when
you
try
and
upgrade
that
resource.
So
you
upgrade
a
deployment
or
you
upgrade
a
replica
set.
It
will
not
work
so
one
of
the
things
you
really
want
to
focus
on
specifically,
if
you're
a
platform
engineer
and
responsible
for
you
for
the
kubernetes
Clusters.
That
you're
running
at
your
organization
is
to
try
and
be
ahead
of
the
curve
of
the
application
developers
right,
because
what
you
don't
want
to
do
is
upgrade
your
kubernetes
cluster
and
then
the
application
developers
can't
deploy
their
applications.
A
So
there
are
some
links
here
to
some
official
kubernetes
cve
streams.
So
you
can
see
all
of
the
cves
kubernetes
does
have
cves
that
you
can
go
through
the
versions
that
they
were
fixed
in
I'm,
not
going
to
go
through
these
in
detail,
but
feel
free
to
to
take
a
look
at
these
in
your
own
time,
then,
from
a
from
a
managed
provider
perspective.
There
are
also
a
number
of
things
to
note
here
so
they're
like
eks
and
gke,
and
an
AKs
on
Azure.
They
they
all,
have
limits
right.
A
There's,
there's
edges
and
boundaries
that
you
can't
go
outside
of
I've
left
the
links
here.
They
are
important
things
to
note
specifically
when,
when
you're
dealing
with
security
groups-
and
you
know,
your
applications
need
to
talk
outbound
to
something
is
running
in
those
Cloud
providers,
so
hands
off
of
people
that
are
running
eks
or
running
in
AWS.
A
A
So
again,
some
other
things
to
note.
From
a
from
a
networking
perspective,
there
are
also
limitations
there
as
well
to
be
to
be
aware
of
the
subnets
that
you're
running
in
some
of
the
plugins,
the
the
specifically
the
AWS
eks
cni
plugin.
That
allows
you
to
have
an
extension
to
actually
leverage
the
amazon
security
groups,
but
they
can,
they
can
sometimes
get
a
little
bit
mangled.
A
So
I
would
recommend
that,
specifically,
if
you're
running
AWS
to
to
read
through
these
plug-in
configurations,
so
the
first
thing
we're
going
to
want
to
do
is
when
we
perform
an
audit.
Is
we
want
to
know
what
are
all
of
the
different
API
resources
that
are
currently
running?
So
the
First
Command
that
we're
going
to
run
is
Cube
CTO,
API
resources,
Dash
o
wide.
A
So
this
gives
us
a
good
initial
understanding
of
what's
currently
what's
currently
possible
to
run.
This
is
not
what's
running
right.
These
are
the
options
that
are
available
to
us
to
deploy.
So
we
can
see
here
that
we're
able
to
deploy
some
some
roles
or
some
pod
security
policies
or
some
pod
disruption
budgets.
A
So
when
we
go
deeper
into
doing
our
audit,
we
should
be
looking
at
these
types
of
resources
and
trying
to
find
the
result.
The
number
of
resources
that
are
currently
running
for
each
of
these
API
groups
from
there
we
can
go
further
and
look
from
a
security
standpoint
at
the
configuration
of
each
of
those
resources.
So
essentially
it's
a
it's.
A
layered
approach.
We're
going
to
start
right
at
the
top
going
to
get
a
good
overview
and
understanding
of
what
possible
resources
can
run.
A
A
A
So
again,
from
a
security
standpoint,
we
could
think
about
scanning
these
images.
What
kind
of
vulnerabilities
do
these
individual
images
have
right
as
as
an
application
developer
myself?
Sometimes,
security
isn't
always
top
of
mind
right.
Releasing
that
feature
to
production
is
more
top
of
Mind,
potentially
than
the
security
of
the
underlying
container.
The
application?
Yes,
that's
top
of
mind,
but
the
artifact
that's
currently
running
in
in
the
production
cluster
or
you
know
even
your
development
clusters,
maybe
not
top
of
mind.
A
Maybe
you've
got
you
know
a
a
generic
configuration
you
use,
something
like
Helm
or
customize,
and
your
SRE
team
or
your
platform
team
are
providing
you
with
this
configuration,
and
they
just
say
all
you
need
to
do
is
add
your
image
in
here
and
set
a
few
variables
and
Away
you
go
right,
but
that
whole
configuration
that
they
have
could
be
completely
insecure.
Right
and
you're.
A
Tools
that
you
may
want
to
use
things
like
gripe
things
like
trivia,
clear,
make
sure
you're
running
them
in
CI
make
sure
you're
running
them
before
you
push
them
to
the
registry.
Some
people
that
I
know
push
them
to
the
registry
and
then
scan
them.
Well,
if
you
push
them
to
the
registry
and
then
scan
them
they're
available,
so
they
could
be
on
your
kubernetes
cluster
before
you
even
get
a
chance
to
scan
it.
The
other
thing
I'd
recommend
doing
as
well
is
using
the
image
digest
and
not
the
tag
itself.
A
So
imagine
I
tag
an
image,
1.2
and
I,
configure
that
in
my
kubernetes
deployment
and
I'm
about
to
deploy
it
I
tagged
the
images
1.2.
Remember
then
someone
else,
because
all
of
these
tags
are
you
know
that
you
can
override
them.
Someone
else
pushes
an
image
1.2
so
now
I'm
ready
to
deploy
my
application,
well,
I'm,
deploying
theirs
and
not
mine.
A
A
I
can
easily
come
in
here,
not
with
the
nginx
ones,
but
if
I
had
my
own
registry,
I
was
running
at
my
own
company
or
I
was
a
rogue
employee.
I
could
easily
come
and
override
someone
else's
tag.
They
could
be
doing
all
kinds
of
nonsense,
Bitcoin
mining
it
could
be
browsing
and
trying
to
work
out
and
plot
the
landscape
of
the
kubernetes
cluster.
It
could
be
doing
anything
and
that
application
developer
has
no
idea
right.
They
just
see
the
tag
and
they've
deployed
it,
and
maybe
it's
working.
A
A
A
So
if
we
run
this
you'll
see
kubernetes
displays
it
quite
nicely
for
us.
We
have
the
replica
sets
that
are
currently
running.
We
have
the
the
deployments
that
are
currently
there
demon
set
Services
all
of
the
pods,
etc,
etc.
However,
one
of
the
things
to
note
is
this
is
not
giving
you
absolutely
everything
right.
It's
giving
you
everything
from
a
cube,
CTL
standpoint.
So
there
is
a
tool
called
get
all.
A
Which
kind
of
actually
provides
you
all
of
the
resources
right
and
what
we're
going
to
do
is
we're
going
to
run
this
now
and
what
you'll
see
is
it
prints
out
a
lot
more
than
what
the
default
Cube
CTL
get
all
this.
So
when
you're
doing
a
cluster
audit,
don't
just
take
what
Cube
CTL
tells
you
as
gospel
right,
there's
other
tools
that
are
around
that
actually
give
you
a
much
deeper
and
richer
response.
A
And
now
you
can
see
there's
a
lot
more
printed
out
right.
We've
now
got
storage
classes,
we've
got
things
about
our
back.
We've
got
priority
classes,
so
there's
a
lot
more
richer
understanding.
Now
of
what's
going
on
from
a
kubernetes
perspective,
so
I
use
this
tool
more
extensively
than
I.
Do
the
cube
CTL
get
all,
because
this
is
the
real
girl,
Cube
CTO
get
all
just
you
know
the
bare
minimum.
A
So
now
we
have
an
understanding
of
the
images
that
are
currently
running
the
resources
that
are
currently
there.
We've
talked
about
images
and
why
tags
are
not
not
great
and
we
should
be
using
image
digest.
So
that's
something
from
an
audit
perspective
that
we
should
be
going
back
to
our
application
developers
and
saying
and
proposing
to
them
move
to
image.
Digests,
don't
use
image
tags.
A
We've
got
a
good
understanding
now
of
of
what's
running
so
we've
got
some
deployments
in
there.
We've
got
some
Demon
sets.
We've
got
some
pods
so
now
what
we're
going
to
do
is
start
to
look
at
some
workload
configuration
so
now,
if
we
copy
this
link
here
so
now,
I'm
on
the
second
number,
two
workload
configurations,
I'm
copying
and
pasting:
the
the
command.
A
And
now
we're
going
to
go
through
an
interactive
flow,
so
what
I
want
to
talk
about
is
some
of
the
ways
that
applications
and
workloads
can
be
insecure,
right
and
there's
there's
many
different
ways
that
they
can
be
insecure,
we're
going
to
talk
about
how
they
become
insecure
and
we're
also
going
to
talk
about
from
a
defense
mechanism.
What
are
the
things
that
we
can
do
to
be
able
to
secure
them,
so
the
the
classic
one
pods
running
is
everybody
has
at
least
one
of
these
pods
running
in
the
kubernetes
cluster
running
as
root.
A
A
So
the
default
nginx
container
is
now
running
as
root.
So
what
what
options
do
we
have
available
to
us
to
make
sure
that
that
can't
happen
right
from
a
from
a
cluster
audit
perspective
containers
running
as
root,
especially
if
I'm
a
rogue
employer,
I
managed
to
get
into
a
kubernetes
cluster
or
you've
you've?
Given
me
too
much
access
I,
you
know,
I
can
I
can
go
Rogue,
so
we
we
have
the
ability
to
use
security
contexts,
so
we
can
set
Runners
non-root
to
true.
A
A
A
So
we
can
see
that's
the
case.
We
do
a
describe
of
that
pod
and
we
look
for
the
error
and
kubernetes
is
telling
us
that
you
know
we're
trying
to
run
it.
We
have
a
container
that's
running
as
root
and
we've
specifically
told
it
that
it
can't
run
as
root.
So
security
context
is
going
to
be
a
key
thing
that
we're
going
to
be
wanting
to
look
for
when
we
are
looking
at
workload
configurations
right.
A
What
a
lot
of
people
are,
what
a
lot
of
people
may
or
may
not
be
doing,
is
getting
their
deployment
configuration
set
up,
not
knowing
or
not
worrying
about
the
security
context,
because
there's
there's
some
things.
You
have
to
think
about
right,
not
everything.
Some
things
are
going
to
have
to
run
as
root
right
potentially
like
or
you
could
have
public
images
like
the
nginx1
that
runs
as
roots.
So
there's
a
lot
of
work
from
an
application
development
perspective
to
get
that
application
to
not
run
as
root.
A
So
what
I
would
recommend
from
an
application
developer
perspective?
Is
this
concept
of
having
base
images
so,
if
you're
running,
Java
or
you're
running
go
or
whatever
language
you're
running
to
construct,
base
images
that
meet
and
comply
to
a
specific
set
of
standards
in
your
organization
right,
one
of
the
obvious
ones,
don't
run
it
as
root
but
run
it
as
a
specific
type
of
user?
Put
the
binary
in
a
specific
location,
put
the
config
for
the
application
in
a
specific
location,
set
the
units
at
the
the
user
and
group
IDs
right.
A
All
of
these
things
allow
you
to
be
able
to
Define
workload,
configurations
that
are
standardized
across
your
organization,
and
then
we
can
start
to
look
for
anomalies,
because
anything
that
doesn't
have
a
urid,
a
user
ID
or
a
group
ID
of
a
specific
number.
We
know
that
that
doesn't
conform
to
your
company's
standards
and
we
can
start
to
alert
on
that
right
with
a
with
the
ever-changing
kubernetes
landscape
and
the
ability
and
ease
for
you
to
be
able
to
deploy
hundreds
of
applications
in
your
for
your
company,
consistency
is
going
to
be
key
right.
A
You
don't
want
to
have
to
go
on
a
long
root,
cause
analysis
for
you
to
try
and
figure
out,
what's
going
on
with
your
application
right,
if
there's
sets
of
standards
that
your
applications
must
have
conform
to
it's
better,
that
the
workload
cannot
be
deployed
than
it
gets
deployed
and
is
vulnerable
right.
A
little
bit
of
friction
with
the
application
developer.
A
What
we
have
we've
seen
sorry
is
that
we
have
a
Public
Image
that
is
running
as
root
and
now
what
we
want
to
do
is
stop
it
from
running
as
root
right
and
there's
a
number
of
options
for
us
to
be
able
to
do
that,
so
nginx
Inc
actually
launched
or
created
a
unprivileged
container
image
so
newsflash.
This
is
the
one
if
you're
running
nginx,
that
I
would
recommend
that
you,
you
use,
you
don't
use
the
Normal
Public
nginx
Image
right
highly
insecure.
A
So
if
we
keep
clicking
through,
we
can
now
see
that,
from
an
ID
perspective
that
we
are
now
running
as
the
nginx
user
right.
So
this
is
a
more
secure
image
than
the
well-known
nginx
image.
So
there
are
sometimes
images
that
are
available
to
you
that
are
more
secure
than
the
ones
that
you
know
and
love
right.
So
don't
just
go
on
Docker,
Hub
and
type
in
the
thing
that
you
you,
you
want
to
leverage
like
nginx
as
an
example
and
just
take
it
verbatim
right.
A
So
yeah
at
a
per
resource
basis,
so
what
I
would
recommend
again
is
is
to
try
and
create
application
templates.
So,
if
you're
using
something
like
hellmore
customized,
the
more
standardized
you
can
make
the
application
from
its
from
its
configuration
standpoint,
the
easier
this
is
going
to
become
to
manage,
so
we
can
force
workloads
in
kubernetes
to
to
not
to
not
run
as
root
right.
A
That's
that's
great,
but
we
can
also
set
the
user
ID
and
group
ID
as
well
in
that
configuration
so
again
same
thing,
same
security
context
now,
but
we're
going
to
force
the
user
and
group
that
we
run
this
application
to
run
as
why
do
we
want
to
do
this?
Why?
Why
is
this
useful
to
us
so
imagine,
I
broke
out
of
this
container
and
I
got
to
the
underlying
host.
Imagine
I
was
running
as
a
root.
I
can
do
whatever
I
want
now
on
the
underlying
host.
A
If
I
set
an
IED,
a
user
ID
or
a
group
ID
that
is
not
going
to
be
on
the
host,
even
if
I
break
out,
it's
highly
unlikely
I'm
going
to
be
able
to
do
something.
That's
why
these
these
uids
and
goods
are
so
high,
I
deliberately
set
them
high,
because
they're
unlikely
to
clash.
If
anyone
manages
to
get
out
of
the
container
onto
the
to
the
physical
node
itself,
so
we
can
set
these
again
with
security
contacts
you
had
endured.
A
A
A
A
This
is
a
much
safer
option.
This
is
the
position
that
we
want
to
be
in.
We
want
workloads
to
not
run
that
don't
meet
our
standards
again,
we
can
see
it
needs
some
privileges
because
it's
you
know
it's
it's
owning
files.
It's
writing
files
all
over
the
place.
We've
set
the
user
and
group
and
the
user
and
group
is
unable
to
be
able
to
achieve
that.
A
So
this
is
where
you,
from
an
audit
perspective,
you're,
going
to
start
having
conversations
with
your
application
developers
and
saying
look:
I've
I've
reviewed
I'm,
trying
to
trying
to
set
some
standards
here
and
your
application's
not
not
working.
Let's
have
that
back
and
forward,
and
you
know,
move
your
application
configuration
to
the
standard
that
we
want
to
set.
A
A
It's
it's
important
that
these
configuration
options
are
are
set
because
we
we
don't
want
to
have
to
keep
repeating
the
same
set
of
audit
all
over
again
right.
We
have
to
keep
going
back
to
the
application
Developers
and
and
telling
them
that
they
have
to
keep
changing.
Some
things
again
do
do
have
to
run
as
root,
and
if
you
want,
if
you
need
them
to
run
as
root,
you
can
set
the
group
ID
to
zero.
There
are
a
couple
of
links
there.
All
of
these
material
is
going
to
become
available
afterwards.
A
Okay,
so
the
next
one
is
privilege,
privilege
escalation
right.
So
if
I
can
elevate,
my
privileges,
I
can
switch
to
pseudo.
I
can
do
all
kinds
of
things
right.
I
can
do
an
app
to
get
update,
for
example,
and
start
installing
all
kinds
of
packages
and
just
go
Rogue
on
them
on
the
container
start,
curling,
endpoints,
etc,
etc.
So,
again,
we're
going
to
create
a
deployment.
That's
going
to
use
this
highly
secure,
Docker
pseudo
image,
and
when
we
look
at
it
it's
got
a
user
and
group
set
right.
A
A
Now
I
can
do
all
kinds
of
things
right
so
from
an
audit
perspective,
when
you
go
into
the
container
and
you
get
access,
try
and
switch,
try
and
elevate
your
privileges
see
what
you
have
available.
You
know
what
what
do
you
have
available
availability
to
be
able
to
do
just
because
they've
set
those
initial
things
and
from
the
from
the
offset
it
looks
like
you're
in
a
good
position,
always
try
and
test
the
boundaries.
A
Maybe
some
of
your
applications
require
sudo
to
be
able
to
see
certain
directories.
This
is
again
another
conversation
with
your
application
developers
start
to
put
your
configuration
that
your
application
needs
in
specific
directories
allow
the
user
that
that
container
is
running
as
to
be
able
to
read
and
maybe
write
to
that
directory.
So
one
of
the
things
that
I
would
recommend
from
a
container
perspective
is
having
a
you
know,
a
slash,
app
directory,
which
is
where
your
application
binary
runs.
A
Slash,
config
for
where
your
config
files
live
and
then
slash
data
for
where
your
data
lives
make.
Now
we
start
to
have
a
standard
right.
We
can
allow
the
user,
whatever
we've,
whatever
you
would
user
ID
and
group
ID
that
we've
specified.
We
allow
them
to
be
able
to
use
those
specific
three
directories
and
nothing
else
we're
now
starting
to
get
to
get
some
secure
standards.
A
So
enable
service
links-
this
is
an
interesting
one.
This
is
a
very
convenient
way
if
I
get
inside
your
container
to
be
able
to
start
to
plot
your
kubernetes
landscape
from
a
kubernetes
landscape.
What
I'm
talking
about
is
the
services
that
are
currently
running,
Within
kubernetes,
so
by
default,
kubernetes
will
add
in
environment
variables
into
your
pod.
To
make
it
convenient
in
inverted
in
air,
quotes
for
you
to
be
able
to
discover
other
Q
other
kubernetes
services.
A
So
what
we're
going
to
do
here
is
we're
going
to
run
a
busy
box
pod
and
if
we
go
inside
that
pod-
and
we
do
an
end,
you'll
see
that
the
service
that
I
just
created
I
know
everything
about
it.
I
know
where
it
is
I
know
the
IP
address.
I
know
the
port
that
it's
currently
running
on
from
a
hacker's
perspective.
This
is
a
dream
right.
Imagine
you've
got
hundreds
of
hundreds
of
these
Services.
All
I
have
to
do
is
get
into
one
I
do
an
end.
I
get
all
of
your
services.
A
I
know
all
the
endpoints
I
know
all
the
ports,
I
just
start
running
attacks
against
them
and
I
figure
out
and
I
can
plot
your
kubernetes
landscape
from
the
inside.
So
it
only
takes
one
one
pod
that
allows
this,
or
has
this
configuration
by
default
for
me
to
start
being
able
to
plot
my
whole
entire
kubernetes
landscape.
A
A
When
we
do
nth,
we
only
get
the
kubernetes
one
right.
We
have
to
get
the
kubernetes
one
to
be
able
to
talk
to
the
kubernetes
API.
If
we
need
to
be
able
to
interact
with
kubernetes.
However,
the
service
that
we
previously
deployed,
we
cannot
see
anymore
so
from
an
Auditor's
perspective.
Think
about
you
know
what
that
what
someone
could
do
with
the
information
by
default
right
so
kubernetes
by
default,
is
giving
me
everything.
A
A
Pretty
insecure
probably
want
to
set
some
setcom
profiles.
Luckily,
kubernetes
provides
us
with
the
ability
to
be
able
to
set
set
comp
profiles,
so
what
I've
done
here
is
deployed
an
nginx
image
and
just
looked
at
the
techcom
profiles
that
it
has
available
and
we
can
see
there
that
there
are.
There
are
none,
however,.
A
Let's
keep
going,
we
can
set
centcom
profiles
by
configuring,
an
annotation
on
the
workload
to
set
a
specific
type,
so
kubernetes
actually
provides
you
with
a
couple
of
defaults
out
of
the
box
that
you
you
may
want
to
use,
or
you
can
create
your
own.
They
are
a
specific
type
of
resource
in
kubernetes
and
then
you
at
your
workload
level,
set
an
annotation
and
then
specify
the
setcom
profile
that
you
want
to
Leverage.
A
A
This
is
the
default
position
that
I
would
go
with
drop
all
of
the
capabilities
and
slowly
but
surely
add
the
ones
that
you
need
right,
don't
allow
all
of
them
and
then
work
backwards.
So
this
is
an
iterative
process.
Excuse
me
that
you'd
have
to
go
on
with
your
application
developers
to
understand
what
capabilities
they
need
within
their
application.
A
A
So
how
do
we
reproduce
this
locally?
So
we
run
the
docker
container
itself
and
we
use
this
cap
drop
flag
and
we
set
them
to
all.
So
this
is
going
to
drop
all
of
the
capabilities.
We
again
are
in
the
same
position,
so
we
can
see
that
it
needs
a
tone.
So
now
what
we
can
do
is
we
can
still
keep
the
drop
all,
but
now
add
the
capability
of
cap
tone
run.
It
again
see
what
happens.
I'm
not
going
to
go
through
this
iterative
process
like
there's
four
or
five
of
them.
A
A
So
this
is
the
actual
nginx
configuration
with
the
very
insecure
running
as
root
image,
with
the
capabilities
that
need
to
be
added
so
again
to
reiterate,
when
you're
performing
the
audit,
one
of
the
things
that
we
should
be
looking
for
is
them
dropping
all
of
the
capabilities
and
only
adding
the
ones
that
they
need
to
add.
If
this
configuration
is
not
set
at
all,
they
have
all
the
capabilities
by
default.
A
Now
we
also
have
images
available
to
us
whereby
we
can
drop
all
of
the
capabilities
because
it
doesn't
need
any
right.
This
is
the
this
is
the
ideal
end
State
I
don't
want
to
necessarily
have
to
add
all
of
the
capabilities
line
by
line
in
my
kubernetes
configuration,
so
by
default,
the
nginx
unprivileged
container
doesn't
require
any
new
capabilities
to
be
added.
Therefore,
we
can
drop
all
this
is
the
ideal
configuration
to
be
able
to
get
to
the
standpoint.
A
A
So
one
of
the
things
to
to
bear
in
mind
now
is
what
is
the
application
actually
doing?
What
does
it
need
to
do
inside
the
container?
Maybe
it's
just
running
a
binary
right
and
it
just
provides
an
API
endpoint
or
maybe
it
actually
needs
to
write
some
configuration
at
startup
for
it
to
be
able
to
know
where
the
database
connection
is
or
where
a
third-party
application
is.
A
A
Obviously,
we
don't
want
to
be
able
to
do
that
again
same
thing
again,
when
I
was
talking
about
having
that
common
directory
structure
within
your
application
configuration.
This
is
why
we
want
to
start
to
be
able
to
do
this
right.
We
want
to
make
the
root
file
system
by
default,
read
only
and
then
have
directories
where
the
application
can
perform.
Its
work
doesn't
need
to
be
able
to
write
to
all
of
the
directories
that
are
possible
on
the
root
file
system.
A
So
what
I'm
doing
here
is
I'm
running
our
nice
Docker
pseudo
image
that
we
run
earlier
and
I'm
running
a
sudo
apt,
update
right
and
now
because
the
root
file
system
is
writable,
I
can
install
all
the
packages
that
I
want.
I
can
run
anything
that
I
want
to
be
able
to
run
right
from
a
hacker's
perspective.
This
is
a
dream.
I
can
install
all
kinds
of
tools.
A
A
A
So
what
we
can
do
is
we
need
to
be
able
to
find
and
locate
the
directories
where
this
application
needs
to
be
able
to
run,
and
then
once
we
have
those
we
can
mount
those
Mount
empty
directories
inside
of
our
container
at
the
specific
directory
location
that
the
application
actually
needs
right.
So
if
we
have
application
configurations
where
we
have
a
standardized
directory
structure,
this
becomes
very
easy
right.
We
have
the
same
directory
structure.
We
create
some
empty
volumes,
they
are
able
to
write
and
read
files
from
those.
A
So
we've
talked
about
some
workload
configuration
and
how
we
can
secure
our
workloads,
but
arbuck
allows
users
and
workloads
to
be
able
to
access
resources
that
are
currently
running
in
the
kubernetes
API.
So
what
I'm
going
to
demonstrate
here
is
the
unnecessary
use
of
a
list
permission
so
kubernetes
by
default
allows
you
to
be
able
to
get
list
and
watch
things.
What
we
are
going
to
do
is
we're
going
to
create
a
service
account
inside
of
kubernetes.
A
B
A
A
A
We've
looked
at
some
of
the
workload
configuration
we
now
actually
want
to
be
able
to
perform
an
audit,
so
things
that
we
want
to
look
for
is
things
that
we've
discussed
and
wanted
to
be
able
to
stop
before
so
some
high
level
ones
containers
running
as
privileged
containers
that
are
allowed
to
perform
privilege
escalation,
containers
that
can
run
as
roots
and
containers
that
do
not
have
a
read-only
file
system.
So
what
we're
doing
here
is
honing
into
workloads
more
than
we
are
our
back.
A
So
there
is
a
tool
called
Cube
audit
by
Shopify
I,
don't
know
if
you
guys
are
familiar
with
that.
That
will
allow
you
to
be
able
to
run
this
and
start
to
look
at
the
configuration
of
your
the
workloads
that
are
running
in
your
kubernetes
cluster
and
see
where
the
insecurities
or
vulnerabilities
are.
So.
We
are
going
to
we've
deployed
keyboard
it
and
we're
now
going
to
run
keyboard
it
privileged
in
our
namespace
that
we've
currently
provided.
A
A
So
we
can
see
here
that
it's
recommending
that
we
we
set
the
we
set
privilege
to
focus
on
all
of
these
applications
that
we've
previously
deployed
there
are.
There
are
a
load
of
Cube
audit
Flags
available
to
you.
You
can
run
keyboard
in
cluster
mode,
which
essentially
runs
it
inside
the
cluster
and
constantly
runs
an
audit,
for
you
gets
a
good
understanding
of
your
kubernetes
landscape
and
provides
you
a
report
out
the
back
of
that.
A
A
Yeah,
so
the
the
URL
that
I
provided
this
URL
here
is
going
to
maintain
online.
It's
the
whole
Workshop
end
to
end.
It
will
go
through
with
you.
You
can
clone
the
Repository
all
of
the
demos,
all
of
the
scripts
that
we've
currently
run
are
are
in
that
repository.
You
can
create
a
gke
cluster
and
run
through
this
whole
thing
yourself.
B
A
So
if
you,
if
you
want
to
be
able
to
run
the
repository
locally,
there
is
a
make
file
task,
just
run,
make
run
from
that
directory
that
will
spin
up
the
website
for
you
locally.
If
you
want
to
run
it
locally
and
if
you
don't,
you
can
use
this
URL
here.
This
URL
is
going
to
be
up
for
the
whole
of
coupon
and
further
on.