►
From YouTube: Webinar: Kubernetes Security Controls and Enforcement: Applying Lessons from the K8s Security Audit
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
The recent Kubernetes security audit and the issues it identified got lots of publicity. But did you know that the audit reports also include many recommendations you can apply today to improve your security posture?
On this webinar, we’ll discuss:
- key takeaways from the security audit including actionable recommendations
- the breadth of native security controls that Kubernetes provides
- how to get started applying and enforcing these controls to reduce the likelihood and impact of attacks
- how you can design a Kubernetes-native security strategy to protect cloud
-native applications without impeding continuous development
Join our discussion, complete with hands-on examples and practical tips, to improve security for your Kubernetes environments today.
A
And
all
right,
I
think
we
are
all
set
here.
Hi.
Everyone
thanks
for
joining
us
today,
welcome
to
today's
CN
CF
webinar
kubernetes
security
controls
and
enforcement,
applying
lessons
from
the
kubernetes
security
audits,
I'm,
Chris,
shorter
principal
technical
marketing
manager
at
Red,
Hat
on
the
OpenShift
team
I'm.
Also,
a
cloud
native
ambassador
I'll
be
moderating
today's
webinar,
a
few
ice-cubes
unites
us
before
we
begin
during
the
webinar
you're
not
able
to
talk
sorry,
but
there
is
a
Q&A
box
at
the
bottom
of
the
screen.
Please
please,
please
use
that
drop
in
questions.
A
There
is
no
such
thing
as
a
stupid
question.
There's
no
such
thing
as
a
stupid
person.
This
is
all
hard
stuff
ask
away,
also
keep
in
mind.
This
is
an
official
CN
CF
webinar.
As
such,
the
CF
code
of
conduct
is
in
place.
Please
do
not
add
anything
to
the
chat
for
questions
that
would
be
in
violation
of
the
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters
and
with
that
I
would
like
to
welcome
Connor
Gilbert
Senior
Product
Manager
at
stack
Rox.
Take
it
away,
Connor.
B
Hey
there
welcome
as
Chris
mentioned.
This
talk
is
about
community
security
controls
and
enforcement,
and
especially
about
how
you
can
apply
lessons
from
the
community
security
audit
now
who's,
this
well
I'm
Connor
I
am
a
senior
product
manager
at
Stack,
rocks
and
I
used
to
be
engineer,
so
don't
hold
the
product
title
against
me.
B
I
happen
to
stumble
into
kubernetes
in
2015
back
when
it
was
a
little
bit
different
from
how
it
is
now
introduced
it
at
one
company,
while
I
still
worked
there
as
an
engineer
and
then
moved
on
to
start
building
container
crudité
security
products
after
that,
because
I
saw
just
how
good
this
could
be
for
security,
the
job
that
I
was
doing
now.
What
do
we
cover
today?
Well,
we'll
start
with
just
sort
of
what
happened
in
the
security
audit
a
little
bit
about
the
process,
some
takeaways,
some
key
takeaways
and
selected
results.
B
Then
we'll
cover
some
of
the
advice
from
the
audit,
including
some
native
gates,
controls
that
you
can
leverage
for
better
security.
I
will
talk
about
how
security
responsibility
is
shared
across
the
stack.
What's
new
and
containers
and
curved
edges
and
what's
not
and
default,
configs
versus
the
ideals
and
finally,
once
we've
covered
the
controls,
we'll
talk
about
how
to
design
a
career,
IDs
native
security
strategy
so
that
you
can
enforce
security
controls
and
practices
without
sacrificing
the
velocity
that
you've
come
to
enjoy
with
kubernetes
open
shifts
and
related
technologies.
B
So,
let's
get
started
after
each
of
these
sections,
we'll
stop
for
questions.
So
if
you
do
have
a
chance
to
put
something
in
the
dqa
we'll
try
to
handle
some
of
those
as
we
go.
So,
let's
get
started
what
happened
in
this
security
audit?
It
made
a
lot
of
headlines.
There
was
a
lot
of
news
coverage
about
it,
but
what
actually
happened
here?
Well,
maybe
it's
best
to
start
with
what
came
out
of
the
audit.
So
there
were
four
main
documents
and,
let's
cover
those
in
succession.
B
First
is
the
security
report,
and
this
is
the
part
that
most
people
have
maybe
read
or
read
a
story
about,
and
this
is
the
one
that
focuses
on
community's
product
security
itself,
so
security
bugs
inside
of
kubernetes
problems
in
the
codebase,
the
documentation.
Things
like
that.
This
is
where
some
of
the
headlines
about
kubernetes
is
vulnerabilities
came
from,
but
there
were
three
other
documents
and
I
think
they're
all
quite
interesting,
and
they
have
some
unique
value
that
we'll
explore
throughout
this
session.
B
B
Maybe
red
blue
team
kind
of
vibe.
So
for
big
documents,
a
total
of
241
pages
and
I
expect
you
all
to
have
read
them
before
you
start
it
no
just
kidding.
So
obviously
not
everyone
in
the
world
has
has
read
all
of
these,
although
they
are
very
rich
and
I'd.
Recommend
that
you
know
if
you
want
to
spend
some
time
seeing.
B
Test
result
looks
like
do
take
the
time,
so
how
did
we
get
these
documents?
Well,
logistically
there
was
a
security
audit
working
group.
They
solicited
some
proposals
from
the
community.
A
number
of
vendors
were
invited
to
bid,
and
eventually
the
group
selected,
a
winning
bid,
a
team
of
trail
with
bits
and
at
Redis
partners,
and
then
the
main
part
of
the
assessment
was
March
through
May
career
days
113
and
the
results
came
out
in
August.
B
B
This
you've
seen
the
the
processes
and
everything
getting
worked
out
through
some
of
the
recent
vulnerability
disclosures,
but
really
this
is
another
way
of
investing
in
park
security,
because
the
community
realizes
how
important
communities
is
to
the
cognitive
stack.
Second,
security
audit
did
identify
a
number
of
security
issues
in
specific
communities,
components
and
those
are
things.
This
is
probably
what
you
might
have
heard.
If
you
read
any
of
the
press
about
this
those
severity
z',
they
range
from
informational
things
up
to
high
severity.
B
There
are
improvements
recommended
in
various
areas
of
the
products
which
will
cover
their
github
issues
for
each
of
those,
and
some
of
them
have
already
been
fixed.
In
fact,
some
of
them
were
fixed
by
the
time.
People
even
read
the
report.
Now
configuring
kubernetes
can
be
complex
as
well.
So
that's
the
third
takeaway
and
that's
sort
of
the
under
covered
part
of
this
audit
report
to
be
secure.
You
do
need
to
take
a
lot
of
steps
to
protect
your
infrastructure
and
applications,
but
they're
not
as
mysterious
as
we
sometimes
might
think.
So.
B
The
code
base
is
large
and
complex,
with
large
sections
of
code
containing
minimal
documentation
and
numerous
dependencies,
including
systems
external
to
kubernetes.
Now
this
this
I
think
it's
important
to
recognize
that
this
is
a
sort
of
measured
look
at
sort
of
honest.
Look
at
the
state
of
the
project
and
that
this
isn't
an
adversarial
thing
right.
This
is
something
that's
part
of
the
community
process,
and
but
it
does
highlight
some
of
the
topics
that
we'll
go
through
now.
B
Let's
go
through
some
of
the
themes
of
the
issues,
so
one
of
them
is
parsing
problems,
so
certain
handlers
do
have
to
take
user
input.
Otherwise,
kubernetes
is
just
sort
of
sitting
by
itself
doing
nothing,
but
some
of
those
handlers
could
overflow
or
run
out
of
memory.
There
are
three
findings,
though
TOB
gates
numbers
are
things
that
you
can
search
for
in
the
audit
report.
To
get
those
details,
you
can
also
find
them
on
github
because
they
shoes
your
tech.
B
That
way-
and
this
is
also
an
area-
that's
seen-
more
security
coverage
lately
with
a
billion
laughs,
attack
our
vulnerability
where
you
could
have
a
specially
crafted
yeah
mole
that
would
exhaust
memory
on
the
API
server
other
kind
of
changes
documentation.
So
there
were
some
recommended,
and
it's
about
maybe
a
you
know
for
encryption
settings.
B
So
there
are
some
in
secret
deprecated
features,
so
things
that
you
know
came
on
early
in
kubernetes
lifetime,
but
still
exist,
so
the
recommendations
to
sort
of
turn
them
down
or
deprecated
them
further
or
just
finally
remove
them
as
well
as
some
problems
with
how
they
were
working.
Some
non-constant
I
and
password
comparison
passwords
being
stored
in
clear
text
that
kind
of
thing
important
to
know
that
those
features
weren't
things
that
you
were
likely
using,
but
they
did
exist
and
the
audit
did
find
them.
There's
some
information
leaks,
some
some
verbose
logs.
B
If
you
bumped
up
the
log
verbosity
to
I,
think
seven
out
of
ten,
maybe
you
could
get
some
secrets
and
logs
in
specific
subsystems.
Those
are
fixed
kind
of
right
away.
There
was
a
bug
in
core
DNS,
allowing
a
zone
transfer
so
sort
of
leak
out
your
service
information,
some
sensitive
and
virus
used
on
the
host
and
then
some
dangerous
designs
where
features
are
really
working
like
they're
supposed
to,
but
the
audit
realized
they
could
be
abused
and
you
know
maybe
people
knew
this
before
but
important
to
note.
B
So
some
long-standing
ones
like
set
comp,
which
there's
been
some
movement
on
recently
and
also
some
TLS
certificate,
revocation
issues
and
it's
important
to
know
that
a
lot
of
this
stuff
or
some
of
it
had
come
up
before
some
of
it
hadn't
and
that's
sort
of
gone
through
the
normal
process
with
the
community,
and
you
can
see
all
of
that
actually
and
github.
So
that's
it
for
the
section
on
the
audit
findings
Chris
and
if
there
any
humidity
questions
about
this
section
or
we
can
move
on
to
the
native
crew.
Based
controls,
keep.
B
All
right,
let's
gone
so
this
is
the
part
beyond
sort
of
the
facts
of
the
report.
Some
real
interesting
analysis
about
how
you,
as
an
operator
as
a
developer
as
a
cluster
administrator,
how
you
can
use
communities
to
be
more
secure,
well
cover
more
about
the
overall
context,
but
first
we'll
sort
of
dive
into
security
responsibilities
and
specific
controls
before
we
talk
about
how
you
can
enforce
them
and
sort
of
get
an
overall,
better
security
posture.
B
So
you
know
it's:
it's
almost
cliche
and
the
security
talks
to
talk
about
shared
responsibility,
but
I
do
think
it's
important
to
note
this,
and
the
audit
does
go
out
of
its
way
to
highlight
that
there
are
different
responsibilities
involved
in
securing
kubernetes
cluster
that
ranges
from
the
application
developers,
the
folks
doing
application
level
operations
making
sure
the
apps
are
up.
It
also
includes
the
infrastructure,
so
the
nodes,
if
you're
using
a
you,
know
the
standard
kind
of
node
based
communities,
cluster
managed
service.
B
If
you're,
if
you're,
you
know
sort
of
asking
someone
else
to
manage
the
control
plan
for
you
and
then
sort
of
the
security
functions,
your
risk
security
compliance
things
as
a
business
or
as
a
large
organization.
You
know
those
are
real
stakeholders
and
and
teams
that
that
will
have
to
be
involved
to
get
your
overall
posture
right.
So
that's
kind
of
the
organizational
structure
maybe,
but
we
can
also
swap
to
kind
of
the
security
surface.
B
So
if
those
were
the
people
and
the
teams
that
are
involved
in
security,
we
can
swap
over
and
look
at
sort
of
the
security
surface
that
you
need
to
pay
attention
to.
So
on
the
Left
again,
we've
got
the
sort
of
the
application
and
that
usually
again
starts
with
application
security.
If
you
have
an
insecure
application
and
you
put
it
in
a
container,
it
is
an
intake,
your
application.
The
container
does
not
solve
that
problem.
B
If
you
have
a
vulnerability
in
your
code
or
if
have
a
vulnerability
in
the
library
like
struts
or
something
the
container
doesn't
help
you,
but
once
we
get
sort
of
past
that
there
are
some
interesting
patterns
and
things
that
we
can
do,
especially
because
we're
using
kubernetes-
and
that
includes
the
deployment
configs,
so
kubernetes,
as
you
know,
will
have
you
know,
declarative
specifications
of
how
your
application
can
operate
and
we'll
cover
some
of
those
in
more
detail.
But
they
do
let
you
lock
down
your
application.
B
You
know
everyone
who's
involved.
This
isn't
just
a
developer
problem.
This
isn't
just
an
ops
problem.
This
isn't
something
you
can
make
someone
else
do
the
only
way
to
do
this
right
is
to
have
everybody
use,
curry
ideas
as
a
common
language
where
you
can
meet
and
understand
sort
of
what's
going
on
use
the
configs
to
your
benefit
for
better
security.
So
with
that
in
mind,
let's
cover
sort
of
what's
different
in
kerbin
at
ease,
and
what's
the
same?
So
let's
talk
about
threats
so
apps,
so
on
the
internet,
nobody
knows
you're
a
duck.
B
Sorry,
nobody
knows
you're
running
in
a
container
and
that's
something
that
we've
found
in
some
some
research
that
we've
done
here
at
stack
rocks,
but
it
also
kind
of
makes
sense.
A
container
is
the
Linux
process
from
the
outside.
You
might
be
hard-pressed
to
figure
out
that
it
is
a
container
and
if
you're
poking
around
inside
well,
you've
already
gotten
in
so
from
the
outside.
The
threat
posture
is
actually
going
to
be
fairly
similar
and
the
infrastructure
side.
B
Let's
talk
about
security
workflows
around
those
same
two
apps
and
in
structured
buckets
so
for
apps.
Well,
the
cool
thing,
though,
is
while
on
the
outside
nobody,
you
might
know
you're
in
a
container.
You
do
because
every
app
we
deployed
has
an
immutable
Shots
56
of
it.
So
you
know
exactly
what
it
is
and
if
you've
ever
tried
to
do
inventory.
B
Typically
you're
not
messing
manually
with
your
apps
as
much.
If
you
are,
it
suggests
you
kind
of
wean
yourself
from
that
practice.
So
there's
much
less
of
this,
like
oh
I'll,
just
ssh
in
the
vm
is
probably
messed
up.
You
know,
and
then
apps
are
ideally
built
to
be
failure,
tolerant
and
sort
of
this
micro
services
cloud
oriented
called
native
design,
which
means
you
can
take
different
actions
when
you
have
a
security
problem.
B
Let's
talk
about
infrastructure,
so
I
had
mentioned
a
new
powerful
API
service
to
protect,
but
you
also
that
API
is
a
central
place
where
you
can
configure
a
lot
of
the
important
security
can
fix
that
you
need.
I
kind
of
call
this
software
to
find
everything,
and
then
I
looked
it
up
and
it
found
out
that
analysts
have
been
using
that
term.
B
You
know:
you're,
not
you're,
not
beholden,
to
exactly
how
your
physical
topology
is
set
up
for
anything
and
the
infrastructure
again.
So
it's
a
critical
foundation.
You
know
it's
really
important
to
keep
the
infrastructure
secure,
but
it's
a
little
bit
more
strictly
separated
from
the
apps,
because
your
apps
are
built
to
be
deployed
using
the
ammo
files
and
and
to
really
kind
of
not
care
where
they
are.
They
shouldn't
be
using
host
mounts
in
general.
B
That
kind
of
thing,
so
your
infrastructure
is
a
bit
more
cookie
cutter,
a
bit
more
strictly
separated
and
that
can
be
a
benefit
for
security
as
well.
So
let's
talk
about
that
API
and
infrastructure
security
segment
of
your
security
posture,
so
here's
a
an
excerpt
from
the
security
white
paper
from
Terrell
Abbott's,
so
we
were
started
with
the
security
report,
which
is
mainly
about
the
communities
project
itself.
We've
moved
on
to
the
security
white
paper
now
because
we're
talking
about
sort
of
security
practices,
so
this
this
is
saying.
B
Welcome
rid
of
these
facilitates
high
availability
work.
The
deployments
all
that
stuff
that
you
love,
the
underlying
hosts
components
and
environment
of
a
commodities
cluster
must
be
configured
and
managed,
and
this
management
has
a
direct
impact
on
that
capabilities
of
the
cluster
and
affects
the
behavior
of
an
operator
is
composed
objects.
So
some
dense
stuff
there,
but
the
examples
they
go
on
to
discuss
are
that
your
cluster
has
to
be
deployed
in
a
way
that
say,
network
policies
will
work.
You
need
to
have
an
underlying
network
provider
that
will
support
those
policies.
B
B
So
in
terms
of
sort
of
basic
API
and
infrastructure
security,
one
of
the
most
important
things
or
that
may
be
the
easiest
to
add-
is
just
controlling
network
access.
The
API
server
so
I
mentioned
earlier.
The
billion
laughs
attack
I
can
never
remember
cvd
numbers
exactly,
but
it's
the
one
that
you've
heard
about
recently
and
this
affected
more
or
less
all
communities,
API
servers,
many
of
which
are
exposed
to
the
Internet.
So
one
of
the
sort
of
easy
ways
to
secure
is
to
consider
that
network
access
a
little
more
carefully.
B
Another
example
of
this
sort
of
is
it's
our
back,
which
we'll
cover
in
more
detail
later.
That's
Korea,
B's
role,
based
access
control
for
amenities,
API
itself,
so
controlling
who
can
do
what
in
kubernetes
access
control
for
notes.
So
one
of
the
things
highlighted
in
the
report
is
that
you
know
you
do
need
to
manage.
Who
can
get
on
your
notes?
Because
if
anyone
can
get
there,
then
anyone
is
route,
especially
because
grid
of
these
has
to
trust
certain
components
to
the
underlying
infrastructure.
B
And
then
some
last
bits
here,
just
standard
Linux,
node
hardening
I'm,
not
a
Linux
security
expert,
more
of
a
container
community's
guy.
But
you
know
there
are
plenty
of
practices,
including
you
know,
CIS
benchmarks
and
things
like
that,
and
but
your
advantage
here
is
that
you
have
these
sort
of
limited
purposes.
Cookie
cutter
nodes
that
are
really
just
exist
to
have
a
container
runtime,
run
the
couplets
and
then
run
your
apps.
They
typically
aren't
going
to
be
doing
lots
of
other
stuff,
maybe
something
for
structure
stuff
like
logging,
but
you
know
not
too
complicated.
B
So
if
we
talk
about
infrastructure
and
API
first
well,
what's
left
everything
else
pods.
So
the
attacking
crew
Teddy's
guide,
which
is
sort
of
a
pen,
tester
oriented,
guide
talks
about
how
we
can
break
into
communities
clusters
and
they
point
out
that
often
critic
compromising
a
community's
cluster
isn't
actually
starting
with
an
API
problem
or
a
vulnerability
or
something
often
because
there's
one
API
server
and
maybe
a
million
apps
and
the
cluster.
B
It's
often
the
app
so
compromising
a
cluster
often
first
begins
with
compromising
a
lower
privileged
pod,
and
the
secure
configuration
of
pods
is
an
often
overlooked
aspect
of
the
system.
So
basically,
what
this
thing
here
is
you
have
job
number
one
is
keep
the
adversaries
out
of
your
pods
and
then
when
they
start
giving
some
more
security
guidance.
It's
a
second
job,
keep
them
in
one
place.
So
if
you
want
to
keep
your
cluster
secure,
yeah
make
sure
you
do
the
API
and
infrastructure
security
stuff.
B
That's
kind
of
the
basics,
make
sure
that
nobody
can
login
and
change
what's
running.
But
then,
once
your
apps
are
running,
they
do
have
some
interfaces
to
communities
and
it's
important
to
both.
You
know,
defend
each
pod
and
then
try
to
put
a
sort
of
wall
around
each
pod
so
that
people
don't
escape
out
of
that
pod
into
the
rest
of
the
infrastructure
and.
B
B
So
one
of
the
things
that
that
the
community
has
been
good
about
is
making
sure
that
upgrades
typically
don't
have
problems,
and
that
means
that
you
can't
have
too
much
of
a
surprise
when
you
do
an
upgrade,
you
can't
have
a
security
feature,
magically
turn
on
that
you
weren't
expecting,
and
that
does
mean
that
some
things
are
disabled
by
default.
We'll
get
into
some
specific
examples
later
so
now
back
to
the
quote:
ensuring
appropriate
configuration
of
all
options
requires
significant
attention
by
cluster
administrators
and
operators.
B
I
want
to
make
sure
that
we're
not
being
too
too
hard
here.
It's
a
complex
system
and
there's
a
ton
of
stuff
too
getting
deployed.
So
this
is
really
about
empowering
you
to
know
what
the
kind
of
things
are
that
you
can
look
for
and
how
you
can
use
kubernetes
to
your
advantage.
So
that
say,
there's
default
configurations
that
you
can.
You
know,
make
an
informed
choice
to
adopt
them
that
kind
of
thing.
So,
let's
start
going
through
the
parts
of
a
pod.
First
we'll
go
through
image
security.
B
This
is
something
that
the
attacking
kubernetes
guide
mentions
a
detail
because
they
cover
pods
a
little
bit
more.
So
file
systems
also
often
contain
bash
or
package
managers
that
further
enable
an
attacker
to
gain
a
shell
and
install
additional
tools.
An
ideal
installation
should
remove
all
non-essential
binaries
and
prevent
modifications
to
the
binaries
that
are
required.
B
Cluster
administrators
care
should
be
taken
that
vulnerable
applications
and
pods
are
patched
as
soon
as
possible,
so
that
internal
attackers
may
not
gain
an
initial
foothold
within
the
cluster,
so
there
they're
referring
to
the
sort
of
personas
they
made
for
through
the
test
of
internal
attackers,
external
attackers.
Things
like
that.
So
basically
like
look.
If
we
want
to
make
sure
that
our
pilots
can't
be
abused
to
get
into
our
cluster
well,
one
great
way
is
to
make
sure
that,
even
if
there's
an
ability
in
the
application
that
there's
nothing
there
for
the
attacker
to
use.
B
If
they
get
a
command
injection,
say
the
struts
vulnerability
is
one
everyone
thinks
about,
and
if
they
can
just
apt-get
install
whatever
they
need
you've
made
life
so
easy
for
them.
So
it
can
be
a
lot
better.
If
you
don't
need
something
just
remove
it.
One
thing
one
of
the
things
we
always
suggest
is,
after
you
finish
installing
stuff
in
your
docker
file
or
in
your
other.
B
You
know
way
of
building
an
image
just
uninstall,
that
package
manager,
the
package
manager
sometimes
needs
an
extra
flag
or
two
to
convince
it
that
you
really
know
that
you
want
to
remove
itself,
but
it's
possible
to
do
that.
So
that's
that's
sort
of
the
the
image
security
bit
and
then,
as
that
second
quote,
sort
of
gets
at
you.
B
No
vulnerabilities
are
sort
of
an
own-goal
now
the
way
to
fix
those,
obviously
isn't
to
just
give
a
big
list
to
to
some
team
and
say
like
fix
them
all,
but
particularly
if
something
is
high
severity,
particularly
if
there's
a
fixed
version
available.
Really,
there's
there's
not
a
great
reason
to
keep
it
running
like
that,
so
the
more
you
can
get
in
the
rhythm
of
having
teams
regularly
understands
the
outputs
of
an
image
scanner.
Are
there
plenty
of
open
source
options
or
commercial
options
that
the
more
you
can
get
in
that
rhythm
of
understanding?
B
What's
problematic,
what
can
be
fixed
and
then
rolling
it
out,
just
like
an
either
could
change
the
better
use
place
you'll
be
in
so
that's
the
image,
because
the
image
is
kind
of
a
foundation
for
the
security
of
the
pop,
but
there's
a
ton
more
because
communities
obviously
doesn't
just
run
containers
alone.
There's
a
lot
more.
So
let's
talk
about
our
back,
so
this
one
again
has
a
fairly
large
excerpt
from
from
the
pen
test
guide
the
attacking
guru,
Daddy's
guide.
B
So
all
containers
in
a
pod
run
with
a
service
account
and
attack
scenarios
have
been
documented
against
third-party
services
that
orchestrate
pod
deployments
using
overly
permissive
service
accounts.
In
these
instances,
a
compromise
of
a
pod
container
is
catastrophic,
but
they
note.
However,
those
compromises
may
not
eat
up
lunch
access
if
you're,
using
role-based
access
control,
authorization
controls,
but
at
the
time
of
the
report,
Trinity's
mounted
default
credentials
in
every
pod.
B
So
an
internal
attacker
could
use
those
to
access
other
resources
in
the
cluster,
like
the
couplet
from
there
that
eternal
attacker
might
be
able
to
move
laterally
throughout
the
cluster
to
get
wider
access,
and
some
of
this
is
still
true,
so
sort
of
an
opt-in
opt-out.
Again,
you
do
get
a
service
account
in
every
pod.
It
doesn't
have
much
access,
but
it
does
have
some
access
and
if
your
application
really
doesn't
use
the
Korean
API,
it's
a
really
low
cost
thing
to
just
remove.
B
It
well
cover
again
sort
of
a
summary
of
those
at
the
end,
but
let's
get
into
our
back
in
a
little
more
detail.
So
we
know
that
service
accounts
get
mounted
into
pods
and
that
that
might
be
bad,
but
we
also
know
from
the
guide
that
hey.
If
we
use
our
back,
maybe
we
can
mitigate
that
problem.
So,
let's
learn
about
our
back
a
little
bit
more.
So
some
of
the
difficulties
of
using
our
back
well
objects
can
be
composed
by
referencing
other
objects.
That
may
not
exist.
B
So
if
you've
seen
a
llamó,
it
may
have
a
reference
section
where
it
says:
I'm
gonna
reference,
another
object,
its
API
version
v1
and
it's
a
type.
It's
a
cholesterol
and
here's
the
name.
It's
that
this
is
nice,
because
you
can
sort
of
create
your
your
animals
in
any
order.
You
don't
have
to
do
a
sort
of
relational
database.
B
You
know
figure
out
which
one
needs
to
come
in
first
and
foreign
key
constraints,
but
it
does
mean
that
you
might
make
a
mistake,
because
you
can
reference
objects
that
might
not
exist.
Also,
the
objects
can
be
created,
even
if
the
controller,
the
component,
that's
using
them,
doesn't
exist.
So
in
this
example,
they're
saying
it
can
be
really
dangerous
when
you're
making
our
back
policies,
because
you
actually
have
to
test
it,
you
might
believe
that
your
policies
are
in
effect
when
they're
not.
B
This
can
also
affect
Network
policies
which
we'll
cover
in
a
little
more
detail.
But
if
you
haven't
enabled
our
back
controller
all
the
rule
bindings
in
the
world
won't.
Do
you
any
good
if
you
haven't
disabled
the
attribute
based
access
control,
the
old
authorization
controller
for
network
policies?
If
you
don't
have
a
plugin
that
knows
how
to
deal
with
policies,
all
the
policies
in
the
world
won't
will
restrict
your
network
access
at
all.
B
So
a
little
bit
of
more
background,
just
just
to
show
there's
roles
and
role
bindings,
more
or
less
and
a
role
plus
a
role
binding
is
what
grants
you
access.
So
in
this
example,
we've
got
some
cluster
roles.
These
allow
you
to
use
a
pod
security
policy,
which
is
something
we'll
cover
later,
but
you
can
see
on
the
left-hand
side
that
the
the
are
back
role
is
telling
sort
of
which
API
what
kind
of
resource
and
what
I'm
allowed
to
do.
B
What
verbs
and
then
there
are
some
nouns
like
which
Paulo
treats,
which
which
policy
names
I'm
allowed
to
use,
and
then
they
were
all
binding
on
the
right
side
of
the
slide
shows
that
it's
one
of
those
references
where,
where
the
object
might
have
exist,
but
again
to
a
kind
cluster,
all
with
a
name
that
matches
in
the
left
side
API
groups
of
matches,
and
then
it
grants
that
role
through
a
set
of
subjects.
And
those
subjects
in
this
case
would
be
a
service
account,
but
they
could
also
be
a
user.
B
A
group
that
sort
of
thing
that's
how
you
get
access
and
based
on
sort
of
what
we
covered
in
the
last
few
minutes.
You
might
be
thinking
of
some
of
the
problems
that
might
ensue,
so
there
are
a
couple
best
practices.
You
find
this
a
little
more
detail
on
the
leave
on
the
CNC
F
blog,
so
some
are
back
best
practices
with
a
knob
too.
It's
got
extra
cluster
admin
considered
harmful,
just
like
go-to,
it's
as
bad
as
go-to
I
telling
you
so
cluster
admin
basically
gives
you
access
to
everything.
B
So
there's
a
role
aggregation
feature
and
if
you're
going
to
use
that,
just
be
careful
that
you
don't
sort
of
mix
the
meaning
of
the
roles.
So
if
you
have
a
view
role,
you
can
add
more
permissions
to
it
using
role
aggregation.
But
if
you
add
an
edit
thing,
you've
changed
the
meaning
of
the
base,
role
that
you're
aggregating
to
and
that
can
be
confusing
and
grant
unintended
access.
B
The
third
one
to
grant
each
role
with
just
one
binding.
You
don't
want
to
have
multiple
paths
through
to
granting
access,
because
then,
if
you
remove,
one
you'll
think
you've
done
it.
But
you
haven't
paired
with
that
sort
of
cleaning
up
unused
roles
and
bindings
it's
much
harder
to
tell
what's
going
on.
If
you've
got
a
bunch
of
trash
lying
around
then
avoiding
dangling
bindings,
that's
where
the
the
whitepaper
was
talking
about
how
you
can
reference
objects
that
don't
exist
well?
Why
would
that
be
a
problem?
B
Well,
one
thing
that
can
happen
is
you've
got
a
binding
that
points
to
a
role
the
person
doesn't
have
any
access,
because
that
role
it
doesn't
exist.
You
add
a
new
role
and
you
give
a
binding
to
the
person
you
want
and
all
of
a
sudden,
your
old
subject
also
has
access.
So
just
some
problems
that
can
happen
with
our
back
and
then
warning.
Just
none
of
this
really
matters
if
you
still
haven't
disabled
attribute
based
access
control,
so
if
you've
installed
since
1.8
or
so
you're,
probably
fine,
but
if
you've
upgraded
an
old
cluster.
B
Sometimes
we
find
clusters
that
still
have
this
stuff
in
Able's
just
by
accident,
because
you
know
it's
a
nice
easy
one
touch
upgrade,
but
you've
got
to
actually
go
and
change
the
API
server
to
disable
this
old
teacher.
So
that's
our
back
this
role
this
plays
in
with
namespaces,
which
is
the
next
thing
we'll
talk
about
we're
getting
toward
the
end.
So
there
will
be
a
time
to
pause
as
well
for
questions.
I
have
seen
some
Q&A
come
in.
B
Let's
talk
about
namespaces,
so
the
white
paper
talks
about
how
religious
namespaces
were
developed
as
a
method
to
help
provide
workload.
Isolation
because
running
multiple,
potentially
multi-tenant
workloads
in
the
same
namespace
that
would
side
stuff
the
protection
of
namespaces,
giving
you
a
single
flat
namespace.
So
that's
sort
of
the
diagram
on
the
right
you've
got
maybe
sixteen
applications
and
they're
all
in
one
namespace,
and
that
will
talk
about
some
of
the
controls
that
apply
or
don't
apply
when
they're
all
in
one
namespace.
You
might
ask
how
do
I
put
myself
in
the
namespace?
B
Well
pretty
easy.
So
at
the
bottom
of
the
screen,
you'll
see
a
deployment
yeah
--ml
inside
the
metadata,
just
where
you'd
name
and
label
your
stuff,
you
can
also
put
a
namespace
and
that
will
locate
the
objects
inside
of
a
communities
namespace
many,
if
not
most,
objects
and
credit.
These
are
names
based,
but
you
just
need
to
put
the
stuff
that
you
want
together
and
then,
when
you
use
cube
control
to
get
pods
or
get
your
deployments,
you
just
added
a
namespace
flag
and
that
keeps
sort
of
different,
often
different
teams.
B
It
depends
on
you,
know
the
organization,
but
often
we'll
see
people
go
either
by
service,
tiers
or
teams.
Things
like
that,
because
there's
a
natural
boundary
where
this
team
is
responsible
for
the
stuff
in
this
namespace.
This
team
is
responsible
for
that
namespace
and
it
just
makes
a
little
more
predictable
and
you
know
also
minimizes
conflicts,
because
when
you
namespace
things
the
names
are
names
based.
You
don't
have
collisions
where
someone
wants
to
call
something
DB
and
then
they
all
try
to
fight
for
the
name,
so
they'll
sort
of
what
namespaces
are.
B
Let's
talk
about
the
security
controls
because
they
mentioned
this,
you
know
slide
stepping
the
protection
of
namespaces
so
on
the
left.
There's
that
bad
large
flat
single
namespace
and
on
the
right
maybe
another
way
of
breaking
up
your
services
and
each
of
those
sort
of
boundaries.
There
is
a
natural
boundary
for
network
policies
because
there
were
falsies
by
default.
We'll
talk
about
you
know,
pods
talking
to
other
pods,
but
that'll
be
within
a
namespace
and
to
grant
access
across
namespaces.
B
You
have
to
take
a
different
step,
so
you
can
have
a
better
sort
of
natural
default
isolation
if
you
use
a
namespace
for
network
policies
for
our
Beck,
all
of
the
role
bindings
and
and
stuff
are
granted
inside
of
either
the
entire
cluster
or
in
a
specific
namespace.
So
if
you
need
to
give
someone
access
to
edit
their
own
services,
you
really
can
only
do
that
if
it's
in
a
separate
namespace
that
way
they
can't
mess
with
other
folks
things
by
accident,
there's
the
ability
to
mount
secrets,
those
are
references
within
a
namespace.
B
You
don't
get
to
mount
things
across
namespaces.
So
if
you're
worried
about
accidental
secret
exposure,
things
like
that
just
the
way
that
the
API
works,
there's
no
way
to
say,
like
I,
want
a
secret
outside
of
a
namespace.
As
far
as
I
know,
it's
a
local
reference
is
what
it's
called
an
API
types.
So
breaking
up
your
name.
Spaces
like
this
means
that
somebody
can
accidentally
snag
your
secret
value.
B
The
use
of
image
pool
secrets
is
also,
you
know,
usually
broken
up
by
namespace,
because
the
secret
lives
in
a
namespace,
that's
if
you're
pulling
from
a
private
registry-
and
you
maybe
if
you
have
different
registries,
for
different
teams
or
for
different
service
tiers,
you
can
keep
the
secrets
different
and
then
have
less
of
a
everything
breaks
at
once.
If
you
change
the
password
kind
of
deal
and
there
are
other
boundaries
as
well,
they
really
lend
themselves
to
this
namespace
idea.
B
I
mentioned
a
second
ago
that
you
know
people
might
make
mistakes
and
accidentally,
you
know
edit
services
they're
not
supposed
to
edit
I'll.
Tell
you
a
friend:
I
won't
tell
their
name,
but
they
told
me
they're
gonna
start
using
our
back
right
away
because
they
had
accidentally
had
a
an
API
call
that
didn't
put
a
namespace
selector
on
when
I
was
deleting
replica
sets,
and
so
luckily
they
are
using
deployments
for
their
application.
B
But
every
so
often
in
this
batch
process
would
delete
all
flic
assets
delete
all
the
pods
prot
goes
down
there,
trying
to
figure
out.
Why
it's
going
up?
Why
it's
going
down?
Why
it's
fixing
itself
so
a
little
bit
of
Krugman
of
these
magic
in
there,
but
they
figure
out
that
the
service
account
they're
running
in
they
weren't
using
our
back,
so
they
weren't
enforcing
that
control,
and
this
was
fairly
recent.
B
So
that's
namespaces.
Let's
move
on
to
one
of
my
favorites!
This
is
a
pod
level
control.
So
the
pen
test
guide
talks
about
the
how
in
many
pods
the
root
filesystem
is
not
usually
read-only.
So
that
means
that
you
can
install
additional
tools
and
again
sort
of
like
having
your
image,
have
extra
package
manager
and
things
like
that
in
it.
This
is
the
thing
that
really
makes
life
easier
for
for
an
adversary.
B
B
But
so
this
is
similar
to
having
sort
of
a
clean
slate
for
your
images
you
want
to
have.
You
can
set
up
read-only
root
of
s,
there's
just
one
option:
it's
inside
the
the
security
context
for
the
container
and
what
you
that
does
is
make
the
slash
filesystem
read-only.
So
by
default,
nothing
in
the
container
will
be
writable
for
many
apps.
That's
actually!
Ok,
you
don't
need
to
write
things
if
you've
gotten
sort
of
a
stateless
app
going
or
if
all
the
persistence
is
in
a
database
somewhere
else
or
if
you're
just
handling
API
traffic.
B
B
You
can
add
writable
paths,
even
if
you
have
read-only
root
filesystem
by
adding
either
of
Vol
docker
file
instruction,
which
will
work
if
you're,
using
docker
or
so
that
v
in
your
image
and
if
you're,
using
cryo
or
other
runtimes,
you
can
use
your
communities
SPECT
at
an
empty
durval
um--,
which
gives
you
kind
of
scratch
space,
but
it'll
go
to
a
specific
path,
which
means
that
the
adversary
won't
just
be
able
to
have
a
script
that
writes
in
to
temp.
That's
what
almost
everyone
does.
B
Temp
is
always
writable,
so
if
you
can
sort
of
just
make
it
slightly
harder
for
them
by
adding
you
know
specific
paths
that
you
need
writable
that
helps
you
out
too.
This
is
the
kind
of
thing
where
you
can
I
think
it
I
think
everyone
can
do
it.
I
haven't
heard
anyone
come
back
with
something
that
that
actually
means
they
can't
so
I'd
love
to
see
this
one
out,
I'm
gonna,
keep
saying
it
till
I
die
or
till
kubernetes
goes
away,
but
that's
not
gonna
happen.
B
So
read-only
root
of
s
is
one
of
these
things.
It
also
helps
you
with
operational
practices,
because
if
you
accidentally
start
right
into
a
path,
this
can
stop
you,
because
if
your
developers
accidentally
change
some
path
or
something,
maybe
operations
is
going
to
like
that,
because
they've
allocated
storage
or
something
having
the
Reap
having
the
root
filesystem
read-only
encourages
people
to
be
very
specific
about
what
they
need
to
be
writable
and
how
things
like
that
so
read-only
root.
If
s
and
then
finally,
our
last
control
will
be
in
network
policies.
B
So
the
advice
from
the
Satori
white
paper
is
to
ensure
that
the
container
network
interface
is
as
restrictive
as
possible
through
the
definition
of
cluster
Network
policies
and
I.
Think
that's
about
the
extent
of
the
paragraph
that
that's
shown
there,
because
by
default,
every
pod
can
talk
to
every
other
pod.
It's
great.
You
know
we
even
have
entire
projects
about
making
mesh
networks
between
services,
but
one
of
the
things
you
come
up
with
is
once
you've
got
a
bunch
of
microservices.
B
So
that's
the
default
to
change
that
you
just
have
to
apply
a
network
policy
and
then
network
restrictions
are
going
to
be
enforced
for
a
given
pod
only
once
you
apply
a
policy
to
it.
So
this
is
kind
of
an
interesting
rollout
by
default.
Nothing
is
restricted
and
then
to
restrict
a
single
pod.
It'll
go
pod
by
pod
and
policies
start
getting
enforced
as
soon
as
you've
got
a
single
policy
targeting
them.
B
So
one
of
the
strategies
we
often
use
is
to
go
namespace
my
namespace
and
apply
a
policy
that
just
lets
people
inside
the
namespace
talk
within
the
namespace.
That
way,
you
cover
all
your
pods,
they
start
getting
enforcement
and
then
you
can
start
white
listing
sort
of
external
connections
that
have
to
happen,
and
then
you
can
also
work
sort
of
iteratively
to
narrow
down,
even
with
the
namespace,
if
that's
desirable,
just
an
example
of
how
never
policy
look.
B
B
There
are
also
key
press
policies,
but
often
those
are
kind
of
a
little
more
advanced
in
terms
of
your
deployment
model.
Just
because
ingress
is
a
little
bit
easier
to
reason
about
then
egress
often
we
see
people
really
just
restricting
like
internet
egress,
because
otherwise
you
have
to
say
on
service
a
I
want
to
be
able
to
talk
to
service,
be
on
service,
be
I,
want
service
a
to
be
able
to
talk
to
me.
It's
a
little
more
difficult
to
manage
this.
A
B
An
example
where
labeling,
which
is
part
of
sort
of
standard
communities
metadata,
is
really
helpful
because
you
can
see
all
this
is
based
on
polyols.
So
having
consistent
labeling
practices
and
doing
sort
of
tier
based
label
laying
or
their
kind
of
strategy
that
helps
you
not
go.
You
know
container
by
container
pod
by
pod,
is
really
helpful.
So
those
are
the
network
policies
and
that's
the
last
of
the
specific
communities
native
controls
they
want
to
talk
about
from
the
security
audit
Chris.
A
A
B
Okay
yeah,
so
this
is
this:
is
the
stack
hearts
product
I'm,
mainly
using
it
for
the
visualization,
also
because
this
is
a
CN
CF
opener,
but
just
to
show
you
the
network
policies
and
kind
of
how
they
apply
and
things
like
that.
The
example:
apps
are
just
custom,
apps,
so
network
policies,
typically
they
are
going
to
be
applied
at
you,
know,
sort
of
Paul
Abel's.
So
that's
your
end
points
and
then
ports.
So
it
works
fine.
B
If
you're
not
doing
you
know,
even
if
you're
not
to
being
HTTP
and
stuff
some
you
know,
service
tools
will
will
be.
You
know
more
oriented
toward
a
CH
t.
Tp
HTTP,
your
PC,
but
network
policies
are
kind
of
like
level
3
level
4
controls
that
apply.
Even
if
you're
doing
you
know,
non-http
workloads
like
message
queues.
B
Good
to
go,
Christmas
or
I
think
we're
good,
ok.
So,
let's
get
to
the
good
part,
how
you
can
use
all
this
to
design
a
cord,
IDs
native
security
strategy
and
I'm
mindful
of
time
so
I'm
gonna
go
through
some
advice,
talk
about
the
opportunity
we
have
and
then
some
enforcement
options,
and
maybe
some
ideas
to
get
started.
B
So
remember
that
paragraph
from
the
beginning,
where
it
seemed
a
little
bit
harsh
even
well
considered
friendly
advice,
but
you
know
the
code
base
has
problems.
Some
configurations
are
confusing.
That
kind
of
thing.
Well,
there's
a
another
paragraph.
You
know
I
think
it's
in
the
next
page
or
right
after
highlighting
the
opportunity
we
have
so
we
started
off
talking
about
problems.
Then
we
moved
on
to
some
of
the
controls
we
can
use.
But
overall,
let's
talk
about
the
opportunity
we
have
with
kubernetes.
B
So
despite
the
results
of
the
assessment
they're
talking
about
the
vulnerabilities
things
like
that,
and
despite
the
operational
complexity
of
underlying
cluster
components,
kubernetes
streamlines
difficult
tasks.
Really
it's
maintaining
and
operating
cluster
workloads
such
as
deployments,
replication
and
Storage
Management.
So
communities
is
doing
a
ton
of
stuff.
For
you,
additionally,
kubernetes
does
take
steps
to
help
cluster
administrators
harden
and
secure
their
clusters
through
features
such
as
role
based
access
controls,
Arabic
and
various
policies
that
extend
the
Arabic
controls
here.
I
think
they're,
talking
about
sort
of
pod
security
policies.
B
Things
like
that
and
continued
development
of
those
security
features
and
for
the
refinement
of
best
practices
and
same
defaults
will
lead
the
kubernetes
project
toward
a
secure
by
default
configuration.
So
even
in
the
midst
of
you
know,
we
got
problems.
We've
got
some
configurations
that
are
maybe
hard
to
use.
B
B
You
know
the
bones:
if
you've
got
a
scanner
going,
you
know
if
registry
it
came
from
again
if
you're
scanning
you'll
know
what
exact
packages
components
are
inside
based
on
which
cluster
it's
in
you
might
know
if
it's
test
or
prod,
which
sort
of
business
unit
which
part
of
your
organization
so
the
sort
of
implicit
context
based
on
the
annotations
and
labels.
You
might
know
something
about
the
criticality
of
the
app
the
dev
team
is
responsible,
ops
team.
Maybe
this
is
where
having
good
annotations
and
labels
can
be
really
helpful.
B
The
privileges
are
specified
in
UML,
so
in
the
security
context,
is
where
a
lot
of
them
come,
but
other
things
like
host
mounts
and
the
service
account
settings
which
service
account
is
then
all
the
are
back
camels
that
say
sort
of
what
that
gets
in
terms
of
access.
You
might
have
like
a
secret
like
an
API,
key
or
crypto
material
secrets.
You
might
be
mounting
a
cloud
disk
and
that's
important
from
a
security
perspective,
because
we're
always
looking
for
where
people
can
do
persistence
on
the
network.
B
You'll
know
something
about
the
blast
radius,
because
you'll
see
if
their
network
policies
applied
you'll,
see
if
this
pod,
if
someone
gets
inside,
can
they
talk
to
other
pods?
Can
they
talk
to
the
API
server?
Can
they
talk
to
the
internet
and
then
on
the
other
way
on
the
ingress
you'll,
be
able
to
see
services
and
ingress
and
understand,
what's
actually
exposed
so
that
you
know
all
the
stuff
around
the
rest
of
the
the
heptagon?
B
So
there
a
bunch
of
tools
you
can
use
to
do
runtime
monitoring
to
see
like
what
kind
of
processor
launched
in
which
active
connections
which
can
inform
the
other
configs
so
that
you
can
kind
of
you
know
back
through
the
rest
of
the
contexts
and
the
the
specs
it's
a
really
cool
opportunity,
because
every
application
we
have
has
all
this
data,
which
makes
doing
all
the
security
workflows
a
lot
easier
makes
a
diagnosis
easier
makes
fixing
the
config
is
easier
and
makes
response
easier
too.
So,
let's
talk
through
some
enforcement
options.
B
So
first
is
pod
security
policy.
This
is
kind
of
a
native
upfront
config,
that's
built
into
kubernetes.
You
can
define
policies
and
then
it
sort
of
uses
our
back
identities
to
tie.
Who
can
use
what
we
saw?
Actually,
that
was
the
example
I
used
earlier,
and
this
slides
about
our
back
make
controls
things
like
privileges
host
mounts
other
settings
like
that
you
do
have
to
enable
pod
security
policy
as
as
a
cluster
feature
and
once
you're
ready
to
use
it,
and
you
do
need
that
policies
in
place
before
you
do
that.
B
Otherwise,
you
will
block
everything
it's
another
example
of
defaults
being
maybe
different
between
features
sort
of
the
middle
option
here
I
am
a
commission
controller.
This
is
something
that
one
of
my
colleagues
has
written
about
in
the
community's
blog
example
of
getting
started
with
emission
control.
It
does
require
deployment,
so
you
need
to
a
cloud
service
or
a
local
service,
ideally
replicated,
but
it
can
consider
any
data.
B
B
Once
you
get
the
API
call,
you
can
integrate
with
an
external
system,
see
if
it's
in
your
service
registry,
anything
like
that
just
be
mindful
of
the
API
timeout,
because
you
don't
want
to
Cupido
commands
to
be
hanging
for
you
know
more
than
five
seconds
and
take
down
your
cluster
either
or
automation
and
then
finally
sort
of
ongoing
monitoring
and
analysis.
This
is
sometimes
the
the
neglected
part
of
security
where
people
want
to
do
a
lot
of
upfront
configs,
but
that
has
the
effect
sometimes
of
making
it
unusable
cluster.
B
B
Maybe
so,
overall,
just
remember
the
user
experience
when
you're
choosing
what
to
enforce
and
we're
to
enforce
it
being
an
unnecessary
bottleneck
is
a
great
way
to
get
managed
out
of
your
cluster
and
don't
and
don't
cry
wolf
either
if
something's
not
a
huge
critical
issue,
don't
like
people
up
on
them
in
the
middle
of
the
night,
using
all
that
contact
can
help.
You
diagnose
that
so
how'd
it
get
started.
Well,
it's
sort
of
jump
through
real
fast
before
handling
any
final
questions.
So
I
always
say
start
with
the
easy
stuff
that
helps
everybody.
B
Everybody
is
helped
if
you
annotate
and
label
deployments
consistently.
If
everybody
can
look
at
a
thing
and
know
what
it
is.
That's
great,
using
concrete
image
tags
like
not
latest-
and
you
know,
maybe
start
scanning
images
for
low-hanging
fruit,
and
you
can
do
that
in
the
dev
process
offline.
You
can
do
it.
B
You
know
all
points
in
the
process,
then
maybe
you
might
level
up
to
other
sort
of
self-contained
changes,
maybe
that
don't
have
as
many
effects
maybe
limiting
access
the
KPI,
because
that
can
be
an
important
security
surface
and,
as
we
saw
with
some
recent
vulnerabilities
like
resource
exhaustion,
is
involved
laughs,
you
know,
if
you
don't
need
to
expose,
don't
expose
it,
you
can
start
disabling
automatic
service
account
mount
for
given
service
accounts.
If
you
know
you're
not
using.
B
You
can
also
start
replacing
your
cluster
Rabin's
just
but
scoped
access,
so
person
by
person
or
service
account
by
service
account.
Then
you
know,
cross-functional
changes
may
be
best
to
go
at
by
app.
So
maybe
you
start
trying
read
only
root
filesystem
app
by
app
for
a
stateless
service
make
sure
a
resource
requirements
are
specified
because
that
has
availability
impact
part
of
the
CIA
triad,
confidentiality,
integrity,
availability.
We
always
forget
about
that
one
and
then
adding
ingress
their
policies
house.
If
you
start
with
sensitive
stuff
and
just
limit
who
can
talk
to
it?
B
You
in
the
rhythm
of
network
policies,
before
you
get
to
all
your
apps
and
finally
just
keep
going,
there's
so
much
that
you
can
do
and
it's
it's
it's
not
that
you'll
get
to
security
one
day.
It's
just
get
the
process
to
keep
to
keep
going
through.
So
that
will
be
done.
If
you
have
questions
you
can
ask
and
zoom
now
you
can
also
email
me
or
get
me
on
Twitter
I
put
my
picture
in
the
front,
so
you
can
find
me
at
goop
con
to
be
happy
to
talk
to
you.
There.
A
A
B
A
Away
Chris
may
be
favored
yeah
like
so.
The
the
the
alpha
stuff
is
stuff
that
I
would
not
recommend
it
using
in
production
when
it
comes
to
kubernetes,
definitely
use
it
and
EV
definitely
make
sure
you
kick
the
tires
on
it,
because
it's
coming
soon,
the
the
beta
things
were
actually
like.
You
know,
put
in
open
shift
for
production
workloads
long
ago,
so
beta
and
kubernetes
is
definitely
usable
and
stable.
The
fact
that
it
hasn't
gone
into
the
main
v1
API
pipeline-
it's
just
a
matter
of
bandwidth,
I,
believe
there's.
B
Another
question
as
well
one
more
thing
on
that
is
Chris
mentioned:
you
know.
If
something
alphago
kick
the
tires.
Do
it
because
alpha
is
the
time
when
you
can
change
the
API
betas
once
thing
is
one
start,
things
start
to
get
solidified.
So
if
there's
a
problem
with
the
feature,
you
know
you
wanna,
you
wanna,
make
it
better.
Try
out
the
Alpha
features
and
gives
us
the
feedback
exactly.
A
A
B
A
B
You
want
to
require
read-only
route
of
fest
or
something
get
mini
coop
on
your
machine
and
try
it
there.
Don't
don't
push
it
through
CI
every
time
right
do
the
local
stuff.
So
you
can
see
the
logs
do
a
quick
iteration
figure
out
what
it
really
needs
and
also
consider
what
kind
of
PSPs
you're
doing
if
it
sounds
like
it
might
be
a
little
too
restrictive.
Maybe
so,
if
there's
some
baseline,
that
that's
more
appropriate
for
everyone
that
might
be
a
yeah.
A
A
A
B
And
we
kind
of
settled
on
a
thing
of
like
if
this
namespace
isn't
ready
for
narrow
policies,
yet,
like
start
with
the
blanket
yeah,
but
but
sort
of
that
that
one
that
work
while
she
lets
you
opt
in
to
a
segmentation
app
or
app
by
app
or
team,
my
team
actually
kind
of
nice.
It
can
be
hard
if
you've
got
a
lot
of
namespaces
to
keep
track,
but
there's
some
benefit
to
it.
You,
yes,
cool.
A
All
right
so
I
gotta
go
follow
you
on
Twitter
and
find
you
that
you've
gone.
Everybody
else
do
the
same.
If
you
have
more
questions,
please
email,
Collin,
myself
or
Connor.
Sorry,
Connor
myself,
the
CNC
have
staff
and
I
posted
a
link
to
the
blog.
That
has
a
lot
of
the
references
that
were
in
this
slide
deck
and
we'll
get
the
slides
and
a
video
out
as
soon
as
we
can
on
scenes,
yet
that
IO
slash
webinars
thanks
for
joining
us
today.
Thank
you.
Connor
appreciate
everything.