►
From YouTube: RBAC - Connecting permissions to associated groupings
Description
Sr. Product Designer Daniel Mora walks through the work being done to move our RBAC project forward. Currently GitLab permissions are individual permissions with no linking to associated permissions. This work will look to link logical permissions and group them to reduce confusion as we move forward with our RBAC project.
See issue link: https://gitlab.com/gitlab-org/gitlab/-/issues/374089
#GitLab #RBAC #permissions #authorization
A
Hi,
my
name
is
Daniel
Moore
I'm,
a
senior
product
designer
with
the
authentication
and
authorization
group
within
the
manage
stage.
Gitlab
and
I
wanted
to
go
over
a
project
I'm
working
on
regarding
our
permissions
model.
The
issue
linked
is
this
one
connecting
permissions
to
Associated
groupings,
so
this
work
is
being
done
as
an
effort
to
consolidate
our
permissions
table.
As
an
example
you'll
see
here
in
documentation,
our
permissions
looks
sort
of
like
this.
It
just
has
a
list
of
permissions
and
then
which
role
has
access
to
that
permission.
A
So
what
we
have
initially
done
in
the
rbac
design
pod,
my
co-worker
Amelia
actually
had
gone
through
the
whole
table
and
then
categorized
the
permissions
into
these
primary
categories
so,
for
example,
namespace
repository
product
management,
etc,
etc,
and
as
I
went
through
the
Prototype
building
process.
I
realized
that
there
was
a
bit
of
an
issue
where
you
could
disable
a
particular
permission,
but
that
did
not
reflect
in
the
rest
of
the
permissions.
A
So
as
an
example
view
project
code
is
one
in
particular
where
it's
just
a
one.
Individual
light
item.
Excuse
me
one
individual
line
item.
However,
if
you
were
to
disable
this
one
permission,
then
functionally
you
would
no
longer
have
access
to
merge,
requests
or
anything
else
that
touched
project
code,
so
these
don't
necessarily
have
a
linking
system.
A
So
I
went
through
and
dropped
those
into
a
sub
section
of
view
namespace
as
you'll
notice.
There's
a
number
of
items
that
have
sub
items
so
in
this
case
view
insights,
there's
one
that
says
view
Insight
charts.
So
again,
the
idea
is
that
if
I
were
to
disable
this
feature
of
viewing
insights,
I
should
actually
disable
this
one,
as
well
as
a
unified
permission.
A
A
A
Another
example
here
is
the
edit
settings.
So
if
I'm
in
a
namespace
and
I
go
to
the
settings,
if
I
disable
the
ability
to
edit
settings,
I
should
no
longer
be
able
to
edit
badges
Samuel,
SSO
change,
visibility
of
the
of
the
project
or
the
group,
or
feature
visibility,
and
all
these
other
Associated
permissions.
A
What
I'm
doing
is
again
going
through
all
of
the
topics
above
here
as
an
example
and
then
re-categorizing
them.
So
in
the
next
step
here
we'll
look
at
repository
and
as
I
mentioned
earlier
view,
project
code
is
the
primary
permission.
So
again,
if
I
were
to
disable
this
one,
then
everything
underneath
it
should
be
prevented,
and
so
this
is
sort
of
what
I'm
working
on
for
repository
I
have
a
number
of
questions
that
I'm
addressing
with
some
of
the
team
members
to
try
and
understand
the
relationships
on
these.