►
From YouTube: Secrets discussion: Michael/Veethika
Description
Feedback on the design proposal for secrets manager POC.
A
A
A
Then
we
had
many
reports
generated
from
that,
after
that,
it
was
followed
by
competitor
evaluation,
sketching
exercise
that
we
did
internally
with
the
team
which
has
its
outcome
stored
here
somewhere,
so
keeping
all
of
this
information
in
mind
and
like
bucketing
them
into
specific
sections.
This
is
what
we
finally
achieved.
So
we
figured
that
the
main
tasks
that
users
come
to
any
secrets
manager
to
perform
are
like
they
want
to
store
a
key.
A
Then
they
want
to
get
access
to
the
storage,
so
in
many
different
products,
this
concept
of
storage
is
different.
So,
for
example,
one
of
the
products
they
call
it
a
vault
and
someone
else
calls
it
like
something
else,
and
it's
like
a
place
where
all
the
keys
would
be
stored
and
they
would
have
policies
for
this
particular
place
separately.
A
So
it
was
also
up
to
us
to
like
how
we
want
to
be
envisioning.
This
particular
part
of
key
storage,
like
do
we
want
to
create
a
new
entity
where
all
the
secrets
would
be
grouped
or
do
we
just
want
to
go
with
the
kind
of
permissions
and
levels
that
we
have
today
within
gitlab,
and
just
sync
with
that,
then
comes
storing
a
key
of
course,
because
that's
what
this
is
for,
so
what
that
would
look
like
for
developers,
maintainers
and
admins
or
owners.
B
A
Extent
gets
extended
yeah,
they
have
access
to
then
preview,
a
new
secret
before
saving
and
for
maintainers.
It
would
be
pretty
much
like
the
same
that
developers
are
doing,
but
on
top
of
that
they
would
also
have
access
some
additional
access
to
these
two
actions,
additional
actions
and
then
moving
a
key
from
Project
to
group.
So
these
are
the
things
which
are
like
just
an
outline
that
we
are
not
100.
Sure
of
that
we
want
to
include
in
the
POC,
because
these
are
nice
to
haves
and
in
the
POC.
A
A
Yeah,
so
what
we
have
tried
to
like
create
here
is
right
now.
The
most
critical
feedback
that
we've
received,
even
like,
without
asking
sometimes
is
that
variables
are
very
hidden
like
for
something
that's
so
critical
to
Everyday
workflow.
They
are
in
a
very
hidden
location
and
we
don't
want
to
do
the
same
mistake
with
the
secrets,
especially
when
we
are
like
starting
off
with
it.
So
the
proposal
here
is,
to
probably
like
add
a
menu
item
in
the
navigation
in
the
main
nav,
which
would
be
for
both
secrets
and
variables
together.
A
So
once
a
user
gets
into
that,
they
would
see
two
sections
four
secrets
and
environment
variables.
There's
a
like.
There
are
two
tabs
available
for
that.
I
haven't
finished.
Writing
this,
but
I
just
wanted
to
put
across
a
message
that
why
users
should
be
choosing
secrets
and
under
what
circumstances,
and
how
they're
different
from
General
environment
variable
then
below
that.
If
there
are
secrets
that
are
existing,
they
would
see
a
list.
If
not,
then
there
will
be
an
empty
State.
A
That
would
like
encourage
them
to
create
a
new
one
and
like
get
started,
but
if
they
have
a
list
of
Secrets
already,
what
they
will
see
is
the
name
of
the
key
some
label
indicating
like
what
environment
were
they
created
for
and
I
have
added
inherited,
but
I'm
not
like
100
sure.
That's
going
to
be
very
helpful,
so
I'm
just
seeking
feedback
around
that.
So
this
is
to
indicate
that
a
secret
has
been
passed
down
from
a
parent
subgroup
or
group
to
a
project.
A
So
this
won't
be
available
for
the
table
in
the
groups.
Let's
say
then
some
information
about
when
it
was
last
used,
so
there's
a
feedback
that
instead
of
used
it
should
be
accessed,
and
that
would
make
like
it
more
clear
what
we're
trying
to
communicate
here.
So
when
it
was
last
accessed
by
any
of
the
environments
that
it
was
created
for
and
then
if
there
is
an
upcoming
rotation,
because
especially
for
developers,
this
information
is
very
relevant.
A
That's
what
we
learned
from
a
research
that
it
would
really
help
them
to
know
that
if
something
is
going
to
be
changed
right
after
they
have
decided
to
use
it
somewhere,
because
that
would
like
there'll
be
more
cautious
while
using
it.
Then,
apart
from
that,
I
really
wanted
to
give
some
sort
of
shortcut
here.
For,
for
example,
the
secrets
are
going
to
be
included
in,
let's
say
the
the
they
would
be
accessed
through
the
pipelines,
the
yaml
file.
A
So
if
we
can
provide
some
shortcut
to
copy
it
in
a
syntax
that
we
could
just
like
copy
from
here
and
paste
in
the
yaml
file,
making
it
easier
to
use
it
within
gitlab
and
or
like
a
shortcut
for
accessing
it
through
CLI
I'm,
still
like
seeking
feedback
around
it
because
I'm,
not
the
expert
here
and
I'm
looking
for
feedback
around.
What
are
the
things
that
would
make
it
easy
for
the
users
to
use
the
secret
when
provided
through
here
yeah
and
that's
for
the
list.
Then.
B
C
C
Somewhere
here
have
a
have
a
link
to
the
docs
so
that
I
can
learn
more
about
secrets
and
variables.
This
would
be
helpful
because
the
interface
shouldn't
be
bloated
with
too
many
explanations,
I
think
other
interfaces
or
other
fuse
in
gitlab
do
the
same,
having
some
some
documentation
linked
for
for
the
learning
async.
C
So
I
don't
know
if
the
the
search
allows
to
filter,
but
this
would
be
a
useful
filter
in
a
way
of
knowing
okay.
I
cannot
edit
this
at
this
level,
but
I
need
to
navigate
somewhere
else,
but
I
would
need
a
link
where
I
can
edit
it.
If
I
have
the
permissions,
so
this
would
be
kind
of
a
ux
workflow
I
would
expect
from
the
UI
hey.
C
You
cannot
edit
it
at
the
project
level,
but
here's
a
link
to
the
group
settings
or
instant
settings
or
something
like
that
which
could
be
like
adding
this
in
a
second
iteration
but
I
think
it's
great
to
see
all
the
variables.
But
there
should
also
be
like
maybe
a
button
or
a
predefined
filter,
removing
all
these
inherited
variables
and
only
show
the
show
shoulder
variables
which
are
defined
at
the
project
level,
because
if
you
have
a
lot
of
environment
variables
or
like
Secrets
being
defined,
this
could
bloat
The,
View
and
oftentimes.
C
C
C
B
C
I
also
would
love
to
have
a
way
that
it
doesn't
say
two
days
ago,
but
the
exact
ISO
date
and
timestamp.
So
I'm
not
sure
if
this,
if
this
uses
the
the
user
profile
settings,
but
it
should
so
that,
for
example,
the
issue
was
updated
two
days
ago
or
the
issue
was
updated
on
whatever.
Maybe
maybe
it
could
also
be
like
a
pop
over
text,
I
text
thing,
which
I
think
is
implemented
with
the
issue
issues.
C
C
C
B
C
Potentially,
it
makes
sense
to
like
ask
someone
from
the
application,
security
team
or
trust
and
safety
when
they
analyze
CI
CD
pipelines.
When
something
is
being
leaked
or
some
tokens
are
being
revoked,
they
can
provide
input
how
they
do
analyzes,
how
they
kind
of
work.
With
all
the
things
I'd
recommend
asking
Greg
Myers
from
the
absec
team.
C
Because
there
was
a
there
was
a
security
incident
for
some
developer
relations
projects
with
tokens
being
leaked,
and
that
would
be
interesting,
so
I
I
know
a
little
bit
how
they
do
it,
but
it
would
be
kind
of
interesting
which
tooling
or
how
which
processes
they
are
using
most
likely
the
API.
But
it
would
be
great
to
have
something
in
the
UI,
like
as
a
sequence,
management,
interface,
kind
of
question.
For
the
for
the
input
for
the
search.
A
B
B
C
A
copy
command,
I'm
thinking
of
the
agent
for
kubernetes
installation
method
right
now,
there's
a
pop
over
so
I
click
on
install
the
agent,
and
it
provides
me
with
the
copy
paste
share.
Snippet
and
I
could
imagine
that
a
similar
snippet
will
be
useful
to
say
here
is
developer
or
here's
the
I
don't
know
exactly
how
the
cicd
syntax
will
be.
A
A
C
C
Something
like
this.
This
is
not
rotate.
Rotated
is
something
else,
but
revoked
means
it's
still
there.
You
can
still
see.
You
can
still
see
it
in
the
history.
It's
probably
filtered
out
or
filtered
Away
by
default,
but
it's
not
deleted
and
then
probably
a
technical
discussion
needs
to
be
done,
whether
you
want
to
only
revoke
Secrets
or
you
want
to
delete
them.
So
this
is
something
to
be
discussed,
probably
with
users
and
customers
as
well.
B
C
C
A
secret
can
be
a
certificate
which
I
want
to
like
inject
into
into
the
cicd
Pipelines
from
the
current
ux
using
cicd
bevels,
for
example,
I
have
no
idea
how
to
add
a
TLS
certificate
which
I
can
then
using
in
my
kubernetes
cluster
in
the
ICD.
This
is
so.
The
form
is
complicated
and
I'm
I'm,
currently
not
sure
if
we
should
be
using
the
same
form
for
Secrets
as
we
do
with
cic
developers,
because
it's
like
a
generic
form,
but
maybe
there's
a
way
of
probably.
C
C
Yeah,
it's
like
I,
want
to
add
a
cicd
variable
and
I
have
the
the
possibility
to
to
select
file
instead
of
value,
which
then
allows
me
to
store
the
value
of
of
it
in
a
different
in
a
defined
file,
and
then
I
cannot
control
anything.
So
it's
yes,
probably
the
the
creation
form,
which
needs
to
be
not
generic
but
really
tailored,
on
which
type
of
secret
is
is
being
being
added.
Okay,.
A
A
We
are
not
providing
the
option
to
protect,
mask
expand
because
a
we
don't
want
to
expand
like
we
expand
variables.
B
there's
going
to
be
an
encryption
by
default,
that's
going
to
be
superior
to
what
we
provide
for
environment
variables,
so
yeah
I
would
love
to
hear
from
you.
What
do
you
think
about
this
club.
C
C
So
anything
I
kind
of
need
to
to
store
in
my
secrets,
management
should
be
I
should
be
able
to
either
select
it
from
a
drop
down
or-
and
this
is
great
in
in
one
password-
you
copy
paste
and
SSH
key
into
the
form
and
it
automatically
detects.
Oh,
you
have
pasted
an
SSH
key
I'm,
selecting
the
type
for
you.
This
could
be
like
future
iteration,
instead
of
instead
of
having
a
drop
down
for
the
user.
B
C
I
I
was
lazy
in
my
in
my
previous
life.
I
never
stored
my
credentials
in
a
password
manager
also
at
the
credentials.
Yes,
but
not
my
SSH
key
and
all
my
tokens,
and
it
would
be
great
if
the
the
ux
or
the
UI
had
some
some
sort
of
detection
hey.
This
is
an
AWS
key
or
hey.
This
is
an
SSH
key,
less
certificate
and
just
need
to
look
into
my
one
password.
C
What
other
types
are
whatever,
because
then,
when
I
have
when
I
know,
the
type
I
could
also
offer
the
user
some
pop-ups
or
some
help
with
this
looks
like
an
AWS
key.
Maybe
you
want
to
consider
adding
security
scan
secret
scanning
to
gitlab
cicd
to
be
to
automatically
detect
if
something
is
being
leaked,
for
example,
could
be
in
an
overlap
with
the
secure
stage
or
the
secure
section.
B
C
I
think
SSH
key
and
and
some
other
thing,
API
credential
is
not
the
same.
So
maybe
some
sort
of
type
Secrets
type
should
be
available
in
the
back
end,
so
like
as
a
database
column
and
the
the
front
end
should
should
probably
provide
a
drop
down
or
like
a
I.
Don't
I,
don't
know
exactly
I,
don't
like
Drop
dance,
maybe
something
to
being
able
to
select
that.
B
C
Yeah,
probably
something
like
that:
I
don't
want
to
like
I,
don't
want
to
have
it
over
complicated
I'm,
just
thinking
of
how
I
started
using
sequence
managers-
and
sometimes
it's
not
like
a
username
password
combination
but
like
something
else
and
after
one
password
detected
that
it's
like
an
SSH
key
for
the
first
time.
I
thought
of
hey
this.
This
would
be
nice
because
from
there,
if
you
know
the
type,
you
can
offer
more
Integrations
with
ingitlab
itself.
B
C
Other
than
that
you
mentioned
that
there
are
filters
that
there
are
labels
in
The
View
when,
when
like
listing
the
secrets,
I
would
love
for
the
user
to
be
able
to
to
add
my
own
labels,
maybe
use
the
same
way
of
using
issue
and
merge
request
labels
or
epic
labels,
especially
for
scope.
Labels
could
be
interesting,
but
some
sort
of
tagging,
which
then
can
also
be
used
for
for
filtering
the
secrets.
This
will.
B
C
A
C
The
access
permissions
are
great,
I,
think
I,
don't
know
exactly
how
How
Deep
The
permission
management
will
go,
but
I
could
imagine
something
similar
to
Asia
cupboard
or
to
access
yeah.
Probably
the
role.
For
example,
when
I
see
ICD
job
is
running
if
I
triggered
the
job
as
a
developer.
I
cannot
get
access
because
the
secret
is
reserved
for
maintainers,
for
example.
So
this
this
I
think
is
a
it's
a
use
case.
Right
now,.
B
C
Think
hashic
Club
world
has
some
more
far
more
fine
granular
permissions
on
how
Secrets
can
be
accessed,
oh,
like
with
oidc
and
I'm
I'm,
not
a
hundred
percent
and
knowledgeable
in
in
that
area.
But
when
a
specific
attribute
is
being
presented
or
something
with
oidc,
then
I
trust
or
then
this
secret
can
be
trusted.
C
A
C
C
C
A
A
C
Probably
the
technical
background
needs
to
be
decided
whether
it's
an
and
or
an
or,
and
then
the
UI
needs
to
be
built,
but
because
I,
this
permission
building
in
the
UI
can
get
quite
confusing.
If
you're
combining
multiple
filters,
so
I
would
I
would
start
like
the
discussion
of
what
are
the
filters
in
the
background
and
then
try
to
model
model.
The
UI
for
that
I
know
that,
because,
in
my
previous
open
source
project,
we'll
try
to
create
awesome
filters
which
worked
on
the
CLI,
but
the
UI
was
horrible
to
build.
C
C
So
I'm
I'm
confused
that
this
is
here
now,
because
my
my
next
question
would
be
I
want
to
edit.
This,
so
I
would
leave
it
away
in
the
in
in
the
preview,
but
maybe
there's
a
way
to
to
access
the
token
in
all
its
Rd,
the
secret
in
all
its
detail,
like
read-only
view,
or
something
or
like
a
few
for
for
the
maintainer
who
needs
to
see
everything
but
for
the
preview
I
would
I
would
love
to
see
everything
which
which
to
form
above
provides
in
that
order.
C
Yeah
I'm
not
sure
about
this
here,
I
come
out.
I
think
it
could
be
helpful,
but
some
users
can
be
confused
about
hey.
You
need
to
create
it
first
and
then
you
can
copy
paste
it,
but
I
couldn't
understand
if
someone
has
multiple
tabs
open
and
they
want
to
continue
editing
the
CI
CD
configuration
and
validate
it
and
then
create
something.
C
C
This
could
be
a
workflow,
so
I
think
like
showing
how
it's
being
done
in
with
the
Yammer
could
could
be
a
great
way
to
encourage
users
to
learn
more
about
it.
Maybe
just
linked
also
talk
to
the
cicd
documentation
or
getting
started
to
tour
and
something
like
that,
or
maybe
there's
a
there's,
a
section
in
the
docs
for
adding
secrets
to
CI
CD
created
for
this
MVC.
B
A
A
A
C
Yeah
and
sometimes
it's
required
that,
for
example,
a
maintainer
of
a
project
can
specify
the
same
variable
but
with
a
different
value
and
it's
a
secret
because
you
need
to
test
something
or
this
specific
project
lives
in
a
different
network
area.
And
let's
make
something
up.
The
the
AWS
secret
needs
to
be
different
because
permissions
over
there
or
company
like
violence
since.
C
Think
I
think
for
compliance
reasons,
it
makes
sense
to
say
nobody
can
override
it.
We
are
defining
it
at
the
group
level,
but
if
there
is
like
the
the
the
the
the
there's,
a
request
from
from
users,
I
need
to
test
something:
I
am
creating
an
access
request,
so
I'm
creating
an
issue
to
document
this
exception,
so
that
I
can
use
a
different
value
for
that.
C
C
Maybe
a
color
makes
sense.
I,
don't
I'm,
not
100
sure
about
user
information,
but
it
could
be
the
default
filter
by
created
like
similar
to
to
the
issue
listing
you
have
created,
as
as
a
sorting
filter,
you
have
updated,
which
updated
can
be
last
accessed,
for
example,
so
kind
of
providing
a
similar,
a
similar
workflow.
How
you
use
the
filtering
and
the
Sorting
like
merge,
request
issues
and
epics.
C
I
do
know
that
it's
sometimes
a
back-end
thing
or
second
problem,
but
as
a
user
I
would
love
to
have
some
like
picture
nature.
Patchy
mated
fuse,
so
that
I
can,
for
example,
bike
select
the
first
page
or
back,
select
everything
and
do
something
with
it.
In
the
case
of
emergency,
for
example,
which
again
is
is
a
thought
for
more
the
security
focused
persons
or
something
let's
make.
Let's
make
it
up,
we're
leaking
all
the
gitlab.com
secrets
from
our
from
our
groups
for
some
reason.
A
C
C
B
A
B
A
Yeah
I
mean
when
I
he
after
reading
the
feedback
that
I
also
received
from
my
team
I'm
thinking
that
maybe
this
is
not
a
great
idea,
because
there's
also
a
need
for
showing
an
audit
Trail
for
audit
logs
for
the
secret
usage.
And
it's
going
to
make
this
page
like
so
much
more
complicated.
So
I
think
I'm
going
to
go
back
to
secrets
and
variables
being
two
different
pages.
C
Secret
is
like
security,
which
might
not
always
fit
into
CI
CD
or
in
the
build
in
the
build
menu
which
is
like
the
new
menu
I,
see
Secrets
more
in
the
secure
and
the
government
stage
and
I
think
I
mean
in
the
beginning.
We
are
working
on
cicd
rivers
to
make
them
more
secure,
but
I
could
also
use
Secrets
Management
in
gitlab.
Without
pipelines.
I
could
be
using
it
as
a
way
to
manage
my
infrastructure
as
code
or
something
like
that.
C
C
I
would
love
to
integrate
one
password
and
hashic
up
World,
similar
to
like
using
gitlab
Secrets
management,
but
I
also
would
love
to
just
what
I
was
also
would
love
to
just
use?
Gitlab
sequence
management,
nothing
else
and
if,
if
it
doesn't
provide
all
the
features
yet
I
can
still
either
contribute
because
it's
open
source
and
open
core
or
like
create
a
feature
request,
and
we
can
collaborate
on
that.
C
A
C
And
I
was
thinking
about
this
before,
when
you
mentioned
the
scope
of
project
or
the
I
want
to
manage
secrets
on
the
project
level.
I
think
that
makes
sense,
but
the
default
should
be
managing
at
the
group
level,
at
least
for
the
gitlab.com,
SAS
and
also
yeah.
The
responsibility
for
instance-wide
Secrets
depends
depends
who
has
access
to
to
which
things?
C
So
the
reason
why
I'm
thinking
this
is
I'm
not
super
happy
with
the
instance
group
and
project
level
way
of
managing
Secrets,
because
sometimes
they
don't
fit.
Sometimes
you
want
to
give
access
to
a
specific
secret
to
a
multitude
of
groups,
some
projects
or
some
some
predefined
label
or
filter
whatever
is
provided,
but
this
is
far
too
advanced
now
I'm,
just
like
thinking
of
I
think
in
the
beginning,
it
would
be
great
to
have
Secrets
Management
on
the
group
instance
and
project
lever,
but
not
within
variables.
A
C
And
yeah
I
think
we
can
reuse
certain
ux
elements,
forms
and
all
the
things,
but
I'm
I
fear
that
we
might
block
ourselves
from
like
using
all
the
same
interfaces
in
the
same
view,
because
when
you're
in
the
same
menu
item
in
the
menu
view,
you
kind
of
need
to
use
the
same
workflows
and
the
forms
need
to
I
think
they
need
to
follow
the
same
behavior.
Otherwise
I
would
get
confused.
But
if
I
know
that
I'm
now
in
the
secrets
area,
I
could
be
having
like
see
at
the
overview.
C
I
could
be
having
the
the
lock
the
audit
log
and
what
else
Integrations,
for
example,
because
I
want
to
integrate
with
one
password
or
with
hashicab
world,
and
this
tab
tells
me
how
to
do
it
or
shows
me
what
is
actually
integrated.
If
we're.
If
we
build
that,
invariables
could
be
yeah
the
overview
usage
count
from
from
sub
projects.