►
From YouTube: The Container Security Checklist
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
this
is
part
of
the
cubesat
enterprise
online
webinar
series.
This
is
week
number
four
of
what
is
now
scheduled
to
be
11
weeks.
So
for
those
of
us,
those
of
you
who
signed
in
early
will
be
sending
out
three
more
additional
weeks,
the
for
you
to
register
for,
but
this
came
about
when
it
was
not
clear
what
was
going
to
happen
with
with
cubecon
amsterdam
and
now
we
all
know
it
will
be
a
virtual
event
in
august
and
we
look
forward
to
seeing
everybody
there.
A
But
in
the
past
three
cube
cons,
we
have
run
an
event
called
cubesec
enterprise
summit,
where
customers
have
come
to
talk
about
the
challenges
deploying
kubernetes
in
enterprise
production
environments,
and
we
had
a
bunch
of
speakers
signed
up
to
do
amsterdam
planning
to
go,
and,
of
course,
thanks
to
this
global
pandemic,
we
had
to
make
some
changes,
but
we
took
many
of
those
speakers
who
were
willing
to
do
this
as
a
webinar
series
and
and
slotted
them
week
by
week.
A
This
week
is,
is
liz's
turn
to
talk
about
her
new
book,
so
liz
in
addition
to
running
open
source
software
for
aqua
you're.
Also
an
established
author
with
a
brand
new
book.
A
Okay,
so
without
further
ado,
let's
go
over
some
of
the
housekeeping
issues
and
then
we'll
let
liz
kick
this
off.
So
if
you
do
have
questions
today,
because
we
have
a
lot
of
people
on
great
turnout
today,
we
will
be
doing
questions
via
your
go
to
webinar
panel.
So
if
you
put
a
question
in
there,
we
will
try
and
take
some
throughout
if
they
seem
like
they're
really
relevant
to
the
current
conversation.
Otherwise,
we'll
try
and
take
some
at
the
end,
and
if
we
don't
get
to
your
question,
we
will
reply
via
email.
A
We
will
make
a
copy
of
the
slides
available
after
the
event
and
we
are
interested
in
your
feedback
as
well
so
on
what
was
good
about
today.
Other
things
we
will
be
doing
some
polls
today
as
well.
So
we
ask
you,
for
those
who
are
here,
live
not
viewing
this
as
a
an
archive
you're
here
today,
you're
live,
we
will
be
polling
and
we'd
love
to
see
your
answers
and
for
those
of
you
watching
this
on
demand,
now
you'll
see
everybody's
answer.
Think
about
your
own
responses.
A
We
go
through
so
with
that.
Let
me
turn
it
over
to
liz
and
to
talk
about
the
her
new
book
and
some
of
the
key
findings
in
that
and
and
share
that
with
you
today,
so
go
ahead.
Let's.
B
Wonderful
thanks,
andy
and
hi
everyone.
Thank
you
very
much
for
coming
and
joining
us
today,
and
I
would
really
like
this
to
be
as
interactive
as
we
can
make
it.
So.
As
andy
says,
there
are
going
to
be
lots
of
polls
during
this
talk
to
to
help
you
get
involved
and
yeah.
Please
do
ask
questions
and
we
can
try
to
take
them
either
as
we
go
along
or
we'll
answer
them
at
the
end,
as
andy
says.
B
So
I
look
after
the
open
source
engineering
team
here
at
aqua
security
and
as
andy
mentioned,
I
am
also
an
author.
I
recently
published
this
book
called
container
security
published
by
o'reilly.
If
you're
watching
this
live,
you
should
find
an
electronic
copy
of
the
book
in
the
handout
and,
if
you're
not
watching
live,
you
can
download
an
electronic
copy
from
aqua's
website
for
just
in
exchange
for
your
contact,
details
and.
A
Mary
did
ask
me
to
make
one
point:
liz
the
handout,
if
you
do,
click
on
the
handout
in
your
handouts,
tab
it
will
open
in
a
separate
browser
window.
You
might
not
notice
it.
Some
people
have
opened
multiples
and
they
find
them
all
later.
So,
look
for
that
separate
window
to
pop
up
if
you
do
download
the
handout.
A
B
Great
and
of
course,
if
you
want
a
physical
copy,
it's
available
in
your
favorite
bookstore
so
go
and
order
it
from
your
local
bookstore.
B
B
Now
in
today's
webinar,
we
don't
have
time
to
cover
all
of
those
questions
and
all
of
those
checklist
items,
but
I
thought
I
would
highlight
a
few
of
my
favorite
and
perhaps
the
most
important
questions
and
we'll
concentrate
on
those
and
explain
them
today.
B
So
for
each
of
these
six
checklist
items,
I'm
going
to
ask
a
question:
we're
going
to
open
a
poll
to
get
you
thinking
about
that
question
and
why
not?
Let's
get
started
so,
let's
bring
up
the
first
of
those
questions
which
is
about
the
build
machines.
Are
you
running
your
builds
separately
from
your
production
cluster?
Are
you
running
bills
on
different
machines
or
virtual
machines.
B
Good
that
is
good
to
see.
Yes,
we're
seeing
the
numbers
are
changing
as
your
votes
are
coming
in,
but
it's
looking
very
much
as
though
your
your
bills
are
running
separately
from
production,
which
is
very
good
news,
as
we
will
explain
shortly
looks
like
pretty
much.
Everyone
has
voted,
so
nearly
everyone
has.
I
think
we
have
a
pretty
significant
view
there
that
the
vast
majority
of
you
are
well.
Congratulations,
you're
running
your
build
separately.
B
So
if
your
build
processes
are
on
the
same
machine
as
your
application,
workloads,
they're,
sharing
a
kernel
and
if
anything
were
able
to
escape
the
build
process
onto
the
host,
it
would
have
access
to
those
applications
and
remember
that
docker
files
that
we're
typically
using
to
that
isn't
working.
Let's
see
there,
we
go
yes.
If
your
docker
files
contain
instructions
to
run
basically
arbitrary
code,
you
can
have
any
instruction
here,
that's
going
to
run
during
the
build.
B
So
if
someone
manages
to
compromise
your
docker
file
and
compromise
those
build
instructions,
they
can
get
the
bill
to
do
pretty
much
anything
they
want
it
to
now.
This
is
even
more
serious
if
you
are
using
a
docker,
build
process
that
uses
the
docker
socket,
because
the
docker
socket
is
essentially
root
access
to
the
host.
B
B
Now
it
is
possible
to
run
builds
in
your
production
environment
in
a
safe
way.
So
I
have
caveated
this
that
if
you
know
what
you're
doing
you
can
run
your
builds
in
production,
you
could
use,
for
example,
sandboxing,
like
g
visor,
you
could
potentially
be
scheduling
your
build
jobs
to
specific
nodes
in
the
cluster.
Where
applications
don't
run.
B
You
could
also
be
using
rootless,
build
processes,
things
like
umochi
or
builder,
or
the
docker
build
kit
in
routeless
mode.
All
these
things
that
basically
don't
require
a
docker
demon.
B
So
there
are
ways
you
could
safely
do
this,
but
it's
probably
safest
unless
you've
thought
very
carefully
about
it
to
just
keep
your
builds
separate
from
your
production
cluster
and
the
good
news
is,
it
seems,
like
most
of
you
are
doing
that
so
we're
off
to
a
flying.
Start,
that's
good
all
right,
so
the
next
question
is
going
to
consider
the
images
that
get
built.
So,
let's
get
ready
for
the
next
poll
in
your
container
image
builds,
is
all
executable
code
added
to
the
container
image
at
build
time.
B
So
if
you
have
containers
that
update
themselves
when
they
start
running
or
that
load
extra
executables,
you
need
to
answer
no
to
this
question.
B
Okay,
so
around
two-thirds
of
you
are
keeping
your
or
adding
all
your
executable
code
to
the
container
images
during
the
build.
A
significant
number
of
you
are
not
sure.
So,
let's,
let's
explain
a
little
bit
more
about
what
we
mean
here.
B
So
once
you
build
your
application
container
image,
it's
a
really
good
idea
to
scan
it
for
known
vulnerabilities
that
might
exist
in
the
packages
or
language
dependencies
inside
that
container
image.
If
you're
not
already
scanning
your
images.
Do
please
start
doing
that.
There's
lots
of
free
and
open
source
tools
available
for
vulnerability
scanning,
including
our
own
trivi.
It's
entirely
free,
so
just
go
ahead
and
use
that
scanning
your
images
lets.
You
know
if
your
containers
have
known
vulnerabilities
that
attackers
could
exploit.
B
A
A
You
know,
obviously
it
gives
you
some
flexibility
to
modify
a
running
container.
I
guess
that's
one
of
the
things
people
are
looking
for.
Is
there
ever
a
good
reason
to
do
this
or
really
you
would
say
if
you
need
to
make
a
change,
go
back
to
that
app,
build
it
fresh
and
never
do
this.
B
B
It
seems
like
most
of
our
attendees
are
already
doing
that,
but
those
of
you
who
maybe
aren't
or
you
know,
maybe
you
need
to
go
and
check
this-
is
it's
all
really
about
scanning
and
having
confidence
in
the
code
that
you're
running.
A
A
B
A
B
Yeah,
well,
I
think
it
would
behoove
everyone
to
make
sure
that
we're
not
running
our
containers
with
privileged
because
it
has
been
called
the
most
dangerous
flag
in
computing.
I
quite
like
that
quote
from
andrew
martin
from
from
control
play.
I
think.
Actually,
that's
a
you
know
a
debatable
point,
I'm
very
open
to
suggestions
for
more
dangerous
flags.
That
could
be
quite
a
fun
question.
So
I'd
love
to
hear
your
thoughts
on
that.
B
B
Now
it's
been
used
for
other
reasons
like
running
builds.
You
might
have
exceptional
reasons
why
you
need
to
use
it,
but
for
the
vast
majority
of
applications
it's
not
really
necessary.
Let's
talk
about
the
things
that
it
does
what
what's
happening
when
you
do
run
a
container
with
dash
dash
privileged.
B
So
back
in
the
mists
of
time,
you
were
either
root
with
all
privileges,
all
privileges,
or
you
were
an
unprivileged
user
with
no
special
privileges,
and
then
capabilities
were
added
to
the
linux
kernel
to
make
these
permissions
more
granular
so
that
you
can
grant
or
deny
specific
privileges
when
you
run
a
container
by
default,
it
gets
a
sensible
set
of
these
capabilities,
which
don't
include,
for
example,
any
of
these
three
that
I've
listed
here.
That
really
most
containers
don't
need
to
do
most
containers
don't
have
any
reason
to
be
modifying
the
kernel
modules.
B
B
So
when
we
run
a
container,
we
can
specify
the
set
of
capabilities
that
are
granted
to
that
container
and
to
start
with
here
in
this
first
example,
I'm
running
a
regular
ubuntu
container
and
I'm
granting
all
the
capabilities,
and
you
can
see
that
if
we
look
at
the
status
file
for
the
process,
one
inside
that
container,
we
get
a
value
with
lots
and
lots
of
f's.
It's
a
set
of
big
flags
and
all
of
the
flags
are
turned
on.
B
Then,
if
we
run
the
same
container,
dropping
all
the
capabilities,
we
look
at
the
set
of
capabilities
and
all
the
flags
are
turned
off.
The
values
are
all
zero
and
then,
if
we
don't
specify
any
capabilities
at
all,
we
get
that
default
set
that
I
mentioned,
and
it's
kind
of
a
mixture.
So
some
of
the
flags
are
off.
A
lot
of
the
flags
are
off.
Some
of
them
are
on
now.
If
we
run
with
batch
dash
privileged,
it
grants
us
all
of
those
capabilities
so
for
the
capabilities,
it's
the
equivalent
of
adding
cap.
B
B
I've
run
the
same
container
without
and
with
dash
privileged,
and
you
can
see
that
with
the
privileged
flag,
you
get
access
to
a
lot
more
devices.
B
In
fact,
with
the
privilege
flag,
you
get
access
to
every
single
device
on
the
host
and
you
could
use
that
to,
for
example,
erase
partitions
on
the
hard
drives
on
the
host.
So
you
really
really
really
don't
want
to
have
a
container
escape
that
has
dash
dash
privilege,
because
inside
that
container
you
can
do
super
dangerous
things.
A
B
Yeah
so
well
at
one
level
you
might
say
why
should
one
container
be
able
to
change
the
time
for
other
containers,
you
can
mess
with
programs
pretty
seriously
by
changing
time.
If
you
expect
things
to,
for
example,
if
you
expect
to
see
the
latest
value
that
something
was
set
to
a
value,
you
might
look
for
the
most
recent
update
and
if
you
change
time
in
the
meantime,
well,
how
do
you
know
what's
most
recently
yeah
so.
B
And
time
is,
interestingly,
something
that
recently
has
started
to
be
namespaced,
so
that
in
the
future
I
would
imagine
in
much
the
same
way
that
today
you
can
grant
a
container
the
cis
boot
capability
and
it
can't
actually
boot
the
whole
machine
anymore.
It
used
to
reboot
the
whole
machine.
B
Now
it
will
just
kill
the
container,
and
I
would
imagine
that
in
the
future
time
being
namespace
would
mean
that
we
could
grant
containers
the
the
system
time
capability
and
it
wouldn't
necessarily
affect
the
rest
of
the
system,
but
today
it's
it's,
not
something
you
want
to
really
give
away
lightly.
B
There
is
one
other
reason
why
dash
privileged
is
maybe
sort
of
psychologically
dangerous,
and
that's
it's
it's
all
about
the
name.
So
there's
an
implication
that
if
you
have
a
container
that
doesn't
have
dash
dash
privileged,
maybe
that
means
it
must
be
unprivileged
and
that's
really
not
true.
By
default,
your
containers
do
run
as
root.
You
do
not
need
the
privilege
flag
to
be
running
as
roots.
You
can
find
out
all
about
that
in
chapter
nine
in
the
book
to
find
out
more
about
that.
A
That
came
in
sorry,
someone
in
the
chat
said
some
security
solutions
can
be
affected
if
system
time
is
changed
as
well.
So
you
know
if
you,
if
you
knew
that
some
some
sort
of
antivirus
or
other
malware
detection
engine
was
running
and
you
could
change
the
time
it
might
impact
that.
So
that's
a
good
point.
B
There's
also
a
question
about
what
about
running
with
privileged
on
the
hosts,
where
the
docker
service
itself
is
running,
with
a
restricted
host
user
and
not
root
okay.
So
I
guess
this
is
the
idea
that
your
so
there
is
a
new
newish
idea
of
rootless
containers,
the
ability
to
run
containers
as
unprivileged
users.
B
The
the
best
sort
of
use
case
example
for
this
is
in
an
environment
like
a
university
where
you
might
have
a
shared
set
of
machines.
The
users
are
unprivileged
and
until
rece,
until
rootless
containers,
if
you
wanted
to
let
students
run
a
container
well,
you
couldn't
do
that
because
it's
it's
essentially
a
privileged
operation.
B
Rootless
containers
allow
you
to
run
containers
as
an
unprivileged
user
and
I'm
guessing
that's
what
this
question
is
talking
about
around.
If
you
run
as
an
unprivileged
user,
if
you
can
run
a
container
as
an
unprivileged
user,
I'm
not
sure
whether
dash
dash
privilege
would
error
in
that
situation
or
whether
it
would
carry
on
and
try
to
grant
you
as
many
privileges
as
possible.
You
certainly
wouldn't
be
able
to
get
things
like
all
device
access
and
I'm
not
sure
what
would
happen
in
terms
of
capabilities
that
you
didn't
already
have.
B
B
B
A
But
it
is
a
big
challenge
to
keep
all
of
those
software
components
up
to
date.
Right
I
mean
it's,
maybe
you
can
keep
the
big
pieces
done,
but
you
even
know
about
all
the
other
smaller
components
you
might
be
using
right.
Well,.
B
Good
number
of
you
aren't
sure
or
know
that
you're
not
now,
and
the
reason
why
this
question
kind
of
came
to
mind,
particularly
for
this
presentation
was
only
a
couple
of
months
ago.
I
got
asked
why
our
cube
bench
tool
doesn't
support
kubernetes
1.8.
B
B
B
So
really
the
you
know,
running
cube
bench
cute
venture
is
going
to
tell
you
if
you
haven't
configured
your
kubernetes
according
to
best
practices,
and
it
doesn't
really
matter
whether
you've
configured
it
according
to
best
practices.
If
you
know
it's
full
of
vulnerability.
B
Well,
full
is
an
exaggeration,
but
if
you
know
there
are
exploitable
security
issues
in
those
really
old
versions,
so
I
explained
that
in
this
video
I
then
got
quite
a
fun
response
from
someone
who
you
know
was
pointing
at
1.8
shock,
horror
face
and
clearly
he
thought
that
I
probably
should
have
been
a
little
bit
more
shouty
about.
B
An
old
version
I
will
point
out:
this
was
not
just
a
random
person
on
the
internet.
This
this
was
actually
a.
You
know,
an
aqua
customer.
So
you
know
there
are
corporate
customers,
enterprise
users
out
there
who
take
their
security
seriously,
but
for
whatever
reason
hadn't
been
taking
it
secure
seriously
enough
to
upgrade
their
kubernetes
systems.
This
stuff
is
all
important.
B
B
I
don't
know,
for
example,
with
turning
off
certain
software
services
that
maybe
you
would
normally
run,
but
if
you
decide
they're,
not
critical
and
they're
interacting
with
a
vulnerability,
and
there
may
be
things
that
you
can
at
least
use
observability
tools
to
detect
whether
a
problem
has
actually
happened,
but
yeah.
Fundamentally,
if
a
patch
doesn't
exist,
you
kind
of
have
to
wait
for
the
fix
to
be
released.
Pretty
rare
these
days
that
you're
going
to
find
a
critical
vulnerability
that
doesn't
have
a
patch.
A
Well,
there
may
be
times
too
where
people
aren't
able
to
to
patch.
If
it's
you
know
at
the
kernel
level,
it's
probably
more
critical
to
do
it,
but
even
in
application
software
here
we
have
the
the
aqua
virtual
patching
capability
as
well,
which
would
be
one.
You
know
our
v
shield
solution,
which
would
at
least
pick
up
or
detect
and
even
potentially
block
some
of
those
accesses,
but
for
if
you're
interested
in
that
take
a
look
at
one
of
our
other
video
webinars,
we
won't
go
into
that
today.
B
All
right-
and
there
was
another
question
that
was
saying
you
know
this
is
limited
to
the
support
of
my
kubernetes
distro
vendor.
That
is
absolutely
true.
One
of
the
benefits
of
using
a
managed
distro
is,
you
know,
they're
collecting
together
all
of
the
upgrades
for
you
they're,
maybe
collecting
together.
You
know
not
just
the
kubernetes,
but
maybe
the
maybe.
The
distro
also
includes
observability
solutions
or
logging
or
a
service
mesh
or
whatever
else,
and
so
hopefully
they
are.
B
Hopefully
your
vendor
is
applying
upgrades
and
supplying
those
upgrades
to
you
in
a
timely
fashion,
particularly
for
you
know,
they
don't
happen
that
often,
but
we
do
occasionally
see
serious
vulnerabilities
in
kubernetes
or
other
cloud
native
software.
If
they're
not
giving
you
timely
patches,
I
would
definitely
call
up
your
account
manager
and
shout
at
them.
B
B
B
A
B
A
A
little
bit
more
of
a
balanced
response,
this
one
is
probably
harder
for
people
to
to
follow
and
adhere
to
consistently.
B
B
Now
I'm
going
to
guess
that
most
of
you
are
using
kubernetes
and
a
good
number
of
you
will
probably
be
using
kubernetes
native
secrets,
and
if
I
get
a
secret
using
cube
control,
I
can
just
decrypt.
Well,
it's
not
decrypted
at
all.
I
can
get
the
plain
text
version
by
base64
decoding.
I
don't
need
any
secret
to
do
that.
It's
not
encrypting!
It's
just
an
encoding.
B
B
B
Now,
if
I
go
and
search
for
my
secret
value
inside
the
database,
I
can
see
that
the
database
file
matches
my
secret
value
and
I
can
actually
look
it's
a
binary
file.
So
it's
not
super
pretty,
but
I
can
go
and
just
look
at
that
xcd
database
file
and
we
can
see
my
secret-
is
just
sitting
there
in
the
clear.
B
So
anyone
who
has
access
to
the
database
file
on
the
host
machine
might
be
able
to
get
at
any
of
the
secrets
that
are
stored
in
there
is
it's
pretty
trivial
once
you
have
access
to
that
file,
because
xcd
by
default
is
not
encrypted.
Now
you
do
have
options.
One
of
your
options
is
to
encrypt
xcd.
You
can
configure
it
to
be
encrypted.
B
Another
alternative
is
to
use
a
secrets
manager
to
hold
the
secret
values
separately
outside
of
xcd,
and
you
might
very
well
consider
that
most
of
your
kubernetes
state
information
isn't
terribly
secret
and
that
it
doesn't
need
to
be
encrypted.
But
your
secrets
are
another
matter,
so
you
might
want
to
take
advantage
of
something
like
hashicorp
volt
or
the
key
management
systems
from
your
cloud
provider
somewhere
secure
that
you
can
store
those
secrets
and
there's
lots
of
kubernetes
integrations
for
secret
storage.
B
All
right,
we
are
coming
up
to
the
last
question,
the
last
poll
for
today
and
remember.
We
talked
earlier
about
treating
your
containers
as
immutable,
so
the
question
here
is:
can
you
prevent
containers
from
drifting?
Do
you
have
a
way
of
spotting
when
a
container
attempts
to
run
something
that
wasn't
in
the
original
container
image.
A
A
The
the
the
belief
here
is
that
that
should
never
happen
is
that
you
know
the
containers
once
you've
you've
built
them.
We
don't
we
don't
want
anybody
running
anything
that
was
not
specifically
allowed
in
that
first
version
right.
B
Correct
and
if
you
do
see
something
running
inside
a
container,
that's
that
wasn't
in
the
original
image
provided
you're
treating
your
containers
as
immutable.
It's
almost
certainly
a
sign
of
compromise.
B
Team
have
seen
you
know,
containers
being
compromised
to
run
cryptocurrency
miners,
that's
the
kind
of
classic
example.
At
the
moment.
A
B
And-
and
this
is
a
harder
problem-
essentially,
you
know
there
is
not
much.
There
are
some
open
source
solutions
for
detecting.
B
There
are
not
any
open
source
solutions
that
I
am
aware
of
for
preventing
container
drift,
but
let
me
show
you
something
that
is
pretty
cool
in
aqua,
so
I
have
a
demo
here:
I'm
going
to
run
an
ubuntu
container
and
we're
going
to
look
in
the
aqua
console,
and
I
can
see
my
ubuntu
image
has
a
default
aqua
profile
associated
with
it,
and
I've
set
up
that
profile
to
well
to
have
drift.
B
B
B
Okay,
so
I've
created
that
file.
I
need
to
make
it
give
it
the
executable
bit
so
that
it
can
be
run,
and
then
I
can
just
run
that
script
and
it
writes
that
message
to
the
screen.
Now
that
is
a
new
executable
added
to
the
container
that
was
not
present
when
we
scanned
the
image.
So
this
is
drift
in
action
and
we
can
see
that
in
the
audit
logs
it
has
been
detected.
Aqua
has
been
able
to
spot
that
you
can
see.
The
security
control
is
drift.
Prevention.
B
Now,
if
we
want
to
take
this
a
step
further
and
prevent
that
drift
from
happening,
we
can
turn
on
enforcement.
And
now,
if
we
try
to
run
that
same
executable,
we
get
permission
denied
error.
We
didn't
even
need
to
restart
the
container,
which
is
pretty
pretty
nice,
and
then
we
can
see
in
the
audit
log
that
this
time
we've
got
a
block.
B
Right
yeah
and
this
drift
prevention
enforcement
is
it
it's
probably
one
of
the
most
advanced
controls
that
you
can
that
you
can
run
for
containerized
security
and
it's
so
powerful
because
of
this
concept
of
container
drift
over
mutable
containers.
If
you
treat
your
containers
as
immutable,
this
is
like
a
superpower
preventing
any
of
those
unexpected
attacks.
B
If
an
attacker
can
compromise
your
container,
but
then
they
can't
actually
do
anything
unexpected
inside
that
container.
That's
super
powerful.
A
Right,
sorry,
no,
I
was
gonna
say
in
conjunction
with
one
of
your
earlier
checklist
items
of
you
know,
treating
your
own
containers
if
they're
immutable
and
not
adding
things
at
runtime
and
now
not
allowing
anyone
who
potentially
was
able
to
make
a
change
to
a
running
container,
which
is
not
easy
but
is
doable.
A
Right,
great:
okay,
if
I'll
remind
people,
if
you
have
any
other
questions,
go
ahead
and
enter
them
now,
we'll
we'll
open
it
up
as
liz
wraps
up
here,
we'll
take
some
more
questions
at
the
end.
B
B
No,
but
if
you're
not
sure
or
if
you
you
know
a
lot
of
the
time,
the
sort
of
default
best
practice
is
a
good
idea,
so
if
you're
not
sure,
maybe
go
and
find
out,
because
there
could
be
some
things
that
you
could
do
relatively
straightforwardly
to
improve
the
security
of
your
deployment.
B
So
hopefully
you've
already
found
the
the
download
of
the
book.
If
you're
watching
the
recording
of
this
presentation
later,
you
can
go
to
info.acquisite.com
and
you'll
find
the
link
there
with
a
picture
of
the
book.
So
you
should
be
able
to
find
that
pretty
easily
physical
copy
is
also
available
from
your
favorite
bookstore.
A
It's
muted
there
there's
one
there's
one
about
cube
bench:
can
you
run
cube
bench
on
a
high
availability,
kubernetes
cluster,
so
with
one
more
than
one
master,
node.
B
Yeah
yeah,
so
we
mentioned
it
briefly
earlier
on
it's
a
tool
for
checking
the
configuration
of
kubernetes
and
whether
or
not
it
meets
best
practices,
those
best
practices
being
defined
by
the
center
for
internet
security.
So
it's
another
kind
of
checklist
of
configuration
settings
for
all
the
different
components
of
your
of
your
cluster.
B
So
I
don't
think
in
the
current
version
of
the
ci
spec,
I
don't
think
there's
anything
specific
to
having
more
than
one
master
node,
but
I
would
expect
that
the
other
tests
would
all
apply.
B
Now
q
bench
configuration
we
could
probably
spend
a
whole
other
webinar
talking
about
all
the
different
things
you
can
do
with
cute
bench.
Configuration
because
you
can.
You
could
modify
the
tests
if
you
felt
that
was
appropriate
for
your
situation.
B
In
the
most
recent
version
there
are
different
sections
of
tests
for
things
like
whether
or
not
it's
running
lcd.
Again,
it
will
attempt
to
auto
detect
that
the
auto
detection
does
rely
on
being
able
to
execute
things
like
cube,
control
or
cube
bench
which
have
to
be
mounted
into
the
path
from
the
host.
So
there
is
some
configuration
there.
We
have
some
example
jobs,
job
yaml
that
can
help,
but
that
probably
don't
cover
every
single
possible
scenario.
B
A
All
right
I
mean:
is
it
a
good
opportunity
actually
to
talk
about
your
latest
news
out
of
your
open
source
team
in
terms
of
the
starboard
project
and
as
a.
B
So
I'm
just
looking
at
the
there's
a
lot
of
questions
as
well:
wow,
okay
and
we'll
come
back
to
that
in
a
second
yes.
So
starboard
is
our
latest
project
from
my
team.
The
open
source
team
at
aqua
and
the
idea
of
starboard
is
to
take
the
output
from
different
security
reports
cube
bench
being
an
example.
I
mentioned
trivia
vulnerability,
scanning
aqua
vulnerability
scanning.
I
think
also
reports
from
third
party
security
tools.
We
have
an
integration
with
polaris
from
fairwinds,
which
audits
your
pod
spec
yaml.
B
Anyway,
we
take
all
this
security
information
and
store
it
in
the
form
of
kubernetes
custom
resource
definitions
and
then
that
way,
it's
accessible
over
the
kubernetes
api
and
with
an
octan
plug-in,
you
can
see
the
security
information
right
next
to
the
kubernetes
resources
that
it
applies
to.
So
that's
much
more
convenient
for
retrieving
for
people
who
are
used
to
tools
like
cute
control
or
who
are
used
to
things
like
the
opt-ins
dashboard.
B
All
right,
so
I
see
a
question
there
about
how
about
securing
fire
gate,
containers
or
azure
container
instances.
Yes,
so
the
interesting
thing
about
fargate
and
container
instances
is
that
you
don't
have
access
to
the
host.
So
some
of
the
things
that
we've
talked
about
today,
things
like
updating
the
software
on
your
host.
Well,
you
don't
have
control
over
that.
That's
something
you
have
to
rely
on
the
cloud
provider
to
do.
B
B
A
There's
another
question
here:
you
know
looking
at
drift
prevention
and
obviously
the
the
control
that's
in
place
for
that.
But
someone
was
saying:
wouldn't
the
change
in
the
size
of
the
container
image
be
detected
as
well?
Why
you
know
what
why
do
I
need
to
do
drift
prevention
in
real
time,
and
I
guess
the
you
know
that
is.
Is
that
something
that
you
would
be
able
to
block
in
real
time.
A
B
So
one
of
the
interesting
things
about
container
immutability
is
that
there
are
perfectly
legitimate
reasons
why
additional
files
might
get
written
into
a
container.
B
You
might
have
a
process
that
writes
some
temporary
state
to
a
file
that
it's
just
going
to
have
running
locally
inside
the
there's
just
going
to
store
inside
its
own
file
system,
so
that
would
affect
the
size
of
the
running
container
instance,
but
it
wouldn't
necessarily
be
executable,
and
it's
really
only
execution
that
you
care
about
you
care
about
an
attacker
getting
into
a
container
actually
executing
something
inside
that
can
they
have
to
be
able
to
execute
something
in
order
to
extract
information,
and
if
you
can
prevent
them
from
running
those
executables,
then
you
kind
of
won
the
battle
so
actual
file
file
size
is
not
really
not
necessarily
a
strong
indicator
of
compromise.
B
Okay,
all
right
there's
a
ton
of
questions
here.
I.
B
B
So
the
idea
that
before
you
run
a
container,
you
can
make
some
kind
of
policy
checks
on
the
container
image
and
its
configuration
and
decide
whether
or
not
it's
safe
to
run
so
yeah.
There's
lots
of
different
approaches
for
doing
that.
There's
things
like
opa
and
gatekeeper
in
the
open
source
world
binary
authorization
is,
I
think
it's
google's
own
term.
It's
certainly
they
talk
about
binos
in
in
gke,
yeah
and
tools
like
aqua,
have
very
flexible
policy
configuration
so
that
you
can
do
things
like
only
runner
only
allow
containers
to
run.
B
You
know
if
they
meet
a
certain
set
of
criteria
and
you
can
either
prevent
or
alert
on
failure
to
meet
those
policies.
A
So
is
that
related
to
there's
a
question
here
about
using
image
signatures
for
container
integrity?
Is
that
something
you
cover
in
the
book?
Is
that
a
new
development,
and
how
does
that
relate
to
what
you're
talking
about.
B
Yeah,
so
it
relates
to
what
we
talked
about
around
immutability
in
order
to
detect
whether
or
not
execute.
In
fact
you
know
the
demo
that
we
just
showed
there
that
the
and
new
executable
had
been
added.
B
The
aqua
solution
is
sophisticated
enough
to
fingerprint
the
different
executables
so
that
you
can't
just
if
I'd
renamed
that
script
to
I
don't
know
ls
or
something
or
if
I'd
overwritten
a
permitted
executable,
it
would
have
detected
that
it
wasn't
the
same.
The
original
I
knew
it
was
different.
Yeah.
A
B
Yeah,
we're
gonna
have
to
be
writing
a
lot
of
a
lot
of
questions.
Okay,
one
question
here:
does
cute
french
have
support
for
scenario
where
xcd
is
in
a
separate
node
than
the
masternode?
Yes,
the
most
recent
version
of
the
cis
kubernetes
benchmark
has
a
separate
section
for
xcd
and
we
do
run
that
as
a
separate
section.
So
yes,
we
can.
We
can
we
have
that
support.
A
All
right,
great,
so
I'll,
take
this
opportunity
to
thank
you,
liz
for
sharing
the
insights
into
your
book.
Well,
thank
you
for
writing
the
book
and
everybody
can
get
a
copy
of
that,
as
we
said,
either
from
the
handouts
before
you
leave
today
on
the
handouts
panel
or
online
from
from
aqua
sect.com,
you
can,
you
can
download
it
from
there
and
but
we
appreciate
you
taking
the
time
to
take
people
through
some.
A
This
is
just
some
of
the
checklist
items
that
that
are
covered
in
the
book
and
there's
obviously
a
lot
more
depth
on
each
of
these
in
in
the
various
chapters.
So
thank
you
again
for
sharing
with
it
sharing
sharing
that
with
us
today.
There
are
a
couple
of
other
things
for
those
of
you
on
the
webinar
who
are
looking
for
a
next
level,
even
beyond
container
security
and
just
continuing
your
evolution
here.
A
If
we
could
go
to
the
next
slide,
we'll
share
a
couple
of
other
resources
that
you
could
be
looking
at
here
has.