►
From YouTube: Integrating Security in the Kubernetes CI:CD Pipeline
Description
As organizations embrace Kubernetes to manage their containerized workloads and accelerate towards microservices architectures, security needs to shift left and be embedded into the software supply chain. In a DevOps-led world, security must adapt to developer workflows by embedding guardrails and automated checks for developers to build and deploy secure applications.
Join this webinar to learn why Kubernetes security starts with securing the CI/CD pipeline, including the build processes, image registries, and Kubernetes deployments.
Attendees will learn how to:
- Detect and mitigate vulnerabilities in the build phase, registries, and at runtime
- Build (or choose pre-built) base images that adhere to security best practices
- Leverage Kubernetes-native security policies integrated with DevOps tooling to automatically validate deployments
A
Hi
everyone
thanks
for
joining
the
stackrocks
office
hours
in
for
october,
I'm
chris
porter,
I'm
the
director
of
solutions,
engineering
at
stack
rocks
and
I'm
going
to
be
moderating
today's
office
hours.
Our
subject
matter
expert
today
is
neil
carpenter.
Who's
joining
me
he's
our
solutions
architect
here
at
stack,
rocks
and
the
topic
this
month
is
on
integrating
kubernetes
security
into
your
ci
cd
pipeline.
Now
before
we
get
started,
I
want
to
go
over
some
of
the
rules
of
engagement
here.
As
you
can
probably
see,
the
lines
are
muted.
A
The
session
is
being
recorded
and
at
the
end
of
this,
the
on-demand
recording
will
be
emailed
to
everyone
post
event,
so
you
can
review
it
if
you
like,
if
you
haven't,
joined
one
of
our
office
hour
sessions
before
this
is
a
little
different
than
some
of
the
other
webinars.
You
may
have
attended
we're
going
to
be
answering.
Questions
live
throughout
this
session.
A
A
B
Absolutely
thanks
chris,
so
I
am.
I
guess
I
come
from
a
long
time
background
in
the
security
end
of
things
I
spent
20
years
at
microsoft.
13
of
those
investigating
security
incidents
in
that
time
spent
a
lot
of
time
with
azure
when
it
was
an
emerging
platform,
then
with
office
365
when
it
was
an
emerging
platform
and
when
it
was
time
to
go
somewhere
else
and
do
something
new,
it
was
containers
and
kubernetes
were
really
the
exciting
new
sort
of
technology
where
there
weren't
a
ton
of
security
adults.
A
Go
ahead
so
today's
topic
we
have
is,
you
know
it's
kubernetes
security
and
the
ci
cd
pipeline,
especially
integrating
this
using
the
ci
cd
pipeline
to
invoke
kubernetes
security
controls.
So
I
thought
for
the
benefit
of
the
audience
here,
to
kind
of
review
what
that
is.
What
do
we
mean?
What
are
we
focusing
on
for
this
session
here?
I
know
you
have
some
demonstration
materials
prepared,
maybe
give
us
an
idea
to
kick
things
off
here.
B
Yeah,
so
you
know,
I
think,
as
as
we
look
at
and
it's
a
great
question
right,
because
some
of
us
are
coming
from
from
the
devops
side
of
the
house,
I'm
sure-
and
you
know,
that's
you've
probably
got
a
good
idea
of
what
this
is.
Some
of
us
are
coming
from
the
security
side,
trying
to
wrap
our
heads
around
it
and
it's
very
much
a
journey.
So
as
you
look
at
why
we're
moving
into
kubernetes?
Why
we're
moving
into
all
the
other
buzzwords?
B
I
I
threw
out
there
cloud
native
and
container,
driven
and
devops
driven,
etc.
You
know,
automation
and
scalar
are
right
up
front
there
right.
We
want
to
be
able
to
deploy
things
faster
and
do
it
in
a
way
that
that,
where
all
of
the
important
checks
are
automated
so
that
we
can
develop
things
and
get
them
out
in
a
very
short
period
of
time,
and
then
you
know
usually
we
talk
about.
As
I
was
growing
up,
I
guess
you
know
we
used
to
release
software
two
to
four
times
a
year.
B
You
know
whatever
sort
of
methodology
we
have
for
deploying
things.
We
want
to
build
it
test
it,
deploy
it
and
have
the
ability
to
continuously
do
that.
So,
of
course,
that's
the
that's
the
business
value
and
that's
the
you
know:
that's
that's
how
we're
getting
there!
The
next
thing
that
becomes
important
is
how
do
we,
how
do
we
put
security
in
there
and
we've
we've
been
down
a
long
path
with
the
sdlc
right,
the
security
development
life
cycle
of
taking
security
and
baking
it
into
development.
B
Right,
let's,
let's
from
the
very
beginning,
look
at
how
we're
doing
things,
let's
do
threat
modeling,
let's
take
all
of
these
actions
to
develop
secure
code.
I
look
at
this
as
the
next
piece
of
it
sort
of
a
secure
operations,
life
cycle,
if
you
will
where,
when
the
sdlc
ends,
we
pick
up
and
start
looking
at
in
ci
we're
looking
at
what's
been
built
so
for
kubernetes
we're
talking
about
an
image
right
or
multiple
images.
B
Those
things
are
going
to
be
turned
into
containers
once
we
finally
deploy
them.
We
want
to
look
at
those
and
understand.
What's
in
them,
what
problems
exist
there
get
that
in
front
of
get
that
in
front
of
the
devops
teams,
make
sure
that
they
know
we've
got
these
vulnerabilities.
We're
particularly
concerned
about
we've
got
these
other
characteristics
of
these
images
that
are
potential
problems
and
maybe
put
gates
in
there
just
like
we're
doing
with
testing
right.
If
I
build
something
and
it
crashes,
it's
not
going
to
get
out
of
ci.
B
B
There
are
lots
of
valid
configurations
where
I
can
jump
out
of
the
container
to
the
underlying
host
to
other
things
and
that's
that's
necessary.
Kubernetes
uses
that
for
cube
proxy
and
some
other
components,
stack,
rocks
and
and
tools
like
us.
We
use
we
use
that
in
order
to
be
able
to
do
the
things
that
we
need
to
do
so,
I
want
to
be
able
to
deploy
stack,
rocks
and
deploy
all
my
cni
and
all
those
other
pieces
and
deploy
them
right,
but
my
application
code.
B
I
want
to
make
sure
that
they
can't
take
advantage
of
those
sorts
of
configurations
and
do
those
sorts
of
things
so
that,
in
a
nutshell,
that's
what
we
want
to
talk
about
today
is
is
taking
that
continuous
integration,
continuous
deployment
and
baking
security
right
into
it,
so
that
we
are
meeting
all
of
those
just
as
we're
meeting
our
test
goals
and
our
performance
goals
and
everything
else.
We're
meeting
security
goals
coming
out
of
the
gate
and
before
we
ever
actually
run
anything.
A
A
Kubernetes
is,
you
know
a
day
in
a
day
out
for
us
at
stackrock's,
the
top
of
mind
topic,
and
we
wonder
how
close
you
are
or
whether
you
already
are
running
kubernetes
in
production
today,
so
we
like
to
run
these
polls
just
to
see
over
time
how
our
customers
are
gaining
experience
with
the
kubernetes
platform
and
we'll
give
you
a
few
more
seconds.
It's
a
pretty
simple
question:
if
you're
running
kubernetes
in
production
today,
and
then
we
can
get
the.
A
A
Wow
50
50.,
that's
great
all
right!
So
we'll
have
a
couple
more
poll
questions
for
you,
we'll
get
back
to
the
the
questions
here.
So
the
the
first
one
up
is.
You
know
you
spoke
about
vulnerability
data.
Is
that
really
the
scope
that
we're
talking
about
just
doing
vulnerability
scanning
in
ci
cd,
like?
Is
that
the
the
security
issue
that
we're
looking
at
here.
B
Now,
no,
I
mean
that's
that's
one
of
the
security
issues
and
I
think
it's
a
good
one
to
start
with,
because
it's
low-hanging
fruit
and
it's
it's
sort
of
what,
especially
in
the
security
side,
it's
what
we've
got
in
our
mind
around,
for
you
know,
20
years
now
is,
is
managing
that.
But
it's
it's
a
good
example
of
of
why
this
is
the
same
and
different
right.
So
it
you
know,
give
you
an
example.
B
It's
the
same,
whether
I'm
deploying
that
app
on
top
of
a
bunch
of
vms
or
I'm
deploying
that
app
and
a
bunch
of
kubernetes
deployments
or
kubernetes
pods
or
how
you
know.
If,
if
somebody
can
exploit
that
they
can
execute
code,
establish
persistence,
do
all
the
things
that
attackers
want
to
do
from
there
what's
different
about.
B
It
is
how
I
have
to
manage
and
address
that
if
I
have
it
running
on
a
vm's
tradition
on
a
bunch
of
vms
traditionally,
at
2
am
somebody
comes
along
patches,
the
mall
reboots
them
if
they
need
to
and
we're
good
every
everything's
addressed
in
kubernetes.
I
can't
patch
200
running
200
running
pods.
It
just
doesn't
work
that
way,
they're
all
copies
of
the
underlying
image.
The
way
I
have
to
resolve
this
is
go
back
to
the
beginning
of
that
cycle.
Get
a
developer
to
fix
the
image
test.
B
B
You
know
obvious
to
me
that
I
I
had
to
wrestle
with
was
it's
the
same
problem,
but
a
completely
different
approach
to
fixing
it
and
a
completely
different
set
of
constituents
involved
in
fixing
it?
So
it's
important
not
just
that
we
have
the
same
sort
of
security
controls.
We
had
before,
but
that
we
work
in
a
way
that
makes
sense
in
this
new
world,
with
everybody
at
the
table
and
everybody
involved
and
and
really
fit
into
the
tools
that
devops
are
using
to
drive
the
value
and
ship.
These
things.
A
So
what
does
that
really
mean
for
for
a
developer
who's
building
that
application?
I
mean
they're,
the
ones
that
are
responsible
for
that
image,
they're,
the
ones
who
chose
you
know,
presumably
the
the
language
stack
to
build
their
application
on
they
chose.
You
know
the
base
image
to
run
that
on
and
they
chose
the
you
know
the
additional
options
in
there
like.
How
do
we,
you
know?
How
does
the
cicd
help
them
help
them
with
that
like?
B
B
So
I'm
I'm
building
in
this
case
I'm
using
circle.
Ci
honestly,
you
know
the
the
different
ci
cd
platforms,
there's,
there's
a
ton
of
sort
of
different
capabilities
and
different
things
and
reasons
you
might
choose
one
from
our
point
of
view.
From
the
security
point
of
view,
I
think
they're
all
they're,
all
a
lot,
the
same
right,
they're
all
going
to
build
a
thing,
give
us
a
chance
to
do
things
and
and
to
return
data.
B
So
I
happen
to
have
circle
ci
up,
but
it
would
be
essentially
the
same
if
I
was
using
drone
or
azure
devops
pipelines
or
jenkins
or
whatever
else
it
was.
I
just
may
be
approaching
it
a
little
bit
differently
and
in
this
case
I'm
building
a
particular
image.
So
I've
got
a
doctor
file.
It's
a
really
simple
doctor
file,
I'm
building
a
node-based
application.
B
I've
got
some
configuration
to
tell
circleci
how
to
build
this
thing,
and
if
I
look
I
build
it,
and
you
know
I
can
see
my
build
happen
if
you've
ever
done
a
docker
build
before
this
is
all
going
to
look
very
familiar
and
after
I
do
that,
I
do
a
scan
on
that
image.
So
I
say
all
right:
let's
scan
that
image,
let's
pull
it
apart!
B
Look
at
it
look
at
the
composition
of
it.
What
components
are
in
there?
What
vulnerabilities
do
those
versions
of
those
components
have,
but
also
what
else
is
in
this
image?
How
you
know
what
tools
are
in
there?
How
is
it
built?
How
is
it
configured
all
of
these
sorts
of
things
and
and
we're
going
to
do
two
things,
and
then
you
know
it
sort
of
doesn't
matter
whether
I'm
using
stack
rocks
for
another
tool
for
this
these
these
two
things
are
going
to
be
the
same.
B
First
of
all,
we're
going
to
do
we're
going
to
pull
the
image
apart
and
do
some
that
compositional
analysis
and
then
we're
going
to
check
against
the
policies
that
we've
set.
So,
in
this
case,
our
our
output
from
image
scan
is
that
compositional
analysis.
It's
everything
about
that
particular
image.
B
I
have.
I
have
actually
taken
that
we
we
return
that
as
json,
which
is
a
great
way
to
to
format
data
and
do
things
with
it.
I've
taken
it
and
translated
it
into
something
more
human
readable
where
I
can
see
all
of
these
components
all
of
these
vulnerabilities,
where
they
were
added
in
and
tie
that
back
into
what
I
have
now.
B
The
second
thing
we're
going
to
do,
then,
is
check
against
policies
and
see
you
know,
does
this:
how
does
this
image
do
against
our
policies
and
it
turns
out,
in
this
case
I'm
failing
my
build
because
there's
a
policy
here,
that's
being
enforced,
so
we're
saying
in
particular,
vulnerabilities
we're
saying
if
you
have
a
vulnerability
in
here
that
is
higher
critical
in
nature,
that
is,
it
has
a
cvss
score
of
greater
than
equal
to
seven
and
a
fix
is
available
and
you
haven't
fixed
it.
That's
a
problem.
B
We're
gonna,
stop
you
there.
Now,
in
this
case,
I
happen
to
be
using
a
what
I
realized
this
morning
was
a
very,
very
old
version
of
node,
and
so
I
actually
have
a
ridiculous
number
of
vulnerabilities,
but
I
can
see
in
here
you
know
what
packages
I
have,
what
vulnerabilities
are
in
in
those
packages
where
they're
resolved
so
that
I
can
work
through
this
and
and
get
to
where
I
need
to
be
the
other
thing
that
I'm
finding
here,
though
chris-
and
this
goes
back
to
your
your
original
question-
is
besides
all
these
vulnerabilities.
B
I
also
have
wget
in
this
image
and
that's
a
that's
an
interesting
one.
It's
not
a
it's,
not
a
an
immediate
way
that
I
can
get
compromised,
but
what
this,
what
this
is
looking
for,
what
this
policy
tells
me
is
if
somebody
were
able
to
compromise
this
and
execute
code
now
they
have
wget
there
that
which
they
can
use
to
pull
in
other
tools,
get
data
out
of
this
environment.
It's
it's
a
swiss
army
knife
for
them
to
do
things,
and
and
realistically
there's
no
reason
that
my
production
application
should
be
wget.
B
There's
an
add
command
and
a
copy
command
and
and
docker
and
in
general
is
security
guidance.
Everybody
recommends
using
copy
and
not
add,
because
it's
it's
more
limited,
it's
a
better
approach
to
it.
So
we
can
look
for
if
I
use
an
add
command
in
here,
we
can
catch
that,
and
you
know
point
out
that
you're
doing
something
that's
outside
of
a
good
practice.
We
can
look
for
wget
and
curl,
and
one
of
my
other
favorite
ones
is
things
like
the
ubuntu
package
manager
and
the
red
hat
package
manager.
B
Once
again,
it's
a
great
way
for
an
attacker
to
pull
in
additional
things
to
use
after
they've
been
able
to
to
start
establishing
persistence
somewhere
in
the
environment,
but
we
can
also
look
for
things
that
are
obviously
secrets
in
in
there.
So
you
know
we
really
want
to
move
secrets
out
of
images
and
store
them
in
a
secrets,
manager
and
inject
them
properly.
B
A
Right,
I
was
going
to
ask
that,
so
it
sounds
like
you're
talking
about
a
couple
things
that
we
bring
up
on
a
lot
of
these
webinars
right,
some
fundamental
things
about
container
security
that
you
know
empower
the
developers,
get
the
information
in
front
of
them
like
fit
either
fix
those
vulnerabilities
or
remove
those
packages.
Right
like
lower
surface
area
is,
is
a
goal,
and
so
this
sounds
like
we're
doing
here
is
we're
translating
a
goal
like
you
shouldn't:
have
any
extraneous
software
in
your
image
into
this
measurable
thing?
B
Yep
and
then
you
know
it's
it's
it's
right
in
front
of
me
here
and
then
obviously,
I'm
making
this
look
easy,
because
this
is
a
demo
in
a
real
world.
I'd
have
to
do
some
research
figure
out.
You
know.
Am
I
using
wget
anywhere
inside
of
here.
You
know:
what's
gonna
happen
when
I
upgrade,
but
you
know
fundamentally,
I've
got
what
I
need
here
so
I
can
go.
I
can
go
edit,
my
docker
file
and
say
all
right,
let's
by
the
way
you
generally
shouldn't
edit
directly
in
github
either,
but
what
I.
B
B
If
I
come
back
over
here
and
if
I
look
because
I've
got
this
integrated,
a
new
build
should
kick
off
there.
It
goes,
and
so
now
it's
it's
going
to
take
a
little
while
to
to
build,
but
we're
going
to
see
that
I've
I've
resolved
those
issues.
My
my
build
should
succeed
because
now
I'm
not
going
to
have
any
critical
vulnerabilities
in
there
that
have
fixes
available
that
are
unfixed.
A
A
B
B
Normally,
what
I
would
see
is
is
a
hand
because
we
we'd
at
this
point,
have
a
rhythm
we'd,
be
building
things
regularly.
If
I
have
image
or
if
I
have
new
vulnerabilities,
showing
up
they're,
either
actually
new
vulnerabilities
or
there
I
added
a
component-
and
I
added
an
older
version
of
that
component.
B
A
Know
yeah
what
you
got
set
up
here
is
like
a
security
rule
that
just
says
you
can't
have
these
vulnerabilities,
but
it's
really
up
to
the
developer
to
decide.
Do
they
choose
a
different
image?
Do
they
update
the
one
that
they
have?
Do
they
try
to
remove
some
of
the
extraneous
software?
Like
there's,
you
know,
as
long
as
you
meet
their
ultimate
security
requirement,
then
then
you're
good
right.
We
can
give
them
that
flexibility
to
decide
how
they
want
to
reach
that
particular
policy.
Yeah.
B
What
we
want
to
do
is
point
out
problems
give
them
the
data
that
they
need
to
resolve
them
and
then
and
then
let
them
fix
them
in
a
way
that
makes
sense
in
the
bigger
environment
but
yeah.
So
I
can
see
here
now
I've
I've
resolved
those
issues.
My
build
is
succeeding,
we're
good
to
move
forward
from
here
now
we
have
one
more
problem
that
that
crops
up
here
and
that
is
as
part
of
cd.
B
We
want
to
check
not
just
not
just
the
image
we
built,
but
as
we
deploy,
we
want
to
check
for
those
deploy
time
things.
So
if
I
look
at
this,
I've
got
in
this
case.
I've
got
my
deployment
yaml.
Here
I
can
see
I've
got
my
deployment
is
going
to
fail
specifically
because
I
have
a
rule
that
says
I
can't
run
as
a
privileged
container,
and
I
am
in
fact
running
as
a
privileged
container.
B
I
have
some
other
deploy
time
things
here
as
well
that
we're
not
enforcing
on,
like
I'm,
not
using
a
read,
I'm
not
using
a
read-only
root
file
system,
which
I
ought
to
use.
I
I'm
not
using
I'm
not
specifying
resource
requests
and
limits,
so
I've
got
some
deploy
time
things
here
to
fix
as
well,
which
I
can
which
I
can
also
go
do,
and
you
know
typically
this.
This
may
not
be
the
same
team,
but
it's
it's
once
again.
B
B
So
in
this
case,
I
can
come
back
here
and
fix
this
and
say,
and
you
know
once
again,
I'm
making
this
look
easy,
probably
if
I've
set
this
to
run
as
privileged
to
begin
with.
There's
some
reason
for
that:
we're
going
to
have
to
figure
out
what
it
is.
We
might
have
to
go
back,
get
an
exception
based
on
on
need,
whatever
else
the
bigger
policy
is,
but
for
right
now
I
can.
B
A
So,
while
we're
doing
that
a
couple
of
things,
one
we'll
put
up
the
next
poll
question
that
we
have
for
the
audience
here
and
get
everybody
to
think
about
the
the
the
queries
that
we
have
here
for
teams
and
ask
you
if
container
security.
The
topics
that
we're
talking
about
here
today
are
an
active
project
or
something
that's
coming
up
for
your
organization,
we'd
love
to
know.
We
also
have
some
questions
from
the
audience
here
that
we
can
start
to
go
through.
As
a
reminder,
this
is
a
live
session.
A
We'd
love
your
questions
using
the
q,
a
section
there.
If
you
want
to
go
back
to
something
that
we've
already
covered,
we're
happy
to
do
that
we're.
You
know
we'll
be
able
to
answer
your
questions,
but
the
the
question
here
that
I
have
in
front
of
me
is
just
a
more
basic
question
about
the
difference
between
kubernetes
and
containers,
and
I
think
you're
illustrating
some
of
that.
At
least
from
from
the
security
perspective.
A
For
this
environment
and
and
from
the
security
perspective,
our
concern
here
is
that
there's
things
you
can
do
both
at
the
image
at
the
container
level
and
at
the
kubernetes
level
that
impact
security
and
a
lot
of
developers
just
either
aren't
familiar
with
them
or,
don't,
frankly,
don't
really
care,
but
the
security
team
sure
does,
and
we
want
to
try
to
cross
the
the
try
to
cross
the
the
the
the
gap
between
those
two
teams.
Here.
B
B
We're
going
to
start
up
so
many
copies
of
this
with
these
parameters,
we're
going
to
run
it
as
a
privileged
container,
not
as
a
privileged
container
we're
going
to
expose
these
ports
in
this
way
and
to
put
the
whole
thing
together
and
run
it
at
scale,
run
it
in
a
way
that
you
can.
You
can
do
all
of
that.
B
And
then
take
it
out
from
there
so
from
a
security
perspective
yeah.
It's
absolutely
important
that
we're
looking
at
both
of
those
things
you
know
is
the
under
are
the
underlying
components
of
the
microservices,
all
well-built
and
well-formed,
and
free
of
vulnerabilities
that
we're
concerned
about,
and
then
are
we
running
them
in
a
way
that
matches
what
we
need
from
them
and
are
we
deploying
them
in
a
way
that
has
only
that
least
privilege
that
they
need.
B
Good,
so
let
me
so
you
know
I
mean,
obviously
let
me
let
me
show
you
some
of
the
underpinnings
of
this
right,
so
this
is,
this
is
all
being
returned
from
from
stackrocks
right
and,
and
so
I
can
set
up
all
these
things
right
now.
These
are
just
default
values
for
this,
but
let
me
let
me
walk
it
back
a
second,
so
I
can
go
to
the
underlying
policy,
and
that
is
privileged
right.
So
I
can
I
can
edit
this,
and
so
what
I
can
do
is
say
you
know.
B
A
B
So,
and-
and
you
know
so
for
me,
as
as
you
grow-
I
mean
it-
we
we
have
customers
from
very
small
startups
to
very
very
large
fortune,
100
companies
right
and
there's,
there's
certainly
a
different
approach.
If
for
a
small
company-
and
you
know
I
can-
I
can
think
of
customers-
I've
worked
with
that
have
one
or
two
people
who
are
doing
both
security
and
devops
work.
B
I
don't
want
everybody
coming
into
the
stackrocks
portal,
no
matter
how
pretty
it
is,
and
it
is
it's
it's
pretty.
It's
got
great
graphs
and
charts
and
strong
information,
but
you
know,
if
I
look
at
say
my
devops
teams,
they're
already
in
say
circle,
ci
they're,
already
in
jira,
they're,
already
influenced
they're
already
in
three
or
four
other
portals
and
tools
and
apps
and
they've
already
got
data
coming
from
all
of
these
other
places.
B
B
I
want
to
integrate
with
where
people's
eyeballs
already
are
and
make
sure
that
they're
getting
the
right
data
there
and
customize
that
data
to
match
match
what
I'm
doing
now.
Of
course,
you
know
back
to
the
original
question.
There's
a
larger
component,
which
means
you
know.
Stackrocks
is
not
the
only
piece
of
this.
We
have
to
have
written
the
policies
down
somewhere.
B
You
know
whether
that's
in
a
wiki
page
or
wherever
it
is
and
and
not
just
say
this
fails
because
stackrock
says
so
but
say
it
fails,
because
we
have
these
policies
govern
governing,
how
we're
going
to
develop
things
and
how
we're
going
to
deploy
things.
And
here
it
is
written
out
and-
and
you
know,
here's
the
exception
process
and
all
the
other,
all
the
other
process.
Components
that
allow
you
to
to
go
on
all
the
layer.
Eight
we
used
to.
A
I
also
feel
like
I
could
be
I'm
a
little
optimistic.
I
I
love
that
we
have
this
rationale
field
in
there
to
help
the
devops
teams
understand
why
this
is
a
security
issue
like
what
it
really
means
from
a
security
perspective,
and
you
know
I'm
kind
of
hopefully
very
you
know
I
have
the
idea
about
a
developer.
Who
wants
to
do
the
right
thing?
A
B
A
B
Yeah,
so
there's
there's
a
couple
of
approaches
to
that.
You
know
I'll
show
you
sort
of
ours
what
I
would
think
what
I
would
think
of
as
the
best
approach
to
that,
and
that
is
the
ability
to.
If
I,
if
I
look
at
this
by
the
way,
is
the
vulnerability
management
workflow.
This
would
usually
be
focused
on
our
analysts
or
our
security
people
walking
through
figuring
out.
B
You
know
where.
How
are
we
doing
across
everything
so
usually
the
way
you
would
approach,
that
is
to
say
you
know
we're
gonna,
we're
gonna.
Do
some
research
and
we're
gonna
see
a
couple
of
new
vulnerabilities
and
go.
You
know
what
these
aren't
that
important
to
us,
we're
gonna,
snooze
them
and
we
can
snooze
for
a
period
of
time
or
indefinitely
to
say
for
the
next
month
we're
not
going
to
we're
not
going
to
worry
about
those
two
vulnerabilities
we're
going
to
we're
going
to
put
them
off
to
the
side
in
30
days.
B
We
can
come
back
and
see
if
people
have
fixed
them
and
obviously
I
can
always
go
and
look
at
what
vulnerabilities
are
currently
sort
of
out
of
scope.
What
what
are
we
not
looking
at
this
is?
This
is
for
me,
the
best,
the
best
sort
of
approach
to
to
doing
that,
because
it
allows
me
to
to
centrally
and
programmatically
make
that
sort
of
determination
and
and
dive
into
it
and
say
yeah.
This
is
this
is
where
we
are,
and
this
is
this
is
what
what
what's
important
and
what's
not
important
to.
A
Me,
the
key
part
of
this
question
is
who's
the
one
making
the
decision
to
accept
that
vulnerability
right.
We
can
give
the
developers
that
power,
but
it
could
get
abused
right
and
if
you've
got
a
security
team
who
is
answerable
to
to
a
higher
power
right
to
auditors,
to
the
cso
organization,
to
you
know,
who's
going
to
get
blamed
if
this
is
actually
gets
exploited
out
there.
So
we
provide
a
lot
of
options.
You
know
there
is
what
we
call
a
break
glass
procedure
in
our
product
that
allows
someone
to
get
a
deployment
created.
A
B
Oh
sorry,
I
was
going
to
say
there's,
I
think,
there's
another
question
that
you
have
to
answer
and
that
is,
if
we're
going
to
enforce
these
policies,
do
we
enforce
them
at
build
time
or
deploy
time
and-
and
you
know
it's
a
choice-
I've
I've
heard
arguments
either
way.
You
know,
let's
enforce
them
at
build
time,
let's
move
them
as
far
left
as
possible,
so
we
know
immediately,
what's
going
to
what's
going
to
be,
what's
going
to
be
problematic
and
what's
not,
but
I've
worked
with
customers
who
went
the
other
way.
B
They
don't
enforce
anything
at
build
time,
because
developers
are
playing
with
things
and
trying
things
and
working
from
there,
but
at
deploy
time
they
have
a
very
clear
set
of
policies
and
in
what
they've?
Added
in
that
description,
rational
remediation,
it's
clear
that
you
know
when
I
build
it,
I
can
see
that
these
things
are
going
to
be
enforced
at
deploy
time.
I
have
to
fix
these
things
before
I
deploy.
B
So
that's
that's
another
piece
of
it
is
you
know
operationally
what
makes
sense
in
in
your
bigger
picture,
how
your
processes
work
and
how
you
know
what
how
things
are
are
running
and
who's
doing
what
and
who's
responsible
for
what
is
is
that
question
of?
Are
we
enforcing
these
policies?
If
so,
which
policies
are
we
enforcing
and
where
are
we
enforcing
them
along
the
way.
A
Right
so
one
more
question
actually
along
those
lines,
so
you
mentioned
about
enforcement
and
the
ways
that
we're
that
we're
doing
that
here
there's
a
question
here
about
how
we
compare
ourselves
and
how
we're
different
from
other
security
tools
out
there
that
deal
with
containers
that
might
have
features
like
this
in
general.
You
know
my
answer
to
that
question
is
always
that
you
know
where
kubernetes
native
and
things
like
enforcement
should
be
done
through
kubernetes.
B
Yeah
and
that's
and
that's
a
great
question,
you
know,
and
and
so
in
terms
of
that
in
in
particular,
you
know
we
talk
about
being
kubernetes
native,
obviously
in
ci,
that's
before
kubernetes
right,
we're,
not
kubernetes
native
yet,
but
we
do
we
do.
We
have
the
ability
to
centrally
manage
that
enforcement
behavior
for
build
time
policies
at
deploy
time.
B
This
is
this
is
one
of
my
favorite
things
we're
using
the
admission
controller
inside
of
inside
of
kubernetes
and
openshift
chris,
and
I
say
kubernetes,
we
really
every
time
you
hear
us
say
kubernetes,
you
can
think
kubernetes
an
open
shift
in
in
your
head.
Openshift
is
you
know
it's
it's
weaponized
kubernetes
effectively,
but
the
admission
controller
is
is
a
really
strong
way
of
doing
this
when
we
compare
it
to
the
alternative,
which
is
what
a
lot
of
other
products
are
using.
So
the
alternative
is
to
enforce
it
at
at
the
various
nodes.
B
The
vms
that
that
kubernetes
are
openshift
is
running
on
so
you
know,
and
that
that
happened,
because
those
products
were
built
to
support
docker
and
ecs
and
all
of
these
other
non-kubernetes
platforms.
So
you
had
to
do
it
in
a
more
universal
way,
but
effectively
what
happens
is
I
do
cube.
Ctl
apply,
dash,
f,
something
right.
I'm
deploying
something.
B
Kubernetes
accepts
that
deployment
schedules
the
pods
to
run
on
those
nodes,
those
vms
and
in
the
environment.
The
pods
then
bring
up
containers
and
the
product
looks
at
those
containers
and
says:
oh
now
that
violates
this
policy,
which
we're
enforcing
and
kills
the
container
from
a
security
perspective.
We've
met
our
need
to
enforce
that
policy.
B
B
In
contrast,
with
the
admission
controller,
when,
when
I
do
cube,
ctl
apply
dash
from
yaml,
whether
I'm
doing
that
manually
on
my
keyboard
or
my
my
continuous
deployment
is,
is
doing
it
auto
in
an
automated
fashion,
when
it
hits
kubernetes
before
kubernetes
accepts
it,
it
passes
it
off
to
the
admission
controller.
The
admission
controller
can
pull
that
apart
and
go.
Oh,
no.
You're
trying
to
run
this
as
privileged
you're
not
allowed
to
do
that,
return
that
failure
and
and
we're
going
to
immediately
see
you
know
like
like
we
did
back
here
all
right.
B
This
is
running.
It's
privileged,
that's
not
allowed
that's
going
to
fail.
We
can't
do
that
and
then
the
added
bonus
is
like
we're
doing
here
inside
of
circle
ci.
We
can
check
that
before
we
deploy,
so
we
don't
even
have
to
get
as
far
as
trying
to
deploy
it.
We
can
check
it
and
say
yeah.
This
is
this
is
going
to
fail,
this
isn't
allowed.
This
isn't
okay
and
get
all
of
that
in
context
and
get
get
all
the
rich
sort
of
data
about
that.
A
Great
thank
you
and,
and
for
anyone
who
is
on
listening
in
and
you
know
we
talk
about
the
different
products
out
there.
These
different
approaches.
You
know
we're
more
than
happy
to
demonstrate
the
product
to
you
in
a
in
a
personalized
session,
and
you
know
it'd
be
an
opportunity
to
reach
out
to
us
and
ask
for
a
demo
and
neil
or
I
or
one
of
the
other
engineers
in
the
team
will
be
happy
to
answer
questions
and
compare
pretty
closely
how
this
works
compared
to
some
of
the
other.
The
other.
A
The
other
tools
that
are
out
there
that
kubernetes
native
part
of
it
is
is
really
not
just
the
the
compatibility
with
the
platform,
but
that
philosophy
right
that
fail
early,
don't
conflict
with
the
with
the
orchestrator,
don't
create
operational
risk,
so
we're
happy
to
demonstrate
that
more
thoroughly
jumping
around
a
little
bit
here,
there's
a
question
about
going
back
to
vulnerability
data
you
know:
does
our
product,
I
guess,
scan
for
like
application
stack
like
python
application,
vulnerabilities
yeah?
Is
there
multiple
packages
from
python
or
node
or
something.
B
So
there
are
from
python
node
java,
ruby,
yeah
and-
and
you
know
it's
an
interesting-
it's
an
interesting
piece
but
yeah
we're
looking
at
we're
looking
at
all
of
those
things,
so
not
just
what
the
package
manager
added
into
the
image,
but
also
what
I
used
npm
or
the
the
java
jars
that
I
copied
into
that
package
here
I
see
a.
I
see
a
good
example
right
here.
If
I
look
at
if
I
look
at
this
particular.
B
Image,
that's
that's
being
used.
It
has
struts
2.3.12
in
it,
which
is
a
a
java
jar.
That's
been
copied
into
the
image,
it's
actually
a
java
jar
buried
inside
of
another
java
jar
inside
of
this
image,
so
we've
gone
through
and
and
seen
that
there's
a
root.war
file
in
in
here
we've
decomposed
that
seen
that
there's
the
struts
2
core
2.3.12
jar
inside
of
that
went
yeah
stud,
struts
22.3.12,
that's
a
really
terrible
version.
There's
some
horrifying
vulnerabilities
inside
of
there,
and
here
they
are
yeah,
look
at.
A
Consider
your
choices!
Well,
you
know
it's
something
where
we
see
a
lot
of
enterprises
making
their
first
leap
into
containers
and
they're
moving
existing
applications
that
were
built
for
virtual
machines,
that,
like
you
mentioned,
they
have
an
existing
patching
process,
but
now
they're
putting
them
into
containers
and-
and
you
just
can't
you
know
practically-
you
know
patch
the
running
containers
and
so
they're
going
to
run
right
into
this
kind
of
problem
when
they're
lifting
and
shifting
an
application.
A
A
B
So
so
effectively
json
is
the
option,
and
I'm
I'm
discarding
the
json
here.
So
you
can't,
you
can't
see
it,
but
it
returns
a
huge
json
blob
of
everything
about
about
that
image.
What
components
are
in
there?
What
are
the
layers
in
there?
What
are
the
vulnerabilities?
What
are
where
are
the
fixes
for
those
vulnerabilities?
What
other
issues
are
there
so
that
we
can?
We
can
apply
that
and
in
this
case
I'm
taking
that
and
transforming
that
into
the
csv,
which
gives
me
this
information.
B
So
now
I
can
see
you
know
if
I'm
looking
for,
I
don't
know
open
ssl
as
an
example,
let's
say
I'm
trying
to
fix
my
open,
ssl
vulnerabilities,
I
can
see
here
they
are.
I
can
see
they're
in
layer
two,
which
is
where
I
run
apt-get
update
an
apt-get
install
a
bunch
of
things,
and
so
I
can
see
where
I
can
take
that
data
and
really
transform
it
into
any
sort
of
format.
B
I
want
in
this
case
I've
done
it
in
the
csv
I
I
grew
up
using
excel
as
sort
of
my
primary
data
analysis
tool
for
an
excessively
long
period
of
time.
So
it's
what
I'm
still
comfortable
with,
but
yeah.
You
can
take
that
data
and
really
do
anything
with
it
to
to
build
out
the
sort
of
you
know.
Human
readable
form
you
want
or
it's
it's
json.
You
need
to
take
it
to
some
other
machine
format.
It's
it's
remarkably
easy
to
do
it.
That's
that's
really.
Json's
reason
for
existing.
B
A
A
A
Poll
there
it
is
so
these
are
our.
This
is
a
multi-select
poll
about
use
cases
for
security.
Today,
we've
mostly
been
talking
about
things
like
vulnerability
and
configuration
management,
but
you
know
we
cover
all
of
the
topics
you
might
want
any
security
or
compliance
solution.
I'd
love
to
know
where,
where
the
interest
is
today.
A
And
see
if
any
more
questions
have
popped
up
there
was
a
question
about
checking,
docker
files
or
docker.
You
know
images,
I
guess,
for
you
know,
through
the
docker
file
for
for
secrets,
because
it's
a
best
practice
not
to
hard
code
secrets-
and
you
know
not
to
use
certain
commands
like
add
you
know,
is
there?
Is
there
a
one,
one-size-fits-all
kind
of
solution
to
that
problem?
Or
you
know?
Is
it
something
where
we
have
to
apply
multiple
techniques.
B
So
out
of
the
box,
let
me
let
me
come
back
here
from
a
stackrock's
perspective.
Out
of
the
box,
we've
got
60
60,
some
policies
that
cover
a
lot
of
space,
but
yeah.
There's
not
there's
for
almost
all
of
these
there's,
not
a
single,
a
single
solution
that
fits
everything,
so
you
may
be
using,
for
instance,
here's
here's.
B
It
lets
you
do
all
sorts
of
things
that
you
want
to
do
it's
something
that
attackers
use
a
lot
to
move
data
around
and
make
connections
and
open
connections
elsewhere,
and
it
tends
not
to
be
something
that
we
want
running
in
environments.
But
in
the
last
few
years
I've
worked
with
three
separate
customers
who
were
using
netcat
for
whatever
reasons
they
had
inside
of
their
environment.
B
So
a
policy
like
this
makes
sense
99
of
the
time,
but
there's
that
one
percent
who's
using
netcat
because
they
they
solved
a
problem
with
it
once
they
know
it's
what
they've
codified.
So
I
think
all
of
these
you
know,
there's
a
rational
set
of
things.
Things
defined
by
default,
some
of
those
you're
going
to
look
at
and
say
this
doesn't
really
match
what
we're
doing.
B
A
Yeah,
so
when
it
comes
to
some
of
these
things,
it's
like
you
know,
applying
swatting
flies
right.
The
developers
will
find
very,
very
creative
ways
to
get
things
done.
I
mean
that's
why
you're
you're
hiring
them.
That's
why
you're
paying
them
and
some
of
those
things
they
don't
realize,
have
those
security
repercussions,
and
you
know
things
like
secrets.
We
find
a
lot
of
creativity.
A
I'd
say
that
probably
the
biggest
issue
with
secrets
that
we
see,
because
if
you
go
out
to
stack
overflow-
and
you
look
at
you-
know
the
questions
like
how
do
I
get
a
password
for
the
the
postgres
database
into
my
application?
You'll
see
it
recommended
to
use
things
like
an
environment,
variable
and
and
yeah-
that's
a
terrible
way
to
do
it.
So
you
know
we're
looking
for
things
where
someone
might
be
using
like
a
plain
text
path
or
embedding
a
secret
somewhere.
I'm
not
sure
you
could
get
all
of
them,
but
you
can.
B
Yeah,
absolutely
and
then
for
secrets
in
in
particular.
That's
a
good
point
right.
What
we're
looking
for
are
you
know
the
the
obvious
ways
that
people
have
tried
to
use
a
secret
in
an
inappropriate
way.
If
somebody
is
is
actively
trying
to
to
hide
it,
then
it
is
effectively
protected
because
it's
already
been
hidden
but
yeah.
There's
there's
a
there's
a
difference
there.
That's
that's
kind
of
important
yeah.
A
B
You
know
I
would,
I
would
think
of
these
as
being
to
some
extent,
there's
a
lot
of
overlap
with
with
those
standards
right.
These
are.
These
are
manifestations
of
the
things
in
those
standards,
so
I'm
gonna
give
you
two
answers,
but
I'm
gonna
start
there
and
I'm
gonna,
I'm
gonna
start
with
another
one
of
my
favorite.
If
I
can,
if
I
remember
the
name
of
the
policy.
B
Yeah
here
we
go
so
pci
dss
says
that
you
should
and
ensure
the
the
image
the
entire
file
integrity
of
your
underlying
one.
I
I
forget
the
exact
language,
but
one
of
the
great
ways
you
can
do
that
in
container
environments
is
by
setting
the
root
file
system
to
be
read
only
so.
If
I
can't
write
to
the
file
system,
I've
I've
ensured
the
integrity
of
all
those
files.
B
So
this
policy
is
going
to
map
really
well
to
that
requirement
inside
of
inside
of
pcidss
and
give
you
the
ability
to
to
not
just
not
just
audit
that.
But
you
know
if,
like
pci,
is
important
to
you,
it's
pci's
not
is
something
that's
not
only
a
little
bit
important
right
if
you're
covered
under
pci,
it's
very
very
important,
so
it
gives
you
the
controls
to
be
able
to
say
not
just
that.
We
know
that
this
is
a
problem,
but
to
say
in
this
name
space
in
this
area.
B
In
this
application
that
processes
credit
cards,
we're
going
to
enforce,
you
can't
even
deploy
if
you
haven't
configured
it
properly
in
a
way
that
meets
that
standard.
Now,
more
generally,
in
stack
rocks.
We
can
also,
for
those
standards,
show
you
you
know
where
you
have
problems
and
dive
into
it
and
see
all
of
all
the
underlying
controls
and
all
of
the
all
the
pieces
and
report
on
that
and
give
your
auditors
reports
based
on
those
things
and
and
get
to
them.
B
B
Yeah
absolutely
this
is
this
is
basically
a
you
know.
The
built-in
policies
are
good
practice,
but
beyond
that
this
is
a.
This
is
a
canvas
for
you
to
paint
those
things
that
are
important
to
your
org,
that
you
want
visibility
into
and
go
from
there
and
you
can
both
create
a
new
policy
from
scratch,
and
you
can
you
know
you
can
take
what
existing
policies
work
from
there
and
just
to
give
you
an
idea
of
one
of
my.
B
I
keep
saying
my
favorites,
but
another
favorite
policy
of
mine,
annotations
and
labels
are
super
important
in
kubernetes
to
define
everything
from
like
what
sort
of
load
balancer
you're
gonna
get
to.
I
worked
with
a
customer
recently
who
was
using
annotations
for
for
project
ids
to
assign
cost
back
to
teams,
and
so
we
have
a
sample,
that's
sort
of
like
that,
but
I
can
take
this
sample
and
say
you
know
this
is
going
to
be
my
project
id
I
could
I
could
clone
this.
I
can
edit
it
whatever.
B
I
want
to
do
create
a
new
policy
from
scratch,
but
I
can
take
the
requirements
in
here
and
say:
you
know
it
must
be
project
id
and
you
can
see
we
can
use
regex
for
the
value.
So
I
can
say
you
know
it
must
be
I'm
terrible
with
regex,
but
I
could
you
know
we'll
just
say
it
must
have
any
value,
but
I
can
put
in
a
regex
there
that
says
it
must
be
four
letters
dash
five
digits
or
whatever
my
project
ids
are
so
yeah.
B
You've
got
a
wide
variety
of
things
that
you
can
combine
to
not
just
take
the
existing
policies
but
to
create
new
policies
and
and
take
any
of
these
sorts
of
things.
You
know
I
could
say,
for
example,
you
know
just
spitting
it
out
here.
Maybe
I
only
need
project
ids
on
things
that
are
exposed
with
a
load
balancer,
so
they're,
available
outside
of
my
cluster.
A
That
is
really
cool
and,
and
the
message
that
I
get
from
that
is,
is
whatever
the
security
team
put
in
there.
So
if
the
devops
teams
ignores
the
the
the
slack
message
that
says,
hey,
everybody
needs
to
have
a
project
id
they're,
going
to
find
out
pretty
quick
one
way
or
the
other
right.
They're,
gonna,
they're
gonna
have
that
message
front
and
center
that
says
hey
this
is
it
I
mean
it's
a
means
of
communicating
those
security
policies
to
to
the
broader
audience
right.
A
One
thing
I
love
about
this
approach
is
too
is
that
you
can
start
by
alerting
people
that
doesn't
have
to
be
an
enforcement
mechanism.
You
can
start
to
say,
hey
look,
this
is
going
to
be
required
and-
and
they
learn
about
and
understand
what
that
means
before
you
start
to
close
the
door
on
on
any
new
deployments
that
that
violate
that.
A
B
And-
and
so
I
can
integrate
that
when
I
happen
to
have
slack
up
and
running
in
this
lab,
so
I
could
start
sending
slack
messages
or
I
could
integrate
email
or
whatever
other
sort
of
channel.
I
wanted
to
send
that
in,
but
I
can
I
can
do
that
without
actually
starting
to
enforce
that
say
you
know
chris,
we
talked
about
this.
You've
got
to
have
a
project
id
and
your
deployment
you're
not
doing
it
you're
not
doing
it,
you're
not
doing
it
and
send
that
and
automate
that
and
yep
great.
A
Well,
we
are
coming
up
on
time
for
the
a
lot
of
time
here,
there's
one
more
poll
question,
which
is
just
really
simple:
that
if
you've
enjoyed
today
and
you've
had
some
time
to
spend
with
you
know
with
us,
if
you
want
to
see
more,
we
are,
you
know,
motivated
to
make
sure
that
everybody
gets
as
much
a
stack
rocks
as
they
can
handle.
So,
if
you
have,
if
you
have
any
any
questions
that
we
can
answer,
we
can
provide
you
with
a
specific
tailored
demo.
A
We
can
even
offer
a
30-day
trial,
the
platform
in
your
environment,
to
help
you
know,
help
you
build
policies,
discover
where
the
security
issues
are.
We
do
have
a
last-minute
question
here,
someone's
watching
very
closely
in
those
policies.
There's
an
item
marked
restrict
to
scope.
What
does
that
do
like?
How
do
how
do
I
put
a
restriction
in
my
policies.
B
Yeah,
so
let
me
let
me
come
back
here.
Let
me
just
we
talked
about
privileged
containers
earlier
and
why
I
would
want
to
why
I
would
want
to
have
privileges
or
not
have
privileges,
and
so
I've
got
restrict
and
exclude
our
side
by
side
right,
which
ones
do
I
want
to
apply
to.
Where
do
I
not
want
it
to
apply
so
you
can
see
in
this
particular
case,
I
am
excluding
the
stacks
stackrock's
namespace,
cube
system,
istio
system,
openshift,
node,
etc.
B
B
So
now
in
the
production
cluster,
you
cannot
run
as
privileged
unless
you're
in
the
stack
rocks,
name,
space
or
cube
system
or
etc,
and
I
can,
I
can
add
other
constraints
right.
I
can
say,
restrict
this
to
a
particular
namespace.
Only
things
labeled
as
don't
know
you
know
whatever
whatever
I
want.
I
can,
I
can
add
those
those
things
so
that
each
of
my
policies
applies
to
some
venn
diagram
set
of
different
things
deployed
in
my
in
my.
A
B
A
So
I'll
kind
of
summarize,
in
maybe
some
grand
terms,
you
know-
we've
been
talking
about
turning
kubernetes
into
a
security
orchestrator
for
a
long
time,
but
I
think
with
the
circle
ci
demos
you've
got
there
we're
also
turning
your
cicd
pipeline
into
you
know
a
security,
education
and
enforcement
tool,
and
you
know
done
in
a
way
that
is
developer
centric,
but
but
ultimately
down
to
the
people
who
have
to
answer
for
security
right.
Your
security
and
security
operations
teams.
That's
a
fair
assessment.
A
Great
well,
neil,
it's
been
a
pleasure.
There's
no
more
questions
here.
Folks,
if
you
have
anything
else,
you
can
always
reach
out
to
us
and
we'll
send
up
follow-up
emails
to
everybody
with
the
recordings
here.
I
haven't
certainly
enjoyed
it
and
I
hope
everyone
has
a
great
day
and
enjoys
the
rest
of
their
evening.
Thank
you.