►
From YouTube: Cloud Native Austin - Securing the Mesh
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Very
good
we
are
getting
set
up
to
be
live
streamed,
actually,
which
is
maybe
the
only
nice
thing
other
than
heim
being
here
about
today's
meetup,
so
so
anyway,
welcome
everyone,
for
you
know
thank
you
for
coming
we're
getting
kicked
off
late
because
because
well
either
it's
my
lack
of
confidence
with
zoom
or
some
funky
setting
about
approving
registrations
either
way
we're
going
to
spend
the
next
50
minutes
to
an
hour,
or
so
talking
about
service
meshes
and
security.
A
Tonight's
speaker,
we've
just
got
one
talk
tonight.
We're
gonna
spend
a
little
bit
of
time,
socializing
here
and
then
we're
gonna
have
a
talk
from
heim
hellman
he's
the
cto
at
carbon
black
app
security
at
organizational
unit
at
vmware.
He'll
talk
to
us.
A
His
talk
will
be
in
infused
devsecops
into
your
kubernetes
and
service
mesh
life
cycle.
Briefly.
Actually
I
don't
know
that
we
need
to
cover
this
because
I
think
I
see
all
friendly
faces
tonight.
All
folks
who've
been
here
before
so
this
is
the
cloud
native
austin
meetup.
It's
s,
sort
of
it's
well,
the
I
think
the
second
in
the
world.
If
I
get
it
right,
that's
been
sponsored
by
the
cncf
kind
of
the
first
one
of
the
first
to
go
into
the
fold.
A
If
you
will-
and
I
think
that
that
had
something
to
do
with
the
fact
that
we're
here
in
austin-
and
so
are
some
other
execs
at
the
linux
foundation
anyway,
we're
very
much
open
source
centric
in
our
topics
and
our
topics
have
been
fairly
oriented
toward
service
mesh
recently
and
that's
almost
entirely
a
factor
of
the
the
fact
that
there
are
not
that
many
people
raising
their
hand
to
speak,
which
means
you
all
get
to
listen
to
me,
which
means
service
mesh
things.
A
So
we're
not
at
a
you
know
a
physical
venue.
We
don't
have
food,
but
we
just
have
kind
of
sponsorship,
of
the
zoom
and
of
organizing.
So
so,
we've
got
layer,
five,
the
service
mesh
community
and
the
cncf
the
cloud
native
computing
foundation
that
are
sponsoring
tonight's
meetup.
A
Let's
take
a
moment
if
we
would
so
usually
we're
meeting
kind
of
physically
and
that's
typically
with
people
who
are
based
in
and
around
the
austin
texas
area,
but
we're
not
bound
to
those
physical.
You
know
walls
anymore,
rather
we're
bringing
together.
I
think
people
who
are
just
generally
interested
in
the
same
topic,
sort
of
irrespective
of
where
you're
coming
from
so
if
we
can
it'd
be
nice
to
exchange
a
little
bit
tonight
to.
A
B
C
B
D
I'll
get
I
mean
we
don't
we're,
not
hiring
we're
always
looking,
but
unfortunately
with
code,
we're
not
hiring
right
now,
but
our
company
is
moving
to
kind
of
kubernetes
environment
for
all
of
our
products.
So
that's
why
I
decided
to
come
here
tonight
kind
of
learn
a
little
bit
more
about
service
mesh
and
securing
service
mesh,
we're
using
istio
right
now
as
our
service
mesh.
So
I'm
still
new
to
that,
but
excited
for
the
content
later.
A
Yeah
totally
brighter
thanks
for
that.
Well
now
now
that
begs
some
you've
come
to
the
right
meetup
by
the
way
like
you're
you're
you're
in
the
place
man.
This
is
good.
What's
the
you
might
have
said
it
and
I
probably
missed
it,
but
what's
the
name
of
the
place
that
you're
at.
D
Yeah,
so
I
work
for
a
company
called
applied
systems,
they're
they're
kind
of
more
of
a
national
company,
they're
not
based
out
of
austin,
but
we
do
have
offices
in
austin
and
some
other
big
cities
and
we're
kind
of
that
classic
dinosaur
insurance
software
company
and
so
there's
been
a
recent
change
in
kind
of
the
leadership,
especially
the
technical
leadership
at
our
company,
and
so
we're
trying
to
move
away
from
30
million
lines
of
vb.net
running
windows,
thin
clients
to
a
more
kind
of
open
standard
and
and
then
also
updating
all
of
our
infrastructure
around
that
so
having
more
public,
api's
and
microservices
architecture
and
so
changing
the
whole
model
of
how
we
do
software.
D
And
so
it's
a
big
journey.
Our
team,
my
team,
specifically,
is
involved
in
a
lot
of
the
analytics
like
analytics
products
around
that.
So
that's
kind
of
what
I'm
looking
to
to
learn
a
lot
more
about,
specifically,
is
how
this
kind
of
plays
into
I'm
not
going
to
say
big
data,
but
those
kinds
of
solutions
to
to
problems.
A
I
my
hat's
off
to
you
and
the
the
being
being
kind
of
a
part
of
a
transformation
like
that
and
well
you
I
think
journey
was
the
right
word.
Some
it's
yeah.
You
may
have
more
patience
than
me.
D
Yeah
yeah:
it's
definitely
a
lot
of
people
making
a
lot
of
really
good
big
decisions,
so
we'll
we'll
see
how
it
all
plays
out,
I'm
sure
we'll
make
some
mistakes,
but
as
long
as
we're
making
forward
progress,
that's
good.
A
A
A
While
he,
while
bradley's
looking
I'll
I'll
share
this
another
kind
of
relevant
topic,
is
events
top
of
mind,
for
me
is
kubecon
eu,
which
has
gone
virtual.
I
think
it's
going
to
be
held
in
amsterdam
a
while
ago,
amsterdam
right,
yeah
and
now
is.
I
was
virtual.
Are
you
speaking
at
this
one
as
well.
C
A
Nice,
okay,
very
good.
Well,
there's
a
is
anyone
else,
I'm
speaking
at
this
event,
or
does
anyone
know
of
other
relevant
events
that
we
should
be
tuned
into.
E
A
Sure
yeah
anybody
attended
some
virtual
events
here
recently
and
thought
that
they
were
pretty
well
done,
like
the
platform
that
was
being
used,
was
sort
of
facilitated
the
the
the
hallway
meet
and
greet
the
social
aspect
of
it.
I've
been
to
a
couple,
and
I
don't
know
that
you
know
they
were
you
know
it
was
still
like
half
the
experience
you
get
well
like
a
quarter
of
the
experience
that
you
actually
get
in
person.
That's
right.
E
A
Well,
yeah,
I've
done
a
couple
last
one
I
was
at
was.
I
was
speaking
at
all
things
open,
which
was
actually
supposed
to
be
here
in
austin
a
little
while
ago
and
they
didn't,
but
they
held
it
virtually,
and
I
forget
the
name
of
the
platform
they
had,
but
they
they
part
of
what
they'd
done
was
a
little
bit
of
speed
networking
which,
for
someone
as
long
winded
as
me,
is
quite
the
challenge,
but
people
are
generally
pretty
friendly,
it's
kind
of
a
nice
way
to
anyway.
A
For
me,
I'm
giving
two
talks
at
kubecon,
eu
and-
and
I
think
I'm
supposed
to
record
him
next
week-
maybe
I
should
actually
start
there's
too
much
going
on,
which
is
why
I'm
super
excited
that
I'm
not
speaking
tonight
rather,
this
fine
gentleman
here
is
heim
is
a
number
of
things,
someone
some
a
friend
actually
someone.
I
I've
really
enjoyed
over
the
last
few
years,
just
tickled
to
see
heim's
company
be
acquired.
A
C
It's
it's
actually,
it's
very
exciting.
It's
it's.
A
huge
opportunity,
vmware
is,
is
moving
very
rapidly
and
with
great
commitment
on
on
both
the
kubernetes
direction
and
to
become
a
leading
security
vendor.
C
So
we're
kind
of
the
where
those
two
lines
meet,
and
there
are
so
many
efforts
in
vmware
with
the
pivotal
and
heptio
acquisitions,
around
kubernetes
and
with
the
carbon
black
last
line
acquisition,
as
well
as
doctoring
around
security,
so
we're
trying
to
bring
it
all
together
to
kind
of
create
a
cohesive
story
around
intrinsic
security
for
cloud
native-
and
this
is
it's-
it's
a
very
large
organization,
but
it's
all
very
nascent.
It's
all
young
and
fresh,
and
it's
exciting
yeah.
A
Wow,
okay,
yeah.
That
is
exciting,
because
it
would
be
some
opposite
words
that
I
would
use
to
describe
large
corporate
technology
organization
and-
and
I
totally
believe
you
that
it's
not
particularly
for
for
any
number
of
reasons
and
and
that
the
way
that
you've
described
it
yeah,
you
guys,
you
know
formally
octorine
like
right,
bridging
the
divide
between
those
those
two
exact
things.
So
that's
a
perfect
lead-in
into
into
hearing
more
from
you
just
kind
of
about
this.
This
subject
I'll
give
you
a
moment
to
share
so.
A
Well,
this
is
com,
I
have
to
say
brian
encouraged,
to
hear
you
guys
have
a
mesh
deployed
and
istio
specifically
has
been
a
focus
of
of
heims,
and
we
might
hear
some
istio
specific
things
tonight.
I
don't
know
which
is
good
because
that'd
otherwise
spoil
the
surprise.
A
It's
that
particular
service
mesh
has
also
been
a
focus
of
mine,
along
with
all
the
rest
of
them.
So
I'll
have
to
have
to
hear
more
about
some
of
your
experiences,
some
how
it's
going
for
you
guys.
D
It's
definitely
an
area
I
need
to
educate
myself
in
more.
I
feel
like
it's
one
of
those
things
that
you
kind
of
use
some
of
the
generally
more
popular
features,
but
then
there's
a
whole
layer
of
really
really
clean
architecture.
You
can
pull
off
if
you
use
the
service
mesh
in
the
right
way,
which
is
kind
of
an
area
I'm
not
totally
comfortable
in
but
hoping
to
learn
more
about
it.
Yeah.
A
I
was
just
writing
some
words
on
paper
that
were
articulating
something
very
similar,
and
I
think,
as
a
matter
of
fact,
I'm
trying
to
knock
out
a
couple
of
chapters
in
an
upcoming
book,
called
service
mesh
patterns
and
part
of
what
it
tries
to
articulate
is
that,
like
the
book
will
be
this
particular
one
will
be
oriented
a
bit
more
towards
well,
if
you
had
to
pick
a
role,
maybe
operators,
just
because
it's
plain
to
see
how
they
are
enabled
by
a
mesh,
but
so
too,
and-
and
therein
lie
a
lot
of
the
common
uses
that
you
find,
but
to
your
exact
description
and
point
that,
like
oh
there's,
so
much
more
power
inside
these
things
and
and
yeah
it's
it's,
it's
gonna
take
a
while
for
people
to
to
come
to
it.
A
A
Fair
enough
good,
I'm
sorry
over
to
you
welcome
so.
C
B
A
B
B
A
A
C
Did
that
that
might
have
to
do,
but
let
me
try
one
more
time.
A
Close
some
stuff
on
maybe
maybe
maybe
shut
off
istio
on
your
on
your
machine.
E
A
Yeah,
it
was
I'll
put
it
this
way,
and
this
is
the
way
that
one
of
my
friend
nick
jackson
had
put
it
to
me.
So
I
can't
claim
the
credit,
but
the
morning
that
it
happened.
I
was
on
a
call
with
him
and,
and
he
had
articulated
it
like
well,
actually
this
isn't
quite
how
he
said
it,
but
it
was
a
little
bit
like
what
core
os
was
to
red
hat
or
core
os
was
to
open
shift.
A
Maybe
rancher
is
a
bit
of
that
to
susie,
as
a
matter
of
fact,
like,
I
think,
there's,
there's
tons
of
examples
where
older
well,
where
organizations
that
have
got
older
offerings,
but
maybe
deeper
pockets,
need
to
can
reach
out
and
pull
themselves
forward
with
with
an
acquisition.
I
think
that
I
guess
I
believe
they're
found
the
rancher
founders
when
they
say:
hey,
they're,
they're,
pretty
excited
about
it
and
they're.
Probably
gonna,
stick
around
and
and
try
to
do
some
good
things.
E
I
just
think
it's
interesting
aligning
like
ibm
picking
up
red
hat
and
what
dell
picked
up
a
vmware
a
few
years
back.
It's
like
it's
collect,
setting
up
different
empires,
which
is
good.
A
There's
there
is
a
unannounced
link
that
the
cncf
tracks
for
acquisitions
relevant
to
the
space
I'll
share
it
in
the.
C
So
I'll
try
one
last
time
if
it
doesn't
work
just
I'll.
Let
you.
C
D
A
C
So
we
can
move
to
the
second.
B
C
That's
that's
lee's,
presenting
all
right
so
nice
to
meet
you
all.
As
lee
mentioned
him
hellman.
Until
recently,
I
used
to
be
the
cto
and
co-founder
of
octorin.
Without
in
octorine
we
were
developing
a
security
solution
for
kubernetes.
We
started
focusing
on
network
security,
but
we
expanded
to
look
at
other
things,
like
configuration
of
kubernetes
workloads
and
kind
of
securing
the
whole
pipeline
of
helping
and
deploying
workloads
into
kubernetes,
as
well
as
monitoring
them
and
runtime
to
look
for
threats.
C
About
eight
months
ago,
I
started
working
with
containers
very
early
where,
when
docker
was
not
really
known
to
anyone
and
we
were
working
with
lxc
containers,
not
docker
at
that
time,
actually
focusing
on
big
data,
so
a
company
called
robin
robin
systems,
we're
looking
at
deploying
big
data
applications,
specifically
hadoop
and
spark
on
using
containers,
and
before
that,
several
companies
doing
all
kinds
of
work
on
enterprise
software.
C
So
today,
I'm
going
to
cover
several
topics
around
security
for
kubernetes
in
general
and
then
in
the
end,
I'll
specifically
talk
about
service
mesh
and
how
it
can
help
you,
and
what
do
you
need
to
do
for
it
to
help
you
actually
secure
your
workloads
again,
we
are
the
goal.
Here
is
not
really
to
secure
this
service
mesh
or
to
secure
kubernetes.
It
is
to
secure
our
applications.
C
C
All
right
so
kubernetes
is
a
game
changer
not
just
as
a
platform
and
and
how
it
affects
the
architecture
of
software,
but
really
it
has
very
deep
implications
on
on
the
organization
as
well
and
both
those
changes.
The
change
in
the
stack
and
the
change
in
the
organization
have
a
very
profound
security
implications.
C
So
the
change
in
the
tech
stack,
the
move
to
microservices
the
move
to
more
ephemeral
workloads
or
moving
from
from
pets
to
cattle
means
that
the
traditional
security
tools
that
were.
C
Very
more
focused
on
static
definitions
is
a
lot
more
dynamic.
Our
network
is
dynamic,
our
storage
definitions
are,
our
workloads
are
being
scheduled
dynamically.
C
There
is
no
affinity
anymore
between
the
network,
identity
of
a
workload
and
what
it
actually
does.
The
the
second
aspect.
The
organizational
aspect
means
we're
now
moving
from
a
very
predictable
deployment
model
to
a
distributed
and
continuous
deployment
model,
which
means
a
developer
pushes
code
and
at
some
point,
that
code
is
actually
being
deployed
into
production,
and
there
is
no
time-
and
there
is
no
way
to
have
a
very
organized
process
of
validating
security
policy
on
on
workloads
as
they
are
being
continuously
developed
and
deployed.
C
So
probably
most
of
you
are
seeing
something
like
this
diagram.
It's
the
traditional
kind
of
cncf
diagram
of
the
text,
the
cloud
native
text
stack,
which
means
we
have
our
cloud.
We
have
kubernetes
and
the
service
mesh
as
the
new
infrastructure
layer
and
then
on
top
of
it
we
run
our
applications
using
containers
and
the
way
we
kind
of
learn
to
look
at
kubernetes
is
is
a
little
bit.
C
C
This
so
we
look
at
kubernetes,
not
just
as
a
layer
of
of
the
stack
and
an
orchestration
or
a
scheduler
for
a
container.
C
We
see
it
as
a
the
new
api
for
infrastructure
is
code,
so,
as
organizations
want
to
create
a
more
cloud
agnostic,
more
uniform
way
to
provision
workloads
both
in
on-prem
in
hybrid
cloud
scenarios
in
multi-cloud
scenarios.
Kubernetes
is
really
that
unified
api
that
allows
you
to
provision
your
storage,
your
network,
your
compute,
to
manage
your
our
back
to
your
secrets,
the
privileges
of
each
workload.
C
Now
we
said
powerful,
which
means
with
with
great
power,
comes
great
responsibility
and
that
that's
not
me,
that's
a
a
wise
person
said
that
that's
spider-man,
of
course
his
uncle.
So
if
it's
in
the
movies,
it's
definitely
true.
C
So
so,
let's
talk
about
a
little
bit
the
the
risk
of
having
such
a
powerful
api
at
hand.
So
when,
when
hackers
see
that
that
that
api
and
they
can
quickly
realize
how
they
can
exploit
it
for
their
own
benefit,
the
first
one,
obviously
the
main
goal
of
hackers
is
to
access
secrets
and
confidential
data
that
can
be
that
can
be
achieved
again
by
taking
advantage
of
this
api.
C
We'll
talk
a
lot
more
about
how
that
can
be
done
once
you're
in
a
kubernetes
cluster
there's
a
lot
of
there
are
a
lot
of
tokens
there,
usually
a
lot
of
access
from
workloads
running
in
kubernetes
to
you,
the
rest
of
your
cloud
resources,
whether
it's
your
databases,
other
cloud
accounts,
your
route
tables,
really
a
very
rich
collection
of
access
points
to
the
rest
of
the
cloud
and,
of
course,
since
it
is
a
scheduler
for
containers,
it's
a
way
to
run
your
own
workloads
in
the
customer's
cluster,
which
means
crypto.
C
Miners,
obviously
find
kubernetes
very
appealing.
We've
heard
multiple
cases
where
unsecured,
apis
or
api
endpoints
were
used
in
order
to
just
run
containers
with
with
crypto
miners.
I
think
the
tesla
case
was
the
most.
C
C
The
first
one
is
how
you
configure
your
cluster
to
begin
with.
Do
you
enable
rbac?
Do
you
actually
use
our
back
correctly?
How
well
is
your
authentication
defined?
C
Do
you
have
ports
that
bypass
your
your
your
security,
your
authentication
mechanism?
Do
you
have
api
endpoints
with
public
ips,
so
is
your
kubernetes
dashboard
open
to
the
internet?
Is
your
kubernetes
api
server
exposed
all
that
has
to
do
with
how
you
define
your
cluster?
C
C
Obviously
we
have
aks
eks
gke
and
in
all
those
environments
there
is
some
effort
done
to
create
a
more
secure
configuration,
as
well
as
the
the
open
source
deployment
tools
that
continuously
improve
and
change.
The
default
configuration
to
be
more
secure.
C
C
C
Another
vector
is
the
tainted
container
image,
so
we
are.
We
live
now
in
a
great
new
world
where
open
source
is
is
available
and
it's
very
very
easy
to
use,
and
it
really
helps
us
move
faster
in
our
development
process.
C
C
C
Crypto
mining
is
a
very
common
application
that
that
is
injected
into
such
images
and
and
the
last
one
is
credentials.
So
we
have
we
once
we
have
the
the
cluster
deployed,
we
need
to
let
our
developers
use
it.
Our
operators
use
it
and
for
that
we
create
credentials
for
them.
C
C
Or
there
is
no
real
way
to
track
which
users
have
access
to
your
cluster,
because
in
kubernetes
there
is
no
such
thing
as
user
object,
so
objects
and
groups
are
all
entities
that
live
in
the
client
certificates
they
do
not,
and-
and
so,
if
we
have
a
user
that
belongs
to
a
group,
that
group
has
a
certain
capabilities
in
our
cluster.
We
will
not
know
that
this
user
still
has
that
access
and
and
once
those
credentials
are
compromised,
they
can
be
used
for
many,
many
things
that
we
mentioned.
This
is
a
very
powerful
api.
C
A
Moving
on,
actually,
I've
got
a
quick
one.
What
do
you,
what
what
are
or
are
there?
Are
there
telltale
signs
that
a
particular
credential
has
been
compromised
and-
and
I
I
know
that
like
maybe
this
is
sort
of
phrased
in
a
in
a
naive
way.
A
C
So
it
it
really,
there
isn't
currently
no
tool
that
would
detect
a
very
sophisticated
attack
that
result.
That
is
a
result
of
a
compromise
credentials
credential
as
long
as
whatever
policies
in
place
is
not.
C
Violated
obviously,
kubernetes
maintains
an
audit
log
and
that
information
can
be
forwarded
to
any
kind
of
sim
or
ueba
or
some
tool
that
analyzes
behavior
and
may
detect
some
anomaly
in
the
you
in
that
user's
behavior.
If
they
operated
an
unpredictable
unpredicted
hour
or
something
like
that.
C
But
not
no
great
tools
exist
that
obviously
the
main
best
way
to
avoid
that
is
not
to
use
client
certificates,
but
really
to
use
a
more
manageable
authentication
method
like
tokens.
So
if
we're
running
in
in
public
clouds,
usually
we
would
connect
our
authentication
mechanism
to
the
clouds
public
cloud
authentication
mechanism,
so
that
will
be
our
cube,
iam
authenticator
in
aws
or
connected
to
gcloud
in
gke
or
to
your
active
directory
in
azure.
C
So
that
usually
usually,
is
the
recommended
way
to
avoid
that
that
pitfall
of
the
fact
that
you
can't
control
which
users
are
defined
got
it.
That
makes.
A
C
All
right,
so
what
what
would
our
attacker
want
to
do
once
they
got
a
foothold
in
our
cluster?
So
the
first
thing
that
we
would
expect
the
attacker
to
do
is
is
privileged
escalation.
So
you
are,
let's
say
you
have
a
shell
running
now
inside
a
container
that
container
has
a
certain
service
account
in
kubernetes,
which
defines
what
the
container
can
do
against
the
api
server.
C
If
you've
configured
your
cluster
correctly,
usually
those
pogs
will
have
very
little
privileges
if
any,
because
usually
your
workload
doesn't
really
need
to
operate
against
the
cluster
itself,
but
rather
just
communicate
with
other
workloads.
C
So
the
first
step
an
attacker
would
want
to
do
is
find
maybe
a
pod
with
more
privileges,
the
most
common
path
to
privilege,
escalation
is
tiller.
C
So
a
tiller
is
part
of
the
helm
package
manager
and
at
least
the
helm
version.
Two
and
one
of
the
nice
things
about
taylor
for
attackers
is
that
it
had
cluster
admin
privileges
as
well
as
no
authentication,
so
it
was
running
in
your
cluster
and
as
long
as
you
had,
you
were
in
any
pod
in
your
cluster,
and
you
didn't
have
a
network
policy
that
limited
you
from
accessing
tiller.
C
You
were
the
cluster
admin.
You
could
run
any
pod,
any
application
you
could
download
a
helm
chart
and
deploy
whatever
you
want
in
that
cluster,
with
any
kind
of
access
control.
C
The
second
path
to
to
an
attack
is
the
container
escape.
So,
as
we
know,
containers
provide
some
level
of
isolation,
but
not
it's
not
a
virtual
machine.
We're
still
sharing
the
kernel
with
all
the
other
pods
in
on
the
node,
so
if
we
can
take
advantage
either
of
the
privilege
of
the
container
itself.
C
So
if
the
container
is
running
in
a
privileged
mode
or
some
vulnerability
in
the
docker
or
the
container
runtime
environment,
then
there
is
an
opportunity
to
establish
a
root
user
on
the
host
itself,
and
once
you
do
that,
you
can
pretty
much
move
to
any
container
on
that
host
and
run
other
containers
which
would
usually
again
result
in
cluster
admin
privileges
on
the
cluster
as
a
whole.
C
The
the
third
thing
an
attacker
would
look
like
would
look
for
is
secrets.
Obviously
there
are
some
secrets
that
have
to
do
with
the
application
itself
database
passwords
aws
over
any
cloud
api
tokens
as
well
as
kubernetes
related
secrets.
So
again,
once
you
are
able
to
reach
secrets,
you
have
all
the
service
account
tokens
so
that
pretty
much
means
you're
a
cluster
admin
again,
because
you
can
authenticate
yourself
as
any
service
account
in
the
classroom
and
the
fourth
one
is
the
more
conventional
attack
pattern
of
lateral
movement.
So
we
start
exploring.
C
The
the
the
other
apis
that
are
available
in
in
the
cluster
and
trying
to
move
to
some
workloads
that
may
have
access
to
more
interesting
data
card
holder
data,
pii.
Anything
that
an
attacker
might
be
interested.
A
I
I
have
a
couple
and
one
is
that
with
the
container
escape
or
no
yeah
the
container
escape,
maybe
it's
with
the
privilege
escalation
as
well.
But
I
guess
it's
been
a
while,
since
I
looked,
you
know
what
what's
the
current
state
of
a
given
a
sort
of
a
vanilla,
kubernetes
deployment
with
its
container
run
time
requiring
that
container
runtime
to
run
as
root.
C
So
so
containers
are
now
are
not
run
as
root
by
by
default
anymore
and
docker
agent
does
not
run
as
root
as
well,
as
runs
as
the
docker
in
the
docker
group,
with
the
docker
user,
so
that
has
been
resolved
a
while
ago.
Still
there
were
incidents
where
run
c
was
vulnerable
to
a
privilege,
escalation
attack
that
allowed
you
to
become
root
on
the
host
itself,
that
that
was
fixed.
A
Okay
of
the
secret
sex
extraction,
assuming
that
an
attacker
has
gained
access
to
a
to
a
pod,
is,
is
one
of
the
first
places
that
they
look
into
environment
variables.
Of
that
container.
C
Or
yes,
so
that
that
is
really
bad
practice.
If
you're
putting
your
secrets
in
environment
variables,
it's
probably
there
are
two
ways
to
do
it.
One
is
by
importing
the
the
value
of
the
environment
variable
from
a
secret
from
a
kubernetes
secret,
which
is
not
the
preferred
way
to
do
it,
because
you
can
still
look
at
the
environment
variable
of
each
process.
So,
if
you're
in
a,
if
you
have
some
access
to
different
processes
on
the
host,
you
can
read
all
their
environment
variables.
C
But
the
worst
thing
is
to
actually
have
it
hard
coded
in
your
yaml
or
in
your
values
file
in
in
which
means,
probably
you
have
it
in
your
source,
control
repo
and
then
it's
not
really
a
secret
anymore.
C
C
People
mistakenly
think
that
read
only
permissions
in
kubernetes
are
not
that
bad,
but
really
a
read.
Only
permission
in
kubernetes
is
exactly
the
same
as
cluster
admin,
because
the
first
thing
you'll
do
is
you'll
read
the
what's
the
service
token
access
the
services,
the
service
accounts,
token
for
a
cluster
admin
and
go
from
there.
A
Last
question:
for
me:
the
lateral
movement
in
the
network,
just
as
it
pertains
to
service
meshes,
is
you
know
that
some
of
these
meshes
will
you
will
require
the
net
admin
capability
in
order
to
you
know,
do
some
traffic
redirection
between
the
application
containers
and
the
side
card
proxies
and
some
of
the
service
meshes
will?
Will
leverage,
maybe
cni
to
remove
the
need?
A
For
you
know
such
privileges
is
am
I
is
that
in
part
and
parcel
to
I
mean
the
way
in
which
you
described
lateral
network
movement
was
wasn't
necessarily
that
mechanism,
but
do
you
consider
that
in
a
similar
category
or
is
so.
C
C
There
is,
there
are
ways
to
to
go
around
all
those
mechanisms
using
net
admin
capabilities
like
you,
you
described
that
again
has
to
do
with
how
we
harden
our
workload
and
we'll
next
talk
about
how
we
can
achieve
that.
B
C
Let's
talk
about
what
we
can
do
to
actually
avoid
those
attack,
vectors
and
attack
patterns.
A
Next
one
lee:
oh
sorry,
yeah
no,
very
good.
C
C
Well,
maybe
the
most
important
one,
but
a
lot
of
the
attack,
vectors
and
attack
patterns
that
we
talked
about
can
be
avoided
by
having
some
sort
of
admission
control.
So
admission,
control
in
kubernetes
means
we're
looking
at
the
spec
of
each
workload
that
is
being
deployed
and
we
applying
some
kind
of
some
set
of
rules
to
decide
whether
this
is
acceptable
for
us.
C
So
one
of
the
cases
that
that
lee
mentioned
is
the
net
admin
capability,
so
it's
very
natural
that
we
would
want
to
have
a
way
to
prevent
containers
with
net
admin
capability
from
being
deployed
in
our
cluster.
That
can
be
achieved
with
what
we
call
a
validating,
webhook,
so
validating
webhook
means
any
api
call
can
be
routed
to
that
validating
service
via
webhook,
and
that
service
will
apply
some
policy
and
will
decide
whether
to
admit
the
word
the
resource
or
to
reject
it.
C
Very
common
admission
controllers
are
the
image
policy
webhook,
which
looks
at
the
image
of
the
containers
that
we
want
to
deploy
and
checks,
whether
it
comes
from
a
registry
that
we
trust,
whether
it's
a
repository,
that
we
trust
whether
it
has
been
scanned.
If
we
have
some
scanning
solution,
so
probably
most
of
the
container
scanning
solutions
today
offer
some
kind
of
an
image
policy
web
hook.
C
What
volumes
can
be
mounted
what
security
settings
need
to
be
in
place
in
for
each
pod,
that
is
being
admitted.
The
functionality
of
pod
security
policy
is
very,
very
important.
Unfortunately,
the
usability
of
it
is
not
the
greatest.
It
is
hard
to
write
a
good
pot
security
policy
there.
A
Question
open
policy
agent
and
you
know
gatekeeper.
A
Are
these,
and-
and
I
guess
cuverno
from
nirmata
are
those
tools
that
are
also
commonly
applied
at
this
point.
C
Yeah
so
we'll
we'll
talk
a
little
bit
about
tools
moving
forward,
but
yes,
for
specifically
for
admission
control,
gatekeeper
is
probably
the
most
known
open
source
project
for
applying
policy
on
on
admission
control
and
it
is
using
opa
and
rigo
as
the
language
to
define
that
policy.
C
Unfortunately,
again,
in
my
opinion,
rigo
is
only
slightly
more
usable
than
port
security
policy,
and
the
good
thing
about
gatekeeper
is
that
you
can
get
some
predefined
policies
off
the
shelf
and
and
use
them
in
your
environment,
and
that
will
get
you
halfway.
There.
C
So
a
little
bit
about
what
how
admission
controllers
operate
and
again
there
are
two
kinds:
the
first
one
is
the
mutating
admission
control,
that's
the
one
that
takes
a
yamo
or
a
resource
definition
at
that
point,
it's
in
json
format
and
actually
modifies
it
based
on
some
kind
of
rule
set
of
rules.
Istio
sidecar
injector
is
probably
the
most
famous
mutating
admission
controller.
C
All
right,
so
another
mechanism,
that's
very,
very
important
and
not
very
easily
managed,
is
our
back
and
again.
Our
back
in
kubernetes
means
we
create
a
role
which
is
a
set
of
resources
and
actions
that
can
be
applied
to
those
resources.
C
Go
to
the
next
slide,
we'll
see
how
our
back
looks
like.
So
again
we
have
our
roles
or
if
it's
across
the
entire
cluster,
then
it's
called
the
cluster
role,
which
says
which
operations
we
can
do
on
which
resource
and
then
we
bind
it
either
to
a
service
account
that
can
be
used
by
one
or
more
workload
or
to
a
user
or
a
group
of
users,
and
our
back
is
is
hard
to
to
manage
again.
C
So
we
mentioned
the
read-only
access
which
seems
harmless,
so
we
just
allow
the
get
operation
on
all
resources
that
is
actually
equivalent
to
a
cluster
admin
privilege
in
kubernetes.
So
it
is
very,
it
is
recommended
that
any
role
would
actually
enumerate
all
the
resources
that
you
want
to
access
in
all
the
operations
that
you
would
like
the
subject
to
have.
C
It
is
very
recommended
to
use
an
external
tool
to
kind
of
audit
your
rbac
recommendations
or
even
automatically
manage
them.
There
are
some
scripts
that
analyze
your
auditor
and
can
tell
you
how
does
that
compare
to
your
rbac
policy?
So
if
you
have
permissions
that
you're
not
using
it
will
tell
you.
C
B
C
C
B
C
So
again,
even
though
it's
it's
hard
to
manage,
it
is
the
best
way
to
segment
your
cluster
and
separate
at
least
namespaces
that
are
sensitive
from
namespaces
that
are
not
kind
of
create
separation
between
different
users
who
operate
different
applications
in
a
multi-tenant
cluster.
C
And
yes,
there
are
many
tools
out
there
that
can
help
you
we're
for
admission
control.
We
talked
about
opa
and
and
gatekeeper,
which
uses
opa.
Our
backmanager
is
a
nice
tool
to
visualize
your
our
bag
and
control
it
in
a
more
atomic
way.
There
are
certain
changes
that,
when
you're
doing
rbad,
you
have
to
do
it
together,
our
back
manager
does
it
for
you.
There
are
many
other
tools
for
visualizing
your
outback
policy.
C
C
C
C
C
And
I
know
we're
out
of
time,
but
we've
reached
the
part
where
we
actually
talk
about
service
match.
C
A
C
So
there
are
multiple:
there
is
a
variety
of
service
meshes
out
there.
As
lee
has
probably
told
you
many
times:
it's
not
all
asia,
but
istio
is
definitely
the
most
the
one
that
gets
the
most
popularity
and
notoriety,
but
linkrd
has
been
there
first.
C
It
has,
as
william
morgan
would
like
to
remind
everyone
and
hashicorp
has
their
console
connect
service
mesh,
so
in
octarine
has
we
have
our
own
service
mesh
as
well,
and
and
to
those
of
you
now
still
don't
know
what
service
mesh
is
a
service
mesh
is
a
proxy
and
a
control
plane.
It
means
we
have
a
proxy
running
as
a
sidecar
running
alongside
each
workload
handling
network
functions,
and
then
we
have
some
control
plane
that
configures
all
those
on
those
proxies
the
most
common
proxy
out.
C
There
is
envoy
that
was
developed
by
lyft
used
in
istio
and
console
connect
and
octarine
and
others.
Linker
d
has
their
own
proxy
and
there
are
a
few
other
proxies
out
there
moving
on
so
the
nice
thing
that
service
mesh
gives
you
when
it
comes
to
security,
is
that
concept
of
zero
trust?
Zero
trust
means
that
all
the
communication
in
your
cluster,
so
not
just
coming
from
the
internet,
should
be
treated
as
untrusted,
which
means
everything
needs
to
be
encrypted.
C
Everything
needs
to
be
authenticated
and,
and
that's
one
of
the
great
features
of
the
service
mesh,
the
proxy
handles
all
the
heavy
lifting
of
key
management
delivering
certificates
to
each
workload,
so
they
can
create
a
mutual
tls
connection
between
the
workloads,
which
means
we
have
encryption
and
server
and
client
authentication
on
every
connection
in
the
mesh.
C
Another
great
thing
that
the
service
mesh
provides
is
that
visibility,
so
it
provides
telemetry
that
can
be
used
to
monitor
traffic
between
workloads
and
layer
7,
and
that
information
is
very,
very
useful
if
you
are
want
to
implement
something
like
an
anomaly
detection
mechanism
or
some
kind
of
intrusion,
detection
tool
without
visibility,
there
is
really
no
way
to
to
know
if
anything
suspicious
is
going
on
in
your
environment.
C
Obviously,
another
way
to
limit
the
blastery
use
of
an
attacker
is
by
using
an
authorization
policy.
This
is
another
thing:
that's
supported
by
most
service
meshes
today,
so
you
can
define
layer,
7,
very
granular,
access
control
policy
for
your
cluster
again
to
do
it
well
is
is
challenging,
but
if
you
do,
then
you
get
you
really
minimize
your
risk
of
exposure
in
terms
of
lateral
movement
and
extraction
of
sensitive
data.
C
Another
thing
that
not
all
service
measures
provide,
but
some
of
them
do
is
the
a
way
to
control
your
egress
traffic,
it's
very
hard
to
to
to
manage
an
attack
if
you
can't
connect
to
an
external
command
and
control
server,
if
you
can
download
tools
and
obviously,
if
you
can't
send
information
that
either
you
generated
or
you
stole
up
for
out
of
the
cluster,
all
those
require
some
sort
of
outbound
connection
to
the
internet
that
can
be
controlled
in
service
measures.
C
Specifically,
eco
provides
the
egress
gateway
component
that
you
can
route
all
your
traffic
through
and
then
you
can
use
firewall
rules
to
make
sure
that
no
other
service
will
actually
be
allowed
to
talk
to
the
internet
to
to
go
outside
of
your
cluster.
And
then
you,
you
get
a
pretty
good
control
over
what
kind
of
communication
leaves
your
question.
C
C
Many
in
many
cases
we
see
deployments
that
are
partial,
so
we
we
only
instrument
some
of
our
workloads,
but
not
all
of
them,
because
there
is
some
overhead
in
latency
and
cpu
for
the
service
mesh.
So
some
of
our
services
are,
they
can't
be
instrumented,
and
then
we
need
to
create
exceptions
in
the
authentication
and
encryption
policy
for
accessing
those
services.
C
C
In
many
cases,
encryption
is
not
even
enabled
so
in
the
earlier
days
of
istio,
there
were
a
lot
of
issues
that
arise
when
encryption
was
enabled,
especially
in
terms
of
discovering
which
paths
need
to
be
encrypted,
which
should
not
there's.
C
Actually,
a
lot
of
good
work
has
been
done
to
automate
that
discovery
process,
so
you
can
define
at
least
best
effort
tls
on
all
your
mesh
connections,
but
obviously,
if
encryption
is
not
enabled,
which
is
an
option
then
you're
losing
that
zero
trust
mechanism,
because
when
you
don't
have
encryption,
you
don't
have
authentication
as
well.
C
Egress
control
is
not
trivial
to
implement,
so
an
egress
gateway
is,
is
an
optional
feature
in
many
cases,
not
deployed
authorization
policy
again
very
useful,
but
does
not
exist
by
default.
So
if
you
just
deployed
the
service
mesh,
you
don't
have
any
authorization
in
place.
Everything
is
allowed
that
which
might
be
strange
for
people
who
are
familiar
with
older
platform
as
a
service
solutions
like
cloud
foundry,
for
example,
where,
if
you
didn't
whitelist
something
if
you
didn't
allow
it
specifically,
it
wasn't
allowed
in
kubernetes
and
initial.
C
Obviously,
if
you
operate
in
the
host,
if
you
have
host
network,
if
you're
working
at
the
host
network
namespace,
which
is
another
kubernetes
attribute
that
you
should
look
out
for
so
there
are
multiple
ways
that
traffic
will
bypass
the
proxy
and
if
you
have
that,
then
again,
no
encryption,
no
visibility,
and
hopefully
encryption
is
enabled
everywhere
else,
which
means
that
at
least
authentication
will
catch,
prevent
access.
C
So
what
can
you
do
to
avoid
all
those
pitfalls
again?
The
first
one
is
avoid
partial
deployments
as
much
as
possible.
It's
not
always
possible,
but
instrumenting
as
many
services
as
possible
means
you
get
the
best
visibility
means
you
get
the
most
encryption
authentication
and
the
most
ability
to
create
access,
control
and
egress
management.
C
C
Implement
an
egress
gateway,
even
though
it's
hard
it's
again,
there
are
no
successful
attacks
without
egress
traffic.
If
you
can't
connect
to
the
internet
there
is
it
doesn't
work,
it's
so
controlling
your
eagers
traffic
is
extremely
important
it.
It
has
to
also
be
accompanied
with
network
with
some
sort
of
firewall
rules
or
a
security
group
that
prevents
outbound
access
from
the
cluster.
By
anything.
That's
not
your.
Your
eager
escape.
C
Use
some
tool
that
will
allow
you
to
create
and
maintain
at
least
privilege
of
the
authorization
policy.
So
in
octarine
we
built
such
a
tool,
but
it's
really
not
that
hard.
Once
you
have
visibility
once
you
know
which
traffic
you
have.
You
just
take
that
information
and
you
can
very
or
somewhat
easily
convert
it
to
an
authentication
policy
in
your
in
your
service
mesh,
so
that
visibility
that
service
mesh
provides
and
the
ease
of
creating
an
authorization
policy
is
something
to
take
advantage
of.
C
C
And
questions
that
was
all
for
me.
A
An
example
of
a
host-based
network
security
solution
that
that
might
work
well.
C
Marketing,
which
is
great-
I
don't
so
once
up
to
six
weeks
ago,
you
could
buy
a
really
good
host-based
securities
network
security
solution
for
kubernetes
from
octorion,
but
not
anymore.
That
would
be
available
at
some
point
from
from
carbon
black
and
from
tanzu
service
mesh.
C
I'm
not
really
aware
of
a
good
well,
so
falco
is
probably
the
best
open
source
solution
that
is
kernel
based,
so
it
actually
end
container
aware,
so
that
allows
you
to
get
full
visibility
and
control
over
not
just
network
traffic,
but
any
kind
of
system
call
that
is
happening
in
any
one
of
your
containers.
C
So
as
far
as
open
source
solutions,
I
think
it's
a
very
good
solution.
C
And
and
obviously
cystic
does
have
an
enterprise
solution
for
that
as
well
yeah.
So
if
I
I
would
have
to
choose
a
solution,
I
would
probably
say
that
falco
is
the
best
open
source
one
out
there
and
there
are
other
commercial
solutions
that
are
also
in
the
market.
D
A
Just
great
it's
a
great
question.
I
can't
help
but
jump
in
and
say
that
that
that
they
don't
that
you
know
some,
some
don't
even
have
don't
have
the
concept
of
a
gateway,
ingress
or
egress,
and
so
there's.
A
D
No
question,
but
I
just
wanted
to
say
thank
you
haim
for
presenting
tonight.
Usually
there's
clapping
that's
involved
at
these
meetups,
but
it's
hard
to
do.
I
call,
but
bravo
thank
you.
A
C
Yeah
there
are
a
lot
of
extra
slides
in
the
back,
as
well
as
some
demos
to
run,
but
should
I
require,
like
a
three
hour
sure.
A
Have
you
yeah
in
some
of
your
travels
time?
A
Have
you
found
bumped
into
those
that
are
maybe
you're
running
in
this
case
kind
of
giving
part
of
your
your
focus
toward
toward
istio,
maybe
they're
running
an
istio
and
they're
having
a
little
bit
of
a
difficult
time,
understanding
their
traffic
control
rules
and
sort
of
of
the
rules
that
are
there
when
you
add
them
all
up
what
what's
actually
going
to
happen,
and
I
I
ask
it
sort
of
in
context
of
the
same
thing
with
respect
to
maybe
some
authorization
that
they've
got
some
some
authentication,
some
authorization
rules,
they've
got
defined
as
well
and
turns
out.
A
They've
got
enough
of
them
that
they're
one
of
their
questions
you
know,
is
like
what
actually
is
going
to
happen
because
they're
they
they
think
they've
got
it
covered
in
yammel,
but
they're
not,
but
they
they
yeah
they're,
not
quite
sure.
C
Right,
so
that's
where
a
good
policy
engine
has
to
come
into
place
because
you
can
define
shadow
policy,
so
you
you
can
define
policies
that
are
going
to
create
a
a
log
but
are
not
going
to
actually
block
traffic.
So
there
is,
there
are
ways
to
you
know,
put
a
policy
in
place,
but
not
actually
suffer
the
consequences
of
that
policy
right
away.
C
You
create
a
permissive
authorization
policy.
You
still
need
a
tool
to
actually
look
at
those
logs
and
see
where,
if
you
are
having
any
sorts
of
violations
and
and
yes,
it
was
a
challenge
and
that's
one
of
the
solutions
that
we
actually
provided
in
octo,
which
was
that
visibility
and
alert
mode.
So
you
can
create
a
policy
but
not
block.
C
Then
you
see
your
alerts,
then
you
have
an
automatic
policy
that
translates
those
alerts
into
new
policy
rules
which
are
then
being
enforced,
and
once
you
don't
get
any
alerts,
you
can
actually
change
your
your
action
to
to
a
deny
or
block
action,
and
at
that
point
you
will
still
get
an
alert
for
violation,
but
it
will
also
the
traffic
would
be
denied.
C
So
it's
again
having
istio
by
itself
is,
is
hard
to
manage
without
the
peripheral
tools
around
it.
Kiyali
is
is
like
the
most
probably
popular
open
source,
one
for
for
visibility
and
to
see
what's
going
on.
C
There
are
some
other
that
that
work
on
visibility
like
aspen
mesh
around
eco
and
again
there
are
certain
tools
from
third-party
sellers
or
integrators.
C
A
A
Wow
this
is
nice.
Well,
it's
the
last
couple
of
times
we've
met
together
as
a
group,
it's
been.
A
A
Very
good
yeah
I'll
see
what
heim's
preference
is,
but
you
know,
if
you
didn't
have
one,
then
maybe
we'll
toss
them
up
on
the
I.
A
A
I
wish,
as
a
matter
of
fact,
we
should
stop
the
recording
before
I
swear
too
much
more
I'd
said
that
I'd
give
a
link.
I
don't
know
how
interesting
it
is
or
not,
but
we
were
sort
of
talking
about
acquisitions.
There's
a
just,
I
think,
just
as
a
point
of
interest
to
the
cncf
and
to
some
of
its
member
companies.
It
keeps
track
of
just.
B
A
A
But
yeah
you
know
my
goodness
lots
going
on.
I
was
just
talking
with
these
fine
folks
this
week
and
then
the
second
thing
was
so
so
I
guess
I
didn't
share
the
link.
Let
me
let
me
do
that
real
quick
in
the
chat.
A
Anyway,
otherwise,
hopefully
we'll
meet
in
a
month
and
talk
about
some
service
mesh
patterns
and
those
would
be
fresh
slides
because
I
don't
have
those
today.
E
A
All
right,
fair
enough.
It's
very
nice
to
see
everyone
today,
thanks
for
all
coming
thanks
for
putting
up
with
the
zoom
issue
and
and
thanks
to
haim
for
the
education.
E
A
Big
old
boy,
he
kind
of
grew
up
on
dog
food
on
the
dry
dog
food
outside.
So
we
we
hatched
him
here.
The
interesting
thing
bradley
is
that
my
my
wife
also
does
wildlife
rehabilitation,
and
so
we've
got.
A
Yeah
yeah
they've
been
released.
They
skunks
are
amazingly
like
some
of
the
softest
sweetest
of
the
animals
that
we
get,
but
we've
got
a
ton
of
raccoons
that
have
been
released
on
our
property.
So
speaking
about
the
the
this
rooster,
he
nests
just
on
the
back
porch
and
we
have
raccoons
that
come
back
nightly.
They've
been
released,
they're
out
doing
their
thing,
but
they
come
back
and
funny
enough.
They
also
go
for
the
dog
food
and
turns
out
hey.
A
If
we
don't
keep
the
dog
food
bowl
stalked,
then
our
rooster's
in
a
bit
of
danger
at
night
he
gets
left
alone.
Otherwise
the
raccoons
come
right
by
and
they
go
for
the
dog
food.
But
if
you
don't
feed
the
coons,
your
roosters
yeah
so
yeah
anyway,
yeah.
A
Oh
very
good,
I
hope
to
see
all
of
you
in
a
month.