►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel: Kubernetes and Cloud Native Security: A State of the Union - Rags Srinivas, InfoQ; Gareth Rushgrove, Snyk; Kirsten Newcomer, Red Hat; Scott Coulton, Microsoft; & Phil Estes, IBM
With the advent of Containers, Kubernetes and microservices, and platforms that build on it, like Helm, openshift, Istio, etc. the attack surfaces have increased and that necessitates a more holistic and disciplined approach towards security. While there is a lot of FUD around cloud native security in general there are approaches to harden security during development and deployment today. This panel, intended for developers and devops audience will look at the cloud native, containers and Kubernetes security ecosystem. Attendees will walk away with a better understanding of the challenges of some of the tools for the trade and how to overcome some of the security gaps that exist today.
https://sched.co/ZeqF
A
Good
morning
and
good
afternoon
or
good
evening
from
wherever
you're
joining
appreciate
it.
So
this
is
a
panel
on
kubernetes
security
and
you
know
cloud
native
security.
There
is
a
perception
out
there,
unfortunately,
that
community
security
is
insecure
by
default,
but
I
have
a
panel
in
august
panel
really.
You
know
the
first
time,
I'm
doing
a
panel
in
august
and
there
is
an
august
panel
joining
from
every
part
of
the
world,
I'd
like
to
welcome
them.
A
First
and
and
then
you
know
I'll,
let
them
introduce
themselves
and
in
the
meantime,
for
those
of
you
who
have
joined
this
panel.
I'd
appreciate,
if
you
can
use
the
q
a
box,
you
know
to
queue
up
the
questions.
You
can
start
queuing
and
queuing
them
up
right
now
and
I'll
start
prioritizing
them.
If
you
have
a
question
to
a
particular
speaker,
you
know
feel
free
to
do
that.
A
A
So
if
you
can
provide
as
much
context
as
possible
that'll
be
great,
I
have
a
set
of
questions
that
I
I
have
queued
up,
but
what
I'm
going
to
do
here
is,
you
know,
hope
that
you,
the
attendees,
will
be
asking
the
questions
and
I
don't
have
to
fall
into
my
bank.
So
with
that
said,
let
me
do
a
quick
intro
of
myself.
A
My
name
is
raghavan
srinivas
and-
and
I
am
a
developer
myself-
I
come
from
really
the
java
and
the
cloud
foundry
background
and
I
just
want
things
to
work.
I
am
a
big
fan
of
kind
of
seeing
the
you
know:
applications
being
stood
up
easily
a
big
fan
of
frameworks
like
draft
and
scaffold,
and
things
like
that,
which
makes
it
kind
of
approach
the
same
philosophy
that
cloud
foundry
has
with
that.
B
Hi,
I'm
scott
carlson,
oh
yeah
there.
I
am
I'm
scott
colton,
I'm
actually
in
sydney
at
the
moment,
so
fun
fact.
It's
quarter
to
two
a.m.
In
the
morning
I
work
for
microsoft.
I'm
the
developer,
leave
for
containers
and
my
interest
is
everything
to
do
with
light
run
times
and
jupiter's
security.
So
that's
what
I
mostly
focus
everything
all
my
efforts
on.
A
C
D
D
A
A
E
E
More
deeply
involved
in
our
is
platform
stack,
so
that
now
includes
the
operating
system
below
the
hypervisor
layer,
and
so
I'm
very
interested
in
in
everything
from
like,
like
kristin,
said,
supply
chain
security,
the
operating
system,
the
the
core
components
at
the
runtime
layer
up
through
the
kubernetes
stack
so
yeah.
Looking
forward
to
this.
A
A
A
Some
overlap
between
operations,
admin,
running
cubecuttle
versus
doors,
running
application
command,
and
hence
we
are
running
into
these
roles.
Profiles,
configurations
even
more
complex
for
operation
admins.
Is
it
okay
to
reuse?
Kubernetes
are
back
even
for
my
application,
cli
to
keep
it
simple,
also,
lesser
complexity
in
configuring
roles
and
profiles.
Only
at
one
place
that
yamafly.
What
is
your
opinion
on
this?
Let's
start
with
phil,
since
he
was
he
was
on
just
now.
Phil.
Do
you
want
to
take
this.
E
E
C
Yeah,
I
think,
ultimately,
it's
like
there's
not
one
right
answer.
Unfortunately,
I
think
it's
always
going
to
be
about
trade-offs
and
this
sort
of
balance
of
how
much
you
let
kubernetes
bleed
through
into
your
applications,
do
developers
need
to
know
kubernetes,
I
think,
is
a
question
that
doesn't
have
a
right
answer.
It's
it's
not
it's
not
binary!
It's
not
yes
or
no,
and
I
think
it's
that
question
you
need
to
ask
which
isn't
just
a
security
question
that
me
like.
C
I
think
bleeding
through
something
quite
as
rich
as
committee's
role,
where
sex
control
can
sort
of
have
like
the
opposite
effect.
The
security
comes
in
through
people
not
fundamentally
understanding
all
that,
because
it's
complex,
so
I
think
there
isn't
a
definite
answer.
It
does
depend,
but
I
think
that
think
about
generally
whether
you
want
to
expose
kubernetes
to
developers
or
not.
D
A
Gotcha,
here's
a
question
that
that
I
think
you
know
is
relevant
to
all
the
panelists
and
I'll
start
with
scott.
The
question
comes
from
jake
klein.
Unfortunately,
I
don't
know
if
I
can
make
it
public,
but
maybe
it's
public
already,
but
in
any
case
you
know
it's
a
simple
question,
but
you
know
a
fairly
lengthy
answer.
I
would
expect
what's
holding
back
communities
from
being
secured
by
default.
Let's
start
with
scott.
B
This
is
a
really
interesting
one.
I
was
just
reading
this.
Actually
I'd
argue
for
some
reason.
I
knew
you'd
throw
this
to
me.
I
don't
know
why
yeah.
This
is
a
really
interesting
question
and
the
reason
why
I
think
upstream
kubernetes
has
so
many
security
configurations
that
are
not
turned
on
by
default
is
because
it's
meant
to
be
implemented
by
different
folks
and
what
that,
what
I
mean
by
that
is
openshift
implementation
compared
to
azure's
implementation
compared
to
gk's
implementation
is
different.
B
Once
you
start
using
like
a
provider,
that's
building
kubernetes
for
you,
you'll
find
that
there
will
be
secure
defaults
on
for
you.
I
know
we
do
it
some
stuff
in
azure,
but
there's
also
there's
a
line
in
the
sand
where
it's
like
operability
versus
security
and
there's
only
so
much
a
provider
can
do
and
make
it
easy
for
the
developer
as
well.
Anything
beyond
that.
B
It
needs
to
go
to
like
the
security
profession
of
that
organization,
because
it
could
be
a
nuance
that
90
of
the
customers
running
on
aks,
don't
need,
but
10
of
the
customers
do
need.
So
that's
why
and
I
think,
as
we're
getting
into
as
we
just
spoke
about
service
mesh
and
other
capabilities
on
top
of
it.
B
Secure
by
default
looks
a
lot
different
for
different
folks,
like
yeah
like
if
you
take,
for
example,
istio,
and
you
can't
just
go
well
we're
gonna,
do
one
policy
for
identity
and
that'll
work
for
every
customer
it
just
it
just
won't
work.
So
that's
why
I
think
there's
nothing
really
holding
us
back
as
per
say:
there's
always
work
we
can
do,
but
it
comes
down
to
the
implementation
of
kubernetes
and
the
customer
needs.
C
I
I
think,
I'm
following
on
from
scott's
point
that
when
you
say
kubernetes
do
you
mean
a
distribution
of
which
can
come
with
more
opinions,
or
do
you
mean
the
underlying
software,
which
invariably
is
optimized
for
for
distribution,
for
people
to
build
things
on
top
of
it,
and
I
think
that's
the
tension
ultimately
as
well.
Changing
things
in
hindsight
is
really
hard,
and
so
I
think
now
we're
sort
of
five
plus
years
on
some
of
the
original
design.
Decisions
could
be
like.
C
We
would
do
that
different
in
in
hindsight,
but
making
that
change
now
would
fundamentally
change
like
it
sort
of
make
kubernetes
more
difficult
to
adopt
for
everyone
who
comes
next.
At
this
point,
I
think
the
addition
of
our
back
was
a
good
example
where
the
community
said.
Actually
we
need
to
do
this.
We
need
to
break
things
in
order
to
make
it
to
induce
that
capability.
So
there
is
precedent
for
kubernetes
being
fundamentally
breaking
backwards.
C
Compatibility
for
security
reasons,
I'd
like
to
see
higher
level
primitives,
I
think
introducing
kubernetes
that
have
better
secure
defaults
than
the
lower
level
ones
that
are
there
pods
and
deployments
even
and
but
also,
I
think,
there's
there's
been
a
conversation
there
of
like.
Let's
see
those
things
emerge
in
the
community
first
and
they
haven't
done
yet,
and
so
I
think
that's
where
we
start
start
up
start
outside
kubernetes
have
some
higher
level
primitive
that
sits
above
deployment
adopt
widely
adopted
with
better
secure
defaults.
C
A
E
Sure
yeah
I
mean
just
one
a
couple:
oh
sorry,
yeah.
I
think
one
one
quick
thing
that
kind
of
ties
in
with
the
idea
of
you
know
distributions
or
use
cases.
I
think
the
narrower
your
use
case,
the
more
you
can
implement
sort
of
a
secure
by
default
system.
For
example,
if
I
build
a
functions
as
a
service
offering
with
kubernetes
as
the
substrate,
I
have
a
much
more
limited
set
of
container
images
that
run
because
maybe
I've
enforced
a
certain
policy
around
that.
E
So
I
think
because-
and
I
think
gareth
referred
to
this-
you
know
kubernetes
this
concept
of
it's
something
to
build
other
things
with.
I
think
there
is
this
tension
between
adding
all
and
turning
out
all
these
features
in
the
base
platform
versus
what
do
I
build
with
it,
and
therefore
what
can
I
enforce,
given
my
potentially
narrower
use
case
than
the
entire
kubernetes
ecosystem.
D
Sure
great
thanks,
so
I
think
everybody's
done
a
great
job
covering
the
distribution
angle,
which
I
think
is
is
absolutely
right.
This
is
very
similar
to
what
happened
with
linux,
as
linux
has
a
lot
of
complexity
as
well,
and,
and
you
look
to
the
distributions
to
provide
security
out
of
the
box
and
automated
ways
to
configure
for
security.
D
So
I
do
think
it's
really
going
to
be
interesting
to
see
where
the
community
goes,
because
I've
also
seen
an
uptick
in
interest
in
securing
kubernetes
in
the
community.
Recently,
red
hat
has
had
security
context
constraints
as
an
admission
controller
from
early
on
to
help
ensure
that
malicious
containers
couldn't
be
deployed
easily
onto
the
container
or
privilege.
Escalation
was
prevented.
D
That
became
pod
security
policies
upstream,
but
even
though
you
know,
cisco
benchmarks
recommend
pod
security
policies,
the
community's
still
not
convinced
about
that
so,
and
I'm
starting
to
see
a
drift
towards
oppa
and
gatekeepers
so
to
to
gareth's
point
about
kind
of
security
that
is
maybe
at
a
higher
level
or
kind
of
at
the
perimeter
of
the
kube
cluster.
I
think
that
may
be
where
we
start
to
see
the
community
be
interested
in
investing.
A
Yeah
great
thanks,
so
one
note
to
panelists,
you
guys
are
all
very
congenial
nice
to
each
other.
Can
we
see
some
disagreement
a
little
bit,
I'm
just
kidding,
but
but
in
any
case,
let's
go
to
the
next
question,
which
is:
how
far
are
we
away
from
the
true
zero
touch
communities,
development
pipeline
ecosystem?
You
know:
how
far
are
we
really
going
as
far
as
not
having
any
human
accessible
accounts
in
the
system
anymore?
C
I
think
it
depends
on
who
you
are.
I
think
some
people
will
be
saying:
no,
no,
we
do
this
already
and
other
people
will
be
saying
like
we're,
never
going
to
get
there.
I
think
that
it's
a
classic.
The
future
is
here,
it's
just
not
evenly
distributed
so
I'll,
rather
than
think,
is
it
possible?
Can
you
build
this?
Can
people
can
people
do
this?
Because
I
think
the
answer
is
yes,
there
are
people
doing
this.
Is
it
easy
to
do?
C
Do
you
need
to
do
a
lot
of
configuration
yourself
and
a
lot
of
composition
yourself
of
a
lot
of
tools?
Yes,
absolutely
I
I
think
that
sort
of
mythical
distribution
of
everything-
I'm
not
sure
that
will
ever
quite
exist
out
of
the
box
like
at
least
in
a
sort
of
time
frame
that
the
a
lot
of
the
people
around
the
kubernetes
community
think
about,
because
I
think
we
build
components
and
we
integrate
components
and,
at
some
point,
yeah
they'll
get
industrialized,
but
the
component
builders
will
probably
move
on.
A
E
D
Oh,
I
was
just
going
to
say:
I
think,
that
the
concept
of
kubernetes
operators
helped
to
move
us
in
the
direction
where
you
can
start
towards
less
and
less
human
interaction,
but
but
I
do
think
that
that
it
does
kind
of
require
a
lot
of
building
and
investment,
but
sort
of
the
combination
of
operators
with
the
get
ops
or
argo
cd
model.
I
I
think,
create
a
lot
of
possibility.
C
Yeah,
I
think
that
the
fundamental
thing
there
is
control
loops.
Can
you
can
you
manage
all
operational
sort
of
instructions
by
some
form
of
control
loops?
However,
you
implement
that
again.
I
think
the
answer
is.
Is
yes,
but
you
will
have
to
build
a
lot
yourself
and
that
might
be
a
greater
cost
than
you're
willing
to
pay
today.
A
B
I'm
not
sure
on
this
one.
This
is
a
cloud
native
one.
I
have
seen
some
people
do
some
stuff
around
a
wasp
and
like
the
kubernetes
api
and
a
few
other
bits
and
pieces
like
that,
I'm
not
sure.
If
there's
like
an
official
one,
you
can
go
to
every
day.
That's
updated,
like
the
the
proper
wasp.
Does
anyone
else
know
if
there's
like
an
official.
C
I
I've
got
an
opinion
here
that
the
answer
is
actually
it
is
the
obos
top
10.
the
fact
that
you're
running
your
applications
on
kubernetes
versus
some
other
platform
versus
like
with
some
other
new
technology,
doesn't
change
the
fundamentals
of
application
security
and
the
the
risks
outlined
in.
Are
they
always
top?
10
are
still
the
things
that
are
going
to
get
you
some
of
them.
You
can
actually
really
apply
very
specifically
to
kubernetes
configuration
risk
is
one
of
the
sort
of
issues
there.
C
It's
always
been
a
problem,
it's
in
there
as
a
sort
of
popular
risk,
popular,
maybe
the
wrong
word,
but
that
is
that's
a
generic
problem
like
whether
you're
on
kubernetes
or
not
applied
to
kubernetes.
It's
obviously
you're
going
to
have
a
lot
of
configuration
at
the
moment
around
the
kubernetes
cluster.
That's
definitely
something
you
should
apply
to,
but
I
think
fundamentally,
application
security
hasn't
changed
with
kubernetes.
The
olaf
top
10
is
still
a
good
list
of
things
to
apply.
A
Great
gareth
I'll
come
back
to
you
because
there
was
another
question
on
kind
of
shifting
security
left.
But
but
let
me
get
to
this
next
question,
which
is
about
what
do
you
think
is
the
correct
layer
to
enforce
security
concepts
like
image
signing?
Is
it
the
container
runtime?
Is
it
the
email
registry
or
some
operator
within
kubernetes,
and
I
let
phil
try
this
phil?
Well,
if
you
want
to
jump
in.
E
Yeah,
so
that's
an
interesting
question
to
me
just
because
again,
I've
been
mostly
focused
on
the
runtime
layer
and
images
and
oci
distribution
and
there's
there's
a
lot
of
folks
involved
here.
Most
of
the
cloud
providers
most
of
their
registry
teams
are
involved
in
an
effort
called
notary
v2.
I
think
there
was
even
a
talk
about
it
earlier
today
or
even
a
working
group,
so
there
are
a
lot
of
smart
people
looking
at
this.
E
You
know
this.
This
is
where
most
of
the
action
has
been.
I
think
it
is
interesting
because
I
work
for
a
cloud
provider
to
try
and
figure
out.
You
know
where
the
hook
should
be
because
now
in
my
kubernetes
layer,
I
want
to
know
that
somewhere
in
my
stack,
the
image
signature
was
checked
by
the
right.
You
know
piece
of
the
stack
and
then
I
can
actually
trust
and
verify
that
happened
because
kind
of
like
what
gara
said.
E
E
There
are
a
lot
of
potential
gaps
and
holes
there
to
make
sure
that
my
kubernetes
stack
knows
how
to
interact
with
my
runtime
layer
and
my
image
registry
to
to
validate
what
I'm
trying
to
you
know
claim.
I
know
I
know
where
my
images
came
from
and
I
know
who
signed
them
so
anyway,
lots
of
good
work
happening
in
this
area,
but
it's
definitely
something
that
cloud
providers
and
security
folks
are
very
interested
in.
A
Okay,
the
next
question
comes
from
casper
nissan
thanks
for
asking
the
question
and
I
myself
am
a
developer.
So
the
question
is
shifting
security
left.
How
do
you
make
developers
care
about
security
because
you
know
as
a
developer?
I
really
don't
want
to.
You
know,
do
too
much,
but
just
make
it
work
right.
You
know
so.
So
what
are
your
parts?
Let's
start
with
kirsten.
D
D
No
developer
wants
to
be
told
just
as
they're
ready
to
deploy
their
app
to
production
that
the
security
team
has
said.
Nope
sorry,
you
know
there's
this
late-breaking
problem
that
we
just
learned
about,
and
you
have
to
go
back
and
start
over.
So
I
think
the
real
value
is
making
it
easy
for
the
developers
to
check
and
build
security
in
themselves
and
get
sign
off
from
the
security
team
during
those
early
stages,
so
so
that
and
and
and
they're
going
to
get
value
by
knowing
they're
not
going
to
get
blocked
at
the
end.
C
I
do
and
I'm
actually
gonna
cheat
a
little
bit
here
because
I
know
casper
a
little
bit.
Casper
is
a
software
engineer.
He's
on
he's
come
along
to
a
panel
about
security,
and
you
ask
that
question
and
I
would
posit
that
actually
developers
like
they
want
to
know
about
security.
They
do
think
security
is
important.
C
I
think
organizationally
lots
of
organizations
have
told
them
it's
not
their
problem
and
that's
the
or
they've
put
up
barriers
that
make
security
not
about
technology,
and
I
think
that's
there
is.
There
is
an
aspect
of
security.
That's
a
lot
more
about
information
security,
there's
a
there's,
a
risk
management
aspect,
there's
a
compliance
aspect.
C
That's
not
the
same
thing
as
security
and
organizations
in
lots
of
cases
have
sort
of
put
those
two
together
put
them
into
a
department
that
deals
with
risk
and
compliance
and
then
said:
oh
we've
got
a
security
department.
Oh
don't
don't
worry
developers,
you
don't
need
to
worry
about
security
anymore.
I
think
it's
organizational
that
organizations
and
organizational
structures
that
have
been
the
problem.
I
think,
if
you
say
hey
like
security's
interesting,
I
mean
that's
how
I
got
into
security
from
a
from
being
a
developer.
C
A
B
Does
pod
security
policy
need
to
be
in
kubernetes,
or
does
it
need
to
be
abstracted
outside
of
the
distribution
and
then
handled
by
something
like
open
policy
agent?
So
at
the
moment
there
is
more
than
just
opa
as
well.
There's
others
other
projects
out
there
open
source
projects
that
are
trying
to
achieve
the
same
thing.
B
So
what
was
what
we're
starting
to
see
is
like
increased,
increased
cap
capabilities
there
and
then
having
a
plug
into
like
the
distribution
of
kubernetes,
because
one
of
the
issues
we'll
have
is,
if
we
keep
building,
kubernetes,
bigger
and
bigger
and
bigger
and
bigger
and
bigger,
with
all
these
things,
it
won't
it
like.
It
comes
with
consequences
as
well.
B
So
this
is
one
of
the
first
projects
that
I've
seen
where
they're
looking
at
something
that's
in
base
companies
at
the
moment
and
they're
looking
at
objecting
it
out
to
a
third-party
application
and
seeing
how
the
community
takes
it.
I
really
think
it's
exciting
and
I'm
I'm
just
watching
it
and
seeing
where
it
lands
it's
still
early
days
at
the
moment
and
if
anyone
else
has
an
opinion
jumping.
C
I
think
it's
worth
noting
that
this
change
this
has
triggered
a
change,
and
not
just
this.
This
is
triggers
changing
how
the
kubernetes
project
treats
beta,
so
possibilities
has
been
in
beta
for
basically
ever
and
hasn't
changed.
I
think
in
the
last
five
or
six
releases,
the
the
the
new
policy
as
of
like
the
related
release
kubernetes
communities
ago,
is
that
things
that
they
think
that,
basically,
I
think
you
have
two
releases
now
and
it's
either
then
you're.
C
C
I
think
that
in
hindsight,
excuse
like
pod,
secured
policies
addresses
specific
needs,
but
the
the
actual
need
is
bigger,
so
basically
people
found
that
it's
useful,
but
not
sufficient
and
therefore
having
something
else
outside
that
actually
duplicated
that
functionality.
You
need
that
as
well,
so
you
might
as
well
just
have
that
and
that
that
I
think,
is
allowing
innovation
to
happen
outside
again.
I'm
involved
in
the
open
pulse
agent
project,
but
there's
others
as
well.
C
D
D
A
A
Do
you
know
about
any
attacks
targeting
communities
clusters
in
general
and
how
would
we
protect
against
those
kind
of
attacks?
Obviously
you
know
I
mean
I
I
think
we
have
talked
quite
a
bit
about
you
know
in
generalities,
but
but
I
mean,
are
we
really
making
a
bigger
deal
than
it
should
be?
I
guess
is
the
tenor
of
the
question
here
or
maybe
I'm
reading
it
wrong.
D
E
Yeah
yeah
yeah,
so
so
I
I
don't
understand
the
connection
with
node
modules,
but
the
rest
of
the
question
is
interesting
in
that
you
know
there
are
quite
a
few
security
and
infosec
people
making
a
name
for
themselves.
I
think
giving
talks.
Even
in
the
last
two
hours,
there
were
a
couple
talks
about
very
specific
attacks
and
cves.
So
you
know
there
are
clearly
attacks
that
target
kubernetes.
E
Specifically
there's
been
some
some
great
talks,
even
across
the
last
few
kubecons
about
ways
to
you,
know,
target
and
attack
kubernetes
clusters
and
obviously,
there's
been
a
good
response
from
the
kubernetes
security
team
in
closing
some
of
these
holes.
You
know
that
it's
a
huge,
wide
open
discussion
about
how
could
we
protect
against
these
kinds
of
attacks?
E
A
A
C
I
was
just
gonna
say
I
think
one
of
the
most
sort
of
common
things
you
you
hear
about
securing
kubernetes
at
the
moment
is
still
basically
just
publicly
accessible
control
planes.
I
think
it's
that
there
are
advanced
threats.
There
are
advanced
attackers,
but
please
secure
you
can
secure
your
like
kubernetes
api
server
on
the
internet.
That's
still
the
thing.
That's
gonna,
unfortunately
end
up
with
you
often
running
a
load
of
crypto
miners.
Most
people
aren't
and
some
people
are
working
in
industries
and
organizations
where
people
really
care
about
you.
C
A
Great,
I
know
there's
a
huge
list
of
questions
and
you
know:
kubernetes
security
is
not
easy
to
talk
in
about
40
minutes,
but
hopefully
you'll
join
our
slack
discussion,
app
dev
on
slack,
but
I'll
give
you
know.
I
really
want
to
thank
the
panelists.
Like
you
know.
I
know
scott
woke
up
at
one
o'clock.
You
know
to
kind
of
do
this
panel,
which
is
which
is
great.
A
You
know,
I
don't
think
I
would
have
done
that,
but
but
I
really
want
to
thank
everybody,
the
panelists
all
of
you
for
the
great
questions
and
what
I'll
do
is
I'll
give
like
in
the
last
two
minutes.
You
know
if
you
can
go
around,
you
know,
starting
with
scott
and
then
going
down.
If
you
have
anything
you
know
quick
last
few
words.
B
Just
have
a
look
at
your
business
needs,
have
a
look
at
your
risk
management
and
then
have
a
look
at
what
controls
you
can
put
around
companies
to
make
it
flexible
for
your
application
developers,
but
also
have
a
good
security
posture.
I
think
once
you
try
to
have
a
start
looking
in
in
that
sort
of
realm,
you
start
to
to
kick
some
goals.
C
Yeah
I'd
say,
like
I
mean
if
you've
come
along
to
this
panel,
if
you're
interested
in
security
in
this
area
like
come,
get
involved,
if
you're
an
expert,
that's
fine.
If
you're
not
there
are
some
serious
experts
to
learn
from,
and
I
think
learning
security
in
the
context
of
this
community
is
actually
probably
more
approachable
than
lots
of
other
places.
You
could
do
so
join
in
with
like
sig
security
joining
with
the
policy
working
group.
C
D
Yeah
great
thoughts
from
everybody
and-
and
I
just
want
to
echo
one
thought
that
was
mentioned
briefly
earlier-
I
think
maybe
by
gareth,
but
but
I
think
culture
is
an
element
that
we
really
that
it
can
be
easy
to
neglect.
When
we
focus
on
the
technology
so
kube
and
containers,
they
challenge
some
of
the
traditional
approaches
to
security.
D
The
same
principles
really
apply.
They
apply
in
new
ways,
but
I
think
the
cultural
shift
is
in
many
ways
the
most
important
one
to
try
and
tackle
and
and
the
more
that
you
get
involved,
the
more
that
you
learn,
the
better
able
you
may
be
to
help
your
organization
kind
of
make
that
shift
left
and
collaborate
and
break
down
the
silos
for
our
new
cloud
native
world.
E
Yeah
great
panel
thanks
for
inviting
me,
I
think
I
think
even
you
know,
as
garris
said,
if
you're
interested
there
there's
so
much
out
out
there,
even
just
scrolling
through
the
security
identity
policy
track
from
the
last
few
days.
I
know
I
moderated
a
talk
by
andrew
martin
earlier
today
that
had
tons
of
detail
just
on
container
isolation.
A
Thank
you
again
thanks
everyone
for
attending
thank
the
panelists,
but
I
would
be
also
remiss
if
I
wouldn't
thank
the
people
behind
the
scenes.
You
know
there's
a
whole
tech
crew
who's
helping
here
I
would
love
to
thank
you,
know
the
cncf
for
doing
such
a
great
job.
So
you
know
scott
who's
behind
the
scene,
matt
who's
behind
the
scene.
Thank
you
all
very
much
with
that
said.