►
Description
Discussion with Verify:CI team about making pipeline permissions more controllable and flexible (#35067)
A
A
Looking
back
at
our
previous
meeting,
I
was
really
trying
to
push
us
to
help
some
well
some
clear
outcomes
of
this
of
this
session.
Therefore,
I
went
and
I
made
some
of
the
proposals
for
the
agenda
and
I
also
created
the
moon
upward
that
I
put
here
so
yeah
I
will
just
drop
it
there,
but,
let's
see,
maybe
indeed
we
can
give
the
war
two
crackers
first
to
start
to
give
us
a
little
bit
of
a
background
on
the
technical
side.
A
B
B
You
know
vision
and
big
picture
of
what
the
problem
is
and
how
we
actually
can
use
CI
job
token,
but
it's
quite
evident
that
CI
job
token
is
one
of
many
ways
in
which
we
can
communicate
develop,
but
it
appears
that
is
that
the
CI
job
token
is
indeed
our
area
of
focus
right
now
and
something
that
we
want
to
take
care
of
right
now
and
I
think
that
the
jasminetea
updated
the
issue,
or
at
least
he
was
supposed
to
that.
So
let
me
try
again
and
perhaps
proposed.
A
C
B
B
B
The
name
this
in
the
story,
so
I
actually
have
one
question
that
I
hope
that
we'll
be
able
to
solve
here
is
that
where
this
should
be
configured
and
how
to
do
that
properly
and
that's
probably
the
only
missing
part
of
the
story,
how
to
actually
configure
that
and
where-
and
we
quickly
discussed,
that
during
our
last
meeting
and
and
I
wonder
if
you
have
any
thoughts
about
what
can
be
done
here,
especially
from
the
UX
side.
But.
A
First,
before
we
even
got
it
because
again
we're
dropping
into
the
solution.
Part
and
I
just
want
to
make
sure
so
does
the
problem
that
you
know
the
problem
statement
that
Jason
proposed?
Does
it
sound
like
that's
the
place
where
we
should
focus
our
powers
right
now,
so
it
sounds
like
we
want
to
provide
users
a
better
way
to
to
configure
the
user
permissions
and
he
proposed.
We
should
not
upgrade
the
existing
permissions
as
well.
A
B
Yeah
I,
don't
have
anything
to
I.
Think
that's!
That's
the
problem
that
we
are
trying
to
solve
that
whenever
it
a
parameter
communicates
with
github
by
executing
I,
usually
provided
script,
that
is
using
CI
job
token
or
the
runner
is
using
CI
job
token
internally,
when
it
communicates
to
get
up.
Get
up
can
use
some
configured
values
to
decrease,
reduce
the
permissions
of
the
user
associated
with
a
CI,
a
job
talking
to
particular
resources,
and
that's
that's
probably
exactly
what
we
are
trying
to
solve.
You.
C
B
Okay,
so,
whenever
an
build
or
job
I'm
using
a
build
name
instead
of
job,
because
this
is
how
jobs
are
represented
in
the
code
all
right,
so
we
don't
have
a
concept
of
the
job
in
the
Ruby
and
go
and
code
base,
but
instead
we
are
using
capital.
So
for
me
all
the
jobs
are
builds
I'm
using
can
build
and
that's
the
reason
why
I'm
also
referring
to
that.
B
So
whenever
a
build
gets
created
and
it
initiates,
it
state
is
created
only
later.
It
migrates
translates
to
pending
state
and
running
and
successful
finish
so
whenever
it
gets
created
before
it
is
actually
fitted
by
a
runner.
We
generate
a
random
token
and
we
write
it
to
a
database,
but
also
when
we
read
it,
we
can
read
a
random.
C
C
B
A
B
A
B
C
B
Okay,
so
something
is
here
so
I
will
take
the
whole
page.
I
will
take
a
look
in
the
meantime
when
I'm
explaining
that
so,
okay,
so
now
we
have
this
CI
job
token
associated
with
dilatant,
a
user
associated
with
the
build.
So
the
build
is
the
entity
that
holds
the
Association,
the
relationship
and
a
CI
jock
token
and
a
user,
and
as
I
told
you
whenever
it
gets
created,
this
relationship
is
being
persisted
in
the
database.
B
The
CI
job
token
is
also
passed
to
the
runner
so
that
the
no
runner
knows
what
the
CEO
job
token
is,
and
it's
and
the
runner
is
using
that
CI
job
talking
internally,
for
example,
to
fetch
pipeline
to
fetch
repository
right
to
fetch
the
code
that
the
pipeline
is
going
to
be
run
for.
But
it
also
exposes
the
CIA
job
token
in
environment
variables.
C
B
B
C
B
Me
go
think
I
wanted
to
check,
but
couldn't
find
time
to
do
so
because
I
was
sick
and
I'm,
not
sure
if
I
see
a
job
token
can
be
used
to
write
to
reverse
tree.
This
is
something
I'm
missing
and
perhaps,
and
perhaps
I
should
I
should
need
to
find
an
answer
for
that.
But
for
me
it's
like
an
a
detail
in
the
story
like
whether
a
CI
drop
token
can
be
used
to
write
or
post
3
or
not
all
right.
B
B
We
definitely
we
need
to
create
a
table
of
what
CI
job
token
can
do
right
now
and
how
it's
going
to
do
it
right
now
and
I
probably
know
80%
of
that
and
the
remaining
20
time.
Twenty
twenty
percent
is
something
I
I
failed
to
check
because
of
the
music
and
I'm
sweet
for
that.
But
let
me
perhaps
finish
explaining
how
it
works,
because
it's
you
know
having
this
full
teacher
of
how
it
works,
might
help
us
to
understand
all
the
details
of
this
issue.
B
Runner
is
also
using
it
internally
to
communicate
to
give
up
and
as
far
as
I
know,
it
is
only
using
that
in
a
few
cases
that
one
case
is
fetching
code
from
repository
right.
It's
internally
little,
a
planner
is
using
git
I,
think
and
it's
using
CI
job
talking
as
password
and
get
up
itself
needs
to
recognize
that
this
is
a
CI
job
token.
B
B
We
have
control
over
how
it's
how
the
communication
is
happening
right,
but
then
the
CI
drop
token
is
also
exposed
in
the
to
the
build
itself
and
a
user
who
designed
the
script,
can
take
it
and
do
whatever
they
want
with
it.
They
can
use
curlew
with
CI
job
token
to
communicate
with
gitlab.
They
can
use,
get
with
CI
job
talking
to
communicate
we'll
get
up.
They
can
do
many
different
things
and.
B
C
B
A
A
And
let
me
make
it
black:
no,
for
example
black;
no,
it
doesn't
work
anyway.
Oh
my
god,
this
tool
is
so
bad,
so
I
think
really
one
of
his
proposal
was
to
like
extend
those
permission
to
make
them
more
granular,
and
they
need
that
also
for
some
of
the
work
in
the
package
registry.
If
I'm
correct,
if
I
understood
it
correctly.
A
B
So
I
think
that
it
can
be
done,
but
probably
not
in
the
scope
of
this
issue.
So
we
for
every
extension
we
might
need
to
have
a
issue
but
having
this
mechanism
that
allows
you
to
limit
what
can
be
done
with
CI
job
token
in
place
can
make
it
actually
easier
to
extend
what
can
be
done
with
C
I
drove
token
in
the
first
place.
Right,
because
this
way
we
can
add,
for
example,
gives
your
job
talk
and
access
to
entire
API,
but
tell
github
that
this
CI
job
token
cannot
rewrite
the
API
at
wall.
C
So
with
that
in
mind,
what
what
is
the
current
permissions
CI
job
token
has
like
if
we
would
like
make
the
permissions
available
of
the
CI
job
token
as
it
currently
is
by
default
hard-coded
configured?
Yes,
what
would
goes?
What
would
those
things
be,
because
those
things
will
need
to
be
represented
in
the
eventual
solution
or
got
a
design
flaw
right,
I'm.
C
B
Right
that
it
can,
you
can
use
your
token
to,
for
example,
post
new,
get
up
release
through
the
API
and
I
think
it
works
that
way.
I
wouldn't
double
check.
Of
course,
again.
I
have
not
done
that
yet,
but
it
can
do
a
few
things
like
that
or
in
some
sense
some
parts
of
the
API.
It
can
only
read
in
other
parts
of
the
API
it
can
written
right
and
we
do
not
have
a
lot
of
a
lot
of
endpoints
like
that
that
CIA
job
token
can
be
used
with
it's
not
available
for
entire
API.
B
B
C
A
C
C
B
You
can
answer
this
question:
it's
not
possible
because
for
some
parts
of
the
API,
with
user
with
API
is
checked
for
other
parts
of
the
API
right
repository
right,
API
is
checked
or
at
the
NPI
scope
watching
for
other
things,
nothing
is
checked
for
registry
with
registry
might
be
checked
and
write
registry
might
be
checked.
So
it's
there's
no
clear
answer
to
what
how
what
permissions
are
set
right
now,
because
for
different
resources,
different
permissions
are
hard-coded.
This.
B
C
B
C
Let's,
let's
you
from
a
different
angle:
what
is
what
would
be
your
like
your
happy
path
in
this
sense
like
if
you
would
see
this
interface
being
created
from
your
perspective
and
I
assume
here?
This
is
just
an
assumption,
so
you
can
go
and
where
else
is
that
it
will
have
an
interface
similar
as
personal
access
tokens,
where
you
can
say
alright,
I
want
to
allow
CI
job
tokens
to
have
access
to
this.
This
and
this,
but
not
this.
This
is
this.
Ok.
B
What
might
be
in
there,
so
my
happy
path
would
be
going
through
codebase
and
documenting
all
the
things
that
you
can
do
with
CI
job
token.
Then
it
would
be
devising
the
Scopes
based
on
what
can
be
done
currently
with
CI
job
talking,
and
this
is
something
that
we
are
missing,
like
the
complete
list
of
everything
that
can
be
done
with
CIJ
token
right
and
once
we
have
all
the
things
that
can
be
done
with
the
job
token,
we
could
create
a
configuration
like
that
and
enable
everything
by
default
on
our
user
level.
B
B
A
B
B
The
it's,
what
I
proposed
is
a
little
bit
different
than
what
is
described
in
the
issue,
because
Jason
described
a
situation
in
which
administrators
can
configure
something,
and
our
solution
means
that
administrators
won't
be
able
to
do
anything
just
yet.
But
it's
going
to
be
users
of
their
tokens
and
when.
A
He
sends
from
my
side
or
five
here
after
a
discussion
with
j-jason.
He
mentioned
that
he
and
Camille
they
have
just
like
dropped
something
as
a
proposal
and
he
said
basically
feel
free
to
put
doubt
and
double
check
looking
into
the
data
we
have
today
from
the
customers
and
by
the
way.
That
would
be
maybe
my
first
question
like
draggers
before,
like
have
you
seen
all
of
those
things
and
I'm
if
you
again,
if
you
can
point,
you
can
click
on
me
right
now,
you'll
be
pointed
to
this
user
feedback
section.
A
Would
be
also
useful,
for
you
were
to
go
through
that
I
dragged
the
most
like
the
biggest
insights,
that
I
thought
are
scoped
in
multiple
issues
that
are
linked
to
this
one
and
see
if
your
opinion
on
the
end
solution
will
change
in
any
way
and
of
course,
let
us
know
but
yeah,
but
from
what
I've
read
and
how
I
understood
it
from
my
not
very
very
super
super
technical
background.
I
think
what
you
say,
what
you're
saying
making
sense
but
I
would
love
for
you
to
go
and
double
check.
D
A
B
A
This
is
all
posted.
This
is
all
copied
from
the.
If
you
go
to
the
agenda,
I've
made
it
this,
like
user
data,
to
look
into
in
the
agenda
and
I
copy
paste
it
well,
not
all,
but
most
of
the
issues
or
Zendesk
requests
or
sales
for
salesforce
salesforce
links.
They
don't
have
account
personally,
but
all
of
this
is
kind
of
like
it's.
A
My
I
like
it
will
take
you
ten
minutes
to
go
over
this
all
it's
to
collect
it's
a
little
bit
more
understanding
of
how
people
see
the
problem
in
pink
and
what
do
they
propose
in
green,
so
I
broke
it
down
for
us
like
that.
Maybe
this
will
help
us
to
push
ourselves
into
a
certain
solution
based
well,
people
are
proposing.
B
C
B
A
The
truth
is
that
they
are
different
problems
and
I.
Think
for
us,
it's
important
to
look
figure
out,
which
ones
are
related
to
the
one
we
kind
of
like
started
from
and
see.
If
that's
still
the
biggest
challenge
here
and
if
so
like
we
can,
you
know
we
can
prioritize
those
different
problems.
Maybe
we
don't
have
all
of
them,
especially
discussion,
but
it's
yeah.
This
is
where
you
are
I.
Guess
at
our
opinion,
is
really
needed
here
as
a
big
people
who
are
having
a
bit
more
understanding.
What
are
we
talking
about.
A
C
Is
the
there's
one
most
important
problem
for
us
to
solve
and
it
is
the
private
like
private
access
tokens
are
currently
being
misused
and
that
creates
a
security
problem.
This
is
the
main
problem.
We're
trying
to
fix
and
I
do
think.
If
we
allow
users
to
fix
that
problem
to
not
have
to
misuse
personal
access
tokens,
and
can
you
see
I
chopped
ovens
and
allowed
OCI
Giotto
gets
to
do
the
same
thing.
They
previously
used
a
personal
access
tokens
for
it.
Then
we
are
solving
the
main
problem
here.
B
B
A
C
C
C
So
the
most
problem,
definition
that
was
given
by
by
Jason
without
going
into
solution,
izing
because,
like
solutionizing
like
hey,
we
want
to
create
this
interface
that
is
accessible
by
admins
to
do
whatever,
without
going
into
that,
he
says
due
to
limitations
on
what
the
currency
I
jumped
up
is
able
to
do
so
that
there's
an
assumption
there,
but
we're
pretty
pretty
accurate
on
that
program.
Most
likely
you
get
up
the
only
way
to
perform
several
common
important
tasks
that
some
pipe
lines
need.
Typically
like
right.
C
Destructive
operations
like
uploading
a
file
right
into
this
API
is
to
curl
the
API
from
the
script
section
of
a
job
using
the
user's
personal
access
token
saved
as
an
environment
variable.
This
is
not
a
very
secure
way
of
doing
things
because
the
access
token
my
it
may
have
more
permissions
that
are
needed
and
it
is
fragile
because
it's
dependent
on
that
user,
so
the
CI
job
token
will
gets
used
by
other
people.
C
B
Now
I
understand
exactly
what
we
want
to
solve
here
and
in
order
for
you
to
understand
that
you
are
probably
missing
one
important
information
about
what
is
the
difference
between
a
CI
job,
token
and
personal
access
token,
and
what's
the
difference
in
the
security.
So
now
the
difference
is
that
CI
job
token
is
only
valid
as
long
as
a
CI
build
is
running,
it's
created
when
a
build
is
created
and
when
it
is
complete
its
revoked
in
some
way.
Of
course,
it
might
be
valid
for
a
more
couple
couple
of
means
more.
B
It
depends
for
many
different
things,
but
that's
the
code
difference
that
CI
job
token
gets
revoked
and
invalidated
after
the
build
translates
to
a
finished
state.
Whether
it's
failed
success,
consult
or
something
like
that,
and
that's
probably
a
problem
with
personal
access
tokens.
There
are
long-lived,
you
create
them.
You
can
set
when
personal
access
token
gets
revoked.
C
B
C
C
You
still
need
to
find
out
and
choose
if
you
stated
before,
because
there's
a
lot
of
things
throughout
the
codebase
that
it
can
do
and
cannot
but
like
what
I
see
as
a
and
as
a
like
there's
the
main
problem
of
the
personal
access
token
being
used,
and
then,
as
is
sucked
like
that
personal
access
token
is
being
used
for
a
variety
of
use
cases.
Then
we
can
choose
in
those
use
cases
which
one
we
want
to
support
right
off
the
bat
and
then
the
other
ones.
We
can.
C
B
I
think
it's
probably
a
technical
decision,
whether
we
want
to
use
reuse,
whether
we
want
to
create
something
like
CI
access,
token
or
CI
user
access.
Token
right,
it
would
be
different.
So
it's
probably
a
matter
of
checking
what's
easier
to
achieve,
because
we
factor
reading
every
place
where
we
actually
CI
job
talking
might
be
quite
difficult,
but
on
the
other
hand,
having
yet
another
token
might
be,
might
introduce
some
amount
of
complexity
that
we
want.
We
don't
want
to
introduce
so.
C
Mean
that
is
what
the
CI
giotto
my
name
is
right.
It
is
like
it
is
connected
with
the
user
ID.
It
will
use
the
user
ID
permissions,
but
then
it
is
fir
halted
by
whatever
the
CI
job
token
is
limited
to
which
is
hard-coded
in
the
code.
That
is
what
we're
gonna
expose.
As
far
as
I
am
understanding.
This
problem,
space,
yeah.
B
C
B
C
Sorry
likely
I'm,
not
I'm,
not
hundred
percent
following
so
like,
please
explain
to
me
what
you
like,
where
you
make
the
difference
between
this
is
what
is
what
a
personal
access
token
can
do
and
that
will
be
use
in
you
know.
A
variety
of
way
is
but
CI
job
token
can
never
touch
that
because
of
X
I'm,
not
sure
what
that
accents.
The.
B
X
is
that
currently
it's
not
supported,
and
it's
simple
as
that,
because
CI
job
token
never
had
this
possibility
of
continuing
scopes.
We
decided
not
to
add
support
for
it
in
most
of
the
place,
so
it
can
be
used
with
the
API.
It
can
be
used
with
a
couple
of
other
resources
and
I
think
that
the
first
step
is
to
understand
clearly,
what's
the
difference
between
what
can
be
done
with
CI
job
token
and
CI
access
token,
and
would
what
would
be
the
effort
to
align
the
two,
because
we
want
to
make
as
he
is.
C
C
B
C
Yes,
that's
how
I
understand
it
as
well?
Okay,
but
the
the
point
being
is
like
there's
there
step.
One
is
in
terms
of
like
we
want
to.
We
want
a
lot
like
we
both
need
to
expose
what
a
CI
job
token
can
currently
do,
and
then
we
need
to
support
one
of
the
use
cases
that
we're
trying
to
fix
so
that
the
job
token
can
indeed
be
extended
to
be
used
for
that
use
case.
That's.
B
One
way-
and
the
second
way
is
to
fix
personal
access
tokens
right,
because
we
can
also
build
a
feature
that
will
basically
inject
your
personal
access
token,
with
a
specific
name
into
the
conflict.
Context
of
CI
build
so
other
people.
Other
pipelines
do
get
a
different
talking,
for
example,
and
then
we
can
also
set
some
expiration
rules
and
invoke
that
token
or
hash
it
in
some
way
that
it's
not
really
visible
in
a
way
that
put
out
people
to
obtain
it
and
reuse.
B
So
there
are
probably
a
bunch
of
solutions,
but
I
guess
that
the
first
thing
to
understand
is:
what's
the
effort
of
aligning
the
CI
job
talk
and
with
personal
access
token,
because
if
it's
so
huge
that
it
would
require
a
rewrite
of
some
parts
of
codebase,
perhaps
we
can
leave
the
CIA
job
token,
as
it
is
right
now
and
device
this
solution
based
on
reworking.
You
know
personal
access
documents
in
some
way,
but.
C
B
Example,
something
like
that
like
there
are
a
bunch
of
solutions.
Well,
what
can
we
do
to
make
personal
access
token
more
secure?
So
it's
a
matter
of
fighting
the
right
balance
between
the
complexity
of
refactoring,
CI,
job
tokens
versus
complexity
of
augmenting
personal
access
tokens
all
right.
So
this
is
more
like
a
technical
decision.
C
C
So
if
the
user
is
currently
using
a
personal
access
token
we're
going
to
extend
upon
the
personal
exit
open
to
allow
for
X
to
be
possible,
then
how
does
that
influence
the
workflow
but
I
do
say
at
the
same
time
and
I
agree
with
you'd
like
first
up,
we
need
to
understand
what
technical
scope
involved
in
either
one
of
those
directions.
Having
that
you
X
will
comment
to
play,
yeah.
B
So
that's
interesting
and
I
think
I
would
definitely
spend
some
time
and
this
time
I'm
going
to
prioritize
this
and
I
hope
not
to
get
sick
again
to
research,
the
tissue
and
give
it
more.
And
so
it's
also
a
matter
of
understanding
what
users
are
using
the
personal
access
token
for
it's
only
a
matter
of
adding
a
charge
of
talking
to
the
API.
It's
probably
a
good
idea
to
rework
the
CEO
job
token,
and
this
way
we
will
be
able
to
add
configuration
options
for
scopes.
B
A
B
A
Think
you're
the
best.
Well,
definitely
not
me
the
meeting,
probably
the
best
people
to
do
that
and
thanks
a
lot
I
think
that's
a
great
proposal.
I
think
we
can
say
that
hey,
we
had
a
meeting
with
all
of
us
to
align
on
the
problem,
and
this
is
what
we
think
the
problem
is,
and
tagging
Jason
and
Tao
and
say:
hey,
do
you
agree
or
not,
but
it
sounds
like.
Indeed
the
discussion
was
pretty
productive,
so
yeah.
B
C
So
there's
one
more
step,
but
I
think
it
needs
to
wait
for
the
technical
research,
because
after
that,
we'll
have
more
information
to
decide
direction
upon.
But
like
we
understand
the
problem
space
that
you
know
personally
X
tokens
are
currently
being
misused.
But
then,
if
we
want
to
extend
and
there's
additional
effort
involved
in
supporting
those
use
cases,
then
we
need
to
decide
on
alright,
which
use
case.
Do
we
want
to
support
first?
But
this
is
gonna,
be
next
step.
Perhaps.
C
But
thanks
for
this
explanation,
it
really
like
when
we
were
talking
about
the
happy
path,
that
kind
of
like
lighted
up
exactly
what
I
was
thinking
like
all
right
in
terms
of
CI
Java
token,
that
is,
if
we
go
for
that
direction,
then
the
other
one
which
I
also
found
very
interesting,
is
like
hey.
We
can
go
a
totally
different
path,
which
is
you
know,
extending
the
personal
access
token
to
be
used
in
some
way
that
it
doesn't
create
that
that
security
problem
bill.
It
also
allowed
for
additional
configurability
for
permissions.
B
Know
and
I
think
that
the
hub
of
it
might
be
also
interesting,
because
if
it's
only
a
matter
of
adding
a
full
support
for
the
API
to
CI
job
token,
then
it
might
be
actually
quite
simple
to
extend
the
API
access
in
the
next
operation,
the
first
one
being
exactly
the
heavy
bottom
part
that
we
described
anyway.
Let
me
do
some
return
right
somewhere
in
the
issue
and
I
think
that
my
brain
is
already
drained
thanks.