►
From YouTube: Secrets Management Sync
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
A
When
I
first
joined
secrets,
management
was
exclusively
about
integrating
with
vault.
It
didn't
have
any
other
feature
functionality
included
in
it,
but
as
I
started
to
interview
users
and
start
uncovering
the
secrets
management
functionality
in
space
for
both
our
internal
users
and
external
users,
two
things
became
really
apparent.
People
are
using
environment
variables
for
secrets,
and
people
have
an
advanced
need
to
integrate,
with
a
variety
of
secrets
providers
to
manage
their
secret
capabilities.
A
So
with
that
in
mind,
we
built
out
the
first
integration
with
a
secrets
management
provider
to
vault,
and
then
we
increased
the
scope
of
secrets,
management
to
include
things
like
deploy,
keys
variables
and
any
sort
of
mechanism
that
allows
people
to
authenticate
with
an
external
system
that
then
stores
data
and
helps
them
run.
Processes
like
build
and
deploy
the
path
to
production
and
locking
it
down
is
typically
secured,
with
secrets
so
from
a
release
management
perspective.
We
were
really
about.
A
So,
with
vault
we
learned
a
couple
of
different
things.
We
learned
that
we
didn't
want
to
store
external
variables
inside
of
git
lab.
We
learned
that
it
would
be
really
expensive
to
bundle
git
lab
and
hashicorp
vault
together,
and
we
learned
that
people
want
to
only
use
their
existing
vaults,
so
they
don't
want
to
have
to
reconfigure
their
vaults.
A
I
asked
them
well.
What
would
you
need
to
remove
your
secrets,
management,
vault
provider
and
many
of
them
said
if
gitlab
had
native
capabilities
for
storing
masking
and
rotating
secrets,
I
could
abandon
all
of
my
secrets:
provider
capabilities.
A
This
is
like
a
really
long
term
horizon
vision
and
we
could
consider
using
some
like
hashicorp
vault
functionality
pieces
on
the
back
end,
but
that's
unbeknownst
to
the
the
user
like
they
would
be
using
git
lab
native
secrets
and
the
rotation
mechanisms
and
the
back
end
would
be
hashicorp
open
source.
But
they
don't
need
to
know
that
because
they
need
to
just
know
that
they're
using
gitlab.
A
That
definitely
needs
more
validation
and
more
pressure
testing.
But
it
would
also
empower
us
at
get
lab
to
dog
food
and
to
use
secrets
without
having
a
security,
vulnerabilities
and
risk
of
our
attack
surface
being
really
high.
A
As
we
started
down
the
path
of
how
do
we
make
really
robust
integrations?
We
learned
that
the
top
three
vaults
that
people
want
are
advanced
hashicorp
capabilities,
azure,
keystore
and
cyber
arc.
Cyber
arc
is
like
a
legacy
ugly
system,
but
it
is
the
primary
system
that,
like
governments,
financial
services,
regulated
industries
joined
like
15
years
ago,
and
they
haven't
gotten
rid
of
it.
So
as
we
start
to
look
at
our
go
to
market
motions
and
where
the
sales
team
wants
to
go,
cyber
arc
keep
comes
keeps
coming
up
in
those
in
those
industries.
A
So
that
might
be
something
that
we
want
to
pursue
down
the
road,
because
it's
it's
in
that
regulated
space.
It
has
an
immense
amount
of
tam
for
us.
A
I
would
say:
priorities
might
actually
be
cloud
native
key
stores
or
cloud
system
key
source
which,
in
my
mind,
is
like
azure,
aws,
gcp,
key
stores
and
providing
a
seamless,
robust
and
experience
with
all
of
those
cloud
provider
keystore
mechanisms.
We
can
use
the
same
jwt
across
all
of
those
with
like
different
authentication
mechanisms.
That's
what
we've
talked
about
before,
so
that
people
have
a
consistent,
can
use
multiple
key
stores
for
different
jobs
and
environments
inside
of
their
yaml
file,
because,
for
example,
they
may
have
secrets
for
different
test
environments
for
different
production
environments.
A
B
Yeah,
yes,
I'm
few
questions
that
I
have
so
I
don't
want
to
focus
yet
on
the
long-term
vision
about
like
building
our
own
secrets,
but
for
now
it
seems
that
we
need
to
integrate
with
multiple
10
different
tools
that
there
are
today
in
the
market,
and
the
question
is
like:
is
there
like
another
strategy?
B
A
So
when
we
were
exploring
this
hashicorp
vault
does
interface
with
all
of
those
different
providers,
but
it
requires
people
to
set
up
a
hashicorp
vault
instance
an
account
and
server
in
order
to
then
tap
into
all
these
other
key
stores.
So
that
was
a
high
friction
point
because
people
are
like
you
know.
I
don't
want
to
have
to
join
hashicorp
fault
in
order
to
then
integrate
with
amazon
gcp,
and
I
think
kubernetes
there's
al
there's
a
couple
of
others,
maybe
even
azure.
A
So
that
was
one
approach
was
like:
okay,
let's,
let's
build
out
our
hashicorp
vault
integration
and
make
that
so
seamless
with
git
lab
and
then
start
offering
easy
connect
or
easy
integration
ways
through
hashicorp
vault
to
these
other
key
stores.
Customers
really
turned
up
their
nose
at
that,
because
they're
like
well.
No
because
I
am
currently
using
aws
and
that's
what
I
want
gitlab
to
work
with.
B
A
Yeah,
so
when
we,
when
we
talk
to
customers
about
this
oftentimes,
the
secret
is
used
as
a
mechanism
for
granting
permission,
authentication
or
a
behavior
inside
of
a
different
place.
So
it's
like
an
action
driven
granting
access
into
a
different
different
segment.
So
this
can
be
someone
running
a
pipeline
that
needs
to
run
a
pipeline
at
a
different
location
or
a
different
project.
This
could
be
somebody
logging
in
via
api
into
an
external
system.
A
This
could
be
somebody
a
developer
that
is
deploying
and
pushing
a
change
that
needs
to
then
have
a
login
to
that
environment
that
they're
pushing
a
change
to
or
even
for
building
an
application
or
a
test
environment.
That
was
a
really
common
use
case,
where
people
needed
to
use
a
variable
in
order
to
build
a
test
environment
and
then
tear
that
down
and
delete
the
variable,
like
it
rotate
that
variable
so
there's
an
access
into
it.
A
So
the
biggest
difference
is
a
secret,
has
a
risk
associated
with
it,
because
it's
about
authenticating
and
granting
permission
to
perform
a
behavior
or
action,
whereas
a
variable
can
be
any
sort
of
coding.
So,
like
a
it's,
a
signal
that
gets
received
by
an
action
that
is
unsensitive
and
it
just
passes
information
through
for
the
system
for
the
software
to
then
conduct
that
behavior
action.
So
this
would
be
something
like
passing
and
injecting
a
variable
for
another
job
to
bump
a
version
in
the
release.
So
let's
say
that
it
wants
to
increment
versions.
A
What
would
come
back
out
in
your
in
your
payload,
there's
other,
like
mechanisms
with
variables
around
just
flexible
permissions
that
aren't
tied
to
a
user
that
are
tied
to
the
system,
interacting
with
the
system,
and
this
could
be
a
secret,
but
in
some
cases
like
because
it's
all
intra
system,
the
risk
is
really
low
and
there
isn't
a
user
seeing
that
some
things
that
we
see
are
like
bots
performing
actions
inside
of
a
project
and
writing
a
variable
into
a
project
to
denote
that
they've
done
something
so
adding
a
remediation
variable.
A
A
Another
thing:
that's
different
between
variables
in
general
is
and
secrets
is
like.
The
the
flexibility
of
what
people
want
to
do
with
variables
is
endless
like
there's
so
many
different
things
you
can
do
with
variables
when
you're
building
an
environment
where
you're
building
your
pipeline,
where
you're
executing
jobs
people
want
to
do
all
sorts
of
things
with
it.
So
we
have
to
keep
that
in
mind
that
it
needs
to
be
flexible,
that
people
are
doing
lots
of
scripting
with
with
predetermined
variables
with
variables
that
they're
adding
custom
variables.
A
So
that's
one
thing
that
I
learned
too:
people
do
store
secrets
inside
of
repositories
as
files
and
that's
a
little
different
than
as
variables.
Even
though
you
can
store.
There
is
a
there's,
a
variable
type
called
the
file
type
instead
of
repositories,
that's
definitely
a
bad
practice
and
like
we
don't
want
to,
we,
we
strongly
advise
against
people
storing
their
variables
as
files
and
or
secrets
secret
variables,
as
files
inside
the
repository.
A
B
A
Let
me
find
this
whole
landscape
issue
our
our
goal.
A
So
when
we,
when
we
first
started
exploring
secrets
management,
we
looked
at
it
from
a
couple
of
different
angles.
We
looked
at
it
from
what
are
people
who
are
doing
ci
doing
about
secrets,
and
what
does
this?
What
are
they
doing
like
to
support
secrets
in
their
tools?
A
So
this
particular
epic
compares
git
lab
jenkins,
claw
beads
bit
buckets
team
city
and
xevia
labs
and
the
dimensions
that
we
looked
at
were
if
they
had
masking
if
they
offered
encryption
at
rest,
if
they
offered
encryption
in
transit
and
if
they
had
dynamic
secrets,
which
are
like
auto
rotation
or
ephemeral
secrets,
or
you
know,
secrets
that
can
be
created
and
torn
down
within
a
within
a
job
based
off
of
what
you
have
scripted.
A
So
in
general,
as
we
start
to
see,
people
are
offering
variables
inside
of
their
tools
and
then
they
add
different
kinds
of
flexibility,
just
like
gitlab
did,
which
is
like
masking
and
encryption
at
reston
in
transit,
the
only
big
secrets
provider,
like
secrets,
management
provider,
that's
become
like
the
leading
tool,
for
this
is
hashicorp.
A
We
have
like
key
stores
for
each
individual
cloud
provider,
but
they
don't
have
the
same
robustness
that
the
hashicorp
vault
has
as
far
as
what
you
know
as
far
as
dynamic
secrets
as
far
as
encryption
as
far
as
flexibility.
A
B
A
So
masking
secrets,
protection.
A
By
project
by
group
by
person,
this
isn't
because
those
are
like
sensitive
variables,
but
they
are
gated
based
off
of
what
that
variable
can
do.
So
maybe
that
variable
runs
jobs
inside
of
a
production
environment
to
clean
up
after
something
has
happened.
Well,
they
only
want
certain
people
to
have
access
to
that.
Even
though,
like
it's
not
a
secret,
another
one
was
visibility
into
variables.
A
So,
right
now
you
can
inherit
variables
across
an
instance
a
group
project,
but
developers
don't
have
access
to
that
settings
panel,
so
they
can
have
variables
inside
of
their
pipeline
and
if
something
goes
wrong
like
if
that
variable,
for
some
reason
has
like
breaks
or
they're
no
longer
available
or
if
it's
like
has
something
that
that
upstream,
the
developer
can't
debug
that
so
they
have
to
then
seek
out
their
maintainer
owner
to
understand
like.
Why
is
my
job?
Failing
related
to
this
variable.
A
A
I
think,
like
that's
a
way
down
the
line
kind
of
thing
to
think
about,
but
it's
it
comes
up
whenever
we,
whenever
every
time
secrets
are
mentioned,
it
comes
up.
A
So
I
wrote
these
notes
under
native
secrets,
because
we
have
so
many
bugs
and
issues
with
how
current
variables
work
to
support
the
secrets
management
use
case
like
with
masking
and
with
protection
of
variables
and
limiting
access
that
we
are
so
constrained
on
how
we
can
support
those
use
cases
based
off
of
how
variables
work
today.
A
So
it
makes
it
really
hard
to
like
support
different
kinds
of
things
than
if
we
re-imagine
like
what
can
secrets
do,
but
that's
that's
it.
Those
are
the
four.