►
From YouTube: Kubernetes Base Images
Description
Join our Office Hours to get your K8s base images questions answered. In this workshop, we will discuss the security-relevant attributes of your base images and show you the steps you must take to understand and minimize your security risk.
A
Hello:
everyone
thanks
for
joining
the
stackrock's
office
hours
for
august.
This
is
chris
porter,
I'm
the
director
of
solutions,
engineering
at
stack
rocks
and
I'm
going
to
be
your
moderator
today
for
office
hours.
I
have
andy
clemenco
joining
me.
Subject
matter
expert
on
docker
images
and
he's
also
solutions
engineering
here
at
stack
rocks
the
topic
is
kubernetes
based
images,
but
before
we
get
started
with
the
actual
webinar
today
I
just
want
to
go
over
some
rules
of
engagement.
You
may
have
noted
that
your
blinds
are
muted.
A
The
session
is
being
recorded,
so
we'll
send
out
the
link
to
the
on-demand
recording
everyone
after
the
event,
but
we
do
want
live
questions
throughout
the
session.
So
please
post
those
questions
in
the
q
a
module
somewhere
on
your
screen,
although,
if
you're
having
problems
with
the
screen
and
seeing
some
of
the
panels,
we've
noticed
that
refreshing.
A
Your
browser
screen
in
the
in
the
ui
here
does
work
so
give
that
a
try
if
you're
having
any
challenges
we'll
try
to
get
to
those
questions
we
may
not
get
to
all
of
them
if
we
can't
get
to
all
of
them
in
today's
session.
What
we'll
do
is
reach
out
afterwards
to
try
to
get
those
questions
answered
for
you
as
well.
So
let's
get
started
andy.
Thank
you
for
joining
me
today.
Looks
like
we've.
A
A
A
B
Absolutely
yeah
so
so
base
images
really
are
the
foundation
for
all
of
your
docker
images,
whether
you
realize
it
or
not.
It's
the
real
starting
point
and
it's
really
based
on
docker's
copy,
on
right
kind
of
concept
with
the
file
systems,
where
you
have
to
start
with
something
and
really
when
you
start
looking
at
base
images
what
you
ultimately
get
while
it's
based
on
a
alpine
centos,
rel
or
ubuntu
or
debian.
B
While
it
looks
like
it's
an
operating
system,
it's
not
so
chris
go
ahead.
Chris
post,
someone
posted
the
the
slide
notes,
I'm
actually
working
off
of
a
github
page
from
github,
slash,
filemaker
office,
underscore
hours
underscore
20.,
and
I'm
going
to
be
referring
to
this,
and
I've
got
some
examples
in
this
talking.
Let
me
go
ahead
and
just
kind
of
pick
over
to
it.
B
So
this
is
the
page
I'm
working
off
of
and
really
we're
kind
of
asking
some
of
the
basic
questions
here
like
what
is
the
base
image,
but
really
at
the
core.
A
base
image
should
be
a
shell
and
a
package
manager.
That's
it
a
lot
of
times.
We
get
organizations,
we
get
companies,
we
get
security,
folks,
say
well,
but
but
it's
an
operating
system.
How
do
I
secure
the
operating
system
inside
that
base
image?
And
it's
not
plainly
put
it's
a
shell
in
a
package
manager.
B
B
You
don't
want
to
ship
python
and
compilers
that
aren't
absolutely
necessary,
because
if
someone
were
to
compromise
that
process,
that's
running
in
there
there's
a
potential,
they
could
use
that
for
horizontal
movement
and
that's
obviously
not
what
we
want
to
do,
especially
working
at
a
security
company.
So
you.
A
B
B
There
you
go.
That's
the
right
one!
Okay.
What
we
can
see
here
is
that
if
it
take
case
in
point,
if
you
look
at
the
centos
based
image,
so
this
is
pulled
right
from
docker
hub
okay,
this
is
upstream,
as
they
say,
centos
it's
215
megs.
Well,
I've
got
this
test
sentence.
What
I
did-
and
this
is
actually
linked
in
the
github
page-
is
I
took
that
base
image.
B
I
ran
yum
update,
that's
the
first
thing
I
always
like
to
do.
I
always
like
to
make
sure
that
the
image
is
fully
updated.
Actually,
here
we
can
do
it
from
here
center
dockerfile.
Okay,
what
I
do
is,
I
run
a
yum
update.
I
want
to
make
sure
that
that
image
is
updated
and
really
what
what
I
hope
did
you
take
from
this
is
every
organization
needs
to
establish
a
set
of
base
images
if
you're
fine
with
upstream,
because
of
what?
B
What
applications
you're
building,
as
you
start
to
get
more
secure
as
it
starts
to
get
closer
to
production,
you
may
want
to
think
about
establishing
your
own
organization's
base
images.
Okay,
in
this
case,
yum
update
right.
I
want
to
make
sure
that
if
centos
hasn't
been
updated
in
a
month,
I'm
getting
the
latest
yum
I'm
getting
the
latest
packages
available.
I
want
to
make
sure
I've
always
got
this
available.
B
B
If
you
notice
that
image
size
was
215
megs,
a
big
chunk
of
that
is
python.
Okay.
What?
If
you
could
remove
python
from
your
base
image?
Okay!
This
is
a
really
good
point
to
start
thinking
about
other
base
images
right,
basically
based
on
alpine
or
debian,
really
also
it
kind
of
comes
down
to
what
package
managers
is
your
organization
comfortable
with
I
come
from
a
federal
background.
I've
been
a
former
dod
contractor.
B
I've
been
dealing
with
in
the
fed
space
for
10
15
years
now,
and
they
have
a
mandate
mandate
is
thou
shalt
run
rel,
okay,
great.
Maybe
we
can
use
the
centos
version.
Maybe
we
can
start
to
look
at
some
of
the
other
images
case
in
point.
Red
hat
has
a
ubi
base
image?
Okay,
there's
some
significant
differences
about
ubi
versus
rel
versus
centos.
B
Okay,
in
terms
of
the
decision
making
points,
if
you're
looking
at
a
real
base
image
rel
can
only
you
can
only
run
yum
update
in
a
rel
container
if
you're
running
on
a
rel
host,
it's
an
interesting
fact
and
you
need
red,
hat's
engine,
red
hat's
version
of
docker
or
red
hat's,
run
c
or
red
hat's
container
d
cree.
I
o,
I
think,
is
what
what
they're
calling
it
now.
B
B
How
do
we,
how
do
we
really
reduce
the
surface
area
even
further?
One
of
the
things
that
I
haven't
put
on
the
github
pages.
I'm
going
to
update
shortly
is
this
idea
of
multi-stage
images,
so
you
install
your
apps
in
the
first
stage,
then
only
copy
those
bits
over
to
the
second
stage
I'll
go
ahead
and
add
one
to
the
repo
shortly.
So
you
can
see
that
there's
a
lot
of
different
decision
points,
one
of
the
other
favorite
ones
that
I
do
love
is.
B
If
you
look
at
alpine
alpine's,
my
favorite,
I
pretty
much
only
build
off
alpine.
The
base
image
is
six
megs.
Okay,
one
of
the
main
reasons
that
they
did
six
megs
is
they
don't
have
python?
They
don't
have
a
big
package
manager
and
they
use
they
don't
have
glibc,
they
use
muslim
c.
They
use
a
much
smaller,
smaller
c
library
and
one
of
the
one
of
the
reasons
why
they
do.
That
is
because
alpine
was
originally
intended
for
iot
devices:
small
tiny
storage,
footprints,
small
tiny
memory
for
prints.
A
Interesting,
so
the
choice
of
base
image
there's
a
lot
that
goes
into
it.
It
might
be
something
that
your
organization
just
has
chosen.
You
know
a
vendor
that
they're
familiar
with
and
that
continues.
You
know
if
you're
using
it
on
vms
in
a
data
center,
you
might
be
required
to
use
that
for
containers,
but
it
could
also
come
down
to
minimizing
that
surface
area
like
smaller,
more
efficient,
less
you
know,
less
stuff
means
more
secure
right
and
then
it
might
be.
B
That's
a
pretty
good
summary.
That's
a
really
good
summary.
The
other
thing
you
want
to
start
looking
at
is
layers
right,
the
more
layers,
the
more
crop
you
can,
potentially
the
more
tech
that
you
really
have,
because
one
of
the
interesting
things
about
images
is
if
I
go
and
build
python
or
something
on
top
of
a
base
image.
Now
I've
got
layers
well
that
yum
update.
I
had
yeah
I'll
pull
it
back
up
again
that
yum
update
this
run
actually
creates
a
layer.
B
Okay,
one
of
the
things
I
do
recommend
is
is
an
experimental
feature
with
docker.
It's
been
there
for
years,
but
a
dash
dash
squash.
So
now
I
can
say:
okay,
I
can
do
a
bunch
of
things.
I
can
make
a
bunch
of
layers,
but
then
I
squash
it
and
I
get
rid
of
the
old
files
because,
even
though
you
do
a
yum
update,
if
you
don't
squash
those
layers
that
old
file
still
exists
on
a
lower
layer,
while
it's
not
visible,
it
can
still
show
up
in
security
scanners,
they
can
still
cause
storage
debt.
A
Interesting
now
I
think
you're
doing
here
speaking
of
security,
I
think
you're
doing
here
what
a
lot
of
people
are
doing,
which
is
pulling
down
the
latest
version
of
a
centos
or
an
ubuntu,
or
something
from
a
public
docker
hub
and
just
using
that
right,
it's
probably
a
very
common
practice.
Is
there
security
risks
to
doing
that,
just
choosing
a
popular
base
image?
How
do
I
find
out
like
if
how
do
I
even
understand,
like
the
things
that
you
talked
about
like
what's
installed
in
that
image
and
where's
the
security
problems
with
it?
B
Yeah,
that's
actually
a
great
point.
One
of
the
things
I
do
recommend
is
actually
an
interesting
little
application
called
dive.
So,
let's
look
into
dive.
Dive
literally
is
like
file
commander.
It
is.
It
is
a
way
that
you
can
actually
look
at
into
the
images.
So
this
is
taking
a
second,
it's
a
larger
image.
Okay,
you
can
actually
go
and
see
all
the
different
layers
and
all
the
different
files
built
in
into
the
image.
B
So
this
is
a
great
way
to
kind
of
inspect
it,
but
you
know
when
you're
pulling
from
upstream,
you've
really
got
to
think
about
this
idea
of
trust,
but
verify
you
really
want
to
make
sure
that
is
the
correct
image
you
can
look
at
hashes,
there's
a
good
way
to
do
it,
but
also
inspect.
What's
in
there.
The
other
thing
I
would
do
especially
start
bringing
talking
about
bringing
images
into
your
own
organization
automate
it
have
it
run.
You
know,
pull
the
image
in
every
friday
night
have
that
freshness
guarantee
that's
in
there.
A
Tips
right,
interesting,
yeah,
okay,
absolutely
so!
I'm
gonna
pause
this
here
for
a
moment
because
I
almost
forgot
we
have
a
couple
of
polls
for
the
audience
here,
just
to
kind
of
set
the
stage
for
you
know
where
what
your
experience
level
is
and
how
much
you're
doing
here.
I
apologize
that
I
forgot
to
do
this
one
at
the
beginning
here
we're
going
to
pop
up
a
poll
question
and
give
everyone
a
little
bit
of
time
to
read
and
answer
that
poll.
A
We'll
have
a
couple
more
towards
the
middle
and
end
of
the
the
presentation
here,
but
we
just
want
to
know
what
your
relative
experience
level
is
with
with
kubernetes.
So
the
first
pool
question
is:
are
you
running
kubernetes
today
in
production,
meaning
that
you
have
a
you
know:
production
user,
facing
application,
that's
running
in
kubernetes.
A
A
B
A
All
right
so
everybody's
finished
with
the
poll.
I
hope
look
at
that.
So
this
is
great
sixty-four
percent
of
your
report
running
in
production
today,
that
is
awesome.
Yeah
we've
been
doing
this
poll
at
events
for
quite
a
bit
and
slowly
seeing
that
tick
up.
I
think
we,
you
know
we
crossed
50
percent
late
last
year
and
we're
seeing
more
and
more
organizations
depending
on
kubernetes
for
for
their
production
workload.
So
that's
great
very
much
appreciate
it
still.
A
A
Some
of
these
organizations
produce.
You
know
a
curated
image
right.
It's
an
image
like
you
pointed
out
that
they
don't
have
a
kernel
in
them,
but
they
have
a
lot
of
other
stuff
and
we
see
some
of
the
cloud
providers.
Some
of
the
application
platforms
build
these
curated
images
that
you
know
designed
just
to
be
used
in
containers.
Is
there
any
advantage?
Is
there
you
know,
I
can
see
them
being
smaller?
Is
there
a
security?
B
B
You
know,
there's
a
bunch
of
the
knit
stuff
there's
ip
routes,
log
rotate.
These
are
things
that
you
don't
necessarily
need
in
the
image
right.
So
so
again,
I
think
it
goes
back
to
that
trust,
but
verify
use
a
tool
like
dive
or
go
or
dig
into
the
image
itself,
put
it
through
an
image
scanner
to
make
sure
that
there
aren't
cvs
if
you're,
using
a
cloud
provided
resource
again
trust
but
verify
you
know
these
are
things
you
have
to
consider.
B
There's
a
really
interesting
point
here
around
pki
this,
the
the
root
ca
certs.
I
know
from
where
I've
worked
in
the
past
that
that
getting
root,
ca,
certs
into
a
container
is
kind
of
a
pain
it
has
to
be
added
later.
It
has
to
be
kind
of
managed
what,
if
your
organization
could
baseline?
All
of
your
images
to
add
in
your
internally
signed
work
cas
right,
add
in
your
internal
certs
such
that
for
the
developer.
A
Unfortunately,
that's
a
great
statement
to
make
because
we
do
have
a
question
here
about
securing
images
from
the
openshift
catalog.
You
know,
and
I'm
assuming
these
are
the
rel
provided
or
that
have
provided
base
images
that
they
they.
You
know,
ship
with
the
openshift
platform,
and
so
the
question
is
like:
what
do
I
do
to
examine
and
and
secure
those
you
know
like
how
do
I
trust
that
this
curated
platform
is
secure.
B
Yeah,
there's
two
there's
two
real
ways.
The
way
I
see
it,
the
first
one
is
one
look
at
a
tool
like
dive,
again
trust
but
verify
don't
take
red
hat's
word
on
it,
use
dive
and
actually
go
in.
Look
at
the
current
layer
comment.
Contents.
Look
at
the
image
contents
ask
yourself:
why
is
this
image?
203
megs?
B
Well,
you
start
to
drill
in
it's
got
stuff
for
java.
It's
got
stuff,
for
it's
got
an
init
d.
I
don't
need
an
nfd
when
the
idea
of
a
container
should
be
one
process.
One
container
right
again,
it's
got
the
pki
stuff,
I'm
just
scrolling
through
here.
Maybe
there's
stuff.
Here
you
don't
need,
maybe
there's
stuff
here
that
is
just
potentially
causing
surface
area.
My
my
just
to
kind
of
prove
to
you
control
c.
B
All
right,
first
name,
fingers
right.
Do
I
want
python
in
my
base,
image
should
be
python3,
but
you
get
the
idea
right.
Do
I
want
an
interpretive
compiler
in
there,
even
though
that
you're
getting
java
from
openshift
or
some
other
fancy
upstream
language,
trust
but
verify
the
other
thing
you
want
to
do
is
maybe
put
it
through
a
cv
scanner
just
to
make
sure
that
you've
got
the
latest
that
there
aren't
glaring
cvs.
B
I
know
from
my
previous,
I
know
from
my
previous
experience.
There
are
cves
that
red
hat
will
not
fix
right.
So
these
are
things
that
you
have
to
kind
of
understand,
and
this
is
where
I
hate
to
do
the
shameless
plug,
but
this
is
where
having
a
security
platform,
just
to
kind
of
do
that
trust
but
verify
on
the
vendors
base.
Images
is
a
good
way
to
go.
A
Good,
I
think
I
think
that's
you
know
it
certainly
is.
Ignorance
is
not
bliss
here
right
that
not
knowing.
What's
in
your
containers,
you
got,
I
mean
we
can
look
through
that
one
image
and
just
look
at
through
the
file
system.
We
can
see
three
or
four
big
security
no-nos
in
the
base
image
that
you're
pulling
from
a
public
source.
So
that
answers
my
question
of,
should
you
just
blindly
trust
the
source-based
images
and
and
yeah,
probably.
B
B
B
A
A
There's
another
slight
dva,
you
know
a
slightly
off-topic
question,
but
a
good
one.
What
do
you
think
about
flat
car
as
a
replacement
for
for
core
os
running
for
running
the
containers?
I
know
that
we've
had
a
lot
of
customers,
who've
been
running
core
os
and
now
that
there's
not
a
public
free
version
of
that
I've
been
switching
to
flat
car
any
opinions
there.
B
B
But
I
think
it's
actually
a
really
good
option.
You
know
find
a
good
host
os
find
a
good
kubernetes
distribution.
There's
some!
I
don't
know
if
anyone
saw
the
news.
K3S
just
got
submitted
as
a
sandbox
project
to
cncf
over
the
over
the
week.
So
there's
a
lot
of
good
linux
linux
distributions
out
there.
There
are
a
lot
of
good
kubernetes
distributions
out
there
and
again
reduced
surface
area.
A
Okay,
well,
let's
get
back,
there's
some
really
good
questions
here
about
images.
So
let's
talk
about
that.
Let's
stay
on
topic
here
and
so
somebody
post
posted
here
that
we're
using
they're
using
cis
benchmarks
for
secure
operating
system
configuration
right
and
those
are
usually
you
know.
I
see
those
targeted
at
vms
right
so
in
a
vm
running
an
ansible
recipe
to
make
the
changes
that
are
needed.
A
B
Well,
didn't
we
talk
about
a
base
image
as
being
a
shell
and
a
package
manager?
Oh
okay,
right!
So
there
really
isn't
an
operating
system
there
to
harden,
but
there
actually
is
value
and
let
me
show
you
kind
of
a
docker
image
right:
a
docker
file.
There
is
value
in
additional
configuration
hardening
of
like
nginx
or
node.js,
or
some
of
the
platforms,
some
of
the
actual
application
stuff.
B
After
the
fact,
what
I
would
do
is
probably
load
the
ansible
stuff
in
and
then
use
a
multi-stage
build
to
make
sure
that
the
ansible
artifacts
are
out
of
the
image
right
or
what
I'd
actually
do
is
translate
that
ansible
recipe
into
a
rum
line
right
so
have
the
ability
to
add
an
additional
run
step,
and
so
now
I
don't
have
to.
I
have
to
do
a
one-time
translation
from
my
ansible
logic,
business
logic
to
my
container
business
logic,
but
at
the
end
of
the
day,
it's
the
same
kind
of
steps.
It's
it's
hardening.
B
A
Right
so
it
seems
like
the
cis
benchmarks
that
are
intended
for
virtual
machines.
You
know
for
servers
that
you're
going
to
run
for
multiple
purposes
are
only
going
to
have
some
applicability
they're,
just
not
going
to
be
completely
applicable
in
those
environments,
but
it
is
still
possible
to
run
some
of
those
controls
against
the
container
image
because
well
you
can
run
scripts
and
additional
builds
in
the
multi-stage,
build
and
run
commands
right.
It
may
not
be
worth
the
time,
but
it
can
be
done.
Okay,
you
know.
B
A
B
A
B
Think
really,
I
think,
really
one
of
the
key
takeaways
of
like
of
those
standards
really
is
where
do
you?
When
do
you
apply
it?
Where
do
you
apply
it
right?
It
may
make
sense
to
harden
stuff
earlier
on,
there's
a
project
I'm
working
on,
I'm
not
going
to
go
into
great
detail.
I
said
I
would
shame
some
some
some
bad
practices,
but
a
certain
vendor
installs,
a
bunch
of
ansible
stuff
in
a
docker
image.
A
Problem:
here's
a
good
question:
what's
the
most
secure,
minimal,
jdk
based
image,
you've
seen
so
for
running
java
applications?
My
only
experience
with
with
some
of
these
minimal
base
images
has
been
from
google,
and
I
know
google
has
a
secure
distro
list
base
image
as
they
call
it
for
a
lot
of
different
runtime
environments
and
java
is
one
of
them,
so
is
python
and
go
and
the
like
any
other
suggestions
for
running
java
as
minimally
as
possible.
B
So
so
my
personal
opinion,
just
to
give
you
a
little
background
before
I
came
to
stack
rocks,
I
worked
at
docker
for
almost
for
three
and
a
half
years
and
really
the
decision-making
process.
I've
given
dockercon
talks
on
this.
The
decision-making
process
should
be.
Is
it
a
validated
docker
certified
upstream
image?
In
this
case
oracle
jdk
is
the
second
thing
to
think
about.
Then,
if
it's
not
certified,
is
it
from
the
community
right?
Is
it
a
verified
publisher,
or
is
it
an
official
image?
These
are
vetted
by
docker.
These
are
vetted
by
the
community.
B
This
is
a
good
place
to
start
right.
So
so,
if
there
is
a
security
issue
upstream
will
fix
it
relatively
quickly,
so
you've
got
jdk,
which
is
the
docker
certified,
and
I
know
they're
not
100
compatible,
so
bear
with
me,
but
open
jdk
and
the
type
is
another
good
option
right
and
with
each
publisher,
so
oracle
versus
open,
jdk
they're
going
to
have
in
their
description
they're
going
to
have
like
recommendations
right.
B
B
B
A
Going
through
docker
hub
propped
another
question
here
from
from
me:
actually
is:
how
do
I
know
these
organizations
are
keeping
them
up
to
date?
Like
do
I
just
go
by
the
dates
that
these
were
created?
Can
I
trust
that
they're
resolving
vulnerabilities,
just
kind
of
assume
that
it's
going
to
be
it's
going
to
be
safe
to
run?
Do
I
trust
anybody
in
this
case.
B
The
short
answer
is
no
it's
that
trust
but
verify
right,
so
I
I
would
run
it
through
a
cve
scanner
just
because,
just
because
someone-
potentially
you
know,
gives
you
an
image
that
says
it's
the
newest
one.
It
came
out
today,
don't
assume
it's
the
latest
one
right
running
it
through
a
cv.
Scanner
will
be
a
good
way
to
tell.
B
Is
someone
trying
to
do
a
replay
attack
against
you?
Is
someone
trying
to
send
you
an
old
version
right?
That's
that's
kind
of
a
litmus
test.
Another
thing
to
do.
There
are
some
tools
that
you
can
enable
called
notary,
so
notary
you
can
actually
turn
on,
and
that
does
cryptographic
verification
that
that
is
the
correct
image.
But
again,
if,
if,
if
a
provider
upstream,
if
a
community
upstream's
like
let's
repackage
job,
you
know
speaking
of
java
java
1.3
and
call
it
the
latest
greatest,
that's
a
problem
right.
A
B
There's
really
now
we're
getting
into
the
ci
realm
of
things
and
it,
and
there
are
a
lot
of
different
ci
tools
out
there
I
mean
I
can
use
cron
tab
in
a
well-written
bash
script.
I
can
use
jenkins
really.
I
would
probably
lean
more
towards
the
formal
ci
things,
because
then
you
can
feed
those
into
other
systems.
B
Create
web
hooks
link
jenkins
to
your
ci,
to
your
version,
control
system,
say
github
git
lab
whatever
you
got
local
right
and
then
that
way,
anytime,
an
infrastructure
person
updates
that
base
image
docker
file
case
in
point
the
ones
I
have
in
the
link.
It
automatically
kicks
off
a
build.
So
you
basically
have
two
triggers
you've
got
every
friday
and
when
there's
a
new
version
of
the
docker
file.
A
So
yeah
security
is
about
process
right
that,
if
you're
going
to
use
base
images,
you
need
to
keep
them
up
to
date
and
you're
going
to
depend
on
those
external
sources
for
an
even
better
practice.
You
should
bring
those
into
your
organization,
vet
them,
but
again
keep
them
up
to
date
like
go
through
that
process
on
a
regular
basis.
Remove
some
of
the
additional
attack
surface
that
a
lot
of
these
images
come
from
and
make
sure
that
you're
scanning
them
for
vulnerabilities.
A
B
A
B
Oh
yeah,
here's
there's
one
for
you
eric
really
at
this
point
I
I
love
the
idea
of
the
customize.
You
know
containerize
your
java
coach.
I
love
the
idea
of
the
customize,
but
here's
the
question.
I
have
right.
It
comes
from
google.
Google
wants
to
sell
you
gke,
okay,
are
they?
Are
they
also
adding
things
into
that
image
that
you
may
not
necessarily
know
about?
So
again,
it's
the
trust
but
verify
right.
B
So,
let's
see,
let's
look
at
the
spring
boot
and
let's
see
if
it's
actually
got
a
docker
file,
I
can
review
so
so
it
doesn't.
So
that
makes
me
a
little
concerned
right
off
the
bat
that
I
don't
have
a
doctor
file.
I
can
review
right,
so
this
is
so
basically
what
they've
done
is
they've
created
a
binary.
It
looks
like
right,
maven,
compile,
right,
that'll,
actually,
potentially,
output,
an
image
yeah,
it
outputs
an
image
and
then
you
run,
then
you
cube
cto,
run
the
image
so
where's
that
trust
but
verify
step.
A
That's
a
good
point,
so
maybe
the
yeah,
so
you
know
be
concerned
about
the
lack
of
transparency
and
some
of
these
images
that
are
provided
but
yeah
great
question.
I
really
appreciate
it
and
we've
talked
a
lot
about.
You
know
securities.
Obviously,
what
we're
doing
here
at
stackrocks
is
security
for
images
and
a
lot
of
what
we
talk
about
is
you
know,
trying
to
maintain
the
flexibility
that
kubernetes
offers,
but
not
just
blindly
trusting
those
sources,
and
I
think
a
lot
of
the
suggestions
you've
made
fit
well
within
that.
A
B
A
A
There
we
go
yep,
so
what
I
mean
by
an
active
project,
you
know
it's
essentially,
are
you
looking
at
container
security
solutions?
Are
you
looking
at
you
know,
projects
that
will
will
help
build
better
base
images
or
secure
any
part
of
kubernetes,
and
if
you
guys
have
experience
with
it,
you
can
put
you
know
you
can
answer
that
or
you
can
skip
the
question
altogether,
but
we're
just
trying
to
get
a
survey
for
how
many
folks
think
security
is
important.
A
So
a
lot
of
folks
a
lot
of
folks
with
a
short
time
frame
too.
So
I
really
appreciate
that.
That's
good
again,
it
shows
the
trending
in
the
industry
that
more
and
more
teams
are
thinking
about
kubernetes
and
production,
and
almost
inevitably
that
means
some
question
about
how
to
secure
it.
So
you
know,
base
images
almost
seem
like
they're
the
foundation
of
a
secure
running
application
environment
and
that
the
goals
should
be
to
know
what
you're
getting
know
where
you're
getting
it
from
keep.
It
updated
scan
it
for
vulnerabilities.
A
B
Quite
honestly,
yeah
when
we're
looking
at
base
images,
the
difference
between
a
scratch
and
say
an
alpine
remember:
we
said
that
a
base
image
should
have
a
shell
in
the
package
manager.
Scratch
has
nothing
right.
Scratch
doesn't
even
really
have
a
yeah.
It
has.
Nothing,
doesn't
even
really
have
a
file
system,
and
what
that
does
is
that
gives
you
the
opportunity
to
say
pack
in
a
statically
compiled,
go
library,
the
nice
thing
about
it?
Is
it's
one
file
in
the
container?
That's
it
right!
So
that's
the
ultimate
minimalism.
B
I
I
think,
though,
there's
a
balance
between
what's
useful
in
the
development
side
of
things
versus,
what's
true,
what's
useful
for
production
right,
so
if
you
ever
need
to
get
into
a
container
to
debug
something
locally,
not
having
a
shell
is
a
problem
right,
and
so
this
is
where
this
is.
Where
you're
as
an
organization,
you
have
to
kind
of
understand.
What's
the
operational
security
tempo
that
you
guys
want
to
maintain,
if
I'm
a
fortune,
100
company
say
a
bank,
I'm
gonna,
go,
I'm
gonna,
take
that
slider
of
security
and
put
it
to
like
nine.
B
A
B
Yeah
really
in
in
terms
of
tips,
a
couple
that
kind
of
really
stand
out,
and
I
know
they're
relatively
new.
Sorry,
I'm
looking
at
some
of
the
questions,
they're
pretty
good
in
terms
of
some
of
the
tips,
one
of
the
things
that
I
think
is
kind
of
completely
underrated
that
hasn't
really
been
taken
advantage
of
in
the
last
five
years.
Is
this
idea
of
a
label
and
really
it's
an
opportunity,
as
you
start
to
baseline
images
for
your
organization
or
use
upstream,
or
even
your
final
images
meant
for
production?
B
It's
this
idea
that
you
can
provide
real
metadata
around
what's
going
on?
Where
did
the
image
get
built
from
one
of
my
favorite
ones?
Really?
Is
the
image
source,
and
then
I
love
this
idea
of
the
build,
how
to
build
it
right.
The
other
one
is
also
like
a
build
signatures
and
the
image
authors
right.
Let's
provide
real
information
around
this
image
where
it
came
from
how
it
was
built,
this
one's
even
missing
a
piece
about
what
the
build
server
is.
So
if
you've
got
a
big
build
environment,
that's
fully
automated!
B
B
What's
the
version
control
commit.
This
is
a
way
that
you
can
say.
Okay,
this
image
came
directly
from
this
commit
version
control,
and
now
you
have
the
ability
to
skip
the
tracing
of
like
okay.
I
gotta
go
to
the
build
service.
What
was
the
build
number?
What
was
the
tag
number
and
go
straight
to
version
control?
B
B
I
can
look
at
these
labels
and
say:
okay,
where
did
it
come
from
where's
version
control?
How
did
it
get
here,
and
this
is
the
way
you
can
actually
provide
some
of
that
provenance
back
to
the
image
itself,
so
that
that's
a
big
one?
The
other
thing
obviously
remove
the
package
manager
make
sure
that
you're
you're
pulling
you're
basing
the
images
on
known
good
sources
like
that's
a
good
one.
B
A
A
It
can
help
your
team
identify
like
where,
where
these
things
are
in
use
right,
because
you
can
look
for
the
labels
in
your
running
environment
and
it
helps
you,
you
know
your
teams
understand
the
you
know
any
gaps
and
errors
and
where
things
came
from
when
there's
a
problem,
so
it
seems
like
a
good
all-around
solution
for
productivity
and
and
security,
yes,
and
the
most
important
question
of
the
day.
Why
is
your
room
not
have
any
posters
up
on
the
wall
and
artwork
we'll
send
you.
B
B
If
I
have
a
chance,
I
actually
want
to
go
back
to
notary
real,
quick
one
of
the
interesting
things
about
notary,
I'm
going
to
use
first
names.
It
looks
like
nawab,
went
ahead
and
asked
this
question
notary's
actually
been
built
into
the
docker
engine
for
quite
some
time.
The
way
you
would
actually
turn
it
on
it's
not
on
by
default
is
an
export.
B
When
you
do
this
and
you
do
a
dock
or
pull
it's
actually
going
to
go
ahead
and
verify
so
one
of
the
things
that
it
did
is
it
actually
did
verify
the
image
and
it
says
image
is
up
to
date,
so
we
were
able
to
pull
the
notarized
version,
in
other
words
the
cryptographically
signed
version
of
that
image.
Okay,
now
that
being
said,
kubecon
this
week,
former
co-workers
of
mine
were
presenting
about
notary
v2.
So
so
they
are
trying
to
re-vamp.
B
A
All
right,
so
the
question
is
pace
of
questions
seems
to
have
slowed
down
a
little
bit.
I
guess:
is
there
anything
else
that
you'd
have
for
tips?
We've
talked
about
a
couple
things
about
little
tips
about
building
for
security.
You
know
removing
package
managers.
Maybe
is
there
any
other
software
that
you
would
look
to
remove
to
to
make
your
images
slimmer
and
more
secure
without
breaking
everything.
B
Anything
that
requires
ssh
interpretive
languages
compilers.
How
many
times
have
you
like?
Let's
just
start
with
gcc,
because
we
have
to
compile
something
in
the
container.
That's
a
really
bad
idea.
That's
that
screams
out
a
multi-stage,
build
where
you
compile
in
the
first
stage,
then
you
only
copy
the
artifact.
B
We
talked
about
the
statically
compiled,
go
binary,
that's
a
great
opportunity
to
build,
in
the
first
stage,
with
a
full
os
with
the
full
go
libraries,
the
compiler
and
all
that
and
then
take
that
one
binary
into
your
second
stage
and
put
it
in
a
scratch
base
for
your
second
stage
and
that
way
it's
super
clean,
and
it's
still
the
same.
It's
literally
one
dockerfile
to
describe
this
entire
motion.
A
That's
interesting
yeah,
so
you
know
general
dev
tools,
don't
belong
in
production
containers
right
ever
ever
yeah
and
that
whole
classification
of
things
and
then
you
know
the
whole
the
whole
minimal
image
thing.
I
mean
I've
been
skeptical
about
using
container
os's
that
look
like
they're,
essentially
vm
images
right
and
they
have
utilities
for
managing
and
maintaining
a
vm
that
you
know,
even
if
they're
not
directly
accessible,
like
sshd
or
they're,
not
running
potentially
represent
risk
for
for
the
software
running
on
there.
A
B
Well,
okay,
so
so
I've
got
I'm
sharing
on
the
screen.
Now
the
multi-stage
build
documentation
from
docker
from
docker's
web.
It's
like
docs.docker.com,
and
what's
interesting,
you
start
to
talk
about
certificates
right
there,
there's
two
sides
to
the
certificate:
there's
a
certificate
and
the
key
certificates
are
supposed
to
be
public
and
the
keys
are
private
right.
So
obviously
you
wouldn't
want
to
put
anything
and
I'm
going
to
use
air
quotes
here,
secret
or
private
within
the
image.
B
You
want
to
pass
that
in
at
run
time,
but
you
absolutely
would
in
this
case,
from
from
an
old
buddy
alex,
you
would
absolutely
use
like
the
full
golang
and
you
could
name
it
as
builder.
You
would
use
the
full
go
link
for
your
build
environment.
Then
he
creates
that
statically
compiled
go
library
and
then
the
second
stage
he
copies
it
in,
but
he
does
something
interesting.
A
B
Right
and
absolutely
like
every
enterprise
I've
dealt
with
from
banks
to
pharmaceutical
to
governments
have
an
internal
certificate
authority.
You
would
absolutely
put
the
root
ca
for
that
in
your
base
image
right
that
that
way,
any
time
a
developer
goes
to
use
whether
it's
a
jdk
service,
an
https
service,
whatever
anything
tls,
it's
already
got
the
root
ca,
so
it
can
validate
connections
from
outside.
Back
in.
A
Cool
all
right,
so
we
are
winding
down
here,
looks
like
the
questions
have
stopped
hit
us
up
if
you've
got
anything
live,
but
while
we're
waiting
for
that,
we'll
go
with
the
last
polling
question
here
that
we
have
ask
you
a
little
bit
about
your
environment
and
and
security
use
cases.
We're
talking
a
little
bit
today
about
things
like
vulnerability
management,
but
obviously
there's
quite
a
few
more
topics
under
the
subject
of
of
security.
So
we
appreciate
your.
A
All
right
so
compliance
and
vulnerability
management,
yeah,
that's
yep!
That's
pretty
interesting
compliance,
I'm
assuming
you
know
we
have
folks
on
that
are
probably
subject
to
industry
or
government
regulation
and
it's
a
hard
topic
inside
of
kubernetes.
You
know.
Certainly
we
have
some
resources
on
that,
not
a
topic
that
we'll
address
today,
but
that
feedback
is
very
valuable
to
us.
So
it
tells
me
that
we've
been
we've
been
thinking
about
and
talking
about
the
right
topics
when
it
comes
to
kubernetes
security.
A
B
In
other
words,
you
need
to
automate
everything,
because
at
the
end
of
the
day,
when
you
want
to
go
on
a
vacation
and
if
it's
automated
right,
you've
removed,
as
they
say
in
the
government,
the
insider
threat
potentially
but
but
you've
automated
everything
to
the
point
that
that
it's
very
hard
to
inject
errors
and
problems
right,
no
human,
no
human
yeah
hold
on.
We
got
one
more
question.
B
B
Any
suggestion
to
keep
multiple
to
keep
multiple
levels
for
base
images.
Actually,
yes,
there
is
a
potential
right,
let's
say
for
example,
instance:
your
organization
is
a
heavy
java
user
or
a
heavy
something
user
right,
no
js
doesn't
matter
whatever
the
framework
is,
there's
an
opportunity
to
not
only
maintain
the
base
image
with
some
techniques
right,
removing
the
package
manager
but
then
also
create
a
java
based
on
it
right
or
a
node.js
based
on
it.
But
here's
the
trick
right.
Remember,
I
said
no
human
should
build
a
deployment
for
production.
B
You
automate
the
base
at
the
same
time,
ten
minutes
after
five
minutes
after
you
build
your
base.
You
then
need
to
build
the
next
level
and
then
build
the
next
level,
so
you
can
tear
these
things
out
and
make
them
dependent
as
long
as
you
automate
it
as
long
as
you
make
sure
that
that
build
trigger
for
the
second
level
is
immediately
after
the
first
one
builds
and
is
validated.
A
Makes
sense
makes
sense
to
me.
Thank
you,
everyone
and
thank
you
andy,
especially
for
your
insights
folks
feel
free
to
reach
out.
If
there's
any
questions
that
we
didn't
get
answered
or
you
didn't,
you
didn't
get
a
chance
to
ask
we'd
be
happy
to
you
can
find
us
at
stackrocks.com
and
we'll
send
out
the
recording
and
the
event
again
thank
everyone
for
attending
and
we'll
catch
you
in
the
next
office
hours.