►
From YouTube: Can You Trust Your Container App?
Description
Containerized applications running in OpenShift need controls to access resources just like human users. Best-practices such as zero trust, least privilege, authentication, authorization, segregation of duties, and audit must apply equally to containerized applications as they do for humans. This session explores how developers can build secure, trusted containerized applications, without the overhead of managing secrets by leveraging the integration between CyberArk Conjur and OpenShift.
A
My
name
is
Karen
elder
I'm
from
cyber-ark
software
and
today
I'm
going
to
talk
to
you
about
a
problem
that
I'm
sure
anyone
who
runs
openshift
or
any
other
tool
in
your
IT
environment
have
bumped
into
which
is
secret
management.
And
how
do
you
trust
your
containerized
applications
when
they
run
within
OpenShift
or
kubernetes,
and
how
do
you
free,
on
the
other
hand,
your
developers
from
the
headache
of
dealing
with
secret
management.
A
So
I'm
sure
a
lot
of
you
have
heard
about
many
initiatives
in
the
last
few
days
of
digital
transformation
and
with
the
move
to
the
new
cloud
native
environments.
Obviously,
we
have
much
more
infrastructure
applications,
much
more
automation,
running
in
your
IT
environment,
whether
it's
in
the
cloud
or
on-premise
or
in
hybrid
environments.
A
If
in
the
past
we
were
much
looking
and
security
looked
mainly
on
human
users
that
need
to
access
different
resources
and
looking
after
what
users
can
do
monitor
them,
take
care
of
access
control
in
today's
environment,
where
there
is
much
more
operation,
the
new
privilege
is
actually
code.
Many
tools
are
doing
what
people
used
to
do
in
the
past,
and
now
automation
is
taking
care
of
that,
and
we
should
be
looking
to
see.
How
are
we
securing
that?
A
A
So
is
all
of
those
users
and
code
that
in
tools
that
are
running
in
our
environment
there,
there
are
much
more
secrets
and
and
keys
and
tokens
and
passwords
that
are
scattered
all
around
just
try
to
count
in
your
organization
how
many
for
each
tool
or
each
user
that
is
working
in
the
environment,
how
many
different
systems
or
resources
or
cloud
services
it
can
access
for
each
of
these.
They
need
to
have
a
certain
secret,
a
certain
key
that
will
allow
them
that
access
now
put
tie.
A
All
of
that
together,
that's
a
huge
risk
to
your
organization
and
anything
left
open
like
that,
basically
leaves
a
door
to
an
attacker
to
come
and
gain
control
to
in
your
environment,
so
I
I
like
calling
all
those
new
tools,
the
new
domain
controller
or
the
new
ID
administrators,
because,
basically
that's
what
they
do
now
and
if
now
a
devops
person
is
now
controlling
your
hand,
Sibyl
or
your
OpenShift.
Basically,
this
has
become
a
human
controller
to
your
risk.
A
A
So
some
of
you
may
ask
or
say,
but
I
am
using
ansible
volt
or
I'm
using
open
the
kubernetes,
a
secret
solution.
Isn't
that
good
enough?
So
that
might
be
a
good
local
initiative.
But
when
you
look
at
it
from
an
enterprise
perspective,
a
large
enterprise
that
needs
to
have
manage
and
control
and
secure
a
very
large
environment,
on-premise
or
in
the
cloud,
we
don't
want
you
to
have
those
security
islands,
and
why
is
that
security?
Island?
First,
you
can't
really
share
secrets
or
credentials
between
such
local
tools
and
second
from
per
security
perspective.
A
These
are
solutions
that
were
not
built,
really
felt
really
with
security
in
mind,
with
all
the
capabilities
that
are
needed
for
secret
management,
things
like
central
audit
or
rotation
of
credentials
and
secrets,
they
do
not
provide
that.
So
we
want
to
really
provide
you
an
enterprise-wide
solution
that
can
be
deployed
and
apply
to
our
meant
whether
we
running
today
on
premise
tomorrow
on
AWS
and
maybe
next
year,
in
Google,
Cloud
or
in
edger.
A
You
know
how
do
you
design
your
environment,
your
applications,
your
tools
that
are
going
to
run
in
those
new
environments
from
the
beginning
to
work
in
a
secure
manner?
If
everything
is
all
about
automation,
let's
put
that
into
let's
automate
security
as
well,
and
let's
put
that
into
our
pipeline
and
build
it
correct
from
the
first
place
and
not
to
just
increase
our
technical
depth.
Now
the
good
news
is
that
probably
all
of
you
are
somewhere
in
this
journey.
So
that's
a
great
opportunity
to
deal
with
that.
A
A
Cyberchondria
was
really
designed
and
built
from
day
one
to
address
those
challenges
of
cloud
elastic,
dynamic,
ephemeral
and
environments,
and
also
integrating
into
all
of
those
tools
and
platforms.
On
the
one
hand,
it's
supposed
to
address
the
need
of
the
security
teams
that
need
to
have
the
controls
in
place,
but
do
not
necessarily
know
you
know
all
the
technologies
and
new
tools
they're
very
well.
On
the
other
hand,
we
provide
native
tools
to
developers.
We
really
want
to
remove
the
headache
of
secret
management
to
developers.
A
We
want
to
deliver
a
very
seamless
solution
to
them
that
they
will
simply
hey
focus
on
writing
code.
We
will
take
care
of
the
securing
all
your
secrets
and
also
auditors
can
benefit
from
it,
because
they
will
get
like
a
central
audit
for
and
proof
for
everything
that
is
happening
in
your
environment,
and
this
is
mainly
relevant
to
highly
regulated
organizations.
The
audit
piece.
A
So
what
have
we
done
with
the
open
shift?
That's
what
I'm
going
to
focus
today.
We,
we
have
integrations
with
many
tools
and
environment
today.
I
will
talk
about
open
shift
and
how
we
can
deliver
secrets
into
applications
running
within
your
open
shift
environment
in
a
highly
secure
manner
and,
on
the
other
hand,
really,
as
I
mentioned,
free
the
developers
from
dealing
with
that,
so
the
integration
goals
were
were
really
around
security
and
how
do
we
securely
authenticate
each
container,
each
application
that
is
running?
A
We
don't
want
to
replace
your
house
coded
credentials
with
a
password
to
our
solution,
because,
basically,
that
will
not
solve
the
problem.
That's
shifting
it
from
one
place
to
the
other.
We
want
to
solve
that
bootstrap
problem.
We
want
to
solve
that
secret
zero
problem,
so
people
call
it
in
different
names
and
still
provide
central
audit
provides
aggregation
of
duties
so
which
application
can
access
only
the
secrets
that
is
supposed
to
access
and
not
other
things,
we
believe
in
lease
privilege
and
model
and,
of
course,
also
secret
rotation.
A
A
Okay.
So
before
we
go
into
the
demo
of
how
this
integration
works,
so
you
can
run
conjure
within
your
openshift
environment.
We
have
a
master
with
higher
availability,
cold
and
hot
standbys.
You
can
choose
to
run
them
outside
or
inside
the
open
shift
environment
based
on
how
many
environments
it
serves,
but
we
also
have
this
unique
component
that
is
called
follower.
The
follower
is
an
active
replica
of
our
master,
so
it
includes
all
the
secret
and
it
sits
close
to
your
application.
A
So,
for
example,
you
can
put
one
or
more
followers
in
the
same
cluster
of
your
application,
and
that
means
your
application
will
get
secrets
in
a
very
high
performance
in
a
scalable
way.
It
will
be
close
to
it
and
even
if,
for
some
reason,
the
connection
to
the
master
is
lost,
it
will
still
continue
to
serve
your
application.
So
that's
a
very
robust
and
scalable
architecture
and
highly
available
architecture
that
we
provide
there.
We
realize
that
secrets
if
they
are
not
delivered
to
your
application.
Basically
it
would
stop
working.
A
So
first
we'll
see
within
the
OpenShift
environment,
as
I
mentioned,
we
have
the
master
running
and
the
two
followers
they
are
already
deployed
in
this
environment,
and
the
first
thing
that
we
will
do
is
define
the
conjurer
policy.
So
the
policy
as
I
mentioned,
we
try.
We
want
to
provide
developers
the
tools
that
are
native
for
them.
That
will
not
hurt
the
velocity
and
will
remove
that
headache.
So
you
can
see
the
policy
is
a
Yama
is
the
llamo
file,
so
you
can
write
it
with
your
application
check
it
into
your
code.
Repository
and.
A
Basically,
it's
a
declarative
policy.
What
we
do
here
at
the
beginning,
we
define
an
application
and
that
needs
to
access
a
certain
a
database,
so
it
needs
the
secrets
to
that
database.
So
we
just
give
permission
to
that
application
to
access
the
database,
we'll
also
run
it
in
two
parts
in
our
OpenShift
environment.
So
we
define
those
towards
as
host
and
we'll
provide
access
to
our
application,
and
we
say
it
will
run
in
that
those
parts.
A
Okay,
the
first
thing
we
do:
we
will
load
this
policy
into
conjurer.
We
will
now
go
to
the
conjurer
UI
I
mentioned
it
can
serve
admins
security.
We
see
all
the
policies
that
we
have
we'll
enter
this
policy
that
we
just
loaded.
We
see
all
the
entities,
the
permissions
who
can
access
what
and
all
the
related
audit
to
that
policy.
A
A
This
is
the
secret.
Now
we'll
go
back
to
our
openshift
environment.
We
didn't
run
our
application
yet
so
there
are
no
parts
that
are
running
when
we
will
now
run
our
application.
It's
a
very
simple
and
dummy
application,
just
for
the
demo
it
basically
you
asked
it
to
retrieve
secrets
and
it
will
show
it
to
the
screen
not
recommended
for
a
production
environment.
A
In
our
policy
at
the
beginning,
we
define
those
pods
with
application
name.
Now
we
call
our
stupid
command
of
retrieving
passwords
to
the
screen.
We
see
the
secret
that
we
saw
before
and
now
we'll
go
change
the
secret
value.
So
we
will
believe
me
that
it
really
gets
the
right
password
from
conger.
If
we
retrieve
the
pan,
they'll
ask
it
to
retrieve
the
passwords
again,
then
we
see
we
have
the
new
password
here
with
the
AAA
that
we
just
added.
So
what
happened
here?
A
Let's
go
back
for
a
second
to
our
diagram,
so
we
have
these
two
pods
running
the
application.
Ok,
these
application
need
to
get
access
to
secret.
The
secrets
are
stored
in
conjurer.
We
want
to
make
sure
that,
if
we're
delivering
the
secrets
to
those
application,
we
actually
authenticate
them.
These
are
really
the
applications
that
they're
saying
they
are
and
they
are
authorized
to
get
those
secrets.
So
what
we
do
here,
our
solution
comes
with
its
code
that
you
run
in
a
sidecar
container.
A
Ok,
this
sidecar
container,
before
your
application
starts
we'll
basically
ask
will
authenticate
itself
against
several
conjurer
based
on
its
characteristics
that
will
so
defining
our
policy
like
the
name
or
the
namespace,
the
name
of
the
part,
the
name
spacer,
and
there
are
other
attributes
that
are
supported.
We
will
authenticate
and
check
that
this
part
is
really
the
one
that
is
allowed.
A
That
is
really
the
one
that
it's
saying
it
is
and
that
it's
allowed
to
access
the
secret
that
it
asking
I
may
have
several
applications,
and
each
of
them
will
be
able
to
access
different
secrets.
It
doesn't
mean
if
we
run
in
the
same
cluster.
I
must
be
able
to
run
a
tool
to
access
all
those
secrets.
So
we
have
that
segregation
of
duty,
what's
also
nice
about
it,
that
we
have
this
tool,
someone
it's
an
open
source
tool
that
will
deliver
the
secret
to
my
application
container.
A
So
if
today
you
have
applications
that
already
consume
secrets
from
an
environment
variable
from
a
file,
you
don't
need
to
change
anything
in
your
code.
You
can
simply
deploy
this
solution
and
it
will
deliver
the
secret
to
your
application.
So
remember
we
mentioned
we
want
to
free
developers
from
dealing
with
secrets.
That's
the
way
you
can
just
configure
it,
deploy
it
and
that's
it.
A
Your
applications
don't
need
to
change
a
single
line
of
code
and
they
can
consume
the
secrets
from
a
secured
repository
with
the
audit,
with
the
segregation
of
duty
with
the
access
control
and,
of
course,
with
the
ability
to
also
rotate
secrets.
That
sbrick
has
a
lot
of
experience
with
and
is
capable
of
changing
and
rotating
hundreds
of
types
of
Secrets
that
are
out
there
for
different
systems.
A
A
Okay,
okay,
so
there
the
last
part
that
I
had
I'll
skip
it.
Basically,
I
wanted
to
show
you
like,
if
I
run
my
application
in
a
third
pod
that
I
didn't
define
in
my
policy
at
the
beginning,
were
we
defined
a
policy
with
which
applications
are
allowed
to
get
secrets?
If
I
run
my
application
now
in
a
third
pod
that
was
not
defined,
which
is
unauthorized,
we
could
have
seen
that
it
basically
fails
and
will
not
be
able
to
get
the
secret.
So
only
really
the
authenticated
and
predefined
applications
can
access
them.
A
Okay,
so
I
haven't
mentioned
that
several
Conger
has
an
open-source
version
that
you
can
start
with
you're
like
a
local
initiative
to
conjure
dot,
W
double
EE
conjure,
dot
org
you
can
download
it
there's
also
like
a
tutorial
that
will
take
you
through
the
initial
step.
You
can
try
it
out
and,
of
course,
there's
also
a
supported,
Enterprise
version.
A
That
also
includes
all
they
have
availability
and
capabilities
when
you
really
want
to
operationalize
it
and
go
wide
to
your
enterprise,
it
also
integrates
with
a
cyber-ark
privileged
account
security
solution,
which
was
again
a
leading
solution
in
the
market
for
privileged
account
security.
So
if
you're
already
in
cyber
a
customer,
many
of
our
customers
are
here.
You
can
basically
leverage
your
existing
investment
and
still
manage
all
your
secrets
within
the
cyber
at
fault
and
get
it
directly
to
your
openshift
containers
and
many
other
tools,
whether
it's
ansible
jenkins
or
whatever.
It
is
so
first.