►
Description
Join us for Kubernetes Forums Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Keynote: Security and the OODA Loop - Liz Rice, Technology Evangelist, Aqua Security
A
Welcome
to
kubernetes
forum
in
Sydney
I
actually
was
programmed
chair
for
this
particular
event.
So
if
you
enjoy
the
talks
that
you
see
today,
please
go
and
tell
the
speakers
that
you
enjoyed
them
and
if
it's
anything
you
didn't
enjoy,
you
come
and
tell
me:
okay,
so
I
work
with
a
company
called
aqua
security
and
security
and
cloud
native.
It's
kind
of
my
thing
so
I
want
to
talk
this
morning
about
security
and
a
kind
of
military
strategy
technique
called
the
OODA
loop.
A
So
has
anybody
here
heard
of
the
OODA
loop
before
it's
pretty
hard
to
see,
but
a
few
hands?
Okay,
it
was
invented
by
a
u.s.
officer
called
John
Boyd,
and
the
idea
is
that
in
a
conflict
situation,
you
observe
your
current
situation.
You
orientate
yourself,
which
is
basically
looking
at
what
you
expected
to
be
happening.
A
What
your
enemy
is
doing.
Then
you
decide
what
you're
going
to
do
you
act
on
that
decision
and
then
you
keep
going
around
this
circle
re-evaluating
where
you
are
observing,
where
you
are
again
orientating
and
moving
on
around
the
loop
and
if
that
sounds
familiar
in
kubernetes,
it's
because
we
use
this.
In
reconciliation,
so
controller
will
observe
the
current
state.
Compare
that
to
expectations
what's
been
defined
in
Y
amyl,
decide
whether
any
resources
needed
to
be
added
or
taken
away
and
create
and
destroy
those
resources
to
constantly
bring
the
current
state
in
line
with
expectations.
A
If
we're
talking
about
a
deployment,
we
might
say
how
many
pods
are
there?
Does
the
number
of
pods
match
the
replicas
counts
and
if
it
doesn't,
there
are
too
many
or
too
few
we're
going
to
have
to
create
and
destroy
some
pods.
So
let's
take
a
look
at
that
happening.
If
my
video
starts
yesterday,
we
go
so
I
have
a
very
simple
deployment
here
with
three
nginx
pods.
The
replicas
count
is
three
and
you
can
see
that
those
three
pods
are
running
in
the
bottom
half
of
the
screen.
If
I
delete
one
of
those
parts.
A
Just
delete
that-
and
you
see
very
quickly:
not
only
does
that
container
get
destroyed,
but
a
new
one
gets
recreated.
So
that's
the
controller,
doing
its
reconciliation
loop
and
bringing
the
number
of
pods
back
to
the
replica
count
we
expected.
So
that's
how
reconciliation
works
in
kubernetes
and
we
can
also
use
other
loops
for
security
purposes.
A
A
A
So
I
have
a
little
script
here,
using
a
tool
called
Tracy
and
that's
gonna
tell
us
about
new
executables
that
start
in
containers.
I
have
my
nginx
deployment
with
my
three
running
pods.
If
I
delete
one
of
those,
the
reconciliation
loop
is
going
to
kick
in,
create
a
new
nginx
pod
and
we
see
two
executables
one
is
the
pause
container.
It's
a
detail
and
what
we
are
interested
in
is
an
engine
X
program
running
inside
the
nginx
pod.
That's
exactly
what
we
expect:
okay
hands
up.
A
If
you
have
ever
downloaded
yeah
morph
and
run
it
from
the
internet
yeah.
We
all
do
it
right
and
you've
got
to
be
pretty
careful,
because
if
you
don't
pay
attention
to
the
details
of
your
potentially
hundreds
of
lines
of
Yambol
that
you
download,
maybe
something
bad
is
being
snuck
in.
So
let's
say
that
I
inadvertently
download
some
bad
nginx
deployment
and
I
run
it
in
my
deployment
and
we'll
observe
what
happens
in
terms
of
the
executables,
and
this
time
we
don't
see.
Nginx
running,
we
see
some
other
things,
including
a
shell
script
called
bad.
A
That
seems,
kind
of
GBS
probably
didn't
want
that
to
happen.
We
can
look
at
the
pods
that
are
running
and
check
the
logs,
we'll
look
at
the
logs
for
one
of
these
bad
ones.
That's
been
created
now
I
wrote
this
demo.
So
I
know
that
all
it's
doing
is
logging
something
out
looking
out
a
message,
but
imagine
it
could
be
cryptocurrency
mining
or
exfiltrating
your
data,
all
sorts
of
bad
things
can
happen
if
you
download,
yam
or
from
the
internet,
but
I
can
detect
that
right.
A
I've
seen
the
executables
running
inside
my
pod,
so
I
can
use
that
either
loop
I
can
monitor
the
new
executables.
Take
a
look
at
the
executable
names
decide
whether
or
in
this
example
I'm
just
going
to
be
checking.
Is
it
bad
and
if
it's
bad,
I'm
gonna
kill
the
pods.
So
this
time
I'm
running
a
very
simple
awk
script:
that's
going
to
match
the
executable
name
against
the
word
bad,
and
if
it's
bad,
it's
gonna
run
a
shell
script
called
kill.
My
kill
script
is
very
simple.
A
A
So
the
problem
we
can
see
there
is
that
it
takes
time
to
react
between
the
observe
step
and
the
action
of
deleting
the
pod,
and
if
that
time
is
long
enough,
an
attacker
could
potentially
use
it
for
their
bad
purposes.
There's
no
real
definition
of
what
is
too
too
long.
What
does
too
slow
mean
well
John
Boyd?
Who
is
the
originator
of
that?
You
de
loop
said
that
you
have
to.
If
you
want
to
win,
you
have
to
operate
at
a
faster
tempo
than
our
adversaries
in
the
world
of
security.
A
We're
talking
about
attackers,
but
there
is
no
time
limit.
There
is
no
fast
enough;
it
would
be
better
I.
Would
the
other
thing
is
what
I
was
mentioning
about
the
problem
with
this
approach,
where
my
security
tool,
my
very
naive
security
tool,
is
our
odds
with
that
kubernetes
reconciliation
loop,
it's
just
a
waste
of
resources
to
keep
creating
these
pods
and
then
deleting
them
again
and
creating
again
and
deleting
them.
Yet
we
need
something
much
more
sophisticated
if
we're
going
to
just
kill
pods.
A
What
would
be
a
lot
better
is
if
we
were
able
to
prevent
those
birds,
nginx
pods,
from
being
deployed
in
the
first
place.
If
we
knew
that
the
intention
was
to
run
something
bad,
then
we
wouldn't
have
to
stop
it
afterwards.
So
a
better
odor
loop
looks
at
the
intention,
compares
the
intention
with
the
expectation
and
then
decides
whether
or
not
to
allow
or
prevent
that
behavior
now
at
runtime.
There
are
tools
that
can
do
that,
but
it's
pretty
hard.
A
What
we
can
do
is
look
earlier
in
the
deployment
pipeline
for
places
where
we
can
insert
preventative
measures.
So
if
we
can
prevent
bad
pods
bad
software
from
being
deployed,
it
just
cannot
do
us
any
harm.
If
we
can
detect
when
our
software
has
known
vulnerabilities,
it
can't
do
us
any
harm
if
we
don't
deploy
that
software,
so
anything
we
can
do
before
runtime
is
preventative
and
basically
more
effective.
A
Scanning
images
is
looking
inside
those
images
for
known
vulnerabilities,
depending
on
your
scanner.
You
may
also
be
able
to
detect
malware.
You
might
be
able
to
detect
that
cryptocurrency
mining
and
it
prevents
those
images
from
being
deployed
from
being
stored
in
your
registry.
Perhaps
we
can
use
role
based
access
control
to
stop
unauthorized
users
from
deploying
software,
and
we
can
use
admission
control
things
like
open
policy
agent
to
check
the
yeah
mall
as
it's
being
deployed
and
prevent
it
if
it
doesn't
meet
our
criteria.
A
Essentially,
if
it
says
it's
going
to
run
a
bad
nginx
container,
I'd
I
don't
want
it
to
run.
If
you
were
thinking
about
securing
your
home
or
your
office,
which
would
you
do
first,
would
you
put
a
lock
on
first
or
would
you
invest
in
web
surveillance?
I
think
you'd
probably
put
a
lock
on
the
door
first
right,
that's
the
easier
and
most
effective
thing
to
do
and
that's
access-control.
That's
a
preventative
measure.