►
Description
Featuring Jason Skrzypek. Security is a responsibility shared by everyone. Developers and engineers alike should understand how to properly secure their applications and traffic in any environment it may be deployed. This talk will explore how to secure applications with a comprehensive look at how Cilium implements standard and extended security features.
A
A
The
tldr
of
this
presentation
is
that
I
want
to
I,
want
you
to
have
to
be
well
armed
in
your
organization,
if
you're
getting
any
pushback
from,
maybe
your
ciso
team
or
your
infrastructure
team
or
developer,
saying
that
this
is
too
complicated.
This
is
too
hard.
This
isn't
something
I
want
to
do.
These
features
aren't
available.
Psyllium
can
do
it,
and
hopefully
some
of
the
material
in
the
slides
will
convince
you
or
give
you
that
information.
A
With
that
network
security
is
going
to
be
a
is
going
to
be
a
cross-cutting
concern
for
development
operations
and
compliance.
So
it's
not
one
team
that
should
be
responsible
for
psyllium,
there's
going
to
be
crdes
and
resources
that
you
create
for
the
development
side,
there's
going
to
be
considerations
to
take
for
anything.
That's
touching
your
infra
that
down
at
the
agency
cni
level,
and
then
compliance
is
going
to
want
to
know
that
psyllium
project
is
doing
everything
it
can
to
well
be
compliant
for
that
matter.
A
So
I'll
skim
over
some
of
the
network
policy,
because
we
did
talk
about
that
a
little
bit
both
at
the
workshop
and
just
a
couple
seconds
ago,
but
there
are
a
couple
things
that
I
do
want
to
point
out
on.
The
left.
You'll
see
the
kubernetes.
This
is
kind
of
tabular
data
and
it's
really
difficult
to
read
in
white
I
apologize
for
that.
A
The
on
the
left
there's
the
things
that
are
specific
to
kubernetes
network
policy
on
the
right.
There
are
the
decisions
that
psyllium's
made
and
in
the
center
are
the
things
that
they
share.
The
one
call
out
that
I
want
to
make
is
that
psyllium
on
top
of
network
policy
gives
you
the
ability,
with
node
selectors,
to
do
host
level.
A
Firewalls
I
talked
to
those
a
little
bit
earlier
in
the
workshop,
but
that's
going
to
give
you
the
ability
to
extend
beyond
the
kubernetes
network
into
the
host
level
Network
and
provide
a
little
bit
more
security
outside
of
what
you
have,
which
is
kubernetes.
There's
also
going
to
be
down
towards
the
bottom.
A
bunch
of
matching
on
criteria.
A
So,
as
a
as
an
as
developer,
the
the
blue
gopher
is
going
to
represent
the
developer
user
story.
You
should
be
familiar,
or
at
least
able
to
create
a
network
policy,
because
it's
not
something.
That's
strictly
info
related
you're
going
to
know
what
applications
your
what
other
services
your
application,
could
communicate
with
better
than
the
infra
team
or
better
than
the
CSO
team,
and
so
it'll
help
move
the
process
along.
If
you
can
start
suggesting
some
of
the
network
policy
objects.
A
The
first
question
that
usually
comes
up,
though,
if
you're
adopting
psyllium
is
how
do
I
use
these
new
formats?
How
do
I
change
the
spec
and
to
that
there
is
a
publicly
available
editor.cellium.io
and
I'll
just
bring
that
up
to
show
you
what
that
looks
like
I
will
not
time
not
on
the
internet.
We'll
pretend
I
brought
that
up
and
it's
on
the
screen
right
now.
Basically,
it's
just
a
UI
that
gives
you
some
options.
I
want
to
select
pods
from
this
namespace
with
these
criteria,
I
want
them
to
be
able
to
communicate.
A
The
second
part
once
you've
actually
gotten
to
the
point
where
you
know
what
network
policy
you
want
you're,
going
to
also
want
to
make
sure
that
it's
working
as
attended
and
to
that
inside
each
of
the
damage
sets
I,
probably
should
have
made
a
mention
here.
You
have
the
ability
to
run
psyllium
the
CLI
with
and
monitor
the
types
of
policies
and
the
vertex
of
those
policies.
A
Here,
I
have
outlined
some
of
the
flags
that
you're
going
to
want
to
focus
on.
If
you
are
implementing
that
in
a
more
procedural
way.
The
first
one
is
that,
depending
on
whether
or
not
you're
letting
psyllium
touch
layer,
7
stuff,
you
can
specify
layer
7.
You
can
also
specify
whether
or
not
you
want
to
just
capture
all
the
drop
traffic,
because
maybe
you're
you're
not
seeing
traffic
that
should
be
should
be
allowed,
or
vice
versa,
or
all
the
accept
traffic,
because
something's
happening
that
shouldn't
be
that
shouldn't
be
happening.
A
And,
lastly,
you
can
filter
based
on
endpoints
endpoint
IDs.
We've
talked
about
endpoints
and
the
identification
system
there.
This
is
just
going
to
make
it
so
that
in
a
large
multi-tenant
cluster
environment,
you're
able
to
pin
down
exactly
what
you
want,
and
so
at
this
point
you
have
a
network
policy
you're,
pretty
comfortable
that
it
is
doing
what
it
is.
It's
supposed
to
be
doing
you
want
to.
You
can
use
that
familiarity
to
actually
go
the
opposite
way.
A
So,
let's
say
I
I
have
an
application
that
I've
been
running
for
years
and
that's
it
communicates
with
a
bunch
of
different
apps.
But
there
have
been
many
iterations.
There
have
been
many
versions
and
I'm
just
not
certain
what
should
talk
to
what
and
from
there
there
is
a
way
with
policy
Automotive
in
the
Daemon
to
determine
what
traffic
normal
behavior
is
so
to
exercise
your
application
and
then
pull
those
results
and
generate
a
network
policy
based
off
of
that.
A
A
So
this
this
would
be
a
simple
four-step
process
for
that
with
the
developer
concerned,
there
are
two
more
resources
that
are
going
to
be
relevant.
There's
a
bandwidth
manager,
the
bandwidth
manager,
you
might
ask:
how
does
how
does
the
amount
of
traffic
leaving
my
pod
impact
security,
but
I
would
respond
with
the
fact
that
we're
already
requiring
that
resources
such
as
CPU
and
memory
apply
a
good
security
posture
network
is
just
another
resource
in
your
in
your
pool,
I
mean
so
towards
the
end.
A
I
will
say
that
that
if
you
have
a
mutating
web
hook
or
a
validating
web
hook,
that
requires
some
sort
of
bandwidth.
Management
on
your
cluster,
then
you'll
be
guaranteed.
You'll,
be
better
safeguarded
against
somebody
spamming
all
the
services
in
your
cluster.
Maybe
you've
got
somebody
who's
maliciously
entered
your
cluster
and
is
just
making
it,
so
you
can't
actually
make
use
of
the
services
there.
A
I
don't
know
of
any
one
particular
Ransom
kubernetes
situation
right
now
offhand,
but
I.
Imagine
if
it's
not
happened
yet
it
will
the
way
that
this
is
enabled
I'm
going
a
little
bit
backwards
here
in
the
center
Center
column.
There
are
two
things
I
want
to
mention
here.
This
can
be
done
with
plot
annotations.
Basically,
you
specify
I
want
my
application
to
only
allow
10
megabits
per
second.
A
You
add
that
as
an
annotation
per
pod
and
that
allows
you
to
through
the
cni
restrict
traffic
as
it's
leaving
that
pod
and
then
secondly,
there's
a
more
more
sophisticated
method
called
that's
that's
about
congestion
at
your
cluster
level
and
that's
called
bbr
congestion
control.
That
requires
a
lot
more
resilient
flags
and
a
little
bit
more
tailoring
of
your
solution.
So
I
would
start
with
the
annotations
first,
but
do
know
that
you
have
a
more
cluster-wide
solution
out
there.
A
The
next
part
that
I
want
to
talk
about-
and
this
is
probably
going
to
touch
upon
more
Legacy
feature
sets-
is
that
psyllium
does
come
with
an
egress
Gateway,
meaning
that
you
can
send
all
the
traffic
that
might
be
destined
for
outside
of
your
cluster
to
a
specific
pod
in
your
cluster,
get
it
to
be
source
and
added,
and
then
all
of
the
systems
that
are
listening
for
that
specific
egress
IP
can
go
through
those
systems.
Already
at
this
point,
it's
a
little
bit
late
in
the
game.
For
this
to
be
too
relevant.
A
This
would
be
more
if
you're,
if
you're,
just
trying
to
migrate
off
of
with
a
legacy
firewall
system-
and
you
haven't,
if
you're
not
too
familiar
with
kubernetes,
but
it's
nice
to
have
this
option
out
there.
I
know
there
are
still
situations
where
people
need
to
make
sure
that
traffic
is
going
through
a
specific
static
setup,
and
this
just
facilitates
that
we've
talked
about
at
least
three
times
at
this
point
about
psyllium
identity
and
endpoints,
and
the
last
thing
that
I
want
to
just
hit
home.
A
A
Okay,
so
switching
down
to
or
putting
our
infra
hats
on,
there
is
the
option
within
psyllium
to
encrypt
all
the
traffic
right.
Now
the
leading
providers
are
going
to
be
ipsec
and
wire
regard,
but
there
are
a
lot
of
caveats
for
if
the
screen's,
not
too
readable,
I
will
go
into
a
little
bit
more
detail
with
these,
because
there
are
some
some
pretty
big
gotchas
with
ipsec.
A
I
will
point
out
that
the
this
is
all
reliant
on
what
your
infrastructure
is
already
presenting.
It's
not
something
that's
come
that
comes
bundled
with
cni.
It's
something
that
you're
going
to
have
to
implement
and
leverage
from
the
kernel
level
and
then
just
make
sure
that
cni,
the
syllium
cni
is
aware
of
that,
and
for
that
the
key
management
is
going
to
be
either
manual
deployment,
which
I
wouldn't
recommend
or
a
kubernetes
deployment
which
you
could
tie
in
something
like
Vault
or
whatever
your
secrets,
management
solution.
A
Is
there
the
second
option,
which
is
the
more
modern
option
and
probably
I,
think
probably
what
you
run
into
first
before
you
run
into
ipsec,
is
going
to
be
wireguard
wireguard
also
uses
the
same
method
where
it's
it's
going
to
assume
kernel,
but
it
does
have
the
option
to
fall
back
into
user
space.
As
you
can
see
there,
there
is
a
flag,
enable
wire
guard
user
space
fallback,
because
not
every
host
is
going
to
be
consistent.
You
might
have
in
the
provisioning
process.
You
might
have
missed
that
part
in
that
way.
A
There
are
going
to
be
caveats,
make
sure
you
read
all
the
notes
and
in
this
case,
transparent
encryption
does
not
work
with
strict
group
proxy
replacement
moving
on
a
little
bit
more
with
the
host
configuration
for
those.
This
is
more
of
a
introduction
to
the
way
that
psyllium
approaches
the
Q
proxy
replacement
I'm
on
the
left
side
of
the
screen.
A
You'll
see
the
basically
entry
level,
the
Least
Complicated
way
to
deploy
the
cni,
the
one
that's
going
to
change
the
least
the
least
about
your
cluster
and
that's
cni
chaining,
so
that
you
can
use
it
in
conjunction
with
the
pre-existing
cni
your
default
as
you
install
the
cluster
is
going
to
be
disabled
replacement,
and
so
that's
going
to
use
group
proxy
you're
going
to
have
iptables
living
alongside
the
functionality
of
evpf.
That's
default
for
a
reason.
A
There's
a
lot
of
history
with
IP
tables
and
sometimes
taking
that
out
and
swapping
in
something
completely
new
could
be
could
be
not
leaves,
are
not
good
consequences.
But,
as
you
get
familiar
with
psyllium,
you
have
the
option
to
either
do
strict,
strict
replacement
or
partial
replacement.
I
mean
I'll
start
with
strict,
because
that's
basically
a
Boolean
you
either
say
I
want
to
be
strict
or
I,
don't
want
to
be
strict
and
there
are
there's
one
Advanced
option
beyond
that,
but
partial
replacement
is
going
to
give
you
the
Spectrum.
A
A
You
can
see
the
some
of
the
flags
that
are
listed
there,
external
IPS,
socket
load,
balancers,
node
ports
and
host
ports.
You
can
choose
some
subset
of
those
with
partial
replacement
in
the
last
note.
I
make
is
that
with
strict
replacement,
there's
an
additional
flag
that
you
can
set
that
allows
you
to
new
to
bypass
net
filter
all
together
that
I
would
say,
use
with
caution.
A
A
It's
mycelium
configuration
in
conjunction
with
my
ipsec
or
my
wire
guard
or
with
the
envoy
process,
that's
running
in
my
cluster
that
I
altogether
encrypt
everything
in
a
Phipps
compliant
method
or
if
it's
compliant
way
with
all
of
our
proper
modules
and
then
I
broke
those
down.
That's
going
to
impact
both
user
space
and
kernel
space
user
space
being
making
sure
your
your
kubernetes
itself
is
a
fips
enabled
Envoy
like
I
said
there
is
the
process
running
in
the
cluster
and
then,
whichever
you
choose
between
wireguard
and
ipsec.
A
I
know
that
currently
wireguard
doesn't
have
the
ability
to
be
fips
compliant,
but
there
are
ways
to
configure,
depending
on
your
configuration,
this
isn't
going
to
work
for
everybody,
but
there
are
ways
to
make
ibsec
fips
compliant
depending
on
what
technology
you're
actually
using
there
to
support
it
me
and
so
drilling
down
into
more
of
the
compliance.
This
again
is
probably
a
little
small,
so
I'll
talk
about
the
the
spark
notes
Here,
but
any
if
you're,
probably
all
aware
that
kubernetes
is
an
open
source
project.
A
The
the
two
parts
of
that
that
I
want
to
mention
about
psyllium
is
that
psyllium
does
on
the
GitHub
repo,
have
a
security
advisory
section
that
tells
you
what
the
known
cdes
at
that
point
in
time
are,
but
they
do
not
post
any
any
of
the
specific
scanning
tool.
Solutions
out
there
I
just
just
to
inform
myself
for
this
session
did
scan
the
psyllium
Daemon
Set
pod
and
as
of
version
12.3,
it
only
has
two
medium
and
18
volt
and
we'll
talk
about
why
that
is
in
a
little
bit.
A
The
second
part,
well
I,
guess
we'll
talk
about
it.
Right
now
is
to
reduce
the
attack
surface
with
minimal
dependencies
using
images
that
might
be
scratch
if
possible
or
images
that
have
less
dependencies,
so
that
you're
not
as
Christian
said
randomly
pulling
in
Java
libraries
that
do
magical
things,
magical
and
disastrous
things.
A
You
don't
even
have
a
shell
access
to
it
so
that
one's
real
locked
out
and
last
thing.
This
is
something
you'll
hear,
probably
about
a
dozen
times
before
you
leave
kubecon
this
week
is
signature
verifications,
s-bombs
I
know
it's
a
big
thing.
Last
year
there
currently
is
an
s-bomb
generation
and
there
are
no
currently
no
signatures
on
the
psyllium
images,
but
both
of
these
are
a
work
in
progress.
A
There's
a
cncf
program
where
you
can
do
more
of
like
a
first
first
issue,
sort
of
submission
to
an
open
source
project
and
both
of
those
are
targeted
for
that
I.
Don't
know
what
the
current
this
is.
Work
in
progress
was,
as
of
last
week.
I
assume
it
hasn't
happened
in
the
last
week,
but
it
should
be
pretty
shortly
that
that's
generated
because
there's
a
there's
enough
tooling
out
there
in
the
ecosystem
right
now
that
that's
not
too
difficult
to
do.
A
I
think
this
is
I
have
two
more
slides,
also
with
compliance
going
back
to
when
I
said
resources,
it's
good
security
posture
to
make
sure
that
those
are
minimal
in
the
installation
for
the
psyllium
values
file.
You
can
see
a
bunch
of
proper
defaults,
so
the
first
one
is
that
each
of
well
they
provide
resource
limits
and
requests,
so
in
production.
A
There
is
the
ability
to
run
and
I
tested
this
a
bunch
of
times
in
the
agent
in
rootless
mode,
but
currently
the
operator
does
require
root,
but
the
that
being
less
of
a
concern,
because
we
are
running
in
a
scratch
environment
so
root
access.
We
don't
have
shell
there's
going
to
be
a
less
of
attack
of
an
attack
surface
there
and
then.
Lastly,
the
we
wanted
to
make
sure
in
any
deployment
that
you
have
proper
scoping.
This
workload
can
do
this
in
this
environment.
Can't
do
anything
else.
A
I've
come
through
all
of
the
rbac.
The
r
back
seems
properly
scoped,
there's
not
any
there's,
not
any
resource
in
there
that
isn't
actually
being
leveraged
by
the
product
by
some
feature
set.
I
will
say
with
a
caveat
there
that
if
you're
going
to
run
selenium
production,
you
might
be
depending
on
the
features
that
you
ultimately
use,
Pare,
that
down
to
a
different
set
of
our
back
rules,
but
where
they
have
about
what
they
have
by
default
is
a
good
start.
A
A
But
the
long
story
short
is
that
psyllium
is
in
fact
a
secure
product
or
it
can
be
a
secure
product.
As
long
as
you
go
into
deploying
psyllium
with
a
critical
mindset-
and
you
don't
overlook
a
lot
of
the
the
installation
components
and
what's
what's
running
under
the
hood,
there
are
there's
a
way
to
make
the
developers
The
Operators
and
the
compliance
people
all
happy
and
just
make
sure
your
environment's
well
secure
and
as
I
ended.
A
My
my
workshop
with
earlier,
if
you're
interested
in
deploying
psyllium,
some
of
you
might
aren't
even
be
running
cilium
because
it
is
becoming
something
of
a
de
facto
standard
in
Cloud
environments.
You
can
see
that
gcp
AWS
cevo
digital
ocean.
They
all
provide
psyllium
options,
otherwise
feel
free
to
try
deploying
psyllium
in
your
own
local
environments,
with
your
own
local
distribution.