►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Working Out SPIFFE Identity for Cilium CNI - Rahul Jadhav, Accuknox
Identity is the basis for authentication and authorization. SPIFFE provides a strong standard-based identity solution that works across heterogeneous environments. Cilium-CNI is an eBPF-powered network policy and observability solution that provides a highly scalable and performant enforcement engine that seamlessly works for L3/L4 and L7 policy enforcement. Cilium effectively uses k8s-labels as an identity for authorization policies. The SPIFFE integration with Cilium-CNI extends the notion of identity by leveraging SPIFFE provisioned identities and then subsequently using those for authorization and accounting purposes. The talk will be about: 1. Explaining/comparing identity marking/transport/representation solutions out there (for e.g., use of k8s-labels (cilium), use of TCP Fast-Open (Aporeto), and use of certificates (SPIFFE) 2. Design considerations/challenges for integrating SPIFFE identity in Cilium 3. Design considerations/challenges for leveraging SPIRE implementation 4. Extended identity use-cases that could now be targeted with Cilium-CNI. For e.g., we can now have policies based on SPIFFE IDs for edge devices outside the realm of k8s (previously, you need to have FQDN or CIDRSet based policies). 5. How is Cilium's integration different from Calico's integration?
A
Before
I
go
into
the
details
of
what
that
integration
looks
like,
I
need
to
give
a
brief
idea
about
what
celium
is
saline
is
a
kubernetes
native
of
cni,
which
leverages
ebpf
for
networking
observability
and
security.
So
evp
allows
celium
to
insert
for
dynamic
insertion
of
control
logic
at
runtime
in
the
linux
kernel.
A
Using
this
celium
make
sure
that
you
know
it
can
handle
the
network
policy
enforcement
in
a
much
more
performant
and
scalable
way.
It
does
away
with
the
use
of
ip
tables
net
filters,
which
can
very
much
limit
the
scale
of
operations
that
you
can
do
if
the
number
of
nodes
or
parts
increase
beyond
a
particular
limit,
the
the
the
number
of
iptable
rules
can
severely
limit
the
kind
of
packet
processing
that
you
can
handle
in
your
network.
A
Apart
from
that,
celium
has
a
unique
concept
of
using
identities
for
policy
enforcement
for
policy
authorization.
I'll
talk
about
that
in
this
in
the
next
slide.
With
all
this
cdm
allows
you
to
do
advanced
network
policy
enforcement,
so
celium
allows
you
to
have
l3
l4
l7
based
policy
enforcement
as
well
as
it
gives
you
detailed
visibility
into
the
flow
level
information
using
which
you
can
have
advanced
observability.
A
A
A
A
So
for
that
celium
converts
the
label
set
into
a
numeric
identity,
which
is
which,
in
turn
is
used
for
authorization
in
the
kernel
space
with
this
color
and
celium
does
away
with
the
use
of
ip
tables
and
net
filter.
Obviously,
once
you
have
an
intermediate
mapping
of
this
identity,
it
needs
to
be
synchronized
and
the
synchronization
is
achieved
using
kv
store.
A
Another
advantage
of
using
such
kind
of
numeric
identity
in
place
of
ip
addresses
is
first,
is
it
completely
decouples
your
ip
addressing
from
identity
solution
and
when
the
number
of
pods
or
number
of
nodes
increases
the
number
of
rules
that
are
used
for
policy
enforcement?
Do
not
increase
exponentially
in
case
of
iptables
based
rules?
If
you
have
a
single
node
increase,
a
single
multiple
parts
are
added
to
the
to
the
mix.
The
number
of
iptable
rules
can
exponentially
increase
this
this
this
this
particular
problem
is
not
based
by
using
ip
table
rules.
A
So
I
need
to
compare
at
a
high
level
the
components
of
identity
and
how
do
fundamentally,
celium
identity
and
speaker
identity
differs
and
then
I'll
go
into
the
integration
details
of
integration
challenges,
so
identity,
attributes
and
attestation.
That
is
the
first
component
of
any
identity
solution
in
case
of
celium.
Of
course,
kubernetes
labels
have
been
made.
Use
of.
There
is
no
explicit
attestation
procedure
there
kubernetes
itself,
the
kubernetes
control
plane
takes
care
of
kubernetes
labels
management,
and
that
is
that
is
essentially
leveraged
by
celium,
as
well
with
in
case
of
spiffy.
A
Spiffy
has
a
kubernetes
plugin,
which
allows
it
to
attest
for
kubernetes
labels
and
other
aspects
of
kubernetes,
but
that
attestation
logic
can
in
turn
be
extended
to
handle
other
other
information,
such
as
other
attributes
such
as
container
attributes.
It
could
be
container
image,
name
or
location,
for
example,
location
of
the
cluster.
A
These
attestation.
There
is
an
explicit
attestation
to
verify
these
attributes.
Then
there
is
identity,
mapping,
helium
maps,
the
identity
to
a
random
unsigned
integer,
and
this
mapping
is
kept
as
part
of
kv
store.
Does
there
is
a
synchronization
that
this
implies
that
there
is
a
synchronization
involved?
A
A
This
fire,
the
kubernetes
control
plane
itself,
serves
as
a
control
plane
for
helium
identity
when
it
comes
to
identity,
carrying
the
identity
across
to
across
the
piers
celium
achieves
it
by
making
sure
that
the
ip
cache
which
is,
which
is
a
mapping
table
to
map
pod
ip
to
identity,
is
been
made.
Using
this.
This
ip
cache
is
the
one
which
which
is
used
by
the
peers
to
identify
the
identity
of
the
remote
entity
in
case
of
spiffy
mtls
handshake
is
used
at
the
end
of
mtls
handshake.
A
Both
the
peers
know
each
other's
identity
in
the
which
is
carried
as
part
of
the
certificates,
identity.
Derivatives
does
the
idea
allocation
results
in
any
derivatives
such
as
tokens
or
credentials,
which
in
turn
can
be
used
for
other
purposes
such
as
authentication
and
encryption
in
case
of
celium?
There
is
no
such
no
such
derivatives.
A
What
was
our
need
for
spf?
The
our
primary
use
case
was
that
we
didn't
want
our
solution
to
be
binded
towards
kubernetes.
Only.
We
wanted
a
consistent
identity
that
can
span
across
ecosystem,
not
just
kubernetes
workloads
in
the
example
given
below
I'm
sure,
iot
edge,
5g,
bare
metal
and
virtual
machine,
and
we
could.
We
wanted
to
also
federate
our
identity
solution
with
third
party
service
providers.
A
Spiffy
gives
us
that
flexibility
that
we
can
think
of
all
these
scenarios
in
the
future.
There
is
a
so.
The
other
point
is
that
we
want
a
common
identity
solution
that
we
could
leverage
across
all
the
policy
enforcement
engines.
We
have
several
policy
enforcement
engineers
there's
a
network
in
the
form
of
celium
systems,
as
well
as
data
policy
enforcement
engine.
We
wanted
to
make
sure
that
there
is
a
single
identity
base
covering
all
three
of
them
and
some
advanced
use
cases
such
as
use
of
dpms
of
enclaves
for
security
station.
These
are
these.
A
In
this
case,
ny
can
attest
on
behalf
of
the
workloads,
because
it
is
part
of
the
same
c
groups
in
case
of
celium
cdm
deploys
roi
in
a
very
different
model.
It
uses
a
node
singleton
model,
wherein
there
is
just
a
single
on
y
proxy
on
the
whole
node.
All
the
user
ports
will
redirect
its
traffic
and
the
redirection
of
that
traffic
is
handled
through
ebp
of
logic.
A
So
what
the
implications
of
an
unwanted
node
singleton
model
used
by
celium?
The
first
is
that
the
spires
kubernetes
workload
attestation
model
currently
expects
that
the
association
apis
could
be
called
only
from
the
same
c.
Groups
of
that
of
the
workload
in
case
of
istio
anoy
is
part
of
the
same
part
as
that
of
the
workloads
being
a
sidecar
model,
so
it
is
able
to
attest
use
that
station
apis,
but
in
case
of
celium,
unwi
is
no
more
co-located
within
the
workload
ports,
and
thus
it
has
no
access
to
c
groups.
A
This
led
to
the
use
of
to
the
development
of
delegated
identity
apis
delegated
apis
is
what
allows
a
privileged
process.
I'll
talk
about
what
privilege
process
means.
It
allows
the
privilege
process
to
fetch
a
suite
on
behalf
of
the
workloads
outside
the
sibo.
So
in
this
case
the
celium
agent
is
a
privilege
process
and
celium
agent
could
request
suites
on
behalf
of
the
workloads
from
this
fire
agent.
A
Now,
how
do
you
ensure
so
these
are
high
security
risk
apis?
So
how
do
you
ensure
appropriate
api
access
to
this?
What
are
the
guard
rails
that
a
user
of
such
apis
needs
to
put
in
the
first
is
only
the
node
local
node.
Local
access
is
allowed
for
these
apis
by
making
use
of
a
simple
unix
domain
sockets
the
caller
has
to
be
registered
with
spire
agent.
A
That
is
a
that
is
the
requirement
here,
and
one
should
ensure
that,
as
a
user
of
this
api,
one
should
ensure
that
the
selectors
to
be
used
for
attestation
by
this
privilege
process
should
be
should
be
only
that
privileged
process.
We
should
be
able
to
attest
for
that
those
selectors.
This
is
something
that
the
user
of
this
api
is
should
keep
in
mind.
A
A
In
case
of
celium,
we
wanted
to
make
sure
that
we
used
the
same
spf
id
for
even
l3
airport,
optimization,
the
one
design
rational
that
we
we
decided
to
use
was
when
the
series,
when
the
celium
agent
gets
retrieves
a
swede
on
behalf
of
the
workload
the
celium
agent
will
in
turn
create
the
kubernetes
label.
On
behalf
of
based
on
that
suite
on
behalf
of
the
workload
now,
what
this
means
is
that,
once
the
spiffy
attestation
registration
is
done,
you
have
s
weight
and,
as
well
as
the
kubernetes
labels
for
the
corresponding
workload.
A
A
So
this
is
very
different,
so
the
l3
l4
authorization
is
very
different
from
secure
service
mesh
solutions
which
only
lose
it
elsewhere.
Other
use
case
for
us
was
to
ensure
that
all
the
non-secure
connections
are
upgraded
to
secure
connections.
We,
we
are
primarily
a
zero
trust
security
solution.
We
we
want
to
ensure
that
all
the
workloads,
all
the
espace
traffic,
is
also
secure
traffic.
A
Obviously,
as
part
of
spiffy,
one
of
the
advantages
that
you
get
certificate
provision
for
the
workload
we
could
use
this
certificate
for
tls,
origination
and
termination
given
here,
is
an
example
of
a
policy
which
could
be
used
for
tls,
origination
and
termination.
So
here
a
typical
x-wing
that
star
example
has
been
made
use
of
x-wing
and
that
star
both
of
them
are
unsecured
application,
which
means
that
they
use
http
for
communication.
A
Other
perks
of
using
spf,
of
course,
spiffy,
has
an
integrated
certificate
management
solution.
That's
a
big
plus
it
integrates
with
other
ca
providers,
which
essentially
allows
us
to
federate
with
a
third
party
service
providers.
Another
point
is
that
we,
we
are
security
solutions
providers
and
we
have
a
sas
environment,
multi-tenant,
sas
environment.
We
want
to
make
sure
that
there
is
a
hard
isolation
across
multiple
tenants
and
some
of
the
concepts
of
spires
such
as
nested
spire,
allows
us
to
do
that.
Hard
isolation
of
resources
readily
integrates
with
words
for
secret
management.
A
A
To
sum
up,
spiffy
does
provide
a
strong
identity
base
flexible
for
all
the
scenarios,
and
there
are
certain
advantages
of
integrating
speed
natively
in
celium.
One
of
the
advantage
that
I've
already
mentioned
is
apart
from
l7
authorization.
You
can
still
have
l3
l4
authorization
also
as
well
as
well
based
on
the
same
speaker
id
well,
the
integration
that
we
did
didn't
have
any
impact
on
the
data
path,
the
ebp
of
data
path,
handling
for
ceiling,
that's
a
big
plus.
A
A
A
A
A
All
the
work
item,
all
the
work
that
is
done
in
the
context
is
available
in
the
open
source,
including
all
the
design
documents.
There
is
a
github
repo
for
serial
inspire
tutorials,
which
allows
you
to
deploy
the
images,
pseleum,
spiffy,
integrated
images
and
try
out
the
policy
examples
that
are
given
given
in
the
slides
in
those
tutorials.