►
From YouTube: GitLab Administration on SaaS
Description
Learn how to manage groups, projects, permissions, and more as you embark on your journey as an Owner in GitLab SaaS. In this session, you will learn what you can and cannot control and customize on the SaaS platform, and come out a SME in administration.
A
Hi
everyone
looks
like
we
have
people
joining
us,
we're
going
to
give
just
another
minute
or
so
for
folks
to
jump
in
and
then
we'll
get
started.
Thank
you.
A
Great,
let's
go
ahead
and
get
started
like
I
said
thanks
everyone
for
joining
us
today.
We're
excited
to
to
go
through
this
session
with
you
just
a
couple
of
housekeeping
items.
First
off
I
wanted
to
let
everyone
know
that
this
session
is
being
recorded
and
it
will
be
sent
out
in
the
coming
days.
So
you
can
look
forward
to
that.
A
Additionally,
if
you
have
any
questions
that
come
up
throughout
this
session,
please
feel
free
to
put
those
in
the
q
a
portion
of
zoom.
We
should
have
some
time
at
the
end
to
get
those
answered
and
there's
there
are
some
folks
on
the
call
that
will
help
answer
throughout
as
well.
B
B
For
today
there
are
folks,
you
know
you
all
who
are
employees
of
companies
that
are
using
gitlab
sas
and
perhaps
you've
been
tasked
with,
like
an
administrative
role
and
you're,
not
quite
sure
how
to
do
that
on
our
platform.
So
we'll
give
you
some
good
starting
tips
of
getting
kicked
off,
or
you
know
general
refresher
points
as
well
out
of
scope
for
today's
session
is
going
to
be.
You
know,
detailed
user
provisioning,
so
your
sso
setup
or,
if
you're,
using
octa
or
something
like
that.
B
B
B
To
you
know,
planning
and
tracking
the
progress
of
your
projects
to
ci
cd
for
building
and
testing
and
delivering
delivering
your
applications
to
an
open
source
community
where
you
can
contribute
to
gitlab
as
a
platform.
So
we
are
one
platform
that
encompasses
many
different
facets
of
a
software
development
lifecycle.
B
B
B
B
So
kind
of
diving
into
like
the
pros
of
gitlab
sas.
The
infrastructure
is
entirely
managed
by
gitlab,
so
you
don't
have
to
install
any.
You
know
you
don't
necessarily
have
to
install
your
own
runners.
You
can
use
shared
runners
for
your
jobs,
you
don't
have
to
set
up
ajo,
etc.
It's
all
completely
managed
by
our
engineers
at
gitlab.
B
B
The
recovery
is
also
managed
by
gitlab.
So
in
terms
of
backups
and
such
you
don't
have
to
manage
that,
you
make
sure
that
your
data
is
safe
and
secure
doesn't
go
anywhere.
You
don't
have
to
worry
about
your
backups
and
finally,
there's
no
barrier
to
entry.
You
just
have
to
pick
the
subscription
level
that
you
want
or
the
license
tier,
that
you
want
and
the
number
of
seats
that
are
required
as
well.
So
there
is
no
setup
required.
You
just
sign
up
and
get
started.
B
So
if
we
compare
sas
versus
self-managed,
there
are
some
key
differences
in
making
this
choice
and
also
knowing
what
your
limitations
are
and
your
advantages
are
specifically
again
around
sas.
The
infrastructure
is
managed
by
git
lab
in
terms
of
high
availability
instance
level.
Backups
and
recovery
is
all
managed
by
us.
However,
if
you're
on
self-managed
you
can
be,
you
know
you
can
use
kind
of
whatever
you
want
for
your
overall
infrastructure
reporting
and
your
devops
adoption
reports
do
look
different
across
sas
and
self-manage.
B
Essentially,
you
can
only
see
the
group
and
project
level
adoption
and
any
reporting
is
only
going
to
be
at
that
top
level
group
or
sub
group
or
project
level.
You
can't
see
an
instance
level
view
because
you
don't
really
have
an
instance
on
gitlab
sas
again
instance
wide
settings,
so
any
setting
for
users
is
going
to
be
the
same
across
the
board
for
sas.
You
don't
have
those
those
custom
settings
across
an
instance
access
control,
so
in
this
case
your
custom
as
a
customer,
you
are
a
group
owner
versus
an
admin.
B
So
there
is
an
initiative
to
kind
of
have
feature
parity
between
sas
and
self-managed.
This
is
something
called
get
lab
workspace.
It
is
very
much
in
the
early
stages.
However,
it's
trying
to
achieve
a
top-level
namespace
where
you
can
manage
applying
settings
across
all
your
projects
and
groups,
aggregating
data
across
groups
and
projects.
B
We
try
to
you,
know,
make
things
work
for
gitlab
sas
and
have
that
kind
of
trickle
down
into
the
self-managed
so
that
we're
not
building
for
two
different
architectures,
so
in
general,
we're
trying
to
move
into
this
workspace
phase,
where
you
can
have
a
little
more
of
that
high
level
control,
but
that
is
very
early
on
in
the
process.
However,
it
is
in
our
roadmap.
B
So
important
to
talk
about
support
when
things
go
wrong
right
and
what
our
logistics
look
like.
So
in
terms
of
sas,
our
upgrade
schedule
is
that
we
release
the
22nd
of
each
month.
However,
sas
is
upgraded
more
frequently
than
those
you
know,
minor
releases
and
major
releases
that
come
out
minor
in
case
every
month.
Major
every
year
you
can't
block
a
sas
upgrade
from
happening.
You
can't
prevent
a
software
update.
Essentially,
however,
you
are
the
first
to
get
patched
in
the
case
of
any
security
updates.
B
B
How
and
where
our
production
databases
are
backed
up
every
24
hours,
with
increa,
with
continuous
incremental
data
at
60
second
intervals,
so
pretty
frequently
and
they're
streamed
into
google
container
service,
the
backups
are
encrypted,
so
your
data
is
always
secure
and
they
follow
the
life
cycle
shown
here
on
screen.
B
Snapshots
of
our
file
systems
are
taken.
Every
four
hours,
which
primarily
contains
your
repo
data,
also
has
some
other
data
as
well,
and
these
snapshots
are
retained
for
30
days
and
we
do
promise
that
nine,
nine,
nine,
nine
nine
nine
nine
percent
durability
for
our
backups.
So
your
unit
is
definitely
secure.
But
it's
good
to
know
the
details
when
you're
not
managing
this
yourself.
B
Let's
talk
about
support
very
important
again,
if
you
don't
have
access
to
those
logs
to
triage
issues
on
your
own
you're,
going
to
want
to
know
how
to
interact
with
gitlab
support
and
what
the
tiers
are
so
here
are
our
tiers
generally.
Any
paying
customer
is
on
a
premium
or
ultimate
plan
and
both
have
priority
support.
B
So
these
are
different
reply
times
and
slas
based
on
the
support
impact
and
the
severity
of
the
ticket
opened.
However,
you
do
have
access
to
those
slas
and
support
engineers
will
get
back
to
you
on
any
issues
that
you
may
have
here
are
some
of
those.
So
in
the
case
of
an
emergency,
you
do
have
a
30
minute
response
time,
sla
right,
not
time
to
fixing
issue,
but
at
least
a
response
time.
24
7..
B
B
So,
like
I
said
well,
what
happens
if
gitlab.com
itself
is
down
or
any
other
facet
of
it?
We
do
track
the
status
of
gitlab.com
at
status.gitlab.com,
which
tells
you,
if
anything
is
not
operational
and
it
goes
past,
just
the
website
of
gitlab.com.
It
also
tells
you,
you
know:
api
status,
skid
operations,
many
other
facets,
even
I
think
our
wikis
are
tracked
in
terms
of
their
operational
status.
If
you
just
check
that
out,
you
can
see
that
you
are
able
to
see
the
status
of
everything
related
to
our
com
service.
B
You
can
also
subscribe
to
updates
via
email.
So,
if
you're,
an
administrator
for
your
company,
you
might
want
to
subscribe
or
subscribe
to
an
email
list
so
that
you
can
get
the
latest
updates
of
anything
going
down
or
you
can
also
configure
a
web
hook
that
posts
a
json
payload
to
any
url,
and
you
can
configure
slack
updates.
So
if
anything
goes
down,
you
get
notified
on
slack.
If
you
have
a
support
slack
within
your
company,
there
is
a
lot
of
options
for
subscribing
to
updates
on
the
status
of
gitlab.
B
Let's
jump
into
the
licensing,
I
have
gotten
questions
about
this
before
you
cannot
mix
and
match
your
sas
license
right.
So
you
pick
if
you
are
a
premium
customer
all
of
your
users
in
your
name,
space
are
at
the
premium
tier,
so
you
can't
mix
and
match
the
tier
levels.
You
know
get
a
couple
people
and
ultimate
a
couple
people
on
premium:
it's
not
quite
how
it
works.
It's
across
your
whole
namespace
right,
so
you
can't
have
a
separate
sas,
like
instance,
necessarily
if
you
have
a
namespace
that
is
a
premium
one.
B
You
pay
for
the
subscription
according
to
the
maximum
number
of
users
assigned
to
that
top
level
group,
you
can
add
or
remove
your
users
during
your
subscription
period,
but
as
long
as
that
users
doesn't
go
past.
The
total
number
that
you're
allotted
in
that
given
time
it
shouldn't
exceed
the
subscription
count.
B
B
Every
user
is
counted
in
the
seat
usage,
something
that
you
can
also
track
within
gitlab
as
well,
including
users
who
are
pending
approval
if
they
have
a
guest
role,
never
mind,
except
with
a
few
exceptions.
So
if
users
are
pending
approval
into
a
group
or
project,
those
users
do
not
count
toward
your
license.
B
If
you
have
a
guest
role
in
ultimate
ultimate
allows
for
unlimited
free
guest
users,
so
you
do
not
need
to
worry
about
those
in
your
seat
usage,
any
service
account
that
is
created
or
any
bot
users
spot
users
for
projects
or
groups.
None
of
those
will
be
contributed
to
your
overall
seat
usage,
and
you
can
also
monitor
that
as
well
in
the
settings
screen
settings
usage
quotas
seats
to
make
sure
that
you're
not
going
over.
You
don't
have
people
being
added
to
projects
and
they
are
no
longer.
You
know
necessary
there.
B
B
So
let's
get
into
the
bulk
of
our
talk.
How
does
administration
work
gitlab
sas
and
what
does
it
mean
to
be
an
admin
on
gitlab.com
again
you're
not
going
to
be
called
an
admin
on
gitlab.com
only
if
you're
on
a
self-managed
instance,
do
you
have
a
literal
advent
role
right?
So
if
you
see
that
anywhere
in
our
documentation
that
might
not
apply
to
you
because
you're
not
on
a
self-managed
instance
of
gitlab.
B
Instead,
though,
you
can
have
a
role
in
a
group
and
that
you
could
be
a
maintainer
or
more
likely
an
owner,
so
the
owner
role
is
very
similar
to
an
admin
and
capability
and
function
on
gitlab
sas
important
to
know
administrators
can
do
quite
a
lot
on
the
gitlab
instance.
They
can
impersonate
users.
So
I
could
say
that
I
am
someone
else
doing
something
on
self-managed
can't
do
that
on
sas.
You
can
revoke
access
tokens
on
self-managed
that
are
created
and
view
if
they're
created.
B
B
Creating
users,
so
you
know,
if
you've
set
up
gitlab,
you
need
to
create
users,
you
need
to
add
folks,
you
can
invite
users
by
email
or
you
can
have
them
create
their
own.
B
Gitlab.Com
and
add
them
directly
to
your
groups,
you
can
also
set
up
your
skin
provisioning,
octa,
azure,
etc.
We
have
some
documentation
on
how
to
do
that.
But
generally
you
just
have
to
focus
on
users
as
accounts
that
are
not
managed
by
you
kind
of
like.
Let's
say
you
create
an
account,
you
know
with
your
email
et
cetera.
I
I
can't
control
the
account
you
create,
but
I
can
add
you
to
certain
projects
and
groups.
So
that's
more
of
your
goal
as
an
administrator
here
at
sas.
B
So,
let's
dive
in
to
the
different
types
of
roles,
first
off
is
the
guest
role.
So
guests
are
not
contributors
to
private
projects.
They're,
not
you
know
pushing
code,
they're,
not
contributing
to
anything
specific
they
can
see,
and
they
can
leave
comments
on
issues
that
is
pretty
much
it
and
gitlab
ultimate
does
provide
those
free
guest
users.
So
that's
a
really
great
option
for
folks
who
don't
need
so
much
visibility
into
a
project,
but
they
do
want
to
be
members
of
it.
B
B
Developers
are
typically
the
lowest
level
that
are
used
in
projects
because
they
are
the
direct
contributors.
They
have
access
to
everything
that
allows
them
to
go
from
ideation
to
production
within
a
project
unless
something
has
been
explicitly
restricted
by
an
owner
such
as
you
know,
protecting
a
branch.
They
can't
push
to
maine
directly
if
the
main
branch
was
protected,
et
cetera,
so
there's
certain
things
that
they
cannot
do,
but
they
can
be
productive
and
do
their
jobs
as
developers
with
the
developer
role.
B
B
So
again,
these
permissions
can
only
go
higher
greater
than
or
equal
to
what
you
have
in
that
group
level.
However,
if
you're
an
owner
in
a
group,
you
can
only
be
an
owner
in
all
subgroups
and
projects,
so
once
you're
an
owner
as
you
go
deeper
into
the
tiers,
you
are
kind
of
an
owner
for
everything.
B
So
our
general
recommendation,
because
folks
ask
you
know
what
do
I
do
with
this?
In
terms
of
setting
up,
you
know
my
permission:
hierarchy
as
you're
getting
started.
You
want
to
use
that
principle
of
least
privilege
right.
So
the
higher
up.
You
are
that
top
level
group.
You
know
your
overall
get
lab
group.
Let's
say
you
start
with
that
lower
permission
and
then
you
increase
it
at
the
deeper
levels.
B
So
maybe
I'm
a
you
know
reporter
at
the
highest
level
group,
but
in
some
lower
levels
I
am
a
developer
and
maybe
even
at
some
subgroups
I
am
a
container
or
even
an
owner.
So
we
generally
recommend
that
principle
of
least
privilege
across
the
board
and
that
ties
in
nicely
to
permissions
only
going
higher
as
you
go
deeper
into
the
tree.
B
B
B
So
I
could
not
invite
someone
to
be
an
owner
right
or
something
higher
than
that,
and
only
owners
and
maintainers
can
actually
update
group
or
project
permissions.
So,
as
a
developer,
I
would
not
be
able
to
update
someone's
permission
level.
I
have
to
have
at
least
that
maintainer
access
to
do
that
and
the
maximum
role
drop
down
is
only
enabled
for
direct
memberships.
B
B
So,
let's
dive
into
subgroup
two,
I
am
a
maintainer
in
subgroup
two,
because
I
was
added
directly
as
a
detainer
and
within
subgroup
2.
There
is
one
project
a
where
I
am
a
maintainer,
which
I
inherited
from
subgroup
2..
So
you
can
kind
of
see
that
the
only
way
my
permission
level
changed
was
that
I
was
directly
invited
at
a
higher
level
of
permission
which
in
this
case
maintainer
is
higher
than
developer.
B
Everything
makes
sense,
however,
I'm
still
just
a
developer
in
project
b,
because
I
inherited
that
from
my
top
level
group.
So
it's
important
to
note
that
I
inherited
the
top
level
group
permission
and
not
from
subgroup
one.
So
it
would
show
up
as
me,
inheriting
from
top
level
group,
because
nothing
changed
between
top
level
group
and
my
inherited
permission
and
subgroup
one
so
smart
and
knows
that
I
was
a
dever
all
the
way
top
level
group
and
that
hasn't
changed.
It
just
propagated
down
to
project
b.
B
So,
let's
see
what
that
looks
like
in
gitlab.com
and
not
just
in
a
diagram
here
I
am
I'm
sam.
I
was
added
as
a
direct
member
as
a
developer
here
to
the
top
level
group,
sam
top
level
group
by
this
owner,
who
is
also
me,
but
we're
going
to
be
looking
at
this
top
user
here
and
you
can
see
that
as
an
owner.
I
think
I
believe,
I'm
logged
in
as
the
owner
here.
I
could
remove
the
developer
sam
from
this
group
if
I
wanted
to,
but
I
don't
want
to.
B
So
you
can
see
the
developer
permission
trickles
into
subgroup
one.
So
if
I
dive
from
the
sam
top
level
group
into
subgroup
one
and
look
at
the
group
members,
I
can
see
that
I
am
still
a
developer
in
my
maximum
role.
I
can't
adjust
in
the
drop
down
here
because
I
inherited
this
permission
from
top
level
group.
B
And
it
shows
my
access
was
granted
one
minute
ago,
in
this
case
by
it's
a
little
confusing
because
they're
both
samworth's,
but
it
was-
I
was
granted
by
the
owner
sam
morris,
who
gave
me
access
to
subgroup
one.
B
So
you
can
see
that
my
developer
permission
stays
the
same
all
the
way
from
the
top
level
group
into
project
c.
So
now
I
am
inside
a
project,
I'm
no
longer
in
a
group.
You
can
see
project
members
right
here
and
I'm
still
a
developer
and
my
source
is
still
top
level
group,
as
nothing
has
changed
from
then
I'm
still
listed
as
a
developer.
B
However,
I
was
directly
added
as
a
maintainer
to
subgroup
two.
So
now
we're
in
subgroup
two
within
the
top
level
group,
and
you
can
see
that
the
source
changed
from
sam
top
level
group
to
direct
member.
So
someone
directly
added
me,
you
can
see
when
the
access
were
granted
in
by
whom
and
then
this
maximum
roll
drop
down
is
here.
So
I
can
only
see
this
maxwell
drop
down
because
I'm
logged
into
my
owner
account
and
I
could
adjust
it
here
to
a
different
level
of
access.
B
And
you
can
see
that
I
inherited
my
maintainer
permission
from
subgroup
2..
So
since
that
was
changed
to
container,
I
can
now
see
it
within
project
a
here
that
I
am
a
maintainer
and
that
the
source
has
changed
to
subgroup
one
and
within
subgroup
one
subgroup,
two.
I
was
changed
to
a
maintainer
previously
and
now
I
propagated
down
into
project
a's
role.
B
So
how
do
we
add
and
change
owners
of
a
group
right?
So
let's
say
you
know
what
you
want
to
make
someone
into
an
owner.
They
want
that
same
administrative
permission
that
you
might
have.
If
it
is
possible
you're
on
boarding
a
new
admin,
you
need
them
to
have
the
owner
permission
role.
How
do
we
do
this?
Owners
can
only
be
added
at
the
group
level,
so
they
can't
be
added
at
the
project
level.
Only
at
the
group
or
subgroup
level,
and
once
an
owner
is
made
an
owner.
B
They
cannot
modify
their
membership
in
projects
or
be
reinvited
the
project
as
anything
lower
than
an
owner.
So
again
you
will
stay
an
owner
and
you
can't
change
your
permission
level.
Even
as
an
owner,
you
will
only
be
an
owner
of
any
projects
and
groups
once
you
are
added
to
the
top
level
group
as
an
owner.
B
So
at
the
group
level
an
owner
can
leave
or
decrease
the
membership
of
a
different
owner,
but
they
cannot
adjust
their
own
membership
in
the
projects
and
this
new
permission
will
trickle
down
into
subgroups
and
projects.
So
at
the
group
level
you
can
change
it,
but
you
can't
change
it
at
the
project
level.
At
the
project
level,
you
can
leave
the
project
right,
so
you're
no
longer
a
member
of
the
project,
but
you
couldn't
have
decreased
your
membership
there.
You
have
to
leave
so
group
level
leave
or
decrease
strategy
level
leave
the
project.
B
B
So
you
want
to
be
able
to
switch
that
back.
So
if
you
make
someone
an
owner
in
a
group,
they
become
an
owner
of
all
those
subgroups
and
projects,
so
you
can
just
switch
them
back
to
that
original
permission
level
at
the
group
level,
and
then
the
previous
permissions
will
actually
restore,
including
any
direct
memberships
versus
inherited
memberships.
So
you
won't
have
to
go
back
through
and
check
all
your
audit
logs
of
what
were
they
before
right.
That
would
be
pretty
difficult
to
trace.
B
Let's
get
into
user
management
on
sas,
some
customers
ask
how
to
identify
inactive
users
right,
which
would
be
super
helpful,
especially
if
you
are
trying
to
you
know
clean
up
the
number
of
licensed
seats
you're
consuming.
You
want
to
know
if
people
aren't
active
in
gitlab
sas
right
for
your
projects
in
your
group,
specifically
so
virtually
there
is
no
automated
way
to
do
this
on
gitlab.com,
because
again
you
want
to
think
of
a
user.
B
As
a
member
that
could
be
a
member
of
any
project
or
group
on
gitlab.com,
you
could
be
a
member
of
gitlab's
group.
You
can
be
a
member
of
your
company's
group
right,
so
you
know
there
isn't
really
a
clean
way
to
kind
of
track
what
you're
a
member
of
right,
because
you're
just
a
user
across
an
entire
sas
platform.
So
there's
no
automated
way
to
do
this.
B
You
can
retrieve
the
last
activity
on
field
for
namespace
members
via
the
billable
members
api.
That
is
a
possibility
for
seeing
the
last
activity
on
field
in
the
ui.
You
can
sort
the
list
of
users
in
a
group
by
their
last
activity.
But
again,
this
is
generic
and
it's
activity
across
any
group
or
project
on
gitlab.com.
B
So
if
I
had
my
own
personal
projects,
I
was
doing
or
my
own
sandbox
stuff.
You
would
see
that
last
activity
on
and
not
necessarily
the
last
activity
in
that
project
or
group
right
so
still
not
a
foolproof
approach.
Unless
you
can
guarantee
that
these
users
are
not
anywhere
else
on
dot
com.
B
I
can
also
review
the
group
information
and
activity
to
see
who
is
interacting
with
any
issue
project,
epic
or
subgroup
in
the
group
and
decide
who
to
remove
from
there.
It's
probably
your
best
approach
if
you
want
to
just
see
who's
active,
but
it
doesn't
tell
you
who
is
inactive.
It
just
kind
of
shows
that
they
weren't
active
in
recent
history
right,
but
you
can
go
through
and
see
the
activity
across
your
projects
and
groups
by
checking
group
information
and
then
the
activity
section.
B
Also,
how
can
you
prevent
users
from
being
added
at
higher
levels
right
because,
obviously,
it's
great
principle
of
least
privilege?
We
want
to
be
able
to
add
people
at
higher
levels,
so
there
are
restrictions
in
who
can
grant
what
permission
again.
So
an
owner
can
manage
permissions
at
the
group
level
and
only
owners
can
make
other
owners
at
the
group
level.
So
there
is
some.
B
You
know,
access
control
in
a
sense
that
you
don't
want
to
give
people
owner
permission,
but
you
can
revoke
it
as
an
owner,
but
you
know
there
are
restrictions
on
who
can
kind
of
do
what
so
that
does
help
owners
and
maintainers
can
manage
memberships
at
the
project
level.
So
again,
you
would
not
be
giving
people
owner
or
maintainer
privileges
unless
you
knew
that
they
were.
You
know,
good
to
add
users
at
certain
permission,
levels
administer
or
even
owner
levels
of
things.
B
Once
a
user
is
a
member
of
a
group
or
project,
they
can
have
their
permission
level
modified
to
be
the
same
or
higher
level,
but
you
can
prevent
a
user
from
automatically
inheriting
permissions
from
a
group
by
adding
them
as
a
minimal
access
user
so
that
these
permissions
don't
propagate
into
the
subgroups
and
projects
within
that
group.
So
that
is
an
option
to
add
a
user
as
a
minimal
access
user.
B
So
public
projects
are
projects
that
can
be
cloned
without
any
authentication
and
they're
visible
to
all
gitlab.com
users,
even
when
they're
not
signed
into
an
account
and
anyone
is
at
least
a
guest
in
a
public
project.
So
this
is
unlikely
for
corporations.
However,
good
to
know
what
a
public
project
is
you
pretty
much
never
want
to
set
a
product
or
group
to
public
and
private
projects
are
cloned
and
viewed
only
by
project
members
except
guests,
so
guests
cannot
clone
or
view
projects.
B
B
So
another
topic
here
is:
what
does
audit
trails
look
like
with
sas?
When
you
don't
have
access
to
infrastructure,
you
don't
have
access
to
those
detailed
logs.
What
do
you
have
so
on
the
premium
and
ultimate
tier
which
many
customers
are
on?
You
do
have
access
to
audit
events
which
are
super
robust
and
very
helpful,
so
audited.
Events
can
help
you
see
if
a
permission
level
has
changed
and
when
you
see
you
click
on
the
audit
event,
you
can
see
the
author
of
the
change
so
who
changed
someone's
permission
level.
B
What
the
action
exactly
was
the
target
or
whose
permission
changed
the
ip
address,
where
this
change
occurred
and
the
date
so
here's
an
example:
someone
changed
access
level
from
maintainer
to
owner
with
expiry
remaining
unchanged.
That
never
expires.
A
B
And
who
authored
the
change?
This
is
very
helpful
in
terms
of
auditing
and
making
sure
that
there
are
no
bad
actors
who
are
changing
people's
permission
levels
to
something
higher,
which
again,
we
do
have
some
restrictions
on,
but
you
know
things
happen.
You
want
to
be
prepared
for
that
logging.
So
this
is
the
audit
event
that's
available
to
you.
B
B
You
can
see
if
a
user
was
added
to
a
project
and
at
what
permissions
again
permissions
changing
for
a
user
if
a
user
was
removed
from
a
project.
So
if
you
recall
earlier,
I
could
have
clicked
like
remove
member
and
take
someone
out
of
a
grouper
project
right,
but
you
have
an
odd
event
that
tracks,
if
that
occurs,
if
a
project
export
was
downloaded,
so
you
know
you
can
export
projects
do
many
different
formats.
B
B
Also
two-factor,
authentication
enforcement
or
if
the
grace
period
has
changed
for
that,
so
we
highly
recommend
setting
up
multi-factor
authentication.
So
there's
an
odd
event.
If
a
you
know,
project
group
set
up
that
or
made
a
requirement
to
set
up
2fa
and
also
you
can
change
the
grace
period
by
which
someone
has
to
sign
up.
So
you
can
check
if
that
has
changed
and
to
what
with
an
audit
event,
and
we
have
both
project
and
group
audit
events,
you
can
take
a
look
at
those
and
see
what
info
is
available
to
you.
B
We
also
have
apis
where
you
can
interact
with
these
audited
events
as
well,
which
is
my
next
slide.
So
how
do
we
automate
this?
How
do
we
check
when
things
are
happening?
You
know
I
don't
necessarily
want
to
go
into
the
ui
and
be
the
audit
event
fair
enough.
So
the
odd
event,
api
and
streaming
are
two
features
that
you
can
consider.
B
B
So
in
the
case
of
project
events,
maintainers
and
above
can
retrieve
project
audit
events
for
all
users
and
developers
can
retrieve
odd
events
based
on
their
own
actions.
If
I
was
a
developer,
I
couldn't
see
everything,
but
I
could
see
my
own
audit
events.
If
I
changed
the
permission
of
someone,
if
I
you
know,
did
something
within
my
well,
I
guess
I
couldn't
if
I
was
a
developer,
but
if
I
did
anything
that
an
odd
event
would
track,
I
could
see
it
for
myself.
A
maintainer
could
see
for
everybody
similar
with
the
group.
B
So
again,
you
can
see
what
you're
doing
but
can't
see
everything
on
event
streaming,
so
this
is
only
for
ultimate
customers.
However,
if
you
are
an
ultimate
customer
available
to
you
so
the
event
streaming
allows
owners
at
the
top
level
groups
to
set
http
endpoint
to
receive
all
odd
events
about
a
group,
its
subgroups
and
its
projects
as
a
structured
json.
B
So,
finally,
we're
gonna
get
into
some
sas
add-ons
right,
including
ci
and
cd
minutes.
So
I've
had
a
few
customers
run
into
this.
Where
you
know
they
went
past
their
allotted
number
of
ci
cd
minutes,
so
you
can
pay
ten
dollars
for
an
additional
10
000
minutes.
You
just
need
a
credit
card.
You
can
pay
for
extra
minutes
to
run
your
jobs.
B
The
cicd
minutes
are
the
execution
time
for
your
pipelines
on
gitlab's
shared
runner.
So
if
you're
using
our
infrastructure
for
your
runners,
you
can
use
your
own
self-managed
runners
set
them
up
wherever.
However,
if
you're
using
our
shared
ones,
you
will
need
to
stay
within
a
certain
limit
of
minutes.
You
can
buy
more,
and
these
purchases
are
one
time
they
don't
renew
annually
or
anything
like
that.
Just
you
know,
as
needed
ad
hoc,
you
can
buy
some
extra
minutes
for
your
jobs.
B
You
can
also
purchase
additional
storage,
so
it's
60
per
10
gigabytes
of
storage
and
you
can
kind
of
check
if
you
need
to
do
that
by
looking
at
your
usage
quotas
within
your
group.
So
you
just
go
in
your
group
and
then
you
check
your
settings,
you
just
go
to
storage
and
then
you
can
purchase
more
storage
from
there.
B
The
storage
subscriptions
do
renew
automatically,
so
I
believe
it's
annually
you
will
be
charged
again
if
you
added
the
10
or
more
gigabytes
of
storage.
So
it's
not
the
one
time
for
just
like
the
ci
cd
minutes,
but
if
you
need
more
infrastructure
you
can
pay
for.
It
is
the
important
note
here
just
an
additional
cost.
A
Great
thank
you,
sam.
Before
we
jump
into
the
questions
which
we
do
have
a
few,
I'm
gonna
pop
open.
A
poll
right
now
would
love
to
get
feedback
from
from
all
of
you
on
on
how
today's
session
went.
It's
just
a
couple
questions.
So
if
you
take
a
minute
to
answer
that
that'd
be
great
and
from
there
we
will
jump
into
some
q
a
so
sam.
B
Yes,
there
is
a
way
to
do
that.
So,
if
you
add
a
user
as
minimal
minimal
access,
that
is
kind
of
the
trick
for
not
adding
them
automatically
into
subgroups
and
projects
underneath
a
group,
so
they
won't
inherit
those
permissions.
You
can
just
add
them
directly.
That's
kind
of
like
a
terminal
permission.
B
B
Yeah
definitely
so
the
admin
panel
or
admin
area
is
a
great
feature.
It's
on
our
self-managed
offering.
So
if
you
want
to
access
that,
you
can
do
so
on
a
self-managed
instance.
However,
it's
not
something
that's
available
on
gitlab.com,
so
you
know.
In
that
case
you
have
to
manage.
You
know
permissions
and
roles
from
the
groups
and
projects
and
you
can't
access
a
direct
admin
area,
but
hopefully
gitlab
workspace
will
kind
of
cover
that
once
we
start
achieving
the
parity
between
sas
and
self-managed
and
you'll
have
those
admin
area
functionalities
on
sas.
A
Okay,
last
one
I'm
seeing
here
what
is
a
good
role
for
someone
who
doesn't
need
access
to
the
code
base
more
of
an
executive
type.
B
Yeah,
so
generally,
we
recommend
a
reporter
level
access
for
that,
so
that
you
don't
have
to
be.
You
know,
contributing
code
or
viewing
it.
You
can
just
leave
comments
on
issues,
especially
to
track
progress
of
things.
We
do
have
a
good
mapping
between
the
permissions
and
roles
and
the
actual
rules
within
a
business
like
what
you
know,
a
business
analysis
knee
what
executive
would
need
so
generally,
our
guidance
for
if
someone
doesn't
need
to
be
hands
on
keyboard
or
developing
anything,
it
could
be
set
as
a
reporter.
A
Great,
thank
you
sam
well
with
that.
I,
I
think
we'll
wrap
up
now
appreciate
everyone's
time
today,
as
I
mentioned
at
the
beginning,
keep
an
eye
out
for
the
for
the
recording
and
the
deck
we'll
be
sending
that
out
in
the
next
day
or
two
and
keep
an
eye
out
for
for
future
sessions
like
this
we're
glad
you
joined
us
today
have
a
good
rest.
Your
day.