►
From YouTube: Antrea Community Meeting 04/20/2020
Description
Antrea Community Meeting, April 20th 2020
A
A
A
B
A
C
C
C
Today,
I
want
to
discuss
the
some
of
the
features
and
the
functional
aspect
of
cluster
scope
network
policies.
So
what
is
the
motivation
behind
this?
It's,
basically
that
humanity
is
upstream
network
policies
are
I,
am
assuming
most
of
us
are
aware
of
what
they
are.
So
I
would
spend
time
in
explaining
the
concept
of
the
network
policy,
but
some
of
the
things
that
about
the
radio
policies
are
that
their
namespace
code.
So
if
you
want
to
create.
C
Some
security
policies
for
the
entire
communities
cluster-
you
will
have
to
essentially
replicate
that
ribbon.
It
is
a
little
policy
in
each
and
every
namespace,
and
probably
you
might
have
an
automation
or
something
either
to
perform
that.
But
you
know
it's
it's
a
tedious
process
and
the
other
thing
is
that
if
you
want
to
add
any
features
to
these
little
policies,
when
you
gotta
go
to
upstream
and
it
can
be
slow
so
that
that
can
you
know
just
adding
something
in
and
here
project
for
now
can
speed
that
process
up
also
I
mean
anything.
C
The
eventual
idea
would
be
that
whatever
works
for
the
community
or
whatever
work
for
a
project,
we
should
try
to
log
stream
that
in
the
community
and
see
if
we
can
eventually
get
this
in
community
so
that
we
can
consume
it
directly
instead
of
having
series
the
one
of
the
other
things
that
the
kubernetes
network
policies
don't
allow
us
to
do
is
prioritize
the
policies.
So
essentially,
the
network
policies
are
set
off
by
closed
rules,
so
they're
all
allowable
and
sorry.
C
They
have
all
allow
rules
and
you
cannot
group
them
or
you
know,
create
a
group
of
policies
which
have
higher
precedence
over
another
group
of
policies.
So
so
those
are
a
few
things
that
you
know
led
to
this.
You
know
thinking
about
like
creating
a
cluster
scoped
Network
policy,
so
so
so
how
we
came
across
this
is
like
basically,
you
know.
Some
of
the
other
CNS
provide
some
form
of
cluster
scope
policies
with
experience
at
VMware.
C
Also,
we
have
security
policies
which
we
can
apply
at
a
larger
scope,
I,
look
to
many
communities
upstream
pr's
and
issues
targeted
towards
this,
this
new
policy
field
and
or
scope,
and
and
then
there
was
some
PM
feedback
for
these
cases.
So
so
the
set
of
feature
that
I
have
documented
here
is
like
is
like
is,
like
you
know,
collected
from
all
this.
These
different
avenues
and
I
have
for
now
put
them
in
to
p0
p1,
essentially
saying
that
please
do
something
that
would
be
nice
to
have
in
the
immediate
draft.
C
First
draft
of
the
clinical
policies.
Even
is
something
that
maybe
we
can
add
later,
but
these
are
not
set
in
stone
these.
This
is
something
that
you
know
the
community
and
your
feedback
to,
and
we
can
you
can
talk
about
it
and
see
what
makes
more
sense
to
be
done
earlier
or
what
can
be
pushed
on
data
so
just
to
go
through
these
a
few
features.
C
So,
today
the
story,
the
network
policies,
allow
you
to
select
workloads
which
are
false,
and
you
for
that
purpose.
It
gives
you
two
kinds
of
select
responses.
One
is
hot
selector
which
can
be
put
in
the
applied
to,
and
maybe
in
the
to
and
from
rules
the
other
one
is
namespace
selector,
which
can
be
put
in
the
in
the
to
and
from
investigations
to
select
namespaces
and
effectively
falls
along
with
that.
C
Also,
the
IP
block
is
something
that
supported
the
communities
network
policy,
but
one
of
the
things
that
we
thought
that
we
could
introduce
with
with
the
cluster
scope
policy,
is
like
to
select
the
ability
to
select
other
kinds
of
workloads.
I
mean
not
just
pods
and
in
spaces,
for
example,
notes.
Maybe
something
that
can
be
interesting.
I
saw
a
few
upstream
issues
around
this.
There
was
a
discussion
on
having
more
selectors
in
the
network
policy
even
a
couple
of
weeks
ago.
C
It
was
raised
in
the
Signet
work
that
we
should
come
up
with
a
v2
network
policy
version
which
might
select
nodes.
So
so
that's
where
that
idea
came
comes
from,
we
can
also
select,
perhaps
provide
a
way
to
select
external
entities
or
something
like
a
VM
or
a
variable
node,
which
is
outside
of
your
communities
cluster.
So
you
can,
then
you
know,
make
your
controller
of
the
air
of
these
externalities
import
them
using
some
way.
C
We'll
talk
about
that
a
little
later,
but
we
can
perhaps
you
know,
then
then
we'll
control
going
to
be
intelligent
enough
to
derive
the
IP
addresses,
and
you
know
constantly
monitor
the
change
in
the
IP
addresses
of
each
particular
series
and
and
then
automatically
apply
it's
based
on
that.
So
that's
one
of
the
things
like
we
will
introduce
like
to
introduce
the
other
is
today
the
the
selectors
are
all
label
selectors.
C
There
have
been
certain
issues
in
communities
or
any
feature
requests
we've
given
IDs
signet
work
that
they
would
like
to
select
certain
resources
directly
by
name.
So
so
so
I
put
a
comment
up
there
and
then
I
thought.
Maybe
this
is
something
that
can
work
with.
The
cluster
spoke
network
policy,
also
that
the
ability
to
select
resources
like
namespaces
directly
by
name
instead
of
having
label
selectors
one
valid
concern,
is
that
you
know.
If
you
are
aware
that
certain
labels
with
only
namespaces
select,
you
will
do
certain
restrictive,
Network
policies.
C
C
So
unless
you
have
no
admission
control
or
some
sort
of
ways
to
restrict
label
manipulation,
but
but
yeah,
and
also
sometimes
you
don't
want
to
expose
certain
namespaces
directly
and
they
might
newly
one
or
two.
So
instead
of
going
and
labeling
those
namespace
routed,
you
want
to
put
their
names.
So
that's
something
that
we
can
think
about.
You
know
directly,
you
know,
adding
a
field
will
match
exact
or
something
of
that
sort
where
you
can
directly
add
names
in
space
labels
like
this.
C
Another
thing
that
I
mentioned
was
the
prioritization
of
certain
Network
policies
like
since
they're
all
whitelist,
you
are
not
able
to.
You
know,
set
precedence
between
two
network
policies.
So
one
way
to
do
that
and
I
know
in
calico
community
they
do
it
using
clearing
so
and
in
vmware.
We
have
let
categories
or
something
like
that.
So
here
we
could
group
these
policies
who
we
would
want,
or
the
area
wants
to
have
higher
precedence
into
into
a
group
called
category.
C
C
Perhaps
you
could
also
add
logging
on
individual
rule
levels
to
you
know
to
to
do
some
sort
of
incident
logging.
You
could
specify
certain
rules
that
you
know
these
rules
are
going
to
check
whether
if
the
packet
passes
and
its
head
because
or
is
allowed
or
denied
because
of
this
particular
rule,
we
would
want
that
incident
to
be
monitored
or
logged.
So
we
could
do
that
at
google
level
by
adding
a
field
we
could
also
support.
I
think
I
skeptical
strike
capability.
C
Never
policies
allow
only
so
you
have
only
one
type
of
action
which
is
allow
action,
so
we
could
also
add
deny
action,
whereas
you
create
rules
which
you
know
it
specifically
deny
perfect
for
ingress
or
egress
on
the
placards.
Similarly,
we
can
also
support
a
reject
action
which
could,
instead
of
just
dropping
the
packet
right
away.
You
probably
send
a
response
back
to
the
requester
you
can
also.
We
can
also
be
more
granular
in
terms
of
setting
priorities
for
different
rules
within
the
policy.
C
I
think
soon,
I'll
talk
about
the
policy
evaluation
have
the
rules,
let
so
that
that
would
be
one
proposal
and
if
anyone
else
has
income
and
comments
on
that,
you
can
feel
free
to.
Let
me
know-
or
you
can
come
in
on
the
dog.
There
are
also
other
selectors
that
were
requested
upstream
and
also
some
issues
was
like
you
know.
Perhaps
we
could
have
services
targeted
instead
of
targeting
pots.
C
You
know
because
I
guess
one
notion
was
that
people
in
communities
exposed
workloads,
wire
services,
that
concept,
and
so
it's
easy
for
them
to
remember
the
pot.
Selectors
sorry
remember
the
services
rather
than
hot
selectors
or
the
labels
that
were
used.
So
that's
one
way
to
you,
know,
add
moving
selector
yeah.
That
is
like
something
called
a
DNS,
be
a
selector
I.
C
Think
in
this
case
the
the
issue
was
that,
for
the
request
was
that
we
can
in
the
to
and
from
we
had
some
DNS
selectors,
where
you
provide
the
DNS,
the
name
and
before
applying
the
policy
you
resolve
that
some
IP
addresses
and
then
use
to
the
addresses
only
to
and
from
and
then
the
it
can
be
dynamically
updated.
So
the
policies
dynamically
a
bit
updated
instead
of
hard-coding
the
signers
using
IP
block.
So
this
could
be
dynamic.
So
that's
that's,
and
that
was
another
request.
C
So
so
we
could
consider
all
of
these
features
in
the
cluster
scope
policy.
So,
let's,
let's
talk
about
so
this
all
of
this
can
be
can
be
achieved
by
creating
a
single
set
of
series
in
the
ninth
area.
So
one
one
such
theory
that
would
help
achieve
this
is
a
category
cereal
which
is
a
pretty
straightforward.
You
know
by
itself
it
doesn't
do
anything.
C
You
know
things
work
out
of
the
works
and
if
they
prefer
to
have
more
hierarchy
and
more
categories,
they
can
do
so.
You
could
also
limit
it
to
a
cap
of
skin
because
you
know
practical
purposes,
I
guess
more
than
categories.
Probably
might
not
make
sense,
but
most
most
these
cases
should
be
should
should
kick
in
within
3
to
10
categories,
and
one
of
the
reasons
why
we
could
set
set
a
limit
to
this
category
is.
D
C
One
of
the
other
reasons
why
I
thought
we
could
cap
put
a
limit
is
that
when
we
think
about
implementing
the
category
with
OVS
and
tables
you
know
each
each
table
has
like
about
65,000
priorities
within
it.
So
we
would
want
to
set
a
few
few,
like
ranges
of
priorities
for
each
of
the
category,
so
you
know
the
more
categories
we
had
less
the
number
of
priorities
I
so
so
10
might
be
good,
but
we
can
talk
about
it
and.
C
C
A
D
Dropped
it
I,
don't
know
if
it's
question
comment
in
I'm,
not
an
expert
here,
but
I
know
a
little
bit
about.
It
was
wondering
how
your
idea
of
getting
policy
down
to
the
service
or
app
level
would
overlap
with
this
deal
now,
maybe
you're,
assuming
that
not
everybody
even
uses.
This
do
and
that's
a
good
reason
to
do
this.
But
it
strikes
me
that
if
your
goal
was
to
implement
policy
at
service
or
app
level,
why
wouldn't
I
use
surface
mesh
so.
C
D
D
Now,
how
how
would
this
vidiian,
if
you're
talking
about
doing
it
down
a
vm
level,
suppose
you
had
something
like
VMs
joining
in
with
kubernetes
workloads,
either
mesh
expansion,
or
there
are
ways
to
do
it
with
envoy
and
contour?
Would
that
be
of
some
use
here?
Would
there
be
some
way
to
plug
that
into
beyond.
C
D
C
Sounds
good
so
so
yeah!
This
is
the
question.
I
call
policy
so
before
we
get
into
the
individual
needs
of
the
policy.
Spec
I
just
wanted
to
talk
about
the
the
evaluation
of
the
policy
enforcement
and
I
think
this
was
probably
serviced.
Your
question
would
be
answered.
Maybe
you
have
some,
so
this
is
how
it
would
look
like
now.
Each
of
those
clustered
policies
will
be
referred
will
will
have
reference
to
the
category
that
it
refers
to,
so
that
that
will
then
form
a
group
of
these
policies
within
one
category.
C
So
let's
say
we
have
three
categories
or
we
have
multiple
categories,
but
let's
say
you
have
like
two
here:
as
shown
can
zero
and
then
you
have
1
2,
3
n,
so
so,
and
then
we
have
like
certain
network
policies
which
are
associated
with,
can
0.
So
now
they
will
be
added
into
this
particular
group.
So
mainly
if
you
have
a
new
cluster
neighbor
policy,
which
is
refering
cat
and
it
will
go
to
this
particular
and
now
this
is
how
the
proceedings
already
will
take
place.
C
C
That
is
that
the
the
community's
network
policies,
when
you
have
certain
odd
selector,
a
certain
set
of
poles
which
are
selected
or
targeted
by
a
network
policy
for
an
allow
rule
they
are
by
they
are
they
are
isolated
from
the
rest
of
the
cluster
and
only
traffic
from
the
ingress
and
egress
rules
specified
by
that
policy
is
allowed.
That's
that's
the
behavior
of
allow
rules,
so
so
the
the
semantics
in
the
cluster
Network
policy
for
all
our
rules
is
similar.
C
Basically,
if
you
select
certain
poll
result
in
workloads
in
the
applied
to
in
the
cluster
Network
policy,
they
will
be
automatically
isolated
from
the
rest
of
the
cluster
and
only
traffic
allowed
by
the
ingress
egress
rules
in
the
in
the
questionnaire
policy
will
be
allowed.
So
so
you
can
see
the
green
boxes
here.
All
of
the
allow
rules
will
be
will
have
the
same
priorities
within
a
particular
category,
and
then
we
create
a
set
of
the
complimentary
isolation
rules
within
the
same
category.
C
I
have
an
open
question
around
this
I
will
ask
the
end
of
the
meeting
so
that
I
can
get
more
feedback
so
yeah.
So
this
is
how
the
allowance
and
the
exhalation
rules
will
work.
The
deny
rules
work.
You
know
pretty
much,
as
is
so.
There
are
no
special
semantics
around
the
denials.
You
know
whatever
is
specified
in
the
in
the
policy,
is
denied
and
and
they
will
have
higher
precedence
over
allowance.
C
So
then
we
deny
will
be
first
taken
into
effect,
so
they're
essentially
making
sure
that
traffic
with
suppose--suppose,
but
it
is
drop
first,
that's
how
the
enforcement
is
proposing
and
and
then
you
know,
once
all
the
categories
are
evaluated
after
that
the
community
is
up
stream.
Network
policies
will
be
validated
so
this
this
was
like.
C
You
know,
let's
say
it's
like
a
category
or
in
itself
which
it
has
the
lowest
precedence,
not
exposed
to
use
it,
because
this
is
a
real
implementation
specific,
but
you
can,
but
here
you,
since
there
are
no
deny
rules,
you
just
have
these
allow
rules
and
then
the
corresponding
isolation
goes
to
enforce
the
particular
NATO
policy.
Semantics
is
you're.
C
D
Quickly,
those
are
enforced,
let's
say:
I
update
the
policy
of
what
I'm
thinking
about
is
suppose.
You
have
some
security
add-on.
That
is
monitoring
for
unusual
behavior.
The
connections
been
established
and
it's
running,
but
my
security
monitor
wants
to
alter
it
to
because
it
spotted
some
anomaly.
It
does
your
spec
envision
that
that's
mandatory
to
support
that
kind
of
thing,
or
is
it
undetermined
or
are
these
policies
enforced
only
when
pods
are
dispatched
or
connections?
Our
main.
C
C
D
Well,
I
was
wondering
if
an
external
entity
could
shut
down
or
limit
an
existing
connection,
or
if
this
would
only
be
applied
when
the
connection
was
first
established,
I
mean
I
could
also
see
doing
this
for
triage
when,
let's
say
I'm
at
an
edge
or
on-prem
location
and
I
lost.
Half
my
bandwidth
and
I
want
to
alter
the
allocations
between
critical
and
less
critical
apps.
Would
what
would
what
we're
proposing
here?
Allow
you
to
do
that
sort
of
thing.
C
C
C
B
You're
correct
because
we
use
contract,
like
others
ionized
like
calico,
it's
not
set
in
stone,
I
mean
if
this
wasn't
a
good
differentiating
feature.
We
could,
when
a
new
network
policies
applied
potentially
like
flush
first,
some
some
contract
rules
that
matched
in
unit
for
policy
and
basically
reset
those
connections.
D
D
I'm
just
guessing
that,
if,
if
ultimately,
we
did
vision
that
perhaps
this
gets
adopted
as
kubernetes
policy
I,
think
the
people
on
their
architecture
and
steering
committees
would
want
something
versatile
enough
that
it
doesn't
apply
to
just
one
network
implementation,
but
potentially
others
that
may
not
have
the
same
limitations.
You
know.
C
A
C
D
C
So
so
this
is,
this
is
like
the
behavior,
like
policy
enforcement
model,
that
you
know
it's
the
proposal,
but
you
know
we
can
always
have
more
discussion
on
this
yeah
so
moving
forward.
This
is
just
a
sample
policies
already
I
think
maybe
you
can
just
skip
this
part
and
then
perhaps
take
a
look
at
the
different
fields.
C
So
the
the
network
policy
cluster
cluster
network
policy,
a
will
be
a
cluster
scoped
policy
which
will
have
like
a
spec
which
would
specify
the
desired
behavior
of
this
policy
and
a
status
which
essentially
will
store
the
feedback.
Like
you
know
whether
things
were
realized.
What
kind
of
you
know
realization
was
them
before
this?
Not
good
policy,
so
I
know
Channing
has
some
proposals
around
that?
Maybe
we'll
probably
talk
about
it
next
meeting
or
sooner
on
the
spec
side.
C
C
Then
there
is
an
applying
to
feel
this
is
similar
to
the
spec
dot
or
selective
in
the
Coverity
is
network
policy.
This
is
where
the
target
you
know
this
is
where
the
policy
will
be
applied,
or
it's
essentially
not
just
pot
selector,
but
it
will
have
more
than
pole.
Selection
will
be
a
namespace
selector,
unlike
network
policy.
It
can
also
select
external
entities,
know
where
and
wherever
in
certain
implementation.
C
If
we
are
able
to
apply
policies
on
the
external
VMs,
but
if
not,
then
there
will
be
part
of
tool
from
then
D
up
so
that
was
applied
to
then
there
is
no
simpler
to
the
communities
network
policy,
ingress
and
egress
would
be
set
up
in
vessels
or
egress
routes.
I,
don't
think
we
need
a
policy
text
here,
because
you
know
persons
of
English
women
would
our
presence
of
ingress
will
be
elect.
The
policies
of
type
ingress
presence
of
egress
would
mean
it.
C
C
They
decided
to
also
write,
because
within
the
ingress
will
again
it's
pretty
similar
to
the
NATO
policy
and
you
will
have
a
collection
of
ports
to
which
this
will
apply
to
which
is
pretty
similar,
the
perks
for
as
the
Canadian
policy
you
know,
you'll
have
the
protocols
supported
protocols
and
then
port
number
and
a
name
port.
Perhaps
in
the
port
number
we
could
also
introduce
ranges
of
poles.
I,
think
that's
something
that
can
be
a
differentiating
thing.
C
I
haven't
added
that
in
the
dock,
but
we
can
add
that
Ritter,
but
that's
something
that
varies
in
act
or
policy
doesn't
support.
So
that's
something
that
we
would
add
in
the
ingress.
The
firm
would
tell
you
from
which
is
the
source
that
is
allowed
like
what
is
the
set
of
those
loads
that
should
become
a
source
action
which
is
different,
which
is
different
from
the
common
regional
policy
that
you
know,
since
we
can
do
deny
action.
C
So
this
will
specify
the
type
of
rule
and
enable
logging
would
then
you
know
if
you
set
this
to
true.
You
perform,
incidentally,
logging
for
this
movie
or
anything
that
it's
just
similarly
for
us,
except
for
from
it's
too
and
then
listen
from
the
destination
part
in
the
way
of
the
rule
for
the
applied
to
action
like
I
mentioned,
allow
and
then
I
would
be
two
actions
that
we
start
off
with
and
perhaps
reject
in
the
future
if
it
makes
sense
the
pure.
You
know
this
is
where
kind
of
we're
at
the
selector.
C
C
C
Means
I
don't
think
we
can
perhaps
I've
validation,
do
not
support
match
name
on
bonds,
because
nobody
creates
for
remember
spots
by
name
make
sense
for
for
resources
space.
The
other
different
thing
is
that
you
know
when
you
select
for
selector
in
the
communities
network
policy.
It
will
select
faults
from
that
namespace.
In
this
particular
case,
pod
selector
by
itself
will
select
fault
the
dose
labels
from
all
these
spaces.
So
that
will
be
the
difference.
C
C
One
thing
that,
and-
and
this
is
something
that
we
can
you
know
in
the
controller-
convert
a
node
into
its
internal
IDs
or
and
then
has
an
allowable
to
be
IP
addresses
using
an
old
selector
can
perhaps
give
us
all
these
cases
where
you
will
want
to
protect
certain
host,
Network
launch
or
on
certain
ports
and
a
lot
of
traffic
or
deny
traffic
on
on
those
things.
So
that's
that's
one
use
case
that
we
see.
C
C
C
A
Don't
have
any
guarantee
that
the
additional
interfaces
are
managed
by
interior,
so
I
mean
I.
I
know
from
a
specification
perspective,
it
makes
sense
from
an
implementation
perspective.
If
the
second
rail
interface
is
managed
by
some
CNI
that
we
don't
even
know
how
it
configures
interface
do
we
know,
do
you
know
our
Bishop
if
we
can
anyway
configure
and
a
security
policy,
for
it.
C
E
A
E
C
You
can
start
off
somewhere
and
then
type
this
and
maybe
keep
the
implementation
aside.
The
addictions
will
assume
things
yeah,
so
I
think
so
before
I
move
on
I
had
this
open-ended
question
here
on
this
particular
diagram
is
two
questions
around
this
one
was
at
the
moment
the
allow
rules
key
semantics
to
disapprove.
Isolate
these
rules.
I
am
placing
them
within
the
same
category
the
default
isolation
so
for
category
0.
All
of
these
isolation
groups
will
be
here
for
any
to
be
here
so
effectively.
C
A
C
F
Is
actually
the
question
I
was
meant
to
ask
you
know
long
time
ago,
when
you
present
this
diagram,
I
mean
to
me,
you
know
for
an
at-will
policy.
If
you
know
you
specify
the
allowed
actions,
you
never
sort
of
like
explicit,
you
say
that
the
other
you
know,
traffic
patterns
applying
to
this
apply
to
destinations
should
be
sort
of
like
denied.
F
So
essentially,
if
you
have
multiple
rules
which
are
selecting
the
same
thing
and
they're
in
you
know
different
categories,
well,
I
think
this
would
mean
would
possibly
be
more
making
sense
if
this
means
you
know
this.
Allow
is
more
of
higher
power
D,
and
this,
allow
is,
of
you,
know,
lower
power
Li,
but
the
higher
power
D
doesn't
mean
you
know.
The
other
traffic
patterns
will
all
be
denied
at
this
priority.
F
A
F
F
B
Maybe
it's
a
bit
he'd
say,
but
I
think,
maybe
that
it
would
actually
help
to
have
some
actual
use
cases
in
the
document,
like
kind
of
like
a
user
story,
kind
of
thing,
like
oh
I'm,
IT
and
the
cluster
operator,
so
I
want
to
really
deny
those
things
and
then
you
have
like
oh
I'm,
I'm,
a
developer
and
I
want
to
add
those
roles
for
my
applications
and
I
was
like
and
talk
to
each
other.
So
maybe
you
have
an
actual
use
case
in
the
document
could
be
useful.
Yeah.
C
C
C
A
One
one
more
question:
a
little
bit
related
to
this.
The
cluster
Network
policy
is
a
do.
You
expect
some
air
back
control
zone
on
the
object,
for
instance,
the
user,
which
is
the
cluster
administrator,
of
course,
can
read
and
write
this
network
policy,
but
there
could
be
cluster
users
like
application
owners
that
don't
have
right
to
modify
cluster
policies
will
be
allowed
to
see
which
are
the
currently
enforced
cluster
policies.
Or
do
you
think
that
these
objects
should
be
completely
hidden
from
users
which
are
not
cluster
administrators.
C
A
C
From
the
name
I'm
going
to
I'm
going
to
skip
the
status
part,
because
I
think
Chan
will
probably
have
a
more
detailed
talk
around
this.
Sometimes
so
maybe
we
can.
The
only
thing
I
would
specify
is
that,
unlike
the
Community
Network
policy,
you
will
have
status
which,
which
can
be
used
to
realization
status,
and
perhaps
you
know,
I
think
a
chance
proposal.
C
C
C
Used
to
import
CRE,
so
import
workloads
which
are
outside
of
criminal
justice,
so,
for
example,
it
could
be
like
a
bare-metal,
some
VN
outside.
Perhaps
this
could
be.
You
know
there
could
be
a
higher
level
API,
which
you
know
which
drive
the
creation
of
external
entities
or
so
so
think
about
services
and
endpoints,
the
endpoints
map
to
the
back-end
of
services
and
an
automatically
created
for
every
ports.
So
the
user
doesn't
really
create
them,
but
you
could
also
create
an
endpoint
explicitly.
C
The
any
points
would
you
know,
kind
of
store,
this
VIP
address,
and
the
name
for
that
for
the
different
endpoints
associated
with
that
entity,
so
think
of,
like
maybe
a
VM
has
multiple
interfaces,
and
then
you
want
to
list
them
out
here.
The
ports
on
that
entity
and
the
owner
is
something
that
recently
added.
It's
probably
you
know.
C
Cases
where
the
controller
can
compute
the
and
then
it
can
be
suppose
that
information
to
the
agents
which
it
does
today
similar
to
policy,
the
presentation
works
there.
But
you
know
you
could
have
like
an
another
controller
which
probably
takes
the
external
entity,
information
and
then
programs.
So,
for
example,
perhaps
you
know
you
know.
C
On
this
owner
field
and
then
apply
policies
create
those
security
on
node,
so
this
is
one
otherwise.
You
know
the
external
entities
can
be
translated
into
the
addresses
and
then
they
can
be
automatically
in
the
from
the
by
the
end
here.
So
these
are
the
set
of
series
that
it
rose
to
be
so
I'm
going
to
skip
the
Yambol,
specs
I
think
it.
G
G
C
Policies
will
all
share
the
same
priority,
and
then
they
can
go
is
more
specific
goal
back
so
the
first
day
will
be
where
it
has
graduated
and
then
there.
So
this
is
writing
a
sperg
engine.
Suggestion
I
think
he
mentioned
that.
Perhaps
we
can
have
order
among
or
between
the
between
the
rules
of
each
of
the
policy.
So
then
we
can
use
those
as.
C
F
C
I
think
that's
that's
orthogonal
to
this
effort,
but
I.
This
was
also
raised
in
some
signature
meetings
was
we
need
a
way
to
the
signature,
can
add
some
tools
which
could
help
improving
and
let
you
know
exactly
whether
you
know
this.
This
communication
is
allowed
or
not,
I
think
the
the
time
when
we
received
this
was
when
we
were.
We
spoke
about
a
cap
about
the
testing
framework,
the
network
policy
testing
framework
that
we
proposed
and
she
network,
if
you
last
one
that
is
when
those
guys
wanted
to
or
dinero
squad.
C
This
has
part
of
that
framework
where
we
we
give
a
sample
input
of
policies
or
like
some
parts
and
then
then
the
tool
kind
of
tells
the
users
whether
this
communication
is
allowed
or,
if
not,
and
what
kind
of
policies
are
blocking
it
in
my
editor,
so
I
think
that's
what
you
are
alluding
to.
So
it's
it's
kind
of
orthogonal
to
to
the
cluster
Network
policy
CID,
but
it's
definitely
something
that
we
can
extend
as
part
of
the
network
policies
rainbow
that
here.
So
perhaps
we
can.
You
can.
A
A
C
As
part
of
them,
obviously
I
think
documentation
and
having
a
unit
testing
is
important,
so
so
I
think
I'm
already
added
such
certain
certain
work
items
in
the
issue.
There
will
be
some
inside
changes
made.
Some
changes,
schema
matching
is
an
added
edition
of
the
series,
an
API
struction
modifying
some
of
the
internal.
So
some
of
these
trucks
that
yeah,
okay.