►
From YouTube: Istio success story: USAF CSO Nicolas Chaillan discusses Istio and DevSecOps adoption with Tetrate
Description
The United States Air Force Chief Software Officer Nicolas Chaillan joins Tetrate's Zack Butcher - early Istio engineer and project steering committee member, to talk about the US Department of Defence's use of Open Source and Istio.
In this 'Ask Me Anything' session, Mr. Chaillan discusses the DoD's adoption and use of open source technology on everything from fighter jets to nuclear subs. He explains how everything they do is open source, and founded on the principles of DevSecOps. He details how the DoD saved 100 years in one year by moving 37 programs to DevSecOps, and around $12.5 million in the budget, per year, per program.
On Istio he adds how vital the move to the Open Usage Commons was for their continued adoption of Istio, and how Istio is the key to successful Zero Trust Architecture.
0:00 - 6:22 - Intro
6:22 - 12:02 - What is DevSecOps? Why was it necessary to adopt Istio?
12:02 - 18:58 - Organizational challenges in a multi-diverse environment
18:58 - 22:32 - How far have you come along on your journey? How many clusters do you run?
22:32 - 25:00 - What are some of the benefits that you have been able to get from Istio so far?
25:00 - 28:00 - Why Istio over other options?
28:00 - 30:00 - How do you upgrade Istio?
30:00 - 33:00 - Docker and Docker Security.
33:00 - 33:50 - Are you going with Hybrid deployments? And if you are going with hybrid deployments, how are you doing networking and keeping it secure?
33:50 - 36:04 - What's your metric and logging strategy?
36:04 - 38:10 - What's your approach to multi-tenancy
38:10 - 40:57 - How has adopting more open source impacted overall cybersecurity at DOD?
40:57 - 43:47 - Why adopt a full service mesh and not just an ingress controller?
43:47 - 45:36 - What were the challenges of adopting Istio? And were there any specific set of tweaks or optimizations, you had to do to be able to use it?
45:36 - 50:46 - What are your experience with Kubernetes at the edge? what are observed issues?
50:46 - 52:45 - What do you think you have been successful in bringing radical changes to DOD?
52:45 - 55:00 - How do you incorporate network compliances that are not part of the service mesh?
55:00 - 58:58 - For DOD contractors, how can they get involved with the joint program platform One?
A
A
Yeah
yep,
so
this
will
be
recorded
and
and
posted
and
I'll
and
I'll
go
over
this
again,
but
generally
nick
you
and
I
will
we'll
have
a
bit
of
conversation.
I
have
some
kind
of
cedar
questions
and
then
we'll
actually
open
it
up
for
the
attendees
kind
of
to
ask
some
questions
and
we'll
take
some
some
from
the
crowd
and
kind
of
address.
What
they're
curious
about
as
well.
B
C
B
A
A
A
Please,
if
y'all
as
y'all
are
coming
in
the
a
good
part
of
this
is
gonna,
be
questions
from
the
audience.
I
certainly
have
enough
questions
to
fill
the
time,
but
that
would
likely
be
very
boring
for
y'all.
So
the
goal
is
for
for
y'all
to
be
able
to
ask
questions
and
and
get
info
that
you
all
want
that
you're
curious
about.
So
please,
if
you
already
have
things
that
you're
interested
in
or
curious
about,
go
ahead
and
type
them
in
into
the
q
a
box
as
those
start
to
appear.
C
B
A
B
C
A
Yeah
there
you
go
all
right
so
there,
so
we
are
five
minutes
after
the
hour,
so
we're
gonna
go
ahead
and
get
rolling
folks
for
for
joining
nick
thanks
for
for
joining
us
as
well
I'll
answer
you
in
just
a
second
here
so
just
to
give
context
for
for
all
the
guests
as
you're
coming
in
you
know,
this
is
gonna,
be
an
open
discussion.
I'll
I'll
see
some
questions
with
nick
here,
but
really
the
goal
is
for
you
all
to
to
get
answered
things
that
y'all
want.
A
So
please
go
ahead
and
drop
questions
into
the
q,
a
if
the.
If
the
question
is
interesting
to
you,
please
vote
on
it
as
well,
so
that
we
can
kind
of
order
the
the
ones
we're
going
through
so
without
further
dude
we'll
go
ahead
and
get
started
so
with
us.
So
hey,
I'm
zach
butcher,
I'm
one
of
the
founding
engineers
here
at
tetrate.
I
was
one
of
the
earliest
engineers
on
the
seo
project
and
I'm
currently
on
the
the
istio
steering
committee
as
one
of
the
community
elected
seats.
A
So
thank
you
all.
Some
of
that
is
one
of
those
community.
That's
here
today.
I'm
sure,
and
with
me
is
nicholas
schwain,
who
is
the
chief
software
officer
of
the
us
air
force
and
additionally
and
very
relevant
for
for
us
today,
runs
the
devsecops
joint
program,
which
is
a
program
that
is
across
the
entire
dod
and
nick.
If
why
don't
you,
why
don't
we
start
off
with?
A
B
B
What
we
like
to
think
of
dev
set
ups
is
really
more
about
the
the
continuous
monitoring
piece,
the
baked
in
security.
So
we
use
the
the
concept
of
psycho
containers
to
inject
a
lot
of
cyber
stuff.
We
use
a
service
mesh
like
histo
to
do
the
enforcement
of
zero
trust
and,
more
importantly,
also,
we
have
a
behavioral
detection,
not
just
scanning
of
cve.
B
So
we
we
have
a
country's
monitoring
with
ai
machine
learning,
behavior
based
detection,
so
we
practically
kill
containers
if
they
drift
in
behavior
and
then
we
use
infrastructure
code
and
get
offs,
and
so
those
are
kind
of
the
foundation
of
of
devsecops.
And
for
us
it's
it's
on
cubase,
it's
on
oca
compliant
containers,
it's
the
service
mesh
and
it's
the
decoupling
of
of
these
microservices.
So
we
can
release
it
at
a
pace
of
relevance
and
particularly
for
weapon
systems.
B
You
know
we
run,
we
run
kvas
on
on
jets
bombers,
weapon
systems,
space
systems,
nuclear
systems
and-
and
it's
really
obviously
you
know
critical
and
you
can
mess
up.
You
know,
I
think
it's
not
like
a
mobile
app
on
a
at
the
retailer
right.
Obviously,
a
lot
of
a
lot
of
security,
air-gapped
environment,
classified
clouds,
on-premise
edge,
use
cases
on
the
jet
on
the
on
the
device
itself.
B
B
I
think
many
people
still
struggle
with
the
the
psycho
model,
but
you
know
one
of
the
great
example
of
that
is
you
know,
envoy
with
easter
right
on
how
they
can
you
know
inject
capability
directly
without
having
to
touch
ready
the
container
itself
that
gives
you
that
abstraction
and
decoupling
that
is
really
game.
Changing
when
you,
when
you
start
using
different
programming
languages.
You
know
we
have
16
programming
languages,
23
databases
on
our
stacks
so
and
and
the
devsecops
initiatives.
B
It's
it's
a
drawing
team
with
duties,
tio,
I'm
the
cody
with
the
od
cio
and
we're
trying
to
really
bring
a
couple
of
things.
One
is
that
architecture,
design
and
abstraction
and
cyber
stack,
and
then
we
have
enterprise
teams,
and
I
think
for
for
organizations
that
have
the
size
of
duty
and
with
the
largest
organization
on
the
planet,
obviously
both
in
term
of
budget
and
people.
I
have
a
hundred
thousand
people
to
train
just
in
one
year.
B
B
That
gives
you,
though,
right
the
the
kind
of
an
understanding
of
the
scale,
and
we
want
to
bring
enterprise
capabilities
right.
We
want
to
bring
first,
we
have
the
iron
bank,
which
is,
and
we
have
cool
names
right.
We
have
the
iron
bank,
which
is
this
centralized
repo
of
containers,
kind
of
a
docker
hub.
B
So
it's
with
more
secure,
more
bit
of
scanning
more
assessment,
and
I
can
tell
we've
found
so
much
stuff
that
people
missed
over
the
years
on
a
lot
of
projects,
including
some
of
the
most
used
open
tools
and
commercial
projects
in
devsecops,
and
we
make
them
patch
it
and
and
everything
we
do
is
open
tools.
That's
also
a
big
push
that
I
did.
I
managed
to
convince
the
dod
to
open
tools.
Pack,
everything
we
do.
B
Everything
is
open
source,
all
the
infrastructure,
transcode,
the
terraform,
the
containers,
the
docker
files,
and
then
we
sign
the
containers
with
a
with
a
key,
a
duty
key
and
those
are
even
available
for
download.
So
we
can
be
your
registry
of
container,
so
you
can
pull
these
somewhat
more
trusted.
I
guess
supply
chain
at
least
trusted
bits
and
we
have
about
200.
You
know
containers
right
now,
some
of
the
more
critical
stuff
that
everybody
pretty
much
use
from.
B
You
know,
databases,
api
gateways,
you
know
service
mesh,
I
mean
we
have
easter.
Of
course
we
have.
We
have
k
native
and
we
have
a
bunch
of
different
things,
but
that's
kind
of
the
the
vision
is
to
bring
that
enterprise
capability.
So
teams
can
stop.
You
know
reinventing
the
wheel
and
focus
on
their
mission
software
and
not
have
to
rebuild
the
platform
team,
build
the
service
mesh
build
and
we
support
multi-pocket-based
distribution.
B
You
know
we
use
openshift,
we
use
convoy
with
rancher,
we
use
vmware,
so
we
have
a
bunch
of
options
and
we're
looking
at
even
more
options.
Now
you
know
the
complexity.
Also
for
us
here
is.
We
have
to
run
on
real-time
os.
Not
many
people
even
know
what
real-time
worse
is.
But
you
know
all
these
systems
run
on
real-time
time-sensitive.
You
know
os's
for
embedded
systems
and
same
thing
for
cars,
and
you
know
space
systems
and
stuff
like
that.
A
Yeah
I'm
curious,
we
might,
if
we
have
some
type
of
I'd,
love
to
dig
into
some
of
the
challenges
there,
because
I
think
that's
a
that's
something
that
not
a
lot
of
people
have
done
with
have
dealt
with
it's.
So
I
think
you,
you
very
nicely
also
kind
of
answer
some
of
my
follow-up
ones,
which
is
you
know
why
was
this
necessary
for
y'all
to
start
adopting?
I
think
you
you
answered
that
pretty
clearly.
A
And
obviously
you
know
so
I'm
sure
that
there's
a
litany
of
technical
challenges
which
might
be
interesting,
but
I'm
actually
a
little
bit
more
interested
in
some
of
the
organizational
challenges
like
you
touched
on
you
know,
dod
is,
is
the
one
of
the
largest
the
largest
organization
in
terms
of
head
count
on
the
planet
right
now
right?
How
do
you?
How
do
you
start
to
approach
the
technically
delivering
this
platform
to
them?
A
And-
and
you
know
one
of
the
reasons
I
I
want
to
touch
on
this-
is
you
know
we
do
a
lot
with
with
large
enterprise
customers
right
and,
as
you
know,
instantly
the
the
biggest
challenge
is
the
people
right,
not
the
not
the
the
projects
and
the
technical
stuff.
So
how
have
you
started
to
grapple
with
that
and
how
was
the
program
grappled
with
that
within
the
duty
and
started
to
affect
change
there?.
B
B
To
even
be
here,
you
know,
but
once
I
got
past
the
building,
I
think
the
the
silos
and
the
you
know
that
we
have
obviously
a
lot
of
people
right,
like
you
said,
a
lot
of
silos,
a
lot
of
a
lot
of
different
teams
and
it's
it's
really
segmented
across
dod,
both
in
the
dod
components
and
also
within
the
components.
We
have
dozens
of
teams
doing
different
things
and
they
look.
They
have
to
do
it
because
there
was
nothing
done
and
centrally
by
the
enterprise.
B
So
we
ended
up
with
a
bunch
of
snowflakes
and
a
bunch
of
shadow
I.t
stuff
going
all
over
the
place,
and
you
compound
that
with
a
side
of
the
team,
then
you
compound
that
with
the
classified
environments
right
so
for
us,
if
you
take
a
use
case
of
an
f35
or
any
program,
we
end
up
with
a
lot
of
environments
right
from
unclass,
secret
top
secret
and
even
higher
than
that
right.
We
have
a
lot
of
different
classification
levels.
B
I
know
you
end
up
having
you
know:
dev
test,
staging
quad
environments,
times
eight
nine,
and
so
you
can
imagine
you
want
no
drift.
You
you
wanna,
you
wanna
have
that
automation,
you
wanna
be
able
to
push
across
air
gapped
environments,
so
we
have
all
these
all
these
issues
of
you
know
scanning
reassessing
software,
so
really
doing
that.
B
Now
we
have
60
programs,
so
the
time
saved
is
tremendous
and
that
compounds
over
years
right.
So
it's
just
incredible
the
the
the
timeliness
piece
of
that
right,
the
the
culture
piece
right
back
to
your
people
problem.
You
know
I.
I
always
put
a
caveat
to
that
right
because
people
say
you
know,
the
tech,
easy
is
easy
and
culture
is
hard.
B
C
B
B
C
B
B
So
you
know
whatever
the
fact
is
you
know
by
the
time
you
you,
you
pass
those
certifications.
The
skills
you
end
up,
having
are
completely
absolute
99
of
the
time,
and
so
how
do
you
keep
up
right
and
so
that
that
impacts?
Your
culture,
because
no
you
have
to
reinvent
yourself
and
for
people
it's
hard
right.
You
have
a
job,
you
have
a
family,
you
have
things
to.
B
Do
you
can't
just
complete,
you
know
continuously
around,
so
we
give
an
hour
a
day
to
our
people
to
go,
and
you
know
access
our
learning
hub
and
it's
a
self-learning
environment
where
we
brought
unbiased
content
very
important
right.
If
you
look
at
the
law
of
the
content
out
there,
it's
biased
to
one
company,
so
we
we
partner
with
the
linux
foundation,
the
cncf
and
o'reilly
the
books
to
bring
unlimited
access
to
all
the
content
to
to
have
a
cloud
sandbox
to
so
you
don't
learn
in
vacuum
and
then
look
we.
B
We
really
went
from
top
to
bottom
and
bottom
up
to
really
explain
to
people
why
this
matter,
then,
for
us
it
was
timeliness
to
keep
up
with
the
pace
of
relevance,
and
you
know
people
say
well.
You
know
I
was
on
a
call
today
with
someone
that
said,
you
know
we
you
don't
have
competition,
I'm
like
no,
we
do
have
competition
and
that's
china
and
russia
and
other
countries
that
innovate.
B
But
we
also
have
competition
within
the
commercial
side
where
we
need
to
keep
up
and
we
need
to
innovate
and
we
need
to
not
waste
the
taxpayer
money
I
mean
for
me,
it's
all
about
also
making
sure
that
our
kids
will
be
able
to
compete
in
that
world.
You
know
20
years
from
now,
and
you
know
honestly,
the
bureaucracy
of
dod
makes
you
in
such
a
state
that
you
end
up.
B
A
B
A
C
B
A
B
A
No,
that
was
great
thank
you
for
kind
of
speaking
to
some
of
the
organizational
challenge
there
and
how
you
all
approach
the
the
adoption,
because
that
is
a
challenge
that
is
not
it's
unique
and
scale
to
y'all,
but
is,
is
I
see
with
every
single
enterprise
company?
We
talk
to
right
yeah.
How
do
we?
How
do
we
grapple
with
the
the
the
skilling
up
of
our
of
our
employees
right
yeah?
So
one
of
the?
C
B
B
Exciting-
and
that
tells
you
we're
not
wasting
your
taxpayer
money,
which
is
great
and
then
in
term
of
scala,
there's
a
lot
of
room
right
and
plus
it's
it's
endless
right.
What
what?
What
is
the
end
state?
I
can
tell
you
what
the
nc
is,
because
it's
moving
by
the
time
I
get
there
anyway.
So
I
don't
know
if
ever
we're
going
to
be
at
a
state
where
we're
like.
Well,
you
know
we'll
be
good
right,
hopefully
now
and
so
in
term
of
scale.
B
You
know
we
still
have
pockets
of
teams
right,
so
the,
but,
but
we
see
big
programs,
big
teams
in
dod
move
completely
their
entire
stack.
All
our
nuclear
programs
are
moving
on.
The
ground
are
moving
gbsd
to
to
kubaz
and
platform,
one
that's
a
massive
win
for
the
taxpayer.
That
means
also
people
for
people
to
realize
why
this
matters
initially
back
in
the
day,
at
least
you
know
we,
we
pay
big
big
companies
right
to
to
write
software.
B
Most
of
the
the
woman
is
not
done
by
airmen,
so
it's
companies
showing
up
and
doing
the
work,
but
it's
often
also
subs
and
different
companies,
and
they
have
a
lot
a
lot
of
different
stacks
and
then
they
integrate.
So
so
we
have
an
integrator
that
brings
all
the
stuff
together
and
that
takes
forever
and,
and
you
have
issues
and
you
have
testing
and
disparity
and
and
drifts,
and
and
now
you
have
to
scan
it
test
it
and
oh
by
the
way
the
scan
fails
and
you're
back
to
square
one.
B
So
having
a
centralized
government
furnished
that
the
team
can
come
and
use
with
all
its
its
companies
and
subs
is
game
changing
because
now
it's
not
throwing
over
the
fans
hoping
for
the
best,
it's
the
everyday,
multiple
times
a
day,
pushing
code
in
that
the
government
furnished
the
devsecops
environment
and
we
control
it.
We
see
what's
going
on,
we
see
the
test
every
demo,
it's
not
every
five
years
every
year,
because
you
know
software
pace
used
to
be
every
five
years.
B
I
mean
in
the
government
sometimes
a
year
when
we
are
lucky
but
really
two
five
years
now
we
can
release
multiple
times
a
day.
You
know
that's
game.
Changing
I
mean
we.
We
just
announced
a
few
weeks
ago
that
we
released
software
on
the
flying
jet.
You
know,
while
the
jet
was
flying,
which
is
you
know
again,
I'm
not
sure
much
people
can
top
that
one.
B
You
know
we
do
it
in
a
way.
That's
super,
you
know
I
mean
yeah,
you
know,
that's
that's
the
other
thing
also
with
with
the
teams
we
have,
we
are
not
getting
around
with
nuclear
surety
and
and
safety
air
weldiness.
We
decouple
and
that's
back
to
the
to
the
decoupling
right.
You
don't
touch
your
flight
control.
It's
a
different
part
of
the
system.
B
There
is
no
chance
that
update
will
tamper
with
the
jet
and
the
flying
components
of
the
jet,
but
there's
a
lot
of
features
we
can
bring
on
top
of
traditional
flying
a
plane
right,
there's,
ai
machine
learning,
capabilities
maps.
I
mean
there's
a
bunch
of
classified
stuff,
we
can
talk
about,
but
you
can
imagine
the
value
of
having
sensors
and
being
able
to
swap
sensors
and
and
try
different
things,
and
that's
that's
really
exciting.
To
see.
A
Yeah
definitely
so
that
actually
kind
of
beautifully
brings
me
into
what
are
some
of
the
benefits.
Y'all
have
realized
I've
been
able
to
realize
from
the
program
so
far
you
know
so
obviously
this
has
been
a
huge
movement
and
there's
been
a
lot
of
a
lot
of
people
behind
it
in
behind
the
joint
program.
So
what
what
kind
of
benefits
have
you
ever
been
able
to
realize?
So
far?
You've
touched
on
quite
a
few.
I
think
already
in
terms
of
timeliness.
B
B
I
think
is
obviously
you
know
number
one.
I
mean
you're,
looking
at
an
average
of
between
12
to
18
months
of
time
saved
for
every
five
year
of
initial
plan
time
per
program
per
team
right.
So
that's
massive.
That's
almost
a
third
of
the
time
so
and
that's
without
counting
like
the
faster
feedback
loop
of
the
devsecops
benefits
of
delivering
capability
and
having
a
faster
feedback
loop
from
your
users,
I'm
just
talking
just
pure
accreditation
and
fielding.
So
that's
already
massive
massive
win.
B
It's
also
having
enterprise
capabilities
like
platform,
one
and
cloud
one
cloud:
one
is
our
cloud
office
with
amazon
and
azure
and
classified
clouds
and
then
platform.
One
is
our
devsecops
team.
Having
that
centralized
team
was
saving
money
just
by
not
building
the
same
thing,
20
million
times,
so
that
alone
is
its
meanings.
You
know
potentially
up
to
12
and
a
half
million
per
year
per
per
large
program.
B
So
again,
you
know
we're
talking
a
lot
a
lot
of
money,
so
that
compounds
to
a
lot
of
money,
yeah
that
to
60
60
programs
and
and
also
the
culture
and
the
you
know,
the
fact
that
we
have
the
same
cyber
stack
now
we're
more
modular.
We
can
have
these
continuous
as
lego
blocks
that
you
can
swap
around
and
push
to
different
teams
and
reuse
code
better
so
again,
another
time
saving
and
cost
saving
in
term
of
sharing
sharing
code
and
look
we
open
sourced
it.
B
We
have
other
agencies
like
dhs
and
va
and
other
you
know,
teams
using
using
the
stack,
but
we
also
have
companies.
I
mean
I
have
dozens
of
financial
healthcare
organizations,
retailers
reaching
out
and
starting
to
consume
some
of
the
source
code
we
have
or
even
partnering,
on
the
open
source
projects
to
you
know
do
that
as
a
drawing
team.
So
what's
the
benefit
of
that,
I
mean
it's
tough
to
quantify
right,
but
it's
it's
massive.
C
B
Yeah,
I
have
to
say,
options
now
are
sadly
growing
at
the
time
there
was
less
options.
That's
necessarily
true
we're
not
looking
at
changing
right
now,
but
the
fact
is
when
we
picked
there
was
really
no
other
option
to
do
what
we
wanted
to
do,
which
was
really
for
us,
not
just
a
service
smash,
but
really
that
mutual
tds
enforcement
denial
by
default
and
being
able
to
issue
certificates
for
service
dynamically,
with
no
human
in
the
loop
and
rotating
them
and
and
whitelisting
traffic
to
to
have
that
zero
trust
behavior.
B
That
was
really
the
main
reason
why
we
picked
ease
you
at
the
time
now
you
have
you
know
blinker
d
and
kuma
and
others
whatever
coming
with
kind
of
the
same
capabilities
and
these
pros
and
cons
and
every
implementations
and
things
like
that,
but
ready
for
us.
You
know
the
open
source
components
and
you
know
we.
We
had
a
big
push
with
google
making
sure
they
they
start.
B
You
know
really
opening
also
the
governance
and
and
a
lot
of
that
stuff
with
with
istio,
because
you
know
we
want
to
make
sure
that
no
single
company
is
controlling
the
landscape
and
both
on
the
trademark.
So
so
why
the
trademark
came
to
be
is
really
because
I
complain
about
it
because
for
us
for
us
the
trademark
matters,
because
I
can't
mandate
something
that
has
a
trademark
assigned
to
one
company.
B
So
then
I
could
not
say
you
have
to
use
istio
because
it
would
be
mandating
of
a
company,
even
though
it's
open
tools
doesn't
matter
so
by
making
it
part
of
a
non-profit
that
solved
that
problem.
So
we
might
not
help
a
lot
of
people
for
that
piece.
But
the
the
next
piece,
of
course,
is
the
technical
steering
and
the
steering
groups
and
and
the
governance.
That's
obviously
for
us
very
important
and
not
not.
One
company
can
push
the
single
sided
decisions
and
I
think
we're
getting
there.
B
C
B
That
and
we're
getting
better,
and
you
know
it's
it's
a
it's
a
big,
a
lot
of
learning.
You
know
not.
Everyone
understands
how
a
service
mesh
works
and
and
the
benefits
of
it,
but
I
think
once
you
get
it
and,
and
once
you
start
also
embracing
the
the
sidecar
model,
you
can
do
a
lot
of
pretty
cool
stuff.
A
Yep
awesome
so
with
that.
Thank
you
for
kind
of
a
wonderful,
intro
and
overview
of
what
y'all
are
doing,
what
you
all
have
accomplished,
what
you've
been
able
to
deliver.
So,
let's
start
talking,
let's
start
working
through
some
of
the
the
questions
from
the
audience,
so
I
think
the
first
one
you
touched
on
some
of
the
kubernetes
cluster
stuff
and
you've
alluded
to,
but
I
think
didn't
come
out
and
tell
you
like
how
do
you
all
actually
manage
deploying
and
upgrading
it
to
you?
There.
B
Yeah,
so
everything
we
do
is
get
ups,
so
we
don't
really
use
federation
mostly
because
it's
just
a
nightmare
for
classification
reasons
and
and
look
you
know,
you
don't
want
to
have
one
weapon
systems
compromise
and
then
everything
is
compromised
at
the
same
time.
So
having
some
sort
of
you
know,
silo
siloed,
you
know
stack
is
makes
sense
right
and
so
we're
not
we're
not
there
willing
it's
not
that
we're
not
capable
we're
just
not
willing
to
go
to
federation.
B
But
what
we're
doing,
though,
is
that
a
central
source
code
of
truth
of
of
a
terraform
and
a
cluster
api
and
and
every
option
we
have
in
term
of
kubernetes
from
from
from
the
the
cloud
to
all
the
way
to
kubernetes.
You
know
from
running
to
on
vsphere
on
amazon,
on
azure
at
the
edge.
All
that
code
is
in
the
same
repo.
So
there
is
no
drift
and
we
can
instantiate
it.
You
know
like
cattle
and
we
treat
our
cluster
as
cattle.
B
So
for
us,
it's
like
you
know
you
can
kill
it
every
night
or
you
know
every
day
I
don't
care.
Everything
is
cattle,
not
just
the
containers
right.
So
once
you
really
embrace
that
get
ups
mentality
of
everything
is
code
and
your
networking
and
that's
how
we
do
our
change
management
right.
How
many
set
of
eyes
do
we
have
on
code
change?
And
you
know
many
companies
do
this
right,
spacex
and
others
where
you
know
you
need
three
set
of
eyes
on
code
to
approve
a
some.
B
You
know
critical
code
change,
maybe
just
two
for
other
stuff.
But
you
know
you
decide
how
many
you
you
do
per
repo
and
then
we
segment
of
code
right
for
container
service,
mesh
platform,
infrastructure,
terraform
code
and
stuff
like
that
right.
So
we
cut
that
into
layers,
and
then
we
can
update
that
and
and
then
we
can
instantiate
it
on
on
classified
gap,
environments
on
on
different
clouds
on
different
providers
at
the
edge
on
the
weapons
or
anywhere.
It's
just
a
push
button
deployment.
A
B
Yeah,
and
so
we
don't
use
docker
ee
or
all
that,
that's
that
stuff
we
we
use
kubernetes,
we
have
multiple
distributions
of
cubans,
they
have
to
be
cncf
compliant,
they
have
to
work
gaps,
that's
the
monday.
So
for
us
any
anything,
that's
the
control.
Plane
is
running
on
on
the
cloud
and
we
don't
have
access
to
that.
It's
not
an
option.
B
We
have
to
control
everything,
as
you
can
imagine
you
don't
want
to
have
a
control
plane
running
somewhere
else
that
you
don't
know
what's
going
to
happen
to
it,
and
so
you
know
we
centrally
accredit
and
scan
each
distribution.
In
fact,
the
the
code
of
convoy
and
and
vmware,
and
you
know
even
upstream
queries,
and
we
have
a
bunch
openshift
and
convoy.
I
mean
everything
is
on
the
susque.
B
My
repo
and
I
put
the
I'll
put
the
link
on
the
chat,
so
people
can
go
and
and
see
that,
but
really
that's
where
we
centrally
harden
the
distros
and
we
scan
them
and
look
if
it's
good
enough
for
weapon
systems,
I'm
pretty
sure
you
should
be
able
to
convince
your
boss
to
use
it
too
right
so
and
use
us
as
a
reference
right
but
yeah.
We
we
do
a
lot
of
hardening
and
scanning
and
we
have
a.
We
have
a
m
many
advanced
setting
right
on
kubernetes
to
to
harden.
B
B
C
A
B
Yeah
so
I
kind
of
forgot
what
I
was
saying,
but
I
was
saying
we
have
oh
yeah.
We
have
all
the
different
distributions
so
use
that
and
use
our
hardening
and
look
you
know
I
I
would
not
use.
I
would
I
mean
I
don't
mind
using
the
docker
runtime,
but
I
would
not
use
docker
without
commands
and
without
you
know
the
orchestration.
I
just
that's
what
we
use,
but
that's.
A
A
B
Yeah
we're
completely
cloud
agnostic,
the
entire
stack
is
built,
you
know
using
terraform
and
and
even
our
single
sign-on
and
and
we
we
really
abstract
every
layer.
We
use
kick
look
for
single
sign-on,
you
know
we
we
don't
directly
tap
into
apis
even
for
stuff.
Like
lambda,
we
don't
use
lambda,
we
lose
k
native,
so
we
don't
get
locked
into
a
single
cloud
provider.
B
A
B
Yeah
yeah,
that's
that's
very
difficult
right
to
aggregate
the
logs,
it's
almost
impossible.
First,
you
can't
do
it
across
classification
level
or
then
you
end
up
at
the
highest
specification
level,
which
means
people
without
the
highest
clearance
cannot
see
anything
which
defeat
the
point
of
their
psychops.
So
you
don't
have
the
feedback
loop
to
the
team.
So
so
we
we
do
it
per
cluster.
B
We
use
the
fk
pair
cluster
today
and
we
aggregate,
and
then
we
have
you
know
traditional
loading
permits,
use
and
all
that
kind
of
stuff
with
kelly
right
stuff
like
that
metrics.
Of
course,
we
also
track
the
dura
metrics
right,
the
mean
time
to
production.
We
tend
to
be
appropriate
all
that
kind
of
stuff
we
try
to
make
by
using
jira
tickets
and
git
lab
comments
and
try
to
see
how
quickly
that
the
container
gets
deployed.
B
But
you
know
when
they
get
deployed
on
the
classified
side,
it's
very
difficult
to
be
able
to
track
that
kind
of
stuff,
because
we
can't
really
do
that
feedback
loop.
Although
we're
trying
to
see
how
we
declassify
just
the
simple
fact
that
the
computer
was
deployed,
so
at
least
the
team
knows
that
the
deploy
worked
successfully,
so
they
don't
have
to
know
where
it
went
or
how
that
went
the
concept
outside
if
they
have
a
clearance,
but
they
know
it.
We
have
probably
the
biggest
impediments
right.
B
Have
to
do
air
gap,
but
but
they
don't
have
the
classification
nightmare
we
have
and
the
size
we
have
it's
just
everything
is
compounded
right,
yep,
but
we
we
have
enough
to
to
know
for
each
cluster
and
each
team
exactly
kind
of
how
well
they're
doing
and
and
we
track
you
know-
tickets
in
gerard
and
confluence
and
and
we
use
gitlab.
Also,
some
teams
use
gitlab
ci
as
well,
and
then
we
use
I'll
go
see
the
idea
and
talk
about
that.
B
A
B
Yeah,
so
we
have
two
modes
right
in
platform:
one
we
have
what
we
call
the
party
bus,
which
is
our
multi-tenant
environment,
and
then
we
have
the
big
bang,
which
is
a
dedicated
instance
of
platform,
one
on
any
classification
level.
That's
really
for
the
bigger
programs.
They
don't
want
to
share
they're,
not
going
to
do
multi-tenant.
B
You
know
it's
too
risky
just
for
cyber
reasons
right
and
so
the
smaller
teams
that
have
less
money
they
want
to
share,
and
we
also
have
a
big
big
engagement
called
abms,
that's
sharing
across
dod,
and
so
that
is
where
we
go
with
the
potty
bus
and
the
bodybus
is
just
a
multi-tenant
environment.
Where
we
we
manage
the
stack
for
the
team
and
we
just
implement.
You
know
traditional
all
back
a
back.
We,
we
did
a
pretty
cool
single,
sign-on
stuff
to
be
able
to
be
very
granular.
B
B
You
know
we
have
different
classification
levels,
so
you
can,
you
could
say,
based
on
the
device
I
use
and
the
state
of
the
device
I
use
if
it's
a
brilliant
device
or
if
it's
a
government
furnished
device,
if
it's
a
mobile,
if
it's
a
tablet,
if
it's
a
laptop,
if
it's
in
a
classified
space,
if
it's
not,
then
you
can,
you
can
grant
access
to
resources
and
and
have
more
and
more
access
to
things
all
the
opposite.
You
know
not
a
white
list
based
on
the
state
of
the
device.
B
If
it's
not
patched
or
updated,
so
we
use.
We
have
a
what
we
call
the
club
native
access
point,
which
is
how
we
connect
to
to
our
enclave
on
the
cloud
and
that
architecture
is
on
the
website.
So
I
put
the
link
of
the
website.
If
people
want
to
see
how
we
architected
all
zero
trust
access
to
the
cloud,
that's
how
we
connect
to
resources
on
the
cloud.
A
B
First,
you're
gonna
have
to
find
me
a
piece
of
software
that
doesn't
use
open
tools
somewhere
anyway
in
the
dependency
or
something
we
don't
even
know
about,
but
I
would
say
it's:
it's
suddenly
a
risk,
but
at
the
same
time
it's
I
think,
massive
improvement.
We
have
eyes
on
code,
we
know
what's
going
on,
we
can
scan
it.
We
can
have
a
you
know.
We
can
have
teams
embedded
into
the
upstream
teams.
We
can.
B
We
can
push
comments
back
to
patch
stuff,
which
we've
done
multiple
times
already
on
on
commands
and
multiple
projects
where
we
we
find
issues
and
we
we
push,
we
have
companies
push
back
fixes.
So
I
think
it's
a
massive
improvement
of
security.
The
key
is,
of
course,
to
do
what
we
did,
which
is
that
centralized
approved
set
of
libraries
and
containers.
So
we
we
understand
the
supply
chain.
We
understand
the
bit
of
material,
the
dependencies,
the
risk
we
scan
it.
We
centrally
approve
it.
We
centrally
update
it.
B
We
work
with
80
plus
companies
to
push
us
updates
also
of
their
cuts,
all
their
costs.
Now
that's
a
new
thing
right:
commercial,
open
source
software
that
you
know,
companies
like
confluent
or
elastic
right-
that
that
brings
us
a
supported
version
of
the
open
source
software
and
they
push
these
updates
directly
to
my
repo
automatically
centrally,
I
mandate
that
it's
automated
there
is
no
human.
We
have
you
know,
signing
and
integrity
checks
and
making
sure
that
the
code
wasn't
tempered.
We
scan
it.
B
C
C
B
A
A
B
Yeah,
I
mean
look,
I
think
once
you
once
you
move
to
to
micro
services
and
containers.
You're
gonna
have
that
east
and
west
traffic
management-
that's
completely
different
from
your
north
and
south
traffic
right,
and
so
you
know,
ingress
is
gonna
help
you
with
that,
and
in
fact
you
can
use
the
ingress
for
foreign
and
have
that
northwest
north-south
traffic
from
cubase.
B
But
you're
gonna
need
something
to
manage
your
east
and
west
traffic,
particularly
to
make
sure
lateral
movement
is
limited
right,
so
you
don't
want
a
bad
actor,
having
access
to
one
continuous
and
be
able
to
talk
to
all
of
the
containers
and
just
literally
move
to
your
current
rules.
So
we
we
whitelist
right
traffic
between
containers
down
to
the
container
level
and
that's
how
we
enforce
your
trust.
That's
why
you
need
a
service,
but
service
mesh
also
brings
you
so
many
more
features.
B
Right
I
mean
we
can
talk
about
even
chaos,
engineering
with
fault
injection.
You
can
talk
about.
You
know
modern
rotting.
With
a
b
testing
can
re-release.
You
know
all
that
kind
of
stuff,
all
the
layer,
seven
load
balancing
you
know
dynamic
rotting,
I
mean
it's.
I
mean
you
know
that
better
than
that.
A
B
Right,
yeah,
there's
the
medium
features
that
and
the
key
right
is
so
people
don't
understand
why,
but,
but
that,
if
you
don't
do
that,
if
you
don't
use
a
service
mesh,
you
end
up
having
to
do
it
per
programming,
language
per
micro
service
and
now
you're
tightly
coupled
when
you
release
and
you're
gonna
have
new
things.
You're
gonna
need
to
do
for
service
discovery
and
all
the
authentication
encryption
stuff.
And
let's
say
you
need
to
update
your
encryption
bits.
B
C
B
A
B
B
C
A
Good
yeah,
no,
I
I
agree
right.
I
think
it's
a.
I
think
it's
you.
You
certainly
need
all
of
the
features
that
a
service
mesh
provides,
have
a
legitimate
distributed
system,
and
I
definitely
think
that
it
being
assembled
in
that
way
is
is
really
nice
that
makes
it
the
easiest
to
consume
that
we've
seen
so
far.
B
C
B
The
demon
you
know
was
a
big
big
lift,
but
we
found
you
know,
gaps
in
documentation.
I
think
I
think
the
documentation
is
definitely
something
that
still
has
some
issues
and
we're
pushing
also
we're
doing
stuff
that
not
many
people
do
in
an
environment
that
not
people
not
many
people
use
with
stuff.
That's
not
just
the
basic
http
stuff,
so
you
know
we're
finding
stuff.
B
Yeah
most
people
would
probably
not
care
or
think
about
if
they're
doing
some
type
of
web
app.
So
that's
what
it
is,
but
everything
we
do.
We
push
it
back
to
the
community,
so
we're
not
forking
we're
not
making
dod
custom
changes.
So
that's
the
good
news
is.
We
are
giving
as
much
back
as
we're
taking
from
the
community.
A
Yeah-
and
I
could
say
from
like
the
seo
side-
that's
been,
one
of
the
really
cool
things
to
see
right
is
is
having
folks
from
one
platform,
come
and
approach
the
community
and
say
hey:
how
can
we
help?
How
can
we
start
to
contribute
back
meaningfully
and
at
all,
which
has
been
really
excellent,
to
see,
excellent
and
and
so
yeah
and
then,
as
far
as
specific
optimizations
and
tweaks?
So
I
I
think
I
can
maybe
answer
this
one
so
far
enough.
There.
C
C
A
B
It's
not
just
at
the
edge,
I
think,
the
biggest
complexity,
and
why
I've
been
getting
a
lot
at
a
lot
of
the
communist
distros
who,
by
the
way,
are
putting
the
entire
community
at
rest
by
creating
very
highly
opinionated
communities.
Distributions,
literally
defeating
the
point
of
communities
being
modular
and
flexible
by
you,
know,
mandating
that
every
little
piece
is
exactly
what
they
want
you
to
use
between
the
cni
and
the
cri
and
and
the
the
container
registry.
And
oh,
you
want
to
use
harbor
no
way.
You
know
you
need
to
use
this.
B
Instead,
that's
the
opposite
of
what
the
the
committees
wanted
right,
and
so
these
distributions
are
really
becoming
a
real
problem
and
I'm
grateful
that
some
companies
are
at
least
trying
to
bring
options
and
be
more
flexible
than
some
others,
but
the
one
side.
If
it's
all
it's
just
not
gonna
work.
B
So
that's
that's
been
a
problem,
but
I
guess
the
the
the
big
the
big
issue
with
the
edge
is
also
the
the
fact
that
most
of
these
companies
are
focused
on
commercial
clouds
and
they're,
not
thinking
a
gap,
so
we
waited
a
year
to
get
openshift
or
vmware.
You
know
working
on
air
gaps
from
the
last
releases
a
year.
It's
a
lifetime,
that's
a
lifetime.
B
To
you
know
we
moved
to
renter
and
and
convoy
from
day
to
iq.
Who
was
able
they
were
able
to
do
it
in
days
because
they
did
not
come
with
all
that.
Opinionated
stack
on
top
to
orchestrate
the
stack
and
stand
up
the
stack
and
they
were
able
to
do
it
in
a
completely
gapped.
You
know
fashion
and
look.
Everybody
is
now
catching
up
and
and
bring
it
to
us,
including
vmware
and
red
air
gapped
version,
but
but
it's
it's
taking
way
too
long.
B
So
that's
been
one
of
the
big
issue
for
us
at
the
edge,
so
edge
could
be
either
completely
a
gap
or
could
be
an
intermittent
rate.
So
you
don't
have
the
best
connectivity,
obviously,
when
you're
flying
or
not
doing
on
a
submarine.
So
we
have
to
have
different
means
of
communication,
but
we
have
to
bring
everything
with
us,
including
the
master.
B
So
it's
not
just
a
bunch
of
edge
devices
that
talk
to
a
master
control
plane
on
the
cloud.
Everything
has
to
be
on
the
system,
so
looking
at
very
lightweight,
so
some
of
the
issues
is
how
heavy
you
know
and
complex
cubes
is
so
we
looked
at
k3s,
but
even
with
we
did
it.
You
know
we
use
the
four
key
maze
at
the
edge
on
jets
to
not
just
the
k3s
distro.
So.
C
B
B
A
A
B
B
To
it,
that's
a
real
one,
but
not
always
it's
at
that
layer,
but
usually
at
least
no
intent.
You
have
to
assume
no
internet,
so
you
can
start
pulling
stuff,
which
is
always
a
big
issue
right.
We
ask
all
our
containers
to
stop
pulling
stuff
left
and
right
and
people
do
a
terrible
job
at
knowing
the
dependencies.
I
can
tell
you
that
that's
even.
B
They're
just
pulling
so
much
stuff
left
and
right
and
they
don't
even
know
where
it's
coming
from.
You
know
it's
dependencies
or
dependencies
that
they
inherit.
But
when
you
give
me
a
container,
are
you
in
charge
of
giving
me
all
of
the
dependencies
updated
and
you're
responsible
for
everything
you
bring
with
that
container?
So
that's
part
of
the
job.
A
Yeah,
this
may
be
actually
my
favorite
question.
That's
been
asked
so
far,
which
is
so.
What
do
you
think-
and
this
is
more
for
you
personally
rather
than
the
the
joint
program,
but
what
do
you
think
is
the
primary
reason
for
your
success
right.
So
this
as
this
question
states,
yeah
dod
is
a
huge
org
with
a
lot
of
inertia
right
and
you've
been
able
to
enact
some
fairly
radical
changes.
So
why?
Why
do
you
think
you've
been
successful?
B
B
B
B
So
I
think
that's
been
great
to
see
having
everybody
that
a
community
of
practice
come
together
and
we
have
1400
people
on
that
engagement.
That's
pretty
incredible!
You
know
leadership,
people,
that's
not
just
mr
anybody
right.
It's
it's
a
lot
of
very
senior
people
in
the
in
the
dod.
That's
pretty
amazing.
A
C
A
B
Yeah,
look
at
that's
another
benefit
of
each
jio,
supporting
some
vm
capable
and
still
bringing.
I
guess,
the
mesh
extending
the
mesh
I
guess
to
outside
of
kubernetes,
but
we
don't
do
much
of
that.
We,
we
use
a
zero
trust,
stack
for
the
rest
with
that
gate,
which
does
a
lot
of
the
same
benefits
for
vms
that
we
get
from
istio,
although
there's
no
decoupling
a
lot
of
other
stuff,
but
it
does
the
same
cyber
benefits
the
legacy
stuff.
B
There's
not
an
easy
answer
right,
it's
a
case
by
case
you
have
to
you
know.
So
what
we
end
up
doing
is
we
strangle?
We
strangle
it
right.
We
strangle,
we
use
a
strangler
pattern.
We
have
a
whole
training
on
the
website.
If
you
go
on
software,
they
have
that
mail
you're
going
to
see
a
lot
of
good
stuff.
B
There,
there's
a
training
section
with
a
lot
of
good
content,
but
the
strangle
pattern
is
what
we
end
up
doing
to
strangle
the
the
the
legacy
and
move
it
to
containers
and
savvy
smash
and,
by
definition,
is
going
to
move.
Not
everything
can
be
done
and
it's
going
to
take
time.
It's
made
of
time
and
we
mitigate
the
cyber
risk
ready
at
first
and
we
try
not
to
touch
the
legacy
and
update
the
legacy
and
bring
the
new
stuff
as
new
code.
B
So
you
don't
keep
padding
on
your
debt
and
adding
on
top
of
that,
and
you
already
stopped
the
bleeding
and
that's
really
something
that
you
have
to
stick
to.
If
you
start
cheating
the
system
and
start
adding
stuff
to
the
legacy
other
than
just
basic
updating
and
patching
of
cyber
issues,
then
you're
going
to
just
compound
your
problems.
So
really
sticking
to
the
strangler
pattern
is
the
only
way
to
modernize
I.t
anyway.
So
that's
what
I
will
say
for
that.
A
Yep
yeah
we've
seen
exactly
the
same
thing
right
with
some
of
the
other
folks
that
we've
worked
with
all
right.
So
I'll.
Ask
this
one
last
one
I
think,
probably
that
we'll
get
to
and
you
can
pitch
so
for
for
folks
who
are
already
working
with
the
dod
for
dod
contractors.
How
can
they
start
to
get
involved
with
with
the
dsop
or
with
the
joint
program?
Yeah.
B
B
Products
or
services,
so
if
you
have,
let's
say:
let's
start
with
products,
if
you
have
products,
push
it
to
the
iron
bank
and
the
the
software
that
I
have
that
meal
slash
these
substance
documents
as
the
the
container
onboarding
guide.
So
you
can
follow
that
and
get
your
container
approved
for
dod
use
once
you
approve,
we
can
buy
it
right,
so
some
companies
do
it
in
two
weeks,
some
take
a
month,
but
it's
pretty
quick.
It's
it's
not
very
hard.
B
If
you
already
have
continuous
it's
a
matter
of
days
to
do
it,
and
then
you
approved
ud-wide
all
the
way
to
the
highest
classification
levels
and
you
can
be
used
anywhere
now.
You
can
sell
your
licenses
and
we
have
contract
vehicle
to
put
you
and
we
can
introduce
you
to
companies
that
can
be
your
reseller.
Many
companies
don't
want
to
be
dealing
with
duty
contracts
and
they
usually
settle,
say
there's
a
bunch
of
them.
B
We
have
them
on
contracts,
so
just
reach
out
to
us
and
I'll
put
I'll
put
the
the
email
of
my
office.
So
you
can
directly
reach
out
and
ask
questions
if
you
want
to
be
introduced
to
some
of
these
resetters
there's
multiple
options,
but
there's
a
few
web
on
contract.
That's
very
easy
and
they
come
on
board
you
in
days.
B
What
used
to
take
a
year
now
takes
days,
then,
if
you
just
have
services
and
you
don't
sell
products
and
you
don't
sell
licenses
and
you
just
sell
a
service-
maybe
it's
talent,
maybe
it's
people
deficit,
cops.
Engineers
started
whether
bt
engineers
expert
that
no
easter,
whatever
we
take
it.
Also.
We
need
a
lot
of
help
and
we
have
contract
vehicles
for
that.
It's
really
easier
to
become
a
sub
to
some
of
the
big
comp,
big
companies
we
have
on
contract
because
you
know
dealing
with
duty
is
a
nightmare.
So
you
pray.
B
It's
it's
a
lot
and
most
people
just
I
mean
there
is
no
benefit
for
you
to
I
mean
sure.
They're
gonna
take
a
cat
on
top
of
you,
but
you
know
that's
what
it
is
anyway.
We
do
it
all
the
time
and
and
it's
what
it
is
so
reach
out
to
us.
If
you
want
to
both
case,
if
you
have
a
product
or
if
you
have
a,
if
you
want
to
have
a
service,
if
you
have
talent,
people
that
you,
you
think
would
make
sense,
they
have
to
be
us
citizens.
B
A
B
Oh
no,
I
mean
it's.
This
is
why
we're
here
you
know
we
want
to
create
a
community
and
we
want
to
share
it
and
for
us
you
know,
like
I
said,
the
code
is
open
source.
It's
a
two-way
street.
If
you
have
good
stuff,
if
you
have
good
ideas,
if
you
have,
if
you
even
see
issues
you
know
in
our
code,
if
you
see
you
know
you're,
protecting
your
kids
you're,
protecting
your
country
by
coming
and
and
helping
us
make
it
better.
So
take
a
look
at
the
source
code.