►
From YouTube: A Security State of Mind: Continuous Security with Kubernetes by Chris Van Tuin, Red Hat
Description
A Security State of Mind: Continuous Security with Kubernetes - Chris Van Tuin, Red Hat
"With the rise of DevOps, containers are at the brink of becoming a pervasive technology in Enterprise IT to accelerate application delivery for the business. When it comes to adopting containers in the enterprise, Security is the highest adoption barrier. Is your organization ready to address the security risks with containers in a DevOps environment?
In this presentation, you'll learn about:
- An understanding of the underlying technologies for Containers and how they enable DevOps
- The security risks with deploying containers in the enterprise
- The dangers of untrusted content and importance of maintaining container images
- How to make your Container workflow more secure using Kubernetes without slowing down DevOps
- Automating vulnerability management, security management, and compliance checking for container images in a Kubernetes environment
Join, Chris Van Tuin, Chief Technologist, West at Red Hat, as he walks through an overview of the underlying Container technologies, the security risks with deploying containers, and how to address these security challenges in a DevOps environment with Kubernetes"
About Chris Van Tuin
Chris Van Tuin, Chief Technologist for the West Region NA at Red Hat, has over 20 years of experience in IT and Software. Since joining Red Hat in 2005, Chris has been architecting solutions for strategic customers and partners with a focus on emerging technologies including IaaS, PaaS, and DevOps. He started his career at Intel in IT and Managed Hosting followed by leadership roles in services and sales engineering at Loudcloud and Linux startups. Chris holds a Bachelors of Electrical Engineering from Georgia Institute of Technology.
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
My
name
is
Chris
Fantine
chief
technologists
for
the
western
region
at
Red,
Hat
and
I've,
been
with
Red
Hat
for
about
12
years,
working
with
strategic
partners
and
customers
who
are
adopting
red
hats,
emerging
technologies,
and
certainly
one
of
the
hot
topics
with
our
customers
is
around
their
business
digital
transformation.
And
how
can
I
t
help
with
that?
Inevitably,
the
discussion
typically
leads
to
a
discussion
around
containers
and
kubernetes
for
container
management,
as
well
as
DevOps,
and
today
we'll
take
a
look
at
the
security
implications
in
that
environment.
A
Many
years
ago,
Andy
Grove
from
Intel
had
a
famous
quote
about
how
only
the
paranoid
survive
and
it
wasn't
about
security,
was
about
strategic
inflection
points.
You
know
their
moments
in
time
when
they're
a
massive
amount
of
change
and
companies
are
faced
with
the
option
of
either
adapting
and
thriving
or
falling
by
the
wayside,
and
certainly
we're
seeing
that
in
real
time
at
many
different
industries.
Here's
one
such
industry
does
anybody
recognize
what
this
is
a
photo
up
right?
A
This
is
the
automobile
factory
for
Tesla
software
is
enabling
the
automation,
the
production
of
the
vehicles,
but
even
more
revolutionary
is
software.
Is
a
big
part
of
the
vehicles
after
it
long
leaves
this
factory
for
the
first
time
it
can
actually
purchase
a
vehicle
drive
off
with
that
vehicle.
Knowing
it's
gonna
get
better
in
3
6,
9
months
time
down
the
road
because
they
have
the
ability
to
deliver
software
updates
over
the
wire,
whether
it's
improving
the
0
to
60
time
the
battery
efficiency
or
the
applications
in
the
center
console
or
even
better.
A
Many
of
us
are
sure
of
read
about
vehicle
recalls.
They
even
have
the
ability
to
deliver
an
update
that
could
potentially
eliminate
or
rectify
a
vehicle
recall
issue
without
having
to
have
a
physical
recall,
saving
a
millions
of
dollars
over
the
competition,
and
so
there's
a
lot
of
pressure
on
IT
to
not
be
the
bottleneck
and
to
enable
the
business
to
quickly
innovate.
But
as
I
talk
with
companies
across
Silicon
Valley,
it's
not
uncommon
to
hear
them
complain
and
from
the
business
perspective
to
say,
hey.
A
It
takes
us
six
weeks
to
deliver
a
single
word
change
to
our
website
and,
as
you
dig
under
the
covers,
what
you
see
is
organizations
that
are
siloed
off
dev
tests
and
operations
and
they've
evolved
with
their
own
processes
and
their
own
technologies,
making
it
very
difficult
to
move
an
application
or
an
update
from
dev
tests
into
production.
And
when
you
talk
about
security,
that's
usually
an
afterthought
and
then
actually
seen
as
a
bottleneck
to
actually
delivering
these
applications.
And
it's
usually
restrained
to
the
production
environment.
A
A
You
know
how
do
you
get
to
that
point
where
you're
able
to
deliver
software
applications
and
install
them
as
easily
as
you
can
on
your
mobile
phone?
Why
is
it
so
easy
to
install
an
application
on
your
phone?
Yet
it's
so
difficult
in
the
enterprise
right
and
that's
really
the
promise
of
containers
to
simplify,
to
be
able
to
abstract
your
application
package
with
its
required
dependent,
seize
and
be
able
to
easily
package
it
once
deploy
anywhere
and
so
DevOps
is
a
big
part
of
this
transition
because
it
breaks
down
those
walls.
A
We
talked
about
earlier
in
this
conversation,
they're
really
three
key
components:
people
process
and
technology
right
DevOps
is
all
about
bringing
together
across
collaborative
team,
dev
QA
operations,
even
security,
and
collaborating
with
a
common
goal
of
delivering
a
new
feature
to
the
marketplace
as
well
as
evolving
the
process.
You
don't
carry
over
the
same
processes
with
this
new
software
Factory
right.
A
This
new
software
factory
needs
streamlined
processes,
automated
processes
to
really
drive
an
automated
build
and
automated
deployment
in
your
continuous
integration
or
continuous
deployment
environment
and
then
also
enabling
technologies,
most
often
in
DevOps
you're,
seeing
them
turn
to
dev
to
open-source
based
solutions,
whether
it's
chef,
puppet
ansible
get
Jenkins,
etc,
but
also
when
it
comes
to
containers
around
docker
and
kubernetes
driving
innovation
quickly
for
the
business
by
being
able
to
rapidly
deploy
and
build
these
applications.
For
you
and
I
mentioned
security.
A
And
so
let's
talk
about
continuous
security.
I
mentioned
kubernetes
open
ship
is
Red,
Hat's,
Enterprise
distribution
of
kubernetes.
We
work
upstream
provide
a
lot
of
contributions,
we're
number
two
contributor
behind
Google
to
the
project
and
so
we're
doing
a
lot
of
innovation
as
well
and
driving
those
features
up
into
the
project.
We
also
deliver
them
in
our
open
ship
offering
to
our
customers,
which
is
based
on
kubernetes,
and
so
what
is
a
CI
CD
pipeline?
A
Look
like
that's
container
base
right
and
what
are
the
security
implications
and
areas
of
concern
that
may
want
to
address
and
be
aware
of
some
best
practices.
So
here's
a
typical
pipeline
that
you
may
see
in
the
enterprise
is
one:
is
you
have
a
a
different
group
of
characters
in
terms
of
your
operations?
A
Folks,
your
developer,
QA
manager
and
your
release
manager
all
needing
visibility,
access
at
different
stages
of
the
pipeline
right
because
they
need
to
be
able
to
contribute,
they
need
to
be
able
to
do
their
job
effectively
and
they
need
to
have
oversight,
so
they
can
incorporate
feedback
and
change
an
ongoing
basis
in
the
DevOps
culture.
And
so
typically,
you
have
a
source
code
repository
and
that's
driving.
A
The
definition
of
your
container
build
you're,
building
out,
typically
in
an
automated
fashion,
your
application
and
then
producing
an
artifact,
typically,
maybe
a
docker
image
and
storing
that
image
in
a
registry
so
that
it
can
be
shared
across
all
your
environments.
Right.
You
want
to
package
it
once
and
then
deploy
everywhere,
not
rebuild
as
you
go
to
each
individual
environment,
and
you
want
a
nice
separation
of
your
environment
so
that
developers
have
access
to
the
resources
they
need
and
can
experiment
and
innovate
without
negatively,
impacting
the
tests
or
the
production
environment
as
well.
A
So
first
thing
you
want
to
pay
attention.
Is
you
know
how
secure
is
that
content
that
you're
actually
building
in
and
delivering
in
the
enterprise,
how
about
a
secure,
build
process?
Where
are
some
best
practices
around
that
and
then,
when
you
come
in
the
enterprise
and
distribute
your
application
in
a
registry,
you
know?
Is
it
secure?
What
am
I
distributing,
who
authored
it,
etc
and
do
I
have
a
secure
deployment
process?
Why
do
I
have
the
ability
to
quickly
deploy
an
update
out
into
my
production
environment
to
address
a
security
concern?
A
A
If
I
have
certain
security
requirements,
storage,
API,
you
know
who
an
API
driven
world,
how
do
I
make
sure
I'm
authentic
ating
authorizing
the
right
people
to
have
access
to
this
platform
and
from
a
DevOps
perspective,
I
need
that
continued
feedback
around
monitoring
and
logging,
so
I
can
make
constant
change
to
my
environment,
based
on
intelligent
decision-making
analysis
and
also
from
a
security
perspective.
I
want
to
be
able
to
have
an
audit
trail
and
then
also
as
I
go
into
more
complex
in
scale-out
environments.
A
You
know
how
do
I
isolate
and
use
federated
clusters
as
well,
so
here
some
of
the
key
topics
around
securing
your
containers
that
we'll
walk
through
and
the
way
in
the
approaches
is
we'll
go
through
the
typical
workflow
of
a
container
environment.
You
have
a
build
ship
and
run
perspective.
One
is
you
build
out
your
docker
file
and
you
produce
an
image,
and
then
you
share
that
image
in
a
common
registry,
and
then
you
pull
down
that
image
and
run
it
on
your
environment.
So
first
off
you
know
from
a
build
perspective.
A
What
are
some
best
practices
when
it
comes
to
building
docker
images?
First
off.
Think
of
with
a
docker
file
which
is
similar
to
a
make
file
in
the
C
language
is
the
blueprint
right.
You
should
always
have
a
blueprint
for
how
to
reproduce
or
produce
the
output
and
case
a
container
image
right,
and
so
that
defines
exactly
how
to
build
that
image,
and
you
want
to
have
that
image
building
process
repeatable,
and
so
you
want
to
hang
on
to
that
blueprint
and
it's
a
good
idea.
A
A
You
want
to
have
a
recipe
for
how
those
VMs
and
those
physical
systems
were
built
as
well,
and
then
you
know
treat
that
docker
file,
like
a
make
file
developers
store
that
in
version
control,
you
know,
store
your
docker
file
into
version
control
as
well,
and
when
it
comes
to
stating
versions
of
rpms
or
other
packages,
don't
just
specify
latest,
because
you
have
no
idea
what
version
you're
gonna
get
next
time.
You
run
that
command.
A
You
want
to
be
explicit
in
your
definition
of
which
version
to
use
as
well
and
then
keep
in
mind
when
you
use
the
run
within
the
docker
file
each
time
you
do
that
it's
running
or
creating
another
layer
in
the
image.
So
it
can
get
quite
bulky,
so
you
want
to
be
aware
of
that
as
well.
So
those
are
just
a
few
of
the
best
practices
when
it
comes
to
building
out
your
images
in
terms
of
content
security,
you
want
to
be
aware
of
actually
what
goes
into
the
container
image
right.
A
So
container
images
can
span
across
any
different
any
language
c
java,
nodejs,
perl,
python,
etc,
and
it
puts
in
your
application,
but
also
pulls
in
dependencies
that
are
required
to
run
that
application.
And
then
you
can
run
that
image
across
physical
virtual,
physical
or
private
infrastructure,
private
cloud
infrastructure
allowing
you
to
package
your
wants
to
deploy
anywhere.
But
what
you
want
to
be
aware
of
is,
as
it
pulls
in
these
dependencies.
You
know,
there's
security
implications
of
what's
being
pulled
in
right.
Who
is
where
is
that
application
dependency
being
pulled
in
from
right?
A
A
What
that
means
is
that
there's
been
66
actually
more
than
that,
because
this
slides
a
little
old
but
there's
been
at
least
66
security
notifications
for
the
JRE
since
well,
7.0
was
released
right
and
so
the
the
message
here
is
that
you
pull
down
your
image,
that's
okay,
it
might
be
secure
then,
but
you
need
to
make
sure
an
ongoing
basis,
you're
checking
to
make
sure
it's
still
secure.
I'm
sure
many
organizations
have
developers
pulling
down
packages.
A
The
operations
or
the
security
team
is
not
aware,
or
they
don't
have
a
process
in
place,
and
so
we'll
talk
about
that
in
just
a
second
and
so
one
of
the
things
you
want
to
do
in
a
DevOps
cultures.
You
have
this
continuous
integration
process
where
your
developers
are
constantly
checking
in
their
code
and
triggering
automated
test
cases
using
Jenkins,
for
instance,
as
your
CI
tool,
and
it's
checking
make
sure
the
codes
okay,
but
also
you
want
to
make
sure
that
your
application
is
secure
right,
so
run
a
security
check.
A
Every
time
you
build
your
container
image
as
a
part
of
your
CI
process.
If
it
isn't
secure,
then
stop
the
clock
or
stop
and
move
back
to
rectifying
that
issue
and
rebuild.
And
how
do
you
do
that?
Well,
there's
a
variety
of
tools
out
there.
Openscape
is
one
such
tool
which
allows
you
to
scan
hosts
virtual
machines
container
instances
as
well
as
container
images,
and
so
you
can
incorporate
this
tool
and
it
checks
for
security
vulnerabilities
within
the
image
or
the
instance
as
well
as
does
it
conform
with
your
security
policy.
A
So
you
could
define
a
security
policy
and
have
it
check
as
well.
Maybe
you
have
minimum
password
settings,
or
maybe
you
want
to
make
sure
things
like
FTP
are
disabled
on
the
behind
the
container
as
well,
and
so
you
can
generate
reports,
so
you
have
audit
trail
and
visibility,
and
it
also
allows
you
to
rectify
any
of
the
issues
from
a
security,
compliance
or
security
vulnerability
perspective,
and
so
that's
just
a
tool.
There's
a
more
in-depth
discussion
about
that
tomorrow.
A
In
my
talk
around
open
SCAP
also,
you
know
treat
containers
as
immutable
images
right,
don't
stuff
all
the
data
in
the
code
configuration
into
the
image
have
a
nice
separation
of
code
configuration
and
data
and
there's
some
objects
and
concepts
within
kubernetes
such
as
config
map
or
secrets
that
allow
you
to
extract
that
configuration
information
and
pass
it
as
an
environment,
variable
a
command-line
option
or
in
a
file.
That's
mounted
on
a
volume
to
the
image
at
instantiation,
and
so
this
allows
you
to
have
nice
separation,
for
instance.
A
I
can
also
do
multi
layer
of
signatures,
so
I
could
have
a
signature
for
my
OS
provider.
I
could
have
it
from
my
middleware
provider
and
my
application
developer
as
well,
and
it's
easy
to
integrate
into
your
existing
flow
in
terms
of
managing
containers
as
well,
and
so
that's
forthcoming.
Also,
let's
talk
about
container,
build
process
right
and
a
traditional
software
supply
chain.
You
typically
have
you
know
in
the
three
different
roles,
your
core
build
engineer,
your
middleware
engineer,
as
well
as
your
developer,
and
they
each
own
a
different
part
of
the
staff
right.
A
You
have
your
core
build
using
a
kickstart
to
build
the
rel
image.
You
have
your
middleware
team
responsible
for
the
installation
of
the
JBoss
middleware,
as
well
as
the
configuration
of
it,
and
then
you
have
your
app
developer,
using
a
war
file
to
deploy
their
application.
Alright,
so
right
here,
that's
a
challenge,
because
each
group
is
using
its
own
tool,
its
own
language
and
it's
hard
for
them
to
collaborate
and
communicate
right.
It's
not
very
effective
in
a
DevOps
world
and
also
from
a
security
perspective.
A
A
I
just
want
to
pay
attention
to
my
application
code
and
docker
file
allows
you
to
do
that,
and
it
also
gets
everybody
speaking
the
same
language
using
the
same
tool
set
so
now,
I
can
help
out
my
application
developer
and
vice
versa,
if
I'm
the
core
builder,
because
I
understand
the
docker
file,
syntax,
etc,
and
when
it
comes
to
production
environments,
I
roll
out
my
application
and
I
have
it
out
in
production.
You
know
I,
don't
want
to
be
maintaining
and
checking
on
security
notifications
for
that
score
or
middleware
layer.
A
Instead,
what
I
can
do
is
send
the
either
through
automation,
tools.
I
could
keep
on
checking
my
registry
for
updates
and
trigger
a
rebuild
right.
So
I
could
monitor
my
core
build
to
see
if
a
new
rel
7
image
was
released
and
if
so,
I
could
trigger
rebuild
of
any
application.
That
depends
on
that
and
red-hats
a
openshift.
We
automate
this
by
subscribing
the
image
streams
and
allow
you
to
trigger
those
rebuilds
in
an
automated
fashion
and
so
a
good
best
practice.
A
If
you
want
to
simplify
the
updating
of
your
application
images
that
have
security
updates,
also
in
terms
of
shipping,
your
content
images,
how
do
you
manage
that?
There's
public
and
there's
private
registries
really
an
enterprise?
You
know
in
terms
of
registry
security,
you
need
to
be
aware
of
a
lot
of
your
developers,
we're
probably
going
out
and
getting
public
repository
images
and
pulling
them
down.
Well,
there
was
a
scan
done
at
one
point
in
time
of
the
docker
hub.
A
A
And
so
it's
a
good
idea
as
the
enterprise
to
deploy
a
private
registry
right.
There's
many
solutions.
Atomic
host
has
a
atomic,
has
a
registry
that
you
can
install
in
your
enterprise,
which
provides
a
standalone
registry
and
content
that
you
can
control
who
can
access?
Who
can
push
new
code
images
up
into
the
registry
who
can
actually
pull
and
deploy
those
images
as
well,
and
so
it's
a
good
best
practice
to
install
a
private
registry.
A
You
can
also
still
make
public
registries
available,
but
it's
a
good
idea
from
a
enterprise
perspective,
but
also
have
a
private
one.
Also
in
terms
of
the
run
aspect,
you
know
deployment
security
right.
How
do
you
address
security
issues
that
are
out
in
production
right?
You
may
have
tens
of
thousands
of
container
instances.
A
Are
you
to
go
out
and
log
in
and
run
yum
yum,
update
and
patch
those
individual
containers
so
right
that
that
process
is
broken
and
it's
broken
for
many
reasons,
not
only
from
a
scale
perspective,
but
it's
never
been
tested
right
and
so
the
whole
premise,
a
container
is
that
you
package
it
once
and
to
deploy
everywhere.
So,
if
I
have
a
security
issue
out
in
production,
I
need
to
go
back
to
my
software
factory
and
rebuild
and
put
it
through
that
whole
test
cycle.
Well,
that
sounds
like
it's
gonna
take
a
long
time.
A
A
A
One
is
rolling
update
deployment
all
right,
so
I
want
to
be
able
to
automatically
go
from
version
10
to
version
11
across
my
environment
and
I
want
to
go
in
an
incremental
fashion,
so
I
go
and
deploy
version
1.2
here
and
then
as
a
gain
comfort
with
that
new
version,
I
roll
it
out
to
an
additional
node
until
it's
at
a
hundred
percent
at
any
time,
I
could
actually
roll
back.
If
there
was
an
issue
discovered
and
so
that's
built
into
kubernetes
I
don't
have
to
script.
A
That
I
can
actually
just
issue
a
command
and
do
a
rolling
update
of
my
environment.
To
that,
newer
version
also
may
want
to
choose
a
blue-green
deployment.
A
Bluegreen
deployment
is
when
I
have
one
particular
version
in
production:
I
go
in
and
develop
and
test
the
next
version
in
this
case
version
1.2
and
then,
when
it's
time
to
switch
over
after
I
complete
my
CI
test.
I
can
do
that
by
just
updating
the
load
balancer
and
redirecting
all
that
the
route
all
the
traffic
to
that
new
version.
A
The
old
version
is
still
there,
and
so
if
there
was
an
issue,
I
could
fall
back
to
that
older
version
as
well
right.
So
this
is
when
you're
going
all
in
on
the
new
version,
with
the
comfort
of
knowing
you
can
roll
back
quickly
by
rerouting
to
the
old
version
as
well.
So
that's
another
option
for
my
deployments
and
when
I
have
security
issues.
A
Another
thing
you
may
want
to
do
is
I
have
a
new
version
that
I
want
to
try
out
so
I
have
version
1
in
production,
it's
receiving
currently,
let's
say
a
hundred
percent
of
the
traffic,
but
I
want
to
try
out
this
next
version
version
1.2.
It
has
a
security
fix
and
I
want
to
see
if
it
has
any
negative
impact
on
my
overall
site,
maybe
to
my
business.
A
So
on
my
laptop
I
have
OpenShift
install,
which
is
our
kubernetes
distribution
and
I
have
installed
it.
My
laptop
here,
but
I
need
to
bring
up
a
cluster,
and
so
I
want
to
go
ahead
and
pull
up
the
cluster.
It's
very
quick
process
and
what
it's
doing
is
its
setting
up
the
kubernetes
cluster.
It's
deploying
a
private
registry.
It's
also
setting
up
a
network
router,
so
I
can
route
traffic
to
my
applications,
sending
up
the
API
listener
as
well.
A
And
on
the
left
side,
I
have
my
browser,
so
I
can
access
the
portal.
They
also
have
a
login
to
github,
because
I've
developed
a
simple
application
in
PHP
to
just
demonstrate
these
deployment
strategies,
and
so
here
you
can
see
my
cluster
is
already
up.
I
can
log
in
on
the
command
line
as
a
developer,
and
likewise
I
can
go
over
to
my
my
browser
as
well,
and
they
get
the
URL.
A
A
And
within
this
dev,
space
I
can
create
new
applications.
So
what
I
want
to
do
is
I
want
to
build
out
and
deploy
my
PHP
application.
So
let's
go
down
here
on
a
build,
a
PHP
5.6,
so
the
nice
thing
is
is
from
a
security
perspective.
I
can
provide
access
to
standard
approved
images.
These
are
application
stacks
that
have
been
certified
and
authenticated
by
my
security
operations
team
and
made
available
to
my
developers.
A
A
So
pull
down
from
github
and
it
used
what's
called
a
builder
image
for
PHP
and
it's
taking
my
source
code
slipstreaming
the
base
image
for
Red
Hat,
Enterprise
Linux
and
the
PHP
runtime,
and
it's
gonna
build
a
docker
container
image
and
put
that
into
the
registry
automatically
for
me,
and
so
here
you
can
see
it's
pulling
down
the
various
layers
I'm
doing
this
over
my
cell
phone.
So
keep
that
in
mind
and
I'm
on
a
end-of-life
laptop
as
well.
A
A
A
Okay
and
talk
about
some
other
concepts
as
well.
So
next
thing
is
this
host
security
right.
So
when
it
comes
to
host
security,
you
have
some
best
practices.
One
is
you
know
these
container
images
they
run
by
default
as
root
I,
really
don't
want
to
run
it
as
root
unless
absolutely
necessary.
So
you
want
to
restrict
that
more
in
a
production
type
of
environment.
You
also
don't
want
to
be
logging
in
SSH
right
use
the
exec
command
on
cube
control.
You
also
want
to
be
careful
about
isolation
and
separation,
so
use
namespaces.
A
In
that
example,
my
project
was
using
the
development
namespace,
so
it
restricted
access
to
all
the
resources
that
that
application
needs
from
a
network,
CPU
memory,
etc
perspective.
Also,
it's
a
good
practice
to
define
resource
quotas,
so
you
don't
have
denial
of
service
attack,
type
of
issues
that
are
over
consuming
resources
that
you
didn't
intend
them
to
consume
and
then
also
be
sure
to
enable
logging,
if
within
your
environment,
so
you
have
access
to
those
from
an
audit
perspective.
A
You
want
to
have
a
best
practice
around
applying
security
errata
to
your
host
systems
that
you're
running
on.
As
well
so
make
sure
using
a
supported
distribution
that
has
a
standard
security
notification
process
and
and
provides
patch
updates.
Also,
it's
a
good
idea
to
apply
security
context
is
from
kubernetes.
This
allows
you
to
apply
and
we'll
have
more
detail
in
the
next
slide,
so
a
security
context.
A
This
allows
you
to
apply
UID
GID,
kernel
capabilities,
selinux
roles
on
a
pod
or
container
level
across
your
environment,
so
you
could
restrict,
for
instance,
at
pod
or
containers
running
as
root
alright,
so
you
want
to
define
that
policy.
There's
some
out-of-box
policies
for
different
different
use
cases,
and
you
want
to
be
sure
that
you
apply
these
out
to
your
environment
and
use
these
in
a
production
environment.
A
A
So
we
talked
about
content
through
container
host.
Let's
talk
about
network
isolation,
storage,
API
monitoring
and
as
well
as
Federation,
so
network
isolation,
one
of
the
nice
things
with
kubernetes
and
Red
Hat
did
a
lot
of
work
in
terms
of
network
name
spacing
is
that
you
can
actually
have
separation
of
your
application
environments.
So,
in
this
case,
in
my
CI
example,
I
have
three
different
projects:
my
dev
UAT
and
prod,
and
each
of
those
have
its
own
isolation.
A
Also,
here
shows
two
use
cases
of
network
isolation.
You
may
have
project
a
project
B,
although
those
application
pods
are
distributed
across
the
same
underlying
infrastructure.
It's
providing
that
virtual
separation
from
a
resource
and
networking
perspective,
and
then
likewise,
you
may
have
a
use
case
where
you
actually
merge
together
two
projects
and
then
can
don't
have
to
actually
move
your
applications
to
new
infrastructure.
It
can
all
be
converging
bind
so
that
now
those
project,
C
and
project
D-
can
share
the
same
resources,
and
so
that
gives
you
some
great
flexibility,
because
the
isolation
is
done.
A
On
a
virtual
perspective,
also,
storage,
security
right,
you
can
use
security
context
restraints
to
restrict
who
can
access
the
different
volumes
from
a
pod
or
a
container
perspective,
but
also
you
can
set
local
storage
quota
so
that
you
know
applications
don't
overfill
the
volume
and
cause
negative
impact
to
other
applications
running
on
that
particular
host.
So
those
are
some
a
best
practices
in
terms
of
storage
security,
also
API
and
platform
access
you
want
to
be
careful
of
who
has
access
to
the
environment,
so
there's
authentication
as
well
as
authorization
concepts
within
kubernetes.
A
You
authenticate
using
OAuth
tokens
and
SSL
certs
using
in
our
open
ship
as
well
as
authorization
you
can
define
user
and
group
defined
roles
which
the
policy
engine
will
check
against
to
make
sure
before
it
gives
permission
to
execute
something.
It
checks
to
make
sure
that
that
user,
a
group
has
the
permission
to
do
so,
and
so
you
want
to
take
a
look
at
that
and
make
sure
you're
applying
those
appropriately
in
your
particular
environment.
It's
also
monitoring
and
logging
right.
You
can
have
from
a
security
perspective.
A
You
want
to
be
able
to
track
and
identify
issues
in
your
environment
and
logs
are
a
great
way
to
gain
visibility
into
that
within
kubernetes.
You
can
deploy
the
Cabana
and
elasticsearch
to
have
a
consolidated
view
across
your
logs
and
do
searches
across
them
for
inspection
from
a
security
perspective,
we're
also
in
an
open
ship.
We
have
a
monitoring
facility
built
around
heaps,
ocular
and
casandra's,
where
the
metrics
are
stored
from
a
historical
perspective,
and
we
provide
a
view
of
the
metrics.
A
So
you
can
track
trends
and
identify
issues
that
may
correlate
with
a
particular
security
issue
in
your
environment
and
then,
lastly,
there's
Federation
right.
So
this
is
a
newer
capability
in
kubernetes
and
being
rolled
into
a
future
release
of
OpenShift,
and
you
may
want
to
use
it
from
a
security
perspective
to
be
able
to
do
nice,
separation,
isolation
of
different
environments,
but
still
have
a
consolidated
management
or
view
of
your
overall
infrastructure.
A
For
example,
many
customers
may
run
their
development
environment
in
a
public
cloud,
so
they
want
that
dynamic
scale
up
scale
down
as
they
tear
up
and
tear
down
or
create
and
tear
down
environments,
and
then
also
they
may
want
to
continue
running
their
environment
in
production,
on
their
private
OpenStack
cloud
right
and
so
with
Federation.
You
could
actually
accomplish
that
and
then
have
a
consolidated
view
across
those
environments
and
also
there's
Federation
at
the
service
level.
As
to
this
is
where
you
have
some
sort
of
global
routing,
global
API.
A
And
then
you
have
your
application
distributed
across
these
different
providers
as
well
and
maybe
route
certain
users
to
certain
two
data,
centers
from
a
security
perspective
or
based
on
a
token
that
they
provide.
And
so
those
are
just
some
of
the
use
cases
from
a
security
perspective
around
Federation.
And
let's
go
back
to
the
demonstration.
A
Alright,
so
I
create
my
development
project
and
then
I'm
gonna
create
my
PHP
application.
Let's
call
it
a
pay
use
my
git
repository
and
I'm
to
continue
to
the
overview.
So
let's
go
ahead
and
build
this
on
my
on
my
laptop
and
then
a
shutdown.
My
my
key
point
so
that
I
have
some
more
memory
and
it's
gonna
go
ahead
and
build
out
this
infrastructure
in
parallel.
I
could
go
out
and
build
another
application
to
my
project.
A
All
right
little
week
on
my
internet
connection
here,
but
let's
see
here
to
do
all
right,
the
bill
completed,
see
if
we
have
better
luck.
This
time,
yes,
and
so
now
we
have
an
application
automatically
deployed
and
I
can
simply
scale
this
application
from
one
to
two
pods
as
well,
and
then
I
can
check
over
here.
My
curl.
A
A
A
Yeah,
exactly
and
so
I
I
went
ahead
and
updated
that
so
now
I
can
actually
trigger
a
rebuild.
If
I
put
up
a
web
hook,
it
could
actually
automate
the
rebuilding,
but
I'm
gonna
go
ahead
and
manually
do
this.
So
let
me
start
that
build
and
so
now,
in
the
deploy
version
2
and
if
I
check
on
my
curl
over
here,
you
know,
one
thing
on
the
notice
is
that
this
deployment
should
be
a
lock.
This
build
should
be
a
lot
quicker.
This
time.
A
As
well
as
the
overall
deployment
and
sure
enough
now
it's
already
deployed
version
2,
and
it
did
it.
It's
doing
an
incremental
rolling
update
of
my
cluster
on
a
gradual
basis,
all
right
so
I
shortened
the
window.
So
it
quickly
did
it,
but
it
was
doing
one
at
a
time,
and
now
all
three
pods
have
been
updated
to
version
two.
A
So
the
nice
thing
there
is
I
can
actually
easily
view
much
better
so
on
to
create
a
new
project.
Maybe
call
this
production
production
production
alright.
So
this
has
to
be
an
isolated
environment.
We
talked
about
that
Network
isolation
and
so
I
don't
have.
This
is
Navy
controlled
by
my
operations
team
and
so
instead
of
building
into
my
production,
environment,
I'm,
just
gonna
pull
images
from
my
development,
environment
right
and
so
I
can
see.
There's
application
it
and
I'm
going
to
go
ahead
and
authorize
this
to
happen.
A
Okay,
thank
you
so
anyway.
That
is
the
end
of
my
presentation.
I
want
to
thank
you
for
coming.
What
I
was
to
do
is
just
show
you
how
you
can
easily
pull
the
image
and
deploy
it
in
production
and
then
also
you
can
set
up
the
route,
so
it
could
route
80%
of
the
traffic
to
version
a
and
then
20%
to
version
B.
But
the
thing
here
is
under
the
scenes:
it's
doing
continued,
continuous
integration,
continuous
deployments
with
the
automated
build
and
automated
deploy
and
I
didn't
have
to
edit
yamo
files
right.
A
It's
all
easy
to
use
really
as
a
developer,
simplify
my
life,
so
I
could
focus
on
the
code.
The
building
of
containers,
the
deployment
of
containers
all
taken
care,
I
didn't
have
to
call
up
Network
engineering
to
update
that
load,
balancer
every
time,
I
added
an
application
or
added
or
decreased
capacity,
and
so
it's
providing
a
lot
of
automation,
a
lot
of
efficiency
and
when
it
comes
to
security
perspective,
I
can
rapidly
roll
out
those
security
updates
across
my
environment.
Thank
you.
So
much.