►
From YouTube: DevSecOps Lunch and Learn (Hashi)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone,
and
thanks
for
attending
today's
virtual
lunch
and
learn
my
name-
is
tam
and
I'll
be
moderating.
Today's
virtual
event,
we
have
the
hashi
team
with
us
today:
paul
cermeyer
enterprise,
account
manager
and
patrick
griezon
senior
solutions.
Engineer
they'll
be
going
over
the
hashi
overview
thanks
for
joining
us
today,
guys
and
then
on
the
stackrock
side.
We
have
chris
porter
our
director
of
solutions,
engineering
to
give
us
a
live
demo
and
quick
overview
of
stack
rocks.
A
A
If
you
don't
see
a
pop-up,
you
might
have
your
pop-up
disabled,
so
just
check
on
that
and
I'll
leave
this
open
for
a
couple
more
seconds
and
let
the
audience
answer
this
question.
A
B
All
right,
awesome,
tim.
Thank
you.
So
much
appreciate
it
and
just
happy
to
be
here.
Stackrocks
has
been
a
great
partner
of
ours
and
I
think
that
there's
a
lot
of
ways
that
we
help
each
other
from
a
kubernetes
standpoint
and
also
from
just
securing
workloads
in
this
kind
of
multi-cloud
strategy.
B
So
before
we
touch
a
little
bit
on
vault,
I
actually
wanted
to
take
a
step
back
and
talk
kind
of
about
hashicorp
in
general.
I
think
that
we're
in
this
really
unique
opportunity
being
an
open
source
company
and
that
many
people
are
familiar
with
our
tools,
terraform
and
vaulted
console,
but
not
so
much
with
the
company
as
a
whole.
So
just
wanted
to
shine
a
little
bit
about
that.
B
So
really
hashicorp
in
essence,
is
you
know
how
to
align
people,
processes
and
tools
to
get
the
most
value
out
of
a
multi-cloud
environment
and
so
for
most
enterprises.
There's
this
idea
that
you
know
this
huge
buzzword
of
digital
transformation
and
what
that
really
means
is
that
new
businesses
need
to
find
a
way
to
engage
with
customers
faster
and
at
a
much
larger
scale,
so
as
opposed
to
using
cost.
B
As
the
basis
for
optimization,
it's
now
speed
as
the
basis
for
optimization,
and
I
really
like
to
use
the
phrase:
it's
not
about
the
big
eating,
the
small
anymore.
It's
about
the
fast
being
the
slow.
We
see
that
all
the
time
within
netflix's
or
the
capital
ones
in
the
world,
so
the
cloud
really
plays
this
kind
of
critical
piece
and-
and
that's
simply
because
you
know
you
have
on-demand
capabilities,
you
have
virtually
limitless
scale
and
technologies
that
just
don't
really
exist,
on-prem,
and
so
we're
really
here
to
help.
B
You
know
companies
take
advantage
of
that
from
a
workflow
approach,
not
necessarily
a
technological
approach,
and
so
the
way
that
we
do,
that
is
that
we
think
about
the
workflow,
not
just
the
technology.
So
each
of
our
technology
stacks
on
the
right-hand
side,
focuses
on
a
specific
workflow
that
an
it
stratification
is
having
a
challenge
with
and
then
that
kind
of
ties
back
into
a
technologically
agnostic
backend,
so
providing
companies,
freedom
and
able
to
use
you
know
whichever
environment
they
want,
and
so
in
essence,
hashicorp
is
the
industry
leader
in
cloud
infrastructure,
automation.
B
We
provide
a
software
stack
that
allows
customers
to
provision
secure,
connect
and
run
any
application
on
any
infrastructure
both
from
the
on-prem
world
and
also
in
any
cloud
environment,
and
to
talk
about
our
company.
So
we
were
founded
in
2012
by
two
people,
mitchell
hashimoto
and
armand
dodger,
and
they
were
devops
engineers
just
like
a
lot
of
people.
You
know
on
the
lunch
and
learned
today
and
a
lot
of
these
tools
started
out
as
passion
projects
to
solve
for
their
existing
workflows.
B
B
And
fortunately
that's
that's,
been
growing
exceedingly
well:
we've
actually
grown
a
hundred
percent
in
the
last
year
we
have
just
under
a
thousand
employees,
and
our
funding
is
a
little
bit
off.
It's
actually
349
million.
B
In
our
last
series
e,
which
was
led
by
franklin
templeton,
one
of
the
largest
financial
companies
on
earth
and
ivp,
which
I'm
not
going
to
blame
you,
if
you
don't
know
that
venture
capitalist
firm,
but
you
certainly
know
the
disruptive
companies
that
they
support
and
that
would
be
netflix
uber,
twitter,
slack
and
snapchat
as
well
stackrocks.
B
So
we
also
have
over
700
enterprise
customers
that
are
across
the
fortune,
500
and
global
2k
segmentation.
So
it
just
kind
of
gives
you
an
idea
of
the
criticality
of
the
work
that
we
support.
B
And
so,
when
we
think
about
you,
know
kind
of
this
world
and
where
we're
going
from
and
kind
of
the
need
for
for
application
delivery,
we
kind
of
have
to
take
a
step
back.
You
know
how
are
things
from
the
existing
on-prem
world
and
how
are
things
in
this
multi-cloud
environment
and
we
decompose
that
problem
into
four
layers.
B
We
have
operations,
teams,
security
teams,
networking
teams
and
developers-
and
I
hope
you
guys
are-
are
part
of
those
teams,
because
I
think
that
you're
in
the
the
right
lunch
and
learn
and
from
a
operation
standpoint
if
we
just
think
about
how
things
work.
So
you
know
in
a
static
environment,
things
are
very
dedicated,
they're
homogeneous.
These
are
rack
servers.
You
know
on
an
on-prem
or
cola
environment
in
a
dynamic
world,
so
in
a
cloud
world.
Well,
this
is
on
demand.
It's
heterogeneous.
It's
across
different.
B
You
know,
availability
zones,
it's
just
a
little
more
complex
from
a
security
standpoint,
we're
going
from
a
high
trust
environment,
so
we're
using
ip
as
the
basis
for
security.
And
that's
you
know,
everything
in
my
private
range
is
completely
secure.
Everything
past
my
dmz
and
my
public
range
is
insecure
and
in
the
cloud
we
actually
have
to
use
identity
as
the
basis
for
security,
because
we
no
longer
control
the
security
perimeter.
This
is
an
invariably
a
low
trust
environment.
B
From
a
networking
standpoint,
this
is
actually
a
pretty
large
transformation
right
now
we're
moving
from
a
host
as
the
basis
for
connection
so
static
ips.
You
know,
I
know
my
web
server
at
whatever
my
ipv4
range
is,
can
connect
to
my
database
server
at
you
know,
whatever
my
other
ipv4
range
is
and
now
in
a
more
dynamic
world.
Well,
we
don't
actually
control
the
networking
perimeter
anymore,
so
ips
in
general
are
entirely
ephemeral.
If
I
scale
up,
you
know,
100
000
servers
and
then
destroy
them.
Well,
those
ips
are
going
to
be
completely
different.
B
The
next
time
I
scale
up
or
down,
and
so
we
really
have
to
transition
into
service
as
the
basis
for
connection
as
opposed
to
host
and
at
a
runtime
layer
and
from
a
developer's
standpoint.
It's
really
about
heterogeneity.
You
know
how
do
I
standardize
around
tools
to
orchestrate
both
containerized
and
non-containerized
workloads
across
my
different
environments.
B
B
Once
I
deploy
into
aws,
I
might
be
using
cloud
formation
or
arm
template
and
azure
or
cloud
depth
manager
in
gcp
from
a
security
standpoint,
I
probably
have
some
proprietary-
or
I
probably
have
some
hardware
and
then,
as
I
move
into
the
cloud,
I've
got
active
directory
or
ldap
or
identity
and
access
management.
B
From
a
connection
standpoint,
maybe
I
have
some
palo
alto
devices
or
cisco
firewalls
and
then,
when
I
move
into
the
cloud,
I'm
probably
using
app
mesh
or
istio
or
maybe
something
more
proprietary
and
then,
of
course,
from
a
development
standpoint,
there's
just
a
tremendous
amount
of
new
services
like
lambda
and
eks
and
azure,
aks
and
kubernetes,
and
so
the
challenge
then
for
enterprises
and
ops
is
well.
How
do
I
reconcile
this
reality?
B
And
this
is
just
a
quick
overview
of
what
it
looks
like
from
a
hashicorp
standpoint,
so
the
goal
then
the
way
we
see
it
and
the
way
we've
helped
our
700
plus
enterprise
customers
is
that
you
create
a
shared
services
platform
with
a
single
workflow.
So
what
hashicorp
does
is
create
this
common
operating
model
across
each
layer.
So
if
we
take
a
look
at
nomad
from
a
development
standpoint,
well
now
we
can
easily
manage
containers
and
our
modern
legacy
applications
with
one
simple
workflow
from
a
networking
standpoint.
Well,
that's
what
we
have
console
for
now.
B
We
have
a
simplified
networking
perimeter.
We've
created
a
service
mesh
we've
automated
our
networking
and
we're
using
service
discovery
as
the
basis
for
connection
from
a
security
standpoint.
Vault
vault
is
a
tremendous
tool
and
we'll
touch
on
that
in
a
moment
with
vault,
we
centralized
our
secrets
across
all
environments:
we've
increased
our
security,
we've
reduced
our
risk
of
data
breach
and
we've
really
eliminated
that
vector
of
attack
from
a
provisioning
standpoint.
Terraform
is
a
tremendous
use
case
if
millions
of
cores
are
provisioned
every
day
using
terraform.
B
Well,
now,
you've
automated
infrastructure,
provisioning,
you've
taken
human
error
out
of
that
and
you've
added
guardrails
like
security
and
cost
management,
to
really
enable
the
self-service
infrastructure
model.
So
that's
my
overview.
So
now
I'm
going
to
pass
it
over
to
patrick
verizon
who's.
Our
engineer
to
dive
a
little
bit
more
into
the
technical
specifications
involved.
C
Thanks
paul
appreciate
it:
let's
see:
oh
hey,
it
works
nice
there
we
go
perfect
thanks
chris
hey,
so
this
is
going
to
be
kind
of
a
busy
looking
kind
of
screen.
Normally
it
builds,
but
I'm
going
to
walk
everybody
through
this
a
little
bit
and
we're
going
to
go
from
right
to
left.
So
if
you're
we're
going
to
start
at
the
background
and
we're
going
to
move
forward
now,
I'm
sure
everybody
on
the
phone
like
to
say
hey,
you
know
I
want
to
see
a
demo
of
all.
C
If
I
showed
everybody
vault
right
now,
you'd
say
well,
that's
it!
But
it's
really
in
the
elegance
of
the
solution
that
I
think
really
really
makes
a
vault
shine
on
the
surface.
It
looks
very
simple,
but
once
we
drill
down
it
gets
pretty
complicated
so
background.
Where
did
vault
come
from,
and
why
do
we?
Why
do
we
talk
about
identity
over?
Let's
say
privileged
access
management?
C
It
actually
started
in
2010
and
just
so
everybody
knows
2009-2010
companies
like
aws
re-restarted
aws,
so
they
they
were
the
first
people
to
come
up
with
the
vpcs.
But
there's
also
this
paper
done.
That's
called
xero
trust
and
it
was
done
by
forrester
by
a
guy
named
john
kinderbegg.
Now
what
he
was
the
first
guy.
That
said
look
we
can't
continue
to
do
security,
the
same
way
that
we've
done
in
the
past,
which
is
I
have
my
corporation,
I'm
going
to
do
the
castle
and
moat
model
around
the
perimeter
of
my
corporation.
C
C
The
the
daz
data
access
asses,
that's
assets
and
storage,
and
it
was
the
first
time
that
we'd
we'd
kind
of
seen
this
shift
from
privileged
access
management,
where
it's
really
more
about
humans
to
machines,
because
now
you
can
spin
up
a
hundred
machines
and
all
the
infrastructure
go
with
it
just
by
putting
a
few
lines
of
code
in
so
moving
forward.
C
C
So
when
we
talk
about
vault,
we're
talking
about
a
secrets
management
solution,
so
the
first
question
most
people
ask
is
what
are
secrets.
Well,
it's
anything
that
authorizes
you
or
authenticates
to
so
a
couple
of
examples:
user
name,
password
database
credentials,
api
tokens
certificates,
those
are
like
it
ones.
I
like
to
use
more
of
an
analogy
around
a
hotel,
so
this,
if
you're,
going
to
walk
away
with
one
thing
today.
This
is
what
I
want
you
to
walk
away
with
for
vault.
C
Vault
works
just
like
a
hotel,
so
I
fly
in.
I
have
my
passport
which
authenticates
me:
okay
and
I
go
to
the
check
into
the
hotel,
vault
and
I
hand
them
my
passport
and
they
they
say
yep,
that's
you
so
I'm
authenticated
and
then
they
take
my
passport
and
they're
gonna
save
that
passport
at
the
front
desk
and
every
time
that
I
need
it.
They
give
me
a
they
give
me
a
room
key.
So
I've
got
this
plastic
room
key.
C
Well,
vault
works
really
similar
to
that
what
happens
is
you're
going
to
authenticate
against
a
source
so
that
could
be
aws.
It
could
be
a
d,
it
could
be
some
ldap
source.
It
doesn't
matter
you're
going
to
authenticate
it
against
this
and
then
you're
going
to
get
authorization
for
things
that
you
can
do
so
like
in
a
hotel.
C
C
C
Well,
I
would
take
my
key
and
I'd
give
it
out
to
10
of
my
friends,
which
I
normally
do
in
some
scenarios,
and
now
everybody
can
get
into
my
hotel
room
whenever
they
want
that's
what
we
all
do
admit
it
well.
What
vault
does
is
it
allows
you
to
to
get
really
granular
with
the
security
at
a
machine
level,
so
again
think
about
machine
security,
high
volume,
very,
very
low
or
no
trust,
and
that
those
are
some
of
the
constructs
that
it's
written
around.
C
So
some
of
the
kind
of
kind
of
objectives
you'd
want
with
the
hotel
key
as
with
vault
who'sa,
has
access
to
them.
How
are
they
being
used?
Are
they
rotated
regularly?
I
mean
you
wouldn't
want
somebody
else
coming
into
your
hotel
room
and
you
don't
want
to
do
that
for
your
company
either.
So
that's
those
are
the
most
common
objectives,
but
in
practice
we
all
have
secret
sprawl,
so
everybody's
got
that
excel
spreadsheet
on
their
desktop,
we're
handling
secrets.
Okay,
sometimes
it's
out
in
source
code,
it
might
be
in
a
configuration
management
tool.
C
Maybe
you
know
again,
maybe
it's
in
maybe
an
your
outlook,
email
or
something
like
that.
So
when
they
were
looking
at
this
problem
with
secret
spoil,
they
decided
the
very
first
thing
that
they
wanted
to
do.
Is
they
wanted
to
centralize
the
secrets,
and
why
did
they
want
to
do?
C
That
is
because,
by
centralizing
the
secrets
they
could
solve
these
problems
of
secret
sprawls,
they
could
put
like
our
back
controls
around
it
and
they
had
an
audit
trail
where
they
know
they
knew
who
was
coming
and
going
and
who
has
access
to
what.
So
that's
the
first
thing.
First
problem
that
vault
solves
is
secret
sprawl.
C
Now
one
of
the
things
that
I
want
to
highlight
here
is
secrets
can
be
in
other
systems,
but
vault
is
going
to
manage
them.
So
it's
not
like.
We
take
all
the
secrets
and
put
them
into
a
big
pot
in
vault.
We
actually
have
vault
reach
into
all
these
other
systems
and
manage
the
secrets,
possibly
in
active
directory
or
in
ldap
directly,
and
involve
or
rotate
those
okay
which
we're
gonna
touch
on
next.
So
the
second
problem
that
we
want
to
look
at
is
great.
We've
got
all
the
secrets
in
one
spot.
C
How
does
an
application
use
it?
Well,
application
usually
gets
a
key,
let's
say
from
vault,
but
we
all
know
that
applications
suck
at
keeping
secrets.
Why
is
that?
Because,
when
they
explode
they're,
typically
in
the
log
file,
maybe
they're
in
a
diagnostic
program,
maybe
there's
some
monitoring
system,
all
those
secrets
get
dumped
out
and
so
they're
easy
to
find
again
now
you
have
them
exposed.
C
So
vault
came
up
with
this
idea.
Around
dynamic
secrets
and
dynamic
secrets
are
ephemeral.
They
they
have
a
short
time
to
live,
they're
unique
and
they
have
an
awesome,
revocation
story.
So
imagine
and
again,
we've
all
done
this.
I
have
a
set
of
containers
in
my
kubernetes
but
to
access
this
database
somewhere
else.
I
have
this
one
token
I'm
putting
in
there.
So
we've
got
10
containers;
they
all
have
the
same
username
and
password
they're
using
to
access
something
else.
What
happens?
C
C
If
you
go
with
vault
vault
actually
will
assign
unique,
username
and
passwords
or
certificates
or
whatever
secrets
you're
using
to
every
single
container,
and
it
will
rotate
those
secrets.
You
know
on
a
regular
basis,
whether
it's
every
30
minutes
or
weekly
or
whatever
you
set
it
up
to,
and
that
makes
the
the
attack
vector
really
small.
So
now
you
could
take
one
of
those
containers,
offline
or
service.
C
You
could
take
parts
of
that
service
offline
and
contain
that,
so
the
blast
radius
doesn't
take
down
your
entire
service
and
then
finally,
the
last
problem
that
vault
really
solves
is
encryption
and
as
a
developer,
encryption
sucks.
I
hate
doing
it.
I
don't
like
I,
I
don't
like
working
with
the
techniques.
I
get
it
wrong
a
lot
of
times,
so
we
we
have
this
idea
of
encryption
as
a
service
within
vault.
We
have
verified
encryption,
algorithms
that
are
verified
by
like
an
outside
source,
and
we
can
we
control
the
need
and
the
keys.
C
So
we
can
rotate
the
keys.
It's
all
done
through
a
high
level
api
and
then
it
it.
It
actually
puts
the
encryption
keys
in
the
encryption
service
through
a
full
full
life
cycle,
which
is
also
fairly
difficult
to
do.
If
you're
doing
it
often,
so
you
can
imagine
if
I
want
to
encrypt
something
I
can
say
credit
card
and
it
will
go
off
and
the
keys
there.
The
service
will
encrypt
it.
It'll
put
it
in
the
proper
field
and
also
your
application
knows,
is
I'm
going
to
encrypt
and
decrypt
the
the
credit
card.
C
So
those
are
really
the
three
problems
that
vault
solves.
I
just
want
to
go
through
just
this
very
high
level
diagram
and
then
we're
going
to
move
on
to
a
couple
examples.
Quick
examples
here
fault
is
really
pretty
simple
to
work
with,
if
you'll
notice
here
on
the
left,
where
it's
the
aot,
so
that's
your
authorization
again
aws
we
can
plug
into
ldap
ad.
C
But,
let's
suppose
you
are
doing
kubernetes
no
problem,
it
has
it'll
actually
plug
into
kubernetes
or
or
brancher
or
open
shift
or
whatever
your
flavor
is,
and
it
will
manage.
It
will
use
that
off
the
authentication
for
your
containers.
C
Again
we
have
a
full
audit
trail
at
the
bottom
of
that
and
then
at
top
there's
various
sources
that
ways
that
you
can
store.
The
information.
If
you
want
the
secret
engines
is
where
all
the
magic
happens,
and
I
mean
there's
normally
like
a
key
value
store.
But
if
you
go
into,
if
you
get
like
start
getting
kind
of
fancy,
you
could
use
a
database
secrets
engine
which
I'm
going
to
give
you
a
quick
example
on
or
even
fun.
C
C
In
the
slide
yeah
there
we
go
there.
We
go
sorry
about
that.
So
just
a
couple
of
really
quick
use
cases.
People
ask
me:
how
do
you
use
this?
Well,
if
we're
here
using
vault?
C
C
Could
you
give
me
the
next
slide?
Chris,
okay,
perfect!
Thank
you!
Here's
another
example.
I'm
going
to
plug
into
aws
or
whatever
your
flavor
of
cloud
is
so
again
you're
not
going
to
have
credentials
out
there.
So
I
had
a
customer.
Just
recently
talked
to
me
about.
You
know,
service
accounts
and
I
said
well.
If
it
was
me,
I'd
get
rid
of
them
they're
like
what
do
you
mean
we
gotta
have
service
accounts,
blah
blah
blah
and
I'm
like
why?
C
Don't
you
just
generate
them
on
the
fly
and
that's
exactly
what
vault
will
do
it
could
plug
into
any
of
these?
These
different
platforms
and
then
you
can
generate
those
credentials
on
the
fly
and
you'll
get
them
for
a
certain
time
period,
an
hour
a
day
whatever
and
then
they're
gone,
which
makes
them
fairly
ephemeral
next
slide.
Chris,
please
so
this
is
another
good
one.
So,
let's
suppose
we
have
a
database,
we
have
a
database
engine,
so
I
can
make
the
database
even
generate
credentials
on
the
fly.
C
C
So
again,
let's
go
back
to
kubernetes.
Vault
works
really
well
with
kubernetes,
so
we
have
helm
charts
to
set
up
the
whole
cluster
orchestration
to
work
with
vault.
A
lot
of
people
try
to
deploy
vault
within
kubernetes.
It's
not
our
recommended
approach,
but
because
there's
some
security
holes
that
it
kind
of
opens
up.
Our
recommended
approach
is
to
actually
run
a
vault
cluster
outside
of
kubernetes
and
then
there's
a
there's,
a
couple
of
helpers
within
kubernetes
to
help
you
move
secrets
in
and
out
of
of
your
cluster.
C
So
this
is
just
kind
of
a
general
overview.
What
I
wanted
to
paste
into
the
chat
channel,
if
anybody's
interested,
we
do
often
do
like
hands-on
workshops
with
vault.
So
again,
I
know
you
didn't
see
it,
but
without
getting
this
background
it
would.
It
might
not
mean
a
whole
lot
to
you.
So
we
do
workshops,
I'm
posting
one
for
july
and
if
you're
interested
this
is
a
free
workshop,
it
doesn't
cost
you
anything
and
it's
a
it's
like
an
afternoon.
C
I
we're
in
eastern,
so
it's
two
to
six
or
if
you're
in
central
one
to
one
to
five
and
you
can
use,
you
can
use
vault
hands-on
and
you
can
get
some
exposure
to
it
and
see
if
it
works
for
you
and
I'm
going
to
hand
it
over
to
chris
porter.
D
Great,
thank
you.
Everyone
before
we
get
started
with
that,
we've
got
another
poll
so
before
we
get
started
on
stack,
rocks.
A
All
right,
let's
launch
our
second
poll
here
so
is
container
security,
an
active
priority
for
your
company.
If
so,
what
is
your
timeline
and
I'll
leave
this
open
for
a
couple
seconds?
A
All
right
looks
like
everyone
is
done,
so
I'm
sharing
the
results,
so
it
looks
like
you
guys
are
spread
out
pretty
three
to
six
months
or
within
three
months,
so
cool,
let's
get
started
hand
this
off
back
to
you,
chris.
D
Great
thanks
very
much
and
thank
you
to
the
team
from
hashicorp
here
to
give
us
a
good
introduction
to
secrets
management,
we're
going
to
talk
about
that
and
more
in
terms
of
kubernetes
security.
So
stackrocks
is
a
kubernetes
security
company.
We
specialize
in
container-based
environments
that
are
running
kubernetes
and
providing
what
we
would
call
you
know
traditional
security
solutions,
but
adapted
to
kubernetes.
So
you
know
in
in
any
application
environment.
D
You're,
looking
at
things
like
preventing
intruders
from
coming
in
you
know:
runtime
security,
you're,
probably
worried
about
existing
vulnerabilities
and
preventing
vulnerabilities
from
being
deployed
topics
like
network
segmentation
in
any
kind
of
incident
response
and
reporting.
Even
things
like
configuration
management.
Where
are
my
teams
using
configurations
that
are
conducive
to
security
and
where
are
they
not?
So
you
know.
The
security
story
here
doesn't
change
a
whole
lot
from
traditional
application
security.
D
But
what
does
change
is
the
nature
of
the
infrastructure
and
the
nature
of
how
you
accomplish
these
things.
We're
working
here
in
a
devops
world,
we're
working
at
very
quick
speeds,
working
with
very
large
environments.
Where
containers
you
know,
a
traditional
application
might
be
running
on
just
a
few
virtual
machines
or
physical
servers,
but
now
might
be
spread
across
dozens
of
containers
and
hundreds
of
replicas,
and
so
there's
just
a
lot
more
moving
parts.
We
also
think,
fundamentally
that
security
in
this
world
can
be
different.
You
can
take
advantage
of
the
nature
of
the
platform.
D
This
idea
of
declarative
infrastructure,
that's
immutable,
meaning
it's
not
supposed
to
change
that.
You
have
rapid
cycling,
but
we
throw
away
the
notion
of
doing
things
like
patching
and
maintaining
the
infrastructure.
We're
actually
introducing
this.
You
know
continual
cycle
from
end
to
end
where
everything
is
driven
by
source
code,
and
that
makes
security
a
challenge,
but
it
also
gives
us
an
opportunity
and
in
fact
we
really
think
that
you
can
actually
achieve
better
security
in
these
kubernetes
environments.
D
In
these
immutable
you
know
12-factor
applications
than
you
could
with
traditional
security,
and
you
can
do
so
with
with
very
lightweight
controls.
So
that's
what
stack
rocks
is
here
for
right
to
essentially
help
you
use
kubernetes
to
orchestrate
security
effectively
right,
you
think
about
kubernetes.
Today
is
a
way
of
managing
containerized
applications
providing
for
things
like
scaling
up
and
scaling
down,
providing
resilience
to
failure
quick
recovery
times.
D
That's
infrastructure
right,
that's
the
advantage
of
the
platform,
but
we
also
think
that
it
can
be
used
as
a
security
orchestrator
that
you
can
program
the
system
to
achieve
a
security
goal
using
the
features
that
are
built
into
it.
So
we
talk
about
things
like
network
segmentation
and
risk
profiling,
we're
talking
about
how
did
the
application
use
the
kubernetes
infrastructure
the
features
that
are
available
there
to
to
better
improve
the
security
for
your
applications?
How
do
you
measure
that
so
you'll
see
this?
D
I'm
actually
going
to
show
you
a
live
demonstration
because
we're
going
to
do
it
live
and
we're
going
to
show
you
some
examples
of
integrations
under
that
category
of
configuration.
Management
is
where
we
would
put
secrets
and
magic
secrets
in
a
kubernetes
cluster
is
challenging
and-
and
we're
not
here,
stackrock's
trying
to
to
replace
that.
D
In
fact,
what
we're
trying
to
do
is
support
the
use
of
tools
like
vault,
because
it's
not
any
good
to
you
if
you're,
not
using
it
and
developers
who
are
very
creative,
have
ways
of
getting
around
the
official
patterns
and
using
whatever
they
want
to
transmit
secrets,
and
the
role
that
stack
plays
is
to
surface
the
bad
configurations.
D
That
teams
are
using
and
push
them
towards
your
vault
environment,
where
secrets
can
be
managed
properly
right,
so
we're
trying
to
surface
areas
where
the
teams
have
chosen
an
approach
doesn't
mesh
with
the
security
goals
of
the
organization
and
you'll,
see
how
our
at
the
bottom
here,
our
deep
integration
with
devops
systems
allows
us
to
communicate
directly.
I'm
always
fond
of
saying
this:
that
developers
really
don't
like
security
products.
They
restrict
what
they
can
do.
They
are
they're
kind
of
narrow-minded.
They
don't
provide
good
information,
it's
often
a
mystery.
D
What
they're
doing
well
in
this
case
we're
trying
our
best
to
be
a
better
devops
security
system.
Maybe
they're
not
going
to
love
this,
but
at
least
they'll
hate
it
a
little
bit
less
we're
going
to
provide
them
with
actionable
information
that
allows
them
to
solve
their
security
issues
on
their
own
when
it
comes
to
logging
and
enforcement
and
other
attributes
that
we
might
you
know,
controls
we
might
invoke
we're
going
to
do
that
natively
through
the
platform.
So
you
can
see
at
a
glance
what
happened
and
why
and
resolve
those
issues.
D
So
we
don't
want
to
be
a
black
hole.
We
don't
want
to
be
something
that
just
enforces
without
any
kind
of
consideration
of
the
of
the
devops
teams
and
that's
a
big
important
change
for
how
we
do
it.
So
you
know
we
we've
been
compared
to
a
container
security
company
we
like
to
bust
out
of
that
category
here,
because
we
think
that
containers
are
a
little
bit.
D
You
know
myopic
when
you're
looking
at
a
container
environment
running
on
an
engine
like
docker
or
cryo,
you
tend
to
think
about
things
in
terms
of
of
those
containers.
But
when
you
look
at
the
larger
environment,
where
the
the
containers
are
part
of
a
pod,
the
pod
is
part
of
a
larger
deployment
or
replica
set
or
daemon
set.
You'll
see
that
the
bigger
picture
gives
you
better
insight
that
we
can
see
more.
D
What's
going
on,
you
have
this
idea
of
of
applications
rather
than
just
individual
containers
and
because
kubernetes
offers
the
capability
of
starting
and
stopping
pods
and
rejecting
admission
to
the
cluster.
We
can
actually
use
that
to
our
advantage
here
to
do
native
enforcement.
The
kubernetes
system
is
very
full
featured.
We
think
you
can
take
full
advantage
of
that
for
security
and
that
there's
a
lot
of
good
ways
that
you
can
improve.
You
know
even
just
in
a
few
moments
the
way
your
deployments
are
created.
You
know
when
you,
when
you
build
an
application
on
containers.
D
So
the
stack
rocks
platform
is
a
software
platform
kind
of
unusual
in
this
day
and
age,
where
everything
is
offered
as
a
service,
but
like
so
many
of
the
security
tools,
it's
looking
at
your
applications
in
your
environment,
potentially
accessing
sensitive
data
and
for
most
of
our
customers.
You
know
just
like
with
secrets:
management
having
it
running
in
your
environment
is
a
preferable
model
so
that
you
know
as
a
vendor.
We're
not
you
know
having
folks
access
your
running
environment
there.
D
This
also
runs
in
completely
isolated
environments
as
a
software
solution,
there's
no
need
to
provide
for
internet
access.
So
if
you're
running
in
air
gapped
or
you
know,
network
isolated
environments,
you
can
do
that.
Our
security
platform
is
a
kubernetes
application
and
we're
gonna.
We're
gonna
see
what
that
looks
like
so.
The
central
system
at
the
top
is
designed
to
be
one
place,
to
look
at
multiple
clusters
to
set
your
security
policies
to
understand.
D
You
know,
for
example,
where
your
misconfigurations
are
happening,
what
the
risk
is
and
where
you're
failing
your
compliance
checks
and
then
that
central
brain
talks
to
each
of
your
individual
clusters,
I
might
have
separate
development
and
staging
environments,
multiple
production
environments
and
they're
all
going
to
be
covered
by
the
stack
rocks.
You
know
called
client
software
that
runs
on
each
node
and
runs
in
each
cluster
very
lightweight.
D
Another
thing
that
we
know
development
teams
don't
like
is
very
heavyweight
security
applications
that
eat
up
all
their
cpu.
We
want
to
make
sure
that
you're
not
sizing
up
your
cloud
instances,
for
example
just
to
handle
security,
so
everything
is
very
lightweight
here,
because
you
know,
instead
of
duplicating
the
capabilities
that
are
already
built
into
kubernetes,
we're
actually
augmenting
we're
programming
kubernetes
to
do
our
security
work
for
us.
D
A
Hey
chris,
before
you
start
your
demo,
I'm
just
going
to
pull
the
audience
real,
quick,
great
see
what
use
cases
they're
interested
in
and
maybe
we
can
cater
the
demo
to
what
everyone's
interested
in.
So
let
me
launch
the
third
polling
question:
real
quick
guys.
What
are
your
top
three
use
cases
for
security
for
kubernetes
environment,
so
we
have
visibility,
vulnerability,
management,
compliance
network
segmentation,
configuration
management,
threat,
detection
and
incident
response.
A
A
All
right,
let
me
end
the
polling,
and
here
are
the
results.
So
chris
a
lot
of
compliance
here
and
then
vulnerability
management
is
a
popular
one
and
it
looks
like
configuration
and
threat.
Detection
are
pretty
close
there
as
well.
Okay,.
D
Good,
so
you
know
we'll
do
with
the
demo
here,
and
this
is
a
live
environment.
So
wish
me
luck.
We're
gonna
run
through
all
of
those
examples
here.
So
I'll
do
a
little
bit
of
an
introduction
and
then,
once
you
jump
into
vulnerability
management,
it
is
an
important
part
of
what
we're
talking
about
here.
We
just,
we
just
think
it's
stack
rocks.
We
just
think
it
doesn't
go
far
enough
and
you
know
vulnerability.
D
Data
is,
is
you
know
available
in
a
variety
of
formats
and
just
how
do
you
operationalize
it
as
a
challenge?
How
do
you
deal
with
such
a
huge
amount
of
information
and
and
pick
out
from
the
noise?
The
signal
that
you
need,
so
the
stack
box
interface
is
designed
like
most,
you
know,
security
dashboards
that
you've
probably
seen
to
provide
a
single
pane
of
glass
right.
D
What
I
like
to
say
is
that
it's
a
good
place
to
go
and
there's
a
lot
of
guidance
for
what
you
should
be
looking
at,
if
you're
not
sure
what
you
should
be
looking
for
like
what
are
the
security
topics
that
you
know
that
we
think
are
important.
What
you're?
Looking
at
here
is
a
software
installation,
that's
pre-configured.
It
comes
with
all
the
policies
that
you
see,
the
reports
are
built
automatically
and
the
compliance
here
that
we'll
jump
into
is
is
all
configured
automatically.
D
So
at
a
glance
you
can
see,
you
know
the
categories
of
violations
that
you
have.
You
can
drill
down
on
incidents
we
can
even
go
into
the
you
know,
jump
right
into
things
like
vulnerability,
management
and
risky
deployments.
You
can
see
at
the
top
here.
I've
got
just
two
clusters.
D
Everything
here
is
also
api
driven.
So
if
you
prefer
not
to
see
another
dashboard
in
your
environment,
you'd
prefer
command
line
and
api
access
to
these
things.
That's
certainly
part
of
it.
In
fact,
we're
going
to
jump
in
at
some
point
and
see
what
some
of
the
command
line
stuff
looks
like
when
you're
doing
kubernetes
security,
config
management
and
vulnerability
scanning
in
something
like
github
actions
or
azure
devops,
for
example,
so
to
start
with
vulnerability
management.
You
know
here
we're
looking
at.
I
think
what
you'd
expect
to
see
in
vulnerability
management.
D
To
be
honest,
this
information
is
pretty
broadly
available.
There's
a
lot
of
good
tools.
In
fact,
stack
rocks
is
somewhat
flexible
here
in
that
we
can
use
other
scanning
technology,
although
we
include
vulnerability
scanning
as
part
of
this,
we
really
think
that
what's
important
is
what
are
you
doing
with
this
information?
D
How
do
you
help
the
security
teams
understand
where
the
problems
are
control,
where
those
images
come
from
and
and
help
the
teams
understand
what
they
need
to
do
to
be
in
compliance
with
the
security
rules,
so
we
focus
on
you
know
to
be
honest,
some
some
reducing
some
of
the
noise
there's,
a
huge
number
of
vulnerabilities
with
new
ones
being
discovered
all
the
time
and
it's
almost
impractical
to
say:
hey
just
fix
all
of
these
things.
So
there's
a
couple
of
practical
things
we
can
point
to.
D
Well,
you
know
fix
it
right,
in
other
words,
in
your
code,
you
should
have
a
process
in
place
to
run
those
image
builds
again
and
again,
you
know,
with
every
single
release,
there
should
be
a
new
build
with
a
new
image
tag,
and
that
should
have
these
commands
here
in
the
docker
file
run,
in
fact,
out
of
all
of
the
information
that
you're
seeing
on
the
screen,
this
is
actually
the
most
important
piece
of
it.
D
The
problem
here
and
the
solution
that
we
recommend
is
rebuild
these
things,
often
that
by
picking
up
these
fixable
cves
you're
going
to
be
way
ahead
of
the
game.
Right,
most
organizations
don't
have
a
handle
on.
You
know
their
inventory
of
images.
They
don't
have
a
handle
on
on
the
components
in
the
infrastructure
and
they're
not
having
this
level
of
visibility,
and
so
you
know,
by
having
a
process
where
you
force
teams
to
go
and
investigate
and
fix
those
issues.
Then
then
you'll
be
ahead
of
that
security
story.
D
Now
back
over
here
in
my
github
actions,
let's
say
I'm
using
github
as
part
of
it.
How
do
we
empower
the
developers
to
solve
this
problem
and,
after
all,
they're
the
ones
building
these
images
they're
the
ones
deploying
them
in
kubernetes
they're
the
ones
doing
bad
things
like
sticking,
passwords
and
environment
variables,
and
we
want
to
make
it
very
clear
to
them.
Stackhawks
is
all
about
empowering
the
developers
to
fix
their
own
issues.
They
appreciate
the
level
of
transparency.
This
is
what
you
have
to
do
to
resolve
this.
D
This
is
what
you
need
to
do
to
deliver
a
secure
solution
and
they
take
those
suggestions
when
it's
given
to
them
in
chunks
of
things
that
they
can
act
on.
You
know
you
could
certainly
you
know,
go
into
our
product
export.
A
huge
list
of
vulnerabilities
in
a
spreadsheet
send
it
out
as
an
email,
but
teams
just
aren't
going
to
pay
attention
to
that,
and
that's
the
unfortunate
problem
here
is
that
the
teams
would
rather
spend
their
time
on
thinking
about.
D
You
know,
bug
fixes
and
performance
improvements
and
new
features
we
want
them
to
think
about.
This
is
something
that
they
can.
You
know
they
can
work
on
incrementally.
Another
challenge
behind
vulnerability
management,
of
course,
is
staying
up
on
the
latest
right.
So
it's
not
just
vulnerabilities
that
we're
concerned
about
so
to
broaden
the
picture
a
little
bit.
We
look
at
risk
risk.
Is
the
stack
rocks
way
of
saying
hey
it's
more
than
just
what
goes
into
your
image,
build
it's?
How
you're
composing
your
deployments?
D
It's
how
the
runtime
activity
of
the
container
since
they
started
is
impacting
your
security.
A
great
example
of
risk
is,
you
know
sure
I've
got
vulnerability.
Data
here
and
I've
got
this
very
serious
one
in
my
environment,
but
this
one's
much
more
of
a
priority
than
others,
because
I've
got
things
like
I'm
listening
on
certain
ports
here,
in
other
words,
I've
got
port
exposure.
That
means
you
know:
I've
got
a
pipe
to
the
internet
right
or
outside
of
the
cluster,
at
least,
and
that
means
that
it's
much
more
likely
to
be
exploited.
D
If
I
look
at
things
like
privilege
levels,
I've
got
privileged
containers
that
have
access
to
the
host
down
here
at
the
bottom.
I've
got
kubernetes
our
back
service
accounts
here
that
have
a
high
level
of
privilege,
in
fact,
cluster
admin
level
of
privilege,
and
these
things
add
to
the
risk.
So
this
one
is
number
one
in
my
list
here,
even
though
it
has,
you
know
a
serious
vulnerability
in
it.
D
It's
the
other
conditions
that
actually
make
it
much
more
likely
to
be
exploited
or
if
it
is
exploited,
to
allow
an
attack
or
a
bigger
access
to
the
environment
right
having
privileged
accounts
having
no
resource
limits
specified.
These
are
all
attributes
that
a
developer
decided
or
or
ignored
when
they
created
this
deployment
and
therefore,
therefore,
there's
all
of
this
room
for
room
for
improvement.
D
Now,
when
it
comes
to
these
policies
that
you're
seeing
here
we're
going
to
look
more
in
depth
to
see
what
they're
actually
getting
at,
but
the
idea
here
is
that
we've
found
a
configuration
that
someone
can
make
a
fix
to,
and
we
can
actually
use
that
policy
information
to
drive
enforcement
to
drive
reporting.
Some
of
this
actually
feeds
up
into
compliance.
Compliance
calls
for
general
security
goals
like
minimal
privileges,
minimal,
surface
area.
You
know
no
unused
services,
like
those
kinds
of
concepts,
are
going
to
be
linked
up
in
the
compliance
reports.
D
Before
I
leave
risk,
though
I
want
to
talk
about
run
time,
no
security
solution,
even
one
that
has
you
know
all
this
guidance
on
hardening.
You
know
if
you
can
make
your
environment
as
hardened
as
possible,
there's
still
going
to
be
somebody
knocking
at
the
door,
and
we
want
to
make
sure
that
everything
is
monitored
from
the
moment.
It
starts
up
again.
We
can
think
about
this
in
terms
of
traditional
security,
like
host-based
intrusion,
detection,
understanding,
what's
legitimate
activity
versus
not
legitimate
activity,
but
things
change
right.
It's
a
container.
D
It's
not
a
virtual
machine
anymore.
We
can
actually
take
advantage
of
the
fact
that
containers
are
not
vms
to
look
for
signals
that
might
indicate
that
there's
an
intrusion
going
on
you
know
somebody
adding
a
user
account
or
changing
a
password
might
not
be
unusual
in
a
virtual
machine.
Somebody
installing
software,
like
we're
seeing
here
somebody
ran
apt-get,
but
in
a
container,
especially
in
a
production
container.
D
This
is
absolutely
unusual.
You
shouldn't
be
changing
the
configuration
you
shouldn't
be
patching
or
maintaining
that
system.
In
fact,
what
stack
rocks
would
prefer
is
that
you
don't
even
have
the
binaries
available
for
somebody
to
run
so
this
is
highlighted
as
unusual
here
we
can
look
at
the
behavior
of
this
container
here
in
this
network
graph.
We
can
actually
see
what
typically
happens
with
a
container.
Is
this
there's
a
startup
period
where
I
have
let's
say
my
java
application
begins
start
up
here
at
the
beginning,
I
start
a
web
server.
D
I
run
a
few
utilities
here
and
then
some
time
later,
somebody's
gotten
in
here
and
there's
some
additional
activity
so
because
containers
should
be
boring.
We
can
highlight
the
fact
that
hey
someone
ran
something
different
right.
We
haven't
seen
this
before
it's
an
hour
and
a
half
or
more
later,
this
one
was
33
minutes
later
we're
seeing
changes
of
the
behavior,
and
you
know
that
change
is
not
good.
You
know,
netcat
here,
for
example,
is
highlighted.
It's
it's
a
useful
utility
for
sure.
D
Like
curl,
like
you
know,
nmap
these
are
useful
network
utilities,
but
because
they
allow
an
attacker
to
do
things
in
the
environment,
we
want
to
minimize
what's
available
to
them
right.
We
want
to
provide
as
few
of
these
troubleshooting
and
system
tools
as
we
can
and
then
again
we'll
see
this
in
policies,
for
you
know
how
do
we?
How
do
we
stop
someone
from
getting
very
far
in
the
environment
once
they've
compromised
an
application?
D
So
as
I
go
down
through
the
risk,
you'll
see
lower
priority
here
I
mentioned
this
vulnerability.
You
know
here's
a
great
example
of
how
that
vulnerability,
data
and
the
other
configuration
information
comes
together.
I've
actually
got
four
deployments
that
have
this
vulnerability
present,
but
they're
ranked
differently
right,
and
that's
because
there
are
fewer
of
these
other
security
violations
down
here.
D
So,
comparing
and
contrasting
maybe
showing
two
different
teams
that
hey
these
guys
are
light
years
ahead
of
you
because
you're
taking
into
account
these
other
configurations
and-
and
you
know
the
other
team-
is
not
another
big
aspect
of
security
and
configuration
mediating.
The
problems
with
vulnerabilities
has
to
do
with
network
segmentation,
and
this
is
also
a
feature
that
I
think,
if
what
I've
been
saying
is
a
little
confusing
about
kubernetes
native
about
stack,
rocks,
helping
you
use
the
platform
tools
hasn't
been
obvious.
I
think
it'll
be
obvious
here.
D
This
is
a
network
diagram
of
my
kubernetes
cluster.
You
can
see
I've
got
more
than
one,
but
I'm
in
my
production
environment
and
I'm
looking
here
at
network
flows
not
between
ip
addresses
and
host
names,
but
between
kubernetes
namespaces
and
deployments.
So
I've
got
a
postgres
database
here
and
a
deployment.
This
could
be
a
few
different
containers.
D
So
the
goal
here
is
to
show
you,
of
course,
what's
what's
been
happening
over
the
last
hour
or,
let's
say
over
the
last
week
and
observe
the
traffic
of
patterns
going
on
here.
But
when
I
switch
my
view
to
you
know
call
it
the
firewall
view
right.
The
allowed
traffic
you'll
see
what
we're
getting
at
about
using
the
platform
right
right
now,
we're
showing
that
my
postgres
database
has
only
been
talking
really
to
the
api
server
here
over
the
last
week,
but
the
network
flows
allow
all
the
other
namespaces
to
communicate
with
it.
D
In
other
words,
I
don't
have
any
network
policies
that
would
restrict
it.
This
is
the
problem
of
network
segmentation
right
micro
segmentation
firewalling
been
around,
for
you
know
many
decades,
it's
gone
from.
You
know:
hard-coded
ip
address
rules
to
host
name
rules
to
application,
aware
rules,
but
whatever
we
call
it
there's
a
way
to
provide
the
segmentation
and
it's
good
security
practice
and
many
compliance
standards
actually
require
that
you
isolate
data,
let's
say
in
a
database
or
in
a
payments
processing
system.
So
no
question
about
the
value
of
this.
D
I
don't
think
what's
different
about
stackrocks
is
how
we
accomplish
it
and
the
you
know.
What
we
feel
strongly
about
is
that
the
kubernetes
platform
provides
this
capability
natively
on
every
platform
that
it's
available,
and
you
should
be
using
that.
That's
really
what
we're
saying
simply
so
we're
here
to
help
you
build
those
rules
in
kubernetes,
so,
rather
than
provide
you
with
a
firewall,
we're
helping
you
use
the
firewall,
that's
already
there
and
because
it's
kubernetes
it's
code
driven.
So
it's
infrastructure
is
code.
It's
declarative!
D
D
You
can
provide,
for
you
know,
for
visibility
to
a
wide
variety
of
teams,
and
what
we're
trying
to
do
here
is
essentially
say:
hey
we're
going
to
suggest
these
rules,
because
your
postgres
database
has
only
been
talking
to
the
api
server
where
your
card
processor's
only
been
talking
to
your
gateway
and
that
kind
of
of
communication
is
allowed
here,
but
everything
else
is
going
to
be
denied
another
advantage
of
using
this
versus
a
proprietary
firewall
from
a
security
vendor
is
operationally
that
this
is
built
into
kubernetes.
D
It's
enforced
by
the
underlying
container
networking
interfaces,
and
this
network
policy
is
is
going
to
be
broadly
supported
on
any
of
the
platforms
that
you
have
and
frankly,
the
stackrock
software
is
not
involved
in
that
enforcement.
We
audit
that
we
help
you
create
these
rules.
We
help
you
test
these
rules,
but
if
one
of
our
components
of
software
down
here
were
to
fail
for
whatever
reason
your
networking
is
not
interrupted,
so
our
security
product
doesn't
create.
You
know
an
outage
risk
in
your
environment,
but
this
notion
of
fix
it
in
the
code.
D
This
idea
that
we
can
do
everything
from
this
declarative
interface
that
we
can
provide
hardening
natively
through
the
platform
is
something
you'll
see
throughout
this.
You
know
vulnerability
data.
These
are
my
violations.
I
can
see
where
I've
got
all
of
this
vulnerability
data
flowing
through
here.
You
know
our
answer
to
that
is:
hey,
go
and
fix
it,
even
runtime.
If
we
see
something
like
this,
we're
seeing
a
process
run
with
an
elevated
level
of
privilege-
and
you
know
this
is
one
where
we
see
this
all
the
time.
D
Is
this
an
issue
that
I
would
say,
take
all
your
apps
offline
and
fix
it
immediately?
You
know
probably
not,
but
we
do
want
to
push
teams
towards
the
fact
that
right
here
in
docker
or
in
kubernetes
there's
a
setting,
you
can
use
for
a
non-privileged
user
account
inside
of
your
containers,
and
you
should
take
advantage
of
that
and
use
it
now.
This
is
what
a
policy
looks
like
in
stack
rocks
and
you
know
I'll
show
you
what
that
whole
library
looks
like
they're
focused
on
empowering
the
developers
to
fix
their
own
security
issues.
D
So
the
role
of
a
security
officer
with
our
software
here
is
to
set
that
guide
rail
right.
The
the
these
are
the
constraints
under
which
you
must
operate.
These
are
the
fixes
that
you
must
provide.
These
are
the
things
that
are
acceptable.
These
are
the
things
that
are
not
acceptable
and
you
know
provide
everybody
with
the
feedback,
the
very
specific
feedback
that
they
can
use
to
to
remediate
that
issue.
D
You
know
to
play
on
what
we
were
talking
about
earlier
about
secrets
in
vault.
You
know,
stackrocks
is
not
a
secrets
provider,
we
don't
store
secrets,
we
don't
transmit
them,
but
we
know
in
kubernetes.
There
are
a
variety
of
ways
to
get
secret
information
into
your
pause,
and
this
is
one
of
the
ways
that
that
teams
do
it.
They
use
environment
variables,
and
this
is
a
bad
practice.
It's
not
encrypted
it's
potentially
stored
in
source
code.
D
Do
the
right
thing
store
those
secrets:
take
advantage
of
the
capabilities
of
that
platform,
so
we're
just
trying
to
push
teams
again
towards
using
the
tools
that
are
right
for
for
your
environment.
All
these
policies
come
built
in
they're,
pretty
easy
to
read
and
easy
to
write.
We
hope
they
cover
everything
from
configuration
deployment
to
vulnerability
management.
There's
some.
You
know
what
I
would
call
advanced
security
topics
in
here
like
using
read-only
root
file
systems.
D
You
know
making
sure
that
teams
aren't
abusing
kubernetes
itself
and
then,
of
course,
this
information
stored
in
our
user
interface
isn't
doing
anybody
any
good.
So
we
talk
about
the
integrations
with
other
platforms.
You've
seen
some
examples
here:
ci
cd
tools,
I've
got
azure
devops,
I've
got
github,
but
we
also
have
a
jenkins
plugin
that
you
can
see
on
jenkins.io.
D
We
also
have
examples
of
configuration
with
git
lab
and
code
fresh,
and
you
name
it.
We've
done
it
aside
from
that
too
integrations
with
registries
cloud
provider,
platforms,
chat
up
systems
like
slack
or
microsoft
teams.
You
know
the
information
that
we
have
here
and
the
security
recommendations
that
we
make
aren't
going
to
do
anybody
any
good
unless
it
gets
in
front
of
the
right
team
and
it's
out
there
and
they
can
see
the
results
of
it
and
get
that
remediation
information
in
there.
D
So
I
haven't
seen
any
questions
pop
up
in
the
qa
if
there
are
any
we're
getting
short
on
time
here,
I'm
happy
to
answer
any
questions
you
might
have,
but
if
not
I'll
finish
up
with
compliance,
I
should
say
this
for
the
end,
because
it
does
kind
of
sum
up.
A
lot
of
what
we've
been
talking
about.
Compliance
is
generally
about
achieving
certain
security
standards
in
your
organization
and
being
able
to
demonstrate
that
you
have
that
process.
D
Now,
for
each
of
these,
we
break
down
the
controls
individually
and
explain
to
you
how
these
apply
here.
So
we're
connecting
the
dots
between
a
high-level
concept
like
you
should
have
a
firewall
at
every
internet
connection
translated
in
terms
of
what
you
need
to
do
within
how
that's
met
within
kubernetes.
Again:
here's
our
kubernetes
network
policies,
another
good
reason
to
choose
a
standard
like
this
and
then
very
specifically
telling
you
you
know,
and
if
I
look
in
each
individual
cluster
or
better.
D
D
This
is
not
just
a
document,
you
know
as
I
go
in
and
I
make
changes
or
even
as
I
apply
networking
suggestions
here,
for
example,
what
you'll
see
is
that
zachrox
is
measuring
those
capabilities
and,
as
I
make
the
changes
you'll
see
where
those
those
compliance
standards
actually
start
to
pick
up
the
changes
and
give
me,
you
know,
updated
compliance
measures
now
the
data
that
we
have
here,
as
I
drill
down
you'll,
see
again
very
exhaustive
sets
of
information
on
each
individual
control
on
the
guidance
to
providing
it.
D
But
here
in
our
web
interface,
it's
not
going
to
do
you
any
good.
Unless
you
can
demonstrate
this
right,
compliance
is
mostly
in
the
in
the
proof
and
so
you'll
see
here
that
I
can
always
export
not
just
the
pdf
pages,
but
also
this
evidence
file.
This
is
critically
important
right.
Your
auditors
are
going
to
want
to
see
control
by
control
this
outline
of
how
these
these
things
are
being
met
and
what
objects
they
apply
to
and
so
being
able
to
demonstrate.
D
It
is
almost
as
important
as
actually
having
the
controls
in
place,
and
so
we
thought
of
that
here,
provided
you
with
a
convenient
way
of
doing
that.
So
that's
really.
It
there's
always
more
to
talk
about
with
security.
We've
talked
about.
You
know:
application
security,
cube
security,
there's
any
questions,
we're
happy
to
answer
them.
If
you
have
think
of
any
later
feel
free
to
reach
out
to
us,
and
I
will.
A
Cool
thanks
chris.
We
have
a
couple
more
minutes,
so
I'm
just
gonna
browse
through
a
couple
questions
here.
Let's
see,
there's
one
for
hashi:
let's
see
how
does
vault
handle
gt
gdpr.
C
That's
a
really
super
good
question,
so
believe
it
or
not
within
the
vault
like
enterprise,
we
can
filter
secrets
and
we
can
keep
them
localized
to
the,
in
this
case
the
physical
domain.
So
anybody
that's
familiar
with
gdpr
the
the
secrets
or
information
from
like
an
eu
member
cannot
leave
physically
that
location.
C
B
Yeah,
the
other
thing
I
wanted
to
add
to
that
as
well,
is
that
outside
of
vault,
another
cool
use
case
for
terraform
is
that
when
you
start
to
templatize
your
infrastructure
and
write
out
infrastructure
as
code,
we
have
a
a
module
called
sentinel
which
allows
you
to
create
those
guard
reels
that
I
mentioned
earlier
so
another
great
way
to
really
easily
enforce
these
kind
of,
like
gdpr
and
type
of
like
stock
requirements
into
your
infrastructure.
A
Cool
and
then
since
I
have
you
guys
on,
let's
there's
another
question
for
you
guys:
let's
see,
can
you
do
two-factor
authentication
with
bolt?
Yes,.
C
C
So
like
like
table,
stakes
is
two-factor
authentication,
but
if
you
use
something
like
sentinel,
you
could
say
hey.
If
I'm
inside
of
my
network
within
the
building,
you
could,
you
could
say,
don't
don't
fire
up
two-factor
authentication,
but
if
I'm
coming
from
ipi
addresses
that
are
outside
of
my
building
or
some
other
ones
you
you
can
use
sentinel
to
actually
say.
Oh,
this
guy
is
really
not
on
premise:
we're
gonna,
we're
gonna,
do
two-factor,
authentication
and
we'll
add
some
other
stuff
to
that.
A
Cool
and
then,
let's
see,
we
got
a
question
for
you,
chris,
on
vulnerability
management.
Do
we
have
to
use
your
scanner
or
can
we
use
others.
D
Oh,
you
could
definitely
use
others,
so
we're
very
agnostic
when
it
comes
to
the
source
of
the
vulnerability
information.
To
be
pretty
frank
about
it,
the
information
is,
is
somewhat
commodity.
At
this
point,
it's
all
generally
available
from
a
variety
of
sources
and
it's
updated
regularly.
So
if
you
have
a
preferred
solution,
remember
that
stackrock's
really
is
focused
on
images
for
containers
and
kubernetes.
D
So,
if
you're,
an
organization
that
has,
for
example,
a
tool
like
you
know
like
a
a
tenable
scanner
for
vulnerability
management
on
vms,
for
example-
and
it
also
does
image
scanning,
we
can
use
the
information
from
those
products
in
the
same
way
that
you
saw
so
again.
The
focus
here
at
stackrocks
is
it's
it's
all
about
how
you
use
it
and
what
you're
going
to
do
with
that
data.
A
Cool
I
put
the
last
polling
question
up.
We
only
have
a
minute
left,
there's
a
couple
questions
we
didn't
get
to,
but
we
will
reach
out
and
answer
those
those
for
you.
The
last
pulling
question
is,
if
you
want
a
complimentary
30-day
trial
from
stackrocks
I'll
leave
that
open,
if
you
guys
hit
yes,
we'll
reach
out
to
you
with
that
in
the
details,
but
I
just
wanted
to
say
thank
you
to
the
hashu
team,
paul
and
patrick
thanks
for
your
time
today.
That
was
awesome
and,
of
course,
chris.
A
Thank
you
as
always.
So
thanks
again
guys
and
have
a
nice
rest
of
your
day,.