►
From YouTube: OC - Secrets management
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
this
is
dave
herschkovitz
and
today
I'm
going
I'm
going
to
walk
you
through
my
opportunity,
canvas
light
I've
created
for
secret
management,
and
I
want
to
first
talk
about
the
problem
that
we
see
today
in
the
market
or
in
the
field.
Then
what
are
the
proposed
solutions
that
gitlab
at
the
moment
has
to
offer
and
what
are
the
potential
opportunities
in
imc
and
we'll
start
with
the
problem?
The
problem
is
simple:
secret
management
is
a
problem
users
having
hard
time
managing,
secure,
slowly,
secure
and
their
secrets.
Now
what
is
a
secret?
A
Anything
that
you
want
to
make
sure
is
confidential
could
be
like
using
my
password
api
key
ssh
key
token,
everything
that
you
don't
want
user
to
get
exp
to
be
exposed,
or
if
someone
retrieve
that,
then
they
can
authenticate
to
your
environment.
And
why
do
we
have
this
problem
today?
Why
didn't
we
had
it
years
back?
We
are
hearing
a
lot
this
term
about
security.
Shifting
left
security
shifting
length
means
that
early
on
in
the
development
process,
engineers
need
to
think
about
a
security
requirement.
A
This
wasn't
something
that
happened
in
the
past,
because
today
there
is
first
of
all,
there
is
way
more
threads
that
there
are
today
the
obvious
threads.
You
know
you
hear
it
all
all
over
the
news,
but
also
with
the
with
the
move,
to
a
micro
service
architecture
that
we
see
more
and
more
organizations
are
going
to.
It
means
that
organizations
are
distributing
their
services.
A
Now
those
services
need
to
speak
with
each
other
or
communicate
between
themselves
and
when
they
do
it,
we
want
to
make
sure
that
this
communication
happen
in
a
secure
manner,
because
all
need
to
happen
is
that
one
compromise
service
it
could
create
a
data
leakage
across
your
organization,
and
this
is
one
of
the
challenges
we
have
with
the
securing
your
supply,
your
software
supply
chain.
So
there
are
like
more
chains
in
the
league
and
the
weakest
link
that
there
is
there.
If,
if
it
get
exposed
or
compromised,
then
basically
this
is
breaking
the
entire
chain.
A
So
I
hope
you
understand
the
analogy,
but
basically
it
means
that
you
have
more
things
that
you
need
to
secure
means
that
you
have
more
secrets
that
you
need
to
manage,
and
this
is
the
problem
about
a
a
secret
management
solution.
One
thing
to
add
in
the
past
security
was
something
that
was
only
scoped
to
the
security
team.
A
Usually
they
used
to
come
in
in
the
test
phase
like
after
you've
developed
your
your
your
product
or
your
software
or
your
solution,
and
then
they
would
come
in
the
test
and
say:
okay,
you
need
to
secure
this.
You
need
to
secure
that
now.
This
is
not
the
case.
Now.
Security
is
something
that
software
engineers
need
to
start
thinking
about
it
when
they
write
their
code
and
devops
teams
need
to
integrate
security
requirement
as
a
part
of
their
devops
processes
and
I'll
give
you
an
example.
A
For
instance,
if
you
want
to
deploy
an
application
to
an
aws
instance
or
a
kubernetes
cluster,
it
means
that
you
need
to
authenticate
against
this
cluster.
The
authentication
happened
in
a
ci
job
actually
in
the
cd
job,
this
authentication.
If
this
job
get
compromised
and
someone
gain
access
to
the
authentication
method
against
your
platform,
your
production
environment,
staging
whatever
it
means
that
they
can
access
that
environment
and
they
can
do
whatever
they
want.
A
So
this
is
this
is
a
problem
that
engineers
and
devops
engineers
and
basically
across
the
organization,
are
aware
of
because
nobody
wants
to
risk
a
data
leakage,
because
it
means
your
job
now.
So,
as
I
mentioned,
there
are
more
things
that
you
need
to
manage
more
things
that
you
need
secure,
and
this
is
why
secret
management
is
a
problem
that
we
are
seeing
today.
Now,
what
does
git
lab
has
to
offer?
We
start
with
the
most
basic
thing
variables.
A
There
are
several
ways
where
we
can
scope
and
limit
the
exposure
of
a
variable,
for
instance,
in
variable
scope,
a
protected
environment
and
mask
variable
now
mask
viable
is
something
that
we
communicate
as
the
secure
way
for
storing
value.
It's
not
really
secure,
because
there
are
several
ways
where
users
can
extrapolate
the
value
of
a
must
variable.
Now
I
have
to
say
that
this
is
a
common
problem
across
all
or
most
of
the
ci
platform.
It's
not
something
that
only
gitlab
has
and
so
for.
A
Storing
secrets
mask
variable
is
not,
I
would
say,
the
official
or
the
recommended
way,
because
it's
not
really
secret.
Okay,
anyone
with
a
little
bit
of
a
fork
could
expose
this
value.
And
secondly,
second
solution
that
we
have
is
an
integration
with
a
different
external
secret
management
provider
such
as
hashicorp
vault,
okay.
So
we
have
a
way
for
our
user
to
authenticate
against
a
against
hashicorp
and
then
retrieve
the
secret
form
the
secret
management
solution
as
a
part
of
their
ci
cho.
A
Now
one
part
one,
one
main
problem
that
we
are
seeing
here
is
first
organization
organization
need
to
have
a
secret
management
solution.
This
is
number
one
number
two.
We
need
to
build
an
integration.
Okay,
so
right
now
we
have
a
native
integration
with
vault.
Again
there
are
like
more
requirements.
Even
if
we
have
this
integration,
there
are
more
enhancements
that
we
can
do
to
disintegration
and
what
happens
if
organization
doesn't
have
hashicorp?
I
mean
all
the
major
cloud
provider
has
a
secret
management
solution.
A
Also,
there
are
like
other,
which
means
that
this
is
a
solution
that
is
scoped
only
for
world
use.
A
This.
The
third
thing
that
we
have
is
the
work
that
we
are
doing
with
the
a
open
id
connect
and
the
jwt.
Basically,
with
this
token,
the
jwt
token,
any
ci
job
will
be
able
to
integrate
with
a
any
product
that
is
open
id
connect,
including
secret
management
provider
such
as
the
all
the
major
cloud
provider
and
different
cloud,
different
secret
management
solutions.
A
So
I
would
say:
hey
we
have
a
solution
here,
but
this
is
this
means,
first
of
all,
in
order
to
use
the
solution,
it
means
that
the
product,
the
product
that
you're
authenticating
against,
need
to
have
an
open
id
connect,
compatibility
which
is
okay,
most
product
does
have
it
today,
but
it
also
means
that
you
need
to
be
a
real
expert
on
retrieving
those
secrets.
A
This
is
not
a
native
solution
and
it's
very
hard
for
users
to
retrieve
secrets
using
the
jwt
token,
it's
doable
it's
possible,
but
it's
very,
very
challenging
and
you
need
to
be
you
need
to.
You
need
to
know
what
we
are
doing
like
even
in
gate
lab.
There
are
like
a
handful
of
people
that
know
how
to
authenticate
against
like
aws
using
the
open
id.
So
it's
a
it's
a
solution,
but
it's
not
a
solution
that
we
are
striving
for.
A
So
what
is
the
solution
that
we
we
want
to
have?
So
actually
I'm
gonna
move
this
here,
and
the
first
thing
is
to
allow
users
to
build
a
native
integration
with
a
different
third
party
tool.
As
I
mentioned,
we
do
have
today
in
a
native
and
easy
integration,
fairly
easy
integration
with
vault
using
a
secret
keyword.
So
just
like
one
keyword
that
you
use
and
then
automatically
we
are
doing
this
integration
and
we
have
the
ability
to
retrieve
cigarette.
As
I
mentioned,
we
don't
stop
here.
A
There
are
like
more
requirements,
for
instance,
support
volt
enterprise,
so
there
are
support
multiple
volt
instances
and
more
so,
even
when
you
are
building
a
native
integration,
there
are
additional
requirements
that
you
need
to
need
to
continue
work
and
also
you
need
to
maintain
a
disintegration
and
also
what
about
the
rest
of
the
of
the
tools.
So
I've
just
listed
like
the
major
cloud
provider,
but
there
are
there,
is
way
more.
A
There
are
always
you
know,
backlog
demand
for
additional
native
native
integration,
so
this
is
this
is
this
is
one
solution
and
it
doesn't
need
to
be
in
this
order.
Okay,
those
two
solutions,
I'll
talk
about
the
second
one
probably
need
both,
and
the
second
solution
is
to
create
a
built-in
secret
management
solution
for
ci
cd
job,
meaning
that
we
that
gitlab
will
have
a
way
to
securely
store
and
manage
secrets
within
gitlab.
A
So
it's
a
service
that
gitlab
will
provide
and
obviously
it
will
be
a
paid
feature,
but
basically
it
means
that
when
someone
is
entering
a
or
inputting
a
secret,
this
secret
will
be
encrypted
using
the
key
and
will
never
be
exposed.
And
I
mean
we
can
think
about
architecture.
But
I
was
thinking
so
this
ski
need
to
be
transmitted
to
a
to
the
platform
or
the
place
where
you
want
to
unlock
or
use
the
secret,
and
this
decryption
happens
there.
A
A
I
was
heavily
inspired
by
hashicorp
s1
and
they
are
that
is
attributed
to
volt,
and
I
was
very
conservative
about
okay,
we
can
look
at
what
volt
is
doing
and
take
half
of
the
of
what
what
hashicob
is
gaining
from
from
vault
and
regarding
the
rice
code.
I
was
also
heavily
inspired
by
the.
A
We've
done
a
lot
of
work
in
in
the
problem:
validation,
parts
of
the
we've
teamed
up
with
with
the
marketing
team,
primarily
erica
from
the
marketing
team
and
and-
and
we
have
done
a
lot
of
problem
validation,
a
lot
of
service
surveys,
user
interviews,
and
we
really
saw
the
pain,
the
challenge
and
the
problem
that
they
have,
and
so
this
is
how
I
gain
I
get.
I
got
the
the
reach.
A
The
impact
and
the
confidence
in
the
high
school
effort
is
something
that
we
can
probably
think
think
too
a
bit
more,
but
it
will
be
like
a
decent
effort
and
in
terms
of
the
business
question,
I
want
to
call
out
that
companies
that
offer
feature
like
that.
As
I
mentioned,
we
have
the
companies
that
provide
a
dedicated
secret
management
solution
and
also
the
major
cloud
provider.
A
No
one
really
have
like
a
built-in
secret
management
solution
who
has
built-in
secret
meta
resolution,
continuous
delivery
deployment
provider
octopus
deploy
harness,
they
do
have
a
way
to
increase
and
decrypt
value,
using
keys
and
integration
with
secret
management
solution
because
of
the
fact
that
they
need.
They
know
that
they
need
to
authenticate
against
against
different
platforms
in
order
to
deploy
their
application.
So
I
think
that
we
can
gain
a
head
start
if
we
start
thinking
or
working
on
a
built-in
secret
management
measurement
solution.
A
In
terms
of
the
evidence,
as
I
mentioned,
we've
done
a
lot
of
work
and,
as
I
mentioned,
I
want
to
call
out
the
kubecon
interview.
I've
been
there
in
person,
together
with
erica
and
we've
interviewed
many
many
users
and
and
and
customers,
and
we've
seen
the
problem.
We've
seen
the
pain,
even
the
orange
cto
that
came
to
our
booth,
the
the
city
of
I
think,
was
the
business
services.
A
We
they,
the
marketing
team,
interviewed
him,
and
he
spoke
about
secret
management
and
and
the
pain
that
they
have.
So
you
can
actually
see
it.
It
was,
it
was
all
over.
Secret
was
all
of
us,
so
this
is
definitely
a
a
pain
that
our
user
experience
today
and
something
that
we
can
definitely
think
about
to
provide
a
solution,
and
I
think
this
is
it
for
now.