►
From YouTube: Automating Secure Configuration for OpenShift
Description
Red Hat OpenShift uses a declarative model for configuring workloads and comes with specific controllers to ensure the observed state adheres to the desired workload configurations.
Securely configuring workloads is one of the key elements of protecting containerized applications in OpenShift. Customers can leverage built-in controls in the OpenShift platform to provide developers and security teams with security guardrails. When there is a configuration drift, these controls can be used to ensure prompt remediation.
Learn how to go beyond image scanning and extend security to the deploy phase of OpenShift applications where workloads are configured. We will show you how to:
- use access and authorization controls to protect your OpenShift clusters from unauthorized access
- reduce your attack surface and mitigate lateral movement by implementing workload isolation using network policies
- embed configuration checks into the build pipeline to shift security left
take advantage of Kubernetes-native controls for better policy enforcement
Join us to see a demo of how to leverage the built-in OpenShift capabilities and Red Hat Advanced Cluster Security for Kubernetes to build and deploy a more secure application.
A
Hey
good
afternoon
or
good
day,
wherever
you
are
thanks
for
joining
us
for
the
office
hours
today
joining
me
is
chris
porter,
my
both
my
boss
and
my
my
colleague
here
at
red
hat.
We
wanted
to
talk
about,
follow
up
on
on
last
week's
conversation
about
shifting
security
left
into
ci
cd
and
talk
about
really
the
next
stage
of
that
automating
secure
configuration
for
openshift
workloads.
A
B
What
else
can
we
do
like?
How
do
we
get
security
if
we
can't
rely
on
that,
so
I've
got
some
short
demos
a
little
bit
of
a
discussion.
We're
gonna
talk
not
today,
primarily
about
vulnerability
management
and
then,
of
course,
you
and
I
can
handle
questions
from
the
audience
here.
So
folks,
you
know
we're
live,
but
all
the
lines
are
muted
here.
B
But
I
thought
maybe
we'll
start
with
just
explaining
what
we
mean
by
secure
configuration
for
workloads.
This
is
something
that's
at
the
heart
of
what
stack
rocks
was
founded
to
do
is
to
recognize
that
you
know.
Kubernetes
platforms
like
openshift
have
a
lot
of
complexity,
there's
a
lot
of
controls
available
and
when
you
adopt
this
platform,
you
end
up
handing
a
lot
of
that
control
over
to
the
developers
and
that's
good
from
from
the
you
know:
application
productivity
perspective.
B
You
know
as
a
developer,
I
love
having
a
sandbox
where
I
can
experiment
with
new
capabilities.
I
can
go
out
and
pull
up
pre-built
container
image
and
start
prototyping
something,
but
that
power
also
means
that
developers
can
make
decisions
that
aren't
good
for
for
security
and
and
sacrifice
is
really
founded
around
the
idea
that
we
can
guide.
B
People
towards
you
know,
choosing
better
defaults,
choosing
better
configurations
allowing
the
security
team
to
have
some
visibility
and
some
say
into
that,
and
then
you
know
ultimately
like
stop
people
from
deploying
things
in
a
risky
way
and-
and
things
in
this
case
means
there's
a
lot
of
configuration.
That's
available.
I
also
like
to
talk
about
security
in
in
openshift
as
being
a
way
where
you
know
some
of
the
configuration
and
the
fact
that
you're
running
in
a
pretty
constrained
environments,
containers
really
aren't
vms
and
you
really
shouldn't
treat
them
that
way.
B
You
know
we
can
get
to
better
security
than
you
could
with
with
traditional
environments
right,
I
can
exclude
a
whole
bunch
of
noise
from
virtual
machines
if
I'm
running
a
service
in
a
container
in
a
dedicated
way.
Now
you
know
you
might
choose
a
lot
of
different
tools
that
could
help
you
with
that,
but
we
think
that
just
you
know,
leveraging
what's
built
into
openshift
is
the
right
way
to
do
it.
So
I
thought
I'd
bring
up
a
demo
here
and
I'm
going
to
you
know,
share
my
screen
and.
B
Assuming
that
this
is
going
to,
let
me
there
we
go
so
I
don't
bounce
around
a
little
bit.
Those
of
you
who
attended
some
of
the
office
hours
before
you've
seen
the
advanced
cluster
security
product.
Here
that
we
talk
about
a
lot.
I
want
to
stress
that
a
lot
of
this
configuration
is
available
in
kubernetes
platforms
everywhere
right.
You
know,
obviously,
I'm
a
little
biased
here.
We
think
that
openshift
and
acs
is
the
right
platform
for
visibility
and
control
over
these
things.
B
But
ultimately
the
settings
that
we're
going
to
talk
about
are
are
in
kubernetes
and
they're
in
containers,
and
so
you
know
what
we're
promoting
is
the
idea
of
platform
native
security
controls
that
that
you
can
use
today.
So
we
talk
about
configuration
management,
we're
talking
about
lots
of
different
things
right,
I'm
going
to
assume
that
we've
ignored
neil's,
good
advice
to
use
the
pipeline
to
examine
image
contents
resolve
vulnerabilities,
you
know
and
fix
configuration
issues
right
and
I'm
gonna
say
all
right:
we've
we've!
B
We
don't
have
that
control
in
place
or
it's
been
ignored
or
somehow
something's
bypassed
that.
What
can
we
do
at
that
point?
And
we're
talking
about
lots
of
things,
I'm
going
to
pick
this
one
in
particular.
A
control
available
in
kubernetes
is
in
the
the
pod
security
contacts
when
you're
building
kubernetes
yaml,
you
have
the
option
of
mounting
the
root
file
system
of
the
container
right.
What
looks
like
slash
in
a
linux
file
system
is
a
read-only
file
system.
B
So
this
is
great
because
anything
that
would
that
would
write
to
the
file
system
right
that
might
try
to
overwrite
special
config
files
or
binaries
anything
that
might
try
to
write
like
a
crypto
miner
to
disk
and
run
that
from
from
you
know
what
looks
like
a
disk
is
going
to
be
foiled
with
this,
and
you
know
an
application.
You
don't
really
need
this
right.
You
shouldn't
be
writing
to
that
root
file
system.
B
You
should
be
using
some
other
kind
of
persistent
storage,
so
this
policy,
I'm
going
to
turn
on
and
first
of
all,
we'll
talk
a
little
bit
about.
You
know
what
it's
actually
going
to
do,
but
I'm
going
to
tell
my
development
teams
to
use
read-only
file
systems
right,
in
other
words,
you've
got
to
use
this.
B
You
know
even
things
like
what
network
ports
you're
exposing,
but
let's
take
a
look
at
this
one
with
with
the
real
read
write
file
system.
Now
I've
got
some
excluded
deployments
in
here,
but
as
soon
as
I
turn
it
on
in
acs,
I
can
immediately
go
and
look
and
see.
Oh
boy,
I've
got
a
lot
of
things
that
are
using
a
fully
writable
file
system.
Right
so
this
you
know
this
the
components
here,
even
the
ones
from
from
stack
rocks
right.
We
don't
always
have
that
in
place.
Now.
B
You
can
also
see
that
I
was
running
this
earlier
and
we
attempted
to
use
it
for
a
new
deployment
and
I'll
actually
jump
out
here
and
show
you
that
again,
I'm
ignoring
the
ci
pipeline
here.
I've
ignored
the
security
team's
requirement
that
I
have
a
that.
I
have
a
a
a
read,
only
root
file
system
and
I'm
just
going
to
deploy
this
anyway.
B
So
I'm
actually
using
you,
know
the
kubecontrol
api
here
or
the
openshift
command
line
whatever
to
directly
interact
with
the
kube
api
and
create
an
object-
and
this
is
you
know
another
one
of
those
things
that
we
talk
about
with
with
configuration
security
is
that
you
need
to
have
a
place
of
enforcement.
For
this.
It's
no
good
to
write.
You
know,
information
about
this
violation
to
a
custom
log
or
even
to
send
somebody
an
email,
an
email
or
something
you
need
to
to
dig
into
the
tools
and
provide
enforcement
at
the
cluster
right.
B
I
don't
want
this
thing
to
come
off.
I've
decided
that
you
know
having
a
file
system.
That's
writable
is
a
security
risk
that
I
can't
accept
and
so
we're
using
in
this
case,
the
admission
controller
to
prevent
this
from
coming
in.
So,
ultimately,
you
know
really
simple
and
there's
lots
of
ways
to
do
this
in
in
kubernetes
by
building
your
own
rules,
and
you
know
setting
setting
up
policies
and
other
systems.
B
I
know
pod
security
policies
are
now
deprecated,
but
whatever
way
you
accomplish,
it
ultimately
allows
for
the
security
team
to
set
that
rule.
Now,
if
I
want
an
exception
to
this
right,
that's
a
challenge.
So
you
know
if
I'm
gonna,
if
I'm
gonna
have
an
exception
to
policies,
you
know
that's
something
that
you
have
to
build
into
your
process.
B
Now
I
focused
on
this
one
because
I
really
like
it,
you
know
if
there's,
if
there's
a
secret
to
container
security
and
I'm
not
saying
there's
any
one
secret,
but
if
there
is
one
top
technical
tip
that
we
give
to
everybody,
it
would
be
make
liberal
use
of
this
kind
of
setting
right.
If
your
containers
can't
write
to
the
file
system,
you
can
eliminate
a
whole
class
of
attacks
right,
there's,
other
restrictions-
and
you
know
another
good
tip-
would
be
to
limit
the
egress
on
the
network.
B
For
your
your
your
containers,
those
are
two
configurations
that
you
know,
especially
together,
can
stop
attacks
in
their
tracks.
Right
we've
seen
the
the
increased
attention
on
a
national
level
about
attacks
that
have
happened,
and
you
know
you
definitely
need
to
fix
vulnerabilities
right
and
be
aware
of
vulnerabilities
you.
You
definitely
need
to
have
like
incident
response
teams
that
can
investigate
issues
as
they're
happening.
B
Those
are
the
things
that
get
the
the
you
know
the
highlights,
but
when
we're
talking
about
defense
in
depth
and
just
practical
security,
you
know
stopping
the
attack
chain
by
interrupting.
You
know
any
portion
of
what
goes
on
during
an
attack
is
certainly
you
know
to
our
our
benefit.
In
this
case,
the
readable,
the
rewrite
file
system
is
going
to
stop
any
attack
that
tries
to
write
a
payload
to
disk.
B
B
Maybe
it
is
actually
a
situation
where
you
know
that
container
image
and
its
dependencies
passed
my
check
yesterday
right,
but
today
there's
a
new
vulnerability.
That's
discovered
right
and
you
know
that
new
vulnerability
is
something
that
nobody
had
encountered
before
it's
a
zero
day
and
now
it's
out
there
live
and
I've
got
that
running
in
my
environment.
B
So
the
the
point
about
configuration
here
is
that,
by
limiting
the
privileges,
the
access,
the
rights
of
a
container
using
you
know
these
configurations,
you
can
stop
even
unknown
vulnerabilities
from
being
exploited
right
and
that's
a
really
really
powerful
thing
to
say.
Of
course
we
don't,
you
know
we
don't
want
to
give
up
on
vulnerability
management,
it's
not
wise
to
ignore
heck.
B
A
lot
of
compliance
standards
require
that
you
have
some
diligence
around
examining
vulnerabilities
testing
for
them
resolving
them
within
a
certain
period
of
time,
but
it
would
be
nice
not
to
be
woken
up
in
the
middle
of
the
night
by
one
of
these
new.
You
know
ransomware
crypto
miner,
to
know
that
you've
got
the
protections
in
place
against
an
attack,
even
if
you
didn't
know
which
particular
vulnerability
was
in
use.
B
So
what
I've
got
here
is
actually
a
few
workloads
running
with
our
good
friend
the
apache
struts
framework
and
the
strut's
vulnerability
from
about
three
or
four
years
ago
in
it
I
don't
have
a
zero
day
today,
so
we're
stuck
with
this
one.
Now
this
you
know
vulnerability
is
getting
a
little
long
in
the
tooth,
but
it's
a
really
good
example,
because
it
does
illustrate
you
know
exactly
we're
talking
about
an
easily
exploited
vulnerability
that
allows
for
arbitrary
commands
to
be
run
by
an
attacker.
B
We
know
it's
been
used
in
the
wild,
and
actually
I
discovered
that
if
you
look
at
some
of
the
you
know
the
the
nist
reports,
this
vulnerability
is
still
out
there
in
the
wild
and-
and
it's
still
over
the
last
few
years
has
been
one
of
the
top
most
exploited
vulnerabilities
out
there.
So
I'm
going
to
make
use
of
it
again
and
what
I'm
going
to
do
is
exploit
it
right.
I've
got
a
script
here
that
includes
a
crafted
content
that
is
going
to
deliberately
you
know.
B
Overflow,
the
root
of
it
and
and
it's
going
to
do
is,
go
and
retrieve
a
common
crypto
miner
from
you
know,
from
github
and
and
run
it.
So
this
is
what
was
submitted.
You
know
from
from
my
local
attacker
workstation
to
the
command
and
then
we've
just
gone
and
run
a
ps
in
the
container
to
go
and
see
what's
running
so
we
see
the
java
startup
right.
This
is
the
container
service,
the
entry
point
there
and
now,
of
course,
we
see
that
the
the
crypto
miner
is
running
so
great
right.
B
So
this
means
that
if
the
vulnerability
is
present,
then
an
attacker
is
really
just
going
to
be
able
to
go
and-
and
you
know
flood
me
with-
you-
know,
crypto
miners,
so
the
the
the
next
mitigation
is
that
read-only
file
system
right.
This
is
a
simple
config
that
some
development
teams
will
take
it'll
take
getting
used
to.
But
if
I
run
the
same
exact
thing,
you'll
see
immediately
that
my
download
and
execute
process
is
interrupted
right
now.
B
This
defense,
this
configuration,
doesn't
know
anything
about
crypto
miners.
It
doesn't
know
anything
about.
You
know
the
the
nature
of
the
attack
here.
How
it
got
in
what
we
know
is
just
that
any
attempt
to
write
to
the
local
file
system
is
going
to
fail
right,
and
so
I
get
an
error.
I
see
at
the
end
that
my
process
isn't
running,
and
so
you
know
job
done
right
successfully.
B
B
I
can
connect
out
to
the
world.
I
can
push
and
pull,
but
unfortunately
that's
a
great
way
for
attackers
to
exfiltrate
data
or
for
malware
to
connect
to
command
and
control.
So
this
example
here
is
the
same
container
same
same
deployment
same
java,
struts
framework
in
this
case
with
a
writable
file
system.
B
Again,
I'm
not
going
to
suggest
that
you
should
ever
stop
doing
vulnerability
scanning
and
fixing
vulnerabilities.
But
here
I've
got
a
you
know
a
four-year-old.
You
know
vulnerability
sitting
here
and
I'm
able
to
you
know
with
a
single
configuration
you
know.
All
I
got
to
do
is
interrupt
that
one
step
in
the
chain:
either
the
right
or
the
communicate
outwards.
A
B
Here
we
go
switch
over
so
some
of
the
the
policies
here
and
and
there's
a
whole.
You
know
we've
talked
about
this
before
in
other
office
hours.
You
know
the
policy
language
here
is
designed
to
cover
the
full
life
cycle,
so
you
know
more
or
less
anything
that
we
touch
when
it
comes
to
the
image
its
image
contents
container
configuration
metadata
that
that
we
could
think
of
that
would
have
some
security
interest
is.
Is
here
so
you
know
we
talked
about
image
contents
quite
a
bit
on
other
other
sessions
right.
B
This
is
what's
in
my
image:
what
are
the
dependencies
and
objects
in
there
and
what
is
the
vulnerability
data
associated
with
it,
but
for
deployment
and
container
metadata
that's
passed
in
as
part
of
my
kubernetes
deployment.
You
know
almost
anything,
you
know
operational
characteristics
like
cpu
and
memory
right.
B
We
think
these
are
important
for
security,
because
that
crypto
miner,
that
compromises
a
container
running
in
kubernetes,
is
potentially
going
to
be
able
to
get
all
of
the
cpu
that
the
node
that
it's
on
right
kubernetes
will
happily
handle
hand
over
any
amount
of
resources
that
it
requests
unless
we
limit
it
in
some
way.
So
again,
another
proactive
control
that
we
can
put
in
place
would
be
to
limit
how
much
cpu
and
memory
a
given
you
know
given
pod
can
occupy
again.
It
can
be
challenging
at
times
it
can
be
hard
to
understand.
B
B
B
Unfortunately,
the
defaults
in
in
docker
and
kubernetes
give
a
little
quite
a
bit
of
privilege
to
to
containers
right
and
if
a
container
doesn't
need
to
do
things
like
you
know,
schmod
files
right,
we
can
remove
those
or
drop
everything.
Essentially,
you
know
and
give
the
the
kernel
capabilities,
just
you
know
very
minimal
set.
In
fact,
the
best
way
to
do
it
is
to
drop
all
capabilities
and
then
you
know,
add
the
specific
ones
that
are
that
are
necessary.
B
But
again,
you
know
a
lot
of
developers
find
you
know,
they're
used
to
running
on
a
linux
box
that
has
you
know,
root
access,
they're,
not
really
sure
what
their
applications
are
doing.
There
are
some
tools
out
there
to
help.
You
understand
exactly.
You
know
some
of
the
things
that
you're
using
and
you
know
again
acs-
can
help
you
examine
where
those
configurations
are
in
use
and
what
the
deployment
status
is
some
of
the
other
deployment
metadata.
Here
you
know
things
like
using
host,
pids
and
and
in
a
process
communication.
B
I
don't
see
all
that.
Often
these
are
things
that
will,
unfortunately,
if
you
use
them,
can
break
the
the
container
to
host
isolation.
So
again
you
know
you
don't
see
them
too
often,
labels
and
annotations
metadata
around
your
deployments
can
be
a
really
powerful
security
tool.
We
also
support
here
looking
at
image
labels
and
since
the
beginning
of
the
use
of
docker
containers
in
the
docker
image
format,
teams
have
been
putting
really
valuable
information
in
from
the
pipeline
into
metadata.
B
What
build
was
this
right
like
what
what
team
is
responsible
for
it?
You
know
what
kind
of
application
data
does
it
handle
and
the
metadata
here
can
be
a
really
good
way
to
do
that.
We
also
like
it
of
course
here
in
acs,
because
I
can
do
something
like
a
label
to
tell
me
what
jira
project
is
this
a
part
of,
or
or
what
slack
channel
do.
I
want
to
send
notifications
to
about
it.
So
providing
you
know
configuration
it
helps
me
understand.
You
know
hey.
This
is
this
project.
B
This
is
the
app
owner
and
this
is
how
to
get
hold
of
them.
It's
maybe
not
necessarily
a
direct
security
capability,
but
it
is
something
that
you
know
can
it
can
assist
the
security
team
and
getting
their
jobs
done
so
lots
of
stuff?
You
know,
storage
as
time
goes
on
as
this
product
evolves.
You're
gonna
see
more
and
more
of
this
and
again
in
the
open
source
community,
both
with
the
stack
rocks
product,
which
is
going
open,
source
and
other
tools
out
there.
B
You
know
you
have
access
to
parts
through
just
about
everything
in
the
in
the
kubernetes
yaml
definitions
and
and
invoke
some
security
controls
here
with
things
like
with
storage,
you
know
when
you
get
have
a
persistent
storage
volumes
which
you
should
do,
whether
they're
host
mounted
or
they're.
You
know,
network
mounted
having
specific
storage
volumes
may
be
restricted
right
by
by
application
type.
We
build
a
few
policies
around
certain
host
mounts
right.
Certain
things,
like
you
know,
mounting.
You
know,
run
secrets
where
you
know
secret
information
can
be
stored.
B
A
So
you
showed
you
showed
a
really
interesting
policy
around
restricting
restricting
containers
to
be
deployed
only
with
a
read-only
root
file
system,
but
you
also
showed
a
list
of
many
many
things
in
your
environment
that
violate
that
policy,
and
you
showed
enforcement
of
that
policy
that
that
caused
you
to
not
be
able
to
deploy
something
that
seems
like
you
could
break
your
environment
really
quickly
and
cause
a
ton
of
pain.
How
did
you
manage
that?
What
does
that
look
like.
B
B
So
there's
a
few
things
and
we
didn't
you
know-
go
really
go
into
this,
but
the
policy
language
that
we're
using
the
way
that
we're
doing
this,
like
one
of
the
benefits
of
of
the
acs
product,
is
that
I
can
actually
turn
on
a
policy
without
enforcement
and
turn
that
off
here
I
can
get
a
pre-flight
check.
So
if
I'm
a
security
person-
and
I
come
in-
you
know
to
say-
hey-
I
can
help
improve
security
here.
I
want
to
invoke
this
control.
B
B
B
What
do
I
do
in
its
place
and
they're
going
to
have
to
learn
about
things
like
you
know,
empty
dirt,
right
where,
where
kubernetes
gives
me
a
way
to
mount
a
temporary
file
system
space,
it's
actually
a
better
way.
You
know
if
you're,
if
you're,
currently
writing
to
the
root
file
system,
you're
making
a
mistake
as
it
is
in
a
container
environment,
but
you
know
give
the
teams
time
to
to
understand
that.
So
let's
say
I've
done
that,
let's
say:
we've
got,
you
know
developers
used
to
the
idea.
B
Most
of
my
applications
are
running
with
the
read-only
file
system
still
going
to
have
this
challenge,
where
you
know,
there's
going
to
be
stuff
that
I
don't
have
influence
over
or
I
can't
do
you
know
here's
some
application
or
my
my
wordpress
or
you
know
worse.
Yet
I
find
something
in
you
know
in
stack,
rocks
or
you
know,
acs
or
in
the
in
openshift
or
in
one
of
my
infrastructure
projects.
B
Like
I
don't
know,
my
jenkins
pipeline
is
running
in
let's
say
in
openshift
I
gotta
have
a
writable
file
system,
and
so
we
give
you
a
way
to
make
an
exception.
I
can
go
and
exclude
a
deployment
here
and
and
add
comments
to
that
now.
This
is,
you
know
specific
to
acs
and
it's
pretty
convenient
that
we
can.
You
know,
create
the
the
exclusion
here.
I
can
audit
that
I
will
see
the
results
of
it.
B
You
know
I
can
do
that
with
specific
deployments.
I
could
do
with
specific
namespaces,
so
that
would
come
down
to
the
tooling
there.
You
know,
I
think
that
the
exception
process
is
actually
what
makes
security
so
difficult
right
that
if
I've
got
a
blanket
rule
that
works
everywhere,
that's
great,
but
a
lot
of
rules
don't
work
that
way.
B
I'm
thinking
back
to
when
I
used
to
work
in
things
like
network
intrusion,
detection
you'd
have
rules
that
worked
great
90
of
the
time,
but
the
10
broke
everything
and
you
end
up
turning
those
rules
off
so
having
a
way
to
keep
it
on
for
the
90
and
turn
it
off
for
the
10.
You
know,
with
a
documented
exception,
is
a
good
way
to
do
it
and
acs.
You
know
supports
that
kind
of
workload,
but
if
you're
out
there
building
it
on
your
own
and
you're
using
tools,
you
know
that
are
open
source.
B
A
Yeah
and
then
so
let
me
this
is.
This
is
going
to
be
a
last
call
for
any
other
questions.
You
have
please
get
them
in
the
q,
a
and
and
we'll
answer
them.
I'm
going
to
give
you
a
little
bit
of
time
to
do
that,
I'm
going
to
I'm
going
to
throw
a
curveball
at
chris
here
and
and
see
what
two
ways
what
the
answer
is,
but
so
you
know
like
the
read-only
root
file
system.
A
That's
a
great
that's,
a
very
strong
protection,
but
I
get
the
sense
that
that's
a
protection
that
may
break
a
lot
of
especially
legacy
applications
that
we've
dragged
into
containers
applications
by
developers
who
weren't
accounting
for
that
sort
of
thing.
So
it
may
be
a
very
difficult
one
to
get
our
arms
around.
So
with
that
in
mind,
what
what
are
maybe
the
top
three
easy
wins
that
somebody
could
take
to
start
chipping
away
at
security
problems
and
locking
down
configuration
that
wouldn't
be
as
costly
and
difficult
to
get
ahead
of.
B
That's
that's
a
great
question.
I
think
there's
lots
of
creative
ideas
there.
You
know
the
other
one,
the
other
config
I
was
looking
at,
isn't
here
in
policies
at
all,
but
in
the
networking
where
you
know,
I've
got
workloads
that
are
running.
You
know
with
open
networking
and
you
can
see
they're
all
making
connections
out
to
the
internet
right,
but
that
that
egress
policy
of
being
able
to
restrict
all
my
egress
here,
you'll
see
that
you
know
this.
This
shopping
cart.
B
Application
that
I
have
here
has
all
this
this
stuff,
restricting
that
outbound
networking
by
default
at
the
name
space
level
or
on
the
individual
pod
level.
You
know,
I
don't
know
if
it's
easy,
but
it
is,
it
is
a
control
that
you
can
put
in
place
that
that
will
that
will
be
will
be
pretty
effective.
B
B
You
know
the
vast
majority
of
these
are
not
state-funded
actors,
they're,
not
sophisticated
apts
right.
They
are
just
looking
for
any
opening
out
there,
and
one
of
the
best
things
you
can
do
to
make
their
job
harder
is
not
give
them
tools
on
the
container
like
package
managers,
compilers
network
utilities,
you
know
things
like
curl
and
wget
are
really
really
useful.
Troubleshooting
tools,
but
they're
configurations
that,
frankly,
all
they're
going
to
do
is
give
you
grief
in
in
a
production
environment.
We've
got
a
few
of
these
in
here.
B
There's
always
ideas
that
we
have
from
customers
from
partners
about
more
and
there's
ways
to
slim
down
your
images
so
that
they
just
don't
have
these
things
available
in
there.
You
know,
there's
no
legitimate
reason
to
to
leave
a
development
tool.
You
know
debugging
tool
in
your
containers,
there's
frankly
not
a
lot
of
reason
to
leave.
You
know
a
package
manager
in
the
image,
and
you
know
what
we're
talking
about
is
slimming
down
the
images.
Another
approach
to
take
would
be
to
start
with.
B
B
So
you
know
these
kinds
of
policies
will
help
you
chip
away
at
you
know
the
utilities
that
are
available
and
if
I
go
through
some
of
my
images
here,
you
know
you'll
see
that
even
something
like
wordpress
comes
with
just
you
know
a
huge
number
of
components,
and
you
know
as
an
admin
as
a
devops
person
as
a
security
person,
you're
essentially
taking
responsibility
for
these
things,
right
shells
which
are
really
powerful,
programming,
languages
and
interpreters
utilities
like
busybox,
you
know
get
rid
of
this
stuff.
Your
container
doesn't
directly
depend
on
it.
B
A
A
I've
had
several
people
challenge
me
recently.
When
I
talk
about
pulling
package
managers
out
of
images,
you
know
the
your
base
images.
You
absolutely
need
the
package
manager
because
you're
going
to
build
on
top
of
them,
you're
going
to
add
packages
wherever
else,
but
your
final
images,
those
images
that
are
destined
for
production.
A
You
absolutely
should
never
be
running
yum
install
in
a
container
running
in
your
production
environment.
That's
just
that's
a
terrible
idea,
so
I
really
like
the
idea
of
yeah
leave
them
in
the
intermediate
images,
but
that
thing
that's
actually
going
to
be
delivered
and
run.
That's
going
to
run
your
application
at
the
end
of
your
build
syrup,
yum
and
apt
and
d
package,
and
all
of
those
things
out
of
there,
so
that
they're
not
available
to
an
attacker
and
the
same
thing
for
network
policies
right.
That's
that's
limiting!
A
Obviously,
if
I
have
ingress
policies,
that's
limiting
what
things
can
connect
to,
but
my
egress
policies
on
on
containers
are
starting
to
lock
down.
If
one
of
those
things
gets
compromised,
what
else
can
it
connect
to
so
that
for
me
conceptually?
Those
are.
Those
are
a
really
important
set
of
controls
that
we
don't
often
think
about,
or
we
don't
think
about,
as
as
often
at
least,
we
think
a
lot
about
vulnerability
management.
Let
me
let
me
patch
all
of
these
vulnerabilities.
B
Yeah
I
mean
the
live,
runtime
threat,
detection
right,
the
sniffing
out
of
hackers
is,
is
what
gets
the
press
and
and
gets
everybody's
blood
going?
But
you
know
you
talked
about
those
two
things,
and
actually
it's
no
coincidence
that
compliance
standards
like
pci
or
recommendations
like
nist,
have
a
strong
focus
on
reducing
surface
area,
limiting
privileges,
limiting
network
access
right.
You
know
having
unused
services
that
you
don't
know
about.
B
You
know,
disclosure
of
data,
the
exploits
that
involve
that
that
data
being
exfiltrated
and
suddenly
you
know
a
million
credit
card
numbers
are
for
sale
on
you
know
on
on
on
somewhere
I
mean
it's
probably
more
than
a
million,
but
you
know
the
point
is
that
the
defense
in
depth
preparing
a
configuration
secure
by
default,
like
that's,
what's
actually
being
being
getting
getting
the
work
done
here.
It's
the
bread
and
butter
of
this
kind
of
thing.
A
B
B
Make
one
more
note
one
of
the
things
you
said
a
couple
of
times
like
we're,
we're
pretty
sensitive
about
breaking
the
developer.
I
mean
we.
We
know
security
tools.
Do
this
right
and
I
hated
it
when
I
was
working
as
a
developer.
So
there
are
some
alternatives
and
there's
some
stuff
that
we've
talked
about
in
previous
webinars.
B
You
know
if
I,
if
I
don't,
have
wget
or
curl
or
I
don't
have
debugging,
then
what
am
I
supposed
to
do?
How
am
I
supposed
to
find
say
you
know,
find
out
things
and
there's
lots
of
alternatives.
There's
things
like
ephemeral
containers
where
I
can
temporarily
start
up
like
a
debug
container
in
my
pod
to
go
and
investigate
things.
B
You
know
and
of
course,
the
whole
separate
topic
of
you
know,
building
better
observability
that
if
you
find
yourself
having
to
go,
run
a
tool
like
curl
in
a
production
container
to
go,
find
out
what
happened
with
something,
then
that's
an
opportunity
to
improve
the
tooling
that
you're
using
for
better
observability,
so
that
you
don't
have
to
do
that
going
forward.
That's
one
of
the
reasons
why
here
in
the
product,
you
know
we
don't
just
look
for
a
curl
being
present.