►
From YouTube: GitLab Access Manager (Project FastPass) - v1.11.18 Demo
Description
GitLab Access Manager (GLAM) is the next generation of IAM and RBAC access request automation being built by GitLab IT Engineering. This is a weekly demo for the v1.11.18 iteration (CalVer).
This focuses on early scaffolding for UI design and navigation development.
https://about.gitlab.com/handbook/business-technology/engineering/#access-manager-engineering
DRI: Jeff Martin, Dillon Wheeler, Peter Kaldis
A
Hey
there,
thanks
for
taking
the
time
to
check
out
the
version,
1.11.18
version
of
project
fastpass
or
gitlab
access
manager.
Let's
have
a
look
and
see
what
we
got
today
so
in
this
iteration
we're
looking
at
the
front-end
ui.
This
is
where
kind
of
the
seeing
is
believing
starts
to
take
place,
and
so
you
can
actually
see
how
we're
going
to
see
it
from
a
user
perspective,
have
an
admin
perspective,
how
we're
bringing
in
the
css
and
the
javascript
and
really
making
it
so
that
you
can
actually
see
what
all
the
back-end
work
is
doing.
A
A
A
The
other
piece
of
it
as
well
is
the
application
that
we're
building
for
glam
is
very
much
a
security
least
privileged
design
model
and
users
should
only
have
access
to
certain
pieces.
They
shouldn't
be
able
to
see
it
all,
and
so
we
really
have
to
think
about
what
can
a
user
access
what's
audited
what's
approved?
And
we
really
have
to
give
that
a
little
extra
thought,
especially
with
the
the
nature
of
this
application.
A
So,
in
the
last
couple,
demos
you've
seen
how
we're
building
our
integrations
through
apis.
Our
database
schema
our
backend.
What
we
call
things
this
is
going
to
bring
that
forward
and
show
it
what
it
looks
like
in
the
user
interface.
So
that's
what
we're
looking
at
so
the
front
end
ui
is
a
piece
of
it.
That's
building
block
on
top
of
the
back
end
right,
so
if
you've
never
seen
how
some
of
these
programs
get
put
together
before
here's
a
little
bit
of
a
concept
overview.
A
It
doesn't
really
matter
what
the
application
is.
The
fundamentals
of
how
requests
are
processed
work
generally,
the
same
with
a
few
variations
between
languages,
frameworks
and
and
some
text
stacks,
but,
generally
speaking,
this
is
the
concept
of
how
these
things
generally
work
through
we're
not
going
to
mind
some
of
the
new
javascript
frameworks
that
do
more,
the
single
page
applications
we're
not
going
to
get
into
the
spa
world.
This
is
focused
on
more
of
the
traditional
nbc.
A
Well,
what's
going
to
happen,
is
it's
going
to
come
into
a
route
and
a
route
is
kind
of
like
a
traffic
cop
or
maybe
a
possibly
a
map,
application
that
says
you've
showed
up
in
our
city?
Where
is
it
you
want
to
go
and
it'll
have
a
list
of
all
the
addresses
that
it
can
get
to
right.
Those
are
called
routes
and
what
the
routes
are
behind
the
scenes
is
they
specify
which
class
or
which
controller?
A
If
you
will
are
you
going
to
go
talk
to
and
which
method
that
control
are
you
going
for,
and
so
it
ties
together,
the
slash
event,
tickets
to
the
event,
ticket
controller
and
the
index
method,
which
shows
a
list
of
all
the
tickets
right.
Once
it
knows
where
you're
going
and
it
validates
that
you're
a
valid
request,
it's
also
going
to
apply
some
middleware,
and
so,
if
you're
not
signed
in
it'll,
redirect
you
to
the
sign
in
page
it
handles
a
lot
of
that
request.
Processing.
A
So
in
a
way
you
could
think
of
routes
as
the
application
version
of
how
your
web
server
would
be
like
nginx
and
like
handling
a
virtual
host.
It's
a
similar
kind
of
concept,
it's
not
quite
direct,
but
if
you've
never
heard
of
it
before
it's
kind
of
what
it
is
where
it
basically
says.
Where
am
I
going
to
take
you
and
are
you
allowed
to
get
there
once
that's
been
handled,
it's
going
to
go
into
a
controller
and
a
controller
is
basically
navigating
what
data
are
you
trying
to
access?
A
What
are
you
trying
to
do
with
that
data,
and
am
I
returning
that
data
to
you
in
some
shape
or
form,
for
example,
an
html
page,
or
am
I
doing
some
action
on
your
behalf
to
save
that
data
somewhere
to
make
an
api
call
to
run
a
workflow
and
the
controller
is
doing
all
the
busy
work
of
connecting
the
dots
of
who
do?
I
got
to
talk
to
what
do
I
got
to
do
now
when
you're
inside
the
controller?
There's
a
couple
steps
that
happen
that
you,
as
a
user,
never
see.
A
Only
the
engineers
ever
see
this
on
the
back
and
when
we're
building
it,
and
that
is
generally
speaking,
you're
hitting
a
controller
to
get
data
right.
It'll
be
presented
in
a
nice,
pretty
view
which
we'll
get
to
in
a
few
minutes,
but
that's
basically
going
over
to
our
object,
relationship,
mapping
system
and,
if
you've,
seen
an
active
record
if
you're
familiar
with
eloquent
it
doesn't
matter
what
the
system
is.
A
It
basically
connects
the
model
to
the
database,
and
so,
if
you
have
a
sql
database
table
and
you
have
models
and
define
all
the
relationships
and
what
fields
you
have
it's
doing
all
the
busy
work
in
the
black
magic.
If
you
will
to
connect
and
says
I
want
to
get
a
list
of
event
tickets,
I
know
it's
in
the
event
tickets
database
table
what
I
need
to
do
to
get
that
you
go
talk
to
the
model.
The
model
tells
you
what
you
can
or
can't
get
defines
all
those
pieces.
A
The
model
will
then
talk
to
the
database
table,
grab
the
data
that
you're
requesting
bring
it
back
to
you
and
then
bring
it
back
all
the
way
to
the
controller.
Now
the
controller
is
going
to
get
an
object
or
an
array
of
that
data.
Think
of
this,
if
you've
ever
seen,
a
yaml
or
json
come
back
and
it's
got
a
couple
key
value
pairs.
It's
got
a
list
of
items
that
happened
through
the
orm.
A
It
went
into
the
database
and
brought
that
data
back
whether
you
do
this
in
a
front.
End
application
like
we're
doing
today,
whether
you
do
this
with
an
api
that
returns
a
rest
endpoint
with
json
data.
It's
all
fundamentally
the
same.
The
presentation
layer
is
going
to
vary,
but
the
backend
fundamentals
are
the
same.
A
A
This
is
json,
which
is
really
simple,
or
am
I
going
to
put
this
into
a
template
file,
and
that
has
variable
placeholders
of
where
I'm
going
to
drop
these
values
into
we're,
going
to
look
at
the
details
of
that
in
a
minute
once
it
says
this
is
the
template
I
want
to
use.
It's
then
going
to
plug
all
those
variables
in
from
our
data
source
into
that
template
and
then
render
it
together.
A
Combine
it
together
into
what's
called
the
rendered
view
that
may
be
cached
that
may
not
be
depending
on
the
application
and
then
that
effectively
is
the
html
that
you
then
see
that
renders
out
in
your
browser.
So
it'll
return.
It
all
the
way
back
through
your
web
server
back
into
your
browser,
and
so
you'll
then
see
here's
the
the
template.
Here's
the
view:
here's
the
html
template
that
we
had
here's
the
data
we
got
from
the
database.
A
A
How
does
a
full
stack
application,
get
data
process,
data
et
cetera,
so
understanding
some
of
these
components
with
controllers
routes
and
views
is
really
helpful
in
understanding
what
we're
working
on
what
we're
talking
about
today
right,
I
don't
want
to
spend
a
lot
of
time,
I'm
going
to
pause
here
for
a
minute.
So,
if
you'd
like
to
stop
the
video
and
kind
of
read
through
some
of
the
details,
this
is
just
drilling
down
and
double
clicking
on
that
summary
workflow.
We
saw
a
moment
ago
where
the
web
server
receives
the
request.
A
It
goes
into
the
route
we
define.
What
the
route
is,
what
controller
it's
going
to
use,
what
method
is
going
to
handle
it?
Look
inside
that
controller.
This
is
how
we
get
that
data
and
here's
what
we're
going
to
return
once
we
have
that
data
as
an
array
right,
that's
what
we're
going
to
end
up
working
with
today,
as
we
pass
it
over
where
to
do
that
event:
tickets!
It's
going
to
go
over
to
the
model.
It
knows
which
database
table
to
go.
A
The
views
are
what
we're
going
to
spend
a
little
more
time
on
today,
because
at
the
end
of
the
day,
remember
that
front
end
user
experience,
we're
always
going
to
be
iterating
upon
this.
We're
always
going
to
be
making
it
better,
improving
it
adding
more
functionality,
but
the
backend
fundamentally
doesn't
change.
We
just
changed
the
way
that
we
present
the
data
to
make
it
more
user-friendly
right.
That's
what
front-end
develop
is
focused
on
doing
design
development
user
experience.
All
those
pieces
are
combined
together
to
make
it
easy
for
the
user
to
do
their
job.
A
So
where
we're
going
to
care
about
is,
in
the
view
file
itself,
we
need
to
work
through
and
look
at
some
of
that.
So
once
the
controller
has
the
template
that
it
needs
it's
you'll
see
you
recognize
the
html
here
we
have
a
very
simple
table
if
you've
ever
seen
a
table
or
a
tr
td
tag.
That's
all
this
is
and
we're
simply
looping
through
that
array
of
tickets
that
we
have
and
it's
going
to
go
down
and
say.
A
Okay,
that
database
table
gave
me
back
the
id
the
ticket
holder
name,
the
price
of
the
ticket.
Did
they
attend?
Do
they
not
attend
right
and
then
simply
loop,
that
into
the
table?
The
controller
will
then
process
that
data
combine
it
together
to
spit
back
the
exact
rendered
cache
view
that
you'll
see
in
your
browser
right.
A
We
can
change
this.
Maybe
this
table
is
more
interactive.
Maybe
I
actually
want
to
see
a
spinning
wheel
of
you
know.
Is
this
ticket?
Are
they?
Where
are
they
at
in
the
in
the
you
know,
theater
or
the
event
center
right
now
right,
there's
different
functionality,
we
can
add,
we
can
add
workflows.
We
can
have
different
pieces
with
this
data,
so
as
you
iterate
through
building
an
application
over
time,
you're
going
to
add
more
and
more
functionality,
the
data
doesn't
change
the
way
you
render
it
does
so.
A
A
So
we
set
that
stage,
and
so,
if
you're,
if
you
don't
really
understand
what
this
is,
you've
never
seen
this
before.
That's
totally.
Okay,
it's
not
going
to
be
overly
important
for
this,
but
if
you're
wondering
hey,
if
I
was
to
remember
this
in
a
nutshell,
these
are
kind
of
the
13
steps
to
remembering
it
right
brings
the
request
in
goes
to
the
routes
to
the
controller
over
to
the
model.
A
Get
data
from
the
database,
bring
it
back
to
the
controller
figure
out
what
view
we're
going
to
compile
that
all
together
with
our
template
variables,
then
return
it
back
through
the
web
server.
So
that's
what
we're
going
to
work
with
right.
Okay,
we've
got
all
that
down
now.
What
are
we
working
with
today
that
relates
to
this?
So
in
previous
demos
we
talked
about
database
migrations
and
those
models.
We
created
those
earlier
right
now
we're
looking
at
creating
those
controller
routes
and
views
if
you've
ever
heard
of
rest
api
resources.
A
What
those
basically
are
is
that
it's
a
common
nomenclature
for
index
get
create,
store
edit
update,
delete
and
restore.
It
basically
is
a
every
rest.
Api
generally
follows
these
conventions,
or
should
this
says
this
is
what
we
call
when
we
not
manipulate
records.
The
index
may
also
be
called
list.
Get
is
to
get
a
single
record.
A
If
you
have
data
loss,
you
do
soft
delete,
you
could
do
a
restore
to
simply
toggle
a
flag
and
the
data
will
come
back.
There
are
also
destroy
commands
that
bear
a
permanent
deletion
they're
out
of
scope
for
the
conversation
today,
but
essentially
our
controller
or
route
and
review
are
going
to
match
this
nomenclature.
As
we
go
through
today,
you're
going
to
see
a
lot
of
the
show
method
show
and
get
are
the
same
thing.
It
just
depends
on
which
nomenclature
we're
using,
depending
on
the
system
that
we're
in
right
all
right.
A
Let's
have
a
look
at
what
this
really
is,
so
we're
going
to
jump
to
the
demo
pretty
quick
today
and
what
I
want
to
share
with
you
is
from
the
web.
Ui
perspective
we're
going
to
sign
in
with
octa,
so
we
now
have
our
authentication
working
we're
going
to
view
user
profile
data.
So
what
do
we
get
from
octa
when
we
bring
that
data
in
and
then
we're
going
to
look
at
just
kind
of
navigation?
A
That
can
happen
once
we've
kind
of
glanced
at
how
the
ui
looks.
We're
then
going
to
apply
some
of
the
knowledge
we
looked
at
a
few
minutes
ago
into
how
the
source
code
works,
and
this
is
explicitly
going
to
look
at
the
routes,
the
controllers,
getting
the
data
from
the
model,
the
views
and
the
permissions.
A
A
Wherever
that
went
lovely
we
want
this
here
we
go
and
that's
how
demos
work
when
things
are
set
up.
So
this
is
the
octa
login
screen
right
for
gitlab
access
manager.
We
are
running
this
in
a
local
development
environment.
We've
connected
to
our
octa
sandbox
instance-
and
I've
already
put
my
credentials
in
here
to
be
able
to
sign
in
so
when
I
click
on
sign
in
it's
going
to
take
me
to
the
gitlab
access
manager,
dashboard
and
the
reason
it's
throwing.
A
This
is
the
joy
of
live
demos.
When
you
try
to
prepare
things
and
you
have
authentication
and
security
and
crsf
requests.
So
it
already
did
my
authentication
for
me.
It
just
had
a
bad
token.
I've
refreshed
we're
now
back
to
a
good
state,
so
once
you've
signed
in
remember.
This
is
early
development
right
once
you've
signed
in
you're
going
to
land
up
on
the
user
section
of
it,
and
this
is
where
all
of
our
team
members
are
going
to
have
access
to,
and
we
don't
have
anything
in
our
dashboard
yet.
A
But
if
I
go
to
the
my
profile,
I'll
see
one
of
the
early
or
early
iterations
or
incarnations
of
what
this
data
gives
me.
So
this
is
kind
of
my
octa
profile
data,
and
so
what
octa
knows
about
me
is
all
this
raw
data
down
below
and
we
share
this
more
for
the
you
know.
Basically,
if
you,
if
you
see
something,
that's
a
problem,
why
does
it
show
in
the
ui
here's
what
octa
knows
about
us?
It
may
be
coming
up
from
the
hrs
behind
the
scenes.
It
allows
us
to
troubleshoot
faster.
A
If
you
can
see
the
raw
data
right
over
on
the
right,
it
knew
that
my
manager
is
peter.
It
then
worked
its
way
up
through
the
octa
database
figuring
out
that
peter's
manager
is
rob,
then
brian,
then
brian
and
then
sid,
and
so
what
that?
The
reason
that
we
share
that
information
in
here
is,
depending
on
the
approval
that
you
need
to
access
something
it
may
require
a
certain
level
of
approval.
A
Sometimes
that's
your
manager,
sometimes
it's
higher
than
your
manager,
but
we
needed
a
systematic
way
to
know
that
it
needs
a
vp
approval,
for
example,
or
it
needs
a
senior
director
approval
depending
on
the
level
of
the
job
title.
We
simply
gave
it
an
integer
from
one
through
ten,
each
user
is
a
one.
Their
manager
is
a
two.
Then
it
goes
to
senior
manager
system
owner
director
senior
director
vp
working
its
way
up
through
the
e-group
all
the
way
to
the
ceo.
A
We
don't
expect
we're
ever
going
to
have
a
lot
of
level
10
and
level
9.
However,
we
want
to
put
that
in
there
from
a
security
perspective
in
interest
of
our
safe
framework
and
some
of
the
data
that
users
may
be
able
to
get
access
to,
depending
on
the
sensitivity
of
it.
If
it's
not
part
of
the
normal
job
role,
so
that's
why
it's
what
it's
there
for
it
also
lets
us
go
in
and
view
the
organization
chart
and
work
our
way
through
that.
A
So
that's
how
the
user
profile
works.
There's
other
areas
in
here
that
we're
not
going
to
spend
any
time
in
today,
but
it
basically
says.
Let
me
show
me
everything
of
how
I'm
connected
what
applications.
I
can
see.
Look
at
my
credentials
for
that
application
or
a
link
to
use
sso
to
sign
in
any
approvals
I've
done
in
the
past.
Any
active
approvals
will
show
up
on
the
current
dashboard
and
then
in
the
audit
logs.
A
You
can
see
everything
that
gitlab
access
manager
has
done
for
you
right,
there's
other
areas
of
here
we're
not
going
to
spend
much
time
looking
at
all
of
them.
We're
going
to
look
at
admin,
real,
quick,
just
kind
of
get
a
glance
right,
and
so,
if
I'm
in
an
admin
view,
obviously
this
will
be
restricted
to
just
a
few
people
is
I'll,
then
be
able
to
see
all
the
different
database
records,
and
this
is
where
that
database
model
that
we
did
before
this
is
where
that
dot
connects.
A
But
that's
the
scaffolding
we
were
working
on
this
week
is:
can
we
get
it
so
that
we
can
navigate
around
and
then,
depending
on
the
links
that
we
have
here
right
now?
My
user
is
an
admin
as
I
remove
different
features
and
functionality
that
navigation
menu
is
going
to
change.
It's
going
to
reduce
and
restrict
what
I
can
access,
and
so,
if
I
go
into
the
database,
I'm
going
to
do
this
off
screen
for
just
a
second
and
I
go
into
the
off
group
or
the.
A
I
should
correction,
the
auth
role
for
what
I'm
looking
at
here,
I'm
going
to
edit
the
permissions
table
and
what
I'm
going
to
specifically
do
is
I'm
going
to
remove
the
audit
and
the
my
team
from
this.
So
if
I
remove
team
and
remove
audit
permissions,
and
so
as
a
user,
I
can
no
longer
access
that,
and
when
I
refresh
this
page,
you
notice
those
icons
on
the
left
are
no
longer
there.
A
Every
user
when
they
come
in,
is
going
to
start
with
my
profile.
They'll
get
elevated
privileges
depending
on
the
role
they're
in
if
they
have
a
team
depending
on
what
you
need
to
access
right
and
everyone
will
obviously
be
able
to
do
docs
and
support.
So
that's
kind
of
the
functioning
out
of
the
ui.
A
Now,
if
I
just
remove
get
get
out
of
here
for
a
second
and
let's
have
a
look
at
that
code,
and
so
if
I
bring
that
back
up,
is
we've
got
a
couple
of
files
in
here,
so
we
know
that
from
a
route
perspective,
we
came
in
through
a
couple
different
paths,
one
that
we
were
just
looking
at
is
admin
slash
dashboard,
and
what
that
was
focusing
on
is
what
am
I
seeing
as
an
admin
when
I
first
land,
that's
the
url
I'm
expecting.
Where
is
it
going?
A
It's
going
to
go
to
the
dashboard
controller
and
then
go
to
show,
and
then
the
name
here
is
simply
an
internal
name.
We
use
in
our
system,
so
we
can
generate
dynamic
links
for
all
the
href
links
throughout
the
application
to
get
to
that
page
without
dealing
with
some
of
the
dynamic-ness
of
dropping
in
variables
or
ids,
or
anything
of
that
nature.
Right
now
we
were
just
on
the
auth
admin
dashboard.
A
What
I
want
to
share
with
you
is
this
route
and
following
this
on
our
way
through.
So
if
I
go
to
the
dashboard
controller,
so
it
says
go
to
the
dashboard
controller
and
look
at
the
show
method.
If
I
go
to
that
dashboard
controller,
here's
that
show
method.
It's
where
we
saw
the
this
is
the
off
dashboard
and
it
showed
the
one
row:
it's
one
table
row,
it
wasn't
formatted,
but
it
showed
the
auth
user.
What
this
is
doing
is
going
into
our
database
table.
This
is
where
that
model
comes
in.
A
A
This
is
what
we
call
view
partials
and
if
you
ever
use,
ginger
templates
they're
very
much
the
same
thing
where
you
can
basically
break
up
your
html
in
different
sections
for
don't
repeat
yourself,
time
mentality,
and
so
we
have
all
of
our
html
here.
It
drops
all
the
navigation
all
the
different
pieces
in
and
then
down
toward
the
bottom.
We
have
yield
content.
What
yield
content
is
doing.
It
says:
go
to
this
page,
look
for
the
section
calling
content.
It'll
then
do
that
and
we're
extending
that
template
right.
A
So
that's
the
pieces
that
go
into
this.
This
is
very
basic
from
a
introductory.
You
know
demo
perspective,
but
we've
just
got
all
that
scaffolding
and
to
be
able
to
navigate
around
handle
the
permissions
start
working
on
the
navigation
start
building
on
our
dashboard
pages
and
it's
very
early
in
our
journey
right.
But
this
kind
of
shows
you
a
taste
of
where
we're
at
so
with
that.
That's
what
we
want
to
share
today.
A
We
have
a
lot
of
different
pieces
in
here
we're
starting
to
touch
the
front
end,
a
lot
of
it's
open
to
our
imagination
right,
so
our
functionality
that
we're
working
right
now
is
this
core
scaffolding
we're
going
to
get
better
over
time.
We're
going
to
do
a
lot
more
over
time,
but
it
kind
of
gives
you
a
preview
of
where
we're
going.
So
with
that,
thank
you
so
much.
I
hope
you
enjoyed
this
and
feel
free
to.
Let
us
know
if
you
have
any
questions
have
a
great
day.