►
From YouTube: GitLab permissions consolidation discussion 2022-11
Description
Authentication and Authorization teem meet to discuss concerns around consolidating permissions in GitLab for our new customizable RBAC project.
See related issue for more detail: https://gitlab.com/gitlab-org/gitlab/-/issues/374089
#GitLab #RBAC #permissions
A
So
the
idea
that,
let
me
go
back
to
the
screen
share
again
if
I
look
or
if
you've
seen
the
Prototype
before,
where
they're
just
individual
line
items,
this
UI
doesn't
account
for
the
groupings
that
we're
talking
about
over
here,
so
I
haven't
designed
a
flow
or
an
interface
to
interact
or
make
these
interactions
linked
or
grouped
so
I
wanted
to
know
what
is
the
technical
ability
for
us
to
do
that
in
the
front
end,
perhaps
with
without
a
visual
presentation.
A
So,
for
example,
if
I
were
to
select
an
item,
would
then
we
could
automate
that
process
to
then
go
through
the
rest
of
these
and
click
as
well,
or
would
that
not
make
any
sense,
I
kind
of
feel
it
like
that's
a
bad
UI,
but
the
reason
I
bring
it
up
is
because
I
am
concerned
that
this
process
to
design
a
redesigned
interface
for
this
might
take
too
long
and
y'all
will
get
ahead
of
me
and
not
have
any
sort
of
work
to
do.
While
I'm
trying
to
figure
out
some
sort
of
visual
for
this.
B
A
Okay,
so
I'll
give
an
example
here
in
our
current
environment.
All
of
these
are
just
individual
line
items
that
are
not
necessarily
linked,
but
arguably,
if
I
were
to
say,
give
it
a
grouping
or
an
inheritance
logic.
None
of
these
would
exist
if
I
were
to
disable
view
namespace.
So
if
I
uncheck
this
view
namespace
permission,
then
all
of
these
on
this
column
and
underneath
would
then
also
be
blocked.
A
A
Right,
so
the
arrow
would
indicate
it
grouped
to
that
like
a
logical
grouping
where
view
namespace
is
tied
to
all
of
these,
but
view
building
can
stand
on
its
own
right,
it
doesn't
necessarily
have
a
relation
to
the
namespace.
It's
a
external
process,
similar
to
like
view
project
code
right,
there's
all
these
subordinate
permissions
that
are
tied
to
project
code
like
merger
Quest
also.
A
Would
it
make
sense
to
just
link
these
by
clicking
one
and
then
the
others
associate
with
that
I,
don't
know
if
that
makes
sense
or
not,
but
so.
C
Yeah,
so
just
to
clarify:
do
we
have
a
an
some
kind
of
limit
on
the
on
the
nesting?
So
how
deep
can
we
go
with
the
groups?
Because
if
we
travel
like
one
and
it
like
opens
a
bunch
of
other
than
toggle
another
one
and
it
opens
like
yet
another
group
I
wonder
if
there's
like
any
kind
of
limit
on
the
level
of
nesting
here.
A
B
Yeah,
it's
hard
to
say,
like
I,
think
the
easiest
thing
from
our
perspective.
Well,
I,
don't
know
if
this
is
easiest,
but
I
guess
like
just
kind
of
thinking
out
loud
here
about
how
I'm
seeing
this
like
all
of
these
different
pieces.
If
we
just
created
a
really
long
list
and
just
said
check
all
these
boxes,
that
feels
like
kind
of
like
the
dumb
solution,
like
maybe
a
different
like
difficult.
You
know
like
that's
what.
A
Yeah,
because
this
is
just
be
paid
after
page
permission
and
then
the
idea
was,
we
would
have
like
a
search
bar
up
here
for,
like
a
specific,
oh
I
want
to
query
just
as
one
permission,
but
that's
the
problem
that
if
I
disable
view
project
code
as
a
permission,
and
then
all
of
these
other
have
to
be
disabled
as
well
same
with
this
they're,
not
Linked,
In,
This
UI
in
this
prototype
and.
A
A
D
D
Actually,
let
me
ask
that
so
the
level
three
permissions
they
can
be
from
like
another
feature
right
there
are.
Are
they
all
group
per
future?
Well.
D
A
So
this
is
my
only
reference
in
regarding
permissions
and
there
is
no
grouping
so
to
speak.
They're
just
line
items
now
how
that's
manifested
in
the
in
the
code,
perhaps
Jesse
and
Emory.
You
can
describe
that,
but
as
it
stands
here,
they're
just
individual
items
and
there's
no
like
information
on
their
grouping.
Apart
from
like
it
says,
repository
for
these,
but
I,
don't
think
that's
a
logical
grouping.
I
think
that's
just
a
descriptor
in
this
documentation,
so
people
know
understand
I.
D
A
Here's
a
link
to
the
docs
if
you're
curious
and
that's
essentially,
what
I'm
trying
to
understand
is
that
what
are
the
impacts?
First
of
all
to
the
code,
where
you
have
to
make
these
groupings
what
sort
of
things
what
sort
of
features
are
going
to
break
and
what
sort
of
connections
need
to
be
done
in
the
code
to
maintain
integrity
and
not
cause
problems
to
where,
if
I
say,
I
click
view,
project
or
disable
project
viewing
project
code.
Everything
connected
to
that
functionally
attaches
to
that
as
well.
C
B
I
was
gonna
say
in
terms
of
like
the
feature
like
one
thing:
I've
been
thinking
about
in
terms
of
these
buckets
is
I
feel
like
what
I'm
seeing
Daniel
is
creating
logical
buckets,
but
I
actually
initially
thought
that
we
weren't
just
going
to
create
logical
buckets
that
we
were
actually
going
to
be
merging
more
permissions,
so
like
reducing
the
number
of
permissions
that
are
in
the
list,
which
I
still
think
could
be
very
valuable
like
as
opposed
to
creating
a
Cascade
like
just
saying,
hey,
we
have
60
permissions
now.
B
Can
we
get
that
to
30,
because
custom
rolls
is
going
to
make
it
very
difficult
to
make
changes
to
our
permission
scheme
right,
because
if
we
start
allowing
people
to
configure
each
of
these
60,
we
can't
just
take
them
away
because
they
think
they've
signed
somebody.
Something
like
we're.
Gonna
have
to
have
like
a
forwards,
compatible
Backward,
Compatible
apis,
basically
in
terms
of
the
list
of
permissions.
B
A
That
that's
exactly
what
I
was
thinking
and
I'm
glad.
You
brought
that
up
because
from
the
discussion
we
had
before
the
recording,
let
me
go
share
the
screen,
so
I
can
show
a
deal.
What
we
were
talking
about,
permissions
that
are
nonsensically
disconnected
so
as
a
reason
or
as
an
example
here,
change,
visibility,
level
and
change
feature
visibility,
level.
These
feel
like
they
should
just
be
one
thing,
but
there
might
be
something
that
we're
not
looking
at
on
the
UI.
A
There
was
one
other
one
that
was
more
direct
but
like
view
pipeline,
page
or
View,
and
then
view
pipeline
Details
page,
why
are
these
two
separate?
Logically?
They
don't
make
any
sense
to
be
separate
so
merging
these
makes
perfect
sense
right
and
that's
kind
of
what
I'm
looking
at
is
that,
where
are
these
other
sorts
of
links
that
can
be
merged
into
a
unified
single
permission
to
reduce
this
right,
and
this
makes,
in
my
opinion,
it
makes
total
sense
to
just
make
these
all
one,
but
that's
kind
of
where
I
was
hoping.
A
D
So,
okay,
so
100,
agree,
I
think
we
should
definitely
do
that
as
a
step
one
to
make
our
lives
easy.
Two
I
think
it'll
be
a
bit
about
so
we'll
find
out.
D
Some
of
them
are
just
like
name,
because
someone
named
permission
differently
than
the
featured,
and
now
we
have
two
but
I
suspect
in
a
lot
of
cases,
there's
going
to
be
a
Nuance
for
like
okay,
I
didn't
want
admins
to
see
pipeline
Details
page
so
I
created
a
permission
just
to
manage
that
and
the
only
one
who
may
be
able
to
tell
that
with
reasonable
confidence
is
like,
for
example,
the
release
team
for
CI
CD
or,
like
those
individual
teams,
I,
don't
know.
A
Yeah
I
I
definitely
tagged
the
people
in
that
team
and
they
basically
have
the
same
agreement
that
there's
no
reason
that
they
should
be
different,
so
I
think
we're
safe
to
start
merging
stuff,
but
that's
kind
of
like
where
I
wanted
to
make
sure
that
your
team
knew
which
links
to
merge
right
and
that's
kind
of
what
I'm
doing
this
whole
mapping
exercise
for
us
to
see
what
these
groupings
are.
These
linkings
are:
are
they
logical
and
what's
missing
or
what's
not
connected
the
big
one?
A
For
me
was
example:
let
me
go
over
here
to
start.
First
repository
was
one
and
then
merger
Quest
was
separate,
but
then
that
doesn't
make
any
sense
in
this
case
they
are
connected
and
that's
what
I
wanted
to
do.
This
mapping
exercise
for.
D
A
A
I
want
to
keep
asking
across
the
organization,
and
perhaps
maybe
you
can
you
three
can
help
me
where
else
I
can
tag
or
post
this
for
more
feedback
across
the
organization,
specifically
I
guess
the
issue
that
y'all
are
working
on
from
the
technical
side,
just
because
I
want
to
have
more
developers
eyes
looking
at
this
problem,
because
it
is
such
a
colossal
project
and
it
does
touch
every
feature
in
the
platform
and
if
we
start
taking
a
hammer
to
stuff
and
someone
complains
that
we
broke
something
it's
like
well,
we
told
you,
we
asked
you
for
input
right.
A
You
know
these
sorts
of
questions.
I
want
to
stop
before
they
arise
right.
C
Yeah
I
think
the
the
best
approach
is
to
bring
the
individual
teams
on
the
on
the
issue
on
the
Epic
page.
I.
Think
one
of
the
difficulty
from
the
codebay
perspective
is
that
these
permissions
are
also
independent.
So
even
if
there's
a
hierarchy
between
I
think
you
showed
the
pipeline
page
and
the
pipeline
Details
page.
So
these
are
like
usually
a
completely
unrelated
and
there's
like
no
hierarchy
within
the
permissions.
C
So
I
I
remember
like
seeing
a
bug
report
that
I
think
like
read,
project
wasn't
granted
but
I
think
the
maybe
the
merge,
requests
or
the
pipelines
are
still
visible
via
the
API,
because
there's
literally
no
hierarchy
between
the
two,
so
even
though
read
project
was
revoked,
the
user
could
like
still
access
the
the
pipelines
or
something
else,
because
because
there's
no
hierarchy
between
the
permissions
in
the
code
base.
A
B
There
is
kind
of
like
an
implicit
hierarchy
right
because
it's
like
well,
we
everybody
has
a
role
to
access
things,
I
guess
or
they
have
an
access
token
with
a
certain
scope
and
that
lets
them
do
certain
things,
and
so
we
we
can
kind
of
logically
group
them
currently
because
of
the
static
roles,
and
so,
like
that's
I,
guess
it's
a
safer
place
to
start
now
than
if
their
custom
roles
and
people
are
just
like.
You
know,
cherry
picking,
permissions
into
custom
roles
that
gets
messy.
B
Then,
if
something
currently
belongs
to
get
a
guest
has
this
one,
but
not
that
one
right,
because
we
don't
want
to
change
the
access
that
our
current
static
permissions
have.
So
in
this
page,
for
example,
we
wouldn't
want
to
merge,
add
tags
to
repository
and
view
a
commit
status,
because
the
reporter
has
one
but
not
the
other.
So
if
we
merge
them,
then
we'd
have
to
decide
we'd
have
to
change
the
meaning
of
reporter.
B
So
that's
something
to
consider,
but
anything
that
any
permissions
that
are
currently
grouped
for
a
role
should
be
safer
to
merge
because
we're
not
going
to
be
changing
the
Status
for
or
the
access
I
should
say
for
existing
users.
So.
A
B
Yeah
I
think
that
would
be
never
want
to
use
the
e
word
easy
and.
C
Yeah,
there's
also
sometimes
happened
that
this
table
is
incorrect.
Yeah.
A
C
Also
need
to
account
for
documentation
error
as
well.
C
And
sometimes
there's
like
even
more
tricky
so
so,
for
example,
like
the
the
UI
one
of
them
is
enforced
and
correct,
but
via
the
API,
it's
a
little
bit
different.
So
there's
that.
A
A
A
So
I
don't
think
we
need
an
answer
for
today,
but
I
wanted
to
apprise
you
all
of
the
status
of
the
work
that
I'm
at
right
now
and
get
your
feedback
on
what
I
should
be
looking
at
or
what
I
should
be
focusing
on.
So
I
think
the
idea
of
grouping
things
and
reducing
the
the
number
of
permissions
is
a
good
first
step
or
to
continue
what
I'm
doing
in
this
grouping
exercise.
A
For
me,
I
think
what
I
want
to
do
is
finish
that
the
first
round
of
the
grouping
and
then
kind
of
do
like
walkthrough
videos
for
each
section
kind
of
explaining
my
logic
and
reasoning
for
that
and
make
that
public.
So
everyone
can
look
at
it
and
we
can
pass
it
around
the
organization
to
see
to
make
sure
everyone
else
is
seeing
the
same
work
that
we're
all
doing
and
use
that
as
a
as
a
start
for
some
dialogue.
A
For
these
cases,
where
more
senior
or
older
people
who
have
been
in
the
organization
for
longer
can
say
no,
no,
you
can't
do
that
because
of
whatever
reason,
I
think
that'll
be
my
first
or
my
next
steps.
A
B
I
was
going
to
ask
amra
if
he
thought
in
terms
of
this
consolidation
like
would
it
make
sense
to
do
kind
of
like
a
first
Mr
just
like
try
to
merge
two
permissions
and
see
how
that
goes
because
in
my
mind
it
sounds
easy,
like
once,
we've
identified,
which
ones
to
merge
I'll
just
merge
them,
but
I've
never
done
that.
So
I
have
no
idea
if
I'm
just
oversimplifying.
A
That
feels
like
a
good
MVC,
like
that
example
of
like
viewing
pipelines,
but
I,
don't
know
we
want
to
do
a
failure.
Analysis
first.
C
Yeah
I
think
I
think
it
makes
sense
and,
and
probably
the
case
will
be
different
from
time
to
time
from
permission
to
permission.
So
this
is
the
for
example.
The
the
example
I
I
mentioned
prior
to
the
recording
is
is
when
we
created
the
the
create
granted
create
project
to
to
developers,
and
then
we
figured
out
hey,
there's
a
there's,
a
lot
of
dependency
to
the
developer,
to
be
able
to
like
create
the
the
the
the
project,
because
it
also
requires
push
code
and
all
the
others.
C
So
I
I
think
we
cannot
like
really
assess
the
entirely.
How
can
we
consolidate
the
the
permissions
I
think
this
first
identifying
the
first
steps
is
the
best
approach,
but
we
need
to
like
start
working
and
experimenting
with
these.
Basically
as
soon
as
possible.
D
Daniel
for
structuring
some
of
that,
so
one
I
agree
with
it
and
I
also
realize
this
is
a
large
effort.
Very
large
effort.
Is
there
a
value
in
for
every
permission
that
we're
consolidating?
We
just
create
an
issue,
tag
the
team
and
say:
okay,
we
are
going
to
go
ahead,
consolidate
these
two
approve
or
hold
your
tongue
forever,
and
then
we
prove
at
least
one
or
two
of
them
and
then
over
time
we
can
Outsource
it
to
other
teams
as
well.
D
So
that
way,
there's
kind
of
a
breadcrumb
of
how
we
got
here
and
also
kind
of
forces
us
to
think.
Oh,
maybe
there's
some
sort
of
feature:
toggle,
backup
functionality.
We
can
use
to
roll
out
the
merge
permissions
to
a
smaller
group
of
people
and
if
it
really
catches
fire,
we
toggle
it
off
and
it
goes
back
to
distinct
permissions.
A
A
This
is
the
one,
let's
all
pass
it
around.
Anyone
have
feedback
on
this
and
then
kind
of
there's
a
word
for
it
and
I
totally
forgot
the
word
and
I
can't
speak
English,
make
a
process
for
every
or
other
group
or
stage
to
do
this
on
their
own,
because,
obviously
this
is
a
lot
of
work
and
everyone
should
be
involved
in
the
process,
especially
just
by
the
nature
of
all
the
features.
We're
touching
so
having
a
US
make
a
process
for
that
starting
off
of
a
simple
one,
makes
perfect
sense.
B
A
That
makes
perfect
sense,
also
like
I
said
or,
like
you
said,
the
if
something's
going
to
go
away
because
it's
merged
there's
no
point
in
making
a
grouping
for
it,
but
that
goes
back
to
what
I
was
saying
earlier
about.
What
is
the
MVC
on
the
UI
for
this
right?
A
Do
I
just
leave
it
the
Prototype
that
I
have
and
we
go
forward
with
making
changes
as
we
go
iterate
on
this
process,
because
we're
not
going
to
turn
on
the
entirety
of
the
interaction
of
the
permissions
table
for
the
time
being
and
I
guess
now
that
I
speak
it
out
loud.
It
makes
perfect
sense
to
just
leave
it
alone,
because
they're
only
gonna
be
one
permission.
Every
time
we
make
an
iterative
change,
so
it
won't
be
so
chaotic.
A
Cool
well
I
think
that's
everything
I
needed
did
anybody
have
anything
to
add.
A
A
If
not,
maybe
we
look
at
something
else.
That's
a
grouping,
as
you
described
like
merging
permissions,
one
with
a
low,
a
low
blast,
radius.