►
From YouTube: Help! My Cluster Is On The Internet: Container Security Fundamentals - Samuel Davidson, Google
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Help! My Cluster Is On The Internet: Container Security Fundamentals - Samuel Davidson, Google
You know security is important, but what does that actually mean in containers and Kubernetes, and more importantly, what are you supposed to do about it? If you’re new to Kubernetes, or at least Kubernetes security, this session will cover the fundamental concepts in container security -- including supply chain security and runtime security -- and give you context for the security tooling and open source projects like Falco and Open Policy Agent you will encounter in the cloud native ecosystem. We’ll use a real world example (“Oh no! This cluster is open to the internet!”) and cover a cheat sheet that you help you prevent bad things from happening. You should expect to leave this session with a mental model of how to think about container security, a list of security-related decisions you need to make on “day 0," and resources for how to keep security front and center in your team.
https://sched.co/ZetO
A
Hello,
everyone
welcome
to
help
my
clusters
on
the
internet
container
security
fundamentals.
My
name
is
samuel
davidson,
there's
my
linkedin
and
and
website.
If
you're
interested
picturing
me-
and
I
will
be
your
tour
guide
through
the
wonderful
world
of
container
security
in
kubernetes,
so
again
a
little
bit
about
me.
My
name
is
samuel.
Davidson
I've
been
at
google
for
about
three
years
two
and
a
half
of
which
I've
worked
on
gke,
the
google
kubernetes
engine
on
the
security
team.
A
Before
joining,
I
was
a
total
kubernetes
beginner,
so
I've
kind
of
got
that
perspective
of
not
knowing
what's
going
on
to
knowing
a
lot
about
kubernetes
security.
So
to
the
title
of
the
talk
again
help
my
clusters
on
the
internet.
There's
your
cluster
floating
around
in
the
cloud
of
the
internet
and
typically
yeah
your
cluster
is
on
the
internet.
A
It's
how
your
devs
access
your
api
server
and
configure
workloads
and
and
set
policy,
and
all
that
and
it's
how
your
users
can
access
their
pods
or
their
data
or
you
serve
api
traffic.
All
that,
but,
as
I'm
sure
you
know,
the
internet
is
a
very
scary
place
with
bots
and
trolls
and
bugs
and
malicious
third
parties
and
bad
guys
and
your
developers
are
making
mistakes,
and
all
of
these
are
working
against
you
to
compromise
your
cluster
to
cause
your
organization,
some
pain.
A
So
I'm
going
to
be
walking
you
through
a
whole
bunch
of
tips
and
tricks
to
help
mitigate
all
these
risks.
So
before
we
dig
into
that,
let
me
briefly
talk
on
the
structure
of
this
talk.
First,
we're
going
to
be
looking
at
workload,
security,
so
the
posit
containers,
then
cluster
security,
which
will
be
like
the
control
plane
and
the
nodes
and
then
we'll
be
looking
at
user
security,
which
is
like
all
of
your
developers,
your
automation,
your
ci
cd,
and
all
that
so
starting
with
workload
security.
A
There
you
are
with
your
with
your
laptop
and
you've,
got
a
workload
to
deploy,
and
you
want
to
make
it
secure.
What
do
you
do?
First
and
foremost,
what
you
think?
What
do
you
need
to
think
about
is
that
you
need
to
assume
that
you'll
be
owned,
and
this
is
a
recurring
theme
throughout
the
entire
talk.
A
You've
got
to
assume
that
there
is
a
there's
a
yet
to
be
discovered
vulnerability
in
one
of
your
dependencies
or
in
one
of
your
base,
images
that
will
allow
remote
code
execution
data
exfiltration,
whatever
your
definition
of
owned
might
be.
So,
let's
look
at
a
let's
look
at
an
example
here.
Container
one
has
all
of
these
tools:
these
linux
tools,
file
systems,
a
whole
bunch
of
keys,
full
networking
capability
and
container.
A
Two
is
a
soft
padded
baby's
crib
with
a
nice
purple
plastic
key
that
maybe
isn't
useful
for
much
just
one
specific
goal
now
which
of
these
containers?
Would
you
rather
an
attacker
own
right,
there's
container
one
where
they
have
all
the
suite
of
this
huge
attack,
surface
suite
of
possibilities
or
container
two,
where
they're
kind
of
trapped
in
a
little
cage?
Obviously
this
is
a
jokey
analogy,
but
we
want
to
make
our
containers
look
more
like
container
two.
So
how
are
we
gonna?
Do
that?
A
A
It
has
all
kinds
of
fancy
features,
it's
got
that
that
you
know
anti-lock
brakes
and
and
steering
assist,
and
whatever
else
it's
got
all
the
cool
tools
built
into
debian
10,
and
it's
also
running
on
top
of
the
debian
kernel,
which
would
be
like
the
wheels
and
the
engine.
The
distralis
release
of
of
debian
10
is
more
like
just
that
kernel.
A
It's
got
the
wheels
and
the
engine
the
bare
bones
to
move
forward
so
mostly
for
the
most
part,
your
workloads
do
not
need
that
suite
of
of
amazing
options
that
that
debian
has
baked
in
and
they
just
act
as
a
basically
attack
surface
that
when
someone
owns
their
cluster,
they
can
use
the
shell
to
ping
around
to
curl
all
kinds
of
endpoints
within
your
cluster
and
cause
you
a
bunch
of
problems.
So
how
do
we
transition
from
debian
10
to
the
distrolus,
w
intent
or
whatever
other
you
know,
distribution
of
linux
or
operating
system
you're?
A
Using
it's
really
easy.
So
here's
an
example:
dockerfile
you
can
see
they
build
their
binary
with
a
sort
of
golang
builder
image,
and
then
they
copy
that
build
that
built
binary
into
debian
10
and
that
is
sort
of
the
output
container
that
is
used
to
transition
to
distralist.
You
simply
replace
debian
10
with
a
distralis
path
to
base
debian
10.
A
and
again
you
don't
need
to
be
using
wn10,
there's
other
distributions,
there's
distalish
versions
of
all
kinds
of
operating
systems,
but
they
all
strip
out
sort
of
all
of
those
tools
and
shells
and
stuff
that
an
attacker
might
use.
I
just
want
to
note
that
there's
a
builder
pattern
used
here
where
they
build
the
binary
before
copying
it
into
the
the
final
sort
of
base
image,
and
you
will
have
to
do
that
because
the
distro
list
is
so
bare
bones
that
compilers
won't
even
really
run
in
them.
A
You
want
to
read
up
on
distralist
pause
here,
go
to
that
bitly
link
or
you
can
just
google
distralis
super
easy
super
common
number
three.
Is
you
want
to
make
sure
that
your
containers
are
really
easy
to
rebuild
and
really
easy
to
deploy?
Why
is
that,
aside
from
just
the
convenience?
Well,
typically,
a
lot
of
the
vulnerabilities,
the
critical
vulnerabilities
and
security
issues
you'll
run
into
are
actually
like.
I
said
in
your
dependencies
in
the
packages
you
pull
in
or
your
base
images.
A
So
often
you'll
have
an
exchange
like
this,
where
an
engineer
might
come
and
they
say
help.
I've
got
a
critical
vulnerability
in
my
container.
You
know
how
much
work
is
this
gonna
be
well
if
you're,
if
your
containers
are
easy
to
rebuild
and
deploy
you
just
bump,
that
dependency
number
bump
the
base
image
edit
the
docker
file,
you
know
one
line
change
and
let
the
ci
cd
platform
take
the
take
the
rain.
So
here's
a
you
know
a
wall
of
ci
cd
platforms.
A
It's
typically
how
people
accomplish
easy,
rebuilds,
easy
employees,
obviously
there's
a
bunch
of
recognizable
brands
there.
This
is
taken
from
the
cncf
landscape,
so
I
recommend
you
set
up
a
csd
platform
that
makes
all
this
whole
process
easier
and
similarly,
you
want
to
trust
your
containers
with
signatures.
A
This
is
another
cool
feature
of
the
ci
cd
environment,
which
is
signatures
which
are
also
known
as
binary
authorization
signed
containers,
image,
signing
binary
attestation,
content
trust
depending
on
the
platform
or
the
brand
or
whatever
they
use
these
different
names,
but
they're,
basically
the
same
thing
where,
whatever
built
your
container,
whatever
your
compiled
your
code
and
containerized,
it
attaches
a
signature
to
it
from
there.
They
have
a
trusted
private
key
that
you've
given
them
and
they
use
that
private
key
sign.
A
No
questions
asked
which
is
a
pretty
huge
risk.
So
if
we
utilize
signatures,
we
can
have
our
trusted
ci
cd
platform,
which
has
that
private
key
that
we've
given
it
that
we
sort
of
has
to
have
told
our
cluster
to
trust,
and
it
will
attach
signature
to
that
container.
Spits
out
and
our
ci
cd
platform
can
be
configured
to
only
pull
reviewed
trusted
code
in
our
master
or
release
branches
on
github,
for
instance,
and
signatures
have
a
bunch
of
other
really
awesome
properties
we
can.
A
We
can
use
for
them
in
your
ci
cd
platform.
You
can
do
dependency
validation,
bone
scanning,
you
can
run
a
suite
of
integration
tests
and
each
one
of
these
phases
can
each
have
their
own
signature.
So
as
our
reviewed
code
is
compiled
and
pushed
through
all
these
phases,
it
can
get
a
signature
as
each
of
these
phases
is
successful
and
then
the
final
output
container
can
have
all
of
these
signatures.
That
sort
of
provide
guarantees
that
we've
run
all
these
tests.
We
have
run
all
these
dependency
validations
and
no
major
issues
arose.
A
So
we
can
then,
as
I
said,
take
your
kubernetes
cluster
and
configure
it
such
that
it
will
only
admit,
containers
that
have
these,
for
you
know
valid
dependencies,
past
tests
and
all
that
and
right
here
you
can
see.
I
say
some
policy
engine
require
signed,
containers
and
then
a
whole
bunch
of
you
know
public
keys
for
these
signatures.
This
is
pseudo
code.
A
I
will
discuss
more
about
how
to
configure
your
policy
engine
later
at
the
cluster
level,
but
just
know
that,
for
now
you
want
to
make
sure
that
your
containers
do
have
a
trusted.
Signature
pipeline
set
up
for
them:
okay,
so
that
was
container
just
as
a
recap,
assume
you'll
be
owned,
use,
distrolus,
rebuild
your
containers
or
make
them
easy
to
rebuild
and
redeploy
and
sign
all
your
containers.
A
Now
what
about
at
the
pod
level?
So
at
the
pod
level,
I'm
going
to
be
giving
all
kinds
of
recommendations
that
concern
the
pod
spec,
which
is
used
all
over
the
place
and
these
tips
all
apply
there.
So
obviously,
in
your
pods,
you
have
a
pod
spec,
but
also
in
your
daemon
sets
and
jobs
and
cron
jobs
and
replica
sets
and
staple
sets
and
any
other
kubernetes
resource
that
might
want
a
pod
spec.
A
It's
these
tips
apply
and
here's
the
pot
spec
reference.
If
you
want
to
pause
and
go
read
the
fields,
there's
a
bitly
link,
so
number
one
don't
use
host
path.
This
might
seem
convenient
because
it
basically
takes
your
container
and
it
gives
it
a
little
window
into
the
node's
file
system.
You
give
it
a
directory
in
the
nodes
file
system
and
your
container
can
mount
that
directory
and
can
the
contents-
and
maybe
you
have
a
key
there
or
config
there.
It's
it's
convenient.
A
It's
a
nice
place
to
just
have
those
files
that
you
need
to
load
in
at
runtime,
but
it's
it's
sort
of
a
very
risky
trojan
horse.
You're
you're,
an
you're
setting
up
for
yourself
where
you
don't
know
where
that
file
system
is
gonna,
be
some
time
from
now
right.
You
don't,
you
can
see
all
the
subfolders.
A
Maybe
the
file
system
is
editable
by
a
whole
bunch
of
other
pods
and
other
services.
So
it's
pretty
risky.
It's
it's.
A
an
attacker
can
explore
this
file
system
and
pull
out
all
kinds
of
sensitive.
So
what
does
it
look
like
in
code?
It's
under
it's
a
volume
field.
So
in
your
pod
definition
you
would
here's
a
very
simple
example.
A
You
can
see
it
just
pulls
in
basic
container
image,
and
then
it
mounts
a
volume
we
define
called
key
volume
and
all
keys
volume
is,
is
host
path
to
some
made
up
directory
in
this
case,
etc.
Pod
data-
and
you
know-
maybe
you
did
just
barely
make
this
folder.
You
only
put
a
config
file
in
there.
You
trust
it.
You
know
it's
not
very
scary.
Right
now,
but,
like
I
said
earlier,
what
about
a
year
from
now,
do
all
of
your
other
developers
know
not
to
reuse
this
pod
data
folder?
A
Will
other
pods
start
to
like
put
all
kinds
of
crap
in
the
in
the
pod
data
folder
there's
just
a
zillion,
better
ways
to
do
this.
So
don't
do
it
use
secrets
or
something
like
that
which
we'll
discuss
later
number
two
don't
use
host
network,
and
this
is
pretty
similar.
It
ties
your
container's
network
into
the
nodes
network,
so
local
host
on
the
node
is
localhost
on
the
container.
It
shares
the
same
port
range.
A
Some
people
do
it,
because
it's
kind
of
convenient
for
your
container
to
network
to
other
sort
of
things
on
the
node,
but
it's
super
risky.
So
in
this
case
the
container
can,
through
localhost
ping.
You
know
the
ssh
server
on
the
node
or
the
various
kubernetes
services,
and
so
can
an
attacker
who
owns
your
container
and
the
problem.
A
The
biggest
problem
here
is
localhost
is
kind
of
treated
like
a
trust
domain
like
things
running
on
localhost
on
the
node
are
trusted
sort
of
system,
infrastructure,
level
services,
not
arbitrary,
kubernetes
workloads,
so
things
like
the
cubelet
provide
some
level
of
trust
for
api
requests
coming
to
it
from
localhost
which
an
attacker
might
exploit,
so
don't
use
host
network,
it's
just
a
field
on
the
pod
spec.
So
in
code.
Here's
another
pod
example
where
this
pod
has
host
network
set
to
true
and
it's
bound
to
the
four
fours
port.
A
Just
don't
include
this
line.
If
you
are
using
it,
you
should
really
look
into
other
networking
alternatives,
see
if
it's
actually
something
you
need
or
if
it
was
just
set
there
arbitrarily
make
sure
it's
not
enabled
number
three,
and
this
is
something
that
a
lot
of
people
probably
overlook,
which
is
to
be
conscious
of
your
pods
service
account.
A
So
here's
a
super,
simple
pod
spec.
All
it
has
is
a
container
image,
a
path
and
a
name
is
there,
you
know.
Is
there
a
concern
about
security
or
service
account
credentials
bound
to
this
pod?
Are
there
credentials
loaded
in
it
or
do
we
have
any
sort
of
concerns
like
that?
It
doesn't
look
like
it.
It's
a
very
simple
pod.
Well,
the
answer
is
yes:
every
pod
is
bound
to
a
service
account
whether
you
like
it
or
not.
If
no
service
account
is
specified,
the
default
service
account
is
bound
which
is
named
default.
A
At
this
path
under
secrets,
which
an
attacker
who
owns
this
container
now
has
access
to
act
as
and
ping
your
api
server
and
perform
all
kinds
of
malicious
requests,
and
you
know
such
a
simple
pod
spec
like
this
might
be
running
something
you
don't
even
trust
that
much
it's
just
a
test
app
that
might
be
buggy.
So
it's
really
something
to
be
aware
of.
On
the
bright
side,
the
default
service
account
usually
isn't
bound
to
anything
by
default.
A
A
It's
brand
new,
it
doesn't
have
any
permissions
bound
to
it
and
we
kind
of
like
trust,
that
it
is
blank
or
it
has
only
the
bare
amount
of
permissions
needed
better,
yet
put
the
pod
in
a
different
name
space.
So
this
time
I
put
the
pod
in
its
own
dedicated
namespace,
which
is
just
a
best
practice
regardless,
because
namespaces
are
a
really
great
security
isolation
in
our
back
or
chances
are.
This
will
work
for.
Basically,
you
and
all
of
your
workloads
is
to
just
turn
off
service
account
token
mounting
this
field.
A
Auto
mount
service
account
token.
Is
that
path
I
showed
you
earlier
and
if
you
set
this
to
false
those
tokens
to
act
as
that
service
account
will
not
be
in
the
file
system,
and
that
means
that
you
know
the
workload
in
the
pod
can't
talk
to
the
api
server,
but
chances
are,
it
doesn't
need
to
your
your
web
server
or
your
api
server
doesn't
need
to
talk
to
the
kubernetes
control
plane
and
make
configuration
changes
or
anything
like
that.
A
I
would
bet
that,
for
99
of
your
workloads,
you
can
go
and
copy
paste
this
config
to
all
of
your
pod
specs.
If
you
want
to
learn
more
here's,
a
bitly
link
again
pause,
go
read
for
yourself.
Whatever
recap
at
the
pod
level:
don't
use
host
path,
don't
use
host
network
and
pay
really
close
attention
to
your
pods
service
account,
okay,
so
that
was
the
sort
of
workload
security.
Now,
let's
talk
about
cluster
security.
A
Here
you
are,
you
did
great
with
your
workload
now
you're
responsible
for
sort
of
securing
up
bits
of
your
actual
cluster.
You
are
standing
in
front
of
it
wondering
what
to
do
number
one,
this
one's
a
no-brainer,
keep
your
cluster
up
to
date.
Bugs
and
vulnerabilities
are
fixed
all
the
time,
and
that
might
sound
obvious,
but
you
probably
relate
to
this
character,
who
has
maybe
a
116-0
cluster.
They
got
it
up
and
running,
it's
working,
fine
for
them
and
they
really
don't
want
to
rock
the
boat.
A
And
while
I
can
relate
to
that,
you
know,
updating
things
is
scary
and
sort
of
might
require
rolling
updates,
and
things
like
that
consider
this,
since
the
116-0
release
there
have
been
174
bug
fix
prs,
not
even
just
pr's
total
into
that
release
branch.
The
latest
patch
version
is
116
14.,
so
you
should
be
updating
your
cluster
to
the
latest
patch
version.
At
the
very
least,
and
if
you're
curious
about
those
pr's,
you
can
go
to
this
bitly
link.
Updating
patch
versions
should
be
minimally
intrusive.
A
You
shouldn't
have
any
compatibility
issues
and
it
is
a
very
strong
recommendation
number
two,
and
this
is
finally
to
the
title
of
the
talk
help
my
clusters
on
the
internet
well
isolate
your
cluster
from
the
internet.
Ideally,
your
entire
cluster
is
in
a
private
network
or
behind
an
auth
proxy.
It
doesn't
have
any
publicly
addressable
ips
to
either
control
plane,
components,
the
api
server
or
any
of
your
nodes.
A
There
should
be
no
way
for
someone
to
port
scan
or
just
hit
your
parts
of
your
cluster
by
just
an
ip,
and
you
might
wonder:
okay,
well,
that
sure
that's
more
secure.
But
now
my
cluster
is
not
very
useful.
It
can't
my
web
server
doesn't
work
and
my
devs
can't
do
anything.
So
what
are
some
solutions
to
those
problems?
Well,
obviously,
for
your
devs
and
bots,
you
can
log
them
into
the
network,
bring
them
into
your
vpn.
A
A
You
put
some
sort
of
public
load,
balancing
layer
that
has
public
ips,
that
customers
can
access
and
then
those
will
forward
valid
traffic
within
your
vpn
onto
the
nodes,
and
they
can
also
have
good
properties
like
they
can
provide
dos
protection
or
block
random
garbage
nonsense.
Requests
that
don't
match
sort
of
urls
or
another
concern
might
be
that
your
cluster
needs
internet
access.
Your
cluster
needs
to
go
download,
configs
or
images
or
something
in
this
case.
You
again,
you
can
just
configure
your
network
to
allow
egress
access
and
better.
A
A
They're
never
saved
on
disk
to
the
node
or
they
are
stored
in
memory,
but
never
saved
on
disk
to
a
node
they're
only
ever
stored
on
disk
in
scd,
which
you
can
encrypt
they're
loaded
as
needed.
So
nodes
can't
request
secrets
unless
their
pods
scheduled
on
them
request
those
secrets
they're
super
easy
to
set
up
authorization
policy,
which
is
great.
The
only
downside
is
they
are
limited
to
one
megabyte.
A
There
really
should
just
be
used
for
keys
and
tokens
and
passwords,
and
not
for
all
your
configs
ever
you
can
use
other
stuff
like
configmaps
or
other
larger,
more
permanent
storage.
For
those.
If
you
want
to
read
more
on
secrets,
pause,
here's
a
bitly
link
for
you,
quick
example
of
what
loading
a
secret
into
your
pod
might
look
like.
Let's
say
you
have
some
file
that
used
to
be
on
your
node
naively
or
it's
on
a
dev
workstation.
A
A
That
would
create
an
api
object
with
just
that
namespace,
that
name
and
then
a
base64,
encoded
secret
and
then
in
our
pod
spec.
We
simply
reference
it
in
a
volume,
so
we
would
mount
a
new
volume.
We
call,
let's
say
keys,
but
it
can
be
anything
obviously
and
we
reference
that
secret
name
and
since
the
namespace
is
a
line
that
secret
will
be
loaded
into
the
pod
at
that
directory
that
we
told
it
to
which
is
just
great
super,
convenient
super
easy
to
use
and
also
much
more
secure.
A
So
recap
at
the
cluster
level:
keep
your
clusters
up
to
date,
isolate
your
cluster
from
the
internet
and
use
secrets
for
the
node.
I
just
repeat:
isolate
your
nodes
from
the
internet
too.
That's
great!
You
want
to
isolate
the
whole
cluster
from
the
internet
user
security.
So
here
you
are
here's
your
dev
team.
You
did
such
a
great
job
with
the
cluster.
Now
your
company's
got
a
whole
bunch
of
new
engineers
and
you
need
to
make
sure
that
they
are
while
they're
uploading,
all
their
workloads
and
making
amazing
products.
A
They
are
not
doing
anything
to
compromise
the
security
of
your
so
number.
One
use
rbac
and
use
groups
with
our
back,
hopefully
you're,
all
familiar
with
rbac
you're,
using
rbac
to
control
authorization
policy
within
your
cluster.
If
you
aren't
familiar
with
rbac
just
it's
the
authorization
engine
built
into
all
kubernetes
clusters,
it
has
subjects
like
your
your
engineers
and
your
robots
and
your
service
accounts.
It
has
roles
that
grant
permission
like
the
git
pod
and
create
pod
and
delete
secret,
and
then
it
has
bindings
between
the
two.
A
So
just
here's
an
example
of
what
some
our
back
organizational
structure
might
look
like.
Here's
all
your
subjects,
your
organization
has
six
engineers
and
and
two
robots.
Let's
say
two
service
accounts.
These
all
these
engineers
have
different
sort
of
roles
within
companies.
Some
are
sres,
some
are
swees,
some
are
security
engineers,
and
so
you
define
out
all
these
different
roles
within
our
back
to
sort
of
provide
least
privilege
for
all
these
subjects.
You've
got
admins
in
some
namespace.
A
You've
got
readers
and
figuration
roles
and
all
that
and
then
you
would
go
through
all
of
your
different
engineers
or
all
of
your
different
employees
and
grant
them
different
role
bindings
to
these
sort
of
least
privileged
roles
that
you
might
need
to
accomplish
their
job,
and
at
this
point
all
of
these
arrows
represent
the
role
bindings,
and
at
this
point
you
know
you're
in
a
pretty
good
place.
All
of
your
subjects
have
access
to
the
things
they
need.
Hopefully
they
aren't
over
privileged.
A
If
you
gave
your
role,
some
good
thought
and
thought
about
the
bindings
in
a
smart
way,
everything's
in
a
relatively
safe
and
secure
place
right
here
relatively,
but
the
problem
happens
is
what
happens.
You
know
some
weeks
or
months
or
years
from
now
when,
let's
say
bob
quits
and
dave
and
emily
switch
roles
and
your
cicd
platform
is
recreated
with
a
new
identity
and
new
requirements
from
the
permission
system.
What
do
we
do
now?
A
This
often
leads
to
some
pretty
terrible,
like
authorization,
decay
of
all
these
bindings,
where
things
get
really
messy
and
suddenly
some
employee
that
quit
a
year
ago,
has
super
user
on
your
cluster
and
nobody
knew
it
right
and
that
access
was
never
revoked.
So
what's
a
better
way
to
think
about
this
and
that's
and
that's
to
use
groups.
So
again
we
have
our
roles
we
defined
from
the
previous
slide.
These
are
again
just
toy
rolls.
A
You
can
do
whatever
works
best
for
you,
but
instead
of
going
directly
to
subjects
we
create
groups
for
each
of
the
sort
of
different
responsibilities
within
your
organization.
So
say
you
have
sres
and
then
you
just
have
engineering
and
you
have
ci
cd
for
like
deployment,
and
you
have
a
security
group
for
performing
audits
or
something
you
can
spend
a
lot
of
time
and
thought
finding
creating
bindings
between
these
root.
These
groups
and
roles
in
a
way
that
you
feel
is
is
very
secure.
A
They
can
be
ephemeral,
it's
easy
to
take
a
user
out
of
a
group
and
put
them
in
a
different
group
when
they
change
roles
and
the
memberships
can
constantly
be
worked
on,
while
the
groups
to
roles
binding
is
like
rock
solid.
So
one
last
one
thing
to
note,
though,
is
that,
while
our
back,
you
know
you
can
create
bindings
to
groups,
groups
are
typically
at
your
organization
on
how
they're
actually
implemented.
Maybe
it's
google
groups-
maybe
it's
some
microsoft
group
thing.
A
If
you
want
to
read
about
rbac,
there's
stuff
about
groups
in
there,
there's
bitly
link,
if
you
want
to
read
about
the
api
spec
on
all
the
different
fields
in
rvac
again,
another
bitly
link
pause
go
here,
so
my
final
tip
and
this
one's
super
huge
and
super
amazing-
is
to
use
a
policy
agent
to
protect
your
cluster
typically
or
what
is
a
policy
agent?
Typically,
it
is
a
kubernetes
admission
controller
which
selectively
allows
or
denies
kubernetes
resource
requests
based
on
rules
or
policies.
So
that
was
a
super
heavy
sentence.
A
You
probably
fell
asleep
halfway
through
it.
Let
me
try
and
explain
with
what
what
these
things
do
with
an
analogy
so
think
about
an
airport
or
a
ball
game,
these
foreign
concepts
that
you
may
or
may
not
have
forgotten
about
in
this
pandemic
world.
When
you
arrive
at
these
places.
First,
you
go
to
like
the
ticket
agent,
the
guy
on
the
left.
Who
would
check
your
identity?
You
would
check
your
ticket
make
sure
you
have
like
a
right
to
proceed
or
right
to
go
forward.
A
You
can
you
know
you
could
proceed
and
then,
even
after
that
check,
you
still
have
to
walk
through
a
metal
detector.
You
might
have
to
put
your
bag
through
a
scanner
and
these
scanners
enforce
policies
like
no
alcohol,
you
know
a
check
for
weapons
and
metal
and
no
full
12
ounce
things
a
toothpaste.
Those
are
super
dangerous,
as
we
all
know,
and
so
in
this
analogy
on
the
left,
the
ticket
agent
is
kind
of
like
our
back.
A
A
So
the
the
scanners
are
like
the
admission
controllers
and
you
can
set
them
up
for
your
cluster
so
rather
than
checking
for
alcohol
or
weapons
or
toothpaste,
they
can
enforce
all
kinds
of
best
practices
within
your
cluster
that
we've
been
discussing
throughout
these
slides
host
path
host
network,
they
can,
you
can
set
policy
on
service
accounts
images,
urls
keys
are
back
labels,
you
can
require
owner
labels
and
there's
just
a
zillion
billion
cool
features.
If
you
that
you
can
set
up,
they
also
can
audit
the
existing
resources
within
your
cluster.
A
A
Probably
I
think
it's
got
the
most
stars
on
that
screenshot.
It's
super
easy
plug
and
play.
If
you
want
to
read
about
it,
there's
a
bitly
link
so
think
back
15
minutes
ago,
to
this
slide,
where
you
have
your
kubernetes
cluster
admitting
or
denying
certain
containers
with
some
pseudo
code
policy
engine.
So,
what's
actually
going
on
behind
the
scenes,
it's
these
container
specs
are
being
passed
through
your
admission
control
and
one
of
those
admission
controllers
is
opa
gatekeeper.
A
A
So
as
a
recap
for
your
developers
in
automation,
use
rbac
and
groups
use
a
policy
agent
to
protect
your
cluster
hooray.
So
your
workloads,
cluster
and
developer
are
enjoying
a
much
more
secure,
kubernetes
experience.
You
are
recognized
for
your
efforts
and
compensated
handsomely.
You're
filled
with
a
sense
of
satisfaction
there.
You
are
with
your
pile
of
money
and
your
happy
kubernetes
cluster.
So
that's
awesome.
A
So
before
we
go
to
questions
just
real
quick
epilogue
here,
I
know
that
was
a
lot
that
was
a
wall
of
information
that
was
like
20
plus
tips.
Maybe
you
took
good
notes,
you're,
probably
not
gonna.
Remember
it
all
the
bright
side.
I
made
a
dock.
So
all
the
tips
and
tricks
tricks
from
this
from
this,
these
slides
lots
of
links
all
the
lots
of
reading.
If
you
want
to
read
more
and
learn
more
plus
a
ton
of
other
stuff
not
covered,
I
had
to
cut
so
much
out
of
this
slide.
A
A
Okay,
any
questions
all
right,
ending
the
recording!
Here
we
go.
How
do
I
end
the
recording?
Stop
hi?
It's
me:
it's
sam,
I'm
a
little
sleepier,
because
it's
early
early
in
the
morning
than
I
was
in
that
video
but
hello.
I've
been
watching
my
recording
with
all
of
you
and
reading
through
tons
of
q,
a
there's,
a
bunch
of
questions
about
slides,
I'm.
I
know
that
this
is.
This
is
all
being
recorded.
It's
going
to
be
on
the
youtube
and
I
think
the
slides
might
be
available
too.
A
I'm
not
sure,
but
also
check
out
that
link.
I
suggested
at
the
end
this
sam
kdes
security
or
sam
k8s
sec
sec
sec,
but
let
me
just
try
and
burn
through
some
questions
here.
There
are
a
ton
of
questions,
a
lot
of
which,
frankly
I
don't
know.
The
answer
to
this
is
a
huge
problem
space
I
kind
of
on
learned.
A
I
had
my
knowledge
and
some
knowledge
of
my
team
and
we
all
sort
of
put
it
together
into
the
slide
deck
and
there's
a
ton
of
really
excellent
questions
in
here
that
I
don't
know
the
answer
to
so.
If
I
don't
get
to
them
google's
your
friend
feel
free
to
ask
questions
in
the
doc
and
I'll
try
and
find
answers
for
you
asynchronously.
A
But
first
question
is
basically
saying
is
asking
about
signatures
that
I
have
here.
It's
like
what
what
happens
if
poisoned
images
are
signed
like
what's
protecting
your
cluster
from
a
signed,
malicious
image
and
that's
a
great
question
like
the
idea
is
that
we
want
to.
We
want
to
only
give
signing
keys
to
trusted
building
platforms
so,
like
we
have
our
cscd
platform
that
engineers
can't
really
touch
like
someone
configured
it.
It
has
private
keys
and
that's
that's
our
sort
of
last
hope.
A
It
trust
so
that
cicd
platform
does
run
all
its
tests
and
and
phone
scans
and
everything
and
attaches
its
signature
and
sure
if,
if
our
trusted,
ci
cd
platform
does
build
a
poisoned
image,
we're
in
a
rough
place,
but
hopefully
we've
configured
it
that
it
only.
You
know
it
only
allows
itself
to
pull
from
trusted
like
base
images.
A
A
Come
up
a
whole
bunch
and
they're
great
questions,
because
yeah
there's
these
fields
that
I
say
don't
use,
are
used
all
the
time
by
a
whole
bunch
of
different
pieces
of
software,
so
they
exist
for
a
reason,
and
so
this
to
answer
this
question
as
well,
as
I
think,
a
whole
bunch
of
others
is,
there
are
probably
a
ton
of
amazing
software
or
amazing,
like
plugins,
for
your
cluster.
That
does
use
these
fields
and
it's
probably
perfectly
safe.
A
A
Maybe
I
should
have
ordered
it
like
that
in
my
talk
really
think
about
it,
sometimes
they're
more
convenient
to
to
sort
of
like
plug
your
container
into
your
network
or
the
file
system,
but
it's
just
it's
really
risky
so
and
there's
tons
of
better,
more
secure
by
default
ways
to
sort
of
achieve
your
goals.
So
that's
sort
of
what
I
have
to
say
about
that.
A
Second,
another
highlighted
question
I
had
was
again
about
host
network.
It
was
asking
about
the
like
cpu
consumption
of
not
using
host
network.
Frankly,
I
don't
know
anything
about
that.
There
are
tons
of
caveats
and,
if
cpu,
if
this
is
a
real
thing,
then
maybe
you
need
to
use
host
network
again.
These
are
all
suggestions.
These
aren't
the
one.
This
isn't
the
100
secure
like
follow
these
rules
and
you're
secure.
That's
that's
not
what
I'm
promising
here.
A
These
are
just
a
whole
bunch
of
of
you,
hopefully
useful
suggestions
that
you
can
use
on
your
personal
cluster
in
your
organization.
Another
great
question
is:
are
secrets
secured
enough?
Aren't
they
just
base64
hashed
yeah?
That
is
a
concern.
Some
people,
some
I've,
read
in
a
like
official
kubernetes
book
that
secrets
are
encrypted
by
default.
They
are
not.
They
are
base64
encoded
and
saved
to
etcd
in
base64
encoded.
A
A
You
know
you
can
set
really
strong
authorization
policy
on
all
of
them
and
they're
like
hard
to
get
access
to
sure.
If
an
attacker
gets
access
to
the
lcd
disc,
like
the
the
actual
storage
of
ncd,
then
you're
in
a
rough
place
for
a
lot
of
reasons
and
yeah,
they
would
be
able
to
read
secrets
so,
but
writing
really
good
authorization
policy
against
your
secrets
is
really
the
benefit
and
yeah.
A
A
I
just
did
a
quick
google
search
and
yeah
like
digitalist,
doesn't
have
a
default
published
alpine
image,
which
I
thought
was
interesting.
I
don't,
I
would
need
to
research
in
more
into
it.
I
might
post
it
in
my
doc
again
bitlydoc
bit
dot
lee
sam
k8s
sec
scc
with
pascal
casing.
I
don't
know
the
answer
to
that,
but
it's
a
good
question
distralis
is
preferred.
That's
another
question.
A
Why
is
digital
is
preferred
is
like
I
said
in
the
talk
it's
it's
got,
a
very
tiny
attack
surface
no
package
manager,
which
is
something
I
didn't
bring
up.
So
you
you
know
if
your
workload
gets
owned,
they
can't
run
like
apt
get.
You
know
huge
network
scanning
data,
exfiltration
tool
install
you
know.
So
that's
an
it's
again.
Just
small
attack
surface,
let's
see,
there's
some
questions
about
how
to
test
cves
in
already
running
images.
A
I
don't
know
if
I
totally
understand
that
question,
but
I
think
what
it's
I
think
basically
is
as
far
as
my
understanding
on
how
to
check
for
cdes
is
a
volts
of
the
way
a
bone
scanning
tool
works.
Is
it
basically
just
checks,
the
base,
images
and
all
of
the
packages
that
pulled
in
against
a
giant
map
of
known
vulnerabilities
and
checks?
If
there
are
any
cvs
associated
with
it,
so
you
could
run
a
bone
scanner
on
a
running
container
and
get
probably
a
pretty
authoritative
set
of
known
cvs.
A
There
were
some
questions
about
the
software
image.
I
did
a
bunch
of
screenshots
from
the
cncf
landscape
with
like
opa
gatekeeper
and
a
bunch
of
cicd
platforms.
Those
screenshots
were
not
an
exhaustive
list
of
solutions
for
that
someone
was
asking
about
an
azure
cicd
platform.
I'm
sure
that
azure
platform
is
excellent
and
if
it
works
great
for
you
use
it
and
there's
there's
other
like
there's
google
ones,
I
didn't
put
right
so
the
one
the
images
I
posted
were
just
the
open
source
ones.
A
I
kind
of
like
was
biasing
towards
showing
off
all
the
cool
open
source
ones
like
opa,
gatekeepers,
totally
open
source
but
they're,
I'm
sure
they're
super
amazing
policy
engines,
they're
super
amazing
cxcd
platforms
that
are
not
open
source
that
maybe
you're
already
using
or
would
be
a
best
fit
for
you.
So
that's
the
end
of
that
answer.
To
that.
I'm
just
gonna
keep
running.
I
don't
know
when
I'm
gonna
be
cut
off,
but
there
are
like
200
300
questions
and
I've
answered
like
six.
A
So
if
I
don't
get
to
your
question
again,
maybe
post
it
in
the
the
the
doc
sam
bitly
dot
bit
dot
le
slash
sam
k8s
sec.
Let's
see,
what's
another
good
question,
there's
some
questions
about
using
scratch
versus
distralis.
I
that's
that's
a
space,
I'm
just
not
super
familiar
with.
I
haven't
used
scratch
very
much.
Maybe
maybe
scratch
is
better.
I
know
I'm
pretty
sure.
Scratch
is
like
a
super
bare
bone
space
image
too.
So
distrolus
is
not
the
only
super
bare
bones
base
image.
A
Okay,
so
here's
a
question
that
says
nice
approach
to
signing
binaries
after
each
step,
but
do
you
have
a
practical
solution
in
mind?
I
can't
find
a
solution
to
that.
Oh,
I
see
okay,
so
I
think
he's
asked
this
person's
asking
like
what
is
an
actual
like
piece
of
ci
cd
software
that'll.
Do
that
for
you
and
I
would
wager
that
most
do
that
it's
based
any.
A
I
feel
like
most
it's
just
most
ci
cd
platform
probably
has
like
phases
that
you
can
set
up
for
your
release
and
yet
for
each
phase,
you
I'm
sure
you
can
say
like
perform.
A
volt
scan
run
this
phone
scan
tool.
If
you
know,
if
it
didn't
return,
an
error
run
a
little
crypto
signature
on
the
image
right
to
the
next
phase.
I
don't
actually
know
exactly
how
they
work,
but
I'm
sure
there
are
a
lot
of
ways
to
do
it.
A
A
What
is
the
reason
that
auto
mount
service
account
token
is
not
set
to
false
by
default.
That's
a
great
question.
I
don't
know
the
actually
the
kubernetes
stocks
right
now.
I
had
to
double
check
that
during
this
talk,
they
do
not
specify
whether
it
is
set
to
false
by
default.
I'm
pretty
sure
it's
not
because
they
kind
of
assume.
A
A
Okay,
I
have
two
more
minutes
there
we
go
now.
I
know
how
much
longer
I've
got.
Let's
see,
I
kind
of
there
are
so
many
questions,
so
I'm
I
again.
If
I
don't
get
to
your
question,
I'm
sorry,
let's
see,
is
using
allowed
host
paths
considered
secure.
This
is
when
I
I
saw
when
the
talk
was
going
on.
This
is
a
great
question.
I
didn't
know
about
this
field.
Maybe
the
talk
implies.
A
A
I
think
from
my
understanding
some
people
on
my
team
who
used
to
like
kind
of
pioneer
the
pod
security
policy
stuff,
it's
kind
of
being
deprecated
in
favor
of
policy
agents
like
opa
gatekeeper,
but
a
pod
security
policy
is
basically
yeah
a
policy,
a
sort
of
kubernetes
native
built-in
policy
agent.
Where
you
can
tell
you
can
tell
your
pods,
but
you
can.
A
You
can
specify
that,
like
your
pod
spike,
can't
can't
be
certain
things
like
it
can
include
certain
host
paths,
so
there's
probably
a
world
where,
for
whatever
reason
in
your
organization's
infrastructure,
your
organization's
computers
that
ne
you
really
need
to
mount
a
host
path
like
a
very
specific
trusted
host
path
like
path
on
the
host
which
is
sort
of
host,
and
you
would
use
like
a
pods
pod
security
policy,
spec
or
a
gatekeeper
spec.
To
say
this
is
the
only
allowed
host
path.
I
talk
briefly
on
pod
security
policy.
A
I
believe
in
my
supporting
doc.
That
is
a
summary
of
this
chat.
Also
in
that
doc
I
kind
of
structured
it,
so
you
can
make
a
copy
and
then
you
can
run
through
all
the
bullet
on
to
all
the
tips
and
then
basically
say
like
this
is
great
I
applied
with
my
cluster.
This
is
not
applicable.
This
doesn't
make
any
sense
for
me
ignoring
it.
So
hopefully
it's
like
a
big
checklist
for
you
that
you
can
either
try
and
see
if
it
works
for
you
or
ignore
it.
A
Let's
see
if
I
can
just
read
one
more
question
here
again:
lots
of
links,
lots
of
questions
about
getting
access
to
the
slides.
I
don't
know
if
the
slides
themselves
will
be
published,
but
the
talk
certainly
will
and
you
can
pause
and
fast
forward
and
all
that,
but
the
slides
might
be
published
too.
I
don't
know
here's
a
good
one
that
says
cluster
update
upgrade
is
a
tedious
task.
How
can
we
best
automate
this
with
minimal
change?
That's
a
super
great
question
that,
frankly,
I
don't
know
the
answer
to.
A
I
have
worked
mostly
on
gke
and
I
guess
this
is
a
benefit
of
managed.
Kubernetes
platforms.
Is
you
like
click
a
button
or
you
make
an
api
call
that
says
upgrade
to
latest
version
upgrade
to
version
foo
and
your
cluster
spins,
and
you
know
all
of
the
engineer.
All
the
engineering
work
has
already
been
done
by
the
google
engineers
or
your
azure
engineers
or
whatever,
and
your
cluster
is
now
on
the
latest
version.
A
I
don't
know
what
the
best
way
to
automate
cluster
upgrades,
but
I
would
bet
that
that
is
a
super
super
common
google
search.
I
would
that's
probably
a
cluster
management
101
that
you
there's
tons
of
software
for
or
tons
of
best
practices,
tons
of
blog
posts.
So
if
I
didn't
answer
your
question
and
it
didn't,
it
doesn't
sound
like.
I
know
what
I'm
even
saying,
which
could
possibly
be
true.
Just
google
it
and
I
pray
for
you
that
you
will
find
the
answers
that
you
desire.
A
Let's
see,
I
don't
know
if
I
have
any
more
time:
oh,
okay!
Well,
I'm
about
to
wrap
up.
One
last
question
is
just
that
like
this
was
going
too
fast.
I
wasn't
able
to
absorb
it
all,
and
I
did
acknowledge
that
at
the
end
of
the
slide
I
it
was
a
dense,
dense
slide.
So
go
to
my
supporting
doc
bitly
bit
dot
lee
sam
kds
sec,
where
you
can
learn
more
okay,
so
I'm
gonna
wrap
up,
see
ya,
you're
great.