►
From YouTube: Pipeline permissions - defining the problem to solve
Description
Discussion on the issue "Make pipeline permissions more controllable and flexible": https://gitlab.com/gitlab-org/gitlab/-/issues/35067
A
Okay,
so
what
I
wanted
to
do
at
this
session
is
talk
about
the
make
pipeline
Commission's,
more
controllable
and
flexible
issue.
There
is
a
part
of
the
issue
description
that
talks
about
is
under
the
proposal
of
what
does
the
design
should
be?
Basically
what
the
users
experience
should
be,
and
specifically
the
the
workflow
and
Dimitra
and
I
were
talking
about
this
last
week
during
our
Thursday
sink
and
I
was
telling
him
that
I
needed
designer
help
on
what
he
thought
that
should
be
in
so
I
scheduled
this
for
us
to
get
together.
A
There's
some
of
it
that
Jason
suggested
that
we
might
have
an
engineer
involved
in
case
there's
some
feasibility
issues.
We
can
talk
about,
relate
it
to
the
workflow
I'm,
not
I'm,
not
that
familiar
with
how
the
how
the
dynamics
of
writing
to
the
the
right
and
the
the
read
and
the
write
access
is
given.
So
I
figured
I'd,
leave
it
to
the
expert
like
jigglers
to
fill
us
in,
and
we
have
questions
about
that.
So
Dimitri,
do
you
have?
A
B
B
I've
been
reading
through
it
and
it's
in
trying
to
grasp
as
much
as
I
can
from
it
and
though,
regardless
of
that
I
need
to
validate
some
of
my
assumptions
here
with
you
Tao
and
then
the
rest
I
think
listen.
We
cherish
can
help
steer
my
assumptions
into
the
right
directions
here,
because
I
was
just
wondering
sometimes
like
what
is
the
exact
model
here
and
what
is
the
right
way
to
solve
it?
So
I'll
talk
a
little
bit
through
the
comment.
I've
created
the
the
problem
as
far
as
I
can
see.
B
Is
that
currently,
in
order
to
give
pipelines
enough
permissions
to
write
back
to,
for
example,
the
repository
or
the
registry,
personal
access
tokens
are
being
used
in
order
to
do
so.
However,
this
opens
up
a
security
problem
because
those
pipelines
will
then
be
run
as,
if
being
that
user
of
who
is
the
author
of
the
personal
access
token,
those
tokens
are
then
used
inside
of
the
job
as
a
secret
variable,
and
so
the
author
of
the
the
original
pipeline
will
not
be
the
author
of
the
changes
that
will
happen
because
of
the
personal
access
token.
B
Additionally,
the
personal
access
token
might
be
able
to
be
revealed,
and
then
any
malicious
user
can
use
that
personal
access.
Token
to
you
know,
create
havoc
and
act
as
the
original
author
of
that
personal
access.
Token,
basically
that
having
identity
theft
there.
So
the
idea
here
now
is
that
additionally,
currently
there
are
some
restrictions
in
place
for
pipelines
and
that,
even
though
they
have
those
access
tokens,
they
are
not
able
to
write
back
to
the
repository
as
far
as
I
can
see,
or
that
is
only
if
you
used
a
deploy.
Token.
Am
I
correct
there?
B
D
So
that's
a
very
good
question
and
I'm
actually
reading
the
proposal
right
now
and
I
still
can't
answer
that
question
I
thought
that
she
behaved
differently.
So
that's
I
was
kind
of
surprised
by
what
you
were
saying
so
I
feel
like
I'm,
not
on
the
same
page
of
what
the
proposal
is.
So,
although
I
already
ready
I'm
doing
this
again
yeah,
it's
mostly.
C
A
And,
and
so
maybe,
I
should
also
go
edit
this
after
this
session,
the
description
when
I
from
what
I
learned,
because
I
talked
to
Jason
about
this,
this
issue
as
well,
and
especially
the
problem
to
solve
and
the
the
problem
as
I
understand.
It
is
when,
when,
when
a
pipe
okay,
so
a
users,
personal
access,
token
will
work
if
they
are
running
a
script,
but
that
there
is
hard.
A
There
is
something
hard-coded
where
it
removes
that
access,
if
that
toque.
If
the
user
is
triggering
this
the
same,
whatever
action
they
were
doing
in
a
job
in
a
pipeline,
and
so
the
part
that
in
the
first
sentence
of
problem
to
solve
and
where
it
says,
with
an
additional
set
of
limitations,
apply
in
order
to
do
reduce
risk.
A
That's
referring
to
whatever
is
hard-coded
that
strips
out
that
permission
so
that
you
can't
perform
the
same
activity
in
a
pipeline
as
that
same
user
could,
with
their
token,
when
running
it
manually
in
a
script.
So
that's
what
I
understand
so
the
what
we're
trying
to
solve
in
this
issue
is
removing
that
hard-coded
restriction
and
instead
allowing
for,
if
you
look
down
to
under
further
details,
allowing
for
a
way
to
assign
these
different
scopes.
A
To
a
user's
token,
and
in
order
to
do
that
in
the
proposal
you'll
see
in
the
implementation
plan,
we
have
to
change.
Camille
has
suggested
all
the
steps
that
would
have
to
happen.
We'd
have
to
change
from
using
personal
access
token
to
JWT
and
then
the
rest
of
the
steps,
one
through
five
for
a
mutation.
D
Eat
through
the
problem
result-
and
that's
probably
the
most
important
section
of
the
issue
for
the
time
being
and
I-
think
I
understand
what
we
want
to
accomplish.
However,
it's
not
necessarily
for
me
if
the
proposal
that
we
have
described
in
the
issue
is
actually
something
that
is
technically
feasible
to
do,
but
I
think
that,
for
that
I
mean
we
can
focus
on
the
problem
to
solve
and
how
I
understand
this
problem
is
that
we
have
two
ways
of
performing
actions
from
vanessi
I
built
right.
D
The
first
way
is
using
personal
access
token,
that
someone
can
inject
into
secret
variables
and,
of
course,
they
first
need
to
add
this
personal
access
token,
and
they
can
define
the
scope
of
access
for
that
token.
So
this
is
something
that
will
works
already,
and
this
is
not
something
that
we
want
to
change
in
the
scope
of
this
issue,
then
another
way
to
communicate
with
gitlab
from
within
a
CI
build
is
using
see
I
job
talkin
right,
and
this
is
something
that
is
another
way.
It's.
D
Deploy
talking
is
yet
another
token,
so
this
it
is
kind
of
different.
However,
actually
in
in
some
cases
it
is
the
same
as
here
Jeff
talking
about
not
in
every
case.
So,
let's,
let's
focus
on
the
CI
job
talking
right
now,
and
indeed
we
do
not
have
a
way
to
limit
the
scope
of
access
for
see.
I
took
token,
and
that's
probably
what
we
want
to
do
it.
We
want,
because
CI
job
token
is
associated
with
a
CI
build
and
whenever
kids
upcoming
I
build
communicates
with
kidnap.
D
Using
that
token,
we
use
it
to
find
a
build,
and
then
every
build
is
also
associated
with
a
user
and
that's
how
we
build
this
relationship
between
CI
job
token
and
the
user,
and
some
you
can
do
some
things
using
CI
job
token.
You
can
access,
get
labs
API
using
token,
not
every
endpoint
in
the
API,
but
a
few
and
there's
no
way
to
actually
reduce
the
access
right
associated
with
a
CI
chopped
up
into.
Perhaps
that's
what
we
want
to
do
here
or
perhaps
I'm
misunderstanding
some.
B
B
B
Yeah
deploy
tokens
are
visible
in
settings,
but
the
thing
I'm
I'm
finding
hard
to
so
I
know
personal
access.
Tokens
I
know
deploy
tokens,
but
I
have
no
way
I've,
no,
no
concept
of
a
CI
token.
Where
can
I
find
it?
Where
can
I
configure
it?
In?
What
way
can
users
use
it
to
resolve
the
current
like
how
they
can
provision
to
work
around
currently.
D
Then
we
have
many
different
ways
of
how
a
script
written
by
a
user
can
communicate
with
github
right.
That's
that's
again
something
interesting,
and
then
we
have
another
couple
of
ways
of
how
a
pipeline
communicates
with
kidnap
when
it's
creating
a
child
pipeline
or
cross-project
pipeline,
and
this
is
yet
another
edge
case,
because
a
pipeline
from
one
project
is
going
to
create
part.
I
mean
another
project
and
we
are
checking
the
access
rights
of
a
user
that
created
a
pipeline,
whether
this
person
cannot
between
pipeline
in
the
downstream
project.
D
So
I
wonder
if
we
should
actually
start
from
documenting
what
kinds
of
communications
we
have
between
a
pipeline
on
gitlab
or
I
built
and
get
up
right
and
then
decide
what
is
in
the
scope
of
the
issue
and
what
is
not,
because
you
can
probably
push
code
from
a
CI
built
runner
to
get
up
in
a
few
different
ways.
You
can
use
access
token
to
push
called
I'm,
not
sure.
If
you
can,
you
see
I
drop
token
and.
D
D
B
A
So
it's
almost
introducing
a
a
an
additional
job
token
to
what
exists
now
for
CI
job
token,
so
she
I
extended
and
then
it
the
link
to
that
comment
is
from
Camille
and
and
of
course
all
of
his
comment
was
pasted
in
to
the
issue
we're
talking
about
under
implementation
plan.
So
but
what
I'm
getting
at
is
rather
than
create
this
new
thing
called
CI,
extended
job
token
I
think
we're
talking
about
just
changing
the
existing
CI
bill.
A
B
So
I
think
we're
converging
towards
the
same
question
and
my
question
was
related
to
arts.
What
is
being
currently
hard-coded
hard-coded,
like
the
limitation,
in
order
to
reduce
the
risk
of
security
problems
preventing
a
pipeline
by
default
to
ride
back
to
the
repository
like,
where
is
that
hard
code
being
happened
like
being
done?
Is
that
currently
being
done?
I
think
it's
not
part
of
personal
access?
Token
I
think
it's
not
part
of
deploy.
Token,
though
deploy
token,
doesn't
have
the
scope
in
order
to
be
able
to
do
that
at
all.
B
D
See
the
point
number
one
in
the
implementation
plan
which
says
that
we
want
to
change
CI
build
token
and
the
token
this
correct
here
is
indeed
a
CI
job
token
right.
So
this
it
appears
that
this
is
what
we
want
to
change
in
the
scope
of
this
request
and
it
does
not
really
touch
anything.
That's
related
to
access
token
diplo
tokens
or
anything
else
and
wait.
A
A
D
B
Because,
as
I
see
it,
it
is
the
only
way
like
at
some
point
in
the
original
description
it
states,
a
user
will
never
be
able
to
get
more
permission.
This
is
part
of
the
proposal,
so
take
that,
with
a
grain
of
salt,
the
user
will
never
be
able
to
get
more
permissions
than
the
user
has
through
this
mechanism.
So
even
if
read,
API
is
turned
on
in
the
scope.
If
the
user
does
not
have
that
ability,
they
don't
get
it
for
free.
B
This
could
potentially
be
improved
on
afterwards,
but
the
the
thing
that
I
get
from
this
is
with
a
personal
access
token
that
is
configured
within
the
scope
of
the
personal
access
token,
and
if
you
trigger
something
through
the
personal
access
token
you're
automatically
acting
as
that
user,
it
is
the
same
with
a
deploy
token
you're,
acting
as
the
deploy
token
in
that
sense,
and
not
a
direct
user
if
I'm
correct
and
then
the
CI
token
always
acts
as
an
extension
of
the
original
author
that
does
the
pipeline
trigger,
like
the
triggers
the
pipeline
right.
So.
D
B
D
With
CI
job
token,
because
I
know
that
we
use
to
retrieve
code
from
get
lab
premier
does
it,
but
what
can
be
done
in
the
context
of
a
build
script
without
CI
job
token
to
access
kidnap,
so
I
know
that
we
can
access
some
parts
of
the
API,
but
not
too
many
and
yeah.
That's
it
I'm,
not
sure
whether
it's
possible
to
use
it
to
push
code,
but
I
will
check
that,
and
hopefully
this
will
give
us
more
context.
What
is
actually
the
impact
of
it
building
this
feature
event.
D
B
D
C
Well,
the
visual
part
that
the
visible
parts,
the
user
experience
for
days
so,
like
the
background
part
we
can,
it
seems
like
we
need
some
research
to
be
done
to
see
how
exactly
we
can
access
that
and
change,
but
also
curious,
is
there
is
anything
right
now
that
we
could
plan
for
on.
How
do
we
want
to
display
those
additional
permissions
to
the
users
or
we
prefer
the
first
to
the
the
well
the
technical
research
and
then
go
to
this
I?
Think.
D
B
B
So
personal
access,
tokens,
CI,
job
togas
and
deploy
tokens
and
the
UI
that's
being
mentioned-
is
either
part
of
the
deploy
token
or
the
personal
access
token
and
there's
not
touching
anyway,
see
I
chopped
up,
which
is
the
most
potentially
the
core
of
the
problem.
We're
trying
to
tackle
here,
which
is
hard-coded
and
not
touched
by
any
UI.
Currently
so,
even
though
we
can
potentially
reuse
some
UI,
we
cannot
act
when
the
existing
UI,
because
it's
not
there,
it's
not
yet
been
created
at
all.
B
So
that
is
I
a
little
bit
unsure
about
that,
because
how
I
see
it
is
that
the
idea
here
is
to
extend
upon
the
users
permission,
so
the
the
permissions
we
give
the
pipeline
will
never
exceed
the
permissions
of
the
user.
So
if
we
can,
for
example,
imagine
let's
say
we
can
scope
the
permissions
of
the
like
of
the
pipeline
in,
for
example,
either
a
project
or
a
group,
then
the
original
author
say,
for
example,
you
Joker's
will
trigger
the
pipeline
and
then
the
pipeline
will
look
first,
at
your
permission,
see
hey.
B
Does
this
user
have
permission
to
write
back
to
repository?
If
so,
move
on
to
the
next
part,
C
at
C,
I
chopped
open,
C,
hey
can
I
actually
use
this
mechanism
to
write
back
to
past
your
token?
Yes,
if
so,
then,
okay
I'll
do
that.
But
if
one
of
those
two
is
no
with
you
being
the
first
one,
even
though,
for
example,
this
year
I
job
token
has
permission
to
do
it,
you
as
a
user,
does
not,
then
it
will
not
be
able
to
do
so.
So
now,
it's
more
of
an
extension
upon
that
yeah.
D
I
understand
that,
but
the
question
is:
who
is
responsible
for
configuring?
This
behavior,
for
example,
I'm
a
user
who
can
push
code
to
some
project?
I?
Don't
want
my
CI
job
token
to
be
able
to
do
that.
So
am
I
responsible
for
doing
that,
or
perhaps
that's
going
to
be
an
affordable
project
group
or
an
instance
level
by
a
maintainer
or
instance
of
minister
who
is.
B
Yeah
so
as
I
thought
initially
of
it,
but
it
is
good
to
look
into
that
is
this
will
become
part
of
either
a
project
or
end
or
the
group
settings
view
so
dis
manageable
as
a
maintainer
of
either
of
those
scopes,
and
then
it
will
react
automatically
based
on
like
DOS,
like
I,
see
this
two
gates
like
there,
the
user
permissions,
and
then
you
have
the
configured
pipeline
permissions,
basically
that
the
process
needs
to
roll
through.
So
in
that
case,
I
would
see
it.
B
It
will
fit
in
either
project
with
group
settings,
but
you
know
I'm
wondering
in
that.
In
that
sense
you
said:
hey
we
have
some
existing
UI
to
manage
pipeline
permissions.
I
do
not
know
about
them.
I
would
lost
in
there
too,
for
you
to
report
back
after
you
got
some
technical
research
here
and
see
where
that
actually
is
because
I
have
no
idea
so.
A
A
So
earlier
you
were
saying
gee
course
that
that
probably
the
technical
part
needs
to
be
figured
out
before
we
start
designing
it,
but
I
I
think
that
the
designing
of
the
maybe
workflow
is
dependent
on
that,
but
not
really
what
the
I
mean
we,
we
may
not
know
where
what
scopes
can
be
included,
but
I
think
we
could
still
map
out
what
the
UX,
what
the
user
experience
the
workflow
would
be
like,
where
they
would
go.
Let's
say:
I'm
a
maintainer
or
I'm
a
product
owner
where.
D
D
We
might
be
using
that
because
it's
a
user
who
is
going
through
the
arc
or
cool
to
authorize
some
application
right
and
in
this
particular
case
it
feels
like
it's,
not
users
responsibility.
So
we
are
not
going
to
build
this
that
way.
Instead,
we
are
going
to
have
some
settings
configurable
in
a
project
or
group,
so
it
means
that
we
might
be
using
out
under
the
hood,
but
not
the
part,
that
is
visible
user
gotcha.
A
A
B
A
C
Immediately
your
point
about
the
cross
projects
usage,
but
there
will
be
also
other
settings
that
are
the
project
that
has
to
be
kind
of
like
it
could
go
under
the
same
pocket
right.
So
basically,
whether
I'm
trying
to
say
that
if
we
are
looking
into
like
yeah
using
cross
projects
pipeline,
there
will
be
other
settings.
That
would
be
people
need
to
figure
out
the
way
how
to
allow
users
to
fix
those
or
configure
those
as
well
similar
to
the
settings
so
yeah
I
just
trying.
Hopefully
it's
clear
what
I'm
trying
to
say.
B
Does
it
make
sense
yeah
yeah,
so
I,
like
you,
mean
like
hey?
If
you
want
to
control
this
from
a
project
setting
them
are
gonna
create
a
group
setting
that
manages
the
same
thing.
Then
we
should
make
sure
that
if
setting
in
the
group
is
changed,
it
has
an
effect
in
the
in
the
project
setting
and
versa.
B
C
More,
like
you
know,
you
have
a
concern
that
you
said
that
if
we
want
to
support
the
cross
project
pipelines,
it
would
make
more
sense
to
put
this
setting
on
the
group
level.
Otherwise,
the
project
level
is
the
best.
It
sounds
like
it
sounds
that
you
are
more
like
leaning
towards
that.
Putting
this
on
the
project
level,
but
I'm,
saying
probably
there
are
other
settings
on
the
project
that
would
you
know
that
would
need
to
be
supported
for
the
cross
pipeline
in
the
future
as
well.
C
D
So
because
user
concept
is
scoped
to
entire
pipe,
a
twenty
instance
right
and
I
can
actually
build
a
pipeline
that
is
going
to
push
code
to
some
project
outside
of
my
groups,
to
you
know
completely
different
resource
different
project
and
how
then
I
evaluate
the
permissions.
If
I
have
a
group
project
in
those
cold
tokens
and
I.
B
In
in
that
case,
it
should
also
always
refer
back
towards
the
user.
Is
the
first
point
of
contact
in
terms
to
see
of
permissions
right,
so
it
should.
It
should
work
in
tandem
with
that,
if
I
have
permission
in
group
a
and
also
in
Group
B
and
the
pipeline
I'm,
starting,
which
intends
to
post
something
back
to
group
a
but
resides
in
Group
B,
then
the
permissions
so
hard.
D
B
B
They
will
all
have
to
act
like
enable
that,
within
their
own
user
permissions
explicitly
before
they
will
be
able
to
do
that.
Well,
if
we
make
it
like
some
kind
of
session
like
detached
from
the
users
permissions,
then
you
have
the
default
user
permissions.
They
have
access
to
the
project
or
not.
They
have
access
to
the
group
or
not,
and
then
you
have
the
separate
pipeline
permissions
that
say
hey
if
a
user
that
has
permission
enough
permissions.
Do
we
also
allow
this
user
to
write
back
to
this
repository?
D
So
I
think
it's
quite
difficult
to
reason
about
that,
and
my
proposal
is
to
document
you
know
calling
this
information.
What
can
be
done
with
the
CI
job
talking
right
now,
because
what
can
be
done
right
now,
the
kind
of
effects
you
know,
design
implementation,
because
then
knowing
what
can
be
done
related
and
reason
about
how
to
reasonably
limit
what
can
be
done,
best
you're
talking
and,
for
example,
the
cross
project
pipelines
and
pipeline
figures.
That's
it
that's
very
interesting,
probably
because
it's.
D
C
It
makes
sense
and
yeah
question
on
the
side.
Maybe
there
is
already
a
case
with
a
similar.
You
know
permission
setting
problem,
because,
oh
my
god,
these
permissions
is
always
like
it's
a
it's
a
wood
forest
such
a
deep
one
that
nobody
wants
to
go
in.
Maybe
we
already
like
have
a
similar
example
somewhere
and
know
in
package.
Cuz
team
was
pretty
team.
Breezy
was
pretty
active
in
the
discussion.
Maybe
we
can
also
reach
out
to
some
other
people
to
say
a
is
a
reason.