►
From YouTube: Building for Trust: How to Secure Your Kubernetes Cluster [I] - Alexander Mohr & Jess Frazelle
Description
Building for Trust: How to Secure Your Kubernetes Cluster [I] - Alexander Mohr & Jess Frazelle, Google
This talk will cover all the ways you can secure your Kubernetes cluster using a Certificate Authority, Authentication, Secrets and more. We will also describe and demo the ways you can use Seccomp, Apparmor, SELinux and cgroups to make your application containers as secure as possible.
About Jess Frazelle
Jess Frazelle is a Software Engineer at Google. She has been a maintainer of Docker, contributor to RunC, Kubernetes and Golang as well as other projects. She loves all things involving Linux namespaces and cgroups and is probably most well known for running desktop applications in containers. She maintained the AppArmor, Seccomp, and SELinux bits in Docker and is quite familiar with locking down containers.
About Alex Mohr
Alex is currently the Technical Lead and Manager of Google Seattle's Kubernetes and Container Engine teams. Previously, he was Engineering Lead for Google Compute Engine's initial public launch, and also lead the design and launch of its VM instance manager subsystem.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
thank
you
all
for
coming
hope.
You
appreciate
the
the
room
today,
it's
great
to
see
all
of
you
I'm,
sorry,
it's
so
packed,
so
my
name
is
alex
moore
with
me
as
Jeff's
Frizzell.
We're
gonna
talk
to
you
about
building
for
trust,
how
to
secure
your
kubernetes
cluster.
Of
course,
this
isn't
a
promise
that
if
you
follow
all
these
steps,
you
will
be
perfectly
secure
and
never
rooted.
Hopefully
these
will
inform
some
of
the
decisions
you
make
as
part
of
your
kind
of
holistic
security
policy.
A
So
let's
get
started
with
some
intros
Jess
here,
maybe
some
of
you
saw
her
wonderful
talk.
Yesterday
she
talked
about
some
of
the
security
disclosure
and
handling
process
that
we've
built
for
kubernetes.
She
built
it
all
with
Brandon
lots
of
it.
At
least
she
used
to
work
at
docker
and
did
a
lot
of
the
work
for
sec,
comp
that
she'll
demo
today
and
some
of
that,
and
we're
really
happy
to
have
a
right,
kupo
cloud
and.
B
B
So
what
we're
gonna
be
talking
about
today,
just
as
a
brief
overview,
security,
boundaries,
identity
and
access
management,
runtime
security
and
a
demo
and
then
a
security
roadmap.
So
if
you're
like
just
now
figuring
out
that
you're
in
the
wrong
talk,
you're,
probably
stuck
and
I'm
sorry,
so
good
luck,
so
we'll
start
off
with
the
security
boundaries.
So
we
have
like
various
different
security
models.
B
So
this
is
today
where
you're
you
know,
entire
cluster
is
your
trust
boundary.
So
all
authorization
permissions
are
for
your
entire
cluster.
All
nodes
have
the
same
identity:
all
pods
have
the
same
authorization,
permissions
and
all
pods
have
the
network
access.
So
this
is
kind
of
like
where
you
trust
team,
one
and
Team
two
to
be
on
the
same
cluster,
because
you
know
that
they
aren't
going
to
mess
with
each
other.
B
But
if
you
didn't,
then
you
should
really
give
the
other
team
another
cluster,
just
so
that
they
don't
interact
with
each
other,
since
there
really
is
no
control
between
the
two.
In
the
future,
though,
this
is
kind
of
what
it's
going
to
look
like,
where
the
names
force,
namespace
and
resource
are
boundaries.
So
this
way
that
you,
instead
of
spinning
up
a
different
cluster
14-2,
if
you
wanted
to
you,
could
actually
just
put
them
in
a
different
name
space,
and
then
your
boundary
would
be
the
namespace
there
and
not
the
entire
cluster.
B
So
you'd
have
your
permissions
granted
at
the
namespace
level,
rather
than
the
entire
cluster
and
nodes
would
have
individual
permissions
and
fine-grained
permissions
between
teams
and
such
and
the
network.
Access
could
be
restrained
between
the
two,
which
is
great
so
now,
I'm
gonna,
pass
it
back
to
Alex
to
go
or
Identity
and
Access
Management
thanks.
A
Jess
so
I
guess
before
I
get
into
the
details,
will
briefly
cover
here:
authentication
like
who
you
are
and
talk
about,
the
three
different
components:
users,
the
system,
components
and
your
workloads,
we'll
talk
about
authorization
and
I'll
talk
a
little
bit
about
our
back.
That's
been
landing
with
1-6
talked
a
little
bit
about
auditing
and
then
close
with
some
secrets
bits
so
user
authentication.
This
is,
who
are
you?
The
users
of
your
cluster
and
kubernetes
comes
with
many
modules
that
you
can
choose
to
use,
whichever
set
of
them
work
for
you,
there's
basic
HTTP
off.
A
We
have
static
bearer
tokens,
x.509,
client,
certs.
The
service
accounts
get
these
tokens
that
are
automatically
created
and
managed
for
you
and
then
there's
an
open
ID
connect
if
you're
interested
in
something
like
an
OAuth
2
flow,
and
if
none
of
those
work
for
you,
you
can
only
build
your
own
custom
web
hook
provider
that
all
interface
with
something
else.
A
All
of
these
things
end
up
coming
in
the
authentication,
looks
at
the
the
credentials
that
you
pass
in
whatever
they
are,
and
the
output
is
a
username,
a
UID
and
an
optional
list
of
groups,
and
you
can
also
tag
it
with
a
little
bit
of
extra
metadata
if
you
need
to,
and
so
the
point
is
after
this
stage
has
passed.
If
the
credentials
are
there,
you
have
that
username,
usually
an
email
address,
and
then
the
authorization
flow
that
comes
later
can
look
and
say.
A
Ok,
given
that
identity
are
you
able
to
do
what
you're
asking
to
do,
but
we
don't
just
have
users,
we
also
have
system
components,
and
some
of
these
are
obvious,
like
the
nodes
in
the
system
need
to
be
able
to
talk
to
the
API
server.
Some
of
them
have
to
do
with
things
like
if
you
have
an
ingress
controller
running
around
the
cube
proxies
that
are
on
your
system
that
are
programming
the
network,
if
you're
using
that
particular
networking
plugin,
and
so
this
is
one
example
config.
A
This
happens
to
be
what
we
use
with
container
engine,
of
course,
you're
free
to
use
whatever
you
like,
and
so
in
this
case,
what
we
have
is
a
cluster
certificate
authority,
a
CA,
that's
the
orange
box,
and
we
take
that
and
we
sign
both
a
master
search
and
then
a
node,
cert
and
so
on
the
master.
Then
it's
plumbed
in
it
has
that
master
search.
It's
sitting
there.
A
Whenever
you
connect
to
it,
that's
the
the
thing
is
going
to
use
and
the
nodes
themselves
are
given
this
node
cert
in
order
to
use
they'll
talk
to
the
API
server,
and
so
then
we're
able
to
do
mutual
off
so
in
each
of
these
directions.
It's
bi-directional
communication
nodes,
verify
the
master
cert,
the
master
verifies
the
node
cert,
and
then
that
means
that,
for
example,
we
know
that
you're
coming
in-
and
this
is
the
identity
cubelet
in
the
system,
and
if
you
are
cubelet,
then
you
get
certain
permissions
by
the
authorizer.
A
The
third
pillar
of
authentication
are
service
accounts,
and
so
this
is
the
workloads
that
run.
If
you
have
a
pod
running
in
your
system-
and
this
could
be,
for
example,
the
ingress
controller,
it
could
be
if
you
wanted
to
run
your
controller
manager
in
the
system
that
could
also
potentially
be
using
this,
and
so
this
uses
kubernetes
service
accounts,
and
so
there
what
we
have
is
a
service
account
controller
and
it
signs
jobs
for
all
service
accounts
in
the
system,
and
then
those
John's
are
stored
as
secrets
in
the
kubernetes
api.
A
So
then,
when
you
create
a
pod,
you
can
say,
if
you
don't
say
anything,
you
get.
The
default
service
account
for
your
name
space
and
that
defaults
to
a
quote/unquote
default
name
service,
account
of
course,
you're
free
to
sub
you
in
something
else.
If
you
like,
and
then,
if
you
need
to
make
calls
to
that
API
server,
you
can
use
that
as
a
bearer
token,
and
you
get
the
permissions,
then
that
you
want
your
pod
to
have
so.
That's
authentication
that
tells
you
the
system
who
you
are
now.
A
A
We
suspect
that's
probably
going
to
become
the
primary
mechanism
going
forward.
So,
if
you're
interested
in
whether
that
meets
your
use
cases,
you
know
please
check
it
out,
try
it
out
file,
bugs
feature
requests
and
so
on.
If
it's
not
meeting
what
you
want,
we
probably
think
expect
a
back
to
go
away
at
some
point
in
the
future.
A
So
here's
the
basic
part
of
our
back
in
my
API
I've
got
these
pods,
and
so
this
is
the
pod
API
on
the
API.
Server
and
pods
have
a
whole
bunch
of
methods
on
them.
I'm
just
gonna
use,
get
and
list
for
examples
here.
So
I've
got
pods,
that's
one
resource
type,
getting
lists
or
different
API
calls
you
can
make
to
it.
So
how
do
I
create
a
auerbach
role?
A
So
that's
the
role
great
there's
a
permission
set
and
I
can
say.
If
you
are
a
pod
reader,
you
can
make
these
calls.
When
a
user
comes
along,
then
how
do
I
actually
take
that
user
and
say
this
user
should
be
able
to
do
those
things
and
that's
where
we
get
a
pod
reader
role
binding.
Basically,
it's
a
way
of
saying
this.
Particular
identity
is
able
to
act
as
a
pod
reader
role,
and
so
then,
when
your
authorization
come
sorry,
the
authenticated
user
comes
in.
A
We
look
at
that
identity
scan
through
the
authorizing
plugin
in
terms
of
our
back
look
at
all
of
the
binding
see
what's
available
and
if
it
gives
you
transitive
properties
to
get
this
get
and
list
access.
So
that's
the
basic
basic
one.
It
also
can
be
a
lot
more
complicated,
of
course.
So
here
what
I've
shaddid
is
a
node
pod
reader
role.
A
We
have
no
table
jects
as
well,
and
the
thing
they
also
have
get
enlist
in
various
other
methods,
so
I
could
create
a
node
pod
reader
role
and
that's
going
to
also
have
node
GATT
and
node
list.
It'll
also
have
pod
get
and
pod
list,
and
so
you
can
have
that
role
there
and,
of
course
it's
not
just
plain
users
that
I
can
have
that
get
these
bindings.
I
can
also
have
one
of
those
groups
that
my
users
may
be
part
of
have
a
role.
A
I
can
have
service
accounts
that
my
workloads
are
running
at
also
have
this
role
binding.
There
are
really
great
Doc's,
I
think
on
this
stuff
online.
You
know
feel
free
to
read
through
it.
It's
pretty
straightforward
if
you
find
it's
problem,
complain
loudly
so
that
talks
about
what
you
can
do,
the
other
part
of
it
is
given.
If
somebody's
doing
things
you
want
to
detect
it.
So
audit
logs
are
pretty
important.
Maybe
you
saw
Macias
talk
yesterday
on
auditing,
about
where
we
want
to
take
that
there's
a
lot
of
interest
from
various
enterprises.
A
Google
internally,
is
looking
to
use
kubernetes
more
and
more
internally,
and
so
we've
done
a
bunch
of
security
audits
internally
to
figure
out
like
what
are
those
gaps
between
what
we
wanted
to
have
and
what
it
currently
does.
So
we're
gonna
be
working
on
improving
these
things
over
time.
Right
now.
What
you
get
is
this
basic
audit
log
in
a
local
file
on
the
cube
API
server,
so
it's
only
logging
API
server
things,
and
it
includes
things
like
an
ID,
a
timestamp,
the
IP
address
the
user's
name,
namespace
URI,
and
in
a
separate
line.
A
The
response
code
so
the
way
it
works
is
it
logs
some
starting
to
process
requests
to
do
X
with
an
ID,
and
then
that
request
processes
and
at
some
point
it
finishes.
And
then
it
says
that
ID
that
you
can
use
to
correlate
the
two
had
this
particular
response
code,
but
simplifying
a
little
bit.
It
looks
something
like
you
know
at
time:
1
IP,
1,
Alice,
created
deployment,
foo
and
a
namespace
pass
and
so
on,
and
then,
finally,
that's
all
about
kubernetes
off
up
to
the
API
server.
What
if
I
have
things
that
aren't?
A
A
You
can
see
an
example
on
the
right
there
of
taking
the
admin
and
a
password
and
encoding
those
and
then
sticking
them
in
as
a
secret
and
then
any
time
I
need
to
use
that
I
can
just
reference
it
from
my
pod
and
then
accessing
it
via
a
file
mount
or
an
environment.
Variable
environment
Merrill's
are
sometimes
easy,
but
then
it
means
that
it's
much
harder
to
pick
up
changes.
If
you
care
about
updating
these
things
over
time,
then
you
can
stick
it
in
a
file.
A
B
Run
time,
security,
the
fun
stuff
that
no
one
writes
okay,
so
containers
actually
aren't
real
things.
They're
made
up
of
you
know:
Linux
primitives
of
namespaces
and
C
groups,
so
namespaces,
there's
all
these
different
kinds,
Pig
mount
network
I
mean
I,
could
go
into
the
intricacies
of
each
but
I
won't
bore
you
with
that.
See
groups
control
actually
what
a
process
can
use.
So
that's
like
resource
limits
stuff
like
that
namespaces,
actually
just
control.
What
a
process
can
see
so
combined
together.
B
B
So
a
primer
is
great
for
kind
of
that,
like
more
granular
control
over
that,
and
then
also
you
can
do
things
like
denying
mount
and
a
couple
of
system
functions,
but
it
doesn't
really
cover
all
of
them.
It's
just
for
you.
So
docker
has
like
a
saying
default
for
an
epimer
profile
and
it
blocks
things
that
you
wouldn't
want
to
happen
regardless,
like
writing
to
proc
or
writing
the
cysts
and
preventing
mount.
B
So
this
is
beta
in
kubernetes
and
you
can
use
like
the
defaults
of
the
runtimes
so
kind
of
what
it
would
look
like
if
you
want
to
do
that.
Is
you
just
add
this
little
annotation
and
then
you
would
define
this
container
engine
X
here,
that's
name
that
is
going
to
use
the
runtime
default,
which
would
use
then
Dockers
default
a
breezing
docker,
and
then
it
will
just
spin
up
this
very
basic
nginx
container
that
we
have
here.
B
So
seccomp
is
another
one
of
these.
So
we're
a
primer
kind
of
leaves.
You
hanging
on
a
bunch
of
system,
functions
satcoms,
you,
your
entire
Cisco
list,
so
you
can
define
exactly
which
this
calls
your
application
is
allowed
to
run,
and
so
it
gives
you
like
a
ton
of
features
there.
You
can
actually
even
with
seccomp
like
trace,
says
calls
and
stuff
like
that,
but
those
are
like
very
advanced
features.
So
by
default,
it's
like
Dockers
default
is
a
whitelist
and
it
prevents
things
that
you
would
not
want
to
happen
as
well.
B
Like
you
know,
syscalls
that
had
a
very
high
CVD
rate,
I
made
sure
weren't
in
the
waitlist.
It
took
a
long
time
to
write
the
whitelist
and
test
it
against
like
applications
to
make
sure
we
didn't
break
anyone,
but
any
sort
of
dangerous
syscall
is
not
on
there,
which
is
great.
So
this
is
alpha
in
kubernetes,
but
it
kind
of
has
the
same
exact
annotation
as
a
Parmer.
B
If
you
want
to
use
it,
so
you
just
defined
that
you
want
to
use
the
default
and
then
you
can
use
it
with
your
container
or
you
can
also
define
your
own,
which
I'll
show
a
little
bit
later
too,
as
well
same
with
a
perm
or
two.
So
then
there's
on
top
of
this,
a
bunch
of
other
features
with
regard
to
SELinux,
which
is
another
linux
security
module.
So
you
can
set
the
SELinux
context
for
labels
on
volumes.
B
You
can
define
that
you
want
to
your
containers
to
only
run
as
a
non
root
user,
which
is
super
good.
You
can
also
define,
like
I,
said,
a
read-only
root
filesystem.
If
your
application
can
you
do
that
and
then
you
can
drop
or
allow
certain
capabilities.
So
if
you're
not
using
something
like
net
raw
in
your
application,
which
is
really
just
for
ping,
you
can
drop
it,
which
would
be
look
like
this.
So
these
fall
under
security
context.
B
B
B
B
So
this
is
just
a
very
simple
nginx
pod
and
we're
just
doing
five
replicas,
because
why
not?
If
we
have
a
cluster,
let's
use
it
and
then
we're
just
mounting
in
some
nginx
configs.
It's
very
simple,
but,
as
you
can
see
here,
like
I
did
not
use
any
of
those
annotations.
I
just
showed
you
this
one's
just
gonna,
show
it
by
itself
running
and
that
we
can
obviously
get
something
to
run
without
any
security.
B
B
Cool
and
then
we'll
curl
again
I
just
have
these
hooked
up
to
a
very
like
basic
ingress,
but
I
didn't
want
to
waste
time
with
waiting
for
that
to
come
up,
so
all
I
did
was
create
the
pods,
so
it
this
like
very
simple
engine,
X
application,
just
spits
out
the
body
of
the
request
and
stuff
so
cool
that
works
like
obviously
it
should,
because
we
didn't
do
anything
to
it.
So
now,
let's
like
have
a
little
bit
more
fun,
I.
B
This
time
I'm
just
gonna
like
wait
a
little
bit
so
that
the
bass
sharp
will
work,
hopefully
they're
up
and
running
cool
and
now
we'll
curl,
the
other
service,
yay,
okay,
cool,
sorry,
I
was
really
excited
about
the
bass,
grip,
I,
don't
know
it's
very
like
interesting
to
type
while
talking
you
know.
So
that's
neat
so
obviously
like
it
did
not
break
our
application.
B
You
can
just
like
use
the
default
if
you're
not
doing
anything
that
you
should
not
be
doing
like
mounting
bolts
like
not
running
mounts
like
doing
anything
where
you
would
already
be
running.
Your
container
is
privileged.
You
might
as
well
just
run
with
the
defaults,
which
is
great,
so
that
was
like
just
kind
of
meta
but
like
if
we
get
a
real
world
example.
Now
I
will
switch
to
the
other
cluster,
which
is
a
bit
more
fun.
B
So
this
cluster,
that
we're
going
to
switch
to
is
a
bit
interesting
because
it
has
three
nodes
but
of
the
nodes
that
are
on
it.
So
sorry,
I'm
just
getting
the
context,
then
we're
gonna
switch
to
it.
We're
on
the
other
cluster
we'll
make
sure
there's
none
and
then
one
of
these
nodes
actually
has
the
dirty
cow
vulnerability.
So
I
labeled
them
as
you
can
see
in
cube,
has
it
so
it's
true,
so
that
one
is
running
with
a
bad
kernel.
B
I
want
to
be
able
to
upgrade
all
the
nodes
like
without
people
breaking
out,
so
what
I
could
do
possibly
is
run
with
a
second
profile
that
would
block
the
bad
things
of
dirty
cow,
which,
if
you're
familiar
with
dirty
cow,
it
was
a
race
condition
between
em
advised
and
P
right,
and
it
was
specifically
em
advised
and
advised
don't
need.
So
you
can
be
super
granular
with
these
SATCOM
profiles.
So
if
we
look
at
this
like
custom
profile
that
I
wrote,
okay.
B
If
we
take
a
look
at
this,
which,
by
default,
the
docker
default
profile
allows
em
advice,
because
obviously
you
need
that,
but
you
can
be
more
granular
with
your
own.
So
this
is
a
fork
of
the
default
where
I
took
em.
Advise
I
was
like,
will
allow
all
parts
of
em
advise
accept
and
advise
don't
need,
which
is
the
second
argument
of
it,
and
this
like
SCMP,
it's
like
it's,
not
equal,
that's
kind
of
like
the
operator
there.
So
I
deployed
this
profiles
re
on
the
node.
B
So
what
we
can
do
is
me,
being
this
system
in
I'll
be
like
I
am
going
to
start
deploying
our
pods.
With
this
you
know
custom
profile,
which
is
localhost
of
advice
so,
and
we're
also
just
going
to
do
one
room:
okay,
because
whatever
and
then
I'm
using
like
node
selector,
to
make
sure
it's
on
the
node
that
I
labeled
previously
as
dirty
cow
like
in
the
real
world,
they
probably
didn't
label
them
because
they
know
that
they're
all
bad,
but
just
to
make
sure
for
the
purposes
of
this
demo.
I
did
this.
B
Cool,
so
it
tried
to
create
the
race
condition,
that's
kind
of
like
the
starting.
It's
like
starts
the
race
condition
and
it
could
not
pone
the
machine,
and
our
sad
hacker
is
sad.
So
we
gave
our
sysadmin
enough
time
to
upgrade
the
notes
which
is
super
cool.
They
could,
you
know,
do
their
thing
make
sure
that
yet
you
hadn't
been
exploited
at
all
previously
to
it
being
known
publicly
and
they
had
time
to
breathe.
B
So
that's
super
nice,
but
of
course
this
wouldn't
be
a
fun
demo
if
we
didn't
actually
pone
the
machine
in
the
end.
So
why
don't
we
do
that?
What
we're
now
going
to
spin
up
is
another
one
of
these
that
was
funny.
Sorry
I
have
like
the
maturity
of
a
five-year-old,
so
we'll
make
sure
this
one
goes
on
a
on
a
dirty
cow
machine,
we're
not
going
to
run
it
with
any
sort
of
second
profile
or
anything.
It's
just
going
to
go
there
and
it's
going
to
do
its
thing
and
pone
the
node.
B
B
B
Cool
source
at
hacker
is
said,
so
that
was
kind
of
a
cool,
realistic
use
case
for
second
profiles.
I
did
try
to
add
to
the
default
second
profile
of
docker
that
specific
line
where
it's
like
you
block
em,
advise
and
M
advice
on
these,
but
the
funny
thing
is
G
load,
C
uses,
M
advice,
don't
need
for
malloc,
so
that
would
literally
break
everyone.
So
in
this
scenario
we
did
not
use
G
livesey
for
anything.
So
if
we
just
go
back
to
the
presentation
now
we
can
move
on
so.
A
Thank
You
Jess
there
we
go
so
in
the
last
few
minutes.
I
want
to
leave
us
time
for
questions,
but
we'll
end
up
probably
going
outside.
If
we
need
to
answer
a
bunch
after
that
quickly
like
what's
the
security
roadmap
for
kubernetes-
and
this
is
my
take
on
it-
there
have
been
a
bunch
of
people
involved
as
well
in
the
community
no
promises.
Community
consensus
is
sometimes
hard
to
predict,
but
with
one
six.
A
What
we
kind
of
have
is
this
single
tenant,
multi
identities
with
one
seven
we're
moving
more
towards
cooperative
soft
multi-tenancy
I'll
cover
in
more
detail
what
we
have
landing
there.
Our
longer-term
goal
is
towards
hard
multi-tenancy,
and
this
is
where
your
multi
tenant
security
boundaries
are
going
to
be
strongly
enforced.
So
we
have
two
a
security
part
of
it
and
then
there's
also
better
resource
isolation
which
may
or
may
not
really
have
to
do
much
with
security,
but
is
one
of
those
things
that
we
need
for
hard
multi-tenancy.
A
What
does
it
really
mean
if
I'm
comfortable
running
in
the
same
cluster,
two
different
third-party
codes
and,
presumably
of
some
level
of
potential
maliciousness?
It's
gonna
take
a
while
for
us
to
get
there.
We
have
to
word,
do
it
across
the
components
of
runtime
security.
Of
course
we
also
need
to
have
our
API
and
namespace
security.
A
The
big
highlight
is
our
back
and
it's
been
a
broad
effort
across
lots
of
people,
Red
Hat,
core
OS,
google,
lots
of
other
companies,
and
so
some
of
the
highlights
are
that
we
started
to
add
identities,
to
the
infrastructure,
components
of
the
system,
the
nodes
controllers
and
we've
limited
permissions
for
many
of
them.
Unfortunately,
we
haven't
quite
finished
limiting
all
of
those
permissions,
but
that's
what
we'll
get
to
with
with
one
seven.
So
it's
1,
7
I,
think
we'll
have
something
that
looks
pretty
close
to
soft
multi-tenancy.
A
If
you
did
have
a
container
escape,
it
would
be
limited
to
the
privileges
on
that
one
node
and
you
wouldn't
have
broad
access
to
many
things
in
the
cluster,
so
we're
gonna
finish:
limiting
some
of
those
infrastructure
permissions
we're
going
to
enforce
granular,
node
identities
and
permissions
and
improve
secrets
management.
So
if
you
have
node
a
and
there's
pods
running
on
it
with
certain
secrets,
those
are
the
only
secrets
that
cubelet
will
be
able
to
read,
and
so
that
will
get
us
that
kind
of
isolation
mechanism.
A
There
we
saw
some
things
about
comprehensive
audit
logs
that
we'll
be
working
on.
Some
people
are
also
interested
in
audit
logs
coming
from
the
nodes
like.
If
you
are
using
binary
verification
and
the
nodes
start
a
pod,
they
should
log
things
that
happen
there
or
if
you
have
exact
or
other
things
running
on
nodes
making
sure
we
have
SSH
access
to
the
nodes
logged
as
well.
Those
are
some
of
the
kinds
of
things
that
you
might
see.
A
Certificate
rotation
has
been
an
interesting
one
right
now.
Some
of
those
certs
are
all
static.
Of
course,
you
know
getting
dynamic.
Rotation
will
be
interesting
and
useful
and
then
maybe
we
can
improve
some
of
the
runtime
components
too
and
then,
after
that,
with
kubernetes
1-8
sometime
in
September
or
so
will
start
moving
more
towards
harder
multi-tenancy.
A
A
Getting
that
more
in
place,
adding
the
better
resource,
isolation
between
containers,
making
sure
that
you
can't
do
too
much
cycle
stealing
between
them
and
then,
once
we
have
a
lot
of
these
security
mechanisms
in
place,
then
the
question
becomes,
if
I'm
an
org
or
I'm
the
security
team,
how
do
I
enforce
that
everyone
used
them
and
that
can
be
either
requiring
that
they
all
be
set
and
rejecting
them
or
automatically
adding
them.
Those
are
the
directions
we'd
like
to
go
in
so
you
know
recap:
we
talked
about
a
bunch
of
stuff
questions.
A
So
the
the
question
is
about
revocation
lists
and
I.
Don't
think
we
support
any
revocation,
but
there
is
the
list
of
things
that
so
as
long
as
the
CAA
is
signed,
your
that's
where
you
are.
This
is
one
of
the
reasons.
What
we're
moving
to
is
the
place
where
the
node
has.
The
cert
only
allows
the
node
to
make
a
certificate
signing
request,
and
then,
by
making
that
request,
then
it
will
get
its
own
identity,
and
so
once
it
has
its
own
identity,
you
wouldn't
need
to
necessarily
revoke
it.
A
Sorry,
right
now,
you
can
either
revoke
them
all
by
doing
a
CA
rotation
which
is
no
support,
or
you
know
getting
that
fine-grained
control
and
allowing
you
to
do
each
one
is
definitely
part
of
what
we're
planning
for
one
seven
mechanism
details
there.
I'm
gonna
go
to
the
back
and
then
up
here.
Please.
A
So
the
question
is:
who
maintains
the
the
cluster
CA
and
yes,
each
each
deployment
is
responsible
for
doing
that
themselves.
Of
course,
pay
off
or
container
engine.
We
have
mechanisms,
we've
built
to
maintain
that
and
keep
try
and
keep
that
relatively
secure
for
you,
part
of
running
it
as
a
service
I'm
sure
other
service
providers
are
also
going
to
have
similar
things
like
that.
I,
don't
know
the
details
of
what
they're
doing
today.
A
A
A
B
B
Yes,
Oh
tres
is
something
that's
not
written
into
the
go
sack
home
library.
That's
like
the
underlying
thing
of
all
of
this,
mostly
because,
like
if
you're
going
to
do
something
like
trace,
you
wanted
to
find
your
own
functions
and
they
get
super
complicated.
That's
like
how
are
you
defining
those
so
I
think
that
there's
like
some
design
discussions
around
that,
but
it's
really
just
like
getting
to
consensus
and
then
getting
it
done.
B
A
B
A
You
could,
if
you're
willing
to
compile
it
all
yourself,
you
could
certainly
write
another
driver
that
would
expose
them
some
other
mechanism.
If
the
files
aren't
what
you
need,
you
know
feel
free
to
open
an
issue
and
say
here's
my
use
case,
and
this
is
why
environment
variables
and
files
don't
meet
them.
I'm
gonna
call
it
a
day.
So
with
that,
thank
you.
Everyone
for
those
of
you
left.
Let's
go
outside.