►
From YouTube: Pipeline permissions (issues #35067) | June 11th 2020
Description
Follow up discussion about "Make pipeline permissions more controllable and flexible" issue and the technical research done by Grzegorz.
A
A
B
Yeah,
so
I
could
spend
some
time
on
trying
to
understand
this
problem
better
and
it's
interesting,
because
recently
I
saw
two
security
issues
that
we
had
to
fix,
that
I
that
are
kind
of
related
to
CI
job
talk,
and
so
it
it
appears
that
there
is
not
only
product
need
in
terms
of
the
customer
needs
to
resolve
that.
But
there
is
also
a
significant
need
from
the
security
side
of
how
we
are
using
CI
job
token,
and
we
need
to
definitely
work
on
more
fine-grained
permissions
for
that
and
I
drop.
B
The
links
to
security
issues
in
the
agenda
in
case
of
someone
like
you
would
like
to
read
them
and
also
modules
from
the
CI
team
is
working
on
these
security
issues,
and
we
had
a
call
today
and
we
found
a
nice
approach
of
solving
these
issues.
That
will
also
allow
us
to
build,
on
top
of
that,
to
fix
to
resolve
the
issue
about
more
flexible
permissions
and
long
story.
D
Can-Can,
while
the
POC
is
being
done
in
parallel,
can
any
UI
UX
or
anything
you
X
flow
the
thought
through,
or
do
you
advise
that
we
wait
until
the
POC
conclusion?
It
concludes
with
the
findings.
The
reason
I
ask
is:
there's
I
wonder
if
we
can
save
some
time
with
with
me
working
with
the
joiner
and
talking
through
what
would
be
the
ideal
workflow
for
how
a
user
would
even
use
whatever
solution
we
come
up
with
like
how
would
they
attach
these
or
assign
these
permissions
or
whatever
to
a
pipeline?
Some.
D
B
D
A
To
go
back
a
little
bit
on
the
proof-of-concept
you've
been
talking
about
remembering
from
last
meeting
I
think
we
were
a
little
bit
on
between
two
strategies.
Right,
we
were
either
gonna,
you
know,
extend
the
personal
access
tokens
to
be
usable
or
it
was
going
to
be
to
extend
the
policy
I
jumped
open
and
make
that
you
know
like
that
accessible
in
Bui
somewhere.
A
B
I
think
that
both
are
possible,
but
it's
by
the
pocs
needed
to
understand
better,
which
approach
is
going
to
be
more
simple
and,
of
course,
I
also
like
to
stress
that
the
simple
does
not
equal,
easy
and
I
would
prefer
to
have
a
simple
zone.
So
even
if
working
we
working
CI
job
tokens
might
be
more
more
work
if
it
leads
to
having
a
more
simple
code
base
and
user
experience.
A
B
And
there
is
one
additional
question.
I
would
like
to
ask
I
managed
to
go
back
into
the
history
of
this
issue,
because
it
appears
that
if
it
is
marked
as
if
the
original
issue
has
been
marketed
duplicate,
it
had
been
moved
a
few
times
from
different
projects
and
I
saw
that
the
previous
iteration
of
this
issue
is
actually
an
issue
with
more
than
300
of
votes,
about
being
able
to
push
code
using
github,
see
right
tokens.
A
I'm
trying
to
understand
exactly
what
the
difference
is
here
you
mean
through,
like
the
thing
I'm
wondering
about,
is
say
that
we
implement
this
like
from
API
respected.
First,
will
it
still
affect
either
personal
access,
tokens
or
CI
job
tokens
like?
Is
it
the
same
problem
that
just
now
interfacer
is
something
else
so.
B
I
think
that
currently
you
can
not
do
you
see
I
job
token
to
push
code
repository,
and
there
was
an
issue
about
exactly
this
problem
and
users
wanted
us
to
make
it
possible
to
push
code
to
get
lucky
triple
screen
using
a
CI
drop
token.
And
if
you
go
to
the
last
comment
in
the
issue,
I
linked
with
the
previous
issue
there
and
you
can
see
that
it
has
more
than
300
uploads.
B
So
it
feels
like
this
is.
This
is
important
and
pushing
code
using
CI
job
token
is
different
than
communicating
with
our
API.
Obviously,
because
you
use
git
itself
to
push
code
from
the
context
of
a
CI
build
and
instead
of
providing
your
access
token
or
your
password
depending
on.
How
is
your
good
luck?
Instance
configured?
You
can
use
a
CI
job
token
to
authenticate
the
git
push
request,
whereas
in
case
of
get
a
VI
access,
you
are
just
using
some
HTTP
clients
to
hit
the
API
endpoint,
and
this
is
just
a
different
thing.
B
You
can,
of
course,
use
API
to
create
comics
as
well,
but
if
you
have
created
a
comet
in
a
context
of
CI
build.
This
is
the
comic
that
you
want
to
push
instead
of
creating
new
and
using
the
API.
So
there
are
two
significant
use
cases
of
extending
permissions
of
CI
drop
tokens.
One
is
giving
them
full
access
to
the
API
and
second
one
is
giving
C
I
drop
tokens
access
to
pushing
code
to
get
up,
because
three
and
I
wanna
repeat
that
yeah.
D
It's
G
gawrsh
reference.
His
comment
in
the
in
the
issue
as
well
right,
I'm
reading
your
comment
that
you
just
made
an
issue
itself.
I
I
did
to
answer
your
question.
G
gosh
I'd
rather
make
the
priority
access
to
the
API,
but
is:
is
it
one
of
those
things
where
you
can
only
do
one
or
the
other
and
the
proof
of
concept.
B
It
won't
make
it
possible
to
communicate
with
the
API
or
won't
make
it
possible
to
push
code
to
remove
the
edge
of
talking,
but
it
will
refactor
code
base
in
a
way
that
we
can
actually
control
what
the
permissions
of
a
CI
job
talking
is
going
to
be
and
how
this
is
going
to
look
like.
So
it's
possible
that
the
POC
will
just
demonstrate
that
we
can
do
that
and
that
we
know
how
to
control
these
permissions,
but
won't
add
more
features
to
see
our
job
document.
B
The
adding
more
features
might
be
done
in
two
subsequent
iteration.
So
this
is
something
that
is
possible
and
only
the
engineer
working
on
the
POC
is
actually
going
to
be
able
to
answer
the
question.
What
can
either
move
on
within
a
POC
right?
But
it's
possible
that
we
will
need
white
right
on
that.
Okay,.
A
D
B
A
D
Well,
let
me
let
me
retract
what
I
said
about.
Let
me
at
first
I
thought
we
reading
the
original
issue
that
we
wanted
to
make
access
to
the
API
the
priority.
But
let
me
think
about
that
for
a
moment,
because
the
other
part
of
what
we
want
to
achieve
in
this
issue
when
I
look
at
the
description
again
are
some
of
the
scopes
and
one
of
the
scope
is
being
able
to
write
to
a
repository.
D
A
B
B
But
then
the
first
alliteration
that
we
are
going
to
ship
to
users
will
combine
the
POC
with
something
that
is
useful
and
it
might
happen
that
we
will
be
able
to
add
API
support
and
get
push
in
the
first
alliteration
that
we
are
going
to
ship
to
users
which
is
going
to
the
second
direction
on
the
issue,
because
the
first
one
is
going
to
be
the
POC
but
yeah.
But
we
need
to
have
the
POC
first
and
then,
after
the
POC.
A
If
we're
gonna,
do
a
PRC
like
what
is
the
time
in
which
we're
gonna
do
that
and
how
it's
gonna
affect
milestones
because,
like
it's
mostly
question
to
once,
you
tell
it's
like
if
you
are
intending
for
this
feature
to
be
shipped
in
1302
or
that
no.3
and
be
user
facing,
then
we
need
to
think
of
that,
like
hey,
if
the
proof
concept
is
not
going
to
be
user
facing
it's
not
going
to
add
user
value,
we're
not
solving
a
problem
then
effectively.
That
issue
is
not
scheduled
for
13.3
right.
B
D
D
D
D
A
Possible
I
would
like
have
to
measure
this,
because
this
is
mostly
planning
related
right,
but
I
would
like
to
dive
a
little
bit
into
that
proof
of
concept
like
what
exactly
is
gonna
be
the
goal
of
it,
how
we're
gonna
approach
it
and
how
we're
gonna
deliver
on
it
like
what
are
the
things
we
want
to
get
out
of
it
right
like
to
me
right
now.
It
sounds
like
a
great
idea,
but
I've
not
really
like
it's
a
little
bit
blurry
as
to
you
know
what
it,
what
what
is
it
gonna
be
so.
B
A
Like
the
the
intent
I
had
was
to
not
focus
at
all
on
any
user
experience,
or
at
least
not
UI,
the
experience
might
be
affected,
but
it's
mostly
like
hey.
What
are
we
gonna?
What
are
we
gonna
like
get
out
of
this
proof
concept
like
and
how
we're
gonna
approach
it
like,
because
as
far
as
I
as
far
as
I
now
know
like
and
I'm
just
grasping
here
right,
like
I've,
not
done
it,
it's
like,
like
you,
know
more
than
I,
do
it's
like.
We
have
the
API
approach.
A
We
got
the
like
the
access,
token
approach.
We
got
the
CI
job
token
that
it's
kind
of
like
mingled
in
between
I'm
trying
to
understand
like
are
we
gonna
proof
of
concept,
one
of
those
strategies
and
see
if
it
works,
and
if
it
doesn't,
we
go
on
to
the
next
one
to
see
if
that
works,
or
is
it
more
like?
No
I
have
like
one
of
those
strategies
that
is
gonna,
be
the
one
that
work
for
certain
gonna
go
with
and
we're
gonna
build
a
current
proof
concept
and
that's
gonna
answer
this.
Today's
question
so.
B
I
think
that,
of
course,
it's
complex
because
it
depends
on
how
someone
is
going
to
approach
this
proof
of
concept.
It's
possible
that
it's
going
to
be
me
and
how
I
would
do
that
is
that
I
would
take
the
solution.
That
appears
to
be
true
to
me
to
be
the
most
the
most
simple
one
and
again
the
most
simple
one.
B
It
does
not
mean
that
is
going
to
be
the
easiest
solution
that
I
can
find,
but
I'm
going
to
take
the
solution
that
feels
that
be
the
least
complex
from
the
backend
side,
which
is
not
to
introduce
a
lot
of
complexity.
New
tokens,
many
different
things,
so
I
guess
that
it's
going
to
be
taking
the
CI
job
token
and
figuring
it
out
how
we
can
augment
CI
job
token,
with
permissions
that
are
defined
somewhere
either
in
project
level.
B
D
A
A
B
It
not
not
related
to
personal
access
token,
because
personal
access,
token
solution
is
completely
separate
one,
and
it
means
that
we
would
not
actually
do
anything
with
CI
job
token.
Instead,
we
would
make
it
possible
personal
access.
Token
got
a
little
different
that
perhaps
are
more
ephemeral
and
living
and
can
be
scoped
to
some
users
like
a
Python
the
below,
but
this
concept
feels
to
be
more
complex
than
what
we
actually
need
watching.
Perhaps
it
could
be
more
flexible
in
regard
to
other
resources
that
are
not
related
to
CI
right.
B
But
perhaps
you
know
this
way
we
could
have
ephemeral
access
token.
Let's
call
it
that
way,
that
might
not
only
be
scoped
to
a
pipeline,
but
might
be
scoped
to
different
resource.
That
is
actually
hard
to
imagine
what
it
could
be,
but
this
resource
can
be
very
different,
so
I
think
that
the
usage
of
ephemeral
access
tokens
might
be
interesting,
but
it
might
also
be
kind
of
orthogonal
and
it
will
get
out
how
to
add
support
for
this
ephemeral
access,
tokens
and
figuring
it
out
how
to
solve
this
issue.
B
It
feels
like
it's
too
many
problems
to
solve
at
once.
Some
would
prefer
to
focus
on
trying
to
understand
what
can
be
done
with
CI
job
token,
and
if
it
proves
to
be
too
complex,
then
the
ephemeral
access
token
is
probably
another
solution
that
we
propose
to
you.
If
the
CI
just
talking
appears
to
be
too
complex,
but
I
I
think
it
might
not
be
too
complex.
So
that's
you
know,
that's
how
I
imagine.
B
A
Just
a
face:
what
what
I
get
is
that
you
know
CI
job
token,
from
the
first
point
of
view,
seems
like
the
approach
that
we
first
like
we
will
have
the
best
chance
with
to
figure
out
exactly
what
we
can
do
with
that.
Based
on
that,
we
would
perhaps
diverge
to
other
play
like
other
strategies,
but
ideally
we
would
figure
out
this
and
then
based
on
that,
we
can
make
decisions.
Yes
all
right!
Thank
you.
So
much.
A
You
know
like
we're:
we're
gonna
be
blocked
from
a
like
e
ux
point
of
view,
but
also
like
from
I
like
actually
solving
this
problem
until
after
proof,
concept
is
all
be
done.
So
I
think
the
remaining
question
would
be
like
how
we're
gonna
schedule
that
proof
of
concept
is
that
going
to
be
part
of
13
attitude.
D
Yes,
I'm
gonna
make
it
that's
what
we
said
earlier.
I'm
gonna
make
it
part
of
13.2
G
course
the
in
the
agenda
there
and
I'll
link
to
it
under
to
the
original
story.
If
you
can
add
the
some
technical
details
to
that
stuff
issue,
I
think
this
particular
original
issue
for
our
discussion,
making
pipeline
permissions
more
controllable,
flexible,
was
assigned
to
you
for
waiting.
D
Could
you
instead
also
admit
actually
there's
are
any
weight
that
was
put
on
the
original
issue
away
to
five?
Can
you
throw
a
possible
weight
on
the
POC
issue?
When
you
add
the
details,
no
problem,
I,
don't
think
and
I
went
ahead
and
assigned
it
to
12.13.12
planning
issue
I'll,
replace
the
original
story
that
I'm
now
promoted
to
epic
I'll,
replace
it
with
this
POC
issue
instant.
D
D
A
There
will
be
you
know,
engineering,
work
included
and
I
think
it
will
be
helpful
to
have
that
issue
planned
ahead
of
1302
and
1303
like
even
if
that's
a
little
bit
ambitious
I
think
it
is
good
to
have
that
on
that
horizon,
so
that
we
can
work
towards
that,
and
this
gives
like
a
trigger
to
UX,
to
keep
in
close
contact
with
Jago.
How
are
you
doing
with
proof
of
concept
which
anything
like
that?
We
are
already
certain
on
those
kind
of
ideas
you
have.
D
A
Currently
about
because
we're
upgrading
the
issue
to
an
attic
right,
we're
that
way
losing
track
of
the
problem
being
scheduled
for
or
problem
solution
being
scheduled
force.
The
only
thing
I'm
saying
it's
like
do
we
keep
track
of
this
beyond
30
knots,
you,
if
not,
let's
create
the
issue
and
put
it
on
a
milestone.
A
A
D
Puts
up
well,
ok,
so
I
I,
don't
I
have
to
think
about
that,
because,
if
I
put
something
out
there
for
thirteen
dot,
it'll
be
doing
about
five
because,
like
you
said,
we
have
to
allow
for
potentially
a
milestone
between
13.2
I'm.
Sorry,
it
be
13.4
allowing
for
some
UX
UI
work
to
be
happening
after
the
POC
in
its
own
milestone,
I
run
the
risk
of
moving
that
along
and
I
have
been
trying
to
avoid
pre
assigning
milestones
out
several
milestones
into
the
future.
D
C
I
hear
estar
yeah
I
think
like
we.
We
can
also
raise
this
question
about
creating
a
follow-up
issue
or
a
placeholder
after
the
PC
as
well
I
mean
yeah
I.
Think
we're
gonna
have
this
PC
scheduled
as
a
next
step,
and
we
can
make
sure
that
we
have
those
issues
created
whenever
we
are
there.
So,
let's
take
one
step
at
a
time.
A
Yeah
MLS
commented
Edward
and
doesn't
need
to
change.
Anything
like
I
understand,
fully
milestones
are
an
issue
we'll
expose
this
towards
our
users,
creating
additional
questions.
That
was
not
the
the
way
I
was
going
for
that,
but
I
think
also.
We
have
tried
to
solve
this
problem
with
our
planning
issues,
which
are
not
user
facing
they're,
actually
private
right.
So
we
don't
have
that
problem,
so
it
can
tentatively
put
issues
in
future
schedules
or
future
milestones.
D
C
C
Think
crackers
will
tall.
We
can
leave
you
as
your
eyes
for
that
right
under
now,
yeah,
just
let's
not
make
this
conversation
drab
anymore,
I
suggest
yeah.
Whenever
we
have
the
piece
you
ready,
we'll
have
the
issue
right
now
for
the
you
see,
you
will
have
the
PC
and
then
we
catch
up
I,
think
or
sink
if
needed.
So
let's
just
leave
it
at
that
sounds
good.
You
have
the
one
cool.