►
Description
DevOps automation is a critical part of improving operational efficiency for development teams, but recent software supply-chain breaches demonstrate just how important it is to secure, authenticate, and audit access to sensitive data, containers and microservices. Unprotected secrets (credentials, keys, tokens, etc.) embedded within code, automation scripts, etc, expose risks because they can grant attackers unfettered access to machines and services. Dev teams need to think-through integrating new layers of protection into their CI/CD pipelines so that they can achieve and maintain compliance and security. Join RedHat and CyberArk in an educational session plus demo session as they outline the differences of machine vs. Human identity, and new forms of integrating secrets management into the DevOps process.
A
A
I
may
have
a
little
bit
of
chatter
on
the
on
the
line
as
I,
as
I
mentioned,
I'm
up
here
in
my
summer,
cabin
on
a
remotely
internet
is
being
fed
over
over
a
pair
of
copper
phone
lines.
So
I
apologize
for
that,
but
hopefully
you
folks
have
a
little
bit
better
internet
than
I
do
being
in
a
more
modern.
You
know
modern
place.
B
B
B
A
I
you
know,
that's
something
I
haven't
done,
I'm
actually
sitting
here
in
an
oak
hickory
wooden
chair.
I
I
never
got
the
memo
when
covid
came
that
everyone
was
going
out
ordering
really
nice
chairs-
and
you
know
nice
work
from
home
desks.
I
I
missed
that
memo
so
now
that
the
virus
is
starting
to
slow
down.
I
think
I'm
finally
going
to
join
the
club
and
and
get
a
good
office
chair
and
a
proper
desk,
so
we'll.
B
B
I
am
what's
my
actual
title
is
devops.
Subject
matter
expert
within
cyber
arc
we're
my
role.
There's
others
like
me
are
focused
on
helping
customers
understand
our
solutions
for
secrets
management.
So
most
of
us
have
some
kind
of
development
background
a
lot
of
times.
We're
working
with
developers
need
need
to
know
how
to
code
need
to
know,
walk
the
walk,
talk
to
talk,
but
I've
I've
had
a
ton
of
different
roles.
I've
been
I've,
been
a
biz
dev
guy.
I
tried
my
hand
at
sales,
but
it
turns
out.
B
B
Recording
is
on
yeah
they're
they're
part
of
a
french
big
french
company,
though
so
okay,
I
have
some
friends
over
there,
but
yeah.
That's
that's
kind
of
how
I
went
up
at
cyber
arc
and
and
and
it's
been
awesome
and
cyborg's,
making
hefty
investments
in
this
space
cyber's
actually
been
securing
application
credentials
for
more
than
a
decade.
B
But
but
the
use
cases
around
you
know,
as
we're
gonna
be
talking
about
with
openshift.
Today,
requires
a
different
architecture,
different
approach,
and
so
there,
the
the
initial
architecture
that
they
built
for
long-running
applications
didn't
really
scale
or
support
the
dynamic
nature
of
container
orchestration
cloud
platforms.
B
A
C
C
C
I
work
at
red
hat,
been
working
at
red
hat
now,
for
over
a
year,
primarily
focused
on
security
isvs,
our
partner,
our
great
partners,
like
cyberark,
have
done
a
lot
of
stuff
with
cyborg
and
did
a
couple
webinars
with
jody
and
some
workshops
as
well
got
a
very
nice
demo
workshop
capability
that
we
put
together
over
the
last
year.
If
you
go
to
demo.openshift.com
you
can
you
can
see
the
cyberark
entry
in
there
as
well,
but
some
of
the
viewers
may
know.
C
C
So
we
decided
to
put
a
sort
of
content
series
together
every
month,
where
we're
doing
we're
actually
doing
two
openshift
tv
shows.
We
have
another
one
tomorrow
by
the
way,
and
then
we
also
publish
try
to
publish
three
podcasts
every
month
and
then
we're
trying
to
do
blogs
and
other
webinars,
and
things
like
that,
and
you
can
see
the
categories
on
the
right
there
and
this
month
is
may
identity
and
access
month,
and
so
we're
excited
that
cyberark
is
a
part
of
this.
A
C
C
A
Okay,
very
very
good
dave,
and
I,
while
you're
going
over
your
your
your
your
slide
number
58
there,
I
decided
to
try
and
spin
my
chair
around
and
get
a
different
get
a
different
view,
because
the
the
glare
from
the
slider
was
just
absolutely
driving
me
crazy.
So
I
hope
this
is
a
little
better,
much
better,
oh
good
good!
A
Now
I
just
have
to
next
time
I'll
just
have
to
check
for
like
for
guns
and
automobile
parts
and
things
anyways
great
okay,
so
jody
you've
been
at
cyberk
now
for
quite
some
time.
You
folks
have
security.
Software
dave
is
a
global
sa.
Managing
software
vendors
who
do
security
for
the
lay
person
like
me,
is
in
security
security.
I
mean
how
many
different
security
vendors
do
we
need
out
there
right,
I
mean.
Is
it?
Is
it
endpoint
security?
A
Is
it
like
network
security?
What
what
exactly
does
cyber
arc?
Do
I
mean
I,
I
know
you
guys
are
publicly
traded
and
I
think
you're
trading
at
110
and
60
cents
a
share
this
morning.
You
guys
look
like
you've
been
trending
up
ever
since
2016,
which
is
really
great
so
whatever
it
is.
You're
selling,
it
must
be,
it
must
be
working
for
the
market.
So
can
you
can
you
tell
us
about?
You
know
how
you're
different
from
many
somebody
else
who
says
they're
a
security
software
vendor.
B
Yeah
well
fundamentally,
we're
about
privileged
access.
So
that's
that's!
The
core
business
is
securing
the
access
of
users
that
have
elevated
privileges,
so
typical
im
solutions
are
for
the
the
rest
of
the
organization
that
needs
access
to
email
and
applications,
and
things
like
that.
But
your
your
system,
administrators,
your
dbas,
the
folks
that
need
elevated
access.
That's
really
what
cyborg's
built
its
business
around
securing
that
and
then
it's
morphed
into
a
lot
of
other
things.
So,
as
I
said,
we've
been
doing
application
secrets
management
for
for
over
10
years.
B
Endpoint
privilege
you
mentioned
so
so.
Keeping
people
from
being
administrator
on
on
their
own
laptops
is
is
a
core
part
of
the
business
now,
and
we're
really
now
focused
on
identity,
securing
identities
and
just
assigning
identities,
using
a
zero
trust
model
and
and
moving
forward
with
that.
We
acquired
a
company
a
little
over
a
year
ago,
called
adaptive,
which
is
a
really
a
single
sign-on
solution
and
that
that
starts
getting
at
that
that
sort
of
zero
trust,
dynamic
access
just
in
time
sort
of
access
for
for
identities.
B
So
so
that's
really
where
we,
what
we
do
with
applications
as
well.
Every
application
that
needs
a
credential
needs
to
be
authenticated,
so
it
needs
to
be
assigned
an
identity.
It
needs
to
be
able
to
authenticate
in
order
to
just
for
us
to
know
who
it
is
and
then
what
it
has
access
to,
and
so
it's
really
you
know
an
identity's
an
identity.
B
As
far
as
we're
concerned,
it
doesn't
really
matter
if
it's
a
person
or
a
process,
it
needs
to
authenticate
it's,
it's
access
needs
to
be
controlled
through
role-based
access,
control
rules
and
then
it's
its
access
needs
to
be
audited.
So
we
know
what,
when
it's
retrieving
those
secrets
and-
and
you
know
what
basically,
what
it's
doing
with
it.
Now
we
add
on
to
that
we
do
sequence
rotation.
B
A
And
just
writing
down
some
notes
here
I
have.
I
have
all
kinds
of
questions
that
I
want
to
that.
I
want
to
drill
our
victim
here
with
today,
but
I
I
do
want
to
mention
that
we
are
live
on
youtube
and
facebook
and
twitch,
and
so,
if
anyone
who's
joining
us
from
any
one
of
those
channels
or
the
bridge
here,
if
you
have
questions
for
jody
or
dave
or
or
santa
claus,
go
ahead
and
put
them.
C
A
How
did
you
know?
I
mean
it's
like
honest
to
god
I
mean
I,
I
people
who've
watched
the
show
before
know.
I've
been
here,
you
know
I'm
as
old
as
dirt,
and
I've
been
here
for
21
years,
but
it's
just
getting
worse
and
worse
and
worse,
you
know,
red
hat
has
single
sign-on,
which
is
doesn't
really
seem
to
mean
anything
because
I
seem
to
be
single
sign-on,
like
20
or
30
times
a
day
and
every
password
is
different
and
I
honestly
got.
A
I
have
a
notebook
where
I
write
everything
down
and
you
know
what
makes
it
worse
is
when
different
systems
are
like.
Oh,
you
have
to
automatically
change
it
every
six
months
and
then
you
can't
reuse,
but
I
don't.
I
don't
need
to
bore
you
guys
with
my
problems,
but
how
does
cyber
ark
fix
that
like?
Can
you
seriously
fix
that
jody?
Can
you
make
that
go
away?
Well,.
B
B
You
know
for
for
a
lot
of
reasons,
and
then
we
would
would
manage
that
so
that
the
purpose
is
really
to
relieve
the
user
of
a
secret
from
needing
to
really
know
what
that
password
is
from
an
application
perspective.
The
application
retrieves
the
secret
when
it
needs
it
and
it
simply
uses
it
to
connect
to
that
that
target
system.
So
we
don't.
You
know,
at
least
in
the
applications
perspective.
A
Okay,
that
that's
cool,
is
there's
and
we're
gonna,
and
you
guys
have
put
together
a
demo
here
which
is
going
to
be
somewhat
technical
in
nature
for
our
audience.
So
we're
going
to
we're
going
to
be
getting
to
that
here.
I'm
just
looking
at
our
at
our
schedule
here
are
there
workloads
that
are
more
susceptible
or
is
there
is
cyber
arc
vault?
Is
that
the
the
main
name
of
your
product
right,
cyborg
fault,
yeah,
yeah,.
A
A
Privilege
is:
are
there
certain
types
of
workloads
that
are
more
susceptible
or
that
are
that
take
advantage
that
benefit
more
from
what
you
folks
have
to
offer?
I
mean
it.
Obviously,
it
sounds
like
like
cloud
native
distributed.
Databases
like
you
know
like
yoga
bite,
or
you
know,
cockroach
db
or
anything
like
that.
That's
probably
like
a
prime
example
of
where
cyborg
fits
in
really
well
right.
B
Well,
we
certainly
can
solve
some
of
the
newer
use
cases.
A
lot
of
what
we
do
is
is
still
you
know,
the
classic
on-prem
oracle
database,
sql
server,
databases,
things
like
that.
Those
are
you
would
be
amazed
how
many,
how
many
of
those
passwords
are
not
under
management
or
they're,
being
stored
in
various
places.
So
so
that's
the
the
number
one.
B
B
You
know
jenkins
openshift,
has
secrets
we'll
talk
a
bit
about
kubernetes
secrets
here
in
a
bit,
so
it's
not
that
people
aren't
are
being
careless.
It's
just
that
the
solutions
they
may
be
using
aren't
necessarily
up
to
what
we
would
consider
adequate
standards.
You
know
for
we
we
advocate
thinking
like
an
attacker
and
so
understanding
how
how
secrets
can
be
exploited
or
or
discovered
and
exploited,
is
a
big
part
of
what
we
educate
the
market
on.
B
I
think
the
the
solarwinds
brief
really
opened
folks
eyes
to
the
susceptibility
of
the
the
devops
pipeline,
potentially
getting
compromised,
and
because
that
was
really
how
the
the
the
solarwinds
breach
happened
was
was.
It
was
a
dll
that
got
added
to
the
product
in
the
development
cycle
or
in
the
the
packaging
cycle.
So
so
that's
you
know.
Securing
devops
pipelines
is
a
big
part
of
what
we
talk
about
when
you.
A
Jody
you,
you
use
the
word
pipeline
and
I
keep
thinking
of
gas
shortages
and,
where
attack
on
on
that
that
pipeline
company,
how
did
that
happen
and
and
would
cyberark
have
prevented?
I
mean,
obviously
it's
a
pretty
generic
question,
but
I
mean
that
was
that
was
amazing
to
see
an
entire
pipeline
shut
down
and
the
effect
that
it
had
on
the
entire
eastern
part
of
the
of
the
country,
if
not
probably
the
whole
country
as
a
result,
but
like.
How
can
that
happen,
and
were
they
not
managing
secrets
or
or
like
what.
B
It
was
a
ransomware
attack,
but
but
yeah
it's
it's
it's
one
of
those
things
where
one
of
the
reasons
I
got
I
wanted
to
get
into
security.
Is
somebody
once
said
it's
the
problem
that
will
never
be
solved.
I
was
like.
Well,
that's,
that's
that's
a
good
place
to
be
because,
and
it
is
sort
of
like
an
arms
race.
You
know
as
soon
as
you
shore
up
one
you
know,
attack
vector
then
others
open
up
like
we
were
just
talking
about
with
the
devops
bypass.
B
A
B
B
Openshift
tv-
let's,
let's
show
a
little
bit
of
open
shift.
So
this
is
a
great,
a
lab
that
dave
and
I
put
together
for
to
show
how
how
secrets
can
be
accessed
from
pods
running
an
openshift,
and
so
it
just
goes
through
we're
all
about
providing
options,
and
so
some
people
want
to
use
apis.
Some
people
don't
want
to
use
apis,
can
actually
show
you
how
to
make
the
the
actual
kubernetes
secrets
or
openshift
secrets
more
secure.
So
we
will
probably
promise
to
keep
this
higher
high-ish
level.
A
C
Well,
I
was
just
gonna
say
I
mentioned
this
earlier,
but
for
those
who
missed
it,
if
anybody's
interested
in
learning
more
about
this
demo,
if
you
go
to
demo.openshift.com
you'll
see
it
there,
we
can
even
do
workshops
so
we've.
I
know
jody's
done
a
lot
of
workshops
already
on
this,
but
we've
got
it
set
up
where
we
could
stand
up
a
workshop
pretty
quickly.
C
For
those
who
know
about
red
hat,
we
have
a
product
demo
system
and
cyberark
is
now
in
there.
It's
really
easy
for
us
to
stand
up
the
infrastructure
around
for
this
workshop.
The
lab
guide
is
here,
jody's
showing
it,
and
so
just
let
us
know
happy
to
do
happy
to
do
a
workshop
in
in
your
location
of
choice.
B
C
B
Yeah
this
is
and
like
they
said,
we've
rolled
this
out,
and
so
I'm
actually
running
the
the
the
lab
in
the
red.
As
this
is
the
the
thing
itself,
I
ordered
it
earlier
today,
so
it
takes
about
40
45
minutes
to
to
get
get
fully
stood
up,
but
this
is
any
any
red
hat
solution.
Architect
has
access
to
this.
B
What
we're
going
to
show
is
just
various
ways
of
retrieving
secrets
from
pods
running
in
openshield,
so
this
is
really
from
the
the
developer
or
the
pod
deployer
perspective.
We'll
we'll
talk
more
about
this,
but
this
kind
of
gets
at.
What
I
was
saying
before
is
that
unless
you're,
actually
using
a
secrets
management
system,
the
place
you're
storing
your
secrets,
probably
could
be
improved
upon
and
so
secrets
management
is
a
term
that
really
came
about.
B
Before
encoded
they're
saying
you
basically
have
compromised
that
secret,
they
they're
they're,
not
even
saying,
maybe
checking
it
in
no
means
the
secret
is
compromised.
So
these
are
the
the
kind
of
things
that
we're
educating
folks
on
and
be
showing
them
a
better
way,
and
that's
really
what
this
this
lab
is
intended
to
do.
This
is,
as
you
see,
running
in
aws.
This
is
the
instance
that
I
had
provisioned
earlier.
B
I'm
logged
in
as
the
administrator,
but
this
has
the
ability
to
run
in
a
multi
to
support
multiple
users.
Each
user
has
their
own
name.
Space
has
their
own
basically
sandbox
to
play
in.
So
if
we
look
at
the
projects
here
on
the
cyber
lab
project,
we
go
to
the
the
developer
perspective.
There
we
see
there's
a
mysql
database
cloud
running
here
and
then
what's
called
the
dap
service,
node
conjure
enterprise
last
year
was
known
as
dynamic
access
provider.
B
Thankfully
we
renamed
it,
but
when
we
built
the
lab,
it
was
called
dab,
but
that
is
basically
the
the
manifestation
of
this
service.
So
the
idea
is
this
is
a
service
that
can
be
accessed
from
basically
anywhere
in
the
extended
enterprise
on-prem
in
the
cloud
multi-cloud
kubernetes
devops
pipeline.
So
the
idea
is
that
there
is
a
single
system
of
record
for
secrets
which
would
be
our
vault,
but
that
can
that
the
secrets
in
there
can
be
accessed
through
local
representations
of
that
service
and
that's
really
what
the
staff
service
node
is.
B
A
B
B
Okay
and
so
that
that's
so
so,
basically
all
the
secrets
are
going
to
come
from
here.
This
is
a
service,
that's
running
in
the
in
the
cluster,
and
so
the
applications
will
access
that.
So
what
I'm
going
to
do
is
go
over
to
the
user,
one
namespace.
We
can
see
that
there's
a
container
in
here
called
lab
admin.
B
B
If
I
go
to
workloads
and
go
into
my
lab
admin,
pod
and
open
a
terminal
here
now,
I've
got
a
terminal
in
my
lab
and
I
can
run
here
just
to
receive
things,
and
this
is
where
the
the
user
one
lab
directories
are
so
so
these
are
just
various
ways
of
deploying
applications,
various
ways
of
doing
authentication.
I
won't
go
into
great
detail
here,
but
basically
we
take
care
of
the
the
the
product
takes
care
of
authenticating
for
the
pod.
B
We
provide
a
small
container
that
authenticates
the
pod,
so
the
developer
doesn't
have
to,
and
the
whole
goal
here
is
to
remove
as
much
friction
as
possible
from
the
the
secrets
management
experience.
You
don't
want
developers
motivated
to
try
and
work
around
the
the
security
best
practice,
and
so
the
first
example
here
going
to
generate
the
yaml
and
deploy
the
app
here
is
where
the
authenticator
is
running
as
a
sidecar.
It's
continuously
refreshing
an
access
token
that
the
application
can
use
to
connect
to
that
database.
B
So
in
every
one
of
these
examples,
we're
retrieving
the
credentials
for
that
mysql
database
and
then
using
that
to
connect
to
the
database.
So
if
I
exec
into
the
pod,
we
look
at
this
script
here
called
mysql
rest,
so
this
is
simulating
an
application
that
wants
to
connect
to
that
database.
So
we
see
that
the
mysql
client
call
here
it's
going
to
use
the
hostname,
the
username
and
the
password,
the
username
and
the
password
are
being
retrieved
from
that
conjurer
service.
So
we
pick
up
that
token.
These
are
the
names
of
the
secrets
here.
B
My
sql
username,
my
sql
password,
make
our
rest
calls
to
the
service,
and
this
is
just
using
a
straight
up.
Rest
call
and
then
getting
those
secrets.
We
each
very
carelessly
leap.
Those
secrets
this
is
this-
will
get
us
something
we'll
talk
about
here
in
a
bit,
and
this
is
actually
called
out
of
the
kubernetes
documentation.
B
The
applications
still
need
to
protect
the
value
of
the
secret
after
reading
it
from
the
volume,
so
even
the
kubernetes
sequence
in
the
the
application
can
carelessly
log
it.
So
this
is
this
is
an
example
of
that,
but
we're
basically
showing
our
work
and
then
we
connect
to
the
database
so
running
the
script
we
just
get.
The
secrets
show
the
secrets
connect
to
the
database
and,
I
can
say,
show
databases
just
to
say
yeah
capability
here,
so
so
we've
now
connected
to
the
database
and
that's
the
whole
point
is
we've
gotten
the
credentials.
B
The
credentials
are
managed
by
by
cyberark,
but
our
application
is
able
to
retrieve
them
dynamically
and
use
them
and
in
this
case,
use
them
retrieving
them
with
a
with
a
rest
call,
and
some
people
just
want
that
api
experience.
Some
people
just
feel
more
comfortable
with
that,
but
we're,
like,
I
said,
we're
all
about
providing
options,
so
we
have
other
ways
of
doing
this.
So,
for
example,
we
can
go
into
this
example.
Here,
I'm
going
to
generate
the
gamma
and
I
think
you
can
see
what
we
try
to
do
is
make
the
lab
easy.
B
But
if
we
were
doing
this
in
an
actual
workshop
environment,
you
you'd
be
coaching
folks
actually
issue
the
the
oc
commands
to
do
the
deployments,
and
so
they
get
a
better
sense
of
how
this
actually
works.
Do
my
deployment
here.
This
actually
uses
a
solution
called
summon
and
summon
is
a
an
open
source
solution
that
we
provide.
B
That
will
inject
secrets
as
environment
variables,
and
this
is
this
I
show
I
like
to
show
this.
Just
because
summon
is,
is
a
cool
little
product
that
that
that
solves
a
lot
of
problems,
so
it
can
pull
secrets
from
different
back
end
systems.
It
doesn't
have
to
be
conjured,
doesn't
have
to
be
cyber
art,
it
can
pull
secrets
from
aws
secrets
manager
or
a
local
key
ring.
So
it's
just
a
way
of
sort
of
insulating
the
application.
B
From
having
to
know
where
secrets
are
coming
from,
we
look
at
this
script
here
called
my
sql
summon.
We
see
that
the
application
is
no
longer
making
rest
calls.
It's
just
accessing
environment
variables,
but
these
environment
variables
don't
actually
exist,
exist
in
this
environment.
We
grep
for
environment
variables,
beginning
with
db.
B
You
see
that
the
only
thing
here
is
that
host
name,
so
so
the
username
and
password
aren't
there
summon
can
be
used
to
retrieve
those,
and
I
won't
go
into
the
the
detailed
mechanics
of
it,
but
summon
basically
retrieves
the
secrets
for
the
application
calls
the
application
with
those
secrets
in
those
environment
variables.
So
the
application
can
now
echo
those
secrets
and
then
use
those
secrets
to
connect
to
the
database.
So
this
is
called
secrets
injection.
B
B
Github.Comcyber.Com,
that
is
a
new
tab,
so
this
this
is
here:
cyberact.github.io,
summon
lots
of
detail
there,
just
a
cool
tool,
that's
generally
useful
to
to
keep
applications
from
having
to
know
where
their
secrets
are
coming
from.
Helps
you
keep
those
secrets
out
of
source
code.
So
that's
that's
that
that
second
lab.
B
B
Yeah,
I
think
you've
seen
this
a
time
or
two
yeah.
So
this
third
example
is
where
we
really
say:
okay-
and
in
fact
three
three-ish
years
ago,
I
was
showing
that
summon
example
to
an
openshift
admin
and
he
said
well.
Why
can't
you
just
push
the
secrets
to
openshift
secrets,
because
our
applications
are
already
built
to
use
openshift
secrets
and
we
actually
thought
that
was
a
pretty
good
idea.
So
so
that's
what
this
does
is.
B
It
allows
the
application
to
use
openshift
secrets
as
native
open
share
secrets,
but
it
solves
these
these
issues
it
solves
at
least
a
couple
of
the
issues.
Certainly
this
issue
here,
where,
if
the
secrets
in
the
manifest
as
a
base64
encoded
value,
it's
not
encrypted,
it's
it's
basically
exposed.
You
look
at
our
db
credentials.
Yaml
here
this
is
my
kubernetes
secret.
So
we
see
the
kind
is
secret
name
is,
is
db
credentials.
B
There
is
something
that's
basics
for
encoded
here,
but
it's
just
the
database
name,
it's
not
really
a
secret,
so
we're
not
really
worried
about
that
getting
exposed
if
we
were
to
check
this
manifest
in
the
source
code.
But
we
see
down
here
this
conjure
map,
so
this
is
a
gamma
array
where
the
key
is
going
to
be
the
the
name
of
the
secret,
and
then
the
value
is
going
to
be
the
current
value
of
that
mysql
username
and
password
same
one
that
we've
seen
before
now.
B
We're
not
making
rest
calls
to
retrieve
this.
This
is
being
done
for
us
for
the
for
the
application,
so
that
when
the
application
goes
to
to
need
secrets,
they
can
be
made
available
just
like
any
openshift
secret
has
environment
variables.
So
if
we
grab
here
now,
we'll
see
more
than
just
the
db
name,
we
see
the
username
and
password
as
environment
variables,
so
these
are
mounted
from
the
openshift
secret
that
we've
dynamically
patched
with
these
values.
B
So
before
the
application
runs,
we
patch.
We
update
basically
update
the
secret
to
to
provide
these
values
here.
They
can
also
be
mounted
as
a
volume
which
we
we
prefer.
We
would
recommend
you
you
mount
them
as
volumes,
but
if
we
look
at
the
fc
secret
volume,
password
I'll
add
an
echo
here
just
so
it's
on
its
own
line.
We
see
the
database
password
so
at
this
point,
they're
just
kubernetes
secrets,
they're
just
open
shift
secrets.
B
You
can
use
those
native
secrets,
but
you
can
also
eliminate
that
security
risk
that
the
storing
basics
for
encoded
values
in
a
github
repository
represents.
So
that's
the
third
example
here.
The
last
example
starts
to
get
at
that.
That
thing
that
I
mentioned
earlier,
that
or
even
the
kubernetes
documentation
calls
out
the
application
has
to
protect
the
value
of
the
secret
if
the
application
leaks
the
secret,
as
we
say,
to
a
console
to
a
log
or
something
like
that,
the
application
has
exposed
that
secret.
B
That's
a
risk
that
can
happen
even
if
the
developer
is,
it
doesn't
have
any
any
sort
of
bad
intention,
and
that's
really
where
a
solution
that
we
develop
called
secret
list
comes
in
so
generate
the
gamble
for
that.
So
the
idea
here
is
what,
if
the
application
never
got
the
password
if
it
just
got
the
connection
to
the
database,
and
so
when
I
deploy
this
this
app
and.
B
It's
running
it's
creating
there
it's
running
and
go
in
here
now
I'm
going
to
look
at
this,
my
sequel,
seekerless
script-
and
we
see
here
now
there's
no
environment
variables.
It's
not
even
accessing
the
database
hostname
that
we
saw
in
the
environment.
It's
not
it's
not
accessing
the
actual
database
service
in
the
cluster.
It's
actually
accessing
the
database
as
if
it
were
listening
as
if
a
local
database.
What's
really
listening
on
that
default.
B
B
C
Yeah
that
that
synchronous,
lab
is,
is
my
favorite
being
a
former
developer,
and
it's
actually
the
one
that
I
focused
on
in
that
10
minute
video
that
I
did
so
very,
very
cool
lab.
I
I
always
chuckle,
because
when
I
first
learned
about
kubernetes
secrets
and
and
navigated
through
openshift
to
where
you
could
see
the
secrets
I
was
like.
Oh,
this
is
great.
My
secrets
are
taken
care
of,
but
then
you
can
click
a
little
I
button
and
it
shows
the
actual
value.
B
Yeah,
I
used
to
use
a
browser,
I'm
going
blank
on
the
name
that
that
showed,
and
it
actually
shows
containers
and
shows
the
connections
between
the
containers
and
it's
the
same
thing.
Brand
privileged
and
and
you
can
click
on
the
container
and
see
all
the
environment
variables,
even
the
ones
that
were
mounted.
As
you
know,
just
from
from
kubernetes
secrets.
So.
B
B
Yeah,
it's
it's
it's
one
of
those
things
where
you
know
until
you've
really
paid
attention
to
it.
You
you
start
finding
these
things
and
and
that's
why
you
know
we
advocate
thinking
like
an
attacker.
It's
like
okay,
how?
How
could
somebody
get
these
credentials
if,
if
we're
not
vaulting
them
and
rotating
them
regularly
keeping
them
ephemeral?
Because
there's
a
lot
of
things
we
would
say
goes
into.
You
know
just
basic
good
security
hygiene,
around
secrets.
C
A
A
So
how
has
how
has
security
changed
as
a
result
of
like
distributed
computing?
You
know
containers
orchestration
kubernetes,
so
it
sounds
like
you
kind
of
answered
that
already
a
little
bit,
but
I
mean
so
because,
presumably
based
on
what
I
infer
cyber
arc
used
to
be
on
premise
only
with
the
with
the
orchestration
of
kubernetes
requirements
and
microservices
and
containers
and
service
mesh
and
everything
else
you
folks
acquired
conjurer,
and
that,
provided
you
folks
that
the
necessary
technology
to
then
kind
of
expand
into
multi-cloud
is
that
is
that
accurate.
B
Yeah
yeah
I
mean,
and
when
I
do
my
my
full
presentation
with
all
my
slides,
I
like
to
point
out
that
security
security
is
not
just
for
people
anymore,
but
it
always
starts
with
people.
People
are
very
well
vetted,
typically
before
they're,
getting
given
an
identity
in
in
a
network.
You
know
so
that
you
have
to
provide
two
or
three
forms
of
documentation,
people
to
do
background
checks.
B
You
know
so
so
people
are
very
before
they're,
given
an
identity
in
the
network,
and
then
you
have
passwords
and
to
your
point,
you
have
to
change
the
passwords
on
the
regular
basis.
You
have
to
have
a
certain
level
of
complexity,
so
you
want
to
extend
that
but
and
people
deploy
applications
and
but
more
and
more
people
are
building
automation
using
things
like
ansible
to
to
deploy
infrastructure.
B
So
that's
the
real
problem
that
we're
focused
on
is
securing
that
whole
chain
of
trust
from
from
developer
to
to
automation
and
then
on
to
applications,
and
that's
that
I
think,
is
you
know
what
what
devops
has
really
brought
about.
You
know
in
the
last
10
years
you
know,
automation
itself
has
has
really
increased
the
the
attack
surface.
If
you
will
and
as
we
saw
with
the
solarwinds
breach.
You
know
that
that
is
now.
If
it's
not
secured,
it
can
be
vulnerable.
A
B
A
We
there
meaning,
like
you
know
there
there
was
there,
was
there
was
unix,
then
there
was
linux
and-
and
you
know,
then
there
was
kvm
and
zen
and
virtualization
and
then
openstack
kind
of
hit
the
street
and
openstack
was
like
the
shiny
object
and
remember
going
to
those
those
conferences
it
was
like.
Oh,
this
is
going
to
be
the
this
is
going
to
be
the
end-all,
be-all
and
then
containers
kind
of
came
out
and
became
more
mainstream.
A
I
mean
certainly
containers
aren't
new
right,
they've
been
around
forever,
but
with
the
docker
technology
that
came
out,
they
became
easier
to
manage
and
or
and
and
so
forth
and
then
and
then
containers
kind
of
went
away
and
docker.
I
don't
even
know
if
dockercon
is
still
even
a
thing,
but
you
know-
and
here
we
are
kubernetes
kate's
right.
So
is
this
it
are
we
like
or
is
this
gonna,
be
the
shiny
object
for
another
18
months
and
then
there's
going
to
be
something
else.
B
Well,
I
think
if
technology's
shown
us
anything
we're
never
going
to
be
done.
You
know,
there's
always
going
to
be
the
new
new
thing
at
one
time:
service,
oriented,
architectures
and
and
web
services.
So
xml.
All
of
that
was
was
the
thing
that
looks
pretty
anachronistic
at
this
point.
You
know:
there's
still
a
lot
of
applications
out
there.
So
so,
if
if
technology
has
shown
us
two
things
one
is
it
never
stops
and
you
never
get
rid
of
it.
You
know
it's
like
what
you
have
we
you
know.
B
B
A
Solution
we
had,
we
were
trying
to
be
really
well
prepared.
For
this
call-
and
I
remember
reaching
out
to
your
marketing
people-
and
I
said:
hey
you
guys
got
to
give
me
like
you-
know,
10
softball
questions.
So
if,
if
jody
dave-
and
I
kind
of
run
out
of
things
to
talk
about,
I
can
start
just
reading
off
the
the
boilerplate
buzzword,
buzzword,
bingo
questions,
but
I
don't
think
we're
going
to
need
to
get
to
those.
A
Thankfully,
but
I
would
say
if
you
know
when
the
when
we,
when
we
hang
up
well,
maybe
he'll
say
that
one
for
later
do
you
have
a
war
story
like
we're
working
on
doing
this
virtuals
we're
working
on
putting
together
a
virtual
event?
It's
going
to
be,
I
think,
in
july,
or
something
like
this
and
I'm
going
to
invite
software
partners
to
come
and
be
be
a
part
of
a
panel
and
say
if
you
got
a
story
and
you
want
to
be
part
of
panel,
it's
going
to
be
called
something
like.
A
You
won't
believe
it
when
right
so
like
what,
if
is
there
anything
that
you've
absolutely
just
been
completely
dumbfounded
by
when
you're
working
with
a
customer
like?
I
can't
believe
that
how
do
people
not
step
in
it
like
what?
What
can
you
do
in
advance
to
help
people
not
go
down
some
path?
That's
completely
going
to
you
know,
cause
an
unmaintainable
environment
for
them.
B
Well,
you
know
we
would
always
say
first.
The
first
step
is
getting
your
secrets
out
of
source
code.
No,
no
hard-coded
secrets
and
that's
you
know,
that's
job
one,
there's
still
a
lot
of
connect
doesn't
return,
those
secrets
never
get
rotated,
because
then
they
have
to
recompile
the
application.
So
you
know
they're
they're.
They
may
be
long
running
applications.
They
may
not
even
have
the
the
the
knowledge
to
have
it
to
know
how
to
rebuild
that
application,
but
that's,
but
that
would
be
the
first
step.
B
I
would
think
the
second
step,
like
I
said,
is
as
soon
as
you
take
it
out.
Where
do
you
put
it?
You
know
where
do
you
store
it
in
any
vaulting
solution
is
better
than
none.
You
know,
so
don't
just
put
it
in,
don't
put
it
on
a
post-it
note,
as
jane
was
saying
earlier,
don't
stick
it
on
your,
don't
stick
it
on
your
screen,
but
also
you
know,
don't
put
it
in
plain
text
in
a
file
somewhere
use
a
key
ring
there.
B
There
are
native
vaulting
technologies
that
are
better
than
than
you
know
putting
it
in
plain
text
somewhere,
but
I
would
seriously
say
you
know,
look
at
you
know.
There's
there
are
open
source
solutions
out
there
easy
ways
to
get
started.
What
we
hear
more
and
more
now
is
we.
We
just
want
one
vault.
B
A
B
A
B
You
do
you
know,
people
will
use
the
the
solution
at
hand.
Well,
jenkins
has
a
place
to
store
credentials.
Ansible
has
a
place
to
store
credentials,
actually
red
hat
built
a
very
nice
integration
to
two
of
our
sequence:
management
solutions
for
ansible
tower,
but
ansible
open
source.
You
know
it
means
secrets.
We
have
a
plugin
for
that,
but
the
even
if
you
standardize
on
a
tool,
but
each
project
has
their
own
vault.
B
Then
it's
very
hard
for
the
security
organization
to
know
how
secrets
are
being
used
these
each
one
of
these
is
is
being
maintained
by
an
organization
that
may
or
may
not
be
using
best
practices
and
and
and
that
creates
its
own
set
of
problems.
So
so
no
it's
the
one
vault
is
is
not
the
norm.
It
is,
it
is
the
norm.
You
know,
cyberark
has
a
pretty
large
presence
in
the
fortune
5000.
B
C
B
Yeah
the
ansible
tower
integration
is
it's
very
slick
in
that,
basically,
you
replace
a
credential
with
a
call
to
a
credential
retriever.
So
so
you
build
a
a
special
kind
of
credential.
That's
a
conjurer
credential
retriever
it.
It
is
the
thing
that
retrieves
the
secret,
so
it
has
an
identity.
It's
given
an
identity
that
can
can
authenticate
to
condo
and
retrieve
secrets,
there's
also
a
similar
implementation
that
uses
our
central
credential
provider,
which
is
a
little
bit
older
technology
similar
to
conjure
but
but
but
a
little
different.
B
But
but
the
idea
there
is,
you
don't
have
to
go
and
change
all
your
playbooks.
What
you
do
is
you
change
a
hard-coded
credential
and
an
ansible
credential
with
that
that
credential
retriever
and
it
takes
as
a
parameter
the
name
of
the
secret
to
retrieve
and
and
replaces
the
value
there.
So
it's
very
easy
just
to
substitute
hard-coded
credentials
in
your
ansible
credentials
with
that
call
to
that
credential
provider
or
credential
retriever.
Excuse
me.
B
A
It's
just
one
follow-up
question
about
the
the
whole
concept
of
disjointed
security
teams.
I
just
I
find
that
amazing.
You
know
we
were
talking
about
different
vaults
and
different
teams.
Just
deploying
whatever.
How
do
is.
Is
that
a
problem
with
really
big
fortune
1000
companies,
or
is
that
mid-market
companies,
or
is
that
like
smbs,
where
they
just
they're
just
kind
of
winging
it
by
their
by
their
bootstraps?
B
Well,
like
I
said
secrets,
management
was
really
only
became
a
thing
about
four
or
five
years
ago.
So
so
this
has
it's
been
exacerbated
by
automation,
but
it's
existed
for
a
long
time.
We've
helped
a
lot
of
those
fortune.
Companies
secure
applications,
but
you
know
these
newer
use
cases
came
about,
so
it's
I
think
it's
just
technological
evolution.
You
know
the
the
state
of
adoption,
the
the
best
practices
become
more
commonly
known
and
organizations
put
initiatives
in
place
to
start
consolidating.
B
We
saw
the
same
thing
with
with
cloud
adoption.
Originally
developers
went
to
the
cloud
because
they
couldn't
get,
they
couldn't
get
access
to
servers
fast
enough,
so
you
had
a
shadow
I.t
phenomenon.
This
is
this
is
very
similar.
It's
kind
of
a
shadow
I.t
phenomenon
that
that
security
organizations
have
have
now
become
sensitive
to
and
are
taking
steps
to
address.
A
Okay,
I'm
going
to
throw
in
one
question
here
just
to
when
we
get
off
this
this
show
here
I
want
to
prevent
that
phone
from
ringing
on
your
desk
and
having
your
your
manager
or
your
director
marketing
call
you
and
be
like
jody.
You
were
on
there
for
an
hour
like
why.
Why,
wouldn't
you
have
just
said
the
following,
so
is
there?
Is
there
something
that
you
want
to
share
with
our
listeners
here?
That
will
prevent
that
phone
call
from
happening
well.
B
Let
me
let
me
just
take
a
second,
but
but
I've
said
you
know
I
I
I
do
things
like
this.
I
talk
about
this.
This
is
my
job.
You
know
talking
about
this
stuff,
so
I've
hit
most
of
the
major
points
you
know.
I
would
just
reiterate
that
our
our
goal
is
to
reduce
that
friction.
Empower
the
security
team
to
deliver
a
service
that
can
be
consumed
as
easily
as
possible
by
by
the
users
of
secrets,
but
those
secrets
are
managed
by
the
security
team.
That's
really
the
goal.
B
B
Developers
want
that
same
experience
for
their
secrets,
so
as
a
self-service
model
is,
is
really
imperative
to
in
in
reducing
that
friction
developers
don't
want
to
have
to
wait
until
somebody
gets
around
to
provisioning
their
access.
They
want.
You
know
fairly
immediate
turnaround,
or
at
least
visibility
into
that
that
that
process.
So
so
that's
that's
things
that
we've
helped
our
customers
build
we're
working
on
how
to
provide
the
widgets
every
the
the
beauty
of
this
space
is
every
customer's
process.
B
If
not,
every
project's
devops
process
is
a
little
bit
different,
and
so
there's
no
there's.
No
one
way
of
saying
this
is
the
you
can't
be
prescriptive
about
how
people
do
their
devops,
and
so
we've
got
to
meet
folks
where
they
are
and
help
them
secure
the
pipeline
that
they've
already
built,
but
but
doing
that
necessitates
that
we'd
be
very
flexible
and
and
how
we
how
we
deliver
that
so.
B
A
A
B
B
So,
as
you
can
see
dave-
and
I
have
collaborated
on
on
multiple
fronts
here-
there's
some
links.
There
links
there
to
the
open
source
solution
for
reconjure,
so
it
is
available
as
a
single
node.
Open
source
solution
at
contour.org
secret
list
is
also
part
of
that
and
summon
those
are
all
three
open
source
solutions.
Red
hat
being
you
know
the
the
the
name
and
open
source
we
like
to
call
attention
to
that
and
then
then
the
documentation,
our
our
enterprise
documentation,
is
online
at
docs.cyberarc.com.
A
Great
well,
I
I'm
pretty
sure
that
the
that
the
stream
switched
over
at
the
top
of
the
r,
but
this
is
going-
this
recording
is
going
to
be
post-produced
and
then
it
will
be
re-published
back
onto
facebook,
youtube
and
and
our
linkedin
site.
So
it's
good
to
to
get
this
on
there,
so
jody
from
cyberark
dave,
muir
from
red
hat.
Of
course,
thanks
for
joining
us
today,
I
know
that
this
was
this
is
very
informative
and
we'll
look
forward
to
catching
up
with
you
soon.