►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Keynote: SIG-Honk AMA Panel: Hacking and Hardening in the Cloud Native Garden - Ian Coldwater, Independent; Duffie Cooley, Independent; Brad Geesaman, Co-Founder, Darkbit; & Rory McCune, Principal Consultant
Have you ever wondered how hackers think? What do attackers look for when they approach a cluster, and what security hardening steps can stop them in their tracks? Join Ian Coldwater, Brad Geesaman, Rory McCune, and Duffie Cooley for an AMA panel session. This group of friends and longtime Kubernetes security SMEs bring their unique perspectives and experience with securing, attacking, and deploying cloud native infrastructure to form ”sig-HONK,” an unofficial Special Interest Group focused on changing the way we think about and practice security in distributed systems. How does this group of people come up with ideas as to what to hack next, and how do they go about doing it? What’s all this honking about, anyway? Come learn the answers to these questions and anything else you have in mind. Ask Us Anything!
https://sched.co/eoIZ
A
Hi
everybody
greetings
from
sunny
minneapolis,
where
it
is
just
as
cold
and
snowy
as
it
would
be
in
boston
if
we
were
all
in
the
same
place.
Welcome
to
the
sighconk
ask
us
anything
panel
at
kubecon,
north
america,
2020
virtual
sikhonk
is
not
an
official
kubernetes
special
interest
group.
We
are
a
hacker
crew
and
a
group
of
friends
who
have
been
working
on
various
aspects
of
kubernetes
security
for
a
long
time
now,
and
we're
super
excited
to
be
here.
A
These
questions
have
been
brought
to
us
by
the
community
and
thank
you
all
for
submitting
them.
So,
thanks
for
being
here
with
us,
let's
introduce
ourselves.
My
name
is
ian
coldwater.
I
come
from
a
devops
turned
pen
testing
background.
I
am
now
the
co-chair
of
kubernetes
sig
security
and
the
new
director
of
devsecops
at
twilio.
I've
been
hacking
on
kubernetes
things
for
about
four
years
now,
and
I'm
super
excited
to
be
here.
B
Hey
everyone:
my
name
is
duffy
cooley
and
my
pronouns.
Are
he
him?
I've
been
playing
with
networks,
distributed
systems
and
people
in
this
space
for
quite
a
while,
and
I
really
enjoy
making
in
communities
like
kubernetes,
like
more
approachable
and
and
certainly
more
inclusive.
So
if
you
have
any
questions
or
anything,
I
can
ever
do
to
help
just
reach
out,
I'm
happy
to
do
it.
I've
recently
transitioned
to
apple
and
and
now
I'm
doing
some
of
that
work
there.
So
I'm
really
excited
to
be
here.
C
D
And
I'm
brad
geesman,
my
pronouns:
are
he
him
and
I'm
the
co-founder
of
dark
bit?
A
consultancy
focused
on
cloud
and
kubernetes
security,
posture
assessments,
I've
been
building
and
hacking
on
kubernetes
for
almost
four
years
now
as
well,
and
yes,
geeseman
is
my
real
last
name.
But
it's
no
coincidence
that
I
was
pretty
much
born
to
honk.
A
A
This
goose
in
this
game
kind
of
sneaks
around
and
uses
seemingly
innocuous
everyday
objects
to
chain
them
together.
To
perhaps
do
something
like
exploit
them
for
its
own
ends.
Because
of
this,
because
it's
kind
of
like
the
way
hackers
do
things.
Some
of
us
hackers
kind
of
adopted
this
goose
as
a
mascot
of
sorts,
and
when
we
talk
about
honking
a
lot
of
the
time,
we'll
talk
about
hacking
or
just
causing
problems
on
purpose.
A
B
That's
a
great
question,
I
think
you
know
in
my
mind,
the
old
way
was
when
we
would
rack
up
a
thousand
servers
or
start
up
a
bunch
of
virtual
machines,
and
then
we
would
leverage
tools
to
deploy
some
subset
of
our
application
to
a
subset
of
those
nodes
right
and
and
and
with
that
old
way.
We
had
all
kinds
of
interesting
challenges,
like
you
know,
shared
libraries
and
other
problems.
B
But
the
difference
is
that
now
you
know
where
some
of
the
benefits
of
this
new
security
model
come
in
come
into
play.
Is
that
now
we're
actually
giving
each
of
those
running
processes
their
own
view
of
the
network,
their
own
view
of
the
file
system,
their
own
view
of
the
pid
namespace,
and
these
things
mean
that
we
actually
have
better
isolation
between
processes,
because
we
can
actually
containerize
them.
B
C
Yeah,
I
think,
for
me,
one
of
the
big
things
about
moving
to
kubernetes
and
cloud
native
has
been
this
move
to
automation.
It's
been
this
process
of
everything
being
you
know
automated
and
infrastructure
as
code
and
that's
kind
of
got
trade-offs.
It's
got
good
things
for
security
and
it's
got
some
things
that
are
challenges
so
the
good
things.
For
me,
one
of
the
big
ones,
is
about
repeatability.
C
This
idea
that
you
know
I
can
take
this
code
and
I
can
create
you
know:
10
20,
30
environments
and
for
me,
as
a
security
tester,
it
means,
I
can
say,
hey
spin
me
up
a
new
environment
just
for
my
test,
and
I
can
be
confident
that
my
findings,
you
know,
they're,
going
to
be
relevant
and
the
same
ones
as
you're
going
to
see
in
production.
So
that's
great,
but
the
downside
is
that
we
have
to
think
about
things
differently
now,
so
we
don't
have
pet
servers
anymore.
C
We
can't
just
load
all
our
secrets
up
manually.
We
have
to
work
out
how
we're
going
to
store
them
and
how
we're
going
to
manage
them
securely.
That's
one
of
the
problems,
the
new
problems
that
we
have
to
think
about
and
also
with
everything
being
in
the
cloud
you
know
we
have
to
think
well.
Everything's
exposed
everything's
one
step
away
from
being
compromised,
so
we've
been
really
careful
with
how
we
manage
our
information
and
access
to
things,
because
it's
all
out
there
just
sitting
on
the
cloud.
D
Yeah-
and
I
I
think
there
are
a
lot
of
benefits-
I
mean
the
move
to
api
driven
infrastructure
and
configuration
means
that
there's
you
know
many
more
opportunities
to
bake
security
improvements
into
the
code.
That
is
the
source
of
truth,
as
opposed
to
say
only
being
able
to
bolt
it
on
later
and
those
same
apis
make
it
much
easier
to
query
about
those
security
settings
at
scale
one.
A
So,
as
you
all
said
a
minute
ago,
I
mean
it's
important
to
just
note
in
general
for
people
who
are
building
this
kind
of
infrastructure.
That
what's
old,
is
new
again.
You
know
that
a
lot
of
these
problems,
of
like
the
old
tech,
that
the
shiny
cloud
native
rapper
is
around,
haven't
really
quite
been
solved
yet
so
keep
an
eye
on
those,
but
also
you
can't
just
assume
that
everything
is
the
same.
So
keep
an
eye
on
that
too.
A
You
actually
know
what's
running
in
your
environment,
do
you
actually
know
exactly
what
your
code
does
and
if
you
do
know
what
your
code
does?
Are
you
including
the
perspective
of
an
attacker
persona
in
your
user
personas
if
you
use
those
because
when
I'm
looking
at
a
system,
I'm
looking
at
it
for
things
like?
Where
are
the
holes
in
this?
Where
are
the
trust
boundaries?
Is
there
anything
that
is
going
to
take
unexpected
input
and
do
anything
weird
with
it?
B
This
is
by
thinking
about,
like
what
is
packaged
inside
of
a
container
image
right
that
can
that
whole
container
image
is
going
to
ship
and
it's
going
to
be
running
and
it's
going
to
be
exposed
to
that
long-running
process
on
those
nodes
that
we
were
talking
about
earlier
right,
and
that
means
that
anything,
that's
inside
of
that
container
image
will
be
available.
If
somebody
were
to
get
a
reverse
shell
on
that
node.
B
The
other
thing
I
think
that
is
useful
is
thinking
about
these
new
contains.
You
know
this
container
orchestration
model
we
have
to
think
about.
Like
you
know
what
privilege
has
been
granted
to
that
process
right
like?
Is
it
running
as
a
privileged
container?
Can
it
see
all
of
the
pids
in
the
host
name
namespace?
B
Is
it
able
to
manipulate
network
interfaces?
Is
it
able
to
do
things
like
this
and
there's
a
ton
of
sharp
edges
and
configurability
in
this,
especially
with
regard
to
things
like
kubernetes,
but
yeah,
you
know
what
tools
have
you
left
behind?
What
what
have
you
left
behind
for
your
attackers
is
a
great
way
to
think
about
this.
B
D
Yeah,
that's
a
really
good
one.
So
for
me
a
lot
of
what
I
do
focuses
on
things
from
a
configuration
standpoint,
so
I'll
first,
look
at
the
configuration
of
the
external
network
and
how
access
to
the
control
plane
and
the
nodes
are
configured
and
I'll
kind
of
work.
My
way
in
and
I'll
look
at
the
configuration
of
the
surrounding
cloud
environment
like
say
how
the
cluster
is
situated
and
what
access
it
has
to
other
things,
and
then
I'm
thinking
about
like
the
api
server
and
just
ruling
out
the
obvious.
D
Our
back
flaws,
like
anonymous
secrets
to
you,
know,
access
to
secrets
or,
if
there's
any
applicable,
cbes
and
things
like
that
and
then
sort
of
like
stepping
in
further
kind
of
like
layers
of
the
onion.
I
look
at
the
configuration
of
the
kubernetes
components,
the
cloud
credentials
that
are
attached
to
the
worker
nodes
and
then
sort
of
as
a
unit.
D
The
combination
of
our
back
emission
control
network
access
control
and
container
image
contents
kind
of
all
is
one
thing
to
say:
you
know,
what's
the
overall
security
posture
of
that
given
workload
and
then
I'll
sort
of
step
back
and
work
through
some
what-if
scenarios
for
like
the
common
types
of
attacks
against
like
the
cluster
from
the
outside
or
what
services
are
exposed
and
then
sort
of
take
the
what
happens
if
this
container
inside
the
cluster
is
compromised
and
look
at
it.
From
that
perspective,.
C
Yeah,
I
think
that
ties
it
a
lot
with
what
we
end
up
doing.
I
think,
when
we
end
up
doing
security
assessments
for
customers,
what
we
typically
do
is
we'll
take
one
of
two
approaches.
You
know
we'll
either
take
this
white
box
approach
where
we
can
give
it
access.
You
know
we're
given
access
to
configs
we're
given
access
to
pull
stuff
down
and
there
a
lot
of
what
turns
out
to
be
happening.
C
Is
we
end
up
doing
data
analysis,
pulling
large
quantities
of
json
down
and
parsing
it
and
looking
for
patterns
you
know,
you've
got
a
lot
of
data
to
look
at
automation
and
parsing
is
really
important
and
you're
looking
for
patterns
that
could
indicate
problems,
so
it
could
be
cluster
admin.
You
know
this.
This
process
runs
this
cluster
up
and
that's
going
to
be
dangerous.
It's
also
going
to
be
a
target
for
me
or
other
attackers.
What
about
privileged
containers?
C
You
know,
as
duffy
said
before,
privilege
containers
can
see
all
the
processes
they
can
get
a
lot
more
access,
so
what's
in
there
that
might
be
running
is
privileged,
but
then,
when
we're
doing
the
black
box,
what
we're
doing
is
really
trying
to
take
that
scenario
and
say:
hey,
you
know,
hey,
I
am
a
compromised
container.
You
know
I've
got
access
to
this
container.
What
can
I
do?
Can
I
break
out
of
the
sandbox?
What
rights
do
I
have
do?
C
A
Yeah
totally
what
they
said,
you
know
you
want
to
look
at
like
what
exactly
is
going
on
in
the
environment
that
you're
assessing
like
what's
running
in
there.
How
is
it
running
what
level
of
privilege
does
it
have?
Is
there
anything
that
is
potentially
exploitable
and
then,
if
you
can
get
that,
then
you
kind
of
see
how
far
you
can
go.
Can
you
break
out
of
the
container?
Can
you
break
out
of
the
node?
Can
you
break
out
of
the
cluster
itself
and
go
into
the
cloud?
A
It's
really
going
to
vary
depending
on
what
you
find,
but
it's
really
a
matter
of
like
figuring
out,
what's
going
on,
seeing
how
far
you
can
get
and
a
lot
of
it,
as
you
all
said,
is
pattern
recognition,
but
I
want
to
note
that
if
people
are
watching
this,
who
are
new
to
this,
I
don't
want
the
idea
of
us
using
a
lot
of
pattern,
recognition
to
be
discouraging
to
you,
because
this
isn't
magic.
It
isn't
that
we're
like
wizards
who
have
arcane
knowledge
that
can't
be
gained
by
other
people.
It's
just
that.
A
A
A
How
to
think
like
an
attacker
is
something
I
really
recommend
that
people
do,
because
it
can
be
useful
and
it's
also
fun.
Definitely,
while
we're
on
the
subject
of
pattern,
recognition.
Another
question
that
we
got
that
I'm
going
to
throw
to
you
all
is:
if
somebody
is
a
defender
or
a
cluster
administrator,
what
are
some
indicators
that
a
cluster
or
a
kubernetes
environment
has
been
compromised,
that
people
should
look
out
for,
if
there's
a
breach,
is
there
something
that
people
can
see
that
happened.
B
Yeah,
you
know
going
back
to
the
answer
about
like
how
the
kubernetes
security
surface
has
changed.
I
think
it
actually
highlights.
You
know
some
of
the
complexity
that
we've
introduced
in
this
process
as
well.
So,
let's
think
about
like
the
old
way
in
the
new
way
and
and
glue
these
things
together.
B
That
were
not
that
we
were
not
expecting
something
you
might
not
be
expecting
is
something
modifying
or
opening
the
the
file
etsy
password
right
or
the
shadow
file
or
any
or
other
like
secure.
You
know
or
things
that
you
would
expect
that
not
an
application
that
would
not
do
during
normal
experience.
B
Well,
now,
in
this
new
system,
as
we
as
we
describe
as
we
explore
containerization,
we
have
n
number
of
etsy
password
files
right
because
each
process
sees
its
own
file
system
right
and
so
that
definitely
adds
a
bit
of
complexity
to
the
problem.
Because
now
we
actually
have
to
understand.
You
know
which
password
file
was
a
track
or
was
was
touched
and
which
container
was
it
running,
and
is
that
still
not
normal?
Or
is
that?
B
B
There's
a
great
project
in
the
cncf
umbrella
called
falco
and
falco
basically
operates
at
the
syscall
interface,
and
so
it's
watching
for
system
calls
like
file
open
or
grabbing
a
file
handle
on
etsy
password
against
the
the
linux
kernel
and
then
maintaining
the
context
so
that
you
can
understand
which
container
this
happened
in
and
maintaining
the
context.
So
you
can
understand
which
container
opened
that
network
socket
and
and
really
provides
like
a
a
great
next
generation
audit
d
capability.
So
that's
definitely
how
I
would
start.
D
Yeah
I'll
echo
what
duffy
said
about
you
know
getting
visibility
into
what's
happening
inside
the
containers,
for
that
malicious
activity
is
like
the
primary
source,
like
somebody
could
control
exact
or
a
shell
respond.
You
know,
file
connection
like
duffy
said
those
are
like
great
primary
indicators.
D
I
think
the
next
best
place
to
be
looking
are
the
audit
logs.
So
you
know
the
api
server
audit
logs
and
the
neighboring
cloud
api
audit
logs
are
really
key
in
terms
of
getting
that
clear
smoking
gun
evidence
and
while
it
might
not
be
the
first
thing
that
captures
the
compromise,
it's
probably
going
to
capture
a
lot
of
the
next
steps
that
the
attacker
will
take,
because
they
will
most
likely
find
valid
credentials
somewhere
and
try
those
credentials
against
those
apis.
D
As
they
say
you
know,
can
I
expand
my
access
inside
the
cluster
or
privilege
escalate
or
try
to
escape
out
into
the
nose
or
escape
out
into
the
neighboring
cloud
environment?
So,
for
me,
I
think
you
know
the
one-two
punch
is:
is
malicious
activity,
detection
logs
and
the
audit
logs
in
combination,
so
you
can
really
understand
what
just
happened.
D
So,
hopefully,
security
incidents
like
that
will
continue
to
be
relatively
uncommon,
but
one
of
the
questions
that
might
be
helpful
for
cluster
administrators
to
know
more
about,
is
you
know?
How
do
you
go
about
evaluating
a
project
for
its
overall
security
posture
before
you
take
the
time
to
install
it
and
integrate
it
into
your
own
environment,
like
what
things
are
you
looking
for
and
that
I'll
throw
that
over
to
you
guys.
C
Yeah,
that's
a
really
great
question
and
I
think
obviously
there
are
a
huge
number
of
projects
in
this
space.
So
it's
one
you're
going
to
have
to
spend
some
time
on
the
first
place.
I
would
probably
look,
is
you
know
the
cnc
security
audit
reports?
You
know
every
graduated
project
has
got
an
audit
report
done
by
a
third
party.
Those
are
great
resources,
not
just
for
like
looking
at
code
bugs,
but
also
for
looking
at
how
the
project
you
know
how
what
a
security
posture
is
like.
So
that's
a
good
starting
point.
C
I'll
also
tend
to
look
at
the
websites.
You
know
for
each
project
and
say:
do
you
have
security
contact
information?
You
know,
do
you?
Are
you
encouraging
security
people
to
get
in
touch
and
to
actually
like
get
involved
with
the
project
and
then
the
other
place
I
tend
to
look.
Is
what's
the
happy
path
install
like
you
know?
What
are
the
defaults
this
project
uses?
Are
they
going
to
give
you
a
secure
installation,
because
that's
that
tends
to
be
a
good
indicator
as
well.
A
For
me,
I
wanna
know
how
exactly
the
thing
works
like
technically,
what
are
the
details
of
like
what
exactly
is
it
doing
in
there?
What
kind
of
privilege
does
it
ask
for
what
kind
of
access
does
it
need?
Does
it
have
read,
write
access
to
the
host
to
other
machines
like
as
an
attacker?
I
know
how
I
would
want
to
potentially
use
something
to
break
out
of
it.
How
viable
is
that
and
in
general,
if
I'm
using
it,
if
I'm
thinking
about
using
it
in
my
environment,
how
does
it
fit
into
my
environment?
A
What
does
it
require
to
be
connected
to?
Does
it
conflict
with
anything,
and
you
know
what
does
it
talk
to
and
how
does
it
fit
into
my
threat
model,
because
it's
really
important,
as
I
said
earlier,
to
threat
model
your
environment
figure
out,
what's
in
there
figure
out,
what's
important
to
you
and
see
if
that
project
is
going
to
fit
into
that
larger
goal?
A
B
Yeah,
it's
a
great
question.
I,
for
my
part,
I
think
it's
I.
I
really
maintain
curiosity
about
everything
everything
around
me
all
the
time
like
I'm,
I'm
definitely
one
of
those
question
everything
types
of
people
and
I
find
that
that's
true,
not
just
in
the
way
that
I
evaluate
software
or
the
way
I
evaluate
systems,
but
generally
in
life
like
I
would
look
at
an
elevator
and
realize
I'm
going
to
be
on
this
elevator.
B
You
know
for
20
minutes
of
my
day
every
day,
so
I
wonder
what
else
I
can
learn
about
this
elevator
right
and
might
do
some
research
on
the
type
of
elevator
it
is
and
see.
If
there
are
any
like
you
know,
secret
button
pushes
or
tricks
to
actually
up
to
change
the
behavior
of
this
elevator
in
to
my
benefit
right
like
and
so
for
my
part,
it's
definitely
curiosity
stay
curious.
B
C
Absolutely,
I
think,
curiosity
is
a
big
part
of
it
and
for
me,
like
some
of
the
best
places
I
get,
a
kind
of
inspiration
is
from
trying
to
answer
people's
questions.
You
know
seeing
someone
ask
me
a
double
question:
go
that's
a
good
point.
How
does
that
work?
So
one
of
the
things
I
do
is
I
do
a
training
course
on
container
security,
and
definitely
some
of
my
best
inspiration
has
come
from
a
question
on
that
course
saying
hey.
How
does
that
work?
C
Oh,
and
that
leads
me
down
a
path,
and
you
know
there's
other
places
good
places
as
well.
You
know
you
can
go
to
stack
overflow
or
security
stack
exchange
and
try
and
answer
the
questions
and
doing
that
will
lead
you
to
interesting
places
could
even
lead
to
cves
the
other
one
I
I
like
personally
is
I
go
to
get
up
issues
when
I
go
to
the
kubernetes
issues
list
filter
by
security
just
start
reading
the
issues
finding
out
what
people
are
thinking
about
security
again
that
can
lead
to
interesting
places
or
even
cvs.
A
I'm
also
a
big
fan
of
reading
github
issues
and
not
just
in
the
kubernetes
repository
various
kinds
of
dependencies.
Different
kinds
of
third-party
components
can
have
interesting
questions
that
are
posited
there
too,
because
not
every
bug
necessarily
looks
like
a
security
bug,
but
often
other
bugs
can
be
security
bugs.
So
sometimes,
if
you
read
between
the
lines
in
different
kinds
of
issues
of
people
being
like,
I
found
this
weird
problem.
What's
up
with
that,
sometimes
you
can
find
interesting
things
there.
I
also
really
enjoyed
reading
the
docs.
A
A
lot
of
project
documentation
can
have
interesting
phrases
in
it
like
this
can
provoke
unexpected
behavior
do
not
use
this
in
production.
Please
make
sure
to
change
these
insecure
defaults,
and
things
like
that
that
when
I
see
that
I'm
like
that's
interesting,
what
does
this
mean
and
then
I
want
to
go
chase
it
and
poke
at
it.
Inspiration
can
be
found
from
all
kinds
of
places,
and
personally
I'm
excited
about
that
unexpected
behavior
and
those
intersections
and
corner
cases
of
like
what
you
don't
think
you're
going
to
find,
but
do
so.
D
Yeah
curiosity
definitely
I'm
fortunate
in
that
I
always
get
to
see
a
fair,
a
number
of
different
setups
and
there's
always
something
I
haven't
seen
before.
So
I
like
to
use
that
opportunity
to
get
my
hands
on
it.
I
have
to
you,
know,
see
it
running,
get
it
working
and
then
sort
of
take
survey
of
what
it
needs
and
the
assumptions
and
design
decisions
that
were
made
especially
around
those
defaults,
but
I
don't
like
stopping
there.
You
know
that
might
be.
You
know
job
done,
but
that's
where
I
think
the
fun
just
starts.
D
So
I
go
right
at
poking
and
prodding
I'm
trying
to
knock
it
over
mess
with
its
inputs
and
really
see
how
it
handles
things
when
I'm
really
giving
it
to
things
that
it
wasn't
expecting.
So
all
the
time,
I'm
asking
what?
If
I
do
this,
what
if
I
do
that?
What
if
I
give
it
that
too
much
too
little?
What
if
I
take
that
out
like
what
behavior
emerges
so
like
a
few
months
ago,
I
was
poking
at
a
container
image
manifest.
D
I
was
just
taking
out
the
digest
or
like
modifying
the
url,
to
fetch
a
layer
from
somewhere
else
and
that
just
ended
up
triggering
a
cve
in
a
container
runtime.
So
you
know
things
like
that
that
just
kind
of
pop
out
of
that
emergent
behavior
is
really
where
I
like
to
dive
in
and
get
my
hands
dirty
on.
B
Yeah,
you
know,
I
think,
going
back
to
like
how
we're
changing
things.
You
know
like
how
things
are
changed
under
container
orchestration.
There
is
a
ton
of
space
that
we
haven't
really
spent
a
ton
of
time
with
yet
right,
as
we
think
about
the
way
that
we're
building
that
isolation
model,
you
know
giving
each
process
its
own
network
name
or
file
system,
those
sorts
of
things.
This
is
actually
implemented
by
container
runtimes
and
there
are
several
popular
container
runtimes.
B
B
C
I
I
think
for
me
it
is
all
about
these
layers
and
all
the
different
assumptions
are
being
built
up.
As
we
stack
over
more
and
more
layers.
You
know
from
the
kernel
up
through
docker
through
kubernetes,
into
things
like
service
mesh
and
where
those
layers
meet,
you
get
these
kind
of
possibilities
for
weird
sharp
edges,
corner
cases
stuff
that
could
be
odd
and
we're
implementing
a
lot
of
protocols
that
are
historically
complicated.
Things
like
http.
There
have
been
security
bugs
in
http
servers
for
decades
now
and
also
pki.
C
C
In
particular,
I
think
where
we
ever
see
a
new
layer,
so
every
new
layer
has
a
time
to
settle
down
and
to
work
out
what
security
looks
like
so
at
the
moment,
something
like
operators,
you
know
it's
quite
a
new
thing:
there's
a
lot
of
activity,
there's
a
lot
of
development,
so
there's
probably
going
to
be
opportunities
to
you
know
to
poke
at
it
some
more
and
it's
an
area.
I
think
I'm
probably
more
interested.
You
know
over
the
next
12
months
or
so.
D
Yeah,
for
me,
I've
noticed
you
know
growing
number
of
projects
that
are
extending
the
kubernetes
api
with
custom
resources
and
that's
to
do
things
like
create
more
clusters
and
even
has
like
a
new
abstraction
for
managing
other
cloud
resources,
and
I
think
anytime,
you
give
the
data
plane
of
one
environment
enough
access
and
permissions
to
be
the
control
plane
of
another
environment.
I
think
that's
where
things
can
really
get
interesting
when
those
those
layers
intersect.
A
For
sure
and
yeah
continuing
the
ongoing
theme
of
layers,
you
know,
container
security
is
a
holistic
thing
right.
Your
container
security
is
only
as
good
as
the
security
of
the
rest
of
your
stack
and
for
me
thinking
about
the
way
that
the
different
parts
of
the
stack
interact
present
a
lot
of
exciting,
often
unexplored,
attack
surface.
I'm
really
excited
about
hardware
attacks.
A
I
think
microarchitectural
attacks
are
really
interesting,
like
meltdown
inspector
and
their
variants,
and
I
think
that
there's
a
lot
of
unexplored
territory
about
how
that
can
interact
with
things
like
multi-tenancy
in
the
cloud.
I'm
also
really
excited
one
layer
above
about
ebpf
as
an
attack
surface.
A
I
think
that
that
is
a
very
interesting
unexplored
territory,
where
there's
a
lot
of
fun
things
that
we
haven't
quite
done
yet,
so
I
feel
excited
about
exploring
that
coming
up
and
and
just
getting
to
explore
all
of
the
things,
because
I
think
the
cloud
native
space
in
general
is
so
new,
we're
all
exploring
and
building
this
stuff
together.
There's
parts
of
the
attack
surface-
we
don't
even
know
are
there
yet,
perhaps
because
it
hasn't
been
invented.
A
If
you
want
to
be
further
involved
in
the
kubernetes
project
or
the
security
of
it,
there's
lots
of
work
in
kubernetes
to
do
and
in
the
cncf
landscape
in
general,
kubernetes
and
a
lot
of
these
projects
are
open
source.
There's
lots
of
work
to
be
done.
Lots
of
interesting
problems
to
solve
if
you
want
to
get
involved,
kubernetes
has
lots
of
special
interest
groups
sigs
that
do
lots
of
different
kinds
of
work.
I'm
the
co-chair
of
stick
security.
A
We
have
lots
of
interesting
problems
to
solve
and
we
would
love
for
you
to
get
further
involved
if
you're
interested.
If
you
want
to
ask
us
questions
or
talk
to
us
further
we're
around,
you
can
find
us
on
kubernetes,
slack
or
discuss.kads.io,
and
we
would
love
to
be
able
to
talk
to
you
all
and
learn
with
you
together.
B
Indeed-
and
I
also
wanted
to
highlight
again
that,
like
a
lot
of
the
questions
that
we
answered
during
this
ama
panel
came
from
the
community,
and
I
wanted
to
give
a
shout
out
to
everybody
in
the
community
who
took
the
time
to
ask
us
a
question
for
this
panel,
we
could
not
do
this
without
your
help.
So
thank
you
so
much
for
for
putting
up
questions
and
one
more
thing.