►
From YouTube: GitHub Security Best Practices - GitHub Universe 2015
Description
GitHub Enterprise comes with numerous levers to pull to secure your installation in the way that works best for your organization. Matt Duff will bring his experience from the field setting up GitHub Enterprise for companies of all sizes to guide you in setting up your installation to be both collaborative and secure.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
So
this
is
a
github
enterprise,
security,
best
practices
or
getting
out
best
practices.
We're
gonna
have
a
more
of
a
slant
toward
github
enterprise
as
there's
much
more,
you
can
do
a
git
of
enterprise
and
configuring
on.com,
but
there'll
be
a
lot
of
things
that
apply
to
dot-com
as
well.
Just
so
you
know,
kind
of
the
heart
of
this
conversation
is
making
sure
that
you
lock
down
your
github
as
all
of
your
intellectual
property
and
everything
or
are
a
fundamental
part
of
that,
but
also
making
sure
that
you
can
still
collaborate.
A
You
know
and
do
everything
else
you'd
like
to
do
knowing
that
it's
good
hubs.
You
know
the
platform
that
you're
using
that's
one
of
the
main
advantages
of
github.
So
let's
get
started.
I'm
Matt,
Guf
I'm,
an
implementation
specialist
at
github,
I
live
in
Utah,
work,
remotely
and
travel
all
around
the
country
and
the
world
to
bring
github
enterprise
and
github
to
different
corporations
and
customers
that
want
to
get
up
and
running
with
github
and
so
I'm
part
of
the
services
organization
at
github
services
at
github.
A
We
it'll
be
nice
to
talk
with
you
and
you
can
stop
by
I
know.
The
conference
is
almost
coming
to
a
close,
but
don't
hesitate
to
just
walk
over
and
ask
us
in
question
and
even
set
up.
You
know
a
meeting
for
another
time
during
the
upcoming
weeks.
That's
not
a
problem.
So
how
does
this
apply
to
security?
For,
for
specifically,
our
services
team?
Is
we
visit
companies
of
varying
sizes?
A
Some
of
these
companies
are
incredibly
siloed.
You
know
where
they
have
contractors
or
something
like
that
that
have
to
be
in
their
own
spot
and
can't
have
any
access
to
any
of
the
code,
and
then
others
are
why
you
know,
within
the
github
enterprise
install,
are
very
open
and
collaborative,
and
so
we've
seen
every
variation
of
this
under
the
Sun
up
to
this
point.
So
it's
it's.
It's
we've
gotten
some
great
insights
into
this
and
when
we're
on
site,
we
do
different
things
like
set
up.
Your
primary
instance
set
up
your
high
availability
instance.
A
We
set
up
backup
utils
so
that
it's
running
for
disaster
recovery
and
then
we
also
go
through
and
do
you
know
even
get
and
github
workflow
training
and
as
well
as
you
know,
connecting
api's
setting
up
authentication
all
the
things
of
that
nature.
So
we've
had
some
great
experience
up
to
this
point
so
to
get
started.
I
took
this
picture
yesterday
over
on
the
other
side
of
the
building.
I
thought
this
looked
pretty
nice
with
the
Sun
coming
in
there.
A
At
the
end
of
the
day,
I
was
noticing,
like
all
the
holes
in
the
side
of
the
building
and
thought
it's
really
cool
that
it
feels
like
both
inside
and
outside
and
you're,
letting
a
little
bit
of
the
that
outside
in
that's
the
opposite
of
what
people
usually
want
to
do
on
github
Enterprise.
They
want
to
have
it
completely
locked
down.
You
know
both
use-cases
work
very
well
for
what
they're
doing
and
there's
a
lot
of
different
ways
that
that
we
can
do
this
and
so
to
get
started
right
from
the
very
beginning.
A
I,
don't
know
how
many
people
here
are
using
github,
Enterprise,
okay,
so
I'm
calm,
how
many
calm,
okay
yeah,
so
it's
pretty
applicable
for
the
for
the
session.
So
so
many
of
you
may
already
know
this.
But
when
you
log
in
to
get
up
Enterprise
you're
gonna
launch
up
the
service,
you're
gonna
get
the
VM
up
and
running,
and
then
it's
gonna
ask
you
to
create
a
password
pretty
much
immediately
and
enter
your
license
for
github,
and
so
the
password
that
you
choose
in
that
instances
is
for
access
to
the
entire
instance.
A
So
SSH
commands
and
different
things
of
that
nature,
and
so
it's
a
very
privileged
user
that
are
very
privileged
access
that
you
can
get
into
that
with
SSH
access
and
everything.
You're
gonna
want
to
set
up
your
password
here
so
that
you
don't
forget
it
first
of
all
or
write
it
in
someplace
where
people
can
find
it.
We
had
someone
call
the
other
day
and
say:
hey:
do
I
have
to
totally
restart
my
instance
and
reset
everything
up,
because
I
forgot
the
password
that
I
set
up
in
the
initial.
A
You
know
consultation,
and
we
said
no,
you
can
use
you
can
SSH
and,
if
you've
added
your
SSH
key.
So
that
brings
me
to
my
next
point:
is
one
of
the
first
steps.
You're
going
to
do
is
you're
gonna,
add
your
SSH
key
to
github,
and
that
makes
it
so
administrators
can
go
in
and
there's
lots
of
command
line
utilities
that
you
can
run
to.
A
So
once
you
have
that
one
of
the
main
decisions
you're
gonna
have
is,
do
you
make
this
externally
available
or
not?
So
is
your
github
enterprise
install
available
outside
of
your
firewall?
And
you
know
people
go
back
and
forth
on
this,
obviously
a
great
deal
because
it
has
determinations
of
do.
We
need
to
use
VPN
and
and
sometimes
depending
on
geography
and
different
things
of
that
nature
that
can
slow
things
down.
A
But
this
is
pretty
important
and-
and
let
me
just
ask
right
now:
what
is
the
percentage
people
who
have
their
Enterprise
instance
publicly
available
just
out
of
curiosity,
yeah,
okay,
yeah,
so
there's
and
I've
seen
probably
about
50/50
in
the
field
or
people?
You
know
people
will
say
yes,
some
people
say
no,
it
just
depends
on
the
use
case
and
where
people
are
accessing
it
from
as
well.
A
It's
really
when
you,
when
you
do
lock
it
down
with
with
you
know,
no
one
outside
of
your
firewall,
there's
obviously
far
less
risk
of
there,
then
than
otherwise,
but
you
can
often
set
up
things
to
mitigate
that.
So
if
you
do
set
it
up,
so
it's
publicly
available-
and
this
is
especially
applicable
for
people
who
have
that
publicly
available
setting.
It
is
required
that
you
set
up
private
mode
in
the
github
installation
when
you're
going
through
the
setup
screen.
A
So
this
is
one
of
the
options
in
there
and
when
you
click
that
it
makes
it
so
note,
none
of
the
getting
github
data
is
available
external
to
people
that
are
not
inside
of
the
firewall.
So
you
can't,
you
have
to
be
authenticated
really
to
be
able
to
see
any
of
the
data
when
you
have
private
mode
on
and
if
your
instance
is
publicly
available
outside
of
your
firewall.
A
This
is
a
required
setting
per
your
github
contract,
and
so
you
have
to
turn
this
on,
because
we
want
to
be
very
explicit
to
say
that
if
you
have
it
open
publicly,
there
could
be
a
developer.
You
know
that
doesn't
know
what
they're
doing
and
says
I'm
gonna
open-source
this
project,
not
realizing
that
it's
not
just
internally
that
they're
open
sourcing,
it
they're,
open
sourcing
it
to
the
world,
so
you're
gonna
absolutely
want
to
pay
attention
to
that.
A
Setting
and
if
you
don't
know
if
you,
which
one
you
have
right
now
setup
I,
would
check
that
when
you
get
back
another
one
that
you're
gonna
want
to
check
when
you
go
through.
This
is
if
you
look
on
the
top
of
the
slide
right
at
the
top
check
box,
where
it
says
subdomain
isolation.
This
is
another
feature.
A
That's
really
important
from
a
security
perspective
when
you're
setting
up
get
of
enterprise
with
your
DNS
records,
so
subdomain
isolation
separates
user
supplied
content
from
other
portions
of
the
github
Enterprise
appliance,
and
this
mitigates
cross-site,
scripting
and
other
related
vulnerabilities.
If
you
don't
have
subdomain
isolation
turn
on
it's
gonna,
add
endpoints
for
a
whole
bunch
of
the
different
resources
that
github
goes
and
accesses
when
it's
up
and
running,
and
it
makes
you
vulnerable
to
those.
A
And
so
if
you
go
in
and
set
up,
you
know
a
DNS
wildcard
for
a
sub
domain,
or
you
explicitly
go
in
and
add
each
sub
domain
into
the
into
your
DNS
records.
Then
you
can
not
have
to
worry
about
that
problem
and
there's
a
github
help
article.
If
you
just
you
know,
search
github,
Enterprise,
subdomain
isolation,
there's
a
really
good
article
that
that
shows
you
each
and
every
individual
DNS
record
that
you're
gonna
have
to
enter
in,
or
you
know
what
the
actual
assets
will
be
that
it's
it's
delivering
up
alright.
A
So
that
brings
us
to
one
of
the
huge
parts
of
securing
your
github
Enterprise
appliance
and
that's
authentication.
So
most
people
that
use
github
enterprise
are
using
their
own
custom
system
for
for
their
company
and
there's
a
few
there's
a
lot
of
different
ways.
You
can
do
it.
You
can
do
open
LDAP,
you
can
do
LDAP
with
Active
Directory.
You
can
do
sam'l,
you
know
with
a
provider
like
octo
or
something
of
that
nature,
and
so
I'm
gonna
highlight
specifically
LDAP
as
I
go
through
here,
but
it's
applicable
for
the
other
protocols
as
well.
A
Let's
say
so,
if
just
Rea
when
you
first
get
started
in
the
setup
page
and
you're,
setting
up
authentication,
there's
a
few
different
options
that
you're
gonna
want
to
look
at.
The
administrators
group
is
one
and
then
another
one
is
the
restricted
user
group.
So
the
administrators
group,
that
one
is
anyone
who
belongs
to
that
group-
let's
say
in
Active,
Directory
behind-the-scenes.
Anyone
is
a
part
of
that
group
when
it
when
they
access,
github
and
log
in
they
will
automatically
be
promoted
to
the
site
administrator.
A
You
know,
which
is
the
equivalent
of
that
password
that
you
set
up
at
the
initial
part
of
the
github
Enterprise
installation,
and
they
will
be
in
essence
omnipotent
inside
of
your
github
Enterprise
instance.
So
this
is
should
be
a
very
small
group
of
people
that
have
access
to
this.
You
know
they'll
be
able
to
impersonate
a
user
for
troubleshooting
and
things
of
that
nature
with
you
know,
logging,
a
reason
why
they're
doing
it
as
well,
but
they
will
have
access
to
the
entire
github
Enterprise
instance,
once
they're
in
there.
It's
a
really
convenient
way.
A
You
know
if
you
have,
if
you
have
like
an
a
group
for
emails
or
something
like
that
to
just
tie
that
to
to
this
as
well
for
the
support
team.
If,
if
the
plan
is
to
have
all
of
them
accessing
this,
as
and
in
that
way,
you
know,
there's
people
who
can
always
troubleshoot
and
things
of
that
nature
and
have
access
to
everything
the
other
one
down.
A
There
is
a
restricted
user
group,
so
there's
a
few
different
use
cases
for
the
restricted
user
group
one
is
it
does
a
really
great
job
of
making
it
explicit
as
to
who
can
access
github
enterprise
from
an
access
perspective.
So
anyone
who
you
add
inside
of
that
group
will
be
able
to
log
into
github.
If
you
don't
have
something
like
that
set
up,
then
anyone
who
has
anyone
who
can
authenticate
with
your
authentication
provider
can
often
can
log
into
github
enterprise,
and
so
we
set
up
that
group.
A
Often
you
know
call
it
github
users
or
something
of
that
nature,
so
that
it's
a
very
deliberate
step
to
say
we
are
giving
them
access
into
these
controls,
and
another
nice
thing
about
this,
too,
is
that's
actually
a
phenomenal
way,
as
most
of
you
I
assume
err
are
administrators.
This
is
also
a
great
way
to
restrict
seat
count
as
well.
So
you
can
just
have
that
one
LDAP
group,
that's
the
restricted
group,
and
then
you
don't
have
people
logging
in
and
taking
up
seats
that
you
don't
want
to
have
them
take
up.
A
So
that's
that's
a
common
use
case
and
as
well
when
someone
let's
say
you
have
the
event
of
someone
leaving
the
company
or
something
of
that
nature.
If
you
have
that
restricted
user
group
set
up,
there's
only
one
spot
to
really
remove
them
and
they
lose
all
access
to
to
get
up
enterprise,
and
so
that's
a
really
for
workflows
and
Fred
for
administrating
the
enterprise
device.
That's
a
really
nice
setting
to
be
able
to
to
have
that
one
spot.
So
LDAP
has
provides
sync,
which
is
a
really
nice
feature.
A
It's
the
only
protocol
that
we
currently
have
right
now
that
provides
syncing,
and
so
whatever
you
have
in
your
groups,
you
know
like,
let's
say
in
Active,
Directory
that'll
carry
over
into
the
teams
and
things
of
that
nature
in
in
github
Enterprise.
And
so
you
can.
You
know,
map
different
fields
to
go
over
there.
But
when
you
turn
on
that
synchronization,
you
can
also
map
SSH,
keys
and
emails
so
that
you
have
those
defined
and
inside
of
the
instance,
so
that
that's
nice
as
well,
because
then
you
can
control
through
fields.
A
And
so
that
gives
you
a
lot
of
flexibility
to
be
able
to
do
audits
on
those
and
be
able
to
go
through
and
periodically
if
you
desire
and
remove
the
ones
that
should
be
removed,
based
on
whatever
parameters
you
set
up
and
can
access
all
right,
so
I
wanted
to
talk
a
little
bit
about
documentation
and
onboarding
for
for
security.
Forget
eventer
prize,
so
I
think
this
is
often
a
missed
opportunity
that
people
overlook
when
they're
setting
up
get
github
and
and
approaching
it
from
a
security
perspective.
A
But
it's
supported
on
github
Enterprise
as
well,
and
you
can't
for
private
repositories
and
things
like
that
with
a
contributing
MD
file
and
the
readme
file,
you
can
actually
say
when
a
new
user
comes
on
board,
instead
of
them
getting
to
the
point
where
they're
gonna
deploy,
you
know
and
they
sit
down
with
a
couple
people
a
couple
times:
they
show
them
it
and
then
they're
like
alright
you're
gonna
go
you're
a
smart
person
right
and
they're,
not
in
their
head.
You
know,
instead
of
to
avoid
situations
of
that
nature.
A
I
think
it's
a
really
great
pattern
to
set
up
and
the
readme.
You
know
how
you
get
up
and
running
with
your
project
that
you're
gonna
be
accessing
and
then
in
the
contributing
MD
file.
That'll
show
up.
Let
me
just
show
you
this
right
here.
That'll
show
up
in
a
pull
request,
and
so
you
can
see
right
here
underneath
the
pull
request.
As
soon
as
someone
goes
to
open
one
up,
it's
gonna
prompt
and
say:
please
review
the
guidelines
for
contributing
to
this
repository
and
so
I
highly
recommend.
A
A
When
we
go
places,
we
actually
go
through
and
set
up
a
step
by
step
flow
for
developers
to
say
you
go
through
each
one
of
these
steps
when
you're
going
to
contribute
code
and
make
sure
that
you're
matching
it
up
with
the
with
the
following
step
in
the
contributing
MD
file
and
that's
the
path
that
we
go
through
to
launch
any
code.
So
it's
a
great
way
to
make
sure
that
specific
protocols
are
happening,
especially
if
there's
you
know,
audits
or
things
of
that
nature.
A
It's
really
great
to
be
able
to
to
have
them
walk
through
that
pattern
and
know
that
that
it's
very
well
documented
as
to
how
they
go
about
doing
those
steps.
So
let
me
start
with
saying
orgs
and
team,
so
this
is
huge
and
github
enterprise
as
it's
the
main
way
that
you're
gonna
restrict
access
within
the
github,
Enterprise
appliance,
we've
actually
revamped
orgs
and
teams.
Recently,
I
don't
know
if
people
have
seen
that
recent
blog
post,
but
they
got
a
pretty
big
rewrite
to
make
it
a
little
more
granular
and
easier
easier
to
use.
A
The
primary
purpose
of
orgs
and
teams
is
first
and
foremost
for
access.
You
know
like
for
orgs,
specifically
the
Oregon
github
Enterprise
is.
It
is
pretty
much
anything
it's
it's.
A
very
close
to
exact
use
case
of
an
org
on
github
enter
our
github
calm.
You
know
where
we
have
two
very
diverse
companies
like
Twitter
bootstrap,
let's
say-
and
you
know
a
large
corporation
that
are
both
using
github
calm
and
we
need
to
silo
that
information
and
separate
it
from
each
other.
That
is
the
same
use
case
for
for
an
Oregon
get
AB
Enterprise.
A
A
It's
it's
really
gonna,
be
the
fight,
the
the
granular
control
that
you
use
to
restrict,
who
can
access
certain
repositories
and
what
permissions
they
have
in
those
repositories.
So
for
github
teams
there
is
a
new
github
team
flow.
That's
quite
nice,
where,
if
you
remember
moat
right
now,
the
current
dynamic
would
get
up.
A
Teams
is
that
if
you
had,
let's
say
a
QA
team
and
you
wanted
your
QA
team
to
be
able
to
have
right
at
our
right
access
to
certain
repositories
like
let's
say
repositories
they
own,
but
then
read
access
to
other
repositories
that
are
yeah,
read
access
to
other
repositories
that
there
they
shouldn't
be
manipulating
or
anything
of
that
nature.
You
really.
It
was
a
very
common
pattern
to
set
up
two
of
this
teams
of
the
same
name
with
just
adding
the
permissions
right
into
the
team
name.
A
So
I've
seen
a
lot
of
people
do
like
QA,
Reid
and
QA
right,
and
then
they
would
give
permissions
based
on
that
to
the
different
teams
and
get
of
enterprise.
The
new
permissions
model
does
not
necessitate
that
anymore.
So,
if
you
can
see
in
this
on
the
right
here,
you'll
have
on
the
on
the
left
side
and
the
old
in
the
old
model.
It
would
have.
This
team
is
secret
and
it's
only
visible
to
members
and
owners.
The
that's
what
it
currently
says.
A
So
if
you
see
this
has
github
school
example,
foundations
that
has
write
access,
there's
also
read
and
admin,
and
so
you
can
set
it
up
specifically.
So
each
team
you
know
like
so
it
more
closely
represents
your
organizational
structure
inside
of
your
company.
Each
team
can
have
its
own
separate
access
for
an
individual
repository,
and
then
you
can
just
have
one
one
that
people
at
mention.
You
know
when
they
need
review
of
a
pull
request
or
something
of
that
nature.
A
A
All
right
and
then
well
actually,
let
me
let
me
share
one
more
thing
about
this:
the
team
so
so
I,
don't
know
how
many
people
use
github,
Enterprise
2
to
specifically
collaborate.
You
know
with
with
other
teams
and
things
of
that
nature
through
app
mentions
and
github.
You
know
blending
to
see
your
hands
if
you
do
that
yeah.
A
You
know
we
have
I,
think
you
know
through
in
the
300h
for
employees
and
we
have
about
500
teams
in
github
Enterprise
instance
o
our
team's
far
outnumber
our
our
individual
employees
in
the
company,
and
we
use
this
for
communication
of
all
types
you
know
for,
for
you
know,
kickball
teams,
you
know
we
have
a
team
up
and
running.
You
know
to
add
mention
people
and
HR.
You
know
and,
and
you
know,
ordering
new
equipment.
A
We
have
repos
for
all
of
these
as
well,
so
our
use
of
it
is
probably
an
extreme
example,
but
the
really
nice
thing
for
security
is
that
when
you
have
team
set
up
for
collaboration,
you'll
notice
that
your
software
becomes
much
more
secure,
because
when
someone's
writing
a
feature,
instead
of
just
pushing
it,
and
then
you
know,
one
person
on
their
team
says
thumbs
up.
This
looks
good
to
merge
in
and
they
merge
it
in
once
you
have
these
team
set
up
for
specific
functionalities
of
the
site.
A
You
know
to
have,
if,
let's
say,
you're
gonna
you
decided
to
go
and
implement.
You
know
the
you
be
keys
to
have
a
to
have
a
team
specific
for
that,
so
people
can
at
mention
them
bring
them
into
conversations
and
you'll
notice
that
the
level
of
security
will
just
increase
incrementally,
as
time
goes
on,
based
on
the
the
increased
communication.
A
Okay,
so
I
don't
know
who's
who,
if
people
have
seen
this
recently,
but
we
we
recently
launched
protected
branches
and
required
status
checks,
so
protected
branches
and
required
status,
checks.
I,
don't
know
if
any
of
you
know
that
has
been
a
very
commonly
requested
feature
in
the
lifetime
of
github,
and
so
we
we
just
were
really
excited
to
launch
it.
We
we
launched
it,
you
know
and
just
kind
of
letting
people
know
about
the
feature
in
September
and
it's
it's
been
well-received
so
far
for
the
people
that
I've
talked
to
that
have
used
it.
A
A
A
Alright,
and
then
one
thing
that
I
wanted
to
chat
as
well
about
that
we
I've
seen
a
lack
of
familiarity
with
when
I've
visited
people
on
site
is
the
audit
logs.
So
inside
of
github
Enterprise.
If
you
click
on
the
contextual
rocketship
icon
in
the
top
right
of
the
screen,
that's
the
site
administration
button,
the
first
time
you
click
on
that
just
so
everyone
knows:
it'll
bring
you
to
the
admin
for
whatever
it
is
that
you're
viewing.
A
So,
if
you're
viewing
a
repository,
it'll
bring
you
to
the
admin
section
of
that
repository
or
an
org
or
user.
If
you
click
on
it
again,
it
brings
you
to
this
overall
site
admin
with
a
side
nav
that
has
the
management
console
which
there's
tons
of
monitoring
and
things
of
that
nature
in
there
and
then
license
info
all
these
different
things
that
you
can
look
through
and
administer,
and
also
users.
A
You
can
suspend
users
from
that
and
you
can
make
sure
your
dormant
users
aren't
taking
up
C
licenses
if
that's
a
problem,
but
the
auditing
log
I
wanted
to
bring
special
attention
to,
because
this
is
a
really
powerful
way
to
keep
track
of.
Whatever
is
happening
inside
of
your
instance.
There's
also
a
way
and
get
of
enterprise.
Where
you
can
see
it
depends
on.
A
You
know
how
your
firewall
set
up,
but
you
can
see
the
IP
addresses
of
any
requests
that
are
coming
inbound
into
it
and
it'll
map
it
out
on
a
map
and
another
different
part
of
the
of
the
interface.
So
with
the
audit
log,
you
can
go
through
and
you
can
see
the
syntax
there.
It'll
have
like
a
repo
dot
create
and
that
top
list
item
it'll,
have
user
dot
log
in
there
underneath.
A
This
is
just
a
little
instance
that
I
set
up
just
a
demo
this
and
you
can
see
the
action
that
people
are
taking
and
the
IP
address
that
they're
doing
it
from
and
there's
also,
events
in
the
API,
where
you
can
subscribe
to
specific
events.
Do
you
know,
and
you
can
see
what's
happening
and
you
can
make
you
know
tools,
you
can
script
tools
that
will
make
take
action
based
on
what's
happening.
You
know
and
the
different
events
that
are
being
kicked
off.
A
So
that's
a
really
useful
tool
there
to
be
able
to
just
go
through
and
say
we're.
Gonna
have
complete
oversight
of
what's
happening
in
this
instance
and
we're
gonna
be
tracking.
You
know
what
users
do
and,
and
it
also
gives
you
the
ability
to
help
them,
not
just
audit
them
or
different
things
of
that
nature.
If
you
see
someone's
having
a
problem,
but
so
that's
that's
the
main
things
that
I
had
today
I
wanted
to
have
about
10
minutes
left
just
so.
A
A
I
see
yeah
yeah,
so
the
question
is:
there's
the
contributing
MD
file,
but
that's
on
a
repository
basis.
Is
there
a
way
to
do
that
across
the
whole
entire
instance,
and
so
what
we
commonly
do
when
we
go
on-site
with
people
is
right
before
we
leave
we'll
actually
go
through
and
create
a
repository.
You
know
an
onboarding
repository
for
all
the
team
members,
you're
gonna
start
getting
onboarding
and
a
get
up,
enterprise
and
we'll
actually
go
through
and
and
pretty
much
outline.
You
know
like
this
is
how
we're
using
the
github
Enterprise
instance.
A
They
may
do
it.
You
know
we
just
use
a
repository
cuz,
that's
how
we
default
things.
You
can
do
it
and
things
like
confluence
or
different
tools
of
that
nature.
You
can
document
the
process
and
so
we'll
ever
a
repository
called
like
onboarding.
You
know,
that'll
just
be
generic
based
on
you
know
best
practices
for
the
organization
security
protocols.
You
know
maybe
specific
teams
to
reach
out
to
if
they
have
any
questions
or
if
they
need
to
get
special
approval
for
different
things.
A
I
know
like,
for
instance,
some
people
will
require
the
individual
employees
to
come
to
the
enterprise
admin
individuals
to
create
repositories
for
the
org
or
things
of
that
nature,
and
so
we
document
inside
of
a
repo
or
whatever
tool
they
have
the
steps
that
they
can
take
to.
You
know
for
really
any
part
of
using
the
github
Enterprise
instance,
and
then
we
also
go
into
the
contributing
dot
MD
file
for
specific
you
know
for
per
repo
instructions
you
can
also
inside
of
there.
A
You
know
you
could
write
a
script
pretty
easily
to
go
and
add
that
file
to
every
single
repo
and
then
just
riff
in
the
top
of
you
know
the
first
item
for
that
contributing
MD
file
reference
wherever
the
documentation,
literal
instance
altogether,
and
so
there's
we
do
it
through
this.
You
know
training
mostly,
but
there's.
No.
There
isn't
a
current
way
to
push
it.
You
know
all
repositories
based
on
the
UI
or
anything
like
that,
but
it's
an
interesting
feature.
So
any
other
questions
yeah
in
the
back.
A
If
you
have
us,
you
want
to
exclude
certain
users
based
on
a
repo.
Is
that
right
on
a
puppet
repo
is
out.
You
said:
Oh,
repo,
okay,
so
there's
different
ways
that
you
can
do
that
you
can.
You
can
make
it
so
people
are
required
to
do
Forks.
Do
you
know
whenever
they
want
to
access
repository,
so
they'd
have
to
fork
a
repo
and
then
contribute
through
that
or
they
can
be
added
to
the
specific
collaborator
section
of
a
repository
in
the
settings.
A
There's
there's
not
a
current
way
to
go
through
and
say
like
these
are
the
Blessed
people
who
can
merge.
You
know
or
anything
like
that
through
the
UI,
but
you
could
do
something
like
it.
You
could
use
I
haven't
seen
anyone
do
this
yet,
but
you
could
use
this
the
CI
tool
and
the
required
statuses
to
go
through
and
say
verify
that
these
certain
individuals
have
commented
on
the
repo
and,
put
you
know
some
text.
A
A
The
directory,
how
does
the
directory
mapping
map
to
the
seat
count?
So
it's
really
just
anyone.
Who's
logged
in
to
the
enterprise
instance
is
taking
up
a
seat.
If
you
go
into
the
admin
section
on
the
side,
there
is
the
all
users
portion
and
then
the
dormant
users,
so
you
can
see
in
the
dormant
users.
That'll
tell
you
based
on
what
metric
you
know,
they're
gonna
be
considered
dormant
or
not.
It's
like
I'm
excuse
me.
It's
a
month
of
inactivity
for
certain
certain
functionalities
that
they
can
perform
and
then
there's
a
suspend
button.
A
It
depends
on
how
you're
doing
it
like
if
you're
doing
it.
Without
that
sync,
you
would
you
would
remove
them
from
the
LDAP,
your
the
Active
Directory
group,
wherever
you're
using
and
then,
if
you're,
but
you
can
also
just
go
through
the
UI
and
with
other
authentication
methods
and
just
suspend
them
there.
But
it's
anyone.
Who's
logged
in
who
has
not
explicitly
been
suspended
is
gonna
use.
The
seed,
yeah
yeah
go
ahead.
A
Yeah
I
think
I'm
pretty
positive
that
when
you,
when
you
turn
that
on
it's
gonna,
redirect
everything
that
needs
to
be
redirected
and
take
care
of
any
of
those
different
considerations,
so
I
think
if
you're
I'm,
sorry
yeah
good
point.
So
he
was
saying,
if
he's,
if
he
has
a
large
github
enterprise
install
and
it's
been
used
for
a
considerable
amount
of
time
and
he's
gonna
turn
on
subdomain
isolation.
A
Did
you
say,
is
it
possible
to
force
users
to
use
multi-factor
authentication?
So
it's
not
currently,
so
there's
there's
a
few
different
ways
that
you
can
do
this,
but
there's
not
a
checkbox.
Let's
say
on
the
setup
page
level
that
says
everyone
in
this
instance
have
to
factor
off
on.
There
is
the
possibility
there
is
reporting.
A
You
know
in
api's
that
will
report
who
has
it
turned
on
and
I
know
that
the
Guardian
has
an
open-source
project
that'll
actually
run,
and
if
someone
doesn't
have
it
turned
on
it'll
give
them
a
warning
and
then
it
will
suspend
their
account
through
the
API.
So
I
think
that
one's
called
GU,
who
is
the
github
branch,
if
I
remember
correctly,
but
it's
the
Guardian
release
that
that's
a
pretty
commonly
used
tool,
but
there
is
currently
no
way
to
enforce
it
like
on
an
org
level
or
anything
like
that.
There's
lots
of.
A
Can
you
hear
me
now
yeah
yeah,
there's
lots
of
ways
that
you
can
that
you
can
get
that
auditing
report
of
who
does
have
it
turned
on,
but
there's
no
like
heavy-handed
setting
that
says
if
you
just
cannot
access
the
instance.
Yet
if
it's
not
turned
on
yeah
anything
else,
all
right
well,
we
have
a
few
minutes
left.
So
if
anyone
wants
to
come
up
and
ask
any
questions,
I'm
I'll
be
up
here
for
a
few
minutes
as
well.
But
thanks
for
coming
and
I
appreciate
it.