►
From YouTube: Webinar: Kubernetes Security Best Practices for DevOps
Description
For many DevOps teams, Kubernetes has become an enterprise IT mandate, but like previous waves of infrastructure change, Kubernetes security best practices must be followed throughout the container life cycle.
Join us for a discussion around Kubernetes security challenges and best practices. You will learn how to:
* stay on top of ongoing Kubernetes hygiene by hardening your nodes, employing RBAC best practices, etc.
* secure your production workloads
* thwart an attack, with a live demo
A
So
welcome
everyone
thanks
for
joining
today's
CNC.
If
webinar
topic
is
kubernetes
security,
best
practices
for
DevOps
looks
like
we
have
a
good
crowd
joining
for
that
and
security
is
always
a
popular
topic.
My
name
is
Phil
Estes
I'm,
a
distinguished
engineer
and
CTO
for
container
and
Linux
architecture
strategy
at
IBM
cloud.
A
Also,
a
cloud
native
ambassador
with
the
CN
CF
and
I
am
your
moderator
for
today's
webinar
and
we're
happy
to
have
Connor
Gorman
here,
a
principal
engineer
at
stack:
rocks
who's
gonna
take
us
through,
but
before
I
turn
it
over
to
Connor
a
few
very
simple
housekeeping
items.
Obviously
this
is
not
a
free
form
open
discussion,
so
you
won't
be
able
to
talk
during
the
webinar
as
an
attendee.
A
There
is
a
Q&A
box
and
we'd
love
for
you
to
use
that
to
get
your
questions
to
Connor
throughout
the
talk
he's
selected
a
few
spots
along
the
way
where
we'll
stop
and
see,
if
there's
anything
pressing
that
he
can
answer,
then
otherwise,
we'll
deal
with
questions
at
the
end.
So
any
time
during
during
the
talk
feel
free
to
open
that
box
and
type
your
question
and
we'll
get
to
it.
A
As
I
said
throughout
the
presentation,
this
is
an
official
webinar
of
the
CNC
F
and
therefore,
as
such,
it's
subject
to
the
CNC
F
code
of
conduct,
of
course,
hopefully
common
sense,
don't
do
anything
in
the
chat
or
in
the
questions
that
be
in
a
violation
of
that
code
of
conduct.
We'd
love
for
everyone
to
be
respectful
of
all
the
participants
and
presenters.
A
A
B
Thank
you
thanks.
Everyone
for
joining,
as
you
said,
I'm
Connor,
Gorman
and
principal
engineer
here
at
sac,
rocks
Zach
Reks
does
community
security
so
right
on
topic,
we'll
be
talking
about
community
security,
best
practices
before
I
worked
in
security.
I
worked
in
infrastructure,
so
been
on
kind
of,
like
both
sides
of
the
same
coin.
You
know
working
on
pushing
containers
through
to
production
and
then
also
kind
of
secure
containers
at
production
as
well.
So,
let's
just
jump
into
it.
B
So,
first
and
foremost,
what
are
we
doing
here
right,
kubernetes
is
is
coming,
the
adoption
is
growing
and
growing
people
are
moving
all
throughout
the
lifecycle
and
different
stages
or
in
death
or
in
prod
right
there
serving
production
workloads
with
kubernetes,
and
you
might
be
somewhere
along
that
spectrum
right.
You
might
be
someone
who's
pushing
kubernetes
at
your
organization,
you
might
be
having
community
pushed
at
you
from
a
security
perspective
or
you
might
just
be
starting
and
trying
to
figure
out
hey
everyone's
doing.
B
Kubernetes
I
need
to
figure
out
what
to
do,
and
you
don't
really
know
where
to
start,
and
hopefully
this
presentation
gives
everyone
a
little
bit
of
of
information
about
that
and
kind
of
like
where
you
could
start
like.
You
know,
just
starting
with
kubernetes,
so
I
think
community
is
coming
realistically
it's
pretty
much
here
and
when
I
find
really
interesting
about.
All
of
these
trends
is
that
you
know
some
other
container
works.
Traders
are
doing
as
well.
B
Communities
is
coming
to
the
top
coop
con
is
starting
to
become
a
huge
conference
and
then
also
the
growth
of
contributors,
which
really
showed
that
it's
a
you
know
very
widespread
group
of
contributors
and
not
just
like
a
couple
companies
driving
the
conversation.
It's
really
kind
of
like
a
whole
community
coming
together
to
build
and
support
kubernetes.
B
So,
first
and
foremost,
communities,
hygiene.
How
do
I
run
the
worker
straighter?
How
do
I
make
sure
that
I'm
securing
that
and
doing
kind
of
light?
Hopefully
what
we
would
consider
the
no-brainer
stuff,
but
in
a
new
world
it's
always
hard
to
figure
out
exactly
what
you
should
be
doing
so
always
upgrade
to
the
current
version.
The
reason
for
this
is
that
the
last
three
versions
are
officially
supported,
especially
when
it
comes
to
vulnerabilities
or
upgrades
or
patches,
and
you
don't
want
to
be
in
a
situation
where
you're
behind
the
trend
right.
B
B
So
the
question
I
usually
get
after
that
is
like
how
do
I
know
what
versions
out
how
do
I
track?
This
I
personally
love
this
Google
group.
It's
just
kind
of
like
a
live
feed.
You
don't
have
to
be
too
involved
with
it,
but
they'll
keep
giving
you
new
updates
about
what
versions
are
out
what
patch
releases
are
out,
and
so
you
can
kind
of
plan
from
there.
Basically
just
looking
at
okay,
you
have
a
new
patch
version.
It
should
be
a
pretty
easy
migration.
B
Why
don't
I
just
migrate
to
the
newest
version,
get
fixes,
get
vulnerability,
updates
and
all
the
above.
So
this
is
this
one
I
like
kubernetes
announced,
guess
you
just
follow
it.
It's
really
easy,
so
more
until
I
kind
of
the
nuts
and
bolts.
Now
what
do
I
do?
This
is
the
key,
our
community,
that,
like
itself-
and
this
is
kind
of
going
to
traditional
infrastructure
approaches
right
so
make
sure
you
control
network
access
to
sensitive
ports,
so
make
sure
you're
restricting
the
ports
use
by
the
couplet
right.
B
There's
been
a
couple
of
cases
where
the
couplets
been
exposed.
You
know
via
the
node
externally,
people
have
exploited
that
right,
I'm
gonna
make
sure
you
limit
access
to
the
criminal
API
server
itself.
You
can
restrict
it
to
IP
blocks.
You
can
assure
that
restrict
it
to
begin.
You
have
it
be
internal
to
your
cloud
writer
there's
a
lot
of
different
options
there,
but
make
sure
you
limit
access
to
the
chromatic
API
server.
There
was
a
recent
vulnerability
where
an
anonymous
user
could
like
DDoS
your
API
server.
A
B
So
for
eks,
specifically
I
think
they
just
announced
support
for
115,
so
they
should
be
real
up
into
that
window,
but
no
I,
don't
think
you
you
shouldn't
avoid
managed
services.
I,
think
you
know
the
cloud
providers
do
a
pretty
good
job
of
patching
them.
You
know:
gke
has
a
lot
of
like
dog
releases
where
they're
they're
bringing
in
patches.
So
you
know,
they're,
really
responsible
and
they'll,
make
sure
that
you're
not
exposed
to
vulnerabilities
so
I.
Definitely
wouldn't
shy
away
from
management
service.
B
A
B
Yes
largely
depends
on
your
organization
how
quickly
you
want
to
move
I
mean
frankly,
I
never
like
to
move
directly
to
the
latest
version.
Sometimes
there's
bugs
to
be
hammered
out,
there's
upgrade
Docs
and
have
to
consider,
but
you
know-
and
hopefully
you
have
a
staging
a
lab-
a
production
environment
right
you're
not
going
to
go
straight
roll
production
and
you
I
will
say
that
you
are.
You
know
in
the
last
three
releases
you
are
covered
in
terms
of
vulnerability,
so
they
will
back
port
the
patches.
So
there's
not
a
ton
of
criticality
there.
B
B
So
we
were
just
talking
about
hardening
node
security
right,
we're
talking
about
physical
access,
making
sure
your
network
is
blocked
off.
So
now,
we've
narrowed
down
our
API
server
to
a
select
group
of
people
that
we
want
to
have
access,
and
now
we
need
to
basically
chop
that
up
into
different
sections
to
make
sure
each
individual
has
the
access
that
they
need
and
only
the
access
they
need,
and
so,
as
a
high
level,
the
way
that
Coover
nazar
backwards.
You
have
people,
you
have
things
called
subjects
which
are
either
users
they're.
B
B
B
So
in
general
yeah
make
sure
you
are
utilizing
our
back,
make
sure
you're
auditing
that
and
looking
at
you
know
what
people
are
doing
and
what
operations
they
can
do.
There's
there's
a
cool
project.
The
recent
came
out
by
Jordan
Liggett.
He
wrote
I,
think
that
will
look
at
your
audit
logs
and
try
to
build
our
back
rules
for
you,
I
haven't
used
it
I
can't
endorse
it
necessarily,
but
it
looks
really
cool.
You
guys
can
check
that
out
awesome.
So
now
we
can
jump
into
work
with
best
practices.
B
I
think
this
is
where
the
bulk
of
kubernetes
security
really
comes
in
I
mean
securing
the
orchestrator
is
number
one.
If
people
have
access
to
the
orchestrator,
then
they
can.
You
know,
change
your
your
services
or
run
things
in
your
cluster,
but
this
is
where
you're
kind
of
exposed
right.
This
is
really
where
you're
running
your
application.
B
So
the
first
thing
to
think
about
in
a
community
environment
which
I
think
is
significantly
different
from
what
we've
seen
before
in
traditional
infrastructure
is
like:
how
do
you
think
about
risk
right
like
what
goes
into
kubernetes,
and
how
can
you
figure
out?
You
know
what
our
risk
points
are
and
how
to
address
those,
and
so
starting
with
the
image
you're.
Looking
at
the
vulnerabilities
in
the
image
what
registry
it
came
from
what
packages
you
have
installed
you're
looking
at,
where
is
this
thing
running?
Is
it
you
know
in
a
production
worker
code?
B
Is
it
in
the
test
cluster
with
no
memory
data
right
you're?
Looking
at
how
is
this
service
configured
as
a
whole?
You
know
what
secrets
does
it
now?
What
storage
doesn't
have
and
kind
of
like?
What's
the
configuration
of
that,
so
you
know
container,
you
know
anything
is
privileged.
You
can
now
host
mounts.
You
can
have
service
accounts
which
have
our
back
access
and
can
access,
kubernetes
and
then
finally
like.
Where
is
it
within
the
cluster
right
and
so
do
it?
B
And
you
know
what
I
like
to
say
is
you're
looking
at
a
community's
deployment
that
has
a
really
critical
network
vulnerability.
If
that's
critical
network
vulnerability
is
exposed
to
be
a
load
on
sir
over
the
Internet
right,
then
that
risk
has
now
been
amplified
right,
and
so
what
you
really
want
to
do
is
think
all
of
these
things
kind
of
come
together,
and
you
know
you
take
that
workload.
You
make
it
privileged
right.
B
That
means
that
someone
can,
you
know,
exploit
your
current
application
and
potentially
get
root
on
the
host
right,
and
so
all
those
things
kind
of
amplify
and
work
together
to
create
what
I
call
like
a
kubernetes
risk
assessment
and
then,
when
you
get
into
behavior
it's
kind
of
like
okay,
now
we're
looking
at
what
this
pot
is
doing.
Is
it
deviating
from
the
normal
and
like
what
active
connections
to
making
you
know?
Is
it
exiting
data?
B
Are
random
connections
coming
in,
and
so
it's
definitely
a
super
interesting
environment
and
kind
of
how
we
like
to
think
about
it,
and
so
what
we
can
do
and
the
approach
that
we've
taken,
the
stack
rocks
is
really
looking
kind
of
all
of
these
factors
in
order
to
kind
of
build
a
risk
assessment
for
you
and
you're.
Looking
at
you
know
what
policy
violations,
so
that's
really
about
your
organization
and
what
your
organization
cares
about
it
in
terms
of
hey
we're.
B
Looking
for
these
things,
you
know,
are
you
running
proxies
we
haven't
seen
before
you
have
image
vulnerabilities,
all
you
want
to
load
bouncer
or
just
a
cluster
IT,
you
know.
What's
the
service
reach
ability
from
the
internet
like
the
stuff
in
the
images
are
interesting.
You
thinking
about
what
components
are
useful
for
attackers?
Do
you
have
a
map
in
your
container
idea
of
curl
W
get
right?
Those
can
be
used
to
go
pull
resources
from
the
internet
and
run
them
in
your
container.
B
How
new
is
your
image
as
we're
talking
about
making
sure
you're
on
the
current
kubernetes
version?
Are
you
on
the
current
distribution
versions,
because
those
can
be
exploitable
and
have
a
lot
of
sea
bees
and
many
times
those
TVs
are
fixable
if
you
just
upgrade
and
then
finally,
what's
your
about
configuration?
Do
you
have
access
to
community
API
server,
so
that's
kind
of
like
how
I
like
to
think
about
it
and
break
it
down
in
terms
of
there's
a
lot
of
different
categories
in
kubernetes
and
it's
kind
of
the
new
thing
it's
like.
B
A
B
A
B
So
I
think
in
general,
what
we
need
to
make
sure
that
we're
doing
is
you
know
having
some
process
in
place
right,
that's
that's!
The
first
start
is
making
sure
that
you
are
looking
at
them
and
auditing
them
right
and
then
trying
to
understand
what
access
people
have
it
can
be.
It
can
be
challenging.
Kubernetes
I
mean
you
know
to
be
quite
honest
and
something
that
we
tackled.
B
That's
back,
Rock
and
basically
like
how
can
we
render
and
show
you
what
access
people
actually
have
right,
because
you're
kind
of
looking
at
a
tango
loaves
are
back
but
there's
tools
and
any
ways
you
can
go
about.
Looking
at
making
sure
you
have
our
back
finely
tuned
in
general.
I
would
say
start
with
the
low-hanging
fruit.
Look
for
the
really
high
privileged
things
and
on
it
those
aggressively
and
you
can
kind
of
work
your
way
down
from
there
I
mean
there
are
some
other
I'll
but
I'll
get
into
here.
A
B
So
I
think
III
think
that
you
hit
nail
on
the
head.
There
I
think
you
can
use
a
PUD
security
policy
to
prevent
that
right
and
then
you
could
also
use
like
other
admission
controllers,
will
do
something
similar
right
like
you
could,
if
you
don't
really
want
to
use
odd
security
policies,
do
you
feel
like
they're
too
restrictive?
You
could
you
know,
create
a
basic
admission
controller
that
will
denied
that
right.
So
that's
an
option
as
well.
A
B
Yeah
I
mean
that
can
be
challenging
right.
I
think
we
can
do
rolling
up
like
you
should
be
able
to
do
rolling,
upgrade
right
and
I
haven't
looked
too
deeply
into
committees,
upgrade
path
in
terms
of
how
that
works
and
manifests
itself
against
your
cluster.
But
if
you
have
multiple
replicas
of
like
masters,
you
should
be
able
to
keep
the
availability
like
higher.
A
B
Mean
so
as
long
as
you're
running
on
top
of
kubernetes
right,
it's
kind
of
like
you're
David,
like
that's
your
application
plane,
the
configurations
will
still
apply.
Great
I
mean
there.
There
are
going
to
be
challenges
if
you're
running
on
you
know
GPUs
and
stuff,
like
that,
you
might
not
get
the
same
level
of
granularity,
but
you
can
get
but
running.
You
know
a
kubernetes
application.
You
can
still
look
at
the
pod
specs.
You
can
still
look
at
the
specs
of
the
applications
and
evaluate
a
lot
of
this
right
and
so
I.
B
A
B
Sure
absolutely
right,
though
you
know,
if
you
can
provide
like
mutual
TLS
out
of
the
box,
for
your
developers,
don't
have
to
worry
about
it
and
certificate
rotation
and
those
are
obviously
great
great
wins
from
a
security
perspective.
I
think
to
what
is
going
to
be
kind
of
hard
operationalize
sometimes,
and
so
you
kind
of
go
back
and
forth
between
the
operationalization
of
it
and
the
security
aspects
you
can
get.
B
But
yeah
I
mean
like
you,
can
get
a
very
highly
grip
like
granular,
pada,
pada,
pada,
pods,
firewall
I'll,
talk
about
network
policies
later
SEOs
kind
of
like
even
deeper
in
that
right
and
but
the
cost
of
that
is
you
know.
I
was
like
operationalizing
it
and
making
sure
all
your
applications
can
run
with
it.
Community
is
doing
stuff
to
make
it
feel
easier
and
to
be
quite
honest
or
adding
sidecars
to
pods
in
the
upcoming
versions,
and
so
it'll
it'll
work
better
with
this
geo.
B
B
Basically
you
you
can
break
down
our
back.
My
teams
right.
You
could
have
someone
be
admin
for
a
namespace,
but
that
namespace
may
not
have
that
many
applications
in
it.
They
could
only
affect
things
on
their
team
and
that's
kind
of
I
would
say
it
gets
you
out
of
doing
finally
tuned
to
our
back,
but
it's
just
a
nice
easy
segmentation
for
our
back.
You
know
native
faces
also
allowing
new
resource
usage
tracking,
so
you
can
see
kind
of
how
many
resources
each
team
is
using.
B
It
allows
for
generic
network
policies
Network
segmentation,
which
I
get
into,
and
it
also
just
for
my
benefit,
makes
coop
cuddle
results
more
more
sane
another
who
ever
listed,
like
you,
know
five
thousand
pods
in
a
single
namespace,
and
you
can't
read
them
and
then
you're
trying
to
filter.
So
that's
just
a
fun
one,
but
it
definitely
helps
when
you're
trying
to
like
you
know,
debug
your
cluster
and
so
we're
talking
about
leveraging
network
policies
and
maybe
a
different
different
time.
B
B
Namespace
isolation
really
helps
ensure
compliance
if
you're
running
a
SAS
model
or
cloud
native
model
with
multi-tenancy
there's
many
times,
you
need
to
make
sure
that
customer
a
and
customer
B's
data
is
completely
segmented
and
creating
a
network
policy
between
those
namespaces
ensures
that
you're
not
accidentally
talking
to
the
wrong
database,
where
two
services
are
talking
to
each
other.
You
know
this
doesn't
come
without
challenges,
so
you
know
what
if
your
environment
already
exists,
how
do
you
go
implement
network
policies
on
top
of
that
right?
B
How
can
you
scale
them
at
your
organization
and
and
how
do
you
make
sure
that
developers
are
enabled
to
build
their
own
network
policies
because
they
have
the
most
knowledge
of
their
own
applications
and
what
their
dependencies
are?
And
so
that's,
like
the
natural
point
for
network
policies
to
be
built
soon,
so
kind
of
a
funny
story.
I
was
trying
to
build
network
policies
two
years
ago
for
staff,
Rock,
Services
and
I.
B
Couldn't
do
it
I
couldn't
figure
out
how
to
do
them
and
create
them
correctly
and
there's
a
lot
of
like
yeah
mold
issue,
and
you
know
empty
brackets
is
different
from
no
brackets
and
it's
really
hard
to
understand.
And
so
what
one
way
that
you
can
really
utilize
network
policies
and
and
create
a
lot
of
value
in
organization
is
looking
at
the
live
traffic
that
you
have
and
then
analyzing
that
and
building
network
policies
based
on
the
live
traffic.
And
so
look
in
this
case.
B
If
you
can
go
distro
list
or
lightweight
based
images,
a
lot
of
those
just
avoid
one
abilities
off
the
bat.
They
don't
really
have
a
lot
of
network
utilities
or
other
utilities
that
just
are
below
in
containers
that
can
be
used
by
attackers
and
then
finally,
like
make
sure
to
scan
your
images
and
enforce
on
them
to
make
sure
they
don't
into
your
environment
again
once
you've
stopped
them
in
your
environment.
So
the
way
I
like
to
to
really
go
through
it
is
you
look
at
a
cluster.
B
You
have
you
know
a
certain
set
of
vulnerabilities,
you
analyze
those
vulnerabilities
and
try
to
reduce
them
over
time,
and
you
know
you're
doing
continuous
continuously
trying
to
reduce
your
risk,
and
then
you
can
say:
okay
well,
I
know
this
image
is
bad.
I
marked
it
as
bad
and
basically
don't
let
people
to
deploy
it
into
your
environment
again
and
make
sure
they
fix
their
vulnerabilities.
B
Won't
let
me
deploy
my
application
because
then
you're
kind
of
butting
heads
at
that
point:
you're
not
really
working
together.
One
of
the
main
challenges
with
slimming
down
images
is:
how
do
you
debug
right?
How
do
you
have
you
don't
have
curl
or
W
get
you
removed
OpenSSL?
How
can
you
go
figure
out?
Why
you
application
a
can't
talk
to
application
B?
So
looking
ahead,
this
is
not
something
to
do
today.
B
Ephemeral
containers
there
are
in
alpha
as
of
116,
so
don't
use
them
in
production.
Use
them
with
caution,
but
the
general
concept
is
that
you
can
take
a
container,
bind
it
to
an
existing
pod,
so
that,
then
you
can
run
debugging
commands
network
utilities.
What
this
means
is
that
your
main
application
right
that
are
you
know
that
are
exposed
on
the
Internet,
don't
have
to
have
a
lot
of
these
networks
and
debugging
utilities.
B
So,
in
my
opinion
this
is
a
huge
win,
because
people
can
go
try
to
exploit
your
container,
you
don't
have
any
packages
or
utilities
that
they
expect
and
then
they
move
on
right.
A
lot
of
attackers
are
just
scripts
that
they
just
run
against
public
endpoints,
see
if
they
can
exploit
us
was
to
the
governor
ability
once
they
can't
they
move
on
because
you're
not
that
high
value
of
a
target
anymore.
A
B
So
I
think
they're,
both
perfectly
valid
I
think
they
definitely
have
different
use
cases
right
and
so
a
lot
of
like
cloud
providers
now
are
providing
container
optimized
OSS,
and
so
you
look
at
like
Google
costs
or
I.
Think
I
think
it
is
us
might
have
justice
like
recently
announced
one
but
basically
running
you
know
optimized
container
LS.
No,
those
are
the
kind
of
traditional
benchmarks
for
going
to
don't
apply
necessarily,
but
I
do
think.
Yes,
you're
running
an
abuti
distribution
and
a
rel
distribution
following
the
best
practices.
B
The
people
who
read
these
benchmarks
are
really
sure,
and
they
know
a
lot
about
the
subject
matter
and
so
I
think
those
are
always
good
to
follow
it
right.
I
think
you
know,
if
you
can't
do
both
right.
You
know
the
community
specific
ones
all
about
to
burn
Eddie's,
and
you
know,
file
permissions
and
stuff
like
down
a
host,
and
then
you
know
the
booboo
to
ones
about
you
know
generally,
your
your
host
securities,
though
I,
think
I,
think
both
are
necessary.
B
B
Yeah,
so
you
know,
OpenShift
in
the
recent
versions
was
like
very
close
to
parity
with
communities.
Obviously,
some
some
difference
isn't
just
in
the
distributions,
but
yeah
all
of
you,
things
can
be
applied
on
OpenShift.
You
know
I,
know
personally,
because
who
you
rented
a
condo
and
shift.
So
it's
you
know
all
of
these.
All
of
these
things
still
apply.
You
know
you
have
some
minor
differences,
exposing
the
internet
right.
You
need
to
look
for
routes
potentially
and
not
load
balancers
right,
there's
kind
of
some.
B
A
B
That's
a
tough
question,
I
think
in
general,
as
its
it's
hard
I
mean
honestly
it's
hard
to
evaluate
these
solutions.
I
I
think
I
tend
to
lean
towards
a
cloud
provider
hosted
solution.
If
you
can
use
like
kms
or
you
know
that
are
provided
by
the
cloud
provider,
that's
usually
pretty
secure
most
easily
very
secure.
B
I
say
that
I
know
that
a
lot
of
people
use
volved,
I
think
having
a
hash
course
for
a
lot
of
work
into
that
as
well,
and
so
you
found
a
lot
of
people
or
have
been
successful
with
vault,
and
so
you
know,
I
think
talk
to
your
peer
see
what
they're
using
you
know
what
works
for
them,
and
especially
from
operational
and
entity
or
security
perspective,
but
yeah
yeah
I,
don't
have
like
a
great
answer
for
that.
I'm.
Sorry.
B
I
mean
and
you
can
be
totally
running
on-prem
and
then
you
don't
have
any
of
those
options
right
and
so
a
lot
of
committees
deployments
are
on-prem,
and
so
you
know
you
kind
of
need
to
go
to
a
third
party
in
and
get
a
solution.
I
mean
the
one
thing
I
will
say
is
don't
roll
your
own
when
it
comes
to
you
know,
secrets
management.
A
It's
yes,
someone
has
a
question.
You
should
have
view
of
the
network,
including
the
API
server,
and
so
their
question
is,
you
know:
does
that
in
a
cloud
managed
service
g,
ke
e
KS
I
cast
a
lot
of
times.
You
don't
have
access
to
the
master
nodes.
You
know,
are
your
suggestions
different
for
that
scenario
or
how
do
you
interact
when
you're
not
controlling
those
moods.
B
A
B
B
B
If
there's
not
that
that's
definitely
a
challenge
and
so
kind
of
have
to
to
work
with
what
you
have,
but
yeah
I
mean
you
should
always
try
to
inspect
or
file
tickets
or
try
to
updates
for
those
things
and
make
sure
that
people
are
considering.
You
know
just
restricting
they're
restricting
access
to
the
API
server
yeah.
A
And
just
because
I
work
for
a
cloud
provider,
you
know
I
would
say,
go
search
the
for
hardening
or
security
guidelines
for
your
cloud
provider.
They
usually
want
to
provide
you,
you
know,
help
and
documentation
on.
You
know
what
ports
they're
trying
they're
using
and
what
traffic
goes
where
so
your
specific
provider
should
be
able
to
provide
you
with
guidance
on
that
yeah.
Exactly
someone
has
a
question
you
you
announced
or
revealed
kind
of
this
new
ephemeral
containers
feature.
That's
I've
seen
a
lot
of
people
chatting
about
even
in
the
last
few
days.
A
B
So
my
understanding
of
how
they
work
is
that
you
they
bind
into
the
names
base.
So
it's
visually
I
think
they
just
add
another
container
to
the
pod
and
then
it
just
binds
into
all
the
same
namespaces
as
a
container.
Alright,
the
rest
of
the
pod
so
you're
in
the
same
network
namespace,
and
so
you
can
get
the
same
like
network
profile
where
you're
trying
to
like
curl
or
W,
get
or
debug,
and
so
I
think
when
two
alpha
on
one.
B
A
Yep
yeah
there's
definitely
an
interesting
area
watch,
let's
do
one
more
and
then
let
you
do
the
demo
and
make
sure
we
have
plenty
of
time
for
that
and
then
we'll
come
back
to
see.
What's
left
so
last
one
for
now,
have
you
evaluated
DoD
and
I
assume
they
mean
the
US
Department
of
Defense
container
image
base
or
base
images?
Do
you
feel
be
preferable
to
use
these
vs.
Alpine
or
other
hard
district?
You
know
you
had
mentioned
about
minimal
bases.
B
B
I,
don't
think,
there's
really
like
hey.
You
should
use
X
Y
&
Z.
There's
no,
like
cookie
cutter
thing
that
you
can
do
for
your
organization.
It
depends
on
which
other
applications
you're
running.
What
features
are
using
of
these
distributions
and
kind
of
all
of
that
so
I'm
kind
of
weary
of
saying
yeah.
We
can
definitely
use
you
know:
X
Y,
Z,
yep,.
A
B
So
I
love
being
through
this
and
I
know
a
lot
of
you
have
a
lot
of
questions.
So
what
we're
gonna
explore
this
in
this
specific
demo
is
we're
gonna
explore
one
of
my
favorite
configurations,
which
is
the
read
on
the
root
filesystem,
which
I
think
it's
a
great
way
to
stop.
Attackers
make
utilities
I
might
actually
skip
this
one
it'll
be
in
the
slides,
but
that
one
is
a
little
harder
and
then
network
policies
because
I'd
like
to
show
which
I
think
are
a
great
way
to
start
in
terms
of
network
segmentation.
B
So
what's
a
read-only
root,
filesystem,
it's
exactly
what
it
sounds
like.
Basically,
you
can
make
your
entire
pods
filesystem
read-only,
which
means
that
it
when
an
attacker
comes
and
tries
to
drop
a
payload
onto
your
filesystem.
It
will
fail
right.
A
lot
of
attackers
and
I.
Don't
know
if
people
have
ever
used
Metasploit,
but
a
lot
of
times
the
payloads
are
dropped
in
slash
temp,
which
are
just
super
traditionally
always
read.
Write
on
VMs
and
other
servers.
Temp
needs
to
be
read
right.
B
A
lot
of
applications
to
rely
on
that
kind
of
the
beauty
of
containers
is
that
typically
you're
running
one
specific
application.
Hopefully
you
can
know
exactly
what
that
application
is
doing
in
terms
of
reading
and
writing
files,
and
so
you
can
make
slash
temp
read-only,
for
example.
If
you
do
need
to
read
write
capabilities,
you
can
mount
volumes
at
a
specific
path
and
that
will
become
readwrite.
So
you
can
make
a
majority
of
your
cells
of
story
domain.
But
then
it's
specific
path
read
write,
and
so
let
me
jump
into
it
here.
B
I'm
gonna
launch
an
Apache
struts
pod.
This
is
the
version
that
was
exported
Equifax,
and
so
what
it
basically
happens
is
that
I
can
show
you
what
the
exploit
will
look
like.
You
can
run
a
curl
with
a
header
and
then
basically
it'll,
give
you
remote
code
execution
and
you
can
launch
a
shell.
What
we're
going
to
do
is
we're
going
to
download
a
minor
D
binary
and
run
it,
and
so,
if
I
go
ahead
and
run
an
exploit,
we're
going
to
pour
it
forward
to
the
stretched
pod.
B
There's
kind
of
like
crypto
jackin
exploits
have
been
like
fairly
popular.
It
happened
to
Tesla,
has
a
curated
API
server
open
and
someone
was
running
like
monaro
miners
and
just
like
stealing
their
resources.
You
know
it's
not
the
worst
thing
that
could
happen,
but
it's
still
something
that
you
definitely
know
what
happened
in
your
organization
and
so
what
I'll
do
here
is
I'll,
go
ahead
and
apply
a
read-only
file
system.
No
I'll
show
you
the
docker
file
that
I
applied.
B
So
what
I
did
here
is
I
running
Apache
server
basically
needs
to
write
to
user
local
Tomcat,
so
I
made
that
a
volume
in
the
docker
file
and
obviously
I'm
running
a
very
portable
image
and
then
the
rest
of
the
filesystem
is
read-only,
and
so,
if
I
see
this
here
right,
you
can
see
right
here
that
I
made
this
awesome
tomato.
So
at
this
point,
user
local
Tomcat
is
read/write,
but
the
rest
of
the
pod
is
is
read-only
reponse
them
I'll
go
ahead
and
rerun
the
exploit
right
and
we
tried
to
write.
B
They
tried
to
write
it
to
the
root
path
and
it
failed.
So
this
is
just
a
super
simple
way
that
you
could
take
a
pod
and
make
it
read
only
and
then
basically
any
attacker
he
tries
to
drop
a
payload
will
be
denied
the
next
question
I
get
after
this
is
ok
cool
that
was
great.
But
how
do
I
make
my
application
read-only?
B
How
do
you
know
where
Internet's
right,
that's
temp
files
right
like
how
do
I
know
that
it
writes
to
var
cash
engine,
X
and
so
I
like
this
tool,
you
just
use
docker
disk,
you
can
look
at
specific
pod
and
it'll
show
you
the
changes
in
the
file
system,
and
so
in
this
case
you
know,
I'd
put
a
mouth
point
and
bar
cashed
in
genetics.
I
need
to
figure
out
if
engine
X
will
run
with
flash
run
engine
next
day
that
that's
readwrite
and
the
rest
of
these
are
secrets
which
kubernetes
will
mount.
B
So
you
don't
need
to
worry
about
those
those
will
be.
There
should
be
reading
anyway,
because
they're
secret,
and
so
basically
this
is
a
sectional
tool
you
can
use
to
to
see
which
files
have
changed
in
your
file
system
and
figure
out
which
path
we
need
to
be
read
right.
So
that's
how
you
can
kind
of
spell
that
problem
you
have
to
use.
You
know
it's
a
little
manual
and
a
little
intensive
in
terms
of
doing
this,
so
I
think
it's
definitely
one
of
the
biggest
benefits
making
your
file
system.
B
Awesome
I
will
skip
winter
utilities
and
come
back
to
it
if
we
have
time,
but
I
will
jump
into
network
policies.
This
is
an
example
of
a
network
policy.
Basically,
you
use
these
things
called
pod
selectors
to
determine
which
pods
this
network
policy
applies
to.
So
in
this
case,
we're
going
to
match
any
pod
in
the
default
namespace,
because
I
didn't
didn't,
give
a
name
space
but
don't
match
any
part
of
us
in
the
default
namespace
that
has
the
key
label
app
and
then
web.
B
So
it
matches
any
app
web
pod
and
then
what
I'm
saying
is
I'm
allowing
ingress
from
any
namespace
that
has
the
team
operation,
so
I
need
from
a
space
for
my
operations
team
and
then
anything,
that's
type
monitoring.
So
you
know
super
calm
and
imagine
you're
running
from
easiest
you're
running
it
in
your
monitoring
namespace.
You
know
you've
labeled
it
with
team
operations
and
you're
curling,
all
of
the
other
endpoints
to
pull
and
scrape
all
the
metrics.
This,
for
example,
would
allow
that
this
would
allow
you
know.
B
So
I
go
ahead
and
add
this
Network
policy.
Basically,
what
I'm
saying
here
is
that
I'm
gonna
deny
and
I
can
print
ourselves
I'm
going
to
deny
egress,
and
so
this
is
where
it
gets
challenging,
because
I
have
specified
a
policy
that
I
want
to
apply,
except
it
doesn't
have
any
selectors.
And
so,
if
you
have
no
network
policies,
that
means
you're.
B
It's
completely
open
communities
wants
to
be
usable
by
default
right
on
the
box,
and
so
no
network
policy
means
no
network
restrictions
and,
if
you
add
a
policy
side
egress,
but
you
don't
specify
any
any
allowed
connections,
I
mean
you're
going
to
deny
all.
And
so
in
this
case
I
know.
My
apache
stretch
should
just
be
serving
traffic
and
not
sending
traffic,
and
so
I'll
go
ahead
and
try
to
run
the
exploit
again
and
I,
possibly
still
read
only
or
I,
don't
have
network
policies
enabled.
B
Classic
classic
demo
so
busily
what
should
happen
is
that
we
should
deny
the
network
traffic.
I
will
note
that
you
have
to
create
gke
clusters
with
network
policies
on
which
is
apparently
what
I
did
not
do,
because
I
didn't
restrict
any
network
access,
so
that's
exciting,
but
yes
make
sure
that
your
cluster
is
enabled
to
have
network
policies,
and
I
will
note
that
some
see
a
nice
support,
created
Network
policies
and
some
don't
and
so
the
default
one
GK.
B
Doesn't
it
screwed
net
and
and
other
providers
do
and
don't
so
you
know
kind
of
one
of
the
mainland
that
do
is
like
calico
or
helium
will
have
their
own
network
quality
implementation.
Awesome
with
that.
I
will
say
that
security
is
hard,
as
you
just
saw,
and
and
that
it's
always
that
I've
got
a
continuous
process.
So
you
have
to
continually
try
to.
You
know
pick
a
couple
low-hanging
fruit
for
your
organization
work
through
those
make
sure
that
you
know
you're
looking
at.
B
If
you
wanted
to
agrees
only
response
them,
you
want
to
implement
network
policies,
you
know
make
sure
you
kind
of
go
through
each
of
those.
You
know
pick
one
start
with
one,
and
you
know
anything
you
can
do
will
start
blowing
here
so
start.
Lowering
your
risk
and
increase
your
security
posture
awesome
bill.
Do
we
have
any
questions?
B
A
We
do
we
saw
up
some
questions.
First,
some
just
practical
matters.
People
asked
about,
as
you
were
doing
the
demo.
One
person
asked
if
you
know
if
the
exploit
is
available
for
demo
purposes
anywhere
and
then
related
to
that,
you
know
any
of
your
scripts
or
your
demo.
Content
is
any
of
that
available
anywhere.
A
B
A
Great
and
then
yeah
so
I'll
tee
up
some
questions.
Michelle
one
of
Connor's
colleagues
has
been
helping
me
filter
those.
If,
if
your
question
doesn't
get
answered,
Michelle
is
offering
two
to
handle
those
offline.
You
can
see
Conners
email
right
there
on
the
screen.
Michelle
is
Michelle
at
stack,
rocks
calm,
so
whatever
we
don't
get
to
feel
free
to
follow
up
with
with
either
of
them,
but
here's
what
here's
a
few
more
that
have
come
in
so
back
to
networking.
What's
your
take
on
new
port
services,
since
the
service
is
exposed
via
the
hosts
IP.
B
Right
so
typically
try
to
avoid
in
dead
port.
It
depends
on
what
your
knows
your
on-prem
are
in
the
cloud.
You
know
cloud
providers
will
provide
load
balancers
for
that,
and
then
also
you
can
make
your
note.
Ip's
not
be
external
right.
So
if
you
are
going
to
use
a
load
balancer
from
like
DJ,
for
example,
you
could,
you
know,
create,
create
a
load,
balancer
object
in
kubernetes,
and
then
that
might
bind
internally
to
a
node
port.
But
you
shouldn't
need
to
have
your
nodes
exposed
over
the
Internet
yeah.
A
B
So
you
know
typically,
yes
right,
you
know
I've
seen
there's
a
lot
of
implementations
of
this
I
don't
have
like
a
specific
solution,
but
there's
a
lot
of
implementations
of
this
in
terms
of
process
or
or
tools.
I
recently
saw
one
where
someone
was
needed
to
use
like
root
access,
and
then
they
had
to
fill
in.
Why
and
they
have
to
send
you
know
they
fill
in.
Why
and
then
basically
like
they
would
be
granted
that
access
through,
like
internal
systems,
whether
it's
like
LDAP
or
other
authentication
systems
and
so
I,
think
I
think
that's.
B
A
really
good
process
is
making
sure
that
one
that
you
know
operations
can
do
things
that
they
need
to
do
right.
At
the
end
of
the
day,
what
you're
trying
to
do
is
run
applications
and
serve
traffic,
and
so
you
gotta
make
sure
that
you're
enabling
people
to
do
that,
but
also
making
sure
that
the
proper
to
document
that
and
make
sure
people
are
abusing
that
system
as
well.
A
Yep
yep
all
right,
so
a
couple
questions
more
on
kind
of
roles
and
and
separation
of
duties
who
typically
performs
these
kind
of
policy
generation
management.
Would
you
see
this
a
security
team
or
DevOps
engineering
and
again
obviously
that
depends
on
you
know
whether
an
organization
is
still
kind
of
operating
in
traditional?
You
know
silos
or
has
really
you
know
done
that
transformation
to
more
DevOps
approach?
What's
your
view,
yeah.
B
I
think
in
a
kubernetes
environment,
security
and
DevOps
need
to
work
really
closely
together,
right,
I.
Think
if
you
want
to
scale
security,
you
need
to
push
it
into
developers
and
DevOps
right,
like
you
need
to
enable
people
to
do
the
right
thing.
Right,
I,
think
I.
Think
everyone
wants
to
do
the
right
thing.
B
You
know
we're
talking
about
vulnerabilities,
for
example,
something
that
I
really
like
is
you
can
see
like
if
the
vulnerability
is
fixable
right,
and
so,
if
you
tell
the
developer
that
this
vulnerability
is
fixable
by
upgrading
a
package,
I
think
the
develop
developer
will
go
and
upgrade
the
package
right,
because,
typically
you
know
that
might
not
have
any
impact
on
their
application,
but
the
security
posture
better
right,
and
so
you
know,
and
developers
are
configuring,
their
own
services
or
using
communities
to
do
that.
Right.
B
Security
needs
to
be
a
part
of
that
to
understand
hey
I'm,
putting
in
these
controls.
Here's
how
we
can
here's,
how
you
can
write
your
applications
to
obey
these
controls,
for
example,
or
your
the
process
for
you
to
run
privilege
and
so
I
think
you
really
need
to
work
hand-in-hand
in
kind
of
like
a
criminai,
his
environment
and
in
order
to
utilize
have
a
lot
of
the
contracts
Carrillo's
gives.
You
are
available
for
security.
A
B
A
B
So
something
that
seemed
recently
I
don't
have
too
much
experience
with
this
honestly.
I
typically
use
the
manage
providers,
but
still
a
lot.
He
will
start
using
certain
manager.
It's
just
something
to
look
at
I,
wouldn't
endorse
it
necessarily
I.
Just
it's
a
tool
that
I've
seen
used
and
so
I
think
it
warrants
a
look.
A
B
There's
nothing
inherently
wrong
with
helm.
I
think
you
hit
the
nail
on
the
head
there
with
the
2
to
3,
upgrade
just
make
sure
you
move
to
3
sitting,
get
rid
of
Taylor,
you
know,
and-
and
that
was
one
of
the
main
reasons
they
got
rid
of.
It
was
for
security
purposes,
but
yeah
I
mean
helm
in
general
range.
Just
is
creating
community
objects
right,
and
so
it's
the
same.
Security
applies,
be
careful
about
secrets.
I've
seen
a
lot
of
different
solutions
for
a
helmet
secrets,
but
yeah
I
think
that's
the
one.
A
Alright,
we're
winding
down
just
a
couple
couple
minutes
left
here's
an
interesting
one
about
the
mission
controllers
or
validating
web
hooks.
How
do
you
protect
them
and
the
assumption
is
you
know
someone
with
a
preferred
access
can
create
a
web
hook.
That's
actually
doing
something
malicious,
like
exfiltrating
data.
Is
there
any
guidance
in
this
space?
A
B
Can't
create
validating
web
hooks,
you
know,
or
if
they
can,
that
they're
going
through
a
specific
process
to
do
so,
I
think
there's.
Definitely
a
security
concern
with
creating
you
know,
potentially
someone's
extolling
data
I
think
there's
other
ways.
People
might
do
that,
but
not
all
doing
well
votes
to
also
need
to
be
very.
B
You
need
to
be
very
careful
about
them,
because
they're
going
to
be
in
the
critical
path
of
your
API
server,
and
so
you
know
sometimes
they
can
take
down
your
entire
API
server,
and
so
you
got
to
be
very
careful
about
the
ones
you're
using
make
sure
you
trust
them
and
so
definitely
kind
of
fine
during
our
back
privileges.
There
and
auditing
of
that
is
definitely
important.
Yeah.
B
There's
a
lot
of
different
tools.
Stack
rocks
is
a
tool,
for
example,
but
you
know
there's
other
site
cards
that
you
can
use.
I,
yeah
I.
Think
it's
hard
to
do
just
be
a
tracing
without
I
mean
it
sounds
bad,
but
but
that's
what
should
be
tracing
so
you
need
to
use
like
typically
done
via
a
sidecar,
but
you
don't
have
to
use
full
on
is
do
right.
You
could
use
other
sidecars.
A
B
So
I
would
have
to
look
into
cured.
I've
never
looked
at
it.
So
I
don't
really
have
an
opinion
on
that,
but
you
know
if
it
develops,
you
pass
things
into
a
nice
tool.
I
think
you
know
anything
that
helps
you
patch.
An
upgrade
and
stay
up
to
date
is
always
like
a
tool
worthwhile.
Looking
at
but
I
don't
have
any
specific
opinions
on
that.
Yep.