►
From YouTube: OpenShift Commons Briefing Why DevSecOps is Critical for Kubernetes Kirsten Newcomer (RedHat)
Description
OpenShift Commons Briefing
Why DevSecOps is Critical for Kubernetes
Kirsten Newcomer (RedHat)
Hosted by Diane Mueller (Red Hat)
2020-05-13
A
Reading
blog
we'll
post
a
link
to
that
as
well,
and
then
we
have
Keith
basil.
Who
is
going
to
talk
about
some
of
the
things
you
can
do
to
automate
some
of
the
compliance
in
OpenShift
afterwards.
So
it's
two
parters
and
we'll
have
some
live
Q&A
at
the
end
and
so
hang
out
for
up
with
us
for
an
hour
or
so
or
see
how
long
this
goes
and
first
off
I'm
gonna.
Let
Kirsten
kick
it
off
with
a
short
talk
on
why
dev
sexes
office
did
I
just
say
that
did.
B
A
B
B
It's
to
ensure
that
you
are
addressing
your
customers,
goals
and
kind
of
getting
ahead
of
the
competition,
and
so
really
with
changes
in
technologies
that
that
have
been
emerging,
for
you
know,
probably
over
five
years
now,
and
have
really
started
to
become
widely
adopted.
Containers,
kubernetes
micro
services
and
DevOps
all
really
helped
to
ensure
that
you
can
deliver
that
innovation
more
quickly,
so
hopefully,
by
now
folks
are
pretty
familiar
with
containers
and
how
they
make
it
easier
to
deliver
applications
faster
right.
B
You
get
to
package
all
of
the
system
dependencies
that
go
with
your
application
in
that
container
image.
That
means
that,
as
you
move
from
dev
to
test
to
production,
there
are
fewer
configuration
changes
if
any
to
be
made.
That
config
is
those
system.
Dependencies
are
all
in
the
container
image
anytime.
You
deploy
you're
deploying
from
that
immutable
container
image,
so
you
have
also
a
simpler,
lighter
way
to
deploy
your
application
and
portability
across
what
environment.
B
So
you
can,
if
you
choose
to
deploy
on
pram
or
in
public
cloud,
you
can
still
use
that
container
image
wherever
you're
deploying
an
kubernetes
makes
it
easier
to
manage
those
containerized
applications
right.
You
need
a
platform
that
helps
you
scale
that
provides
resiliency
and
built-in
high
availability
for
your
applications
and
container
orchestration
platforms
really
require
some
additional
things:
networking
and
routing
persistent
data
storage.
All
of
these
are
capabilities
that
kubernetes
provides
and
really
well.
B
We
saw
you
know
three
or
four
years
ago
we
saw
a
wide
variety
of
container
orchestrations
out
there
and
the
orchestration
tools
out
there
in
the
market.
Today,
really
we
we
see
primarily
kubernetes.
We
know
it's
one
so
DevOps,
so
we've
talked
about
containers
for
applications,
making
it
easier
and
faster
to
deliver
kubernetes,
making
it
easier
to
manage
your
containerized
applications
with
the
declarative.
B
Nature
of
kubernetes
ensures
that,
if
instance
of
your
containerized
app
goes
down,
another
one
is
automatically
spun
up,
but
in
addition,
devops
is
really
a
necessary
part,
because
agility
can't
succeed
in
silos
right.
So
we're
talking
about
an
environment
here
that
involves
all
of
these
people
down
at
the
bottom
of
this
slide
right,
you've
got
your
network
admin,
your
security
team,
your
developer,
who's,
building
the
containerized
application,
the
line
of
business,
who's,
driving
the
innovation
that
your
customers
or
your
partners
need
to
take
advantage
of,
because
you
may
be
deploying
in
the
cloud.
B
You've
got
your
cloud
admin
as
well
as
the
sysadmin
to
think
about,
and,
of
course,
your
ops
team
has
to
think
about
all
of
these
elements.
All
the
way
through
so
DevOps
is
about
getting
things
out
the
door
to
end
users
quickly
and
reliably
and
dev
suck-ups
is
about
doing
that
quickly
and
reliably
and
securely,
and
then
the
reason
that
devs
tech,
ops
matters
so
much
for
containers
and
kubernetes
is
because
containers
and
kubernetes
are
both
an
opportunity
to
improve
security
and
a
challenge
to
the
traditional
approaches
to
application
and
platform
security.
B
They
sat
down
in
a
room,
they
determined
what
were
the
key
use
cases
that
they
needed
to
meet
as
they
were
embarking
on
this
container
journey
and
they
came
to
agreement
not
just
on
those
use
cases,
but
also
on
how
they
were
going
to
to
meet
those
use
cases.
One
of
the
things
that
was
key
here,
because
DevOps
is
not
just
about
technology.
It's
also
about
people.
So
actually
two
things
were
key.
B
One
is
that
this
group,
at
upper
level
of
the
organization,
decided
that
this
was
an
important
opportunity
and
decided
to
work
together
to
figure
out
how
they
were
going
to
make
this
happen
and
empower
their
teams
to
make
it
happen,
and
one
of
the
other
big,
different,
big,
big
and
important
changes
here
was
that
all
three
teams
decided
they
needed
to
learn
from
each
other.
They
needed
to
understand
more
about
what
mattered
to
each
of
the
different
groups,
each
of
the
different
silos.
B
What
used
to
be
silos
and,
in
particular
the
security
team
determined
that
they
needed
to
understand
more
about
development
tools
and
how
developers
did
their
work,
and
this
wound
up
in
a
situation
where
now
security
has
shifted
left
in
their
organization.
More
of
the
security
tools
are
deployed
in
the
CI
CD
pipeline.
The
security
team
is
alerted
early
on.
B
B
Who
wants
to
hear
right
at
the
end
as
you're
ready
to
deploy
your
application
that
there's
a
late-breaking
vulnerability
that
you
didn't
know
about
that
your
security
team
found
and
now
you
have
to
rebuild
and
redeploy
and
that
delays
your
release
and
Ops
doesn't
want
to
deal
with
that
either.
They
need
to
know
right
now
we
have
OS
libraries
embedded
in
those
containerized
applications
in
that
container
image,
and
so
sometimes
the
updates
that
need
to
be
made
are
being
made
in
that
OS
layer,
which
is
the
traditional
responsibility
of
the
ops
teams.
B
So
when
you
were
deploying
monolithic
apps
to
a
physical
machine
kind
of
everybody
knew
you
know
what
was
the
IP
address
of
the
host
that
the
app
was
deployed
to
then,
when
we
moved
to
virtualization,
you
still
had
a
lot
of
that
same
information.
Now
you
have
VMs
to
configure
not
just
the
apps,
those
VMs
might
live
for
months
for
years,
but
you
moved
to
containers
and
containers
are
intentionally
ephemeral.
B
They
are
intended
to
be
spun
up
and
run
for
as
long
as
necessary
and
then
with
the
addition
of
kubernetes
to
the
containers
environment
right
if
a
container
instance,
even
without
kubernetes,
if
the
container
instance
dies,
you
would
just
deploy
a
new
instance
from
the
container
image.
Kubernetes
just
makes
that
easier
and
more
automated,
and
so
those
changes
mean
that
we
need
to
think
differently
about
our
pipeline.
We
need
to
add
even
more
automation
into
our
application,
CI
CD
pipeline,
because
containerized
images
again
require
those
those
OS
dependencies
to
be
built
into
the
container
image.
B
You're,
always
going
to
be
using
some
external
content
in
your
containerized
application.
You
want
to
assess
that
content
as
early
as
possible
as
soon
as
you
bring
it
down
into
your
environment.
That's
one
of
the
key
reasons
for
using
a
private
registry
to
manage
images.
You
want
to
think
about
what
security
gates
you
need
to
put
into
your
CI
CD
process.
Are
you
willing
to
have
certain
you
know
critical
vulnerabilities
break
the
build
as
our
as
our
friends
did
mentioned
earlier.
How
are
you
going
to
manage
application
secrets
in
a
container
world?
B
What
do
you
what's
the
runtime
security
posture
that
you
need
to
think
about,
and
one
of
the
key
differences
that
really
drives
the
move
to
a
deaf
set
cops
model
for
building
your
container
images
is
that
you
should
never
patch
a
running
container
in
place,
and
one
of
the
reasons
again
is
so,
let's
say,
you're
running
your
containers
in
kubernetes.
You've
said:
I
want
three
instances
of
those
of
that
web
front-end
part
of
my
application
running
one
of
the
instances
dies
and
kubernetes
is
going
to
deploy
a
new
instance
of
that
from
a
container
image.
B
If
you
patched
that
running
instance,
that
patch
is
lost,
so
you
always
need
to
rebuild
and
redeploy
to
address
any
security
issues
or
any
other
type
of
bug,
of
course.
So
that
just
means
you
need
to
think
again
about
more
automation
and
there's
some
opportunities
here.
So
you
want
to
look
at
what
security
tooling?
Can
you
build
into?
B
Can
you
integrate
into
your
IDE
environment?
So,
for
example,
you
might
want
to
use
code
ready
workspaces,
which
is
a
hosted
IDE
that
allows
you
to
kind
of
gives
visibility
to
everyone
across
the
team
about
the
code
you're
working
on
as
you're
working
on
it,
and
it
means
that
you
don't
need
to
download
any
code
to
a
local
laptop
right.
B
You
can
ensure
that
the
code
is
it's
secured
in
one
place,
because
it
is
an
IDE
as
a
SAS
offering
you
can
use
solutions
like
sneak
which
do
early
on
in
the
IDE
provide
dependency
analysis,
and
so,
if
there
is
a
known
issue
in
one
of
the
pieces
of
the
code
that
you're
using
it'll,
let
you
know
what
some
of
those
other
dependencies
are
say.
You
need
to
do
an
update.
You
absolutely
need
to
be
investing
in
automated
unit
testing
oftentimes
for
organizations
who
are
you
know,
moving
existing
applications
to
containerized
apps.
B
Automated
testing
is
one
of
the
biggest
stumbling
blocks,
so
so
sometimes
when
you're
starting
out,
you
want
to
start
with
a
Greenfield
app,
but
unit
testing
is
usually
easier
to
add
than
some
of
the
more
complex
testing
that
you
might
do
down
the
road.
But
you
also
want
to
add,
in
things
like
sonar
cube
or
Coverity
for
code
quality,
some
of
those
code.
B
Streams
in
combination
always
making
sure
that
you're
pulling
down
the
latest
base
image
with
those
OS
dependencies
and
built-in
pipelines
that
help
you
automate
rebuild
and
redeploy.
But
you
absolutely
want
to
be
sure
that
you
invest
in
the
appropriate
level
of
automation
here
in
your
pipeline
and
also
in
your
production
environment
in
your
runtime
environment,
and
so
in
addition
to
the
built-in
security
capabilities
that
come
with
a
platform
like
openshift.
There
are
partners
out
there
who
provide
additional
security
capabilities
as
need
that
can
enhance
what
you've
got
available.
B
And
so
again,
some
of
complexity
comes
from
the
declarative
nature
of
this.
The
system
that
it
has
many
different
parts
and
each
of
those
parts
has
declarative
config.
So
it's
not
the
fact
that
it's
declarative.
It's
more,
that
there
are
many
different
parts
with
many
different
configurations.
It's
a
dynamic
system.
B
Things
are
changing
regularly
as
new
applications
are
deployed,
new
solutions
added
to
the
cluster
its
automated,
and
it
is
an
API
managed
platform,
and
there
are
organizations
who
are
not
used
to
the
level
of
automation
that
kubernetes
leverages
and
the
benefits
of
it
and
and
to
get
the
real
benefits
of
that
automation.
You
need
security
solutions
that
know
how
to
work
with
this
platform
in
a
much
more
automated
way.
B
Kubernetes
requires
an
Sdn
some
of
the
traditional
network
security
tools,
don't
work
well
with
SDNS
right
application,
configs
and
deployments
are
managed
in
new
ways,
whereas
a
application
deployed
to
a
VM
again,
you
know
kind
of
that
might
be
in
place
for
four
months
or
even
longer.
Applications
deployed
on
kubernetes
are
going
to
change
as
needed.
As
something
happens,
you
need
to
scale
up,
you
tell
it.
You
need
to
go
from
three
instances
to
five
I've
now
got
five
instances
and
I,
don't
know
where,
on
my
cluster,
those
are
deployed.
B
Locations
change
as
needed,
and
containers
themselves
are
opaque
to
many
existing
security
tools
as
as
well
as,
in
general,
the
way
kubernetes
works.
For
example,
there
are
a
lot
of
you
know:
certificate
management,
solutions
that
aren't
used
to
working
that
that
aren't
used
to
being
managed
in
an
automated
fashion.
B
So
you
need
security
automation,
not
just
application
and
application
platform.
Automation
kind
of
already
been
saying
this
right
so
doing.
Kubernetes
right
for
the
enterprise
involves
a
lot
of
different
things.
You
have
to
have
your
hosts
set
up.
You
need
to
validate
your
environment,
you
need
to
manage
identity
and
access.
You
need
to
think
about
adding
monitoring
for
the
platform
as
well
as
for
applications
there
going
to
be
cases
where
you
need
persistent
storage.
You
need
to
think
about
managing
north-south
traffic
for
the
cluster
ingress
and
egress.
B
You
need
to
think
about
effective
management
of
the
Sdn
and
the
east-west
traffic.
You
need
to
think
about.
Potentially,
how
are
you
going
to
manage
charge
back
if
you're
running
in
the
public
cloud?
How
are
you
going
to
harden
the
platform?
What
certifications
do
you
need
disaster
recovery
and
how
are
you
going
to
manage
patching
and
upgrades
to
all
of
the
different
components
that
make
up
not
just
kubernetes,
not
just
your
custom
applications,
but
all
of
the
additional
things
you
add
to
kubernetes
to
make
it
enterprise
ready?
B
You're
logging
stack,
your
monitoring
stack
your
security,
tooling,
that
you
add,
so
in
addition
to
kind
of
all
of
that,
we
so
kind
of
as
a
high-level
way
of
summing
that
up
right.
We
need
to
think
about
host
security.
Runtime
security,
Identity
and
Access
Management
are
back
project
namespaces.
Sir
kubernetes
has
the
concept
of
namespaces.
If
you
choose
to
take
advantage
of
those
to
have
a
multi-tenant
cluster,
you
want
to
be
thinking
about
how
you're
going
to
work
with
that
network
isolation.
B
So
we
are,
and
we
have
delivered
open
shift4
on
rail,
core
OS,
which
is
a
containerized
optic
container
optimized
operating
system,
which
is
also
managed
with
an
operator
a
kubernetes
operator,
the
machine
config
operator.
So
this
allows
us
to
deploy
an
opinionated
kubernetes
cluster
full
stack
deployment
from
the
OS
all
the
way
up
through
the
kubernetes
layer,
including
audit
and
logging,
including
monitoring
and
metrics,
and
including
the
CI
CD
tooling.
That
developers
might
want
to
take
advantage
of.
B
Of
course,
you
know
with
kubernetes,
you
can
use
your
own
CI,
CD
tooling,
outside
of
a
coop
cluster,
or
you
can
run
that
inside
of
a
coop
cluster.
This
also
has
changed
how
we
manage
patching
the
full
stack
that
we
deliver
with
openshift.
So
we
are
now
able
to
provide
patches
to
the
host
OS
layer,
the
kubernetes
layer,
all
of
the
other
components
of
openshift,
including
the
Sdn,
the
monitoring,
the
logging
in
a
rolling
fashion.
B
Through
one
interface,
we
test
everything
together
we
deliver
everything
together,
we
patch
things
through
same
interface
and
the
operators
that
are
used
to
manage
each
of
these
components
and
openshift
apply
those
patches
in
a
way
that
enable
a
rolling
update
across
the
cluster,
in
particular,
for
the
host
OS.
The
machine
config
operator
ensures
that
again
we're
taking
the
approach
of
managing
the
hosts
as
an
element
of
kubernetes.
So
if
there's
an
update
at
the
host
OS
layer,
OpenShift
will
notice
it
will
mark
a
node
as
being
ready
for
upgrade.
B
It
will
move
all
of
the
workloads
off
that
node
and
on
to
a
node.
That's
continued
going
to
stay
in
service.
The
OS
update
will
be
applied.
This
host
will
be
rebooted,
put
back
in
service
and
OpenShift
will
move
on
to
the
next
rel
core
OS
node.
So
we
are
doing
0
application.
Downtime
upgrades
for
will
behaving
apps
on
this
on
this
kubernetes
environment,
OpenShift
managed
with
kubernetes
operators,
so
devstack
ops
at
work.
B
So
when
you
think
about
def
sec
ops
for
your
teams,
how
can
you
get
started
if
this
is
not
something
you're
already
doing?
Well,
just
like
the
the
group
that
we
mentioned
early
that
I
mentioned
early
in
this
deck,
you
really
kind
of.
First
of
all,
you
need
to
identify
your
key
stakeholders
and
what
your
business
objectives
are.
And
ideally
you
do
this
with
executive
sponsorship.
B
That's
one
of
the
most
effective
thing,
effective
ways
to
move
forward
and,
of
course
you
also
need
technical
leadership
and
you
need
those
technical
leaders
to
be
willing
kind
of
to
step
outside
of
their
silos
their
boxes
and
learn
from
each
other.
It's
great
to
start
with
a
pilot
project.
We
find
that
that
is
the
most
effective
way
and
kind
of
define
initial
processes
tools,
and
then
you
know
kind
of
identify.
B
Your
initial
timeline
measure
of
progress,
but
just
like
with
any
agile
process,
you
need
to
be
prepared
to
iterate
and
learn
from
what
from
your
mistakes
and
as
part
of
this
again,
because
it's
not
just
about
tools,
it's
also
about
people.
You
want
to
think
about
the
cultural
elements
right.
So
here
are
some
of
the
key
things
that
that
you,
really
your
team,
really
needs
to
embrace
as
part
of
DevOps
or
dev,
so
cops
culture.
You
want
to
push
responsibility
down
into
the
team
as
far
as
you
can.
B
One
of
our
customers-
Schiphol
Amsterdam
Amsterdam
Airport,
achieved
a
50%
reduction
in
application
development
time
through
adopting
DevOps
approach.
This
you
know
kind
of
the
bullets
here
are
a
little
bit,
not
just
about
their
DevOps
elements
right.
They
used
the
development
pipeline
and
open-open
shift.
They
used
source
to
image,
but
also
some
of
the
application
tooling
that
they
used
as
well.
They
run
thousands
of
containers
and
mission
critical
workloads
on
OpenShift
today,
and
we
have
other
customer
numbers
that
are
even
even
higher
than
this.
B
So
just
kind
of
to
sum
it
up,
dev
checkup
models
model
is
really
an
extension
of
the
DevOps
model.
Devops
was
always
intended
to
include
security,
but
in
many
places
that
sort
of
got
lost
along
the
way.
So,
as
you
look
at
any
existing
devops
teams,
you're
working
with
today
say,
look
take
a
look:
have
they
added
enough
security
capabilities
into
their
CI
into
the
CI
CD
pipeline?
How
are
you
automating
security
out
the
operations
end?
How
are
you
iterating?
B
How
are
you
adapting,
as
you
learn
from
the
changing
landscape
and
as
you
take
on
new
types
of
application
technologies,
so
I'm
sure
and
and
if
folks
would
like,
we
have
teams
out
there
that
we
would.
You
know,
customers
or
if
you
have
an
example
that
you
would
like
to
share
with
us.
We
would
love
to
hear
your
experience
in
moving
into
DevOps
and
the
dev
suck-ups
journey.
That's
what
I
had
for
you
today,
Diana
back
to
you
thanks.
A
And
that
was
that
was
great
one.
It's
a
wonderful
introduction
to
you
all
the
concepts
behind
dev
sack
ops,
as
well
as
the
importance
of
it
for
the
kubernetes
and
the
whole
cloud
landscape
on
folks,
so
really
thrilled
to
do
that.
I
put
in
the
chat,
a
link
and
I'll
post
it
again
at
on
the
Twitter
stream
as
well
to
the
dev,
SEK,
ops,
dig
I
said
it
right
this
time.
A
Well,
the
other
one
would
probably
get
more
traction,
and
so,
if
you're
interested
in
this
topic,
please
join
us.
We're
gonna
start
kicking
off
some
regularly
occurring
conversations
around
dev
sec,
ops
with
Kirsten
newcomer
and
our
co-chair
as
well
John
Willis
from
the
Office
of
global
transformation.
I
love
that
title,
and
so
please
do
join
us
there
and
if
you
can
and
when
we'll
send
you
an
invite
to
the
kickoff
meetings.
For
that,
that's
a
wonderful
way
to
be
part
of
the
conversation
as
well.