►
From YouTube: Best practices for Calico security policy implementation
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 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.
A
Hi
everyone
welcome
to
this
session
on
Calico
security
policy.
Best
Practices,
my
name
is
Adil
Abdul,
majeed
I'm,
a
Solutions
architect
with
high
gear
Ross
customer
success,
team
helping
our
customers
deploy,
Calico,
Solutions,
okay,
let's
start
off
with
the
agenda
for
today's
session,
we're
going
to
be
looking
at
security
challenges
in
kubernetes
and
how
kubernetes
disrupts
traditional
networking
and
security
paradigms.
We
look
at
Calico
security
policies,
the
anatomy
of
her
Calico
security
policy
and
the
declarative
policy
language.
A
A
There
are
benefits
to
this
model.
It
alleviates
the
complexities
that
could
have
been
due
to
the
underlying
Network.
However,
the
model
also
introduces
certain
security
challenges.
Kubernetes
disrupts
traditional
networking
and
Security
paradigms
in
traditional
networks
when
security
is
enforced,
it's
done
so
at
certain
choke
points
in
the
network
and
controls
are
enforced
when
traffic,
traverses
or
transits.
Those
choke
points,
typically
using
some
form
of
networking
constructs
now
in
kubernetes,
pod
scheduling
is
dynamic,
IP
addresses
are
ephemeral
and
scheduling
is
typically
non-deterministic.
A
Okay,
what
that
means
is
you
can't
bind
a
workload
identity
to
a
networking
construct
anymore?
Also
firewalls
external,
the
cluster
cannot
map
IP
addresses
to
workload
identity.
So
when
traffic
egresses,
the
cluster
Upstream
firewalls
cannot
enforce
security
policies
based
on
IP
addresses,
because
the
IP
addresses
for
the
Pod
are
non-deterministic
with
those
challenges
also
comes
an
opportunity
and
will
look
at
Calico
a
bit
in
this
slide.
A
Policies
are
declarative,
so
Calico
offers
a
very
flexible
declarative
policy
language,
and
what
that
means
is
that
the
underlying
implementation
of
the
policy
is
abstracted
from
the
user,
the
underlying
implementation
being
the
data
planes,
for
example,
ebpf
iptables
or
windows
hns
that
is
abstracted
from
the
user.
What
the
user
gets
is
this
declarative
pulse
language
that
can
be
used
to
define
security
intentions?
Okay
and
policies
are
highly
Dynamic,
and
what
that
means
is
the
underlying
policy.
A
Implementation
in
the
data
plane
is
for
every
pod
in
the
cluster,
so
as
pods
are
created,
so
are
policies
and
as
pods
move,
so
do
the
policies,
so
the
policies
are
highly
Dynamic,
but
you
as
a
user.
You
only
have
to
specify
the
security
intention
using
the
declare.
Deposit,
language
and
Calico
will
take
care
of
the
underlying
policy
implementation
using
a
data
plane
of
your
choosing
okay.
So
these
are
some
of
the
characteristics
of
security
policies.
A
However,
Calico
offers
several
more
extensions
than
what's
available
in
Native
kubernetes
policies
and
policy
ordering
being
one
of
those,
and
we
look
at
how
you
could
leverage
policy
ordering
when
building
a
policy
model
policies
can
be
applied
to
any
kind
of
endpoint
being
pods,
VMS
or
hosts
external
to
the
cluster.
Okay
and
policy
rules
support
a
love
deny
log
and
past
actions.
A
A
A
Now,
there's
a
lot
going
on
in
this
slide
and
it's
not
possible
to
cover
all
the
policy
features
in
a
single
session.
So
in
this
session,
we're
going
to
focus
on
policies
for
pods
and
containers
all
right,
we're
not
going
to
be
discussing
about
policies
for
host
endpoints
or
VMS,
or
policies
for
nodes
outside
the
cluster
and
in
terms
of
actions.
We're
primarily
going
to
be
focusing
on
the
a
love
and
deny
action,
we're
also
not
going
to
be
discussing
about
the
optional
packet
handling
capabilities.
A
A
A
A
Now
a
policy
is
going
to
have
one
or
more
Ingress
and
or
egress
rules,
and
if
you
look
at
a
particular
rule
in
a
rule,
you
could
have
either
an
a
love,
deny
log
or
pass
action
and
in
an
egress
rule.
If
you
look
at
the
destination,
there's
a
two
field
there,
where
you
could
specify
the
destination
and
the
destination
protocol,
there's
also
a
front
field
there
that
you
can
use
to
specify
the
source.
Now,
when
specifying
The
Source
again,
you
can
use
endpoint,
selectors
or
namespace
selectors
service
accounts
could
be
networks.
A
Network
sets
of
global
network
sets
now
network
sets
and
Global.
Network
sets
are
a
way
of
grouping
either
IP
addresses
or
cider
blocks,
and
it
will
explore
some
examples
in
the
subsequent
slides
when
it
comes
to
protocols.
Again,
we
look
at
some
protocols
in
the
previous
slide.
For
example,
you
could
choose
between
TCP
UDP
icmp,
even
HTTP
match,
if
you're
using
layer,
7
policies
all
right,
so
quite
a
bit
going
on
here
right
just
park
this
for
the
moment,
I
think
we'll
be
able
to
bring
this
together.
A
A
Alrighty
so
before
we
look
at
some
examples,
let's
look
at
security
policy
Behavior
now,
if
no
network
policies
or
Global
Network
policies
for
that
matter
are
applied
to
a
pod,
then
all
traffic
to
and
from
that
pod
is
a
love.
So
by
default,
if
a
network
policy
is
not
applied
to
a
workload,
all
traffic
is
a
love.
That's
that's
a
default
whitelist
behavior
in
kubernetes.
A
If
one
or
more
Network
policies
apply
to
a
pod
containing
egress
rules,
then
only
egress
traffic,
specifically
Allowed
by
those
policies,
is
allowed
for
those
endpoints.
What
this
simply
means
is
that,
once
the
end
point
is
matched
by
a
policy,
only
flows
are
loved
by
that
policy
or
any
other.
Subsequent
policy
is
allowed
for
that
endpoint.
A
A
A
So
inside
the
policy
you
can
have
one
or
more
either
Ingress
and
or
egress
rules,
and
you
should
look
at
using
rules
for
a
given
workload
or
a
group
of
workload
and
making
sure
that
you
have
a
single
policy
for
those
workloads
with
multiple
rules.
Okay,
Implement,
a
hierarchical
design
that
allows
for
optimizing
the
number
of
security
policies
by
filtering
out
non-compliant
Flows
at
the
top
of
the
funnel.
A
When
we
look
at
the
policy
model
in
subsequent
slides,
you
will
look
at
how,
for
example,
Global
Network
policies
are
used
to
implement
certain
high-level
controls
so
that
we
can
filter
out
unwanted
or
non-compliant
Flows
at
the
top
of
the
funnel
use,
Global
Network
policies
to
implement
high-level,
guardrails
and
network
policies
to
implement
fine-grained
controls.
Okay,
so
Global
Network
policies
are
what
spans
across
multiple
namespaces
or
even
all
the
workloads
in
the
cluster.
A
So
you
could
use
Global
Network
policies
to
enforce
high-level
security
intentions
and
network
policies
for
fine
grain
controls
that
apply
to
very
specific
workloads,
leverage
policy
order
with
allow
and
deny
actions
When,
developing
security
policies
right.
This
is
a
powerful
capability
in
Calico
policies,
also
use
network
sets
and
Global
Network
sets
to
group
IPS
and
Sliders
so
that
there
could
be
referenced
by
even
multiple
policies.
Okay,
it's
just
a
bit
more
efficient
doing
it
that
way,
right.
So,
with
these
best
practices
in
mind,
let's
look
at
some
example:
security
policy
patterns.
A
This
particular
cluster
has
two
tenants
and
a
tenant
is
simply
a
logical
isolation,
so
it
could
be
any
form
of
logical
isolation,
for
example,
in
your
environment
could
be
a
PCI
environment
that
you'd
like
to
isolate
from
the
rest
of
the
cluster
workloads.
If
you're
a
hosting
provider,
then
could
be
a
customer.
So
if
you
have
multiple
customers,
you
have
to
make
sure
that
they
remain
isolated
in
a
shared
cluster.
A
Also,
if
you're
having
a
shared
cluster,
that's
shared
between
various
development
teams,
you
may
want
to
have
illogical
isolation.
All
right
so
tenant
is
any
form
of
logical
isolation
that
you'd
like
to
create
for
your
class
and
our
tenant
could
have
one
or
more
namespaces.
So,
for
example,
in
this
cluster
tenant,
one
has
two
name
spaces.
It's
a
shop
and
Yao
bank
and
tenant
2
has
a
single
namespace
called
book
info.
Okay.
A
Now
the
applications
in
these
tenants
are
exposed
using
an
Ingress
controller
in
the
Ingress
nginx
namespace
right.
So
hopefully,
this
cluster
is
similar
to
your
environment.
Of
course
you
could
horizontally
scale.
You
can
have
more
tenants
more
name
spaces,
but
the
pattern
hopefully,
is
similar
to
your
environments.
Okay,.
A
A
So
my
my
first
policy
is
a
denialist
policy
and
the
denialist
policy
is
a
Calico
Global
Network
policies
which
applies
to
all
cluster
endpoints,
more
the
reason
for
that
default
or
love.
So
now,
I
have
a
policy
that
applies
to
all
cluster
endpoints.
What
that
means
is
all
cluster
endpoints
now
have
a
default
deny
Behavior
for
egress
traffic,
since
this
policy
matches
equals
traffic
okay.
A
So
this
policy
has
egress
an
egress
rule
which
denies
traffic
two
IPS
insiders
in
the
IP
deny
list
Global,
Network
set
and
I've
shown.
The
global
network
sets
on
the
right
hand,
side
as
well
now
recall
that
Global
Network
sets
are
a
way
of
organizing
could
be
IPS
or
cider
blocks
and
referencing
those
in
policies.
A
So
what
this
policy
does
is,
if
any
of
the
cluster
workloads
try
to
connect
to
the
IP
addresses
specified
in
This
Global
Network
set.
Those
flows
are
going
to
be
denied
by
this
policy.
So,
for
example,
if
you
could
retrieve
these
IPS
from
a
thread
feed
and
update
up
and
update
the
global
Network
set,
then
you
could
effectively
deny
all
cluster
workloads
access
to
those
malicious
IP
addresses.
Okay.
A
Now,
if
you
look
at
the
actual
underlying
policy
implementation,
the
policy
is
implemented
for
every
endpoint
in
the
cluster,
using
the
data
plane.
Okay,
however,
for
Simplicity
I've,
grouped
all
the
endpoints
and
shown
that
traffic
is
denied
in
the
IP
deny
list.
Global
Network
set
okay,
all
right,
so
this
is
the
first
example.
Let's
move
on.
A
The
second
example
is
the
cube
DNS
policy.
Now
the
qbns
policy
is
a
Global
Network
policy
which
applies
to
all
cluster
endpoints.
It
has
an
Ingress
rule
which
allows
DNS
traffic
from
all
endpoints
to
cube.
Dns
has
an
egress
rule
which
allows
DNS
traffic
from
all
in
points
to
cube
DNS.
The
selector
field
is
used
to
match
the
qbns
endpoints
using
the
KH
app
equals
qdns
label.
A
A
A
A
A
Okay,
let's
look
at
the
next
policy.
This
policy
is
called
tenant,
one
restrict
so
this
is
the
Calico
Global
Network
policy,
which
applies
to
all
cluster
endpoints
in
tenant.
One.
The
namespace
selector
field
is
used
in
the
security
policy,
with
the
project
calico.org
forward,
slash
name
label
to
select
endpoints
in
the
tenant,
1
namespaces
as
an
Ingress
rule
which
denies
all
traffic,
except
from
the
specified
namespaces.
A
As
an
egress
rule,
which
denies
traffic
except
to
the
specified
namespaces
and
the
not
selected
field,
is
used
in
Ingress
and
egress
rules
with
the
project
calico.org
or
forward
slash
namespace
label
to
exempt
endpoints.
That
should
not
be
denied
okay.
So
this
is
a
Global
Network
policy
and
in
the
policy.
A
And
in
the
policy,
the
namespace
selector
is
used
to
specify
the
Hipster
shop
and
Yao
Bank
name
spaces.
So
this
policy
applies
to
the
heater
shop
and
Yahoo
Bank
endpoints
in
the
Ingress
direction.
There's
a
deny
action,
however.
The
not
selector
is
used
to
exempt
the
endpoints
that
should
not
be
denied.
A
A
A
A
A
So
this
policy
does
not
permit
any
traffic
right.
Given
that
you've
specified
a
policy
for
tenant,
one
restrict
a
subsequent
policy
must
permit
traffic
flows
that
should
be
permitted
for
tenant.
One
workloads.
Okay,
all
this
policy
does
is
it
isolates
the
101
workloads
and
denies
traffic
to
all
other
cluster
endpoints,
except
for
what's
Exempted
using
the
not
selectors
in
the
rule.
A
Now
we're
going
to
have
a
similar
policy
for
tenants
2
as
well
again,
a
Global
Network
policy
using
the
namespace
selector
with
project
calico.org
forward,
slash
name
label
to
select
the
10
and
2
endpoints
has
Ingress
and
egress
rules
again
with
not
selectors
using
the
project.
Calico.Org
forward
slash
namespace
label
to
exempt
endpoints
that
should
not
be
denied
so
similar
to
the
previous
rule.
A
You
know
the
book
info
and
the
Ingress
and
nginx
namespaces
are
Exempted
now,
of
course,
we're
exempting
the
Ingress
nginx
namespace,
even
in
the
previous
case,
because
the
applications
are
exposed
via
that
namespace.
Okay,
so
we'd
expect
to
receive
inbound
traffic
from
that
namespace
again,
we
are
not
permitting
that
traffic
and
we
look
at
subsequent
policies.
You
will
see
how
traffic
from
Ingress
nginx
is
permitted
to
workloads
that
are
exposed
to
external
consumers.
A
A
All
right
so
now
we
have
a
policy
called
the
front-end
policy.
Now
the
front-end
policy
is
a
network
policy
which
applies
to
the
front-end
endpoints
in
the
Hipster
shop
namespace
in
tenant
one
now
the
selected
field
is
used
to
select
the
front-end
endpoints
using
the
app
equals.
Front-End
label
has
an
Ingress
rule
which
permits
traffic
from
the
Ingress
controller.
A
So
let's
go
through
this
policy
a
bit.
This
is
a
network
policy,
which
means
it
applies
to
a
specific
namespace,
a
namespace
being
the
Hipster
shop
namespace.
However,
in
the
policy
we're
using
an
endpoint
selector,
so
we're
using
the
select
a
field
and
using
the
app
equals
front-end
label.
What
this
means
is
that
the
policy
applies
only
to
the
front-end
endpoints.
Okay
in
the
Ingress
Direction
You
Know,
by
using
a
namespace
selector
to
select
the
Ingress
nginx
namespace.
A
A
So
when
you're
using
selectors
and
when
you're
using
labels,
you
could
use
and
or
not,
operators
in
this
case
we're
using
an
N
operator
to
make
sure
that
the
controller
has
two
labels
and
that's
how
we
are
identifying
the
Ingress
controller
for
in
this
particular
rule.
Okay,
now
in
the
egress
Direction
front,
end
is
sending
traffic
to
add
service.
So
we
specify
the
port
here
similarly
sending
traffic
to
checkout
service.
Now
this
rule
continues
I've
truncated,
the
rule.
What's
important
is
not
the
number
of
services
it's
talking
to
in
the
same
namespace.
A
There
is
quite
a
bit
of
them
for
this
particular
application,
but
the
idea
being
that
the
pattern
is
is
the
same
it
kind
of
repeats
and
what
we're
doing
is
given
that
this
policy
applies
to
the
Hipster
shop.
Namespace
we're
using
the
selector
field
to
select
other
workloads
at
the
front-end
workload
can
communicate
with
in
the
same
namespace.
A
So
if
you
have
to
visualize
this
policy,
you
know
we
have
the
front-end
endpoints
and
in
the
English
Direction
we've
created
a
pinhole
so
that
the
front
and
end
points
can
receive
traffic
from
Ingress
nginx
and
on
the
egress
deduction.
We've
created
a
pinhole
so
that
the
front
end
endpoints
can
send
traffic
to
other
services
in
the
same
namespace.
A
A
The
selector
field
is
used
in
the
security
policy
to
select
checkout
services
endpoints
using
the
app
equals
checkout
service
label
has
an
Ingress
rule
with
a
select
a
field
to
select
the
front-end
endpoints
using
the
app
equals
front-end
label
and
several
egress
rules
with
the
selected
field.
Matching
apicals
X
labels
to
select
other
endpoints
in
the
same
namespace.
The
checkout
service
endpoints
would
need
to
communicate
with
all
right.
So
in
this
example,
the
policy
is
a
network
policy
very
similar
to
the
policy
we
saw
for
the
front-end
service.
A
However,
if
you
recall
the
previous
policy,
the
egress
pinhole
for
the
front-end
endpoints
were
created
in
the
front-end
policy.
Okay,
so
now,
with
this
policy,
we
now
have
end-to-end
communication
or
the
end-to-end
flow
from
the
front
end
to
checkout,
permitted.
Okay
and
the
checkout
service.
Endpoint
has
an
egress
rule
so
pinhole
in
the
egress
direction,
for
the
checkout
services
endpoint
to
permitting
it
or
allowing
it
to
communicate
with
the
other
endpoints
in
the
same
namespace
that
it
should
be
able
to
communicate
with
okay
again,
the
same
logic
holes
right.
A
So,
for
example,
if
it's
communicating
with
payment
services
in
the
policy
that
we
have
for
payment
services,
we've
got
to
make
sure
that
that
flow
is
allowed
in
the
inbound
Direction.
Okay.
So
the
policies
we're
developing
for
the
Hipster
shop
namespace,
a
very
fine-grained
granular
policies
right.
The
policies
apply
to
select
endpoints
endpoints,
representing
a
particular
microservice
and
for
those
endpoints
we're
applying
rules
in
both
the
inbound
and
the
outbound
directions
right.
So
these
are
very
granular
policies.
A
Okay,
now,
of
course,
for
the
checkout
service,
we're
not
permitting
traffic
from
the
Ingress,
because
it's
the
front
end
that
communicates
or
the
front
end
that
receives
traffic
from
the
Ingress
okay.
However,
the
checkout
service
will
receive
traffic
from
front
end
and
on
the
egress
Direction
communicate
with
other
microservices
or
endpoints
in
the
same
namespace
all
right.
So,
let's
move
forward
so
I've
not
shown
the
rest
of
the
policies
for
the
Hipster
shop
namespace.
A
Those
policies
you
know
will
continue,
however,
the
pattern
Remains,
the
Same
okay,
so
assuming
that
we've
completed
the
policies
for
the
Hipster
shop
namespace.
Let's
now
look
at
the
policy
for
the
yaw
Bank
namespace.
This
policy
is
a
network
policy
which
applies
to
all
endpoints
in
the
Yahoo.
Bank
namespace
has
an
Ingress
rule
which
permits
traffic
from
the
Ingress
controller.
A
The
namespace
selector
field
is
used
in
the
rule
with
the
project
calico.org
name
label
to
select
the
Ingress
nginx
namespace
and
the
selector
field
is
used
with
multiple
labels
to
select
the
Ingress
controller
traffic
permitted
to
the
customer.
Endpoints
using
a
selector
with
label
equals
app
equals
customer
label.
A
Now
the
policy
also
has
an
Ingress
rule
which
permits
traffic
from
all
other
endpoints
in
the
same
namespace
using
the
selector
field
with
the
all
match
operator
similar.
It
also
has
an
egress
rule
which
permits
traffic
to
all
endpoints
in
the
same
namespace
using
the
selector
field
with
the
all
match
operator.
A
So
this
is
a
interesting
pattern,
so
very
similar
to
the
front-end
policy.
We
looked
at,
however,
with
a
distinction,
so
this
is
a
network
policy
applies
to
the
Yahoo
bank
namespace
and
in
the
Ingress
direction.
If
you
look
at
the
rule,
given
that
this
policy
applies
to
all
endpoints
in
the
Yahoo
Bank
namespace
we've
not
specified
a
selector
and
what
that
means
is
all
endpoints
in
the
namespace
are
matched
for
this
policy.
A
A
A
If
you
look
at
the
second
Ingress
rule,
what
this
means
is
that
all
endpoints
in
the
Yahoo
Bank
namespace
can
receive
traffic
from
all
other
endpoints
in
the
Yao
Bank
namespace,
given
that
this
is
a
network
policy
and
we've
not
specified
selectors,
all
endpoints
can
receive
traffic
from
all
other
endpoints
and
the
egress
rule
is
similar
to
that
as
well.
There
are
no
selectors,
and
what
this
means
is
that
all
endpoints
can
send
traffic
to
all
other
endpoints
in
the
Yahoo
Bank
namespace.
A
So
this
is
what
the
pattern
looks
like.
The
Ingress
nginx
can
send
traffic
to
the
customer.
Endpoints
that's
governed
by
the
first
rule
in
the
Ingress
Direction.
However,
the
endpoints
within
the
namespace
can
freely
talk
to
each
other
since
we've
permitted
or
Alive
outbound
and
inbound
Communications
from
all
endpoints
in
the
same
namespace.
A
A
Now
this
differs
from
the
policy
we
created,
for
you
know
front-end
and
checkout,
and
the
services
in
the
Hipster
shop
namespace,
because
those
policies
were
very
specific
to
a
group
of
endpoints
within
the
same
name,
so
it's
an
even
when
they
had
to
communicate
with
other
endpoints
in
the
same
namespace
it
had
to
be
explicitly
permitted
using
rules
or
policies
all
right,
so
moving
on
to
the
booking
for
policy
very
similar
to
the
Yahoo
bank.
It's
a
very
similar
pattern.
Again.
A
A
So
it's
not
important
that
you
kind
of
understand
all
the
microservices
involved
in
some
of
these
examples.
The
idea
is
that
you
understand
the
pattern
right
so
in
in
the
Yahoo
Bank
example,
it
was
the
customer
endpoint
that
was
exposed
to
external
consumers
and
in
the
bookie,
for
example,
it's
the
product
page
in
points,
that's
exposed
to
excel
consumers
and
those
are
the
endpoints
that
have
the
pinhole
in
the
Ingress
Direction,
permitting
traffic
from
the
Ingress
controller
foreign.
A
So
we've
looked
at
a
few
policy
patterns
right,
so
we
started
off
with
the
deny
list.
We
had
a
pattern
for
cube:
DNS,
build
policies
to
restrict
tenant,
one
enter
into
workloads.
We
looked
at
some
granular
policies
for
the
endpoints
in
the
Hipster
shop
namespace
and
then
look
at
some
core
screen
policies
for
your
back
and
book
info.
Once
you
are
done,
building
policies
for
a
certain
set
of
namespaces.
You
could
then
enforce
a
default
deny
for
those
namespaces.
A
So
in
this
case
we
are
first
enforcing
our
default
deny
for
tenant
one,
and
what
this
says
is
that
deny
all
traffic
in
the
Ingress
and
increase
directions
for
the
tenant
one
workloads.
This
policy
is
a
Global
Network
policies
and
the
workloads
identified
using
the
namespace
selector.
In
this
case,
we'll
match
the
heaps
of
shop
and
Yahoo
Bank
namespaces.
A
Similarly,
we
have
a
10
and
2
default
deny
very
similar
logic.
It's
a
Global
Network
policy,
we've
matched
the
namespaces
using
a
namespace
select
in
this
case.
It's
just
a
booking
for
namespace
and
all
Ingress
and
egress
traffic
is
denied
all
right.
So
hopefully,
now
you
understand
the
reason
for
this
default
deny
right.
Sorry
default
a
love.
If
you
look
at
this
policy
model,
I
have
policies
where
we've
matched
all
the
endpoints
in
the
cluster,
for
example
Cube
DNS.
A
However,
we've
not
built
all
the
policies
for
all
the
endpoints
in
the
cluster
right
and
what
this
means
is
that
if
that
default
deny
sorry
the
default
love
wasn't
there
right.
I
would
be
denying
all
other
flows
in
the
cluster.
So
the
idea
being
that
you
take
a
progressive
approach,
When
developing
your
policy
model,
you
may
want
to
restrict
certain
environments.
So
in
this
case,
assuming
that
doesn't
want
the
tenants
were
actually
customers
you'd
want
to
secure
those
custom
environments
and
isolate
them
from
the
rest
of
the
cluster.
A
So
that's
what
we've
done
and
now
you
can
continue
with
the
rest
of
the
policy
development.
However,
hopefully,
the
patterns
that
we've
shown
with
the
global
Network
policies
and
network
policies
and
how
environments
were
isolated
from
the
rest
of
the
cluster,
the
course
Grant
policies
and
the
fine
grain
policies.
Hopefully
those
patterns
help
you
think
about
how
you
should
be
approaching
policies
for
your
environments,.
A
All
right
so,
with
the
policy
model
build
now
you're
in
a
position
you
know
to
introduce
security
policy,
governance,
okay
and
when
you're
thinking
about
governance,
you
know
you've
got
to
think
in
terms
of
policy
model
rather
than
individual
policies
and
Leverage
security
policy,
ordering
role-based
access,
control
and
admission
control
to
enforce
policy
governance.
Okay,
for
example.
If
application
developers
are
authoring
policies
and
if
they're
auditing
policies
for
a
particular
namespace,
you
could,
for
example,
assign
a
certain
order
for
the
policies
that
they
are
allowed
to.
Author.
A
Okay,
that
kind
of
ensures
that
they're
not
able
to
circumvent
high
level
controls
and
you
have
enforced,
for
example,
controls
such
as
restrict
and
the
deny
list,
maybe
under
the
purview
of
the
security
team,
and
when
you
are
permitting
other
authors
to
apply
policies,
you
may
wanna
have
some
governance
around
that
and
policy.
Ordering
is
a
feature
that
you
could
use
to
create
a
governance
structure.
A
Alrighty,
so
there's
a
lot
going
on
in
our
Calico
pulse
and
I.
Think
we've
simply
scratched
the
surface
here.
The
best
place
to
understand
all
the
features,
all
the
capabilities.
All
the
fields
and
operators
available
in
a
Calico
policy
is
to
refer
to
the
documentation
of
put
the
link
here
to
the
network
policy
and
the
global
Network
policy
documentation
for
project
Calico,
all
right.
So
with
that
you
know,
let's
talk
a
bit
about
calico,
Enterprise
and
Calico
cloud.
Calico
OSS
is
the
foundation
for
Calico
Enterprise
and
Calico
Cloud.
A
We
look
at
the
policy
features
in
Calico
OSS
and
Calico
Enterprise
and
Cloud
Builds
on
top
of
this
and
offers
certain
Advanced
security
policy
features.
For
example,
you
could
use
policy
tiering.
So
when
we
build
policies
this
time
policy
model
was
in
a
single
tier
with
calculate
the
price
and
Cloud.
You
have
the
option
to
have
multiple
policy
tiers.
A
There's
a
policy
UI
editor,
a
policy
recommender
to
suggest
policies
based
on
active
flows
in
the
cluster
policy,
dashboards
with
Prometheus
metrics
policy,
auditing,
login
capabilities
and
endpoint
browser
to
identify
which
policies
are
applied
to
certain
endpoints
for
service
graph
to
identify
and
understand
a
security
policy
evaluation
flow
visualization
for
troubleshooting
and
compliance
reporting,
so
add-on
functionality.
However,
the
functionality
provided
by
Calico
OSS
Remains
the
foundation
for
this
additional
capabilities.
A
All
right
with
that
I
think
we're
going
to
wrap
this
session
again
thanks
for
your
time,
I
hope
it
was
beneficial
for
more
information.
You
can
find
us
on
the
project.
Calico,
slack
Channel
and
also
the
project
category
documentation
for
further
information
around
some
of
the
policies
and
the
policy
features
that
we
discussed
in
this
session.
A
With
that,
thanks
for
watching
I
hope
you
have
a
good
rest
of
the
day.
Thank
you.