►
From YouTube: How the DoD Use Istio for End-to-End Encryption and Authentication - Zack Butcher & Jeff McCoy
Description
How the DoD Use Istio for End-to-End Encryption and Authentication - Zack Butcher, Tetrate & Jeff McCoy, Platform One
Security remains one of the primary drivers behind service mesh adoption today. We’ll describe why and how Platform One is using a service mesh - Istio - to provide both encryption in transit as well as end-user authentication via SSO for applications across the Department of Defense. We’ll dig into the practical challenges involved in deploying the Istio ecosystem’s authservice, which implements Envoy’s external auth API to provide SSO, and the design considerations that went into making the system incredibly simple for application teams running on Platform One to consume. Finally, we’ll briefly introduce an upcoming NIST IR covering the usage of a service mesh to provide authentication and authorization for applications.
A
Great
so
today
we're
going
to
talk
about
a
couple
different
things,
so
one
we'll
do
just
a
little
bit
of
context.
Setting
tell
everybody
kind
of
what
platform
one
is
what
the
problems
are
solving
and
how
they're
going
about
solving
those
problems,
some
of
their
use
cases
around
service
mesh,
specifically
some
of
the
pain
that
we've
gone
through
kind
of
on
that
service
journey,
a
little
bit
of
practical,
oh
and
as
part
of
the
use
cases,
we'll
actually
show
you
a
little
bit.
A
I
think
some
we'll
actually
have
a
little
demo
there
we'll
talk
about
some
of
the
pain
that
that
jeff
and
kind
of
his
favorite
work
has
experienced
as
as
they've
kind
of
started
on
this
mess
journey
out
of
that
pain.
We'll
talk
about
a
couple
of
some
advice
for
for
kind
of
going
down
this
path
yourself.
I
finally
will
mention
just
very
briefly
a
little
bit
upcoming
literature
as
well
so
jeff
take
it.
Take
it
away.
Tell
us
about
the
platform
one!
Please.
B
Yes,
the
platform
one
is,
I
guess
in
a
nutshell
where
we're
trying
to
do
is
to
is
to
find
a
repeatable
pattern.
That's
somewhat
open
source,
that's
collaborative
in
nature
among
the
various
duty
organizations,
so
that
we
can
kind
of
move
the
ball
forward
and
how
we
think
about
committees.
How
we
think
about
it's,
the
cyrus
stack
and
all
the
tools
that
you
get
with
kubernetes
service
mesh
is
one
of
those
components.
It
is
not
the
only
component,
so
it's
mesh,
it's
not
a
magic
eight
ball.
B
For
us,
it
is
one
piece
of
a
layered
stack
of
security
that
we
offer
and
that
we
try
to
optimize
and
one
of
the
goals
of
platform.
One
is
to
hopefully
over
the
next
year
or
two
is
to
really
push
all
this
back
to
open
source
and
both
the
things
that
we're
building,
as
in
writing,
code
greenfield
applications
and
also
just
the
integrations
we're
building.
We
do
this.
You
see
a
few
tools
listed
there
like
repo
one,
which
is
essentially
our
version
of
github.
B
So
we
have
a
binary
agent
of
trust
that
matters
we
use
the
ubi
or
scratch
or
distrolus
images
as
our
bases,
and
then
we
we
stack
on
top
of
those
layers
and
sign
those
and
publish
those
out
for
people
to
consume
and
from
that
we
produce
something
called
big
bang,
which
is
just
a
way
for
us
to
automate
the
deployments
of
things
like
in
dsop.
Here
we
list
out
here
that
has
things
like
our
chat
solution,
which,
right
now
it's
mattermost.
B
B
So
so
we
want
to
give
a
similar
experience
to
engineers
across
the
board,
whether
they're,
in
that
most
restrictive
working
on
nuclear
weapon
systems
or
if
they're,
building
web
apps
to
show
dashboards
for
for
bosses
in
the
military
or
or
the
department.
And
so
so
really.
Platform
in
a
hole
is,
is
a
way
for
the
dod
to
to
modernize
and
optimize.
How
we
automate
devsecops,
using
kubernetes
and
and
the
various
cyber
tools
that
we'll
go
over
in
this
briefing.
B
Yeah,
so
I
I
think
a
couple
years
ago,
when
we
first
started
talking
about
doing
this
in
the
dod
someone
already
gone
down
this
rabbit
hole
with
you
know:
rancher
had
a
really
great
kind
of
gateway
drug
into
this
world
for
a
lot
of
people
who
didn't
know
varieties.
So
people
who
knew
automation
but
didn't
know
communities
in
the
dod
went
down
that
that
hole.
B
B
The
youtube
was
famously
did
that
recently
and
and
so
the
dod's
starting
to
latch
into
this
concept
of
what
I
would
call
it's
more
than
infrastructure
agnostic,
it's
really
more
about
platform,
independence
and
and
so
with
platform,
one
we
actually
don't
say
valve,
shot,
use,
extreme
commodities
or
you
should
use
rancher
or
you
should
use
convoy
or
you
know
tkg
or
ocp,
or
you
pick
your
poison
right.
We
say
just
give
us
a
n
minus
two
compliant
cluster.
B
So
you
know,
accumulation
is
117
118,
something
like
that
cluster
and
then
we
will
deploy
our
stack
on
top
of
that,
for
you
what's
really
cool
about.
That,
though,
is
we
have
very
different,
inconsistent
environments,
so
we
try
to
segment
those
layers,
so
we
can
move
between,
classified
and
then
classified
easily
and
istio
is
a
very
solid
choice
for
this
there,
because
we
have
a
service
mesh.
We
need
to
decide
pattern.
B
We
love
envoy,
istio
has
some
growing
pains
we'll
talk
about,
but
it
made
a
lot
of
sense,
even
in
the
early
days
after
we
got
through
the
initial
hurdles
of
holy
craps,
there's
a
lot
of
yammel
to
learn
a
lot
of
manifest
and
a
lot
of
things
going
on
here.
We've
we've
worked
through
most
of
those
kinks.
We
think
now
so
we're
getting
to
a
repeatable
process.
Finally,
with
this
geo.
A
So
I
mean
the
the
first
use
case
and-
and
I
think
you
know
from
my
perspective-
this
is
one
of
the
primary
reasons
that
that
I
see
mesh
adoption
right
and
is
the
encryption
and
transit
right
for
a
variety
of
regulatory
reasons,
for
a
variety
of
security
reasons.
This
is
kind
of
what
I
almost
call
the
the
standard
mesh
use
case
right.
A
You
all
had
kind
of
some
interesting
requirements,
though,
or
some
kind
of
interesting
snags
versus
a
lot
of
folks
are
doing
this
in
the
form
of
a
lot
of
legacy,
a
lot
of
off-the-shelf
and
a
lot
of
open
source
software
that
y'all
were
kind
of
pulling
in
to
use
right.
So
I
I
know
we
hit
some
pain
points
there
that
I
think
we'll
talk
about
in
depth
later,
but
that
was
still
not
not
super
easy
to
to
kind
of
get
encryption
everywhere.
Correct.
B
Yeah
and
it's
it's
a
constant
battle
like,
like
you
said,
we'll
talk
about
some
more
specifics,
but
the
bottom
line
was
the
the
automation
of
encryption
was
super
important
to
us.
We
have
some
hard
requirements,
especially
in
the
classified
systems.
I
mean,
if
you
think,
about
the
consequences.
If
we
mess
this
up,
the
systems
using
this
are
not
going
to
affect
your
gmail
it's
going
to
affect
national
treaties,
so
we
have
to
be
really
careful
that
we
get
this
right.
B
So
so
things
like
fips
validation
is
becoming
more
more
important
to
us,
which
is
something
we're
working
through
with
the
different
kubernetes
layers
right
now,
we're
going
to
be
bringing
that
to
other
layers
too,
including
the
tls
rotation
process.
So
there's
there's
all
these
layers
here
that
we
care
about,
but
certainly
it's
it's
not
been
like
easy
button
everywhere.
It's
every
neutral
we
bring
into
the
ecosystem,
is
a
new
challenge
for
us
to
to
figure
out
how
to
make
that
happy
in
istio
land
when
it's
complex.
A
Yep
yep
on
the
flip
side,
though,
the
key
rotation
that
that
issue
brings,
I
think,
is-
has
really
kind
of
opened
up
a
lot
of
doors
right,
because
this,
I
think
that
kind
of
the
the
kind
of
encryption
and
trains
that
they
all
are
getting
today
would
not
have
been
achievable
with
your
legacy
pki.
Do
you
think
that.
B
Totally
yeah
yeah.
No,
I
fully
agree.
I
think
it's!
It's
really
that
that's
one
of
the
biggest
selling
points
is
just
handling
of
cert
rotation,
handling
of
issuance
handling
of
verification.
All
these
things
that
in
pk
island
we
take
for
granted
and
unders.
The
dod
is
one
of
the
biggest
pki
consumers
on
the
planet.
With
you
know
the
common
access
card
it
it's,
how
the
entire
forces
in
the
in
the
u.s
government
essentially
does
their
business
and
authenticates
the
system.
B
A
Are
yeah
yep
exactly
so
that
was
just
kind
of
briefly
and
again
we
didn't
spend
a
ton
of
time
there
on
encryption
in
transit
because,
quite
frankly
I
think
it's
it's
not
super
super
interesting
for
for
a
lot
of
the
folks
here
at
the
server
smash
con.
You
know,
I
will
say
I
think
one
of
the
big
things
that
y'all
are
starting
to
do
and
that
we
would
recommend
here
I
just
revisit.
I
definitely
try
to
root
your
mesh
pki
and
your
existing
pk.
A
That's
going
to
make
your
your
whole
life
easier
with
respect
to
managing
your
the
best
certificates
and
things
like
that.
So
there's
just
one
one:
learning
I'll
leave
there,
but
if
we
transition
over,
I
want
to
talk
about
then
kind
of
the
second
major
use
case
that
you
all
embarked
on
after
encryption
and
transit
right
and
that
was
kind
of
giving
what
you
know
I'll
call
it
sso
for
free
not
for
free
for
y'all
but
effectively.
B
Yeah,
I
think
that
there's
there's
this
really
and
and
as
like
you
know,
you
know-
we've
talked
about
quite
a
bit
over
the
past
year,
but
one
of
my
first
complaints
when
I
first
met,
I
met
you
guys,
you
and
varon
was
hey.
I
just
want
automation
and
how
I
do
sso
and
right
now,
it's
not
great
with
this
deal
because
it
just
it
really
wasn't
like
you
could.
B
You
could
do
often
and
honestly
right
against
jbks
that
kind
of
stuff,
but
there
was
no
management
of
the
user
session
or
it
was
just
you
either
had
a
token
or
you
didn't,
and
if
you
didn't,
you
got
a
big
fat
403
and
that
just
wasn't
great.
So
so
getting
to
the
point
where
we
are
now
sso
for
free
literally
is
we
want
app
developers
come
in
and
build
their
software
and
not
worry
about
the
details.
B
They
just
need
to
be
secure
and
we're
doing
this,
not
just
the
unclassified
but
the
classified
workloads
as
well
work
this
way
and
it's
just
a
way
to
network
break
using
the
service
mesh.
You
know
using
on
voice
filters
that
connection,
so
we
can
stop
traffic
flow,
and
this
is
super
interesting
too,
for
for
tools
that
we
don't
write
and
we
don't
control
that
don't
have
oidc
or
saml
or
other
typical
standard
sso
integrations.
A
Yeah
yeah,
which
is
super
cool.
I
actually
don't
know
if
I,
if
I
realized
that
y'all
are
doing
ozzy
for
for
some
third
party
apps
with
this
as
well.
I
knew
obviously
they
are
going
off
in
and
so
the
the
big
way,
then
that
that
this
is
achieved
is
using
some
some
tooling
out
of
the
iso
ecosystem,
the
the
auth
service
in
particular,
and
so
it
acts
as
a
shim
between
envoys
and
oidc
using
envoy's
external
authorization
api.
A
So
if
again,
I'm
sure
that
other
people
will
give
talks
about
that
today,
but
envoy,
provides
exactly
like
jeff,
said
a
set
of
filters
that
that
call
this
external
auth
api,
the
sectional
authorization
service
that
effectively
provide
a
network
stop
right,
so
they
they
give
us
a
handle
to
be
able
to
insert
in
arbitrary
authorization,
authentication
or
authorization
logic
right
and
so
we'll
we'll
look
at
some
of
the
config.
But
in
a
minute,
but
service
you'll
basically
have
deployed
you
mint
it
out
as
part
of
the
standard
stack.
A
That
is
the
platform
one
deployment
pointed
at
your
existing
identity
providers
and
then
yeah
like
we
said
earlier
label
label
the
pod
and
it
goes.
I
know
there
were
some
enhancements
that
that's
we
I
I
say
we
I
didn't
actually
make
them,
but
you're
also
made
to
auth
service
as
well
to
actually
make
it
fully
usable
right
for
your
use
case,
correct.
B
Yeah
there
are
some,
you
know
in
the
ecosystem.
You
see
this
in
all
open
source
projects.
There's
people
wanting
the
same
problems
right
and
the
same
scenarios
and
somebody
challenges.
They
have
the
same
issue
and
then
somebody
comes
in
and
does
a
pull
request
and
so
on
and
so
forth,
and
we
provided
some
code.
There
wasn't
much
to
change
really.
Frankly,
it
was
very,
very
small,
and
others
have
already
put
as
well.
So
sir
redis
back
end
was
one
of
the
ones
that
was
in
works
that
some
minor
tweaks
we
we
had
there.
B
There
was
also
some
issues
with
just
the
way
that
the
protobufs
work
that
was
breaking
down
instead
of
envoy,
going
back
to
off
service
and
actually
crashing
off
service.
So
very,
very
minor
things.
You
know
very
minor
code
change,
I
should
say
the
very
breaking
breaking
problems
for
us
and
just
the
transition
which
we'll
talk
about
later
on
of
envoy
as
the
api
changed
and
envoy
and
how
we
had
to
change
the
on
wood
filters
was
pretty
pretty
painful
for
mr1617.
A
Yeah
yeah
and
we'll
definitely
dig
into
that
in
a
second
here,
but
actually
you
can
see
here
on
the
right
side,
the
outcome
of
that
which
is
a
new
and
updated
envoy
filter
config
for
istio
1.7,
and
this
is
one
of
the
things
that's
a
little
bit
painful
and
in
the
migration,
but
we'll
get
into
it
a
little
bit
but
effectively.
You
know
like,
like
we
said
before
we
have
this:
this
mesh
wide
envelope,
filter
notice.
It's
in
that
seo
system
name
space.
So
it's
going
to
be
the
default.
A
If,
unless
somebody
has
an
envoy
filter,
you
know
more
specific
than
this
one.
This
one
implies
and
and
teams
deploy
again
with
with
that
label.
In
this
case,
we
the
labels,
protect
key
cloak,
and
what
we'll
do
is
exactly
what
the
envoy
filter
says:
we'll
go
in
there
and
we'll
insert
the
external
oxy
for
all
envoys
that
are
doing
http
requests.
A
That's
that's
an
important
idea
is
the
idea
of
using
the
mesh
to
provide
operational
assurances
and
we'll
talk
about
this
kind
of
at
the
end,
very
briefly
as
well,
but
you
know
the
mesh
is
providing
security
between
the
the
auth
service
deployed
in
the
mesh
and
workloads
in
the
mesh
right.
So
it's
not
just
you
know
just
like
the
messages
providing
security
between
random
arbitrary
services,
effectively
the
same
security
that
the
mesh
offers
any
arbitrary
workload
we
can
use
to
secure
our
often
and
off
z
services
and
gain
additional
security
benefits.
A
Those
operational
assurances
that
the
mesh
provides
for
our
authorization
and
authentication
services
themselves
right,
and
so
this
gives
us
a
powerful
set
of
tools.
It's
really
nice.
When
we
get
to
a
system
that
can
kind
of
model
itself
that
can
represent
itself
right
and
and
with
the
service
mesh,
we
can
start
to
do
that,
and
so
that's
a
really
really
important
idea
that
I
want
to
call
out
and
with
that
I
think
we
we
have.
We
can
actually
show
you
how
the
system
actually
works.
A
B
I
think
it
did
exciting
so
so
inside
of
platform
one.
We
have
this,
this
sort
of
concept,
of
stamping
we're
trying
to
do
right
now
called
hello
world,
which
is
just
like
examples,
distilled
examples
of
how
to
use
parts
of
our
big
bang
product,
and
this
is
the
first
one.
We
did
that.
I
spent
a
lot
of
time
on
myself
directly,
just
because
I
wanted
to
get
it
right,
because
I've
been
stuck
in
the
istio
ozzy
land
for
a
little
bit.
But
but
basically
we
have
this
simple
little
script.
B
B
If
I
run
in
the
same
script,
it'll
destroy
the
cluster
and
recreate
it,
and
if
you
haven't
used
k3d,
it's
it's
similar
to
kind,
but
we
have
quite
a
few
rancher
people
on
our
team
and-
and
they
have
convinced
me
to
love
k
3d,
because
it's
just
really
dang
fast.
As
you
can
see,
it
still
works
really
well,
but
kind
is
also
perfectly
valid
here.
B
A
B
Yes,
but
delete
create
cluster
all
basic
stuff.
You
guys
all
know
this
stuff
and
then
istio
is
going
to
do
its
thing
as
a
reminder,
nothing
fancy
here
we're
just
creating
a
basic
cluster
with
some
ad443
load
balancers
and
installing
some
certs
that
we
generated
that
my
browser
will
not
trust
because
we
use
a
make
sure
to
install
them
and
and
go
from
there
and
deploy
them
out
so
with
this
setup
here,
and
it
should
be
just
about
done
now.
B
What
we
try
to
do
is
kind
of
distill
down
like
what's
what
so
hello
world,
we
wanted
to
show
you
how
simple
it
was,
and
really
this
is
all
it
is
so
pod
info,
if
you
don't
know,
is
a
super
great
tool,
open
source
tool
that
just
shows
a
bunch
of
great
stuff
about
a
pod
running
inside
your
cluster.
So
you
can
use
headers
or
environment
variables
and
do
some
tests
against
it.
There's
a
whole
swagger
api.
B
You
can
check
out,
but
we
wanted
to
show
if
you
took
some
random
workload
in
this
case
pod
info
and
then
protected
it.
What
would
it
take
and
we
used
customize
to
do
patching
so,
if
you're
not
familiar,
you
know
it's
pretty
basic
point
remote
resource
and
add
this
patch
street
merge
here,
which
is
going
to
now,
do
the
enforcement
for
us
and
then
the
config
for
us
service,
which
is
frankly
a
little
verbose
right
now
we
don't
super
love.
This
still,
there's
still
some
work
to
be
done
here.
B
B
B
App
developers
still
do
that
they
want
to,
but
they
don't
need
to
anymore.
So
if
you
wanted
to
do
further
filtering
some
sort
of
aussie
thing
against
the
claim
on
the
jot,
you
could
do
that,
but
we
just
we
don't
require
that
for
our
engineers,
literally,
they
just
say,
go:
read
the
header
jbt
and
there's
your
token
parse
it
out
we've,
given
an
example
of
what
that
looks
like
from
our
sso,
some
basic
information,
what
it
would
look
like
to
them,
because
they
can
see
the
format
and
they
go
from
there
right.
B
So
this
is
booted
now
and
we
can
see
these
labels
exist
here
for
protect
key
cloak
as
expected.
So
I'm
gonna
go
over
here
to
google
and
I'm
currently
logged
into
a
session,
or
hopefully
I
still
am
so
I'm
going
to
go
ahead
and
go
to
localhost
with
this
network
traffic
logging.
So
you
can
see
this
all
right,
so
you
can
see
what
happened
here.
I
don't
want
to
show
you
my
tokens,
but
but
basically
we
were
at
localhost
it
redirected
to
our
our
production
sso.
We
do
that
on
purpose.
B
We
want
the
engineers
to
see
it
live
with
their
real
credentials.
They
actually
see
their
headers
and
see
their
claims
and
because
I'm
already
an
authenticated
session,
another
basically
key
click
as
a
running
session.
Right
now,
it's
active
still.
We
redirected
and
now
we're
back
here
now
to
show
you
another
example
here
we're
not
going
to.
We
went
back
and
forth
and
how
to
show
us
that
exposing
too
much
about
credentials-
or
you
know
how
we
do
this
stuff,
so
we're
just
going
to
let
it
redirect
to
a
login.
B
Basically,
as
you
can
see
here,
redirected
to
that
login
screen
as
expected
and
now
you're
at
our
little
baby,
auto
login
screen
and
just
gee
whiz
facts
when
we
do
key
cloak,
there's
a
whole
bunch
of
extra
stuff.
We're
doing
here.
We've
built
a
whole
custom
framework
around
this,
so
that
we
can
do
the
r
back
and
off
c
stuff
at
key
club
before
it
even
touches
the
workloads
before
it
even
touches
the
oidc
consumer.
So
so
we
actually
do
some
interesting
checks.
Even
beyond
this,
we
actually
have
appgate
for
authentication.
B
So
we
do
a
bunch
of
layers
above
just
this,
but
at
the
very
basic
level.
Here
you
are
at
an
oidc
provider
trying
to
get
authenticated,
trying
to
follow
the
odc
oauth2
flow.
We're
stopping
you
here,
obviously,
because
we
don't
want
to
show
any
more
about
how
we
do
the
dod
side.
It's
you
can
go.
Look
it
up.
It's
very
basic.
It's
all
the
same
off
flows.
A
The
fact
that
we
can
have
sso
against
production
identity
servers
for
any
single
application,
adding
a
label
that
is
is
awesome
and
a
huge
time
saving
as
well
for
a
lot
of
your
developers,
because,
historically,
if
if
they
had
wanted
to
do
this,
they
basically
would
have
had
to
maintain
this
entire
infrastructure
themselves.
Correct,
not
the
identity
servers,
but
the
the
they
would
have
had
to
handle.
Calling
to
you
see
the
whole
flow
right.
B
The
air
force
has
something
that
they
provide
you
as
well,
using
those
and
consuming
those,
and
then
writing
like
these
authentication
brokers,
to
go
to
their
applications
very
complex,
very
risky,
and
then
we
had
others
who
would
okay,
fine,
we'll
use
this
sso
oidc
or
cmo.
Excuse
me
and
then
you
know
we'll
we'll
consume
it
some
way
through
the
application
and
manage
state
there.
B
So
all
these
different
variances,
then
we
finally
got
to
the
point
where,
with
off
service
and
before
that,
a
few
other
similar
tools,
we
used
these
envelope
filters
that
were
really
complex.
The
envoy
filters
were
getting
really
messy,
very
big,
a
whole
bunch
of
stuff
going
on.
It
took
a
dang
degree
to
read
through
those
that
was
complicated,
but
then
it
was
worse
than
that
because
you
also
had
to
deploy
as
a
side
car
off
service
attached
to
the
workload.
So
you're,
not
just
deploying
this.
You
know
envoy
filter
configuration.
B
That's
often
an
aussie
filters
in
istio.
You're
then
also
deploying
this.
This
other
sidecar
thing,
oh
by
the
way,
if
you
have
you
know
more
than
one
replica
running,
which
is
like
what
pretty
much
anyone
does
in
these
systems.
You
now
have
multiple
side
cards
right
for
each
of
those
different
workloads,
so
there's
different
replicas
and
now
your
state
isn't
synchronized,
so
you
have
to
do
things
like
a
back
end,
redis
to
manage
state.
So
now
you
have
this
really
complex
thing.
B
It
was
so
complex
that
we
actually
used
cookie
cutter
to
try
to
automate
the
deployment
of
all
those
manifests,
because
there
was
a
lot
of
manifest
a
lot
of
state
to
manage
for
engineers
who
don't
even
barely
know,
kubernetes
we're
not
expected
to
manage
all
this
complexity.
So
we've
we've
now
broken
it
back
down
to
literally
add
a
label
to
whatever
workload
you
want.
That
will
now
be
protected.
A
Yep,
which
is
yeah
just
awesome,
however,
there
was
a
lot
of
pain
to
get
there
and
you
know
we've
kind
of
alluded
to
it
throughout
right,
but
I
think
it's
worthwhile
for
us
to
kind
of
call
out
and
call
attention
to.
I
I
what
I
think
are
some
pretty
important
areas
that
need
to
be
improved
right,
and
I
think
you
know
jeff
maybe
can
can
scream
this
one,
but
maybe
the
single
biggest
area
that
is
still
rough
today
is
is
upgrades.
Upgrades
are
still
really
painful.
A
B
A
What
even
the
values
that
you
can
set
are
so
then,
to
kind
of
compound
that
a
lot
of
those
values
over
time
have
been
updated
and
upgraded
into
first
class
fields
on
the
operator
api
itself,
which
is
phenomenal.
That's
great
right!
That's
exactly
what
we
want
to
see
the
problem
is,
there
tends
to
be
kind
of
lackluster
documentation
when
that
happens
right,
and
so
there's
not
a
very
good
guide
for
how
you
might
keep
your
operator
api,
your
operator,
cr
up
to
date
over
different
versions
of
istio.
B
Add
color
yeah,
it's
just
weaving
and
matching
generally
speaking,
yeah
from
a
consumer's
perspective.
You
know
we
platform
one
we're
we're,
definitely
probably
third
graders
in
istio
land.
Still
I
mean
that's
why
we
brought
in
tetrad
to
help
us.
You
know
when
we
get
stuck
and
I'll
mention
onboard
filters.
I
had
zach
read
line
by
line
with
me.
B
The
envelope
filters
to
explain
to
me
what's
happening
and
and
why
but
there's
been
just
lots
of
gotchas
throughout
the
the
past
year
year,
and
I
guess
almost
two
years
now
of
doing
istio
stuff-
and
you
know
just
from
a
consumer
perspective,
it's
it's
so
much
better.
We
were
so
excited
about
1.5.
We
jumped
on
1.5,
immediately
yeah
and
that
had
consequences
in
1.6
land.
We
basically
had
to
skip
1.6
because
we
had
perpetual
issues
but
we're
finally
migrating
our
workforce
for
one
five
to
one
seven
and
getting
better.
B
A
Nice
awesome
I'm
glad
to
hear,
and
then
you
know
kind
of
to
carry
on
in
that
same
vein.
Right
there,
oh
yeah,
I
just
complained
about
the
operator
docs
there.
The
other
docs
in
general
need
some
improvements.
I
think
we
talked
about
that
envoy
filter,
specifically,
so
we'll
we'll
revisit
that
one
now
the
syntax
on
the
envoy
filter
changed
going
from
seo
one
six
to
one
seven.
Now
there
was
actually
nice
documentation
going
over
that
change.
Yep.
A
If
you
went
and
read
the
the
detailed
upgrade
notes
for
for
seo
one
seven,
unfortunately,
the
the
underlying
documentation
under
that
we
go
so
hey
envoy,
filter
yeah,
we
know
hey
the
syntax
changed,
that's
great.
Unfortunately,
you
know
that
syntax
change
included
adding
some
things
like
this
at
type
field,
and
so
one
of
the
great
mysteries
is
what
do
I
put
in
the
app
type
field
right,
and
so
there
are
there's
still
some
some
holes
in
the
documentation
today.
A
You
know
this
is
another
example
where
I
think
seo
is
getting
a
lot
better
right.
The
fact
that
we
had
those
detailed
notes
in
the
1.7
upgrade
that
talked
about
the
the
change
of
the
shape
of
the
omb
filter
api-
that's
great
right.
We
haven't
had
that
that
level
of
detail
before,
unfortunately,
there's
still
a
little
bit
of
gap
that
we
need
to
cover.
I
think
in
terms
of
really
making
them
very
usable
and
easy
to
use.
B
A
A
B
Yeah,
I
mean
all
the
love
for
istio
team.
It's
it's
it's
definitely
better,
but
there's
there's
there's
challenges,
especially
when,
in
the
dod's
case
we
just
lack.
We
lack
kubernetes
expertise
in
the
department
overall,
so
it's
it's
contracted
in
right
and
and
the
contracting
quality
is,
is
extraordinarily
varied.
B
B
A
I
think
that
that
if
I
were
gonna
call
out
kind
of
one
of
the
one
of
the
best
areas
in
my
opinion
of
the
project
today,
I
think
I
think
y'all
are
doing
great
stuff
and,
and
really
a
lot
of
the
tooling
has
come,
come
a
really
really
long
way.
There's
still
a
lot
more
to
go
right,
even
catching
little
errors.
I
I
have
up
an
example
here:
right,
jeff
and
the
team
had
changed
some
gateway,
ports
right
and
another
group
that
had
a
virtual
service
that
matched
on
port
number.
A
B
A
In
one
spot,
exactly
exactly,
and
so
that's
some
areas
where
I
think
things
like
you
know-
iso
control
analyze
still
has
room
to
grow
right.
There's
already
pretty
promising
work
there
to
begin,
and
it's
already
super
helpful.
I
think,
as
we
get
more
mature,
we
can.
We
can
start
to
stamp
out
a
lot
more
of
those
kind
of
small.
You
know
gotcha
misconfigs
right
which,
at
least
in
my
experience,
are
the
vast
majority
of
kind
of
the
the
angst
of
istio
configuring.
A
And
then
you
know
finally,
and
we'll
go
pretty
fast
here,
because
we're
we're
nearly
out
of
time.
You
know
jeff,
I
I
don't
know
what
you
want
to
say
about
some
of
the
oss
and
prepackaged
work.
You
know
it
can
be
challenging
for
some
of
these
applications
to
get
iso
to
run
there.
I
think
that
there's
opportunity
for
the
seo
community
to
work
with
some
of
these
other
open
source
communities
to
kind
of
provide
packaged
setups
of
hey
here
is
istio
with
gitlab
or
you
know
whatever.
It
is.
B
Yeah,
I
think,
for
most
of
the
third-party
tools,
where
we're
at
right
now
is
our
basic
idea.
Is
north-south
traffic
we're
going
to
protect
we're
going
to
do
the
tls,
btls
enforcement
and
all
those
the
good
things
we're
we've
been
talking
about
for
third
party
applications?
That's
just
how
it's
going
to
work
for
simple
third-party
applications.
You
know
east-west,
we
can
totally
do
mtls.
You
know
within
that.
Namespace
is
totally
reasonable,
but
something
like
git
lab,
which
is
it
is
no
slide
on
gitlab.
It's
an
incredible
tool.
It's
just
massive!
B
If
you've
seen,
we
deployed
a
lot
of
different
gitlab
instances
right
now
across
multiple
levels
of
classification
and
different
environments,
and
it's
it's
just
a
very
large
home
chart,
essentially
and
and
so
there's
just
a
bunch
of
stuff
going
on
there
so
trying
to
get
mts
enforcement
across
the
the
mesh.
You
know
injecting
sidecars
for
all
those
different
workloads.
It
just
doesn't
work.
There's
so
many
I
mean
we
could
play
whack-a-mole
all
day
trying
to
get
those
to
work,
but
it
just
it
just
doesn't.
B
Then
we
have
weird
ones
like
gypsy,
which
is
a
vtc
option
and
I
actually
met
with
the
creator
of
gypsy
and
a
by
a
super
helpful,
very
informative
about
the
architecture
and
how
they
do
it
at
scale.
For
millions
of
users,
it's
all
vm
based
and
orchestration,
but
it's
it's
not
readies
and
their
their
statement
to
me
was
it
just
won't
run
on
kubernetes.
I
understand
why
they
said
that
now,
because
it
was
literally
a
nightmare
and
it's
still
not
fully
done.
B
We
were
actually
waiting
on
sto16
for
a
change
that
allowed
us
to
do
association
by.
I
think
it
was
request
uri
for
our
sticky
sessions,
but
and
once
this
was
broken
for
us,
we
ended
up
doing
one
seven
but
yeah
just
we
actually
ended
up
leveraging
some
seo
stuff
with
jitsi
for
north
south
and
east
west,
but
then
only
parsley
because
gypsy
under
the
hood
using
webrtc
and
a
lot
of
udp
traffic
and
though
on
voice
supports
that
the
seo
support
is
really
not
there.
B
A
B
Sometimes
you
know
it's
just
typical
open
source
pain,
so
we're
platform
one
is
offering
to
help
now,
so
we're
gonna
try
to
formalize
it
a
little
more
just
to
find
out.
You
know
how
we
can
lend
our
hand
to
keep
it
running
and
maybe
down
the
road
we'll
see
it
more
integrated
with
this
geo
itself
would
be
wonderful.
A
Yeah
no,
I
agree.
I
would
love
to
see
that
awesome
and
so
with
just
you
know,
some
we'll
go
very
quick
here,
because
I
know
we
are
we're
running
short
on
time.
If
you're
looking
to
do
this
yourself,
I
think
you
know
maybe
the
two
biggest
things
that
that
we
would
say
are
standardize
as
much
as
possible
right,
I
think,
especially
as
we're
getting
the
the
1.5
to
1.7
upgrade
kind
of
wrapped
up.
A
B
Yeah,
I
just
have
one
other
thing
that
real,
quick,
the
beyond
just
like
developers,
capacity
to
understand
and
to
to
even
worry
about
something
cognitive,
as
you
mentioned,
there's
also
the
point
of
security
and
and
focusing
your
efforts.
So
now
we
don't
have
50
different
ways
of
implementing
ssl
authentication.
B
We
have
focused
ways,
we're
doing
it
and
we're
consulting
this
down
more
and
more.
We
still
have
deprecated
and
grandfathered
ways,
we're
doing
it
right
today
that
we're
moving
over
to
this
way
over
time,
but
but
the
point
being
that
we
can
focus
our
red
team
efforts
now
and
our
assessors
and
from
a
dod
perspective,
accreditation's
super
important.
You
know
on
other
industries.
A
Yep-
and
this
really
goes
to
the
heart
of
what
I
believe
is-
is
one
of
the
most
powerful
benefits
of
the
mesh,
which
is
it
allows
these
small
central
teams
to
to
create
these
big
wins
for
the
entire
organization
right.
The
fact
that
you
know
who
knows
how
much
how
many
man
hours
you
save
just
in
you
know
how
many
engineering
hours,
just
in
the
the
security
audit
right,
that
that
every
individual
program
has
to
go
to
deploy,
and
so
you
know
in
that
vein,
we
actually.
A
A
That
is
really
about
this.
This
idea
of
the
service
mesh
is
an
operational
assurance
framework
right
a
way
you
know
it
will
will
provi
provide
some
guidance
on
how
you
can
safely
deploy
a
service
mesh
in
a
way
that
gives
you
these
operational
assurances
and
we'll
talk
about
and
we'll
talk
about
what
those
operational
insurances
are
in
detail
and
then
we'll
talk
about
how
you
can
then
use
those
to
deploy
other
systems
like
authentie
and
make
the
overall
system
more
secure,
leveraging
the
service
mesh
right.
A
Is
that
really
kind
of
getting
into
the
meta?
How
we
use
the
service
masterpoint?
You
know
even
things
that
the
mesh
uses
and
so
we're
we're
pretty
excited
about
that
because,
like
we
said
you
know,
we
really
do
think
that
the
the
mesh
is
is
key
for
first
security
moving
forward
and
with
that
I
think,
hopefully,
on
the
day,
we'll
we'll
take
some
questions
jeff
anything
you
want
to
close
with.