►
Description
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
Hello,
this
is
my
first
time
in
South
Korea.
So
it's
wonderful
to
be
here
and
I
want
to
talk
today
about
a
military
strategy
technique
called
the
OODA
loop.
Has
anyone
heard
of
that
you
delete
before?
Okay,
it
was
invented
by
an
US
Air,
Force
officer,
called
John,
Boyd
and
leader
stands
for,
observe,
orientate,
decide
and
act.
So
if
you're
in
some
kind
of
military
conflict
situation,
the
idea
is
that
you
observe
your
current
situation.
You
orientate
yourself
by
looking
at
your
surroundings,
seeing
what
the
enemy
is
up
to.
A
You
make
a
decision
on
what
to
do.
You
take
some
action
and
then
you
start
again
after
the
action
is
complete.
You
see
where
you
are
and
you
see
where
your
enemy
is
and
you
carry
on
around
the
OODA
loop
and
if
that
sounds
familiar,
it's
because
it's
very
much
what
we
see
in
kubernetes
with
the
reconciliation
loop,
where
a
controller
will
look
at
the
current
state.
Look
at
the
desired
state
identify
what
the
difference
is
between
the
two
and
create
or
destroy
resources,
to
bring
the
the
current
state
in
line
with
the
desired
States.
A
And
if
we
were
talking
about
deployment,
we
might
look
at
the
number
of
pots.
Look
at
how
many
replicas
we
were
expecting
decide
whether
there's
too
many
or
too
few,
and
then
the
controller
will
create
and
destroy
pods
as
necessary.
So
let's
take
a
look
at
that
happening.
I've
got
a
very
simple
nginx
deployment
that
expects
to
have
three
replicas
replicas
counts
of
three,
and
you
can
see
there
are
three
pods
running
nginx
right
now.
A
A
A
A
A
So
perhaps
we
can
observe
these
executables
and
use
this
for
security
purposes.
So
we
could
check
the
executable
name,
decide
whether
it's
something
we
want
to
allow
to
run
and
what
are
we
going
to
do
about
it?
Well,
I'm
gonna.
Do
an
example
where
I'm
going
to
kill
the
pod,
so
I've
used
exactly
the
same
tool
as
before
and
I'm,
comparing
the
executable
name
with
the
word
bad,
and
if
it
is
bad,
it's
gonna
run
a
simple
script:
that's
going
to
get
the
list
of
pods
and
then
just
for
simplicity.
A
A
At
this
point,
we
can
see
that
those
bad
pods
were
able
to
print
out
that
message
and,
if
I
carry
on
with
the
this
demo
here
we
see
some
error
locks
because
you
can't
get
logs
from
a
container
wallets
being
recreated
or
being
destroyed,
but
we
also
see
basically,
these
pods
are
being
deleted,
recreating
and
then
they're
doing
that
bad
action.
So
the
problem
is
that
it
takes
time
to
react
to
this
observation
and
bad
things
could
be
happening
during
that
time.
A
A
Another
issue
in
that
very
naive
security
tool
that
I
just
showed
you
is
that
it's
in
conflict
with
that
kubernetes
reconciliation
loop.
So
if
we
keep
deleting
pods,
the
reconciliation
loop
in
the
controller
will
keep
recreating
them,
so
we're
just
going
to
keep
cycling
around
creating
and
deleting
parts.
A
A
Reacting
to
these
events
is
really
difficult
and
it
would
be
much
better
if
we
could
prevent
these
bad
actions
rather
than
cure
them
after
they've
happened.
So
a
better
security,
eda
loop
would
look
at
the
intention
rather
than
the
actual
behavior
and
then
based
on
the
intention.
It
could
decide
whether
this
is
something
we
should
allow
or
block.
A
Now
it's
quite
difficult
to
detect
that
intention
at
run
time,
but
we
have
other
opportunities
if
we
look
at
the
deployment
pipeline-
and
this
is
a
very
simple
version
of
it-
I've
been
talking
about
reacting
to
anomalies
at
run
time,
but
we
have
other
opportunities
by
inserting
security
tools
earlier
in
that
pipeline,
we
can
do
security
at
deploy
time.
We
can
even
do
security
at
build
time,
and
if
we
do
this,
it's
before
the
software
ever
gets
to
run.
So
we
prevent
security
issues
rather
than
trying
to
cure
them
those
preventive
measures.
A
A
We
can
use
role
based
access
control,
that's
built
into
kubernetes,
to
prevent
unauthorized
users
from
deploying
code,
and
we
can
use
admission
controllers
or
the
open
policy
agents
to
perform
checks
on
that
yeah
more
to
make
sure
that
what
we're
deploying
is
what
we
expect
and
intentional.
So
we
have
a
lot
of
options
for
preventative
security.