►
From YouTube: GitLab Community Meetup: The Role of GitLab in Building a Zero Trust Moving Target Defense SaaS
Description
This is a recording of a virtual community meetup from April 2, 2023.
The Role of GitLab in Building a Zero Trust Moving Target Defense SaaS
Gartner has identified Automated Moving Target Defense (AMTD) as the future of cybersecurity. GitLab, a leader in developing secure applications and DevSecOps CI/CD has been an enabler for a new form of AMTD. Tom McNamara, the Founder and CEO of Hopr (https://hopr.co), an AMTD technology innovation company, joined Stephanie Phifer and Nicholas Hughes from EITR Technologies to explain how GitLab, DevOps and AWS were used to produce XTRA, a DevOps friendly SaaS for protecting workloads and APIs with AMTD. In this recording of a community meetup, we discuss the workflow, architecture, challenges, and provide a demo.
A
So
hi
everyone,
my
name,
is
John
Coughlin
I'm
on
the
community
relations
team
at
gitlab,
I've
been
at
gitlab
for
more
than
four
years.
I
actually
started
as
a
program
manager
in
the
program
that
I
kind
of
launched
and
managed
when
I
first
joined
was
our
meetups
program,
and
so
it's
really
cool
to
still
be
involved
in
our
meetups,
and
you
know
in
the
community-
and
it's
certainly
been
one
of
the
highlights
of
my
career,
so
really
excited
to
be
here
and
be
hanging
out
with
all
of
you
today
at
gitlab.
A
If
anyone
you
know
wants
to
review
that,
you
know
I'd
encourage
you
to
do
so,
and
you
know
if
anyone
is
having
any
kind
of
issues
or
would
like
to
report
a
violation
of
this
code
of
conduct
during
the
event
feel
free
to
just
send
me
a
DM
via
Zoom.
So
if
you're
not
familiar
with
zoom,
you
can
do
that
by
going
into
the
zoom
chat,
finding
toggling
from
kind
of
everyone
in
the
meeting
to
my
name
and
then
send
Amy
a
message:
that'll
be
the
most
efficient
way
to
to
reach
me.
A
So
with
that,
you
know
just
wanted
to
say
thanks
for
being
here
for
folks
who
are
new
to
kind
of
get
lib
not
familiar
with
Git
lab
we're
a
complete
devsecops
platform.
So
it's
one
in
interface,
one
data
model,
one
permission
model:
all
of
your
conversations
are
happening
in
one
place.
We
have
thousands
of
features
and
that
require
no
contact,
switching
between
different
applications,
and
so
it's
really
just
the
complete
devops
platform
that
you
and
your
team
need
to
deliver.
Software
faster,
we're
also
an
open,
Core
Company.
A
So
for
today
we're
going
to
go
through.
You
know
a
presentation
from
the
team
at
Hopper
and
eitr
just
a
couple
small
requests,
as
I
mentioned
earlier,
if
you
could,
if
you're
comfortable
being
recorded,
be
great
for
you
to
keep
your
cameras
on,
but
no,
you
know
no
worries
if
you're
not
comfortable
doing
that.
Please
stay
muted
during
the
presentation.
If
you
do
have
questions
it'd,
be
great
to
use
the
chat
to
ask
those
rather
than
interrupt
our
speakers,
we're
also
going
to
have
time
for
Q
a
at
the
end.
A
If
you
haven't
already
be
awesome,
if
you
could
share
your
location
in
the
zoom
chat,
I'm
joining
from
New
York,
it
seems
like
there's
a
couple
folks
from
Maryland,
actually
a
lot
of
folks
from
Ireland
but
I'm
sure
they'll
get
to
that
in
their
introductions
in
a
second
yeah
and
I
would
just
say
you
know,
like
close
slack,
close
your
other
tabs
and
just
kind
of
try
and
be.
You
know,
attentive
and
enjoy
the
great
presentation
that
these
people
have
worked
hard
to
prepare
for
us.
B
We
build
a
automated
moving
Target
defense
technology
that
protects
workloads
and
apis
in
the
cloud
and
today
we're
going
to
be
giving
you
a
presentation
about
how
we
do
this
with
hardened
tunnels,
but
we're
also
going
to
be
stressing
and
talking
quite
a
bit
about
how
we
use
git
lab,
and
so
my
colleagues
from
from
eitr
have
partnered
with
hopper
to
develop
this
technology
and
the
product
that
we're
taking
to
the
market
so
Nick
next
slide.
Please.
B
So
Nick,
who
is
joining
running
our
slides
right
now,
will
be
joining
us
in
the
presentation
later.
As
a
co-founder
and
CEO
of
eitr,
Technology
he's
really
been
the
Chief
Architect.
If
you
will
of
the
product
that
we're
going
to
talk
about
today,
he
is
also
a
dual-headed
as
the
VP
of
our
product
engineering
at
Hopper,
and
he
is
joined
by
our
other
co-founder
from
eitr
the
CTO
who
is
Stephanie
Pfeiffer.
B
B
So,
as
I
mentioned
at
the
beginning,
we
have
a
automated
moving
Target
defense
technology
to
protect
workloads.
So
the
challenge
we're
trying
to
solve
is
really
about.
Who
are
these
workloads?
How
do
we
know
their
identity?
How
do
we
trust
their
identity?
How
do
we
know
the
credentials
that
we're
getting
are,
in
fact
from
legitimate
sources
and
not
from
a
man
in
the
middle
attack?
B
And,
of
course,
we
would
all
like
to
see
neutral,
TOS
everywhere,
but
it's
not
really
possible
or
practical
to
get
that
there
are
places
where
mtos
terminates
in
the
cloud.
Then
we
don't
have
any
control
necessarily
over
that
and
it's
very
difficult,
sometimes
to
put
mtos
into
place
everywhere,
because
if
it's
dependency
on
pki
and
certificates
and
those
types
of
things
so
I
won't
get
into,
but
it's
a
great
goal
to
achieve.
B
But
what
we'll
talk
about
today
in
hardening
and
these
hardened
tunnels
is
essentially
an
mtls
everywhere
alternative
and
I'll
talk
more
about
that
on
the
next
slide.
The
other
part
of
our
problem,
we're
solving,
is
the
friction
that
developers
and
devops
confront
when
they're
trying
to
implement
TOS
or
mtls
outside
of
clusters,
they're
trying
to
implement
it
with
automated
certificates,
authorities
and
pki
infrastructure.
It's
a
lot
of
trial
and
error.
A
lot
of
configuration
a
lot
of
friction
really
in
getting
that
deployed
and
working
properly.
B
And,
of
course,
all
this
adds
up
to
cost
people
cost
time
cost
there's
also
dependencies
on
cloud
vendor
services
and
and
the
cost
associated
with
key
management
systems
and
certificate.
Management
Systems
Secrets
managers
Etc
next
slide.
So
what
we've
done
is
to
develop
a
solution
that
uses
a
technology.
We
call
codes
hidden
in
plain
sight,
chips
for
sure,
and
it's
both
a
technology
and
a
protocol.
Nick
will
be
talking
about
that
more
towards
the
end
of
our
presentation,
but
essentially
what
it
does
is.
B
What
we
do
is
we
use
that
within
the
workload
to
actually
build
a
end-to-end
encrypted
tunnel
on
demand
and
we're
able
to
do
this
without
ever
going
through
any
handshakes
or
any
key
exchange,
and
the
final
part
of
our
solution
that
we're
quite
happy
about
is
that
we've
been
able
to
package
all
of
this
into
a
simple
container.
So
it's
deployed
as
a
sidecar
with
each
workload,
and
it
makes
it
really
easy
in
a
devops
friendly
way
to
essentially
get
what's
the
equivalent
of
mtls
everywhere,
but
it's,
but
on
steroids
next
slide.
B
So
we've
come
up
with
a
way
in
our
solution
to
use
these
hardened
tunnels,
along
with
our
chips,
technology
to
essentially
protect
data
all
along
the
entire
route.
Here,
where
you
see
the
blue
and
green
lot
green
lines
and
one
the
blue
lines
are
a
product.
We
call
extra
Nick,
we'll
talk
more
about
that,
and
the
green
line
is
the
product.
C
Thanks
Tom
I
appreciate
it:
gitlab's
really
been
able
to
power
our
team
to
organize
our
communication,
our
tasks
break
down
and
enable
us
to
do
continuous
integration
and
deployment
and
delivery
really
seamlessly.
So
we're
excited
to
to
jump
right
in
here,
so
Nick,
let's
go
to
the
next.
Thank
you.
First,
we're
going
to
jump
into
our
project
tracking
in
the
past,
I've
used
jira
a
lot
and
I
think
gitlab's,
really
giving
jira
run
for
its
money
with
their
product
tracking
and
management
at
Hopper.
C
Oh
and
one
thing
to
keep
in
mind
that
Tom
did
mention
earlier
we're
using
the
gitlab
ultimate
license.
So
if
any
of
this
doesn't
look
familiar
and
looks
super
cool
which
it
does,
you
should
definitely
check
out
the
ultimate
level
of
git
lab,
because
it
is
very
helpful
with
these
products.
So
at
Hopper
we
take
our
architectures
and
our
tasks
and
we
break
that
down
into
a
milestone,
which
is
a
set
of
time
that
we
want
to
get
accomplish
certain
things.
C
C
It
really
gives
the
ability
to
manage
my
workload
easier
as
a
developer
and
to
come
up
with
tasking
as
a
manager
a
lot
easier.
We
leverage
labels
for
prioritization
and
they
are
based
off
of
the
git
lab
recommendations.
They
are
in
the
screenshot
in
the
lower
left
hand
corner,
and
we
use
things
like
Priority
One.
To
say
these
are
the
important
things
we
need
to
do
now,
all
the
way
down
to
Priority
four,
which
it
needs
to
get
done.
C
But
if
I
have
a
critical
bug,
obviously
I'm
going
to
attack
that
first,
a
really
great
thing
about
how
gitlab
does
their
issue
tracking
is.
We
are
able
to
keep
even
our
issues
and
our
accesses
to
our
repositories.
Dry,
don't
repeat
yourself!
So
I,
don't
want
to
add
people
to
a
bunch
of
different
repositories.
I
don't
want
to
go
through
adding
additional
users
to
issues,
so
they
give
us
the
ability
to
make
confidential
issues
and
confidential
epics
and
those
permissions
trickle
down
from
the
Epic
Level
all
the
way
to
the
issue.
C
Customers
are
given
in
basically
an
email
address
that
they
can
hit
and
that
will
trigger
an
issue
created
in
our
service
desk
queue
and
that
issue
can
go
back
and
forth
between
our
developers
without
us
having
to
add
every
customer
to
our
git
love
instance
and
we're
able
to
communicate
back
with
our
customers
via
comments
on
the
issue.
So
it's
a
streamlined
interface
between
our
customers
and
our
developers
and
our
support
team
to
make
sure
that
we're
attacking
the
things
that
customers
need
and
simplifying
that
workflow.
You
can
see
in
our
screenshot
on
this
page.
C
We
are
also
using
the
templates
that
come
along
with
service
desk,
where
you
can
add
new
notes.
Thank
you
notes.
Whatever
templates
are
going
to
help
in
your
workflow
to
make
sure
that
your
customers
understand
that
they're
getting
the
feedback
that
they
need
that
way,
you're
not
Reinventing
the
wheel,
every
single
time.
You
want
to
send
a
note.
The
service
desk
has
been
really
valuable,
especially
for
that
communication.
C
So
you
can
jump
to
the
next
slide
to
our
security
features.
So
gitlab-
and
some
of
this
starts
bleeding
into
the
ultimate
level
license.
But
the
security
features
really
start
with
the
security
dashboard,
which
is
in
that
top
right
hand,
corner
of
your
screen.
All
of
our
projects
get
reviewed
automatically
and
we
can
see
a
nice
report
of
what
level
what
grade
we're
getting
on
our
projects.
C
As
you
can
see,
over
the
last
90
days,
we've
had
pretty
much
Straight
A's
at
Hopper,
which
is
excellent
and,
as
issues
come
up,
we
can
be
proactive
because
the
dashboard
is
giving
us
the
ability
to
to
see
what
needs
to
be
addressed
and
while
dashboards
are
great.
Reports
are
very
important
and,
as
you
can
see
in
the
middle
of
the
screen,
we
have
our
vulnerability,
vulnerability,
vulnerability.
Report
I,
don't
know
how
to
talk
anymore.
C
Our
vulnerability
report
is
going
to
give
us
an
overview
of
everything
that
gitlab
has
been
able
to
see
as
an
issue
on
our
projects.
There
are
some
simple
ones
in
the
bottom
and
you
can
see
they
go
from
critical
down
to
low
and
there
are
even
informational
issues
that
they've
found
and
the
thing
I
really
like
about
this.
Is
it
links
directly
back
to
a
project?
You
can
create
issues
off
of
these.
It
gives
great
visibility.
C
It
gives
descriptions
it's
awesome
and
for
those
informational
alerts
that
probably
don't
need
anything
done
for
them,
except
for
a
little
bit
of
documentation.
You
can
you
can
get
rid
of
those
by
just
clicking,
hey
I'm,
going
to
ignore
this
issue.
This
actually
is
okay.
I,
don't
need
a
new
magic
number
every
single
time,
so
I
think
it
gives
a
really
great
visibility
into
our
security
features.
They
are
reporting
on
things
that
you
know
are
commonly
overlooked,
maybe
because
they're
so
simple,
but
having
that
visibility
is
really
great,
especially
automatically.
C
So
now
we
can
jump
to
the
next
slide
and
talk
about
my
favorite
part
of
git
lab,
which
is
a
CI
CD.
On
the
hopper
side,
we're
leveraging
shared
Runners.
We
try
to
have
as
minimal
infrastructure
as
possible
and
the
shared
Runners
give
us
the
ability
to
just
run
inside
of
an
environment
github's
already
provided
for
us.
C
We
are
using
a
blend
of
the
custom
Hopper
templates,
as
well
as
the
standard
gitlab
CI
templates.
The
templates
are
great
because
they
larger
they're,
largely
Universal
and
address
common
and
often
overlooked
issues,
and
the
hopper
templates
are
generic
and
streamlined
for
use
cases
across
all
of
our
technology
sets.
So
you
can
see
in
this
diagram.
C
We
have
a
custom
template
called
workflow.getlabci
that
we
leverage
to
make
sure
that
we're
not
going
over
our
minutes
and
making
sure
we're
only
running
pipelines
when
we
need
to,
but
in
the
bottom
part
of
the
diagram
you
can
see
that
we're
bringing
in
the
security
license
scanning
dependency
scanning
SAS
templates
that
are
provided
by
gitlab
to
make
sure
that
we're
getting
that
security
scanning.
So
the
blend
between
those
two
really
gives
us
that
holistic
gitlab
CI
pipeline
that's
going
to
help
our
projects
be
as
robust
as
possible.
C
So
if
we
go
to
the
next
side,
we
can
see
it
in
action.
Here
are
some
diagrams
of
the
pipelines
that
we
are
using
today.
So
you
can
see
we
have
standard
job
standard
stages
like
pre-commit
test
build,
and
then
we
diverge
and
build
and
Deploy
on
whenever
we
need
to.
You
know
create
a
tag
put
something
out
to
our
users
or
just
build
and
make
sure
that
everything
is
working.
C
D
D
So
a
great
lead
in
Stephanie
mentioned
the
container
repositories
and
how
we
have
an
external
one
for
our
customer
environment.
It
gives
us
the
ability
to
have
this
promotion
process
where
you
know,
when
we
cut
tags
on
a
repository,
it'll
go
ahead
and
build
artifacts
that
we
can
go
ahead
and
test
internally
before
we
say
okay,
this
is
ready
for
customer
consumption.
D
So
right
now
that
is
a
manual
promotion
process.
You
can
see
we
have
the
little
gear
button
there
that
somebody
has
to
go
in
and
click
when
they're
ready
to
promote,
but
we
do
have
plans
to
automate
that
process
as
we
get
a
little
bit
more
more
mature
in
our
processes,
maybe
run
some
Canary
builds
or
something
like
that
and
then
go
ahead
and
and
promote
containers
that
pass
from
there.
D
D
You
know
the
container
repositories
that
our
images
live
inside,
of
that
we're
building
has
all
of
our
products
bundled
in,
and
so
what
that
gives
us.
The
ability
to
do
is
Leverage
container
orchestration,
Frameworks
like
fargate
and
ECS
in
AWS
or
really
any
other
Cloud
platform.
So
you
can
see
we
have
here.
D
You
know
your
basic
networking
setup
where
you
know
we
have
individual
network
interface
interfaces
that
are
attributed
to
each
workload:
internet
access,
inbound
and
outbound
through
internet
gateway
and
that
Gateway,
respectively,
and
where
we
have
web
services,
we're
generally
fronting
those
with
albs
and
WAFF.
But
we
do
have
some
for
some
of
some
of
our
tunnel
Frameworks
that
aren't
layer
seven.
So
we
have
nlbs
in
front
of
those.
D
We
leverage
terraform
for
all
of
the
things
and
in
addition
to
that,
we
do
use
the
Terra
grunt
wrapper
outside
of
that
in
order
to
keep
our
infrastructures
code
dry.
So
we
do
write
all
of
our
terraform
as
modules
and
then
reference
the
modules
and
pass
variables
in
in
order
to
to
get
those
spun
up.
One
of
the
other
things
that
the
Terra
Grant
gets
us
is
the
ability
to
create
and
Destroy
entire
stacks
of
of
infrastructure.
D
So
you
know
if
you've
ever
used
teragram
before
you
have
the
the
apply
all
command,
which
is
really
nice.
You
can
keep
all
of
your
infrastructure,
pretty
Atomic
and
then
use
apply
all
to
reach
into
you
know:
substructures
of
your
infrastructures
code
directories
in
order
to
to
spin
up
large
pieces
of
it
all.
At
the
same
time,.
D
D
In
this
case
we
have
an
RSS
feed
URL,
and
if
you
get
this
from
any
news
source,
it's
probably
going
to
be
changing
pretty
quickly
right.
You
know
you
have
the
the
news
cycle
is
pretty
quick,
something's
always
happening
in
the
world,
and
so
you
know
we
have
new
headlines
coming
into
our
feed
all
the
time.
So
what
we
do
is
we
reach
out
to
that
feed.
We
grab
a
predetermined
headline
as
identified
inside
of
a
particular
algorithm.
D
Just
a
series
of
steps
that
we're
going
to
go
through
that
same
algorithm
also
tells
us
how
that
headline
data
is
going
to
be
transformed.
So
maybe
we
have
certain
characters
that
are
replaced
with
other
characters.
You
know,
maybe
we
are
breaking
it
up
into
predescribed
chunks
and
moving
things
around
shuffling
stuff
up.
Each
algorithm
that
we
have
in
our
stack
allows
us
to
do
different
things
to
that
data
and
then,
finally,
we
create
the
key
from
the
data.
D
So
you
know
we
have
workload
a
and
workload
B
that
are
attempting
to
talk
to
each
other.
We
have
them
configured
both
for
the
same
algorithm.
For
the
sake
of
brevity,
we'll
call
that
abc123
and
if
they
are
both
configured
for
the
same
algorithm,
they
can
both
independent
only
derive
the
same
key
for
encryption
between
the
two
endpoints.
D
D
D
You
gain
access
to
anything
else
that
you
can
do
in
Envoy
as
well,
which
is
really
nice.
So
it
gives
us
a
lot
of
flexibility,
gives
our
customers
a
lot
of
flexibility
to
do
whatever
they'd
like
in
addition
to
having
our
filters
in
the
stack,
and
so
you
know
you
can
see
that
maybe
we
have
a
requester
and
a
responder
in
this
communication
stream.
D
Each
one
has
an
on
voice
sidecar
that
is
close
to
it
and
as
the
requester
reaches
out
Downstream
Envoy
handles
that
data.
Our
filter
performs
the
encryption
it
travels
across
the
wire
Downstream
to
the
other
side,
where
Envoy
handles
it
again,
decrypts
it
hands
it
to
the
responder,
and
then
it
comes
back
the
same
way.
D
So
how
do
we
apply
those
Concepts
to
our
products
that
Tom
mentioned
at
the
beginning?
We
have
extra
and
K
for
C,
we'll
start
up
off
with
extra.
So
in
this
scenario
we
have
workload
a
and
workload
B
for
the
sake
of
argument.
They
are
inside
of
the
same
organization
here
and
if
they
want
to
talk
securely
to
each
other
workload,
a
has
an
algorithm
configured.
It
reaches
out
to
its
predetermined
internet
source
and
derives
that
key
using
the
chips
algorithm
that
we
discussed
before
so
now
that
it
has
its
key.
D
It
reaches
out
to
workload
B
with
some
encrypted
payload
workload.
B
says:
hey.
What's
going
on
here,
I
just
received
some
encrypted
data,
I
I,
don't
know
how
I'm
supposed
to
to
decrypt
this.
Let
me
go
ahead
and
and
get
my
key
and
then
I'll
go
ahead
and
be
able
to
decrypt
it.
So
it
reaches
out
to
the
same
source
which
is
configured
by
that
algorithm
on
each
side,
and
now
it
has
the
same
key
that
workload
a
has,
even
though
they
didn't
have
any
key
exchange
and
it
can
decrypt
payload.
D
D
Those
are
configured
by
devops
engineer
when
the
software
is
deployed.
You
know
the
algorithm
is
and
then
the
key
is
derived
the
same
way
that
that
we've
shown
before
right.
You
know
chips
is
involved
in
the
process
and
the
same
key
generation
process
that
we
see
in
extra
is
used
in
in
k4c
as
well,
when
org
a
wants
to
talk
to
ord
B.
D
D
If
that
certificate
needs
to
be
regenerated
or
it
expires
and
needs
to
be
reassigned.
It's
it's
kind
of
its
own
new
entity
right,
so
workload
B
on
the
left,
you
know
is
now
expired.
It
can't
be
used,
but
there's
no
link
between
it
and
the
next
workload.
B
Identity
or
the
subsequent
workload
be
identity.
All
you
get
is
this
trusted
Authority
that
says
like
yeah,
this,
this
identity
is
good,
so
you
know
if
you
haven't
revoked
it
and
it
hasn't
expired,
it's
it's
okay,
but
other
than
that.
D
D
D
D
D
Let
me
go
talk
to
Hopper
and
see
what's
up
so
at
that
point
reaches
out
to
us
and
we
have
queued
up
this
key.
So
the
same
encrypted
path
and
negotiation
takes
place
between
org,
B
and
Hopper
right,
it's
using
its
configured
Green
Key
in
order
to
secure
that
communication,
and
it
is
able
to
retrieve
the
purple
key,
that's
waiting
for
it,
so
they
can
can
communicate
with
or
a
so
at
that
point
or
gay
and
org
B
have
that
purple
key
and
they
can
talk.
D
This
video
is
a
recorded
demonstration
of
Hopper's
moving
Target
defense
solution
that
protects
workloads,
apis
and
data
with
end-to-end
encrypted
tunnels
will
demonstrate
the
Simplicity
of
deployment
and
how
Hopper's
Solutions
work
in
operation
with
deployed
workloads
in
the
cloud.
The
video
is
in
two
parts.
D
D
Encryption
occurs
in
each
session
and
protects
endpoints
by
securing
the
data
communication.
We'll
also
see
how
it
blocks
any
untrusted
connection
from
reaching
a
protected
endpoint.
Let's
look
at
how
easy
it
is
for
a
devops
engineer
to
achieve
end-to-end
encrypted
tunnels
for
their
Enterprise
workloads.
D
It
is
a
simple
process
of
editing,
a
yaml
file
when
deploying
a
workload
to
production.
As
far
as
the
extra
product
for
Hopper
is
concerned,
we
are
going
to
quickly
go
over
the
the
configuration
of
the
product,
which
is
pretty
easy.
You
know
we
provide
some
artifacts
that
enable
point-to-point
communication
and
those
can
be
extended
for
any
types
of
communication
scenarios
that
you
might
have
so
just
running
down
this
really
quickly.
D
We
have
some
kubernetes
artifacts
here
that
we'll
be
showcasing
and
we
have
a
namespace
that
everything
is
going
to
be
deployed
in
a
configuration
map
that
will
be
used
by
Envoy,
which
is
a
very
popular
open
source
project.
That's
used
as
the
underpinning
for
a
lot
of
kubernetes-based
projects,
including
istio,
so
we
have
the
full
Envoy
configuration
syntax,
that's
available
to
us,
and
so
that
outlines
some
real
basic
routing
and
filtering
that
we'll
be
performing
in
this
demo.
D
Then
we
have
a
web
server
script
that
we'll
be
using
to
show
that
we
have
in
fact
reached
the
other
side
of
a
communication
point-to-point
setup,
and
then
we
have
some
registry
credentials
that
we
use
to
contact
the
hopper
repository
for
pulling
down
containers
into
our
kubernetes
environment.
But
this
secret
here
is
really
the
one
that
most
customers
will
be
interested
in,
and
that
is
our
license
key
that
we
use
to
enable
features
within
the
extra
and
other
Hopper
products
and
then
the
chips
algorithm.
D
A
C
D
So
once
we
have
that
implemented.
Essentially,
we
have
communication
between
two
sides.
Here
we
have
on
the
top
our
Babar
node
and
it
is
reaching
out
to
the
Cornelius
node,
and
you
see
it's
getting
response
back
here.
So
every
30
seconds,
the
the
curl
test
container,
is
reaching
out
actually
locally
and
hitting
it
on
void.
Endpoint
that
is
then
filtering
and
sending
it
on
across
the
internet
to
Cornelius
and
Cornelius
is
doing
the
same
thing,
but
in
Reverse.
D
D
So
if
we
have
a
third
endpoint
in
the
mix-
and
we
wanted
to
try
to
connect
one
of
our
secure
endpoints,
you
can
see
that
if
we
try
to
reach
out
to
Babar
from
our
third
endpoint
here,
which
happens
to
be
my
laptop,
we
don't
get
a
response
back
right
now.
The
communication
that's
occurring
from
my
laptop
to
that
endpoint
is
being
initiated.
It
goes
over
the
Internet.
It
goes
into
the
extra
software
and
effectively
since
it's
not
encrypted,
it's
being
black
holed.
D
So
there's
no
response,
that's
coming
back,
which
is
useful
when
you
have
application
endpoints
on
the
internet.
Any
type
of
response
that
you
have
even
rejections
can
positively
identify
the
existence
of
an
application,
so
we
are
black
holding
that
that's
effectively
being
dropped,
but
if
this
endpoint
was
a
legitimate
endpoint,
all
we
would
need
to
do
is
run
the
extra
software
on
that
endpoint.
We
still
cannot
access
the
internet
endpoint
directly.
D
However,
what
we
can
do
is
we
can
access
our
our
local
egress
to
that
endpoint,
which
is
being
served
up
by
Envoy,
and
you
can
see
that
we
have
accessed
The
Listener
port
on
localhost.
However,
we
have
gotten
to
the
the
web
server
endpoint
for
Babar,
so
all
of
that
encryption
occurred
between
my
endpoint
and
the
Babar
endpoint,
and
every
single
session
that
we
initiate
will
have
a
new
key
potentially
based
upon
the
aggregation
of
Internet
information.
D
A
C
I'm
sure
Nick
might
be
able
to
jump
in
as
well,
but
for
our
internal
repository
when
we
are
doing
testing,
we
push
our
containers
to
container
repo
inside
of
gitlab,
but
when
we
want
to
publish
those
containers
to
our
external
customers
and
give
them
a
common
space
in
for
them
to
grab
new
Docker
images
from
we
push
it
to
our
internal
Harbor
instance
that
they
have
access
to
it's.
Just
a
I
saw
you
on
Munich,
so.
D
Basically,
what
the
external
Harbor
in
students
allows
us
to
do
is,
you
know,
have
separate
authentication
for
our
customers
coming
into
to
Harbor
and
also
it
allows
us
to
go
through
that
promotion
process.
So
we
won't
necessarily
allow
customers
to
be
able
to
run.
You
know,
quote
unquote
bad
versions
or
whatever
right.
A
D
D
So,
and
we
made
the
the
choice
to
to
steer
towards
technologies
that
the
folks
were
going
to
be
familiar
with,
and
you
know
we
didn't
want
to
put
anything
out
there.
That
was
going
to
be
you
know
so
so
crazy
and
complex
that
it
was
going
to
take
forever
to
to
get
out
there
right,
like
that's,
that's
one
of
the
main
things
that
differentiates
us
between.
D
You
know
what
we
do,
and
you
know
the
traditional
pki
infrastructure
that
is
required
for
something
like
mtls
is
that
you
know
generally.
Those
setups
for
mtls
are
quite
complex,
at
least
if
you're
doing
it
right,
and
so
we
are
a
much
simpler
thing
to
get
ready,
but
you
know
just
as
strong,
if
not
stronger,
in
identifying
the
the
workloads
and
and
securing
them.
A
All
right,
I
think
in
that
case,
we'll
wrap
it
up.
So
yeah
I
wanted
to
just
say.
You
know,
thanks
to
you,
know,
Nicholas
Stephanie
and
Tom,
for
the
presentation
today
really
interesting,
really
informative
and
great
to
learn
about
how
you're,
using
gitlab
and
yeah
for
everybody
who
kind
of
came
out
for
the
event.
A
Thank
you
for
your
time.
Attention
questions.
You
know:
I
noticed
that
I
think
everybody
who's.
You
know
in
this
room
had
RSVP
for
the
event,
so
you
can
always
go
and
ask
any
follow-up
questions.
You
have
about
the
content
on
the
Meetup
page
and,
if
I
see
anything
popping
up,
there
I'll
be
sure
to
flag
it
for
today's
presenters.
So
you
know
thanks
again
for
your
time
your
attention
and
being
part
of
the
gitlab
community
and
I
hope.