►
From YouTube: CNCF SIG Security 2020-04-15
Description
CNCF SIG Security 2020-04-15
C
Okay,
just
give
it
a
couple
more
mats
for
me
to
get
on
the
call
I'm,
just
gonna
paste
a
link
to
the
attendance
list,
so
anyone
that's
everyone's
already
familiar
to
the
drill,
if
not,
if
you're
new
here,
please
stand
your
name
and
if
you
don't
want
to
be
called
upon.
Just
please
put
no
update
in
parentheses
next
to
your
name
or
if
you're
new,
just
leave
a
blank
and
we'll
introduce
you
during
the
check-in.
Well,.
D
A
F
C
It
something
that
was
tubing
this
myself,
like
do
you
think
it
makes
sense
from
your
perspective,
zoom
for
public
stuff,
that
we
don't
mind,
sharing
I
mean
the
only
time
I
think
we'd
ever
have
to
change.
Anything
in
the
public
meeting
is
if,
for
some
reason
we
had
to
edit
a
video.
If
someone
accidentally
drops
an
ephah
hunk
or
something
so,
do
you
think
that
zoom
is
still
acceptable
for
public
stuff
and
then
any
private
correspondence?
We
get
a
web
extra
slack
instance.
C
E
I
mean
they've
there's
a
lot
of
other
concerns
like
anyone
who's
using
the
zoom
client
on
their
system.
I
hope
is
doing
so
inside
of
a
virtual
machine
or
some
other
contain
environment
that
make
me
fairly
nervous
about
zoom
in
general,
and
there's
also
things
that
you
know.
There's
a
nice
report
by
citizen
lab
talking
about
some
of
the
privacy
and
other
concerns
with
zoom,
in
particular
about
how
they've
gone
about
doing
things
and
providing
keys
to
you
know
on
servers
in
China,
for
reasons
that
you
can
probably
guess
and
so
on.
E
So
I
I,
don't
feel
think
it's
not
just
something
where
there's
like
the
one
tiny
potential,
like
the
one
tiny
thing
that
happened.
That
is
the
reason
why
you
move
away
but
I
think
there's
just
a
whole
litter.
You
know
like
just
a
massive
number
of
reasons
to
perhaps
not
you
zoom,
especially
since
we're
sig
security.
E
C
G
Some
people
paint
it
is
that,
like
do
you
recall,
entering
your
administrative
passwords
together
these
tiles
it
kind
of
miraculously
arrived
on
your
system,
which
is
why
it's
so
popular,
because
it's
so
easy
to
start
using
it,
but
you
can.
Actually.
You
know
it
raises
some
questions
like
how
it's
happening.
You
don't
like
to
put
your
root
password
together,
the
installs.
You
can
do
a
lot.
H
You
know
just
to
riff
on
where
Cabos
was
going
like
that
with
that
for
us
in
particular,
you
know
we
are,
you
know
it's
modeling,
you
know
to
other
groups,
and
so
if
we
use
the
technology-
and
you
know
therefore
kind
of
promote
it
right-
we're
seen,
as
you
know,
security
and
authority
in
cloud
data
space,
and
then
you
know
the
technology
we're
leveraging,
and
everyone
sees
us.
You
know
and
joins
our
meetings
and
is
invited
to
use
that
technology.
C
C
C
I'll
just
get
on
board
with
the
agenda.
I
should
stick
to
I.
Think
everyone's
had
ample
time
to
hop
on
board
and
if
not
I'll,
just
keep
an
eye
on
the
roster
there.
So,
let's
see
attendance
is
there
anyone?
That's?
We
could
volunteer
as
a
scribe,
slash
meeting
minute
taker
today
we
could
use
up
to
two
if
possible,.
C
Seems
we
have
at
least
one
person
starting
to
type
in
the
scribe
role
there
so
I'll
take
that
thank
you
Ray
and
if
someone
else
is
able
to
actually
thank
you,
Ray
Thank,
You
ash,
perfect,
all
right.
Let's
get
this
underway
attendance
check
in
here.
Are
there
any
working
groups
or
SIG's
or
partner
groups
that
have
any
check-ins
today
or
anything
to
bring
up
I,
don't
see
anything
in
the
tenants?
That's
fine.
E
Your
hey
yeah
great,
just
have
a
quick
update
so
as
I
I
wonder
if
I
didn't
check
to
see
if
fund
Reyes
is
on
here,
whether
he'll
give
an
update
or
talk
or
anything
about
the
harbor
assessment,
but
that's
going
along
well.
One
thing:
I
wanted
to
just
kind
of
mention
in
general
that
I
think
I'm
gonna
be
adding
a
little
more
clarity
to
in
the
assessment
plan
on
documents
like
the
way
which
you
do,
security
assessment
is
to
make
sure
that
groups
are
being
very
explicit
about
like
how
they
handle
security
compromises
and
failures.
E
H
E
H
J
E
They're
working
on
resolving
comments
and
they
have
been
pretty
diligent
about
it.
One
thing
that
I
said
in
that
working
meeting
on
Monday
and
will
repeat
again
here
for
the
record
is
like
this
is
a
process
that's
done
kind
of
when
it's
done
and
we're
not.
You
know
it's
not
something
where
there's
like
there's
like
a
game
clock
and
we
have
to
just
you
know,
stop
at
that
specific
time.
E
You
know
if
they
continue
at
the
pace
they
have
for
and
get
us
that
information
in
the
next
24
hours
or
so
I
think
we
probably
will
be
able
to
to
wrap
it
up,
but
we
don't
have
a
we
have
not
yet
in
the
ones
that
we've
completed
the
two
of
them
that
we've
completed.
We
haven't
yet
had
a
firm
timeline
in
part,
because
we're
still
trying
to
you
know,
figure
out
and
different
groups
have
different
amounts
of
time.
They
take
to
do
things.
J
C
A
A
Ended
weirdly:
it's
not
seeing
I'm,
showing
in
my
whole
screen
here.
I,
don't
know
I,
so
weird
zoom
think
I'll
just
stay
on
the
slide
doc.
So
so
so
you
might
know
glue.
We've
been
around
we'll
be
11
years
in
May
we
have.
The
team
is
very
globally
distributed,
we're
on
every
continent,
basically
except
Antarctica,
the
counting
the
deployments
over
the
years.
You
know
we
were
estimated
around
3,000
deployments
and
the
business
model
for
Glu
as
we
sell
support
on
the
glue
server
and
we
have
serving
mostly
large
enterprise
customers
around
the
world.
A
So
there's
50
enterprise
customers,
good
in
partner
network
and
anyway.
So
that's
a
little
background
about
the
glue
server.
So
what
can
be
confusing
to
people
is
differentiating
the
glue
server
from
its
components.
So
the
glue
server
I
tell
people
it's
a
little
like
Red
Hat,
you
could
think
of
Red
Hat
as
a
distribution
of
open-source
components,
some
of
which
Red
Hat
wrote,
some
of
which
they
didn't
but
they're
integrated
together,
given
a
version
supported
for
a
year.
So
it's
productized
and
the
glue
server
is
like
that.
A
So
it
consists
of
a
number
of
different
products
and
that's
our
commercial
product,
the
glue,
server
and
I'm
not
proposing
that
now
that
product,
some
of
those
products
are,
you
know,
conducive
to
be
made
cloud
native.
Some
of
them
aren't
but
I'm
not
proposing
that
we
make
the
glue
server,
that
we
contribute
that
to
CN
CF.
A
So
this
isn't
where
we
are
today.
But
this
is
where
we're
moving
to
so
the
the
core
OAuth
service,
the
phyto
service,
which
is
currently
integrated
into
the
OAuth
service.
But
we
think
we
can
break
that
out
a
skim
service
which
which
is
currently
in
our
admin
component,
but
we
think
we
can
break
this
out
and
a
config
service
which
is
also
currently
and
in
our
admin
service.
A
Horizontal
scalability
was
an
important
design
goal
from
day
one
low
operating
costs,
so
customers
or
who
deploy
the
glue
server.
They
probably
rather
use
a
SAS
like
octave,
but
they
can't,
but
given
that,
given
that
we
will,
even
though
they
might
prefer
a
SAS,
we
want
to
focus
on
making
it
as
easy
as
possible
and
keeping
their
long-term
costs
down,
because
operations
just
goes
on
forever
and
it
ends
up
being
the
biggest
portion
of
your
total
cost
of
ownership.
So
we
always
focus
on
low
operating
cost.
A
Flexibility
was
really
important
to
us.
It
turns
out
that
you
think
authentication
is
like
everyone
does
the
same,
but
it
turns
out
that
everyone's
authentication,
business
logic
is
a
little
different
and
we
wanted
to
make
sure
that
you
could
implement
your
business
rules
without
forking
the
code
forking.
The
code
means
makes
it
hard
for
for
end-users
because
they
have
to
merge
their
codes,
merge
their
updates
and
it
makes
it
hard
to
keep
current
with
the
latest
version.
A
We
have
a
loose
persistence
to
boot
to
the
persistence
layer.
So
a
lot
of
the
performance
of
glue
is
driven
by
the
database
that
it
connects
to.
Initially
we
built
glue
around
LDAP
like
most
of
the
other
access
management
platforms
out
there
two
or
three
years
ago
we
decided
to
implement
another
database.
We
chose
Couchbase
in
the
future.
We
actually
on
the
roadmap
this
year.
We're
looking
at
supporting
Amazon,
maybe
dynamodb
is,
is
what
we're
thinking,
but,
but
basically
there's
an
abstract
adverse
isten,
Slayer
and
caching
layer
so
that
we
can
implement
different
persistence.
A
Backends
we've
always
had
a
test-driven
development
strategy,
so
you
have
to
you
can't
submit
features
unless
you
submit
the
corresponding
tests
and
as
a
design
goal
when
glue
started
in
2009,
there
was
probably
like
20
other
companies
or
organizations
that
had
a
sam'l
product.
So
we
always
said
we
wanted
to
be
the
best
in
the
next
thing
which
in
2009
was
Roth
and
open
ID.
So
we
made
a
big
investment
in
sort
of
being
on
the
cutting
edge
and
really
being
innovative
in
in
the
OAuth
area.
A
So
a
little
bit
of
a
spoiler.
We
just
put
out
this
press
release
yesterday
and
it's
showing
we
basically
did
a
benchmark
where
we
started
one
morning
and
we
spooled
up
enough
servers
to
show
a
sustained
rate
that
would
get
us
to
a
billion
authentications
per
day
and
when
our
competitors
do
this,
they
tend
to
do.
You
know
they
tend
to
hit
the
back-channel
end
point
and
send
the
user
name/password
and
call
that
an
authentication,
but
what
we
did
was
actually
show.
A
How
do
you
scale
the
webs
here,
because
in
open
ID
you're
talking
about
presenting
a
webpage
processing,
the
you
know,
returning
the
code
trading,
the
code
plus
client
credentials
getting
a
token
hitting
the
user
interval
endpoint.
So
we
looked
at
the
whole
web
base.
Open
ID
flow,
not
just
sending
the
username
and
password
and
calling
that
authentication,
and
how
do
you
scale
that
to
a
sustained
rate
of
a
billion
authentications
per
day,
it's
a
pretty
hard
problem.
I
did
benchmarking
for
a
Rackspace.
We
were
trying
to
achieve
this.
A
We
never
could
with
LDAP
based
infrastructures
or
if
we
could,
it
was
only
by
using
proxies,
which
were
really
hard
to
scale
up
and
required
a
lot
of
operational
expertise.
In
terms
of
how
do
you
manage
the
database,
we
were
able
to
do
this
test
on
basically
because
of
advances
in
cloud
native
technology
and
advances
in
the
persistence
scaling,
the
persistence,
but
there's
no
other
I,
don't
think
there's
any
other
commercially
available
system
that
can
do
this.
A
Other
systems
tend
to
show
how
they
could
maybe
scale,
but
they
can't
scale
like
they
can't
auto
scale
to
get
to
this
rate.
I'll
go
more
into
the
benchmark
results
own
later
on,
but
but
just
to
give
you
an
idea.
So,
in
terms
of
the
quality
of
the
implementation,
glue
has
always
been
a
leader
in
the
interrupt
testing.
Before
there
was
open,
ID
certification,
there
was
the
interrupts.
These
are
results
from
interrupts,
for
that
shows
that
glue.
This
was
from
2013
January,
so
glue
was
actually
leading.
A
A
We
are
also.
We
have
login
tests,
which
haven't
even
be
published,
we're
ready
to
pass
those
and
submit
those
we
submitted
glue.
We
to
the
there's,
a
fat,
the
open
ID
provider
set
of
conformance
profiles
and
glue
for
to
which
we're
about
to
release
is
passes
both
of
those
so
glues,
a
very
comprehensive,
open,
ID,
Connect
implementation.
I
would
also
say
that
these
tests
are
like
the
bare
minimum
of
what
you
should
be
doing.
You
could
drive
a
truck
through.
What's
not
in
these
tests,
there's
a
lot
of
missing
negative
tests.
A
Also
so
I
would
say.
In
my
opinion,
these
tests
are
the
bare
minimum
of
what
vendors
should
be
doing.
We're
also
the
only
implementation
to
recertify
four
times.
It's
important
that
when
you
make
a
new
release
you're
according
to
the
Terms
of
Service
you're
supposed
to
read,
recertify
and
we've
done
that,
but
we're
the
only
implementation
to
actually
recertify
four
times.
I
think
we'd
I'd
be
the
only
one
to
recertify
three
times,
even
so
going
a
little
bit
into
what's
in
there
and
in
the
open,
ID
Connect
we
implement.
A
Discovery
is
the
configuration
endpoint
front
channel
back
channel
logout
Seba
is
a
new
open,
ID
profile
that
is
used
for
call
center
push
notifications
to
mobile
devices.
So
if
you
call
it
your
bank
and
they
want
to
push
a
notification
to
your
phone
there's
a
new,
the
new
open
ID
standard
for
that
that'll
be
in
4.2,
there's
also
a
certification
that
we
expect
to
pass
in
4.2.
For
that
question.
C
A
We
implemented
actually
glues
the
most
comprehensive
implementation
of
this
profile,
called
Ummah
user
managed
access.
It's
actually
we're
one
of
four
implementations
that
supports
this
profile,
but
we're
the
only
implementation
that
implements
the
authorization
endpoint
in
oahu.
There's
two
endpoints
there's
the
authorization
endpoints
in
the
token
endpoint
token
is
back-channel.
Authorization
is
front.
Channel
glue
is
the
only
one
that
actually
implements
the
front
channel
endpoint,
which
is
critical
for
use.
Cases
where
you
want
to
get
consent
like
G
in
GDP,
are
the
European
privacy
regulations.
A
You
might
want
to
get
consent
from
a
user
to
call
an
API
on
their
behalf.
You
might
need.
There
is
also
use
cases
in
the
healthcare
industry
for
consent
to
medical
records.
Stuff
like
that,
so
we
like
OMA,
especially
where
consent
of
the
user
is
needed
after
authentication
happens,
and
you
need
to
go
back
to
the
to
interact
with
the
user.
A
We
love
phyto.
We've
built
a
phyto
into
the
glue
server,
including
u2f
and
and
Phi.
We
actually.
Maybe
this
is
a
little
bit
of
a
non
sequitur,
but
we
implemented
a
skin
endpoint
endpoint
for
Fito,
also
because
one
important
question
becomes
okay.
What
happens
when
you
lose
your
fight?
Oh
token,
you
need
some
way
to
unassociated
fight,
oh
token,
from
the
person.
So,
in
addition
to
the
fight
Oh
endpoints
that
are
defined
in
the
spec,
we
also
have
a
skin
profile
for
fight.
Oh,
that
is
conducive.
A
If
you
want
to
enable
user
or
a
user
self-service
portal
to
allow
users
to
say.
Okay,
those
tokens
are
really
small,
eventually
you're
going
to
lose
the
thing
you
need
to
do,
handle
that
I
mentioned
skin.
We
have
a
very
comprehensive
implementation
of
skin.
We
did
interrupts
with
sale,
pointing
and
paying
in
others.
This
has
been
in
production
a
long
time.
Skim
is
actually
pretty
standard.
A
A
We
we,
like
the
stability
of
this
platform
and
and
and
glue,
has
a
lot
of
code
so
we're
using
it
extensively.
Let
me
just
say
a
little
bit
more
about
well.
I.
Think
I
have
some
another
slide
later,
but
so
we
actually
are
I
mentioned
it
somewhere,
but
anyway
yeah
here,
so
we're
looking
at
other
platforms
for
the
smaller
services,
the
phyto
service,
the
skim
service,
the
config
service
for
those
services
we
can
use
lighter
weight
like
Korkis,
is
what
we're
looking
at,
but
there's
for
these
smaller
services.
A
I
think
it's
okay,
but
there's
some
for
the
for
the
core
Oh
auth
service,
even
though
it
might
be,
you
know
larger
than
we
might
like.
We
still
feel
that
the
stability
is
really
important
for
us
for
this
kind
of
product.
We
need
the
stability
and
we
think
it's
been
serving
us.
Well,
there's
been
a
lot
of
features
in
here
that
we
like,
and
we
deploy
in
a
jetty
servlet
container,
so
we
don't
require
an
EJB.
A
Even
though
it's
welled
we
don't,
we
don't
need
a
an
EJB
server
like
wild
flier
or
something
like
that
and
we're
we're
actually
using
the
Amazon
JDK.
This
is
what
we're
using
we've.
You
probably
all
familiar
with
those
issues,
but
okay,
so
persistence
glue.
Does
a
lot
of
persistence.
You
wouldn't
think
so,
but
users
clients
some
types
of
tokens
like
like
long-lived
Refresh
tokens.
Those
types
of
things
need
to
be
written
to
a
disk
and
those
and
and
that
ends
up
being
the
barrier
for
performance,
is
right.
A
Operations
and
replication
ends
up
being
really
an
important
driver
for
when
you
want
to
scale,
and
so
we
have
a
and,
as
I
mentioned,
an
abstracted
interface
that
allows
us
to
maintain
different
different
backends,
LDAP
and
Couchbase.
For
us
supporting
backends
is
a
big
deal,
because
it's
not
just
doing
the
mapping.
It's
also,
you
know
doing
enough
performance
testing
to
make
sure
that
we
have
the
queries,
optimized
and
everything
else
about
it.
The
operational
replication
and
there's
really
a
lot
to
it.
A
So
before
we
take
on
a
new
database,
it's
not
a
trivial
undertaking,
we're
targeting
Dino
DB
dynamodb,
the
we
know
a
lot
of
our
customers,
don't
want
to
be
in
the
in
the
database
management
business
at
all.
They
really
just
rather
like
use
a
cloud
database,
so
we're
looking
at
that.
Our
DBMS
has
been
a
no-go
for
us,
we'd,
actually
like
to
see
an
AR
DBMS
for
smaller
applications,
but
because
of
issues
with
replication
and
scaling
them.
It
hasn't
been
a
priority
for
our
use
case,
which
is
performance
and
horizontal
scalability.
A
Couchbase
has
memory
buckets.
This
is
good
when
you
need
multi
data
center
replication
of
the
cache.
We
also
support
Redis
and
in-memory.
We
support
database
caching,
which
might
sound
like
an
oxymoron,
but
it
it
eliminates
the
need
for
the
cache,
because
we
can
use
the
database
for
replication.
So
in
cases
where
maybe
performance
isn't
needed-
and
you
want
to
simplify
the
number
of
components,
you
can
actually
specify
the
database
instead
of
instead
of
the
cache
but
but
managed,
but
there's
some
data
where
it
would
kill
your
performance
to
write
it
to
the
disk.
A
Like
the
code
and
the
authorization
code
flow,
it's
only
a
you
should
be
used
one
time.
So,
there's
just
no
point
in
writing
it
to
the
disk.
So
for
those
types
of
like
short-lived
objects,
we
need
to
use
the
cache.
There's
pre
authentication
state,
there's
a
number
of
cases
where
it's
not
just
the
persistence
you
need
to
think
about,
but
also
the
caching
I
mentioned
the
interception
scripts
before
as
a
way
to
an
upgrade
friendly
way
to
implement
business
logic.
A
The
scripts
are
written
in
Java
Python,
the
we
we
are
have
shied
away
from
Java.
Having
worked,
you
know,
for
ten
years
before
I
started
glue,
I
work
with
every
SSO
platform
out
there
that
was
available
at
the
time
and
I
felt
like
Java
was
a
big
barrier
to
system
administrators,
and
so
our
goal
was
even
though
we
love
Java,
a
clue
was
to
expose
an
easier
interface
for
customization.
We
chose
Python
as
the
syntax.
A
We
could
have
chose
chosen,
JavaScript
or
groovy,
but
we
chose
Python
partially
because
I'm,
a
big
Python
fan
we
use
JSON,
because
that's
that
was
the
Java
implementation
of
Python.
That
made
it
easy
for
us
to
implement
in
the
future.
I
think
we
might
actually
enable,
and
it's
these
interfaces
in
pure
Java.
That's
on
our
feature
wish
list,
but
these
jython
scripts
have
served
us
well
and
have
enabled
our
customers
to
implement
lots
of
crazy,
like
you
know,
use
cases
that
we
never
thought
possible.
A
Like
I've,
never
heard
any
customer
say
I
need
to
do
this
with
a
glue
server
and
I.
Can't
we've
seen
all
sorts
of
like
very
creative
implementations
of
glue
to
get
to
get
various
use
cases
done
out
of
the
box.
We
so
have
a
lot
of
two-factor
support
social
login,
inbound,
sam'l,
phyto
authentication,
which
I
mentioned
one
time
password
SMS
x.509
certificates
I
have
a
link
down
here
to
even
more
reset
your
password
after
90
days.
You
know,
try
these
two
LDAP
servers
on
the
back
end.
Call
this
API,
there's.
A
Basically
like
lots
of
different
ways.
You
can
implement
how
the
user
gets
authenticated.
There's
lots
of
other
interesting
interception.
Scripts
introspection,
know
auth
token
introspection
is
one:
that's
used
a
lot
when
you
want
to
add
scopes
or
otherwise,
stuff
other
information
into
the
OAuth
token
client
registration.
If
you
want
to
use
software
statements
to
as
an
alternate
trust
model
to
lock
down
dynamic
client
registration,
maybe
it's
too
open
for
you.
So
there's
a
bunch
of
ways.
You
can
implement
these
scripts
to
meet
your
business
model,
okay,
so
there's
actually
no
auth
is
a
big
topic.
A
If
you
look
at
the
OAuth
working
group
at
the
IETF
you'll,
see,
there's
like
I
think
18
RFC's,
there's
a
probably
like
another
10
draft
RFC
is
at
least
so.
Ooofff
like
LDAP
is
a
bunch
of
specs.
You
know
related
ooofff
is
the
same
thing:
it's
not
just
RFC
67
49.
It's
actually
the
whole
a
whole
bunch
of
these
related
rfcs
that
have
come
about
to
promote
best
price
kisses
and
also
to
mitigate
certain
vulnerabilities
of
OAuth
that
have
been
discovered
over
time
glue.
A
A
We
currently
have
a
cheroo
where
beta
testing
snap,
which
is
a
new
distribution
packaging
strategy
for
customers
who
aren't
ready
or
don't
have
economies
of
scale
to
go
cloud
native,
but
for
our
larger
customers,
especially
consumer
and
gun
citizen,
facing
applications,
we're
really
pushing
customers
towards
our
kubernetes
helm,
distribution
of
glue,
and
anyway
we
did
a
quick
chests
checklist
to
see.
You
know
how
we're
aligning
with
some
of
these
principles.
You
can
maybe
I
don't
want
to
go
into
too
much
detail
here,
but
you
can
you
can
check
it
later.
A
We
have
a
huge
effort
on
kubernetes
your
years,
long
effort
in
in
and
and
even
before,
kubernetes
was
out.
We
were
looking
at
how
to
use
orchestration.
For
example,
some
of
you
might
remember,
juju
we
tried
that
we
were.
We
were
trying.
Basically,
we
knew
we
had
this
auto
scaling
problem
before
juju
we
were
looking
at
platforms
like
puppet
and
other
configuration
MANET.
We
knew
we
had
to
figure
out
some
way
to
auto
scale.
A
Kubernetes
really
solved
those
problems
for
us
once
and
for
all,
but
not
without
a
lot
of
work
years
of
work,
I'm
partially
because,
as
you
know,
the
platform
itself
was
changing
a
lot
as
we
were
innovating
there'd
be
new
versions
of
everything.
It
was
really
a
lot
of
work,
but
after
after
you
know
two
and
a
half
years
or
so,
we
really
have
a
pretty
solid
kubernetes
helm,
distribution
of
the
glue
assets,
each
service
running
in
its
own
container.
A
The
the
automation,
the
failover
you
you
guys
are
already
drinking
the
kool-aid,
so
you
know
the
advantages
so
I
mentioned
before
on
the
benchmark
results.
Actually,
in
the
press
release
there
are
instructions
on
how
to
replicate
our
benchmark
and,
and
we
actually,
we
actually
did
benchmark
both
the
resource
owner
password
credential
flow.
This
is
basically
where
you're
descending,
the
username
password
to
the
token
endpoint
and
asking
for
a
token.
We
also
benchmark
the
authorization
code
flow,
but
this
is
a
again
in
the
press
release.
There's
a
link
in
the
glue
docs.
A
We
actually
documented
how
to
achieve
these
results.
I
believe
that
for
the
for
the
code
flow,
it
took
almost
500
glue.
Server.
500
servers,
there's
no
way
you're
slowing
up
by
100
fans
home
to
do
this.
So
so
you
really
need
the
scalability
and
we
do
think
that
actually
this
scalability,
what
was
previously
only
available
like
sure,
Google
and
Microsoft
and
octa
and
Aussie
are
oh,
they
can
do
this,
but
you
can't
license
their
technology
stack
for
authentication
or
not
even
license
you
can't
deploy.
A
So
in
talking
with
some
of
my
friends
at
Linux
Foundation,
if
we
were
to
contribute
the
core
glue
technology,
it
has
to
be
rebranded.
Now
we
actually
have
a
separate
open
source
and
and
commercial
brand.
So
the
currently
leave
the
open
source
stuff
at
glue
we've.
Always
we've
always
had
prefix
and
o
X.
So
there's
ox
off,
there's
ox
trust,
there's
ox
D,
but
we
decided.
Actually
we
can
go.
We
can
go
further
and
maybe
break
and
just
come
up
with
a
totally
new
name
over
the
years.
A
I've
gotten
complaints
about
ox
off
them
being
impossible
to
say
for
French
speakers
also
I'm,
not
sure
I
love
the
metaphor
of
an
ox
being
a
castrated
male
cattle,
so
so
I'm
up
for
so
we're
up
for
changing
the
name,
I'm
suggesting
a
new
name,
we're
named
after
racing
pigeons,
the
fastest
racing
pigeons
on
the
planet.
We're
bred
by
these
guys
Janssen,
so
Johnson
racing
pigeons
are,
are
sort
of
the
known
for
being
the
fastest
pigeons
in
the
world.
A
A
A
We
try
not
to
be
paternalistic
at
glue
and
realized
that
our
customers
have
a
range
of
security
requirements.
Some
of
them
are
very
paranoid,
like
the
Navy
is
a
customer
of
glue.
The
US,
Navy
and,
and
also
others
of
them,
are
in
other
areas
and
using
the
glue
server
for
other
things,
where
maybe
they're,
not
quite
as
paranoid,
and
so
so
I
think
that
it's
important
to
remember
that
security
is
about
mitigation,
not
about
perfection
and
the
extent
of
mitigation
that
we
want
to
leave
that
up
to.
A
We
want
to
make
good
default
choices
for
the
customer,
but
we
also
want
to
leave.
You
know
some
flexibility
to
the
customers
to
find
the
right
security
profile
that
meets
their
needs.
No.
This
is
especially
true
and
open
ID,
where
there's
lots
of
signing
and
encryption
options
and
we're
not
saying
you
have
to
use
them
all.
We
want
to
make
them
available
to
you
and
then
once
the
customer
choose
so
the
question
about
JSON
and
Python
to
seven
you
know,
potentially
you
could
map
other
scripting
interfaces.
You
could
do
Jew,
groovy
or
JavaScript.
A
We
had
that
idea
in
the
past,
I
think
for
the
for
how
these
things
are
exposed
and
compiled.
I.
Think
it's
okay
I'd
like
to
see
what
is
the
attack?
You
know
that
we're
mitigating.
What's
the
likelihood
of
that
attack,
so
I
think
that
just
just
saying
sort
of
knee-jerk
we
should
get
rid
of
this,
but
yeah.
Thank
you.
Those
are
the
slides.
You
knows
may
be
premature,
it's
something
we
can
look
at,
but
the
other
question
is:
let
me
just
read
it:
how
many
enterprises
are
in
production
with
the
core
aspects
being
discussed
today,.
A
So
well,
I
said
around
50
I
mean
almost
all
the
glue
customers
have
to
be
using
this
core
feature.
You
can't
use
glue
without
using
this
open,
ID
connect
component,
the
sam'l
components
are
chained.
So
when
you
do
a
Sam
law
authentication,
we
actually
redirect
you
to
the
open,
ID
connect
provider
to
be
authenticate,
then
send
you
back
to
the
sam'l
IDP,
so
there's
no
way
to
use
glue
without
using
this
portion
of
glue,
and
so
we
do
have
a
commercial
product
called
cluster
manager.
But
this
isn't
a
cloud
native
product.
A
This
is
only
for
VMs,
so
there's
two
cluster
strategies
at
glue,
there's
kubernetes
and
helm,
which
is
open-source
and
then
but
it's,
but
some
of
our
customers
aren't
ready
for
cloud
native
or
they
don't
have
economies
of
scale
or
they
can't
run.
They
don't
have
an
elastic
kubernetes
service
available
that
to
them
and
they
don't
how
to
build
one.
And
so
we
have
another
distribution
of
glue
using
packing
Linux
packages
and
if
you're,
using
these
Linux
packages,
we
have
a
commercial
product
called
cluster
manager,
which
is
a
deployment
tool
that
helps
you.
A
A
We
actually
document
how
you
can
cluster
glue
in
the
documentation,
so
there's
no
secret
about
what
cluster
manager
is
doing
but
I
also
say
you
know
to
open-source
business
people
out
there
just
because
your
products,
open-source,
doesn't
mean
that
everything
you
write
has
to
be
open
sourced
and
this
tool
we
figured
saves
customers
a
lot
of
time
created
commonality
across
cluster
deployments
for
this
VM
distribution
and
we
felt
like
it
was
fair
game
to
them
to
license
it.
But
so
there's
no
I
wouldn't
say
that
clustering
is
commercial.
A
B
B
A
bit
confused
about
which
parts
of
our
software
is
commercial
or
not
kubernetes
in
general,
the
the
setup
of
kubernetes
with
glue
is
not
commercial.
The
cluster
manager
is
is
using
VMs,
it's
nothing
close
to
what
kubernetes
does
on
the
clouds
signed.
So
it's
it's
not
even
there
are
two
different
tools:
kubernetes
and
that
two
point
in
the
deployment
that
it
brings
to
glue
is
all
open
source,
and
you
can.
You
can
just
follow
the
docs
on
how
to
install
that.
So
there's
nothing
commercial
about
that
and
that's
what
we
used
in
the
press
release.
A
Well,
also,
keep
in
mind
that
what
we
agree
to
support
like
the
software,
the
the
binaries,
the
documentation,
that's
all
open
source,
but
that
doesn't
mean
we
have
to
support
you
glue.
Does
a
lot
of
community
support?
You
can
look
at
our
support
forums
and
we
have
a
whole
team
that
does
nothing
but
community
support.
We
find
that
actually
supporting
clusters
is
an
enterprise
requirement
and
and
plus
we
would
need
to
expand
our
community
support
capability
and
we
feel
like
we
can't
support
the
world.
You
know
we
can
give
you
everything.
A
We
can
document
it,
but
but
we
are
what
we
choose
to
support
commercially.
The
community
can
answer
other
community
questions
about
clustering,
but
but
we
don't
feel
like
we
have
an
obligation
to
support
and
it
support
is
what
we
sell
and,
and
so
there
has
to
be
a
business
model,
that's
our
business
model
and
we
we
want
to
support
and
I
always
say
you
know,
open
source,
we're,
not
a
charity
for
big
businesses.
We
give
a
lot
of
free
software.
We
do
a
lot
of
stuff
for
free.
A
We
also
have
to
figure
out
some
way
to
fund
all
that
good
stuff
and
and
then
what
we
sell.
The
support
there
is
no
so
glue
is
not
open
core.
There
is
no
Enterprise
version
or
or
community
version
and
there's
just
one
version
of
glue.
There's
one
specific
tool:
cluster
manager,
that's
licensed
and,
as
we
said
about
four
times,
that
tool
only
relates
to
VM
deployment.
It's
not!
A
So
we
didn't
want
to
create
that
bifurcation
of
motivations
that
glue
so
there's
only
one
version
of
the
glue
server,
but
so
it
might
not
be
as
clear
on
the
marketing,
but
there's
really,
if
you
look
at
glue,
not
only
is
the
glue
server
open-source
but
glue
gateway,
our
our
API
gateway
base
on
Kong
Community
Edition,
that's
open
source.
Our
plugins
or
open
source
super
glue.
Our
mobile
app
is
open
source
also
our
client
software
ox
D,
and
one
of
them
I
missing,
casa,
r2
factor,
credential
of
application
all
open
source.
A
However,
we're
just
we're
not
talking
about
those
those
projects.
Those
are
separate
projects,
we're
really
just
talking
about
the
core
Hoth
open,
ID
service
in
Glu,
which
we
think
is
the
most
relevant
to
the
cloud
community
I
liked
this
last
question
about
what
do
we
want
to
get
from
CN
CF
membership?
Well,
we
want
to
build
the
community
for
Glu.
That's
that's!
A
The
main
reason
is
so:
we've
done
a
good
job,
I
think
getting
the
product
to
where
it
is
today,
but
in
order
for
we
think
it
would
be
hugely
advantageous
to
us
if
we
could
attract
a
bigger
community
to
collaborate
with
and
the
SIA
and
by
aligning
with
the
governance
model
of
CN
CF
and
making
glue
is
pretty
stable.
At
this
point
you
know,
we've
implemented
a
lot
of
feature.
A
So
at
this
point,
we
think
that
if
we
could
formalize
how
features
get
added
to
the
glue
and
create
a
more
consensus,
driven
approach
to
that
process,
we
see
collaboration
opportunities
with
other
CN
CF
projects.
In
particular,
we
already
have
an
integration
with
OPA
in
our
gateway
product.
Well,
we
really
are
big
fans
of
the
declarative
security
model
of
OPA.
A
That
would
like
to
collaborate
on
the
glue
server
more
closely
and
moving
glue.
The
the
core
technology
out
of
glue
the
company
and
and
into
a
foundation
would
provide
some
assurances
and
every
once
in
a
while
and
when
we've
been
committed
to
open-source
for
10
years,
but
every
once
in
a
while.
We
still
get.
You
know
how
questions
about
what,
if
somebody
buys
glue.
A
Evernote
who's
I,
mentioned
in
the
in
the
slides
later
on,
is
one
of
our
customers.
There
they're
deploying
glue
at
scale
and
also
service
other
companies
who
want
to
launch
their
own
afta.
So
we
have
a
number
of
partners
globally
who
want
to
launch
a
hosted
identity
service
based
on
glue
and
so
moving
moving
glue
to
CN
CF,
we
believe
would
create
a
more
would
procreate.
The
governance
structure,
which
would
enable
us
to
collaborate
with
a
larger
ecosystem
of
developers,
I'm.
I
C
H
H
Besides
just
being
able
to
say
it's,
the
OAuth
part,
you
know
not
having
a
focused
project
to
focus
on
is
really
hard,
so
you
know
is
the
correct
understanding
that
Jenson
would
be
that
circumscribed
Olas
componentry
that
you're,
considering
you
know
bringing
into
the
CNC
F
or
is
that
you
know
the
glue
server
that
is
open
sourced
and
you
know
the
name
going
forward.
Yeah.
A
So
the
closest
thing
that
we
have
is
really
aux
off.
That's
our
core
Roth
phyto
component
today.
So
we're
really
talking
about
re.
Naming
that
Jantzen
breaking
out
the
phyto
on
phyto
is
only
like
a
couple
of
end
point:
it's
not
a
really
big
part
of
the
glue
server,
but
we
don't
want
to
hold
back
innovation
of
phyto
four
new
versions
of
the
OAuth
server,
because
phyto
is
a
perhaps
on
a
could
be
you
know.
If
we
have
a
new
phyto
release,
maybe
we
should
dawn
off
the
way
for
the
next
release?
A
Oh,
oh,
so
we
want
to
decouple
these
things.
Really.
You
need
a
config
service.
We
already
have
a
config
API,
but
we're
breaking
that
out
and
into
a
separate
lightweight
config
api
and
the
skim
service
likewise
also
exists,
but
we
just
want
to
break
that
out.
So
these
are
the
four.
You
need
the
skim
service,
because
you
need
a
way
to
add
edit
delete
users
in
the
glue
server.
You
need
the
config
service.
You
can
automate
not
just
deployment
but
also
configuration
of
the
glue
server
and
fight
O&O
auth.