►
From YouTube: Discussion around CI permission audit: Fabio/Veethika
Description
Fabio and Veethika discussing the early steps in mapping CI permissions with available operations on the UI.
A
B
A
So
I
thought
maybe
that
to
to
be
able
to
do
all
of
this,
I
should
have
probably
a
structure
in
place
like
one
spreadsheet,
where
I
can
just
keep
keep
a
log
of
all
the
information
that
I
collect
and
this
struck
this
I
mean
the
process
that
I
had
defined
in
the
beginning.
It
was
very
incremental
and
I'm
also
trying
to
evaluate
how
feasible
this
would
be,
because
if
I
follow
this,
so
it
says
at
one
step,
it
says
that
map
it
with
the
permissions.
A
The
other
step
says
map
the
business
logic,
but
it
might
happen
that,
while
I'm
looking
at
an
operation
and
while
I'm
going
in
visiting
the
code
bases,
I
would
be
uncovering
different
things
which
are
related
to
that
operation.
At
the
same
time,
so
I
mean
doing
it
in
steps
means
revisiting
the
same
thing
again
and
again
anyway.
I'll
show
you
what's
the
initial
setup
that
I
have
created.
A
So
let's
say
if
we
start
with
the
pipeline
index
page,
so
I
try
to
number
like
all
the
operations
that
I
see
here
on
this
page.
There
might
be
more
and
then
maybe
like
listing
those
operations
here
and
making
a
note
of
how
are
users
able
to
perform
those
actions.
Is
it
through
ui?
Is
it
through
api?
I
am
right
now.
A
B
B
B
Mixing
is
another
scenario
which
is
now
taking
in
consideration
with
the
job
token
scope
with
the
siege
of
telescope,
which
is,
is
a
an
additional
dimension
to
the
roles
that
we
have
here,
which
is
whether
the
user
is
authenticated
by
ci
job
token.
So
you
can
be
a
developer,
but
if
you
are
authenticated
by
a
ci
job
token,
you
might
get
by
api
specifically
a
slightly
different
permission
set.
A
B
A
Got
it
and
I
mean
somewhere
after
you
made
a
remark
about
how
there
was
a
specific
action
that
you
mentioned,
that
it's
different
for
archive
projects.
So
I
went
ahead
and
I
I
think
I
read
through
in
the
pipeline
policies
somewhere
and
so
that
the
archive
projects
are
kind
of
like,
for
example,
this
there's
a
different
the
separate
condition
mentioned
for
archive
projects.
B
B
B
B
A
B
B
B
Yeah
and
then
I
think,
depending
on
the
operation
that
you
want
to
perform,
so,
for
example,
normally
a
developer
will
have
the
permission
to
play
a
job,
but
if
the
job
is
archived,
then
it
won't
be
playable
regardless,
regardless
of
the
role
and
okay.
So
it's
kind
of
certain
characteristics
of
the
model
in
this
case,
like
the
job,
might
disallow
a
specific
operation
in
the
first
place.
B
A
A
B
A
B
A
B
B
B
A
B
B
If
the
model
fulfills
certain
conditions
like,
for
example,
the
user
is
also
the
creator
of
the
pipeline,
and
then
we
will
allow
the
user
to
see
some
extra
information,
then
a
user
that
wasn't
the
creator
of
the
pipeline,
even
though
might
still
be
able
to
see
the
rest
of
the
information
on
the
pipeline.
So
certain
information
like
the
pipeline
variables
might
be
hidden.
B
Because
it's
not
a
lot
of
list,
I
think
it's
more
like
a
matrix
where
you
say:
okay,
you
can
be
developer,
but
if
you
also
are
the
the
owner,
the
author
of
the
pipeline,
you
can
see
these
other
things.
You
can
be
maintainer,
but
if
you're,
not
the
old
the
author
of
the
pipeline,
you
will
behave
the
same
way.
You
know
for
that
specific.
A
B
A
B
B
B
Use
because,
like
even
if
we
say,
run
a
pipeline
and
number
five,
it's
not
that
one
pipeline
will
be
always
available
for
maintainer
for
reporter.
I
think.
Sometimes
it
depends
whether
if
the
project,
for
example,
is
marked
as
being
being
deleted,
then
even
a
maintainer
will
not
be
able
to
run
a
pipeline,
for
example.
B
I
think
that's
part
of
the
business
logic
more
there's
a
lot
of
preconditions
to
run.
This
is
like
a
precondition.
Then.
If
everything
is
satisfied,
all
the
preconditions
succeed,
then
we
check
whether
the
user
role
has
permissions
to
run
this
action.
So
maybe
you
can
yeah.
Can
we
consider
preconditions.
B
A
B
B
B
A
B
B
A
Yes
also,
I
mean
recently,
we've
been
running
into
some
problems.
Problems
hasn't
just
some
confusions,
like
which
role
should
see
what
on
the
ui,
so
just
to
make
those
decisions
easier.
I
mean
documenting.
This
would
also
help
with
one
thing
like.
If
we
get
to
see
all
of
this
information
together
on
the
same
page,
then
maybe
we
would
be
able
to
make
more
fast
decisions
like
okay.
If
this
happens
in
this
way,
then
maybe
we
should
also
carry
this
forward.
Carry
this
decision
or
business
logic
forward
to
this
particular
operation.
B
A
B
Try
to
map
everything
I
think
could
be
complex
just
because
of
all
these
preconditions
that
would
need
to
be
evaluated
if
we
kind
of
keep
some
variables
outside
of
the
scope.
We
might
not
also
not
give
like
a
a
real
representation
of
the
case.
You
know,
because
then
there
will
always
be
scenarios
where
this
doesn't
match.
What
is
documented
and
it's
because
of
maybe
some
preconditions
that
we
hadn't
considered
and
so.
B
B
I
think
you
need
to
have
some
permissions
like
to
admin
a
pipeline,
and
this
could
be
generic,
but
also
a
little
bit
vague
to
say,
okay,
what
is
actually
mean,
maybe
like
something
like
admin.
A
pipeline
would
be
a
permission
that
represent
like
a
baseline
for
doing
certain
things
with
the
pipeline,
and
then,
if
you
have
permission
to
admin
a
pipeline,
you
automatically
cascade
into
something
more
specific,
like
creating
like
triggering
a
pipeline
with
a
specific
variable
or
which
means
like
changing
the
behavior
of
a
pipeline.
At
one
time
and.
B
Same
scenarios
would
be
with
the
red
job.
So
if
you
can
read
details
of
a
job,
then
we
could
probably
cascade
into
to
read
the
article
rather
than
using
reading
job,
it's
a
kind
of
very
generic
rule,
but
we
can
actually
cascade
into
something
very
specific
and
then,
if
really
job
is
it's
not
allowed
for?
Some
reason
then
read
that
effect
wouldn't
want
to
be
allowed
either.
B
A
Right
and
then
I
mean
we
can
start
off
with
focusing
on
the
baseline
permissions,
that's
needed
to
perform
an
operation
like
you
mentioned,
and
then
mapping
like
what
else
is
it
going
to
affect
and
what
affects
that
that
operation
so
yeah?
This
will
be
very
helpful
so
in
case,
if
you
just
have
to
introduce
anything
at
any
point
of
view.
B
B
A
B
B
B
And,
for
example,
if
you
click
on
a
job,
a
number
for
example,
or
even
somebody
sends
you
a
link
to
a
job.
The
first
thing
we
check
if,
if
you
are
of
the
project
regarding
the
job
or
pipeline,
if
you
are
part
of
the
project-
and
you
have
permission
to
read
the
project,
then
we
can
go
further
into
the
into
the
permission
checks.
But
if
this
condition
fails,
then
you
probably
see
a
404
page
directly
and
and
then
we
check
for
like
a
more
more
detailed
conditions.