►
Description
The U.S. Department of Energy has many authentication systems, and even more disjointed GitLab instances. In order to securely run CI jobs in this environment, they needed more fine-grained user access control than GitLab provided. In this talk, David Nicholaeff, a mathematician with the U.S. Department of Energy, walks through the technical details of developing and deploying federated auth as well as extending zero trust data zones and automation for GitLab. Additionally, he will share some insights on the process of contributing to GitLab as they have decided to open source the code and contribute it upstream.
Link to referenced issue/more info: https://gitlab.com/gitlab-org/gitlab/issues/33665
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
A
They
asked
me
to
give
a
little
spiel
on
Who
I
am
so
I,
don't
have
any
social
media
of
any
kind
and
I
figured
I'd
just
do
something
random
from
my
recent
trip
to
Germany.
This
is
a
panda
I
like
to
fancy
myself
a
panda
rolling
from
project
to
project,
so
I
somehow
found
myself
working
on
Federation
in
get
lab
my
backgrounds
in
quantum
foundations
and
mathematics,
so
I'm
very
interested
about
measurement
theory
in
sort
of
the
context
in
which
you
run
physics,
experiments
and
I
find
Federation
very
fascinating.
A
Because
of
that,
because
I
feel
like
it's
setting
up
the
measurement
apparatus
to
study
programs
that
could
build
themselves.
But
if
you're
interested
in
knowing
my
background
more,
we
can
talk
after
the
talk.
But
if
you'd
like
to
follow
up
after
this
I'm
on
get
lab
lab,
comm,
/d
Nick,
and
then
we
have
a
big
issue
here,
where
we're
trying
to
merge
all
these
Federation
enhancements.
In
to
get
labs,
so
that's
issue
three,
three,
six,
six,
five
I'll
present
it
right
at
the
end,
so
you
guys
can
check
that
out
later,
so
very
quickly.
A
I'm
just
gonna
run
through
what
high
performance
computing
is.
What
the
exascale
computing
project
is,
how
we're
trying
to
use
get
lab
CI
in
the
ECP
talk
high
level,
what
the
enhancements
are
and
then
I'm
going
to
do
a
live
demonstration,
so
fingers
crossed
everything.
Flows
is
expected
so
very
quickly,
kind
of
by
the
numbers,
the
X
scale.
A
So
when
you
run
CI
for
something
like
a
web
application,
often
times,
you
can
write
very
small
unit
tests
and
have
them
run
in
parallel
by
themselves
with
computational
physics.
You
have
this
challenge
that
you
have
multiple
time
scales,
multiple
size
scales,
the
coupling
between
something
like
a
fluid
dynamics,
flow
or
radiation
transport.
It
becomes
very
complex
and
it's
just
not
sufficient
to
run
simple
unit
tests.
A
You
have
to
couple
everything
and
you
have
to
write
very
large
integration
tests
so
to
kind
of
achieve
the
level
of
testing
we
want
for
something
as
intricate
as
compressible
flow.
We
need
to
actually
test
our
codes
in
the
environments
they're
gonna
run,
so
that
involves
not
just
running
on
the
big
supercomputers
that
will
run
the
simulations,
but
also
the
the
diverse
ecosystem
of
software
that
that
exists
there.
So
you
know
different
compiler
versions,
different
libraries
tools.
All
of
these
need
to
be
exactly
what
the
real
simulation
is
going
to
use.
A
So
keeping
that
in
mind
now
we'll
look
at
the
challenges.
So
really,
when
you
think
about
CI
right,
you
want
to
have
pure
automation,
no
people
involved
whatsoever,
but
there's
challenges
to
that,
namely
CI
jobs
run
arbitrary
code
right.
You
don't
know
who
checked
in
the
code
oftentimes
you're
pulling
in
code
from
a
third
party,
and
you
want
to
build
in
real-time,
so
in
typical
multi
cloud
environments
right,
we
have
docker
containers
that
can
isolate
your
environment,
but
unfortunately,
those
don't
get
bare-metal
performance
and
and
even
still
most
docker
containers
are
just
run
this
route.
A
So
in
the
HPC
world
right
we
need
this
bare
metal
performance.
I
mentioned
that
we
want
to
run
on
heterogeneous
hardware
architectures.
We
have
supercomputers
that
use
power,
9
systems
that
use
arm
systems
x86,
and
then
we
have
this
rich
software
ecosystem.
Where
modules
are
built
at
very
specific
versions,
the
combinatorial
nightmare
of
getting
them
all
to
work
together.
You
you
really
have
to
test
exactly
with
how
the
big
simulation
is
going
to
run
so
trying
to
Enclave
it
away
to
a
container
doesn't
really
work.
A
On
top
of
that
to
tap
into
the
HPC
resources
we
use
batch
schedulers
and
that
in
itself
introduces
some
new
complexity
because
of
the
time
limits
you
have
to
have
certain
money
allocated
to
run.
For
that
amount
of
time,
then,
of
course,
your
security
and
really
that
to
me,
is
kind
of
the
fascinating
part
about
Federation.
Is
it
solves
a
lot
of
the
security
challenges
so
kind
of
simplify
it
down?
You
cannot
have
jobs
run
by
user,
a
interact
whatsoever
with
jobs
run
by
user
B,
so
you
have
this
idea
of
an
enclave.
A
So
how
do
we
ensure
that
that
happens?
Well,
we
need
to
have
really
fine-grained
user
access
control
and
so
I'm
going
to
talk
about
that
in
the
Federation
enhancements
and
ultimately,
what
this
leads
to
is
this
idea
of
zero
trust?
It's
not
enough
to
just
be
on
the
system
get
through
the
firewall.
Every
single
action
you
take
needs
to
fundamentally
be
authorized,
and
so
we're
gonna
show
how
our
Federation
enhancements
are
working
towards
achieving
that
I'm
not
going
to
talk
about
why,
of
course,
we
need
automation.
Hopefully
it's
self-evident.
A
This
high
level
is,
is
sort
of
the
model
that
we're
working
with
here,
projects
host
their
code
in
get
lab
or
their
own
self
hosted
get
lab.
That's
then,
mirrored
to
our
central
yet
lab
in
the
cloud
at
Asti
and
and
then
those
jobs
are
picked
up
by
a
federated
runners,
that
the
different
facilities
are
gone
and
Oakridge,
and
you
can
see
here,
I'm
gonna
talk
a
fair
amount
about
the
identity
providers.
A
This
is
the
key
source
here
and
get
into
it
in
the
next
few
slides,
but
we're
really
tapping
into
the
Omni
aunt
functionality
of
get
lab
to
trigger
the
jobs
and
and
know
who's
running
them.
So
I'll
get
right
into
the
technical
enhancements
we
needed
to
make
and
it
can
be
kind
of
summarized
by
analyzing
what
the
challenges
are.
So
really,
the
three
key
challenges
were:
how
do
we
refine
the
user
access
control?
Normally,
when
a
CI
job
is
run
it's
around
his
route
and
we
can't
have
that
at
the
national
laboratories.
A
So
how
do
we
refine
that
control?
How
do
we
directly
leverage
the
HPC
resources?
I
won't
talk
about
that
that
gets
into
some
of
the
set
UID
and
batch
runners
we've
been
working
on
and
then
the
the
what
I
like
to
call
the
three-body
administration
problem.
We
have
server
admins,
runner,
admins
and,
of
course,
admins
at
the
identity
providers.
Thankfully
we
all
communicate,
but
there's
still
a
challenge
there
of
well
Federation.
A
Currently
only
the
required
fields
are
actually
leveraged,
so
you
have
a
provider,
a
user
ID
and
some
basic
info
like
a
name
but
as
part
of
that
schema,
there
are
additional
fields
inside
of
the
credentials
hash
inside
of
the
auth
hash.
So
there's
a
token,
that's
an
access,
token
secrets,
a
deprecated
value
from
ooph
one
and
then
a
boolean
for
expires
and
an
expires
time.
So
we
take
advantage
of
that
credentials.
Information
is
provided
by
an
oauth2
type
identity
provider,
but
we
also
actually
support
sam'l
and
other
other
providers.
A
Of
course,
it
required
a
fair
amount
of
tinkering
around
which,
again,
if
you're
interested
in
the
details
of
that
you
can
come
talk
to
me
after,
but
fundamentally
we're
taking
advantage
of
this
authorization
code
flow
from
OAuth
2,
so
steps
one
through
nine
here,
it's
all
standard,
OAuth,
2
code
flow,
so
I
won't
dive
into
it
in
detail
and
in
the
demo,
you'll
see
me
walking
through
these
steps.
Really
the
the
key
enhancements
start
at
step
9.
A
So
once
the
provider
sends
over
some
payload
of
off
information,
as
I
said
before,
gitlab
just
grab
the
provider
external
username,
and
that's
it
really.
It
was
merely
meant
to
handle
social
sign-in,
but
we
want
to
do
more
with
that
right.
We
want
to
take
advantage
of
the
credentials
information,
that's
provided
so
in
step
9.
We
extract
that
credentials.
Information
put
into
the
database
and
now,
when
you
want
to
trigger
CI,
you
actually
passed
down
that
users
context
all
the
way
down
to
the
runner.
A
So
you
can
see
there
in
step
10
right
all
that
data
is
passed
down
to
the
runner
and
now,
whereas
before
you
would
just
have
the
runner,
execute
the
CI
job
and
send
the
response
and
step
12.
Now
you
can
actually
do
step
11.
The
runner
can
communicate
directly
with
the
identity
provider.
So
now
you
can
see
where
that
three
body
administrator
problem
kind
of
comes
into
play
here
right
before
you'd.
Have
someone
set
up
a
get
lab
server?
You'd?
A
Have
the
get
lab
runner
get
the
token
register,
and
then
you
just
have
this
implicit
trust
all
the
time.
But
now
we
give
power
to
the
the
the
server.
Admin
still
has
the
same
power
they
had,
but
now
the
runner
admin
has
more
power
to
say.
You
know
what
maybe
I
don't
want
to
run
that
job
I
want
to
communicate
with
the
identity
provider,
I
trust
first,
so
they
can
take
that
access
token
and
validate
it
against
the
identity
provider.
I
won't
go
into
the
digital
identity
guidelines
stuff
too
much
I'll.
A
So
every
Federation
event
literally
looks
like
a
not
an
audit
event.
Alright,
so
I'm
gonna
do
a
live
demo.
Now
the
progressions
gonna
be
I'm
going
to
show
this
this
transition
from
what
a
normal
CI
job
looks
like
when
you
use
just
a
normal
shell
Runner,
then
we
progress
to
a
set
UID
enhancement,
then
full
Federation
time
permits
I'll,
show
some
auditing
stuff
and
then,
of
course,
lessons
learned
and
where
we're
at
now.
A
A
So
this
first
part
is
going
to
use
a
bunch
of
virtual
machines
that
I
have.
Let
me
zoom
in
here,
make
sure
you
guys
see.
That's,
maybe
a
little
too
big.
That's
still
good!
Okay,
so
this
first
part
is,
is
all
a
bunch
of
virtual
machines
that
I
have
running
so
you'll
see
how
the
10:26
for
all
of
them?
Okay.
So
in
my
example,
repo
here
a
very
simple
CI
mo
file.
A
A
So
if
I
come
over
here
to
my
pipelines,
I
look
at
the
latest
job
I,
see
as
I
expect
route
ran
the
job.
That's
because
the
runners
running
his
route
and
so,
of
course,
the
CI
job
is
going
to
run
his
route.
So
the
next
iteration
here
is
to
take
advantage
of
set
UID.
So
that's
where
I'm
gonna
actually
try
and
change
the
user.
That's
triggering
the
job
to
actually
run
it.
A
A
A
Oh,
it's
failing,
okay!
Well,
it's
telling
me
because
there's
some
unknown
user
D
Nick
trying
to
run
the
job.
Well,
that's
because
set
UID.
The
first
pass
that
you
know.
Moving
towards.
Federation
is
literally
just
taking
my
get
lab
accounts,
D
Nick,
so
that
that's
my
username
in
the
server
is
D
Nick.
But
if
you
look
at
my
username
here,
yes,
it's
in
a
VM,
but
I
kept
it
the
same
as
my
laptop
I'm,
just
I'm
D,
nikolai
f,
so
the
user
names
don't
match
alright.
So
it's
very
quickly
make
this
job
pass.
A
A
Yes,
okay,
so
now
you
see
the
job
past
as
d
Nick.
Well,
for
the
purpose
of
this
demo,
you
can
see
I
created
a
username
D
Nick,
just
so
it
pass
okay,
so
you
can
see.
There's
some
limitations
there
with
set
UID
right,
the
fact
that
it's
grabbing
the
username
straight
from
the
server.
So
now,
let's
move
to
Federation.
A
So
Federation
is
going
to
tap
into
Omni
off,
like
I
had
mentioned
so
I
come
to
my
profile.
Account
page
and
you'll
see
the
social
signing
another
way
to
get
there.
You
come
up
to
settings
and
then
you
click
account.
So
I
have
two
identity
providers
here,
I'm
just
gonna
show
off
the
one.
It's
a
very
simple
JSON
web
token,
based
IDP
that
I
have
a
VM
running
for.
A
A
So
now,
when
we
come
down
to
the
pipelines,
you
see
it's
running
Federation
past,
and
this
time
we
see
it
actually
ran
as
d
nikolai
off',
which
is
not
my
get
lab
server
username,
it's
the
one
that
was
provided
by
the
identity
provider.
So
all
as
well.
I
have
delegated
the
control
down
to
the
runner
to
talk
with
the
identity
provider
and
say
who
you
know,
who
should
be
running
the
CI
job
and,
and
so
I've
got.
A
We've
kind
of
you
know,
elevated
the
role
of
omni
off
to
to
to
manage
user
access,
control
and
fundamentally
tap
into
the
identities
table
that
exists
in
gitlab.
Ok,
so
just
make
sure
I'm
on
track
here
showed
you
guys
say
the
shell
runner
set
UID
moving
to
the
federated
runners
and
ok,
so
now
I'm
going
to
show
you
sort
of
our
pre-production
testing
environment.
A
So
here
you
can
see
the
social
sign-in
we
have
a
few
one
ID.
Is
this
really
cool
authentication
hub
where
we
can
tap
into
all
the
National
Labs?
Really
not
all,
but
many
of
them
I'm
not
gonna,
use
that
for
this
demo
here,
because
I
don't
feel
like
grabbing
my
Los
Alamos
crypto
card
out,
but
for
the
case
of
multiple
signings
I
will
show
you
guys
nurse
quickly,
since
this
just
right
across
the
bay.
A
A
A
Okay,
so
now,
though,
you
can
already
see
here
on
the
run
or
something's
failing
well,
it
looks
exactly
like
that
failure
we
had
with
set
UID,
namely
it's
trying
to
run
the
job
as
some
user
that
doesn't
exist
on
the
system.
So
it's
trying
to
run
as
user
1
1
6
for
8
cents.
Well,
that's
my
Google
user
account,
so
I,
of
course,
don't
have
a
local
account
that
matches
my
Google
user
account.
So
how
do
I?
How
do
I
fix
this
problem?
A
Well,
as
I
showed
in
the
authorization
code,
flow
diagram
really
wanted
to
give
a
lot
of
power
to
the
the
runner
admins
so,
which
you
can
see
here
in
the
config
tamil,
is
that
we
actually
allow
you
to
specify
a
validate
auth
script,
which
I'll
I'll,
show
you
in
a
second
or
actually
I
might
as
well.
Just
show
you
right
now
on
before
I
I
do
the
run.
A
A
Now
with
that
validate
script,
retry-
and
you
can
see,
the
job
has
succeeded
on
the
runner,
and
if
we
refresh
the
s
there
you
go,
you
can
see
that
not
only
did
it
remap
my
Google
user
account,
which
did
that
long
integer
to
the
actual
local
one
that
I
cared
about
again
a
an
operation
performed
by
the
runner
admin.
But
in
addition,
as
I
showed
you
in
that
script,
we
took
the
the
access
token
and
hit
Google's
endpoint
to
to,
in
fact
ensure
hey.
A
This
is
this
is
a
legitimate
session
that
they
have
with
Google,
so
showed
you,
the
federated
runner
stuff
showed
us
austie.
As
I
said,
we
really
focused
on
what
the
runner
admins
can
do
with
the
credential
information
showed
you
that
script
here
and
I
still
have
a
couple
minutes.
So
I'll
just
very
quickly
show
you.
A
A
Federation,
if
you've
never
played
with
JQ
I
highly
recommend
it
it's
a
very
cool
parser
of
JSON.
So
you
can
see
here
we
have
full
entries
in
the
log.
We
give
these
unique
identifiers
to
each
Federation
event.
You
can
see.
Oh
hey
a
CI
job
the
past,
but
perhaps
we
put
a
little
too
much
information
in
it,
but
you
can
see
here
under
the
target
details.
You
know:
okay,
it's
a
type
CI,
here's,
the
job
ID.
What
was
the
project?
The
project
ID
the
commit
hash.
A
A
Okay,
this
is
perhaps
more
of
a
personal
reflection
on
the
project,
but
I
feel
like
one
of
the
the
biggest
issues
we
had
with
trying
to
get
to
the
state
of
Federation
that
we're
at
was.
It
was
not
really
having
a
full
formal
specification
up
front
Security's,
really
challenging
right
they're.
Just
you
can't.
You
can't
expose
every
part
of
your
attack
surface
an
attacker
will
eventually,
but
you
know
you
trying
to
find
that
is
very
hard.
A
We
had
a
challenge
where
you
know
we
went
one
way
with
set
UID
in
the
beginning
and
it
ultimately
didn't
really
mesh
as
well
with
Federation
as
we
wanted,
and
and
so
it
took
a
lot
of
catch-up
to
kind
of
evolve
it
to
where
we
need
to
get
to
this
next
lesson
is
going
to
be
kind
of
preaching
to
the
choir.
Hopefully,
but
really
you
should
just
test
test
test.
A
We
didn't
start
making
like
exponential
and
advances
in
our
development
until
we
wrote
that
full
virtual
environment
had
docker
containers
testing
everything
I
mean
we
started
to
run.
Ci
CD
on
our
CI
CD
enhancements,
so
I
mean
I
can't
understand,
is
to
just
test
your
own
tests
and
then
the
third
biggest
lesson,
especially
since
we
want
to
upstream
this
to
the
community,
is
getting
involved
early
again.
A
One
of
the
sort
of
failures,
perhaps
early
on,
was
that
we
didn't
engage
the
gitlab
team
early
enough
with
the
set
UID
enhancements,
but
with
Federation
we've
we've
reached
out
to
our
points
of
contact
met
with
everyone
in
the
community,
we're
here
a
key
at
lab,
commit
and-
and
so,
if
you
really
want
to
make
an
impact,
the
source
community
I
think
getting
involved
as
early
as
possible.
It's
really
critical
in
terms
of
current
state.
We
have
a
lot
of
our
ECP
projects.
A
I
showed
some
of
those
pretty
pictures
of
computational
physics,
simulations
they're
all
starting
to
use
our
CI
infrastructure
and
we're
nearly
at
a
place
where
everyone's
gonna
be
running
through
our
production,
asti
instance.
In
terms
of
next
steps,
the
user
experience
is
something
we
want
to
work
on
so
obviously
going
to
slash
profile.
Slash
accounts
to
connect
your
social
sign-in.
Isn't
the
most
convenient
way
to
do
this,
so
we're
looking
at
commit
as
assurance
where
you
can
actually
sign
your
commits
with
tokens
in
real
time.
A
Code
scanning
is
a
big
part
of
where
we
want
to
go
as
well
and
actually
tapping
into
new
schedulers
is
another
big
deal.
As
I
said,
bare
metal
performance
is
critical
to
us,
and
some
of
the
schedulers
are
getting
a
little
bit
older,
so
tapping
into
things
like
flux
and
on
the
roadmap.
So
that's
my
talk.
I
hope
you
all
enjoyed
it.
If
you
have
any
questions,
please
come
up
and
talk
to
me
after.
Thank
you.