►
From YouTube: Network Security at Scale: L3 Through L7 at Splunk - Mitch Connors & Bernard Van De Walle
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Network Security at Scale: L3 Through L7 at Splunk - Mitch Connors, Aviatrix & Bernard Van De Walle, Splunk
What does it take to securely connect dozens of clusters across multiple cloud providers at Splunk scale, while not disrupting the agility that is required to compete in the modern marketplace? How do you balance security at L3 and L4 with the flexibility and identity needs of L7? Join us to explore Splunk’s networking stack, starting at multi-cloud VPCs for L3, and Istio for L4 and L7. We’ll also discuss how some of the pain points in this architecture are driving the new Istio Ambient design.
B
And
my
name
is
Mitch
Connors
I'm,
a
principal
software
engineer
at
aviatrix,
where
I
am
working
on
the
istio
project.
I've
been
a
member
of
the
istio
project
since
2018,
currently
serving
on
the
technical
oversight
committee
I'm.
Also
a
local
here
to
Seattle,
which
means
that
I
can
give
you
istio
swag
I
can
answer
any
questions
you
have
about
the
project
about
aviatrix,
where
I
work
or
I
can
give
you
really
good
restaurant
recommendations
for
the
area.
So
come
chat
with
me.
After.
A
Very
nice,
and
so
today
we
want
to
talk
to
you
about
Splunk
load
and
the
story
behind
it.
So
splint
cloud
is
basically
a
re-design
of
Splunk
to
be
Cloud
native,
so
we
wanted
to
standardize
it
on
the
kubernetes
API
and
we
wanted
to
be
Cloud
agnostic
as
much
as
possible,
and
today
we
run
both
in
AWS
and
gcp,
mainly
in
AWS.
A
We
run
in
about
35
clusters
all
over
the
world
in
all
regions
of
AWS.
Pretty
much
and
the
tech
stack
we
are
going
to
talk
about
today
is
kubernetes
istio
and
Envoy
mainly,
and
so,
if
you
look
at
the
agenda,
I
think
our
goal
today
is
to
tell
you
a
generic
story
and
go
in
detail
into
each
of
the
layers
that
you
deal
with
when
you
manage
the
network
of
such
a
cloud
deployment
and
I.
Think
it's
especially
confusing,
because
to
some
level
you
can
configure
networking
policies
on
the
cloud
provider
on
your
VPC.
A
You
can
also
configure
Network
policies
on
kubernetes
and
you
can
do
that
on
istio
as
well
right,
so
I
think.
What
we
want
to
do
today
is
to
go
into
each
of
those
layers
and
explore
what
you
can
do.
Our
goal
today
is
to
make
it
as
generic
as
possible,
so
it's
not
really
tied
to
Splunk,
even
though
it's
what
we
use.
A
A
A
And
this
brings
me
to
the
first
knob
that
you
can
use
for
security,
which
is
Network
ACLS,
so
pretty
much.
Every
cloud
provider
supports
this.
Those
are
very
low
level
crude
ACLS.
They
are
stateless,
so
they
don't
really
take
into
account
already
opened
connections
and
the
issue
is
they
get
applied
to
sublets,
which
means
you
pretty
much
need
to
allow
everything
that
any
of
your
instances
will
eventually
require,
because
you
can
only
apply
on
the
subnet
level.
A
You
cannot
specify
specific
instances,
they
give
you
very
basic
layer,
2
and
layer,
4
capabilities,
meaning
you
can
match
on
ipn
ports
both
on
the
source
and
destination
and
I,
pretty
much
see
them
as
a
kind
of
casual
Last,
Resort
set
of
rules.
The
way
we
use
them,
for
example,
is
on
the
internal
subnet.
You
never
want
to
see
anything
else
than
the
IP
IP
private
range,
like
10
8,
the
RFC
19
18
IP
range,
so
we
default
we
by
default.
We
deny
everything
except
traffic
with
those
Source
IPS.
A
A
Okay,
so
on
the
private
subnets,
we
will
deploy
node
groups,
those
are
the
kubernetes
nodes
typically,
and
we
will
group
them
into
different
functions
into
those
node
groups.
For
example,
we
got
Ingress
node
groups,
that's
where
we
want
to
deploy
our
Ingress
gateways
where
we
will
run
Envoy.
Eventually,
we'll
talk
more
about
this
later.
We
also
got
some
generic
node
groups
and
workload,
specific
node
groups,
all
of
those
get
deployed
into
a
private
IP
space.
Because
again
we
never
want
anything
outside
which,
which
you
know
directly
to
those
node
groups,
and
so
doing.
A
This
gives
you
the
ability
to
use
something
else
that
most
Cloud
providers
support,
which
is
security
groups,
so
security
groups
are
kind
of
network,
ACLS,
plus
plus,
first
of
all,
they
are
stateful.
So
the
the
support
connection
based,
you
can
also
apply
them,
for
instance,
which
means
you
can
do
more
fine-grained
things
like
this.
A
We
want,
for
example,
to
fully
isolate
the
generic
node
groups
and
only
allow
Connection
in
through
the
Ingress
node
group,
and
so
what
we
do
is
we
apply
a
very
locked
down:
Security
Group
to
the
generic
node
groups
and
a
slightly
relaxed
Security
Group
to
the
Ingress
node
groups,
and
so
this
basically
forces
anything
coming
into
the
cluster
to
transit,
to
those
English
node
groups
and
the
other
good
thing
with
security
groups.
Is
they
allow
you
to
use
a
slightly
higher
level
syntax?
You
can
use
other
security
groups
as
Source
or
destinations.
A
A
The
public
nlbs
are
obviously
made
for
public
internet
connectivity
and
we
use
internal
internal
nlbs
for
anything
that
needs
to
be
reached
from
inside
Splunk.
Those
will
be
iped
on
the
10-8
IP
space,
obviously,
and
what
they
do
is
they
basically
Target
the
Ingress
node
group
and
the
Ingress
node
group
will
run
the
envoy
gateways
that
will
terminate
connections
and
proxy
traffic
Upstream
inside
the
cluster.
B
So
for
internal
traffic
once
you've
hit
the
NLB
inside
the
internal
subnet,
you
still
need
a
way
to
get
to
another
cluster.
Another
cluster
lives
in
another
VPC.
So
for
that
they're
using
AWS
Transit
gateways,
those
are
advertising
only
the
internal
subnet
Source
IPS,
so
those
private
subnet
public
subnet
IPS,
are
not
getting
advertised
across
that
Transit
Gateway
and,
of
course,
this
transits
through
the
Splunk
firewall,
where
security
rules
can
be
applied.
B
In
addition,
there's
a
number
of
shared
services
that
every
cluster
needs
to
be
able
to
access
and
they
need
to
be
able
to
access
it
without
transiting
an
NLB.
So
for
for
these
cases,
Splunk
is
using
aviatrix
aviatrix
apply,
allows
a
flat
Network
at
layer
three,
where
all
of
the
Clusters
directly
from
their
private
subnets
can
access
those
shared
services
across
the
aviatrix
transit,
Gateway
and,
of
course,
once
you've
established
a
peering
so
that
your
pods
can
access.
B
Those
shared
services
aviatrix
by
default,
would
allow
those
pods
to
communicate
with
one
another
which
of
course,
would
bypass
all
of
the
rules
that
we've
set
up
in
our
internal
subnet.
So,
in
order
to
prevent
that,
Splunk
has
used
aviatrix's,
Network
domains,
feature
which
simply
allows
you
to
say
this.
Vpc
can
talk
to
that
VPC.
That
VPC
can
talk
to
the
other,
but
certain
vpcs
can't.
A
Okay,
so
let's
look
at
the
next
layer
which
is
kubernetes
so
first
of
all
or
kubernetes
deployment,
that's
blank.
We
treat
it
as
a
full
self-service
platform
which
means
that
teams
own
namespace
they
can.
They
can
do
whatever
they
want
with
the
kubernetes
API
they
can
provision
objects,
CRVs
or
steel,
etc,
etc.
A
One
of
the
things
we
try
to
do
obviously
is
for
the
service
teams
not
shoot
themselves
into
the
foods
I'm
going
to
show
you
a
couple
of
examples
on
how
we
do
that.
First
of
all,
one
of
the
things
we
mended
is
any
Ingress
connectivity,
both
internal
or
external
needs
to
go
to
our
nlbs
Ingress
nodes
and
Ingress
Gateway.
That's
a
way
for
us
to
apply
security
into
a
central
point.
A
A
So
one
thing
we
do:
we
use
quite
heavily
some
validating
web
hooks,
so
the
goal
of
a
validating
web
Hook
is
it's
basically,
a
callback
from
kubernetes
API.
Whenever
a
code
create,
updates
or
delete
of
a
specific
object
is
being
performed,
and
so
we
use
this
in
order
to
validate
that
users
use
those
objects
correctly.
A
typical
example
is
for
a
service
of
type
load.
Balancer
You
by
default
kubernetes
will
create
an
NLB.
If
you
use
a
service
of
title
balancer,
we
absolutely
want
to
block
this
right.
A
Since
again,
we
want
to
force
traffic
to
go
to
our
NLB
and
Ingress
nodes,
and
so
we
use
those
validating
my
books,
that's
just
one
example.
In
order
to
enforce
those
things-
and
there
are
plenty
of
open
implementations
of
those
validating,
workbooks
Opa
is
one
example:
I
used
to
use
cable
at
Cruz,
which
is
a
good
open
source
alternative.
In
this
case,
we
we
create
our
own
ones,
but
they're
pretty
easy
to
implement
okay.
A
They
allow
you
to
use
the
kubernetes
syntax,
which
means
you
can
use
labels
in
order
to
select
pods
so
that
you
don't
have
to
explicitly
Define
the
eyepiece
of
each
pod.
You
want
to
match
on
those
are
by
default,
implemented
by
your
cni
plugin,
something
like
cilium
or
Calico,
and
a
typical
example
is
something
like
this
right
in
which
you
have
a
two-tier
application,
and
you
want
the
back
end
to
be
able
to
be
reached
from
inside
its
own
namespace.
B
All
right
so
far,
we've
talked
about
from
VPC
level
layer,
three
up
to
kubernetes
policy,
how
security
is
applied
at
each
of
these
layers
to
scale
up
to
the
level
that
Splunk
requires.
Now
we're
going
to
look
at
layer
seven
and
for
that
it
Splunk
is
using
the
istio
project
if
you're
unfamiliar
with
istio.
It's
a
service.
Mesh
and
lots
of
people
have
attempted
to
explain
what
a
service
mesh
is.
It
can
all
seem
very
confusing
and
hype
at
a
fundamental
layer.
This
allows
application
near
application
layer,
networking
abstractions
over
your
network.
B
So
if
you
want
to
talk
about
your
network,
not
in
terms
of
this
IP
and
Port
can
talk
to
that
IP
and
Port,
but
instead
in
terms
of
this
service,
identity
can
talk
to
that
service
identity.
You
want
a
service
mesh
if
you
want
something
that
can
globally
collect
Telemetry
and
say
something
along
the
lines
of
HTTP
requests
with
this
path,
and
this
verb
are
succeeding.
This
percent
of
the
time
you
want
application
layer,
networking
abstractions,
you
want
a
service
mesh.
B
You
can
also
play
with
routing
a
little
bit
and
say:
perhaps
our
premium
tier
users
are
routed
to
a
subset
of
this
service,
which
we
know
to
run
on
a
little
bit
better
hardware
and
be
a
little
bit
faster.
That's
what
istio
does
we're
going
to
talk
a
little
bit
about
how
istio
does
this
and
then
we're
going
to
look
at
how
Splunk
is
leveraging
istio?
Well,
all
of
the
magic
of
istio
comes
from
Envoy.
We
insert
an
Envoy
sidecar
into
every
single
application
pod,
which
means
that
this
diagram
isn't
quite
correct.
B
If
we
were
to
correct
it,
it
would
probably
look
a
little
bit
more
like
this
there's
a
lot
of
application
pods
in
your
average
service
mesh,
which
means
there's
a
lot
of
envoy
sidecars
we're
running
Envoy
everywhere,
but
the
advantage
is
that
means
that
we
have
control
over
all
of
the
network
traffic.
We
can
collect
Telemetry
over
all
of
the
networking
traffic,
and
so
the
trade-offs
in
splunk's
case
have
been
worthwhile.
B
One
of
the
key
things
that
istio
offers
for
Splunk
is
in
transit
encryption
without
any
need
to
modify
applications.
So
the
applications
are
sending
plain
text
to
http.
As
far
as
they
know,
the
envoy
sidecar
will
intercept
and
apply
Mutual
TLS
to
that
traffic
so
that
it
may
not
be
intercepted
or
modified
in
transit.
B
You
can
run
istio
in
strict
mode,
which
requires
that
mtls
apply
to
all
traffic.
Occasionally
you'll
run
into
some
hiccups
there,
so
Splunk
runs
in
permissive
mode,
which
means
it
will
attempt
to
use
mtls
and
fail
back
to
plain
text
if
necessary,
and
then
they
have
this
fancy
alert
setup
that
lets
them
know.
When
there's
traffic
that's
happening
in
plain
text
so
that
they
can
alert
their
security
team
rather
than
blocking
it
proactively.
They'd
rather
have
developers
respond
to
that
plain
text
and
correct
the
problem.
A
Yep
so
I
think
one
interesting
thing
to
talk
about
is
the
way
we
provision
gateways
in
our
English
story,
because
this
is
going
to
be
the
the
Ingress
point
for
anything
into
the
cluster
right.
So,
as
we
said
before,
we
want
anything
that
comes
in
to
go
to
nlbs,
because
that
allows
us
to
nlbs
and
Ingress
gateways,
because
then
we
can
apply
a
new
uniform
security
policy
to
it.
A
What
we
do
is
we
deploy
basically
nlbs
and
gateways
together,
so
the
gateways
will
be
Envoy
running
on
Ingress
nodes
based
on
the
source
of
the
traffic
you
want
to
ingest,
for
example,
if
you
want
a
public
traffic,
you
obviously
will
deploy
your
NLB
on
the
public
subnets
for
the
internal
traffic.
Your
NLB
needs
to
be
on
the
internal
subnets.
What
we
also
do,
obviously,
for
security
reasons
and
blast
radius
reasons
is
sometimes
we
deploy
nlbn
gateways
for
very
critical
applications.
A
A
Those
gateways
are
managed
by
us
as
a
platform
team.
We
run
them
into
the
istio
gateway
namespace
and
it's
basically
a
capability
that
we
offer
to
everyone
into
the
the
cluster
they
can
basically
plug
into
it
and
the
way
we
do
this
is
what
we
use
this
steel.
We
set
up
Gateway,
so
istio
is
going
to
program
Envoy
as
a
Gateway,
and
we
set
up
those
gateways
through
the
istiocrds
like
Gateway
crb,
so
Gateway
crd
will
basically
Define,
which
hostname
and
which
Port
you
expect
traffic
on.
A
We
also
provisioned
those
Gateway
service
with
certificates
so
that
we
enforce
TLS
by
default
right
and
then
we
allow
our
users
into
the
into
the
cluster
to
plug
into
those
gateways.
Again,
this
is
gated
to
a
validating
workbook,
so
that
not
any
namespace
can
connect
on
any
hostname.
They
need
to
be
pre-validated
in
some
ways.
Again
we
want
everything
to
be
self-service
except
the
critical
Parts,
like
the
those
hostname
and
ports
open
to
internet.
A
And
so
we
quickly
realized
something
which
is
that
users
had
to
to
create
and
provision
a
lot
of
crds
and
objects
on
kubernetes,
and
this
was
leading
us
to
see
a
lot
of
mini
security
incidents.
I
will
say
in
which
people
will
configure
things
wrongly.
So
we've
moved
forward
by
creating
a
service
abstraction
layer
which
is
essentially
a
controller
which
will
attempt
to
configure
everything
for
you
all
those
complex
objects.
A
The
way
we
did
it
is
we
allowed
teams
to
provision
an
open,
API
stack,
and
this
controller
is
going
to
scrape
that
spec
and
create
the
virtual
Services
destination
rules.
Gateway
all
the
kubernetes
objects
you
require
to
get
end-to-end
networking
connectivity,
it
will
also
manage
certificates,
so
generate
a
certificate
for
your
hostname
if
it's
allowed
and
setup
DNS
that
goes
directly
to
the
right
NLB.
So
this
is
pretty
much
first,
one
click
deploy
solution
for
the
network
end-to-end.
A
Okay,
something
else
I
would
like
to
talk
about
is
some
level
of
layer
7
authentication.
So
we
wanted
to
provide
inner
clusters
a
standard
way
to
do
hotel
so
authentication.
We
do
this
by
leveraging
a
spec
from
Envoy
called
x2z,
so
x,
dot
Z
is
defined
by
the
envoy
project.
So
we
do
this
outside
this
year.
It's
basically
a
way
to
get
a
sync
call.
A
So
what
we
did
is
we
developed
a
bunch
of
x2d
proxies
that
we
that
act
as
the
next
to
this
server
and
those
will
allow
a
bunch
of
plugins
to
plug
in,
and
so
we
develop
those
plugins
based
on
what
alternants
need.
For
example,
we
have
an
authentication
plugin
which
will
validate
in
some
cases
your
better
token
for
HTTP.
We
got
some
JWT
talk
plugins
and
we
got
things
like
Kota
plugins,
which
will
make
sure
that
a
specific
tunnel
doesn't
issue
more
than
a
specific
amount
of
RPS.
A
The
good
thing
is
this
is
enforced
on
the
Gateway
before
going
into
the
cluster.
Our
goal
is
to
basically
develop
any
bogus
request
because
before
they
get
Upstream
further
into
the
cluster,
I
mean
I
highly
recommend
XT.
It
was
a
super
easy
protocol
to
implement
the
workloads
Upstream
into
the
bud,
still
need
to
re-verify
the
identity,
though
this
is
just
a
way
for
us
to
stop
large-scale
ddoses
in
some
ways
or
to
block
anything
that
should
not
get
into
the
cluster.
A
Other
things
we
use
istio
4
is:
we
also
use
some
level
of
network
policies,
some
alloy
lists.
Once
you
reach
the
istio
level,
you
can
basically
start
mixing
and
matching
layer,
4
and
layer,
7
Concepts,
and
we
do
this.
Quite
often
it's
not
super
clean,
but
it
allows
us
to
do
things
like
defining
us,
a
bunch
of
source
IPS
that
should
be
able
to
go
to
specific
paths
and
host
names
for
a
service,
for
example,
so
the
higher
level
you
go
into
the
stack,
the
more
Concepts
you
can
use
to
provide
those
Network
policies.
A
A
So
if
we,
if
we
take
a
step
back,
any
policies
applied
on
the
VPC
and
kubernetes
level
are
applied
for
connections.
Any
policies
on
istio
are
applied
per
requests
pretty
much
so
your
client,
when
they
send
us
a
request,
they
first
open
a
connection
to
our
NLB.
The
NLB
will
layer
three
proxies
to
one
of
our
Ingress
nodes.
This
will
end
up
into
our
Envoy
Gateway
that
will
terminate
TLS
and
then
we'll
inspect
the
request
on
a
layer
7..
A
A
B
All
right,
so
that
was
a
lot
of
layers
of
security
and,
as
you
can
imagine
not
all
of
it
is
as
wonderful
as
one
might
expect.
Let's
talk
about
a
couple
of
particular
pain
points
in
this
security
stack
and
what
we're
doing
to
resolve
them
that
slide
that
we
had
earlier
with,
like
a
million
Envoy
instances
on
it,
it
looked
bad
and
that's
on
purpose
running
one
proxy
per
instance
of
your
application.
You're
going
to
run
into
scalability
problems
for
one
compute
cost
is
very
substantial
for
that
many
proxies
for
two.
B
B
Obviously,
we
need
to
capture
all
traffic,
but
there
may
be
more
efficient
ways
and
we'll
look
at
that
in
a
little
bit
that
we
can
capture
all
of
the
track
traffic
across
envoys
there's
also
a
lot
of
magic
involved
in
istio.
Today,
I've
pulled
this
quote
from
the
istio.io
documentation
site
and
this
last
sentence
here.
Any
new
pods
that
are
created
in
that
namespace
will
automatically
have
a
sidecar
added
to
them.
It's
magic.
It's
really
cool.
What
about
the
old
pods?
B
Okay?
Well,
we
don't
do
anything
to
those
those
pods
are
immutable.
We
can't
do
anything
to
those
pods,
so
you've
got
to
go
through
every
time.
You
change
something
about.
What's
going
to
get
injected
in
a
pod
or
a
namespace,
you've
got
to
go
through
and
restart
that
workload.
Don't
miss
a
workload
you
might
be
rolling
out.
A
critical
vulnerability
fix
that
you're
going
to
rely
on,
and
if
you
forget,
to
restart
your
workload,
your
istio
upgrade
will
have
succeeded.
B
Everything
looks
good
and
you're
still
100
vulnerable
on
The
Wire,
so
we
we
think
we
could
do
better.
Also
just
answering
the
question
which
Envoy
am
I
running
where
can
be
challenging,
so
the
istio
project
is
aware
of
these
challenges
and
we
believe
that
we
have
a
solution
for
them.
We
are
developing
ambient
mode
for
istio
where
all
of
our
layer,
4
technology,
all
of
that
mtls
magic
that
we
talked
about,
will
happen
in
a
Daemon
set
that
runs
on
every
node
and
serves
every
pod
on
the
Node.
B
So
no
more
sidecar
all
of
the
traffic
capture
happens
outside
of
the
application
pod.
That
Z
tunnel
should
do
very
little.
Only
layer,
4
functionality,
which
means
it
should
be
much
less
susceptible
to
cves
much
less
susceptible
to
upgrade.
Breakages
Etc
should
be
safer
to
run.
Then,
if
you
want
layer,
7
magic
as
well,
you
can
still
run
an
Envoy,
but
it
won't
run
as
a
sidecar
it'll
run
as
its
own
deployment
in
the
namespace.
B
The
Z
tunnel
will
take
care
of
redirecting
traffic
from
whatever
application
needs
it
into
the
envoy
side
car,
where
we
can
apply
all
of
the
L7
magic
that
you've
come
to
know
and
love
from
istio,
but
not
one
per
instance.
You
can
scale
that
Envoy
installation,
independently
of
the
application
scale
you
can
adjust
its
resource
utilization
or
allocation.
B
B
All
right,
so,
let's,
let's
look
in
the
rear
view
mirror.
This
was
a
lot
of
information
to
cover,
in
a
pretty
short
time,
we're
doing
good
on
time,
at
every
single
layer
of
the
network,
from
the
cloud
provider
and
VPC
level
and
layer,
three
to
the
kubernetes
policy
to
istio
at
layer,
seven,
we
have
to
solve
for
identity
policy
and
observability.
Now
this
looks
redundant
right.
We've
already
done
identity
at
layer
three.
Why
are
we
doing
it
again
at
layer,
four
and
then
again
at
layer?
Seven,
that's
computationally,
expensive.
B
A
It
from
there
yeah
I,
mean
I.
Think
one
of
the
key
things
is
that
we
learned
over
time
is
defense
in
depth.
So
what
we
want
to
do
is
if
we
speed
up
on
things
you
can
color
in
each
layers.
The
best
way
is
to
close
them
down
each
the
most
you
can
and
to
make
sense,
so
that
you
have
that
swiss
cheese
model
right
in
which,
if
by
mistake,
one
secret
incident
happened
at
one
layer.
Hopefully
the
next
layer
is
going
to
catch
it.
A
The
things
we
learn
as
well
is
that
self-service
platforms
are
really
hard,
so
the
best
thing
you
can
do
is
to
put
safeguards
in
place
to
avoid
your
users
doing
stupid
things.
Most
of
the
security
incidents
we've
seen
is
basically
users
misconfiguring
things
so
over
time.
What
we
try
to
do
is
to
block
those
things
one
by
one.
A
Finally,
I
will
close
by
saying
that,
for
us,
observability
was
key.
That's
how
we
detect
secret
incidents
with
a
bunch
of
alerts
we
get
paid
if
any
public
traffic
is
discovered
in
some
vpcs,
for
example,
it's
also
very
useful
for
helping
your
users
debug
at
the
end
of
the
day,
because
there
are
so
many
layers
and
nobody
understands
all
of
them.
A
B
A
Good
thing
happens:
yeah
I
mean
a
typical
example
is
I.
It's
not
really
mini
secret
incident,
but
it's
so
if
it's
still,
you
can,
for
example,
look
at
your
pass
through
cluster.
If
you
don't
use
a
fully
strict
encryption
in
transit
and
you
will
see
anything
that
doesn't
use
ntls
go
to
that
cluster
right
and
so
that's
how
we
identify
those
as
soon
as
we
see
some
traffic
on
this,
we
alert
I
mean
Alexis.
A
A
That's
a
really
good
question:
I
have
as
well
to
be
honest,
I
think
it's
a
mix
of
historical
reasons
and
validation,
webhook
being
really
easy
to
to
deploy
yourself.
I
mean
it's.
The
code
is
really
simple,
but
yes,
we
are
maybe
looking
at
consolidating
that's
why
I
mentioned
it
to
appear.
I.
Think
I
used
Gabriel
in
the
past
as
well,
which
is
also
a
similar
project,
which
is
very
kubernetes
Centric.
A
Yeah,
that's
that's
a
good
point.
I
mean
we
try
to
keep
or
close
deployments
on
layers,
so
we
don't
use
things
like
layers
and
gateways
on
the
cloud.
For
example,
everything
comes
into
or
Android
when
we
do
everything
at
that
level,
yeah
I
mean
I.
Guess
we're
always
looking
at
what
could
be
done.
But
at
this
point
yes,
we
yeah.
We
try
really
strongly
to
be
Cloud
agnostic.
So
that's
the
kubernetes
API
is
our
point
of
reference
here
and.