►
From YouTube: Network Isolation For 1500 Microservices - Jack Kleeman
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Network Isolation For 1500 Microservices - Jack Kleeman
Network policies can be difficult to manage at scale while maintaining granular controls, and migrating an existing cluster is particularly challenging. In this presentation, Jack Kleeman will explain the problems that his team solved to be able to write, maintain, test, and enforce network policies for an existing self-managed Kubernetes cluster with 1500 highly connected Go microservices.
https://sched.co/ZekU
A
A
So
I'm
talking
about
some
work
that
I
actually
did
at
my
last
company,
which
is
a
large
banking
startup
in
the
uk
and
I'm
just
going
to
try
and
refer
to
them
by
the
word
bank.
From
now
on,
so
this
company
they
were
cloud
native
from
pretty
much
straight
away
very
early
in
the
container
wars
and
they
actually
are
now
running
a
kubernetes
cluster
that
is
about
four
years
old,
which
I
think
is
pretty
mad.
A
You
know
one
continuous
cost
of
that
entire
time,
even
persisted
across
the
cni
migration,
which
is
pretty
cool
and
they're
running
1500
micro
services
that
are
almost
all
written
in
go.
So
it's
a
very
homogenous
platform
which
made
my
life
a
lot
easier
and
I
work
primarily
on
security,
but
also
a
lot
of
core
platform
stuff.
A
So
it's
self-hosted
kubernetes
running
on
aws.
So
by
self-hosted
I
mean
that
we
are
doing
all
of
the
management
of
it.
We're
using
ec2
didn't
use,
cube
admin,
we
didn't
use
any
of
the
distributions
and
we
didn't
use
any
managed
services
because
essentially
the
platform
predated
a
lot
of
that
stuff.
We
also
had
a
homegrown
envoy
sidecar
service
mesh.
In
the
early
days,
we
were
using
linkedin
as
a
demonstration.
A
We
ended
up
using
envoy
as
a
demon
set
and
then
eventually
went
to
envoy
containers
in
every
single
pod,
and
that
was
really
awesome
and
we
ran
our
own
control
plane
for
that
and
for
networking
we
basically
were
using
calico
at
the
cni
which
worked
fine.
We
didn't
do
anything
too
magical
with
that,
so
you
might
have
seen
this
picture
before
I
tweeted
it
a
few
months
ago
and
it
got
a
lot
of
attention.
What
is
this
picture
of
well?
This
is
actually
what
a
bank
looks
like.
A
The
dots
are
services,
basically
microservices
and
the
lines
are
enforced.
Networking
rules
between
those
services,
so,
if
you're
interested
in
network
isolation,
this
is
a
pretty
good
case
study
for
how
that
can
look
like
a
scale
but
it
I
know
it
looks
really
really
chaotic
and
that's
partly
just
because
this
isn't
really
a
good
representation
of
anything
meaningful.
It's
just
a
fun
diagram
that
I
like
to
show
people,
I
guess,
and
with
good
tools
we
create
ordering
the
chaos
right.
A
So
while
this
might
look
really
complex,
this
isn't
necessarily
something
that
needs
to
be
in
anyone's
brain.
Unfortunately,
it's
not
in
my
brain-
and
I'm
not
here
to
justify
the
whole
concept
of
our
micro
service
is
good.
Is
this
too
many?
What
I
will
say
is
banks
are
complicated
and
computers
are
fast,
so
by
banks
are
complicated.
I
mean
you're,
not
just
looking
at
a
database
that
describes
the
bank
balance
of
everyone's
account
you're.
A
Also
looking
at
employee
management
system
you're,
also
looking
at
a
lending
decisioning
system,
you're,
looking
at
a
full
support,
chat
system
that
we
built
completely
ourselves
and
we
weren't
using
a
lot
of
third
parties
and
stuff
like
that
you're
seeing
a
diagram
that
has
a
lot
of
different
stuff
and
they're
tightly
interlinked,
which
is
actually
powerful
and
by
computers,
are
fast.
I
mean
the
latency
is
still
fine.
It's
acceptable,
especially
for
a
banking
product.
A
People
don't
expect
to
get
their
balance
in
five
milliseconds
we're
not
a
high
frequency
trading
company,
but
instead
people
expect
us
to
build
features
really
really
quickly
and
feature.
Velocity
is
really
important
and
an
architecture
like
this
actually
allows
us
to
deploy
hundreds
of
times
a
day
to
never
bump
into
other
people's
code,
and
I
think
that
was
really
awesome.
A
So
so
I
think
this
worked
great
for
us,
so
yeah
the
lines
are
network
rules
and
then
four-speed
network
policies,
just
standard
kubernetes
network
policies
and
obviously
the
dots
are
services
and
managing
these
rules
is
actually
really
easy.
Surprisingly
easy
and
that's
kind
of
what
I'm
here
to
talk
about
is
how
do
we
design
a
system
that
manages
rules
like
this
so
that
it's
safe
but
also
doesn't
require
that
toil?
A
A
A
So
the
problem
with
this
is
that
most
of
our
compete
was
actually
in
the
same
name
space.
We
didn't
have
team
name,
space
separation
for
various
reasons,
so
it
doesn't
really
give
a
lot
of
security
value.
This
was
kind
of
a
test
run,
and
this
isn't
just
a
security
problem.
It's
also
a
monitoring
problem.
A
You
don't
actually
know
what
connections
are
happening
internally,
you're
not
able
to
secure
it,
because
you
don't
know
what
they
are
and,
as
you
saw
in
the
diagram
before
it's
clearly
complex,
it's
clearly
something
that's
going
to
be
difficult
to
determine
accurately,
but
from
a
security
and
regulation
perspective.
The
primary
problem
is:
there's
a
lot
of
services
that
can
move
money.
A
You
know
we're
a
bank
there's
a
lot
of
different
ways
that
money
can
be
moved
and
lots
of
services
could
talk
to
those
services,
even
though
they're
not
supposed
to,
and
that's
a
huge
concern
for
us
as
a
security
team.
It's
also
a
huge
primary
concern
for
regulators.
You
know
you
want
to
be
showing
some
isolation
between
things
that
handle
employee
management
and
things
that
handle
money
interviews.
A
So
that
was
a
big
concern
and
solving
it
was
kind
of
the
top
priority
at
the
time
and
instead
of
just
identifying
a
list
of
services
that
needed
high
security,
that's
a
list
that
becomes
stale,
we
kind
of
wanted
to
think.
What's
the
security
that
we
want
to
attain?
What's
the
strict
controls
that
we
want
and
then
can
we
make
it?
Generic
and
automatic
and
manageable
enough
that
we
can
just
apply
to
all
services.
You
know
why.
Why
only
have
a
few
high
security
services?
A
So
we
started
to
think
about
how
this
might
look
like
by
doing
a
single,
really
strict
network
policy
and
that
applied
to
our
banking
ledger,
which
is
kind
of
the
core
description
of
all
transactions
that
fundamentally
occurred
across
the
whole
business.
So
that's
a
really
important
service
and
it's
the
kind
of
service
that
can
literally
invent
money
out
of
min
air
by
out
of
thin
air.
A
If
you
can
get
it
wrong,
so
we
obviously
wanted
to
restrict
that
as
much
as
possible
and
it
actually
worked
fine,
it's
rolled
out
safely
and
it
worked
fine
for
a
long
time.
But
we
didn't
have
any
illusions
that
we
could
scale
this
to
another
thousand
services.
First
of
all,
one
of
the
problems
is
that
the
owning
team
has
to
review
every
new
client.
A
So
this
is
another
policy
that
literally
has
a
list
of
every
label
of
the
services
that
I'll
have
to
call
it,
and
that
list
lives
with
the
other
manifests
for
the
service,
which
means
it's
owned
by
the
owning
team,
and
they
have
to
review
everything
and
they
actually
wanted
to
better
review
everything.
So
this
was
helpful,
but
most
of
the
time
teams
don't
care
about
new
callers,
their
services.
You
know
they
would
be
spending
a
lot
of
time
reviewing
that
in
some
cases.
So
that's
that's
not
very
helpful.
A
In
all
cases,
we're
not
to
be
optional.
Another
problem
is
that
this
policy
also
has
to
allow
things
like
prometheus
and
upstreams
that
have
to
call
everything
and
that's
not.
Today
we
want
to
duplicate
everywhere
and
also
we
were
just
maintaining
this
manually.
We
had
some
pretty
basic
static
analysis
to
remind
engineers
to
update
it,
but,
like
fundamentally,
this
was
a
pretty
scary
manual
operation.
A
We
needed
to
move
to
a
declarative
model
for
rules,
by
which
I
mean
the
fact
that
a
service
calls
the
ledger
is
not
really
a
property
of
the
ledger.
It's
a
property
of
the
of
the
calling
service.
We
want
to
identify
that
securely
and
we
want
to
be
able
to
review
it
in
some
cases,
but
it
still
should
live
with
the
calling
service
in
the
monavie
code,
and
if
you
maintain
it
as
a
property
of
the
ledger,
you
lead
to
all
kinds
of
educations,
the
primary
one
being
rollbacks.
A
So
if
you
roll
back
the
ledger
to
before
one
of
the
clients
is
allowed
to
access
it,
but
you
don't
roll
back
the
client,
you
have
an
instant
and
that's
very
scary,
and
that
didn't
even
happen.
So
it
makes
this
very,
very
difficult
to
deal
with.
We
also
just
want
to
shield
our
engineers
from
working
with
these
kinds
of
policies.
A
We
want
to
give
them
very
thin,
keyholes
with
which
to
interact
with
kubernetes,
not
writing
arbitrary
policy
ammo
files.
The
information
we
need
from
an
engineer
is
a
b.
We
don't
even
editing
a
manifest
to
assert
something
as
simple
as
that
and
lastly,
we
didn't
really
have
a
way
to
test
policies
like
this.
So
when
we
rolled
out
this
policy,
we
checked
it
manually
countless
different
ways,
thinking
about
every
different
way,
that's
something
we
could
call
the
ledger.
A
I
would
check
it
against
metrics
and
and
then
we
basically
just
roll
it
out
to
one
pod
and
check
the
connection
errors.
Now
those
errors
would
have
been
retried,
so
we
knew
that
was
essentially
safe,
but
we
can't
do
that
for
a
thousand
more
services
and
that
wouldn't
always
be
safe
in
all
instances.
A
So
the
first
step
towards
moving
towards
a
generic
solution
is
to
take
the
basic
static
analysis
that
we
had
built
and
make
it
really
generic
and
as
accurate
as
possible,
and
we
turned
this
into
a
tool
called
rbc
map.
Sadly,
it's
kind
of
very
specific
to
the
way
that
our
rpcs
look
like
in
our
platform,
but
I'm
sure
that
you
could
write
the
same
thing
for
grpc.
Obviously,
mac
would
scan
all
of
the
imported
packages
for
a
service
and
look
for
things
that
look
like
rpcs.
A
Second
of
all,
you
can
use
tools
like
find
and
grep
to
look
through
your
whole
code
base
and
determine
what's
allowed
what
connections
are
occurring?
That's
really
useful.
So
I
really
like
this
approach
of
using
files
just
empty
files
and
down
the
line.
We
can
even
decide
to
add
metadata
to
these
files,
so
the
files
could
actually
have
some
kind
of
text
format
inside
them.
That
would
do
things
like
allow
endpoints
and
specific
endpoints
to
be
used,
so
that
is
really
powerful.
I
really
like
it.
A
What
does
this
actually
mean
in
kubernetes
land?
Well,
we
have
a
deployment
pipeline
at
this
company
which
allows
us
to
take
the
code
in
the
monorepo
and
manifest
in
the
monorepo
package
them
up
into
a
docker
image
and
package
them
into
the
kubernetes
manifest
and
then
deploy
them
right.
So
we
decided
that
we
wanted
to
compile
these
rule
files
into
kubernetes
pod
labels,
so
something
like
service
dot
led
to
the
rule,
becomes
bank.com
egress
s
ledger
equals
true
and
having
labels
to
determine
all
the
dependencies
of
a
service
is
super
useful.
A
First
of
all,
you
can
just
list
all
pods
that
call
the
ledger.
In
kubernetes,
which
is
really
useful,
very
fun
to
do,
you
can
also
read
a
pod
label
and
determine
all
of
its
dependencies,
which
is
helpful
and
you
can
use
it
programmatically.
So,
for
example,
our
envoy
control
plane.
Instead
of
giving
you
access
or
giving
you
configuration
for
all
services
and
giving
you
a
lot
of
expensive
endpoint
updates
for
that.
Instead,
we
just
give
you
the
ones
that
the
labels
say:
you're
allowed
to
call
and
that's
a
massive
performance
optimization.
A
A
Instead
of
listing
labels
that
are
allowed
to
call
a
given
service
instead,
just
select
on
all
the
pods
that
have
a
label
saying
yep,
I
can
call
the
ledger
and
it
makes
the
policy
really
simple
and
the
other
trick
that
we
used
is
every
part
that
gets
one
of
these
network
policies
which
obviously
at
first
is
none
of
them
and
eventually
becomes
all
of
them.
We
also
give
it
a
label
just
network
policy.
A
True
and
now
we
have
a
label
for
everything
that
already
has
a
network
policy
and
that's
super
powerful,
because
the
first
little
policy
for
a
pod
is
dangerous.
It
restricts
its
inbound
traffic,
but
the
second
network
policy
for
a
pod
can
only
increase
its
traffic,
so
it's
always
safe
to
write
policies
on
things
that
already
have
policies,
that's
a
guaranteed
safe
operation,
and
that
means
we
can
write
global
policies.
So
we
can
select
on
every
pod
that
already
has
a
network
policy
and
do
things
like
allow
prometheus
and
that's
always
going
to
work.
A
The
other
advantages
is:
every
policy
is
going
to
select
on
that
label,
which
means
that
if
you
remove
the
label
you're
going
to
drop
your
port
out
of
every
policy,
it's
like
removing
all
the
policies
in
the
entire
platform,
but
just
for
that
pod
and
deleting
metal
products
in
general
is
very
dangerous,
but
deleting
this
label
is
always
safe.
This
is
really
useful
for
debugging.
A
A
A
Safely,
so
the
model
works,
the
source
of
information,
the
rule
files
is
relatively
reliable,
but
not
all
inbound
connections
look
like
rbcs,
not
all
of
them
are
even
in
the
code
base
and
even
within
the
code
base,
they're
going
to
be
exceptions
that
rpc
map
can't
determine
things
like.
If
I
build
the
service
name
programmatically
in
some
way,
something
weird
like
that
using
metrics
from
envoy
get
us
some
of
the
way
there.
But
not
everything
goes
through
envoy.
A
Our
staging
environment
gets
some
of
the
way
there,
but
not
everything's,
going
to
get
caught
in
staging.
It's
not
acceptable
to
just
hope
that
the
instance
that
these
problems
cause
won't
be
that
bad,
you
have
to
plan
for
them
and
you
have
to
explicitly
say
no
we're
going
to
catch
all
issues,
we're
going
to
prove
this
to
ourselves.
A
What
we
wanted
was
a
war
mode
and
it
would
be
awesome
if
metal
prices
have
this
kind
of
feature
by
default,
but
you
can
kind
of
hack
it
together
and
by
one
mode
I
mean
you
want
to
know
what
a
policy
would
drop
or
what
packets
would
be
getting
dropped
with
your
current
set
of
policies,
but
without
actually
being
dropped.
This
is
actually
really
easy
to
do
with
calico.
A
You
essentially
want
a
policy
that
runs
last
after
all,
other
policies
and
therefore
packets
will
only
reach
it
if
they
are
not
already
accepted
and
they're
going
to
be
dropped,
and
then,
in
that
policy
you
want
to
log
which
means
it'll
essentially
go
to
the
kernel
log,
a
full
description
of
the
packet.
That's
been
dropped
and
you
then
want
to
allow
the
traffic.
So
what
that
means
is
all
packets
will
never
be
dropped,
but
they'll
always
be
logged
if
they're
going
to
be
dropped.
A
So
we
call
that
a
dry
run
policy
and
in
calico
that's
very
easy
to
write.
We
run
this
tool
called
cube
ip
tables
taylor.
It
turns
it
runs
on
every
node,
it
tails
the
kernel
logs,
and
it
turns
these
log
lines
into
kubernetes
events.
It
turns
them
also
into
metrics,
and
that
makes
it
really
easy
to
track
what
packets
weren't
being
allowed.
A
You
can
basically
get
the
slack
message
for
every
single
packet
that
gets
dropped,
which
is
really
awesome,
but
where
this
goes
wrong
and
where
this
did
go
wrong
is,
if
you
log
a
lot
of
packets,
because
you
roll
out
a
really
bad
policy,
maybe
accidentally
I
did
do
this.
The
kernel
will
be
logging
so
much
that
you
can
essentially
take
down
networking
on
that
host.
That
is
not
a
lot
of
fun
and
it's
not
very
easy
to
debug.
We
spent
a
long
time
thinking.
This
must
be
aws's
fault.
No,
it
was
not.
A
It
was
kind
of
my
fault
in
some
sense,
so
we
started
to
think
is
logging
overkill
like
we
don't
need
a
log
line
for
every
packet.
We
kind
of
just
need
to
know
the
packets
are
being
dropped.
As
long
as
you
know
that
a
service
is
receiving
traffic
that
we
haven't
specified,
you
can
usually
figure
out
what
the
reason
is.
You
can
go
and
look
at
the
service.
What's
weird
about
the
service,
where
might
ever
be
receiving
traffic
from
that's
unusual,
the
rpc
map
wouldn't
notice,
and
you
could
almost
always
figure
it
out.
A
A
Fortunately,
this
is
possible
with
calico
as
well,
because
calico
policies
are
just
ib
tables
rules,
right
and
ibtable's
rules
have
counters
and
those
counters
can
be
scraped
using
a
prometheus
exporter
and
we
wrote
one
of
these.
It's
called
caloric
accountant,
it's
going
to
essentially
every
time
you
scrape
it.
A
So
at
that
point
you
can
turn
on
enforcement
and
the
way
you
do
that
is
you
just
take
a
dry
run
policy
which
is
currently
logging
and
allowing-
and
instead
you
just
lock
so
we're
still
getting
the
slack
messages
when
packets
are
going
to
be
dropped,
but
you
don't
actually
allow
them
anymore,
so
they
do
actually
get
dropped
and
this
was
boring
by
the
time
we
did
it.
I
mean
it
was
meant
to
be
boring
right.
It's
such
a
straightforward
change
and
it
doesn't
really
change
anything
because
it
was
affecting.
A
That's
ever
happened
because
suddenly
you're
now
in
a
scenario
where
an
attacker,
that's
somehow
in
a
pod
on
our
network,
except
for
a
few
other
pods
that
it's
supposed
to
be
allowed
to
call
if
they
do
any
kind
of
basic
internal
exploration,
you
know
send
out
some
curls
or
whatever
else
we're
going
to
get
a
slack
message
for
every
packet
that
they
send,
which
is
a
difficult
position
for
them
to
be
in.
I
suspect.
A
So
it's
about
a
year
later
now
I
don't
work
there
anymore,
but
I
have
a
good
authority
that
things
are
running
pretty
smoothly.
Engineers
maintain
their
raw
files
using
rpc
map.
Obviously,
map
usually
means
they
don't
think
about
it
very
much
and
it
gets
reviewed
in
the
pull
request
and
quite
a
few
teams
actually
ended
up,
taking
advantage
of
the
fact
that
you
can
set
code
owners
on
all
the
rules
for
a
service
and
then
review
all
new
callers.
A
A
lot
of
like
payments
teams
started
to
do
that
against
the
standard
practice
when
they're
writing
a
new
sort
of
dangerous
service,
and
that's
really
awesome,
I'm
glad
we
supported
that.
We
don't
really
see
very
many
issues
related
to
bad
rules.
Rbc
map
catches,
most
things
staging
catches,
a
lot
of
things
metrics
as
well,
and
the
system
is
incredibly
tightly
specified.
We've
got
13
000
rules
or
rule
files
in
the
monorepo.
A
A
So
what's
next
well,
having
spent
a
few
months
thinking
about
internal
network
traffic
and
network
isolation,
the
obvious
extension
to
that
is
what
about
traffic,
leaving
the
platform
and
obviously
the
first
thing
that
an
attacker
will
do.
A
lot
of
the
time
is
pull
down
a
payload
from
elsewhere
I
mean
github
or
whoever
else,
some
hosting
provider.
So
we
essentially
want
as
many
pods
as
possible
to
have
no
public
internet
access
whatsoever.
We
want
to
give
them
s3,
and
maybe
you
know
internal
s3
buckets.
A
A
We
want
to
give
them
the
websites
they
actually
need,
and
particularly
the
dns
names
that
they
actually
need
and
there's
a
few
cni's
that
can
provide
this
functionality,
and
you
can
also
do
it
with
this
j,
but
we
actually
wanted
something
that
tightly
integrated
with
our
existing
network
policy
setup.
So
we
wanted
to
use
the
same
rule
files.
Essentially
and
the
same
pod
labels
and
then
have
the
effect
of
instead
of
restricting
services,
we
restrict
to
external
services,
and
we
created
an
operator
for
this.
It's
called
equals
operator.
You
can
look
it
up.
A
Tiny
dot
cc,
slash
equals
operator
and
I
hope
to
talk
about
this
with
another
coupon
someday,
but
you
might
be
interested
in
looking
into
it.
It's
really
awesome
and
I'm
sure
that
some
people
looking
at
this
talk
or
hearing
this
talk,
will
be
thinking
and
will
want
to
ask
me
about.
You
know
why
don't
we
use
istio,
why
don't
we
use
htls
certificates,
declarative,
etc,
calico
network
isolation
is
really
the
first
step
of
a
longer-term
strategy
which
will
involve
isolation
on
a
per
endpoint
basis.
A
We
definitely
want
to
be
able
to
say
things
like
you
can
use
the
read
endpoint,
but
not
the
right
endpoint
for
this
service
and
stuff,
like
that
and
there's
loads
of
instances
where
the
security
network,
isolation
is
really
compromised
by
the
fact
that
a
service
has
dangerous,
endpoints
and
safe
endpoints.
This
hasn't
been
decided
yet,
but
we
were
thinking
pretty
closely
about
using
sto.
A
So
that's
something
that
hopefully
we
can
do
in
the
future
and
that's
everything
that
we
have
time
for
thanks
so
much
for
listening.
This
whole
talk
is
basically
adapted
from
our
blog
post
and
you
can
read
about
that
tiny
dot
cc,
network
hyphen
isolation.
You
can
also
follow
me
on
twitter
jackkleeman,
and
you
can
email
me
about
this
or
my
future
self
in
the
q.
A
I'm
sure
can
answer
any
of
your
questions
and
thanks
very
much.
That's
all
hi
everyone
thanks
for
coming.
A
I
hope
everyone
can
hear
me,
okay,
etc.
I
think
most
of
the
questions
I've
already
answered,
but
there's
one
left
and
there's
probably
some
more
that
will
come
in
while
I
answer
so
one
from
kevin
saying
one
of
my
thoughts
on
using
network
policies
for
traffic
flow
in
and
out
of
the
cluster.
So
I
touched
on
this
a
little
bit
with
the
egress
operator
that
we
worked
on.
A
I
think
we
started
to
realize
that
most
attacks
would
involve
some
kind
of
egress
or
some
kind
of
traffic
leaving
the
platform
to
reach
an
attacker's
platform
or
obviously
yeah.
If
you're
running,
like
hybrid
crowd
or
hybrid
cloud
or
on-prem,
it
might
be
reaching
other
things.
So
I
think
you
know
my
basic
stance
on
this
is
that
all
traffic
should
be
specified.
A
I
mean
in
practice
you
should
have
network
policies
for
everything
and
you
could
start
off
with
very
generic
ones
that
allow
a
lot
of
things
and
try
and
scope
them
down
over
time
and
that
should
include
yeah
things
getting
out
of
kubernetes
and
basically
try
and
have
as
much
restriction
as
possible,
even
if
it's
not
necessarily
a
security
priority.
I
think
it
is
so
valuable-
and
I
touched
on
this
a
little
bit
to
have
a
programmatically
queryable
list
of
of
things
that
are
happening
in
your
in
your
cluster.
A
That's
provably,
true,
like
you
know
that
this
set
of
policies
is
a
superset
of
the
traffic.
That's
actually
happening.
I
think
that's
amazing,
and
just
for
the
kind
of
monitoring
and
kind
of
headspace
benefit
of
that.
I
would
advise
it
even
if
security
isn't
the
top
priority,
but
yeah,
I
would
definitely
be
keen
on
using
their
policies
for
as
much
as
possible.
A
Another
question
from
gaston
when
using
sjo
the
network
policies
for
cube
system
and
other
namespaces
aren't
protected
yeah.
I
think
we
would
never
have
planned
to
exclusively
move
everything
over
to
it's
job
and
just
dump
all
this
work
that
we've
done.
I
think
we
would
see
it
as-
and
I
think
sg
to
some
extent
recommends,
like
some
usage
of
number
policies
in
some
areas.
A
Defense
in
depth
is
the
name
of
the
game
and
it's
never
acceptable
to
have
just
one
control
and
actually,
when
you're
dealing
with
regulators
in
particular,
it's
never
acceptable
to
just
have
one
control,
so
we
would
have
layered
hd.
On
top
of
this
to
add
endpoint
level,
security
and
encryption
and
more
authentication
power,
we
wouldn't
have
removed
what
we
already
have.
I
think
network
policies
like
they're
my
favorite
resource
in
the
whole
kubernetes
they're,
so
powerful,
I'm
excited
for
v2,
but
I
think
that
they
have
a
lot
of
power
already
and
yeah.
A
I
would
really
advise
that
yeah
next
question
for
ralph
have
I
thought
about
an
english
operator.
I
don't
really
know
what
that
would
look
like,
because
it's
already
possible
to
have
a
lot
of
control
over
ingress.
You
can
essentially
not
allow
pods
to
receive
traffic
on
host
network.
You
can
only
allow
it
to
happen
through,
like
certain
network
increases
to
your
cni,
and
then
you
can,
you
know,
have
api
get
ways
for
those
things.
So
that's
probably
what
I
would
recommend.
A
I
don't
know
if
it's
quite
this
same
solution,
the
same
thing
just
does
not
apply
for
egress.
Generally,
all
pods
have
total
access
to
like
the
internet,
and
that
was
the
thing
we
were
concerned
about,
but
certainly
at
this
company
it
was
not
possible
to
reach
a
pod
from
an
external
like
place.
You
would
have
to
go
through
some
kind
of
software-defined
network
ingress
and
that
had
all
the
power
that
we
needed
question
from.
A
I
don't
know
if
I'm
saying
this
right
nick,
how
did
you
create
the
diagram
in
the
beginning?
Really
simple?
Actually,
so
it's
take
the
rule
files.
You
run
find
to
get
a
list
of
them.
You
said
to
turn
the
list
of
file
names
into
dot
file
syntax.
So
you
take
the
first
part,
which
is
the
name
of
the
calling
service
and
the
last
part,
which
is
the
name
of
the
recipient
service,
and
you
put
an
arrow
in
between
them
and
that's
now
dot
syntax.
A
Now
you
have
a
dot
file
and
you
use
a
piece
of
software
called
gefi
which
turns
dot
files
into
beautiful
graphs.
And
then
you
do
some
sort
of
graph
positioning
algorithm.
That
sort
of
doesn't
work
very
well,
but
it'll
work.
Okay,
and
that's
how
you
do
it.
It's
super
easy.
So
this
is
the
awesome
thing
about
having
these
files.
A
Next
up,
how
I
thought
about
nsx
micro
segmentations,
I
don't
know
what
that
is.
So
clearly,
I
haven't
thought
about
it,
but
I
would
love
to
hear
more
if
you
can
elaborate
on
that
and
finally,
is
there
a
possibility
to
use
cubby
tables
taylor
without
switching
from
cake
network
policy
to
calico
network
policies?
So,
first
of
all,
you
don't
need
to
switch
to
calico
network
policies.
You
just
need
to
have
a
single
policy
that
logs
everything
and
then
allows
everything
that
runs
late
and
there's
not
currently
possible
to
log
using
just
kubernetes
policies.
A
If
you're
already
on
calico,
it
wouldn't
be
very
difficult
to
create
a
pr
against
calico
or
to
fork
it
specifically
against
their
calico
coupe
controllers,
which
is
a
pretty
simple
controller.
You
that
would
allow
you
to
label
a
policy
such
that
a
it
runs
last
and
b
it
logs.
That
seems
possible
to
do,
because
you
can
definitely
write
a
policy
that
allows
everything
the
things
you're
missing
are
ordering
and
logging.
You
can
trick
the
ordering
thing
with
alphabetical.
A
A
A
You
need
it
to
be
able
to
log
and
you
need
it
to
affect
all
name
spaces
or
you
can
create
a
policy
per
name
space
if
you
need
to,
or
you
can
write
a
controller
that
does
that,
for
you,
but
running
last
is
often
possible
if
you
name
the
policy
in
a
certain
way
and
logging,
that's
the
tricky
one
and
we
at
one
point
even
fought
calico
to
have
this
functionality,
but
we
decided
in
the
end
to
use
color
code.
Global
policies
from
bart
is
rpc
map
required
to
set
up
the
dot
rules.
A
Yes,
it
is
that
that
was
a
very
much
a
homegrown
thing.
It
was
passing
our
code
to
look
for
things
that
look
like
rrpcs
they're,
not
grpc,
and
they
create
rule
files
for
you.
You
would
have
to
build
something
similar,
and
if
someone
builds
that
for
grpc,
then
that
would
be
incredible,
but
I
I
don't
know
what
that
would
look
like.
It's
not
required
for
calorie
accountant,
caloric
accountant
is
incredibly
generic
tool.
It
just
looks
at
your
color
code.
Rules
turns
them
back
into
policy
names
and
tells
you
what's
going
on.