►
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,
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.
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.
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
A
D
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
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
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
D
A
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.
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
A
A
C
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.
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
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
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
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.