►
From YouTube: OFFICE HOURS: Kube Security - DOs and DON’Ts
Description
Learn the do’s and don’ts of implementing a successful Kubernetes security strategy from hands-on practitioner Connor Gorman, principal engineer at StackRox. Listen to our first-ever virtual Office Hours to to hear the questions answered on the security challenges you must address and the best practices to follow. Questions answered were on how to:
- Shift security left by embedding security into the software supply chain
- Harden your Kubernetes infrastructure by enforcing configuration and compliance best practices
- Protect workloads running in production environments from external threats
- Ensure that security poses minimal operational risk
A
So
welcome
everybody
to
our
inaugural
office
hours,
I'm,
McClane
VP
of
Marketing,
here
at
stock
rocks
and
I'm
joined
today
by
Connor
Gorman,
we're
here
to
answer
your
questions
on
coop
security.
I
want
to
let
you
know
about
a
couple
of
other
things:
we're
going
to
be
asking
a
couple
polling
questions
along
the
way
because
we'd
like
to
know
where
you
are
in
your
coop
journey
and
you
might
occasionally
hear
another
voice.
Chris
Porter,
our
lead
solutions.
Engineer
is
also
with
us
today.
O'connor
go
ahead
and
take
it
away,
except.
B
I'm
for
joining
hope,
everyone's
staying,
safe,
yeah,
I'm,
Connor,
Gorman
I'm,
a
principal
engineer
at
stack,
rocks
I.
Previously,
you
know
before
stack,
rocks,
worked
in
infrastructure
and
I've
been
working
on
our
stack
box
platform.
You
know,
I
am
super
interested
in
love,
kubernetes
and
I.
Think
the
security
side
of
it
is
particularly
interesting.
So
you
know
this
is
pretty
relaxed.
Pretty
open.
You
know,
ask
ask
away
any
questions
and
I'll
do
my
best
to
answer
all
of
them.
B
You
know,
like
Michelle
said
we
had
a.
We
had
a
webinar
with
C&C
f,
you
know
there
here
are
some
just
like
top
highlights
for
right.
You
know
stay
up
to
date
on
kubernetes
in
terms
of
you
know,
versioning,
you
know
try
to
stay.
You
know
within
this
three
version
window,
which
you
know
the
community
has
as
committed
to
maintaining
backports
for
vulnerabilities
to
you
know,
make
sure
you,
you
harden
your
nodes.
B
You
have
CIS
kubernetes,
CIS
docker,
you
know,
depending
on
on
which
engine
you're
using
and
you
know,
also
stole
you're
still
gonna
follow
the
best
infrastructure
practices.
You
know
restrict
access
via
networking
in
our
back
right.
Don't
leave
your
API
server
open
to
the
world?
If
you
can
help
it,
you
know,
make
sure
you're
using
role
based
access
control.
You
know
principle
of
least
privilege
is,
is
always
King.
You
know
use
the
group
native
constructs
to
really
help
you
out
namespaces
and
network
policies.
B
You
know
segment
segment
to
your
your
kubernetes
cluster,
and
so
you
can
really
provide
fine-grained
access
and
and
controls
there.
You
know
and
then
you
know,
slim
down
your
images
lets.
You
know
it's
make
sure
that
we
don't
have
huge
bloated
images
which
have
impacts
on
network
and
there's
also
tools
that
attackers
can
use
that
are
in
a
lot
of
base
images
that
are
for
convenience.
But
you
know
maybe
you're
running
a
go
marrying
you,
you
don't
need
these
extra
packages.
B
So
let's
really
try
to
you
know
slim
those
down,
and
so
that's
just
a
couple
highlights-
and
you
know,
let's
just
go
ahead
and
jump
into
some
questions.
Oh
you
know
what
one
question
that
was
asked
in
advance
was
around:
you
know
how
do
you,
how
do
you
evaluate
risk
and
score
various
threats
to
kubernetes
right?
And
so
you
have
workloads?
You
know
master
nodes,
CLI
API,
you
know
control
playing
at
CD
right
criminais.
B
B
You
know
they
make
sure
that
you
have
proper
permissions
and
ownership
on
files
that
you're
using
you
know
the
correct
parameters
right
like
you're,
not
allowing
I
thought
amiss
off
that
you
have
our
back
and
abled,
and
so
there's
a
lot
there
just
to
like
kind
of
do
sandy
checks
against
your
master
nodes
and
also
the
API.
You
know
for
API
control,
I
think
about
our
back
a
lot
right.
Let's
make
sure
that
you
know
we're
segmenting
that
API
correctly
that
people
only
have
access
to
what
they
need
to
have
access
to.
B
You
know
make
sure
that
API
is
not
on
the
internet.
I
mean
there's
a
in
some
recent
vulns
around
DDoS,
where
you
know
anonymous
teacher
could
send
a
payload
that
would
basically
make
your
API
server.
You
know,
run
recursively
and
run
out
of
memory
and
ran
out
of
CPU,
and
so
those
are
those
are
always
important.
You
know
and
then
of
course
like
protecting
your
data
playing
with
best
infrastructure,
best
practices,
I
think
they're
all
kind
of
come
together
there,
and
so
that's
really
really
important.
B
I
mean
I,
you
know,
I
can
go
on,
I
could
talk
forever.
You
know,
I
think
another
important
aspect
of
besides
just
kubernetes
infrastructure
itself
right,
like
the
the
individual
moving
parts,
is
also
like
workload
risk
and
so
there's
a
ton
of
components
that
go
into
that
and
so
you're.
Looking
at
what
privileges
and
capabilities
is
that
container?
Have
you
know
what
what
are
the
resource
limits
and
requirements?
Let's
make
sure
that
they're
set,
you
know,
looking
at
service
account
exposure.
Is
that
on
a
load
balancer?
Is
it
publicly
available?
B
You
have
Network
policy
set
up,
so
I
could
only
talk
to
this.
You
know
the
other
micro
services
it
needs
to
talk
to.
You
know,
there's
a
whole
encapsulation
of
that
which
is
really
at
the
kubernetes
level,
and
so
with
all
that
kind
of,
like
rich
context
around
kubernetes,
you
can
really
figure
out
how
risky
something
is
within
your
specific
environment
right.
So
you
might
have
a
really
high
CDE
that's
available
via
network,
but
if
you've
buried
that
you
know
six
layers
deep
into
your
networking,
you
know
it's
less
likely
to
be
exploited.
B
C
Conor
there's
some
questions
coming
in
from
the
chat.
The
first
one
is
about
your
second
recommendation
here
about
hardening
nodes.
What
does
that
really
look
like
in
terms
of
you
know
what
work
do
I
have
to
do
if
I'm,
using
like
a
managed
service
like
AWS,
eks
or
something
like
Google
gke,
like
don't
the
cloud
providers,
do
that?
What
else
do
I
need
to
look
out
there?
Yeah.
B
So
I
mean
they
also.
A
lot
of
cloud
providers
also
have
a
variety
of
ways
that
you
can
run
near
nodes
right,
so
Google
has
container
optimized
versions,
Amazon's
coming
out
with
them
as
well
right,
and
so
you
know
just
really
figure
out
exactly
what
you
need
and
if
you
can
run
on
those
levels
of
infrastructure-
and
so
you
know,
there's
a
bunch
of
new
technologies
coming
out
from
the
cloud
providers
themselves.
B
Where
you
know,
maybe
you
can
opt
in
to
using
some
of
these
instead
of
using
kind
of
like
maybe
you
know,
just
in
a
Bluetooth,
flavor
or
something
and
so
I
think
I
think
that's
a
powerful
thing
and
and
also
like.
You
should
always
verify
that
you
know
the
defaults
and
cloud
providers
are
something
that
you
are
comfortable
with
from
a
security
perspective.
You
know,
I
know
that
master
masters
for
Communities
are
always
publicly
available,
which
is
usually
for
a
convenience
saying.
B
You
know
you
always
access
it,
but
maybe
you
can
put
that
on
a
you.
Maybe
you
can
have
a
private
GK
cluster
and
you
know,
depending
on
your
your
organization's
policy,
so
those
are
always
always
good.
Ideas
to
you
know
trust
the
cloud
providers
there
they're,
you
know
good
at
what
they
do,
but
also
you
know
see
what
else
you
can
do
in
terms
of
hardening
the
you
know,
even
that
infrastructure.
C
B
B
What
resources
yeah
I
talked
about
this
in
the
CN
CF
webinar,
but
Jordan
like
it
had
a
pretty
cool
project
where
you
would
look
at
you
know:
kubernetes
are
back
audit
logs
and
then
you
can
map
them
to
users
and
see
if
they
had
too
many
permissions
based
on
the
are
back
rules.
So
this
is
kind
of
a
cool
way
that
you
could.
You
can
use
those
audit
logs
to
scope
down,
but
you
know
also.
C
Okay,
are
you
familiar
with
G
K
ease,
new
workload,
identity?
There's
a
question
about
that,
and
actually
the
question
here
is
about:
how
do
we
implement
that
kind
of
workload,
identity
somewhere
else
like?
Is
there
an
alternative
for
environments
running
on
premise
in
in
like
a
VMware
like?
Is
there
a
general
kubernetes
way
they
do
that
I
guess.
B
C
Yeah,
we'll
get
back
to
folks
that
are
asking
those
questions
really
do
appreciate
it.
The
next
question
here
is
actually
going
back
to
I.
Think
we're
talking
about
hardening
like
a
gke
cluster.
You
know
there
are
some
hardening
guides
out
there
using
some
of
these
g-cloud
flags
too.
You
know
when
you're,
when
you're
launching
it
one
of
them
is
enabling
private
nodes
and
another
is
enabling
the
masters
authorized.
Networks
are
those
things
you're
familiar
with.
C
B
So
on
gke
there
are
some
options
that
you
can
turn
after
the
fact
and
there's
some
that
have
to
be
on
default.
I
don't
have
like
the
exhaustive
list,
but
you
know
you
can
you
can
always
try
right
and
so
there's
some
that
I
think
for
like
pod
security
policies
and
stuff
like
that
right
there
there's
some
knobs.
You
can
turn
in
ng
ke
to
after
the
fact
to
help
secure
your
cluster
I
mean
a
lot
of
these
are
easy
to
turn
easier
to
turn
initially
right,
specifically
like
pod
security
policies,
turn
them
on.
B
After
the
fact,
you
have
to
be
very
careful
because
you
can
make
things
stop
running,
but
the
default
for
G
K,
for
example,
at
least
last
time.
I
checked,
didn't
have
network
policies
on
by
default.
They
were
using
a
different
C
and
I,
didn't
support,
network
policies
and
and
pod
security
policies
are
off,
and
so
you
know
specifically
around
you
know:
gke
masters
on
authorize
networks,
I
think,
that's
generally
a
good
idea.
I
think
the
API
generally
has
a
lot
of
attack
surface
and
so
just
reducing
that
by
by
putting
it
on
a
private
network.
C
That
topic
from
one
of
our
earlier
seminars,
especially
about
some
of
the
managed
services
out
there,
they
don't
support
or
don't
enforce
some
of
the
basic
things,
and
it
can
be
kind
of
difficult
and
surprising
to
find
those
things
out
later
and
the
topic
you
brought
up
about
eks
clusters
and
and
network
policy
is
not
being
enforced
by
default.
Is
it's
one
of
those?
The
next
question
here
is
about
secrets.
You
know
the
the
asker
here
has
concerns
about
the
security
risk
of
secrets
and
kubernetes.
C
B
I've
seen
a
lot
of
times,
people
will
use
like
the
kms
from
the
cloud
provider
or
like
vault
from
Hoshi.
Corp
is
something
that
I've
seen
quite
a
bit,
and
so
yeah
I've
seen
things
where,
basically,
you
could
use.
I
am
an
e
KS
and
you
know
they
make
it
a
little
difficult
to
attribute.
I
am
two
containers
and
there's
like
coop
to
I
am
and
I
think
there's
one
more.
B
The
its
I
took
my
time,
but
I
can't
remember
it
and
you
can
basically
give
I
am
to
a
container
and
then
you'd
be
able
to
pull
down
secrets
from
like
the
kms
stores.
So
there's
there
some
options
there
I
think
yeah,
I
think
I
think
there's
a
challenge
there
with
secrets
in
our
back
right.
So
you
know,
if
you
screw
up
your
secret,
our
back.
Everyone
can
look
at
it.
So
I
think
you
know.
Kind
of
a
traditional
technology
can
help
sometimes
like
vault,
for
example,.
B
Exactly
so,
there's
benefit
there
right.
You
can
have
kind
of
more
of
an
organizational
posture
around
something
like
vaults,
and
then
you
know
hook
that
into
your
kubernetes
clusters
and
and
there
you
know,
hashey
corp
is
pretty
good
at
hooking
that
and
making
things
like
operational,
so
I
think
you
know
that's
that's
the
way
I
would
lean
if
you're
really
concerned
about
that
great.
C
Rick
the
results
are
in.
We
have
well
kind
of
evenly
split
between
in
the
cloud
and
hybrid,
a
few
Lou
they're
running
on
Prem.
Only
so
obviously
the
kubernetes
story
about
running
everywhere.
You
know
for
providing
a
cloud
agnostic
kind
of
interface.
It
seems
to
be
pretty
well
understood
here.
The
next
question
here
is
about
Ubuntu,
so
to
go
back
to
comments
about
hardening
the
the
clusters
and
using
Ubuntu
for
4-node
images
there.
So
the
question
here
is
that
we're
using
Ubuntu.
So
what
else
should
we
use?
C
B
So
I'll
take
a
step
back.
I
didn't
I
didn't
mean
that
I'm
going
to
buy
it
necessity
is
bad
right.
I
think
you
know,
I
think
it's
just
a
little
bit
more
fully
fledged
right,
then
some
of
these
kind
of
like
very
slimmed
down,
container
specific
operating
systems,
and
so
you
know
there
is
a
boon
to
hardening
guide
and
stuff
like
that
as
well.
So
I
think
you
know
those
those
are
reasonable
to
use
and
they're
and
they're
pretty
mature,
but
yeah
I
mean
I.
Think
there's
there's
options
there.
B
C
C
B
I
think
I
think
a
lot
in
the
community
we've
seen
held
to
be
really
effective,
and
you
know
it
has
has
some
deficiencies
and
personally
I
think
in
secrets
management.
But
if
you're
using
an
external
provider,
then
you
don't
have
to
worry
about
that
too
much
and
so
I
think
helm
has
has
kind
of
picked
up
steam
and
they've
made
some
changes
in
Hubble
three
that
I
think
are
pretty
good.
C
C
B
That's
a
that's
an
interesting
question.
That's
a
challenge!
You
know
I
used
to
fly
Mass,
you
know
it's,
there
really
isn't
a
favorite,
I
think
I
think
that's
just
a
general
challenge
that
we
have
I
think
I
think
there's
definitely
some
opportunity
there
for
some
plugins
to
help
validate.
You
know.
Kuby
animals
and
stuff
like
that
and
the
dry
run
in
coop
cuttle
is
always
as
always
a
welcome
friend.
So.
B
C
A
C
So
the
next
question
here
is
from
Nilesh
who's
actually
submit
quite
a
few
of
them.
So
so
thank
you.
You
know.
The
questions
are
definitely
very
welcome.
He
wanted
to
get
your
take
on
multi-tenancy
in
kubernetes
is
namespace
isolation.
Sufficient
I
can
I
run,
you
know,
can
I
run
different
applications,
maybe
put
different
clients
if
I
have
customers
into
the
same
cluster
with
different
namespaces
or
there's
there
other
isolation
that
we
want
to
have
no.
B
I
think
I
think
that's
a
really
effective
way
of
doing
kind
of
like
multi-tenancy
in
a
single
cluster
is
through
namespaces
and
then
you
know
even
kind
of
tax,
some
more
stuff
on
top
of
that
right,
and
so
you
can
go
into
you
know,
network
policies
which
you
can
scope.
Two
namespaces.
You
could
say
you
know
customer
a
cannot
talk
to
customer
B
under
any
circumstances,
and
you
can
provide
that
gate
right
there
and
in
terms
of
a
network
policy.
You
know
you
can
apply
our
back.
B
So
you
know
users,
you
know,
depending
on
what
your
system
is
doing,
but
also
even
like
solutions,
teams
and
customer
success
teams
can
can
look
at
you
know
their
customers
only
potentially
so
yeah.
That's
a
really
nice
way
to
do
that.
You
can
provide
network
isolation.
Obviously,
containers
provide
pretty
good
process,
isolation
and
so
I
think
namespaces
are
really
a
natural
point.
To
do
that,
you
know
I
will
say
when
you're
talking
about
you
know
doing
monitoring
on
all
of
these
clusters
right.
You
don't
have
to
have
monitoring
within
each
namespace.
B
C
B
So
I
think
I
think
it's
a
little
early
I
think
you
know
you
can
try
and
see
what
they
offer
I'm.
You
know,
depending
on
what
exactly
your
application
is
doing.
There
may
be
some
challenges
there,
but
you
know
they'll
keep
they'll,
keep
moving
forward
and
keep
developing
on
top
of
this,
so
I
think
give
it
a
shot.
Hey,
don't
run
your
production
on
it
to
start
right,
but
you
know
really
really
investigates
them,
because
I
think
you
know
any
sort
of
security
that
can
reduce
your
attack
surface
but
not
sacrifice.
C
Another
question
here
about
pod
security
policy,
specifically
PSP
versus
open
policy
agent
and
about
whether
they
overlap,
which
one
should
we
choose
in
this
case.
The
context
is
that
they,
the
the
asker
here,
has
a
dedicated
infrastructure
team.
It's
looking
at
these
deployments,
so
the
developers
don't
have
access
to
that
so
which
tool
you
think.
Would
they
should
they
look
at
yeah.
B
B
Otherwise
you
won't
be
able
to
deploy
anything
into
your
cluster,
and
you
know
that
there's
like
webhook
latency,
so
they're
a
little
bit
more
difficult
to
operationalize,
in
my
opinion,
make
sure
you're
running
multiple
of
multiple
replicas,
et
cetera,
but
I
find
them
to
be
more
extensible
than
pod
security
policies.
So
you
know
when
we're
talking
about
privileged
pods
you
can.
You
can
solve
both
problems
with
pod
security
policies,
but
I
think
it
missed.
Controllers
are
like
a
little
bit
more
extensible
and
I
think
the
privileged
rule,
for
example
in
OPA
or
another
admission
controller.
C
Okay,
I
think
this
is
back
to
a
little
bit.
We
jump
around
a
little
bit,
but
what
are
your
thoughts
on?
It
comes
to
to
get
ups
when
it
comes
to
kubernetes,
especially
so
you
know,
tools
that
are
preserving
the
state
and
always
maintain
in
the
cluster
state
based
on
you
know,
in
pull
requests
and
and
commits
in
and
get.
B
Yeah
I
think
it's
a
really
awesome
way
to
do
configuration
management
of
your
of
your
infrastructure.
I
think
you
know
it's
hard
to
replace,
get
log
and
looking
at
kind
of
the
changes
that
you've
made
over
time
and
so
I
think
I
think
that's
a
really
great
system.
I
think
you
know
making
sure
you
can
validate
that.
You
know
before
you
push
it
and
you
know
maybe
even
do
like
static
analysis
on
some
of
the
deployments
and
stuff
like
that.
B
Right,
like
the
further
left,
you
go
the
better,
and
so,
if
you
could,
you
know,
say
you
have
an
emission
controller
on
privileged
right
and
you
want
to
make
sure
that
no
one
can
roll
anything
out
through
privilege.
It
would
be
better
if
someone
Smits
a
PR
to
make
something
privileged
to
say:
hey,
you
need
approval,
or
you
know
this.
This
one
would
be
denied
when
you
try
to
deploy
it.
If
you
merge
this,
you
know
at
that
level
where
the
developer
can
be
like.
B
C
Okay,
we
got
a
question
here
about
CNI.
Would
you
recommend
a
particular
one
from
a
security
perspective?
There's
a
lot
of
different
choices
out
there,
especially
with
some
of
the
enterprise
platforms
for
kubernetes,
and
they
have
their
pros
and
cons.
What
do
you
think
about
the
security
perspective
on
CNI
yeah.
B
So
I
think
that's
a
an
important
thing,
but
you
know
there's
a
lot
out
there,
and
so
you
really
need
to
pick
one
that
works
well,
so
I
mean
I,
know:
calico
provides
network
policies,
that's
the
one,
if
you
say
on
jjigae,
if
you
turn
on
network
policy,
that's
what
you
get.
I
know
that
amp,
like
some
of
the
eks
native
ones,
don't
necessarily
support
the
network
policies
and
so
from
that
perspective,
I
think
that
network
quality
the
biggest
part
there
and
basically
having
that
pod
pod
segmentation,
yeah.
C
I
know
that's
part
of
our
some
of
our
eks
secure
cluster
guide
that
we
published.
They
talked
specifically
about
that
issue
because
the
default
network
policies
they
work,
they
appear
to
be
applied,
but
they're
not
actually
enforced
under
the
hood
and
that
can
lead
you
to
a
misleading
state
of
sense
of
where
you
are
in
the
cluster.
So
it's
a
good
point
to
recommend
something
like
calico
to
replace
the
default
so
that
you
get
that
that
enforcement.
B
Yeah
or
on
top
of
that
for
a
second
or
you
can
consider
something
at
a
higher
level
that
will
do
you
know
some
of
that.
So,
for
example,
sto
can
provide
some
higher
level
like
kind
of
firewalling,
between
pods
and
and
services.
So
you
know,
if
that's
not
an
option
like
you
can
still
kind
of
use.
Maybe
there's
other
tools
that
solve
that
problem
as
well.
Yeah.
C
Speaking
of
which,
on
the
next
question,
is
about
multi-tenancy
and
network
security,
are
there
any
tools
that
will
help
you
visualize
this
and
help
you
look
at
network
security,
configuration
and
I?
You
know
we
didn't.
We
didn't
plant
this
question,
but
you
know
stack
rocks
as
a
company
provides
that
kind
of
thing.
We
were
trying
not
to
make
this
a.
You
know
product
pitch
session
here,
but
I'm
with
with
an
engineer.
But
yes,
you
know
something
that
stack
rocks
does
is
part
of
the
security
offering
that
we
have
yeah.
B
So
I
mean
you
know,
there's
kind
of
a
funny
backstory
to
to
that
feature.
I
was
trying
to
add,
you
know
we're
a
security
company
and
we
always
want
to
use
the
best
best
practices
in
our
product
and
when
we
deploy
our
product
and
so
I
was
going
through
and
in
building
Network
policies
for
for
stack
rocks.
You
know
for
our
services
and
it
was
really
tough
man.
It
was
really
it
was
really
a
challenge,
and
so
what
I
wanted
to
do
was
I
was
like
hey
like.
Maybe
we
can
make
this
easier?
B
Maybe
this
is
a
spot,
and
so
you
know
we
built
visualization
for
network
policies
that
show
you
like
which
pods
and
can
talk
to
each
other
and
which
deployments
can
talk
to
each
other.
We,
you
know
started
Mearing
live
traffic
on
that,
so
I
think.
One
of
the
concerns
for
me
was
okay.
Well
I'm,
applying
this
yeah
mol.
Does
it
do
what
I
think
it
does
right?
There's
sort
of
idiot
sing
Chrissy's
there,
where
you
know
you
have
I,
think
it
applies
in
this
namespace.
Does
it
actually
and
then
you
have?
B
Okay
am
I
going
to
stop
live
traffic,
like
am
I
missing
some
network
connection,
do
I,
understand
my
services
well
enough
and
so
having
that
together
on
the
same
graph
and
then
being
able
to
to
say,
okay,
cool
I
can
apply
this
with
some
confidence
now,
but
I'm
not
gonna,
go
break
production
or
go
break
development.
Is
it
something
that
you
know
it's
a
crutch,
I
think
it'd
be
fine,
very
important,
so.
C
You
built
a
tool
that
you
would
want
to
use
for
to
solve
this
kind
of
problem.
That's
pretty
awesome,
I
love
that
so
we're
jumping
around
a
little
bit
here.
Another
question
back
on
secret
management:
what
is
your
take
on
things
like
git,
ops
and
secret
management
like
vault,
is
an
alternative,
but
are
there
any
other
tools?
I
mean
you
know,
does
get
ops
and
secrets
work
together,
or
do
you
always
have
to
find
a
separate
tool
for
that.
B
B
You
know:
how
do
we
integrate
with
that
successfully
and
what
tooling
is
there
I
think
you
know
there
I'm
not
super
familiar
with
some
products
that
might
you
know,
might
integrate
with
that,
but
I
think
that's
a
space
too
that
people
could
really
develop
on
and
expand
on.
Is
you
know,
hey
here's
my
workflow
I
want
to
be
able
to
just
like
reference
a
secret
but
make
sure
it's
stored
security
and
pull
it
down
at
runtime.
I.
Think
that's
a
really
important,
important
aspect
of
of
kind
of
like
that
whole
workflow.
C
B
I
mean
you:
can
you
know
you
can
define
upon
security
policy?
That
kind
of
is
like
blankets,
everything
and
that
you
can't.
You
can't
run
privilege
pods
in
your
infrastructure.
You
know
you
can
have
ones
that
are
more.
Finally,
scoped
that
will
allow
you
know
maybe
specific
things.
So
now,
when
you're
talking
about
monitoring
or
even
some
security
tools
like
you
need,
you
do
need
to
run
those
things
as
privileged
and
there
are
legitimate
reasons
for
running
things
as
privileged
right.
B
C
Okay,
before
we
get
to
the
next
question,
we've
got
on
the
pole
for
the
audience
here
about
use
cases.
You
know
how
you're
using
kubernetes
today
so
we'll
bring
that
up.
You
know
these
are
the
security
concerns
and
you
know
if
you
can
select
up
to
three
here
about.
You
know
what
you
guys
are
seeing
out
there
and
the
in
the
world
and
and
where
your
concerns
are.
If
you're,
if
you're
operationalizing
kubernetes-
and
you
know,
your
security
team
has
brought
concerns
to
your
door-
love
to
know
what
those
are.
C
C
Well,
everything,
so
it's
all
a
concern,
so
the
results
here
are
yeah,
76
percent
vulnerability
management,
obviously
a
classic
topic,
and
not
just
in
containers
and
kubernetes
compliance
configuration
management.
So
just
everything
here,
network
segmentation
seems
to
be
a
little
bit
lower
down,
but
sometimes
I
feel
like
once
the
security
team
figures
out
that
your
clusters
are
all
wide
open
pod
to
pod.
They'll
they'll
start
to
put
some
pressure
on
you
detection
into
the
response.
Oh
great
thanks
everyone!
So
this
question
here
about
upgrading.
So
this
is
a
little
more
operational,
a
little
less
security.
C
B
Everything
should
be
able
to
kind
of
like
gracefully,
shut
down
and
move
over
and
and
not
provide
downtime
overall,
and
so
there
are
nicer
ways
to
do
that
right.
You
can
cordon
the
node
off.
You
can
drain
the
node
first
and
then
you
can,
you
know,
bring
it
down
and
have
it
come
back
up,
I
think
I.
Think
that's!
B
You
know
a
really
important
thing
to
make
sure
you're,
considering
right
that
you
know
kind
of
the
overall
idea
is
that
you
can
run
on
ephemeral
infrastructure
and
if
a
node
goes
down,
it's
not
the
end
of
the
world.
You
know
your
your
dev
opti,
your
develop
steam
infrastructure
team
they're,
not
waking
up
at
night
right.
This
is
it's
just
something
that
happens
and
you
can
recover
from
that
and
handle
that
you
know
upgrading
kubernetes,
there's
always
a
little
bit
more
hairy
right.
B
This
is
like
the
thing
that
runs
everything
so,
in
terms
of
you
know,
versioning
and
wind
upgrade.
You
know
obviously
planted
out
kind
of
thoroughly.
You
know,
as
I
mentioned
before,
they've
committed
to
the
last
three
versions
for
vulnerabilities
and
so
I
think
that
is
really
critical
because
say
some
critical
vulnerability
comes
out
right.
B
You
don't
want
to
be
stuck
doing
infrastructure
upgrades
while
you're
doing
phoner
ability
you
know
doing
every
structure
upgrades
just
to
get
a
vulnerability
fix.
So
you
know
there
was.
There
was
a
period
of
time
where
we
upgraded
from
Exedy
to
two
XE
g3
right.
That
would
became
the
new
data
layer
and
you
know
I
would
not
want
to
be
in
a
position
where
I'm
trying
to
roll
that
out
really
quickly.
B
You
know
it's
literally
the
backing
storage
just
because
I'm
trying
to
fix
the
vulnerability,
and
so
you
know
really
plan
those
out,
but
you
know
make
sure
you're
staying
within
that
window
and
so
I'm,
never
a
huge
fan
of
always
rolling
out
to
like
the
bleeding
edge.
Like
you
know,
hopefully
everything
will
be
fine.
B
You
know
you
can
take
a
little
bit
of
time.
Let
it
bake
a
little
bit.
You
know.
Hopefully
you
have
kind
of
staged
approaches
where
you
have.
You
know
dev
staging
prod.
You
know
prana
always
goes
last.
You
know
you
could
roll
it
out
to
staging
make
sure
you
have
a
representative
work
load
on
it
and
see
what
the
impact
is.
So
I
think
you
know
making
sure
you're
just
kind
of
using
like
operational
rigor
going
through
it
and
making
sure
that
you're
validating
all
of
these
changes.
You
know
take
your
time.
C
Certainly
seems
like
in
cloud
environments
that
the
clusters
themselves
can
be
treated
more.
It's
like
a
disposable
resource
to
so
that
you
know
when
you're
rolling
out
a
new
version
of
your
product,
maybe
make
sense
to
just
move
on
to
a
new
version
of
kubernetes
and
plan
on
that,
rather
than
try
to
preserve
an
upgrade
in
existing
clusters
that
make
sense
yeah.
B
I
mean
so
you
know,
depending
on
you
know
what
level
of
every
structure
you
have
I
mean.
Also,
you
know,
for
example,
on
GK
you
can
you
can
upgrade
your
masters
pretty
seamlessly.
You
know,
make
sure
you're
running
the
multiple
master
mode
for
the
replicated
masters,
which
you
know
is
not
always
on
by
default
and
so
make
sure
you're
checking
that
box
you're
not
taking
any
like
API
downtime
when
that's
happening,
but
you
know
they
have
pretty
seamless
upgrade
processes
as
well,
which
is
pretty
convenient.
C
Well
so
next
question
here
was
moving
up
the
stack
a
little
bit.
We
were
talking
about
networking
before
and
this
is
back
on
the
same
topic,
but
now
asking
about
like,
like
application
layer
like
it
is
enabled
by
the
surface
mesh
architectures
you
know,
is
there?
Is
there
a
security
use
case
there?
You
know
we
see
things
like
sto
being
used
for
you
know
offloading
TLS
and
you
know
for
doing
like
canary
testing.
Is
there
a
security
story
there
as
well?
What
do
you
think?
Yes.
B
No,
my
general
opinion
on
sto
is
that
it's
been
tough
to
adopt
a
little
bit
because
sometimes
things
weren't
like
made
for
it
perfectly
kubernetes,
has,
is
making
some
changes,
which
I
think
will
will
let
the
operational
side
of
yes
do
become
a
lot
easier.
So
you
know
crooners
is
adding
sidecar
to
the
spec,
so
you
can
literally
manage
the
lifecycle,
the
sidecar,
completely
separately
from
the
lifecycle
of
the
pod.
B
So
a
common
sto
issue
is
that
you
know
you
have
to
make
sure
the
rules
get
synched
before
your
pas
tries
to
make
outward
Network
calls,
and
so
there's
kind
of
like
some
manual
hacks
that
people
were
doing
and
now
you
know
the
lifecycle
is
immediately
baked
in
and
then
once
you
know
once
that
we
can
operationalize
that
you
know
making
it
on
a
security
perspective
right.
You
provide
better
firewalling,
better
application
to
application
communication.
B
You
know
you
can
whitelist
external
IDs
like
there's,
there's,
definitely
some
more
functionality.
There
I
mean
I
love
the
the
easy
MT
LS
between
services.
I
think.
That's
always
a
challenge
when
you're
doing
kind
of
like
certificate
management
and
so
I'm
also
kind
of
excited
to
see
what
visibility
comes
out
of
that
right.
C
B
Yeah,
so
I
haven't
had
too
much
experience
honestly
with
the
federated
clusters.
I.
Imagine
a
lot
of
kind
of
like
the
similar
security
II
know,
rules
apply
but
in
this
case
I
think
you're
kind
of
like
going
out
potentially
over
the
internet
between
federated
clusters,
and
so
you
always
want
to
be
like
a
little
bit
more
cautious
there.
But
you
know
I,
don't
have
any
distinct
kind
of
rules.
There
I'm
not
sure
exactly
how
this
gets
set
up
in
infrastructure
and
what
does
look
like
so
definitely
something
to
watch
out
for
I.
B
C
I
haven't
seen
anybody
using
it.
We
do
get
some
questions
about
it.
We
get
some
people
experimenting
with
it.
I
think
it
has
a
ways
to
go
and,
as
you
mentioned,
some
of
the
challenges
run
operationalizing
is
do
mean
that
if
you're
doing
Federation
through
something
like
this,
do
you
have
now,
you
know
bleeding
edge
feature
on
top
of
a
beat
of
bleeding
edge
platform.
It
makes
you
know
it's
not
clear
that
it's
ready.
Yet,
to
be
honest,
most
of
my
customers
are
relying
on
traditional
cloud-based.
C
You
know
cloud
provider
based
security
controls
like
security
groups,
to
isolate
the
clusters
from
each
other,
as
they
would
any
other
application
architecture.
And
that's
you
know
at
this
point,
pretty
pretty
tried-and-true
right,
pretty
well
tested.
Here's
a
great
question
I
was
I
was
hoping.
Somebody
would
ask
this
one.
This
is
in
your
opinion.
Is
it
better
to
use
a
managed,
kubernetes
service
versus
deploying
your
own
clusters?
You
know,
there's
pros
and
cons,
I
know
from
a
security
perspective,
there's
pros
and
cons.
What
do
you?
What
do
you
think
about
that?
C
B
I
mean
III
I
leaned
towards
the
managed
services,
I
think
from
operational
perspective,
they're
much
easier,
but
also
from
you
know,
kind
of
an
ephemeral
side.
Right,
like
you
know,
say,
there's
a
feature
you
want
to
roll
out.
You
don't
have
to
kind
of
try
to
convert
this
traditional
on-premise
Terr.
B
You
have,
you
can
kind
of
you
know,
as
you
said
earlier,
Chris
just
tear
one
down
bring
one
back
up
right,
and
so,
if
there's
options
that
you
that
are
harder
to
turn
on
after
the
fact
you
know
it's
a
lot
easier
for
me
to
to
use
terraform
or
use.
You
know
the
other
tooling,
for
cloud
providers
to
just
bring
up
a
cluster.
B
C
I
think
we,
the
engineers
here
we
can't
really
address
the
cost
part
of
it,
but
that's
another
aspect
that
some
organizations
have
that
it's
it's
sometimes
more
expensive
to
run,
though
so
we're
usually
more
expensive
to
run
those
services.
So
you
have
to
look
at
the
pros
and
cons
of
what
you're
getting
and
when
it
comes
to
security,
especially
we,
you
know
we
talk
about
the
separation
of
duties
and
the
comm
providers
do
take
on
some
of
that.
But
it's
important
to
understand.
C
C
So
there's
question
about
I:
guess
about
architectures.
You
know
for
any
kind
of
supporting
services
like
continuous
integration
like
monitoring
and
logging.
Do
you
recommend
keeping
that
in
the
application
cluster,
or
do
you
dedicate
a
separate
cluster
for
that
sort
of
you
know
supporting
services.
B
So,
if
you're
doing
like
Network
policies
or
hardback
I,
think
that
that's
beneficial,
you
know
if
you're
using
a
cloud
provider,
there
are
tools
like
you
know,
logging
will
immediately
go
to
you,
know
Google's
logging
or
or
AWS
logging
right,
and
so
you
know
if
you
can
use
that,
that's
even
better
right,
because
that's
you
know
in
in
the
control
plane
itself,
as
opposed
to
being
managed
by
yourself.
But
you
know
for
something
like
say:
you're
running,
prometheus
right,
I
think
prometheus
should
run
in
the
same
cluster
as
the
services
that
you're
you're
scraping.
B
C
Okay,
there's
some
other
questions
here,
we're
going
through
the
backlog
here,
there's
some
more
stuff
about
namespaces.
Is
it
really
possible
to
use
a
namespace
as
a
hard
security,
boundary?
I?
Guess
that's
similar
to
the
question
it
got
ins
answered
earlier,
but
is
it
really
a
hard
security
boundary?
Anything
kubernetes
intends
it
that
way.
B
I
think
I
think
it's
like
a
way
to
logically
segment.
Your
clusters,
you
know
I,
don't
know
if
it's
necessarily
a
hard
security
boundary
in
the
sense
that,
like
yeah,
you
know
a
process
for
customer
I
could
still
run
on
the
node,
but
the
process
of
customer
be
right.
I
mean
you
know
you
can
segment
your
you're
a
single
cluster
into
you,
know
node,
selectors
and
stuff,
like
that.
B
I
think
I
think
that
moves
away
a
little
bit
from
the
benefits
of
using
something
like
kubernetes,
where
you
can
kind
of
like
pack,
things
in
and
the
containers
provide
the
isolation.
But
you
know
I
do
think
you
can
use
namespaces
as
like
a
network,
a
network
boundary,
for
example,
with
network
policies
right
so.
C
B
So
I
was
actually
looking
at
this
today.
So,
for
example,
the
audit
logs
there's
a
it's
an
alpha,
but
there's
a
dynamic
audit
log
sync
where
you
can
hook
up
like
a
service
that
will
basically
pull
from
the
API
server
and
the
API
server
will
send
the
auto
eyes
out.
It's
a
little
bit
hard
to
get
to
you
right
now.
B
So,
if
you're
running
like
your
own
on
Prem
communities,
this
is
definitely
an
option
for
you
is
using
like
this
dynamic
sync,
you
have
to
make
sure
you
turn
the
flag
on
so
that
it
works
it's
an
alpha.
So
you
know
take
that
with
a
grain
of
salt,
honestly,
but
I
think
usually
careers
officer
are
pretty
decent,
but
in
manage
cloud
providers.
B
You
know
it's
a
little
bit
harder
to
get
to
that
data,
and
sometimes
you
might
have
to
pull
it
from
something
like
stackdriver
or
like
cloud
watch,
as
opposed
to
just
you
know,
being
able
to
connect
with
the
sync.
So
yes,
and
no
I
mean
if
you
can
utilize
the
cloud
provider
logging.
You
know
utilize
that,
but
if
you're
running
on
Prem
yeah
there's
an
option
there,
where
you
can,
you
know
take
all
that
a
lot
of
log
data
and
ship
it
off
right.
C
The
last
question
here
about
our
back
can't
make
kind
of
a
loaded
question.
I
guess:
is
there
any
web
interfaces
to
managing
and
visibility
in
our
back
and
again,
this
is
where
stack
rocks
provides
some
controls
and
some
visibility
into
kubernetes
clusters,
because
again
we
identified
that
need
that
you
know
there's
a
there's
a
there's.
Some
definitely
some
some
tools
out
there
for
that.
C
B
So
I
think
it
depends
on,
like
you
know
where
your
nodes
are
exposed
right.
So
you
know
I
know,
for
example,
that
a
lot
of
the
load,
balancers
and
public
clouds
will
will
become
node
ports
based
on
you
know.
If
you
use
the
load,
balancer
type
or
kind
in
in
kubernetes,
you
know
make
sure,
though
those
are
not
exposed
externally,
which
I
think
you
know
cloud
providers
do
a
pretty
good
job
at
so
you
know
it
kind
of
depends
on
how
your
nodes
are
exposed.
B
What
network
they're
on
I
mean
there's
like
kind
of
like
a
lot
of
extenuating
circumstances
there
and
so
I,
don't
think
they're,
necessarily
bad
and
I'll
have
like
a
hard
stance
against
them.
I
think
it's
a
way
that
you
can.
You
know,
expose
expose
your
services,
but
you
know
always
always
be
careful
and
verify
you
know
who
can
access
them
in
from
where
right.
C
We
are
getting
short
on
time,
but
we
got
a
couple
more
questions
here,
this
one's
pretty
broad
topic,
so
you
know,
maybe
maybe
we
could
start
looking
at
some
of
the
topics
here,
but
it's
tips
week
that
you
have
on
PCI
segmentation,
so
I'm,
assuming
this
means
payment
card
industry,
recommendations
around
isolation
of
data,
anything
particular
about
that
standard-
that
you're
you'd
recommend
here.
I.
B
Honestly,
have
nothing
like
very
specific:
around
PCI
compliance,
I
think
you
know,
those
standards
are
pretty
pretty
difficult
and
you
know
for
a
good
reason,
but
yeah
I
think
you
should
look
and
see
which
you
know.
Here's
a
kind
of
a
generic
answer.
I
think
you
should
look
and
see
which
tools
that
you
could
use
in
which
knobs
you
can
turn
within
kubernetes.
First
I
think
there
are
quite
a
few
where
you
can.
B
You
can
utilize
that
and
and
and
provide
some
of
that
segment
or
even
looking
at
deployments
and
workloads
and
and
saying
that
your
workloads
are
compliant
to
PCI
I.
Think
that's,
like
a
nice
view
right,
so
you
know
the
way
I
like
to
describe
communities
a
lot.
Is
that,
like
the
pod
is
the
base
unit,
but
everything
else
is
all
about
how
you
want
to
run
a
pod,
and
so,
if
you
can
look
at
a
deployment
and
say
like
yeah,
this
deployment
is
compliant
with
PCI.
B
Then
you
can
also
say
that,
like
your
pods
are
also
complying
with
PCI
and
so
like.
Sometimes
you
can
have
less
work
if
you're
kind
of
looking
at
the
top-level
view
inside
kubernetes,
and
so
you
know
you
know
one
change
can
propagate
throughout.
So
you
can
make
a
demon
you
can
make
all
pods
in
a
demon
set
compliant.
If
you
just
change
the
demon
set
so
right.
C
So
I
mean
the
one.
The
point
that
you
made
there
I
think
is
really
important.
That
PCI
has
a
lot
of
different
aspects
to
the
security
recommendations.
It
requires
the
controls
that
it
requires
that
you
demonstrate,
but
wherever
possible,
you
should
use
what's
there
in
kubernetes
for
that,
because
things
like
examining
vulnerabilities
and
isolating
data
can
be
done
with
tools
that
are
that
are
native
to
the
ecosystem.
Right,
it's
not
like
you,
don't
necessarily
adopt
something.
That's
gonna
be
separate
from
kubernetes
itself
right,
yeah,.
B
I
think
and
I
think
a
really
cool
thing
about
careers
in
general
is
that
you
could
you
can
kind
of
get
a
whole
snapshot
of
your
entire
infrastructure.
Look
at
all
the
workloads
that
are
running
there.
You
know
verify
those
are
compliant
and
then,
as
you're
kind
of
moving
forward
right.
You
can
use
things
like
in
the
mission,
controller
or
pod
security
policies
to
ensure
that
you're
still
meeting
that
compliance
as
you're
moving
forward.
So
you
know
once
you
get
you
once
you
have
a
solid
foundation
of
you
know
your
applications
are
compliant.
B
You
know,
based
on
configuration,
you
know
you
know
image
vulnerabilities
come
in
over
time.
So
that's
a
little
bit
of
a
challenge,
but
you
can
enforce
that.
You
know
this
needs
to
be
maintained,
and
so,
when
you
do
come
up
to
an
audit,
you
have
a
high
confidence
that
yeah.
Maybe
you
have
a
couple
of
problems
to
fix,
but
you're
not
kind
of
fixing
a
whole
months
or
a
couple
months
worth
of
problems
that
have
accrued
right,
yeah.
C
So
it's
a
continuous
process
to
dig
in
which
a
slightly
different
question
here
about
integrity,
monitoring
like
what
kind
of
changes
we
should
be
look
for
in
a
cluster
like
what
could
from
a
security
perspective.
Should
we
be
looking
at
that?
You
know
you
know
it's
the
change
but
but
could
indicate
an
attacker
has
gotten
hold
of.
Let's
say
like
an
API
endpoint.
B
Yeah,
that's
a
that's
kind
of
a
tough
plan.
I
mean
I,
think
you're
really
getting
getting
into
the
kind
of
the
detection
piece
there
right,
and
so
you
know,
if
you
can
baseline,
hey
here's
what
these
users
are
using
from
an
are
back
perspective
and
then
suddenly
you
start
seeing
deviations
from
that
right.
Then
that
is
like
a
pretty
good
indication
of
something
going
wrong.
You
know,
if
you
look
at
a
workload
you
can
look
at
hey.
Has
this
never
ran
this
process
before
and
suddenly
this
process
is
running?
B
C
C
We
have
a
question
about
protecting
admission
controllers
or
other
web
hooks,
so
you
know
making
sure
that
someone
who
has
appropriate
access
you
know
or
inappropriate
access
could
do
something
to
like
steal
data
using
a
sinister
web
hook.
You
know,
or
something
like
that,
is
there
any
guidance
on
on
protecting
those
in
the
cluster
yeah.
B
I
mean
audit
are
back
early
and
often
right,
and
so
you
know
this
is
one
of
the
things
that
can
take
down
your
clusters
in
the
mission
controller
right,
and
so
this
is
definitely
something
that
you
want
to
make
sure
that
you've,
like
really
locked
down
right
default
users,
don't
have
it.
You
know
one
thing
with
our
back
that
I've
we've
seen
over
and
over
again
is
okay
cool.
You
know
our
company
is
trying
out
kubernetes
we're
working
on
it.
You
know
a
lot
of
you
guys
are
learning
about
it.
B
You
know,
maybe
our
backs,
not
the
top
of
mine.
Maybe
you
know
you
give
yourself
cluster
admin
because
you
don't
want
to
get
rejected.
You
know
you're
trying
to
you
work
through
in
stage
clusters
and
then,
as
these
clusters
kind
of
become
production
clusters
that
cluster
admin
access
was
never
revoked
or
never
changed
or
never
moved
to
the
new
policy.
B
And
so
you
know
it's
just
kind
of
drift
over
time
as
something
becomes
more
mature
and
you
know
suddenly,
this
cluster
is
now
running,
prod
workloads,
and
so
you
know
make
sure
you
go
back
and
audit
and
say:
okay,
who
has
cluster
admin?
You
know
who
can
access
these
and
mission
controllers
and
really
scope
that
down
to
some
defined
service
accounts
or
to
find
users.
B
B
You
know,
I
really,
love
the
communities
community
and
and
how
everyone
kind
of
like
comes
together
and,
and
you
know,
support
each
other
and
so
yeah
I
want
to
make
sure
that
everyone
has.
You
know
the
right
support
and
if
they
have
security
questions
that
we're
building
kubernetes
clusters
that
are
secure,
I.
Think
that's!
You
know,
you
know
something.
I
can
contribute
to
if.
C
A
Thank
you
so
much
for
the
great
interaction
everybody,
wonderful
questions
that
you
sent
in
and,
as
Connor
said,
we're
always
here
to
help
our
blog
is
full
of
really
great
technical
depth
information,
a
lot
of
security,
best
practices
in
there
other
content
from
Connor
other
content
from
some
of
our
other
engineers
and
DevOps
engineers.
So
go
ahead
and
check
that
out,
Connor
and
Chris
many
many
things
Thank.