►
From YouTube: Security Week: Network controls- How to See and Protect Container Network Traffic Using Deep Packet
Description
Network packet inspection is the most important single source of truth for detecting modern attacks on cloud deployments. Hackers will use the network to probe for vulnerable entry points, download malicious code, connect to command and control servers, install crypto-mining software, and steal sensitive data. But traditional network security tools don’t have visibility into container and Kubernetes networks, and basic Network Policy controls are inadequate for protecting against these attacks. Join Tracy Walker of NeuVector in this exploration of the network attack surface for Kubernetes and how to use Deep Packet Inspection (DPI) to get visibility into these attacks and prevent them.
Twitch: https://red.ht/twitch
A
A
A
B
We
have
a
go
all
right,
ladies
and
gentlemen.
Welcome
to
the
wednesday
episode
of
the
openshift
commons
briefings
operator
hours.
My
name
is
michael
waite
from
red
hat
philip
red
hat
been
here
forever,
and
today
we
are
fortunate
enough
to
have
with
us
some
really
great
friends
from
new
vector
and
if
the
screen
share
is
working,
you
can
see
that
we
have
tracy
walker,
who's,
a
senior
solutions
engineer,
and
I'm
I'm
told
that
he
is
that
he's
quite
shy.
C
B
C
B
You
know
I
not
not
to
make
this
be
about
weather,
but
when
I,
when
I
was
in
the
army
a
long
time
ago,
I
went
to
basic
training
down
to
fort
benning
georgia,
and
it
was
in
like
july
and
august
and
like
that
was
like
that
was
just
amazing,
amazingly
hot
and
wet
anyways.
What
do
you?
What
do
you
do
at
red
hat
cameron?
Tell
us
a
little
bit
about
yourself.
While
we
have
you
front
and
center.
C
Yeah
sure
thing:
I'm
a
partner
solutions
architect,
so
I
work
with
our
global
isp
partners
case
in
point
new
vector,
the
friends
we
have
on
our
call
today
and
we
do
joint
solution
creation
together.
We
work
on
integrating
our
technologies
together
and
you
know
spreading
the
good
word
about
the
partner
ecosystem
at
red
hat.
B
A
Well,
I
run
product
management
and
a
number
of
other
technical
functions
at
new
vector,
as
you
mentioned,
you
know,
we've
known
each
other
for
quite
a
while.
So
was
with
the
company
when
we
launched
five
years
ago,
and
at
that
point
we
focused
mainly
on
runtime
security,
but
currently
we've
expanded
that
product
line
to
really.
C
B
B
B
D
D
C
A
Container
and
kubernetes
and
openshift
security-
and
it's
the
name,
actually
comes
from
new
threat,
vectors
right
in
a
containerized
environment.
You
have
new
attack
surfaces,
it
could
be
the
orchestrator,
it
could
be
the
runtime
or
it
just
could
be
the
container
workloads
that
are
running.
So
that's.
A
C
A
It's
it's
fortunate
for
security
firms
and
customers,
because
all
of
that
is
virtualized
right.
The
network
is
virtualized.
The
application
layer
is
virtualized,
so
you
can
really
see
the
network
you
can
see.
What's
going
on
in
containers,
you
can
see
the
host,
so
it's
it's
really
been
an
exciting
time
to
to
see
kubernetes
grow
and
to
see
companies
go
into.
You
know:
full-scale
production,
with
their
new
pipelines.
B
Yeah
yeah,
so
so
you
folks
are
here
today
this
isn't
by
chance
right.
You
know,
you
folks,
have
a
red
hat.
Certified
container
you've
actually
been
working
with
us
for
for
years
on,
on
on
being
on
board
with
that,
and
you
folks
have
an
operator,
it's
red
hat
certified.
So
we
we
put
on
these,
you
know
we,
we
invite
our
partners
like
yourselves
to
come
here
and
join
us,
and
today
we're
going
to
be
talking
about
network
packet
inspection
as
as
one
of
the
topics,
but
mostly
the
deep
packet
inspection.
A
D
A
deep
packet
inspection
means
that
we
are
looking
at
the
actual
network
traffic
as
our
source
of
truth.
First
and
foremost,
we're
able
to
see
the
network
payloads
we're
able
to
identify
the
layer,
7
protocol,
we're
able
to
validate
that
layer,
7
protocol,
which
means
we
have
protocol
decoders
that
are
able
to
make
sure
that
there's
no
tunneling
attacks
or
anything
in
the
network
and
because
of
our
ability
to
do
that.
B
B
D
I'll
I'll
take
a
first
swing
and
then
let
and
then
let
glenn
correct
me
but
yeah
we
work
with
containerized
applications,
so
it
doesn't
have
to
be
using
an
orchestrator,
but
they
do
need
to
be
containerized
and
it
needs
to
be
a
containerized
environment,
so
docker
or
openshift
et
cetera,
any
flavor
of
kubernetes.
We
work
with
rancher,
openshift
and
various
other
flavors
of
kubernetes,
but
as
a
whole.
That's-
and
it
is
because
of
those
environments,
because
sometimes
those
containers
or
those
clusters
are
exposed
directly
to
the
internet.
D
D
But
if
you're
running
a
containerized
workload
in
containers,
whether
it's
on-prem
in
an
air
gap
environment,
which
we
have
many
customers
that
do
that
or
if
you're
running
in
a
cloud
environment
on-prem
doesn't
matter.
We
work
inside
of
those
environments
inside
of
kubernetes,
as
well
as
in
those
containerized
environments,
and
that's
where
we
do
the
that's.
How
we,
where
we
do,
the
security.
B
D
D
Every
exploit
in
the
world
is
a
combination
of
network
access
and
processes
right,
they're
going
to
get
access
to
it
via
the
network,
they're
going
to
execute
processes,
somehow
they're
trying
to
get
information
back
they're
trying
to
wreak
havoc
they're
trying
to
explore
to
find
other
ways
of
you
know
getting
reverse
shells
or
etc,
etc.
So
the
threats
are
kind
of
the
same.
D
You
lose
some
of
that
visibility
when
you're
using
an
orchestrator,
because
that's
what
it's
abstracting
away:
the
complexities
of
managing
the
network
between
hundreds,
if
not
thousands,
of
containers,
so
you
lose
a
little
bit
of
that
by
you
know.
You
gain
the
simplicity
and
the
orchestration
and
the
health
checks
and
all
that,
but
you
lose
visibility
of
what's
really
happening,
and
can
we
detect
something
being
you
know
if
you
get
an
application
exposed,
if
somebody's
trying
to
do
cross-scripting
or
trying
to
you
know,
find
a
way
to
exploit
your
environment?
D
That's
that's
what
we
give
back
and
because
we're
using
the
network
as
a
source
of
truth.
That
means
we
can
use
a
lot
of
automation
so
that
increasing
security
doesn't
mean
also
creating
a
bunch
of
stuff
people
have
to
do.
We
can
automate
so
much
of
it
that
you
can
virtually
do
everything
without
having
to
do
lots
of
configuration
and
stuff
like
that.
B
Apparently
there's
there's
no
question
that
he
can't
answer,
or
at
least
come
up
with
a
reasonable
facsimile
of
so
if
you
have
any
questions
for
tracy
or
glenn
or
cameron
or
well,
you
don't
need
to
ask
me
any
questions,
drop
them
in
the
chat
and
our
bot
will
we'll
drop
them
over
here
into
the
into
the
bridge.
Here
you
were,
you
said
you
brought
up
the
word.
Micro
services
is
micro
services,
still
buzzword,
bingo,
and
let
me
let
me
clarify
what
I
mean
like
everyone
has
been
talking
about.
B
Well,
containers
are
getting
smaller
and
smaller
and
smaller
and
they're
getting
into
microservices,
and
then
that's
why
you
need
to
have
tools
like
a
service,
mesh
and
and
so
forth,
to
be
able
to
manage
all
these
tiny,
tiny
little
containers
all
over
the
place.
But
I
was,
I
was
on
a
call,
or
actually
we
were
doing
a
one
of
our
tv
shows.
It
was
about
a
month
and
a
half
ago,
and
somebody
popped
in
and
said.
B
B
A
Well,
certainly,
if
they're
just
trying
to
lift
and
shift
existing
applications,
you
can
just
take
a
big
old
monolithic,
app
and
you
know,
put
it
in
a
container
and
run
it.
So
I
think
companies
are
just
rushing
to
get
going
on
this
new
cloud
infrastructure
by
doing
that
and
then,
but
you
know,
I
think
what
everybody
is
striving
for
is
whether
they
call
it
microservices
or
not.
It's
really,
you
know
separating
out
their
the
parts
of
their
applications
and
so
that
different
development
teams
can
have
you
know
their
own
unique
pipelines.
A
One
of
the
things
that
I
think
is
most
critical
to
understand
is
that
you
know
we're
moving
to
a
model
where
there's
automated
pipelines
and
security
is
being
built
into
those
pipelines
in
order
to
really
enable
security
teams
to
fit
into
that.
You've
got
to
have
kind
of
a
microservices
based
approach
right.
When
your
application
team
develops
its
little
app
widget,
they
can
really
understand
what's
going
to
happen
in
there,
and
they
can
declare
the
allowed
behavior
of
their
app
once
it
gets
into
production,
and
then
it
can
be
locked
down.
C
A
It's
much
more
difficult
to
do
that
and
to
take
advantage
of
that
modern
security
pipeline.
So
you
know
that's
kind
of
the
goal
I
think
of
many
companies,
but
I
think
what
you
may
be
seeing
is
that
once
you
get
your
first
applications
done,
there
is
a
tendency
to
have
application
creep.
You
know
that,
as
you
add
more
features
and
features
and
features
they
get
bigger
and
bigger
and
bigger.
That's
probably
just
the
natural
human
tendency
that's
going
to
occur
unless
you
have
a
very
disciplined
architecture.
Team.
B
Okay,
all
right,
I'm
actually
just
writing
down
a
note.
I
wanna,
I
wanna,
ask
tracy
a
question,
but
I
wanna
wait
till
after
the
demo.
It
seems
like
being
here
at
red
hat.
You
know
we
have.
We
have
cameron
and
and
dave
muir
and
aaron
levy
and
all
these
people
that
manage
our
relationships
with
security
companies.
It
seems
like
there's
just
a
ton
of
security
companies.
How
many,
how
many
different?
B
How
do
I
phrase
this
like?
How
many
are
needed
like
are?
Are
they
just
waiting
out
there
they're
all
saying
for
multi-cloud
or
you
know,
are
they
do
you
really
need
to
have
40
different
security
companies
in
order
to
be
able
to
protect
your
production
environment?
I
don't
know
if
that's
for
tracy
or
glenn
or
cameron,
but
what
are
your
thoughts.
A
But
having
said
that,
I
will
say
that
you
know
because
the
kubernetes
and
containers
are
abstracting
things
for
the
first
time
you
can
really
in
a
single
security
tool,
see
the
network.
You
can
see
what
previously
was
called
endpoint
security,
so
you
can
see
what's
happening
either
on
the
host
or
in
the
container
the
process
and
file
activity.
A
A
B
A
D
D
B
B
B
I
forget
what
what
company
was
was
hacked
or
or
whatever,
but
when,
when
you
see
something
like
that,
where
company
gets
taken
offline
and
they
can't,
you
know,
deliver
whatever
services,
whether
it's,
whether
it's
you
know,
raising
pigs
or
delivering
energy
and
oil,
is
that
because
they're,
just
not
paying
attention?
Is
that
because
they,
you
know,
I'm
not
trying
to
point
any
fingers
to
any
company,
but
when
something
like
that
happens,
is
it
because
they
were
just
not
doing
their
job
right
from
a
security
perspective?
C
A
Struts
attack
that
should
have
been
remediated
but
was
not
and
exploited
the
tesla
crypto
mining
one
was
just
the
kubernetes
console
that
was
left
open.
So
those
were
kind
of
you
know
the
moments
and
and
could
have
been
solved
by
some
auditing
and
configuration
management.
But
but
you
know
having
said
that
that
these
attackers,
these
hackers
are
very
sophisticated
and
they
have
you
know
very
sophisticated
means:
they're,
always
trying
to
stay
one
step
ahead
of
the
security
teams
and
the
technology.
A
So
it's
a
continual
challenge
to
do
that,
and
companies
just
need
to
really
stay
vigilant,
always
see
like
there's
no
attack
surfaces,
there's
a
new
kubernetes
man
in
the
middle
attack
that
can
attack
the
api,
server
and
orchestrator
you
know
need
to.
They
need
to
understand
that
could
happen
and
make
sure
things
like
that
are
mitigated
and
then,
as
tracy
is
going
to
show.
Ultimately,
you
know
that
something
bad
could
happen,
no
matter
all
of
your
preventive
controls
that
you
put
in
place
in
scanning
that
you
do
so.
A
B
Okay,
we
had
a
question
come
in
from,
I
think
it
came
in
from
youtube
and
I'm
going
to
just
toss
this
up
there
tracy.
If
that's
okay,
I
don't
want
to
make
this
one
came
in
from
john's
john's
from
home,
or
something
something
like
that.
John
anyways
john
says
earlier,
I
heard
new
vector
talking
about
what
they're
not
doing
to
catch
the
network
traffic,
but
I
didn't
catch
what
they
are
doing
to
catch
the
network,
traffic.
D
D
D
D
B
D
System
setting
and
wanted
wanted
me
to
restart,
so
I'm
hoping
you
can
see
my
screen
now.
We
can
see
your
screen.
Yes
all
right.
Well,
this
is
my
only
powerpoint
slide,
so
I've
got
to
make
it
good.
I
might
show
the
architecture
as
well,
but
what
I'm
going
to
show
you
is
that
behavioral,
xero
trust
or
behavioral
based
zero
trust
so
and
I'll
just
kind
of
explain
those
operational
modes
here
and
then
I'll
show
you
what
that
looks
like
and
you'll
see
it
live
in
action.
D
D
D
Now,
albeit
this
is
a
small
demo
environment,
but
what
you're
seeing
here
is
the
traffic.
Here.
I've
got
an
istio
operator,
I'm
seeing
ssl
traffic
there.
As
I
look
at
some
of
these
other
lines,
I
may
see.
Let's
see
here,
I've
got
http
traffic
and
then
I
think
I
even
had
some
redis,
but
we
can
identify
35
different
application
protocols
happening
live
inside
of
a
cluster
and
so
again
that's
validating
that
cluster
or
validating
that
application
protocol
as
well.
So.
B
B
D
Usually
from
customers.
Currently
these
are
the
34
protocols
that
we
recognize.
Obviously
that's
not
all
of
them.
I
have
no
idea
how
many
various
application
protocols
there
are.
We
have
customers
that
have
custom,
they
have
created
their
own
application
protocol
specific
to
their
environments
and
I'm
sure
part
of
that
was
for
efficiency
or
speed
or
performance
or
even
security.
So
whenever
a
customer
says
hey,
we've
got
this
app
protocol
that
it
doesn't
it's
not
on
your
list.
Can
you
add
that
we
we
add
that
glenn?
A
B
A
Yeah
and
and
the
reason
that's
important-
and
this
is
very
key
to
you-
know
a
difference
between
a
layer,
seven
firewall
and
layer,
three
layer,
four.
Is
that
there's
a
connection
you
know?
Let's
say
it's
from
the
front-end
web
or
application
logic
to
the
database,
and
you
know
if
you're
just
saying
well,
this
connection
can
connect
on
a
certain
port
that
the
database
runs
on.
A
You
can
have
a
kind
of
an
attack.
That's
trying
to
attack
that
port
one
layer
of
additional
security
is
to
make
sure
that
the
proper
application
protocol
is
being
used
in
that
connection,
and
so
that's
what
we're
verifying
here
and
then
a
third
layer
of
deep
packet
inspection
is
actually
looking
within
an
approved
application
protocol
for
embedded
attacks
and
that's
the
thing
you
would
be
most
familiar
with
would
be
like
a
sql
injection
attack.
D
That
was
a
perfect
I
and
I
switched
in
case
you
didn't
notice
the
we
went
from
app
protocol
to
the
threats
that
we
can
detect
in
those
protocols.
So
this
is
the
the
network-based
threats
that
we
can
detect
and
the
way
that
we
detect
those
is
using
the
paradigm
of
zero
trust.
Zero
trust,
unfortunately,
has
been
one
of
those
words.
You
were
meaning.
D
You
know
talking
about
micro
services
and
buzzword,
bingo
and,
unfortunately,
zero
trust
has
become
one
of
the
spots
on
that
bingo
card
because
because
it
it-
and
I
kind
of
I
guess
I
kind
of
relate
this
to
devops
right
devops-
is
really
a
philosophy.
It's
a
it's
a
cultural
approach
to
developing
software,
where
you're
trying
to
do
the
things
that
you
can
do
in
development
as
early
as
possible,
because
if
you
can
find
issues
with
it
earlier,
it
costs
less.
D
The
way
we're
doing
and
applying
that
approach
of
zero
trust
in
in
new
vector
is
that
once
we
learn
this
discovery
mode
right
when
we
and
this
is
live,
it
just
requires
that
you
exercise
your
application
right
run.
The
reports
make
sure
all
the
services
are
talking
to
all
the
services
and
and
click
on
all
the
buttons
and
add
and
delete
things.
D
That's
learning
that
behavior
then,
once
we've
learned
that
and
that
again
that
could
be
five
minutes
five
hours
a
couple
of
days
over
the
weekend,
then
you
can
turn
off
the
learning,
and
that
is
what
establishes
the
zero
trust.
Now
you
need
to
validate
what
that
behavior,
that
you
learn.
You
know
revalidate,
that
what
we
saw
is
all
known,
yep,
that
all
looks
normal
talk
to
developers
etc,
but
they
don't
have
to
be
involved
in
this.
D
Otherwise,
from
a
technical
or
implementing
this
approach,
when
you
turn
on
that
monitor
mode,
that
means
that
now
we're
going
we're
not
going
to
block
anything
it's
completely
safe,
and
then
we
were
talking
about
performance,
both
discover
and
monitor.
We
act
as
a
tap.
We
are
not
in
line
with
that
network
traffic,
we're
not
we're
not
inducing
any
performance
lag
anywhere,
and
so
this
is
kind
of
free
right.
You
can
turn
on
monitor
mode.
D
D
We're
trying
to
reduce
the
size
of
the
haystack
where
you're
trying
to
find
the
needle
into
a
bunch
of
bales
of
hay
and
a
small
stack
of
straw
with
hopefully
no
needles,
but
if
there
is
one
it
becomes
readily
apparent,
we
need
to
check
that
out.
Why
is
this
network
connection
coming
from
some
foreign
country
that,
what's
going
on
here
right,
so
we're
trying
to
give
you
the
ability
to
see
something
that
that
you
should
probably
be
paying
attention
to
and
doing
that
in
in
real
time?
D
Then,
if
you
want
to
turn
on
protect
mode,
if
you
want
to
block
this
activity,
then
you
can
use
the
protect
mode
to
not
only
notify
you
of
any
anomalous
activity
but
also
block
that
activity.
So
that's
using
xero
trust
to
get
alerts
to
block
or
to
protect
your
environments
and
again
we
have
customers
that
are
running,
monitor
mode.
We
have
customers
in
protect
mode
and
anywhere
in
between.
You
can
do
this
at
a
very
granular
level.
D
B
D
I
will
I
will
try
to
make
this
very
quick
and
painless
we're
going
to
focus
on
one
container.
This
container
right
here,
that's
called
struts
and
the
details
around
this
container
is
currently
in
a
monitor
mode.
I
have
some
network
rules
that
I've
learned,
so
this
application,
it's
very
simple.
Little
demo
just
running
this
little
super
app
container.
It's
got
a
web
front
end.
It
has
a
load
balancer.
D
D
So
here
is
this
container
there's
the
processes.
So
it's
a
java
app
pause
is
a
kubernetes
native
process.
So
this
is
the
processes
we've
learned
this
morning
when
I
was
in
discover
mode
and
also
network
rules.
We
do
have
file
access
rules.
I
won't
get
into
that
here,
mainly
we're
just
going
to
focus
on
the
process
and
the
network
roles.
So
this
application
is
running
here.
D
I
can
create
a
new
order
and
we'll
call
this
for
tony
and
I'm
just
going
to
give
it
some
numbers
wrong,
keys,
everything's
working
on
this
app
everything
in
normal.
What
and
since
we're
in
monitor
mode.
If
anything
anomalous
happens,
we're
going
to
alert
on
that.
So
let's
do
some
anomalous
stuff.
Very
first
thing
I'm
going
to
do
is
I'm
going
to
bash
into
that
container
and
I
did
preload
my
commands
here
to
make
sure
I'm
in
the
right
environments
and
all
that
kind
of
thing.
D
So
I'm
bashing
into
this
struts
container,
I'm
in
the
container,
I
can
do
an
ls.
I
can
run
commands.
If
I
come
back
here,
remember
we're
in
monitor
mode.
We
don't
block
in
monitor
mode.
So
if
that's
anomalous,
activity
and
bash
and
du
and
ls
are
not
listed
here
is,
is-
is
new
vector
going
to
tell
me
about
those.
D
D
D
Let's
exit
and
let's
attack
that
with
the
struts
attack
that
glenn
was
talking
about
earlier.
I
can
execute
a
python
script
that
is
going
to
hit
this
ip
address.
32
182.
This
will
be
gone
after
after
this
demo,
so
there's
our
ip
address
and
I'm
going
to
hit
it
with.
Basically
a
reverse
shell.
I'm
going
to
try
to
run
this
nc
minus
nv
with
my
ip
address
leap
is
going
to
be
my
port:
reverse
shell
there.
So,
let's
run
that.
D
Okay,
I
got
a
response
now,
while
that
didn't
actually
give
me
a
reverse
shell,
I
did
get
a
response
from
that
container,
and
that
is
exactly
what
a
hacker
wants.
I
want
to
know
that
I
can
cause
a
reaction
that
wasn't
expected
now.
I
can
delve
deeper
into
this
exploit
to
see
what's
going
on
there.
What
did
new
vector
have
to
say
about
this.
D
D
We
did
an
automatic
pack
capture,
so
this
is
unique
to
new
vector
where
you're
able
to
do
live
packet
capture
automatically.
As
I
scroll
down
you
can
see
all
of
the
stuff,
that's
in
that
packet,
so
you
can
download
that
pcap
file
and
and
put
it
into
a
you,
know,
wireshark
and
do
some
analysis.
There
also
notice
down
here
process
profile.
There's
my
nc
there's
my
shell.
So
all
of
those
things
were
captured
network
activity
and
process
activity.
D
And
let's
put
that
container
in
a
protect
mode
and
I'll,
do
this
pretty
quick,
I'm
going
to
move
it
to
protect
mode,
I'm
going
to
jump
to
my
other
my
terminal
window
and
I'm
going
to
execute
those
attacks
pretty
quick
here.
So
I
get
a
confirmation
that
yep
we're
in
protect
mode.
Let's
go
back
and
let's
run
that
exact
same
command.
D
D
We'll
pay
owners
to
the
live
demo
gods,
my
gosh,
it
worked.
No,
we
were
confident
so
there
is
that
apache
struts
remote
code,
execution
and
notice.
We
still
did
the
packet
capture,
but
this
time
it's
deny,
so
we
denied
that
network
connection
from
even
happening
right,
so
that
is
network
layer
security
also
notice.
There
were
no
other
nc
sh.
D
D
D
Any
processes
there.
Oh
that's
the
processes
that
we
were
seeing
earlier
I'll
go
back
here
to
my
group
so
that
you
can
see
that
for
that
container
the
process
profiles
you'll
see
it
just
added
that
bash
to
my
processes.
There
I'm
still
in
protect
mode,
but
it
looks
like
that.
Maybe
now
that
bash
should
work
and
it
does,
can
I
do
my
ls?
No,
can
I
do
my
du?
No?
D
D
Let
me
show
one
last
thing,
because
I
want
to
show
the
actual
discover
of
how
we
do
this,
so
I'm
going
to
move
this
now
to
a
discover
mode,
so
we
can
learn
those
processes
real
time.
You
can
see
exactly
how
fast
this
happens.
I'm
bashed
in
I
can
do
ls.
I
can
do
du
and
when
I
come
back
here
and
I
hit
refresh
there's
my
bash
there's
my
ls
there's
my
du.
So
we
learn
that
fast
and
we
can
then
make
those
rules
that
fast
and
then
I
can
export
those
rules
and
I'll.
D
Let's
say
I'm
going
to
go
to
a
different
environment.
I'll
put
them
in
monitor
mode.
We
can
automatically
create
the
yaml
file,
so
you
can
replicate
those
security
policies
across
multiple
clusters.
Basically,
cloning,
your
zero
trust
perimeter,
and
now
you
can
do
the
exact
same
segmentation
across
multiple
clusters.
So
now
you
get
the
exact
same
size
haystack
to
find
those
needles
to
look
for
that
unknown.
Behavior.
B
D
D
So
we're
not
like
suggesting
there's
some
security
tools
that
will
like
suggest
a
layer,
three
layer,
four
policy,
that
you
know
a
user
can
implement
in
this
case,
because
we're
doing
layer,
seven
and
kubernetes
doesn't
do
layer,
seven
rules,
so
we
are
independent
of
those
now
if
you've
already
spent
a
lot
of
time,
creating
those
kubernetes
network
security
policies,
don't
toss
those
in
the
trash
right.
You've
already
spent
time
defining
the
paths
right,
which
is
essentially
what
you
do.
There's
no
deny
rules.
It's
all
allow
rules,
I
think
that's
right
I'll.
D
We
can
then
verify
using
our
rules
and
our
network
inspection
to
validate
that.
Yes,
all
the
traffic
is
using
those
rules
and
we're
not
seeing
anything
outside
of
those,
and
that
becomes
the
big
advantage
in
those
environments.
You
may
already
have
some
network
security
policies
or
maybe
you're
partially
covered
with
network
security
policies.
D
We
give
you
the
the
ability
to
cover
all
of
that
gap
for
the
known
and
the
unknown,
whether
or
not
you're
using
those
you
don't
have
to
change
them
continue
to
use
them.
Kubernetes
will
still
use
them,
but
this
will
give
you
like.
The
analogy
I
like
to
use
is:
if
you've
already
put
locks
on
your
data
center.
D
Now
we
can
be
the
video
camera
on
those
doors
to
making
sure
that
nobody,
you
know,
put
tape
over
the
lock
and
is
going
in
and
out
of
that
door,
even
though
you
put
the
lock
in
right.
So
we
can
be
a
verification
and
validation
of
the
of
the
good
work
that
you're
already
doing,
and
we
don't
we're
not
managing
those
and-
and
you
could
potentially
have
some
conflicts,
but
our
learning
is
100
accurate.
D
A
But
you
know,
I
would
say
we
do
help.
Customers
convert
those
ultimately
policies
into
new
vector.
Most
of
our
rules
are
a
superset
of
that.
So
you
know
we
just
build
ours
by
default
at
layer.
Seven.
So
at
that
point,
if
it's
a
similar
rule,
there's
no
need
to
have
a
network
policy,
so
you
can
just
get
rid
of
those.
A
D
B
Hey
tracy
a
question
from
from
mike
waite
here
from
new
hampshire.
How
does
this
work
meaning,
like
you
know,
I
work
with
lots
of
software
companies.
Some
some
software
companies
have
like
a
software
as
a
service
where
you
know
everything's
running
inside.
You
know
their
infrastructure
and
you
just
connect
up
to
it
to
get
whatever
you
need
or
other
other
companies
who
have
like
apm.
You
know
performance
management,
there's
there's
like
agents
that
have
to
be
deployed
on
each
node
that
then
phone
home
to
the
mothership.
B
D
Oh
well
I'll
make
it
quick.
We
do
not
use
agents,
agents
that
are
talking
directly
to
kubernetes
api
slows
down
the
api
we've
seen
that
firsthand,
because
we
just
completed
performance
testing
with
one
of
the
hyperscale
cloud
providers
where
they
were
doing
performance,
testing
of
new
vector
versus
other
tools
using
500,
750
and
1000
node
clusters.
D
No,
I
did
not
mistake:
1
000,
vms
running
in
a
single
cluster
and
then
doing
performance
testing
on
that
we
were
the
only
product
that
was
able
to
complete
all
the
performance
testing
successfully
in
that
kind
of
an
environment
and
the
reason
we
can
perform
that
well
is
the
following:
we
deploy
as
containers.
This
controller
is
the
only
container
that
is
communicating
with
the
kubernetes
api,
no
other
container.
We
don't
have
100
agents
or
side
cars
or
anything
like
that.
D
We're
not
using
the
sidecar
overlay
we're
inside
of
the
cluster,
so
there's
four
different
types
of
containers.
This
is
handling
our
apis.
The
scanner
container.
Does
our
scanning
very
fast
I'll
emit
some
details
there,
the
web
ui,
making
api
calls
of
the
controller.
So
everything
that
you
were
seeing
me
doing
here,
those
are
making
api
calls
of
that
controller.
D
I
also
have
a
command
line
tool
interface
built
in
then
this
enforcer.
So
this
is
what
we're
using
to
see
that
traffic
and
collect
those
processes.
This
enforcer
sits
next
to
that
virtual
switch.
So
that's
how
we're
able
to
see
that
network
traffic
and
inspect
and
validate
that
network
traffic.
This
is
one
of
our
seven
patents,
this
positioning
and
how
this
thing
works,
and
so
that's
how
we're
able
to
do
that.
That's
why
we
don't
use
agents.
There
is
a
single
enforcer
on
every
worker
node.
D
So
in
a
thousand
node
cluster
we
would
have
a
thousand
enforcers
and
all
of
those
enforcers
would
be
talking
to
these
controllers.
We
did
have
to
beef
up
the
size
all
of
these
default
at
one
v
cpu
and
one
gig
of
ram
vram.
So
on
average
they're,
very
you
know
fairly
small
containers,
but
when
you
get
to
you
know
250
500,
1000
node
clusters,
you
may
have
to
beef
up
your
controllers
a
little
bit
because
they
are
doing
all
that
talking
to
all
of
those
enforcers,
etc.
B
C
B
B
B
B
Where,
where
can
we
see
you
guys?
Are
you
going
to
be
at
kubecon
by
the
way
I,
like
you
know,
just
we're
planning
on
going
to
kubecon
out
in
los
angeles,
but
I
was
talking
with
our
hr
team
yesterday
and-
and
it
looks
like
that,
might
actually
get
you
know
switched
back
to
being
100
virtual,
but
but
how
do
we?
How
do
we
find
you
folks
going
forward.
A
You
know
obviously
a
great
place
to
just
meet.
I
think
tracy
will
be
there,
so
you
can
get
a
live
hands-on
there
as
well,
and
we
have
a
number
of
publications
on
the
red
hat
site.
We
do.
We
have
several
podcasts.
I
think
I
did
one
earlier
this
year
on
vulnerability
management,
so
totally
different
topic,
yeah,
that
was
in
march
the
topic.
B
Excellent
well
before
our
producer
starts,
sending
me
any
more
messages
on
google
chat.
I'm
gonna
have
to
wrap
this
up
for
the
day
and
like
to
thank
you,
tracy
and
glenn
again
for
for
being
our
victims
here
on
the
open
shift,
commons
briefings
operator
hours
and
thanks
everyone
for
coming
and
we'll
see
you
next
time.