►
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.
Making Compliance Cloud Native - Ann Wallace & Zeal Somani, Google
If you’re in a highly-regulated industry, you likely have compliance requirements which make it challenging to adopt containers. Traditional compliance frameworks such as PCI and ISO 27001 were written for traditional architectures and have not yet adapted to cloud-native technologies. We’ll first discuss misconceptions that auditors believe about cloud-native technologies and architectures. Then, we will demonstrate how to meet compliance requirements – like segmentation, encryption, supply chain management, and monitoring – in a containerized environment, using our OSS K8S compliance starter kit. Lastly, we will share techniques for communicating these learnings with audit and compliance officers. Attendees will come away from this talk with knowledge of how technologies like Kubernetes can actually make compliance easier and how to shift left security and compliance requirements.
https://sched.co/ZetI
A
So,
let's
understand
this
problem.
First,
whether
you
are
a
regulated
bank
or
an
e-commerce
store
running
a
regulated
workload
is
quite
complex.
Why?
Because
you
have
multiple
stakeholders,
you
have
the
makers
and
the
checkers,
the
makers,
which
is
you
know,
mainly
your
developer
community
and
then
the
checkers,
your
your
security
folks,
your
you're,
risking
compliance
folks
and
then
you
know,
legal.
A
A
Now.
Having
said
that,
as
these
workloads
are
primed
for
modernization
and
to
become
cloud,
optimized,
containers
and
kubernetes
are
are
favored
within
our
makers,
community,
mainly
for
two
reasons:
one:
it
enables
microservices
and
a
service
oriented
architecture,
so
you
can
break
apart
a
large
giant
monolith
into
smaller
chunks
and
you
can
run
it.
You
know
at
different
places,
giving
you
better
flexibility
and
agility.
It
allows
for
multi-cloud
and
hybrid
deployments.
A
Our
checkers,
which
you
know
our
security
folks,
are
risking
government
governance.
Folks,
they
love
them
too,
because
you
can
inherit
a
lot
of
security
defaults
from
your
cloud
provider
and
it
allows
for
blue
and
green
deployments
to
reduce
the
downtime
and
to
reduce
downtime
and
business
continuity
risks.
A
However,
not
everything
is
hunky-dory.
A
compliance
conversation
is
always
incomplete
without
an
independent
regulator
or
an
auditor
which
rolls
us
to
regulatory
audits
which
are
cyclical,
seasonal
and
can
make
our
makers
and
checkers
a
little
anxious.
Why?
So,
when
you
look
at
when
you
closely
look
at
an
audit,
there
are
two
main
steps:
one.
You
have
to
scope
the
audit
accurately
and
you
have
to
evidence
the
controls
with
a
monolith.
You
basically
have
you
know
one
front-end,
one
back-end
and
one
app
server.
A
So
it's
really
easy
to
scope,
scope,
the
monolith
or
scope.
The
audit,
and
you
know,
evidence
the
control
on
that
on
a
monolith
versus
as
you
move
as
you
move
towards
microservices
with
containers.
You
have
these
containers
running
in
different
cloud
providers.
You
enter
into
a
shared
responsibility.
It's
hard
to
draw
a
boundary,
it's
hard
to
evidence.
The
shared
responsibility,
as
there
are
multiple
control
owners.
A
This
is
another.
Why,
in
general
audits,
can
be
quite
daunting
because
of
the
things
on
the
left-hand
side
right,
the
compliance
frameworks
are
not
cloud-native.
It
takes
a
village
to
pass
an
audit
fear
of
misconfigurations
and
then
evidencing
the
short
responsibility.
So
how
do
we
make
this
experience?
You
know
pain-free
or
you
know
more
pleasant,
and
we
are
going
to
talk
through
this
during
the
rest
of
our
presentation.
A
The
underlying
question
is
what
are
these
compliance
requirements?
So
what
we've
done
is
we've
looked
at
different
compliance
frameworks
such
as
pci,
dss,
nist
853
for
fedramp
27001,
and
what
we
see
is
that
the
compliance
requirements
fall
in
one
of
these
pipe
buckets,
we'll
cover
some
of
these
areas
in
our
presentation.
A
So,
let's
start
with
segmentation
and
networking
segmentation
and
networking
can
look
challenging
with
containers,
especially
with
all
the
requirements
on
the
left.
You
know
things
that
I
mentioned
on.
The
left
has
to
be
demonstrated
to
it
to
your
auditor
it
and
that
that
becomes,
you
know
quite
cumbersome.
So
let's
dig
a
little
bit
deeper
on.
You
know
what
segmentation
is
and
how
does
it
relate
to
compliance
frameworks.
B
A
Most
compliance
frameworks-
segmentation
is
really
not
a
compliance
requirement,
but
it
is
a
best
practice.
It
is
an
opportunity
for
you
to
demonstrate
to
your
auditor
what
is
in
scope
versus
out
of
scope
and
establish
a
strong
audit
boundary.
When
you
have
proper
segmentation
and
networking
controls
in
place,
your
audit
will
go
really
fast.
Being
an
auditor
myself,
you
know.
I
ask
the
first
thing
that
I
ask
my
audits
is
show
me
your
audit
boundary
with
respect
to
containers.
A
So,
let's
spend
some
time
understanding
the
both
types
of
segmentation.
Let's
start
with
cluster
networking
or
cluster
segmentation
within
a
cluster,
each
part
has
its
own
ip
to
segment.
The
parts
use
network
policies,
network
policies,
work
similar
to
your
vpc
firewall
rules,
so
you
can
allow
or
deny
traffic
based
on
ip
rules.
A
Building
upon
that
segmentation.
Now
you
have
segmented
the
parts
within
the
cluster,
but
you
further
need
to
demonstrate
separation
of
dev
and
test
environments
versus
the
plot
environment
to
your
auditor,
or
you
need
to
segment
application
profiles
where
one
application
contains
sensitive
information
versus
other.
Doesn't.
This
is
where
you
use
name
spaces.
A
A
So,
let's
check
through
the
components
of
a
service
mesh
here
is
deal
with
an
example
one
you
have
an
on.
You
have
a
network
proxy
here
with
it
is
onboard
that
intercepts
the
service
to
service
communication.
Then
you
have
pilot,
which
runs
the
control
plane.
Number
three
is
mixer
that
enforces
security
policies
and
then
number
four
is
citadel.
That
offers
service
to
service
committee
authentication
via
a
certificate
authority.
A
A
You
can
also
enforce
mtls
for
service
to
service
communication
or
service.
To
end
user
communication
to
ensure
encryption
in
transit,
so
we've
spoke.
You
know
we
spoke
a
little
bit
about
service
mesh
and
it
establishes
a
strong
boundary.
But
how
to
keep
you
know?
The
next
step
is
how
to
keep
the
assets
inside
the
boundary
private,
which
is
again,
you
know
a
common
compliance
requirement.
A
This
is
where
this
is
where
you
need
to
net
into
your
kubernetes
footprint,
and
you
have
two
options
you
can
use
the
manage,
you
can
use
a
manage
net
from
your
cloud
provider
or
you
can
use
an
open
source
tool
like
calico
that
integrates
well
with
other
service
meshes
kubernetes
private
cluster.
This
is
another
great
feature
that
allows
you
to
keep
things
private,
an
important
compliance
checkbox
in
private
cluster.
A
You
know
you
have
your
connection
from
master
to
node,
completely
private
through
vpc
peering
off
the
cloud
provider,
or
you
can
make
that
endpoint
public,
where
you
can
allow
certain
ip
addresses
to
connect
to
the
master,
so
this
will
allow
this
is
really
a
good
use.
This
is
a
great
use
case
for
road
warrior,
use
cases
where
developers
and
admins
are
working
remotely
and
they
need
to
access
the
master
over
the
internet.
A
To
sum
up,
this
is
how
you
build
segmentation
in
and
around
a
cluster
and
demonstrate
a
strong
audit
boundary.
However,
a
common
question
I
get
is
that
you
know
this
is
great.
Kubernetes
is
great.
Networking
with
it
is
great,
but
how
do
I
communicate
those
controls
to
my
auditor?
My
auditor
does
not
understand
containers
and
cloud.
So
how
do
I
explain
these
concepts
to
them?
Being
an
auditor
myself,
I
can
relate
to
this
really.
Well,
you
know
on
the
other
side
of
the
table.
This
is
where
I
at
you
know.
A
So,
let's
move
on
to
data
protection
with
data
protection.
It's
all
about.
You
know
encrypting,
all
things.
Well,
almost
all
things
everywhere
ensure
your
app
is
flips
validated
or
fixed
compliant.
If
there's
a
need
for
one
and
then
you
know,
if
you're
using
encryption
for
data
protection,
you
you
want
to
have
strong
key
management
procedures,
so
you
know
for
for
for
for
data
in
flight,
as
I
mentioned
before,
a
great
great
control
is
use
of
service
mesh
at
rest.
A
A
So
you
might
say
you
know,
with
kubernetes,
aren't
the
secrets
already
encrypted
in
etcd?
No,
they
are
not
because
they
are
base64
encoded
and
they
are
not,
which
is
not
encryption.
Anyone
with
access
to
etcd
has
access
to
the
secrets
in
plain
text.
Hence
it
is
important
to
protect
your
kubernetes
secrets
and
we
recommend
to
use
envelope
encryption
envelope.
Encryption
is
the
practice
of
encrypting
data
with
a
with
one
key,
which
is
called
the
data
encryption
key,
and
then
you
encrypt
the
that
key
with
a
different
key.
A
So
we've
talked
about
you
know
our
data
protection
and
and
the
three
areas
now
let
let's
quickly
go
through.
Some
must
use
as
you
look
at
cloud
native
technologies,
so
step
number
one
or
number
one
you
know
have
a
time
to
live
on
your
data
beyond
your
ttl
make
sure
the
data
is
securely
deleted,
especially
if
the
data
is
residing
in
the
cloud
you
want
to
shred
the
keys
and
and
if
it
is
residing
in
the
cloud.
A
A
You
know,
pips
140-2
has
different
different
levels
of
compliance,
understand
which
encryption
modules
from
your
cloud
provider
are
flips,
validated
or
not,
and
lastly,
key
management.
You,
the
main
thing
with
key
management,
is
to
set
rotation
policies
for
your
keys
and,
if
you're
using
you,
know,
envelope
encryption,
if
you
have
decks
and
kecks
you
want
them
to
be
separate.
You
want
to
keep
the
pets
at
least
equally
strong
or
stronger
than
the
deck.
B
So
if
we
look
at
the
different
stages
of
the
software
supply
chain,
first,
the
developer
checks
code
into
git.
Then
an
image
is
built
and
then
tests
are
run.
So,
as
your
container
images
are
being
built
and
pushed
to
your
registry,
they
might
be
scanned
for
known
security,
vulnerabilities
and
categories
based
on
cve
rate
gains.
This
is
a
common
compliance
requirement
and
then
at
the
the
employee
stage
you
can
use
tools
like
open
policy,
agent
or
credis
to
create
deployment
policies
and
deny
deployment
in
your
environments
based
on
these
policies.
B
I
don't
have
enough
time
to
dive
into
all
the
details
of
kubernetes
emission
controller
or
open
policy
agent,
but
the
tldr
is
open
policy
agent
or
opa
is
a
cncf
project.
It's
a
policy
engine
that
can
be
used
to
enforce
policies
across
multiple
parts
of
your
stack,
such
as
kubernetes,
terraform
or
infrastructures
code
and
then
api
authorization
and
then
api.
An
emission
controller
is
a
piece
of
code
that
intercepts
the
request
to
the
kubernetes
api
server
prior
to
persistence
of
that
object,
and
then
the
request
is
authenticated
and
authorized.
These
are
static
and
dynamic.
B
There
are,
there
are
static
and
dynamic
controllers
and
we're
going
to
focus
on
the
dynamic
controllers
are
also
known
as
emission
web
hooks.
So
if
we
look
at
kubernetes
with
open
policy
agent
first,
the
cube
api
server
sends
a
kubernetes
object
into
the
web
hook.
Request
to
opa
opa
then
evaluates
the
policies
it
has
loaded.
Then
opa
policies
generate
an
admission
review
response
that
is
sent
back
to
the
api
server.
A
minimal
response
of
true
or
false
also
note
that
policies
can
be
loaded
as
a
config
map.
B
So
in
the
case
of
pci,
maybe
we
have
an
e-commerce
store.
That's
selling
some
hipster
items,
we'll
call
hipster
store,
so
they
want
to
make
sure
that
all
their
load,
balancer
traffic
is
over
port
443,
so
they
have
created
a
policy.
So
on
the
left,
we
have
an
opa
policy
written
in
rego.
In
a
nutshell,
this
checks.
First,
if
the
kind
of
object
be
is
a
service
and
the
request
is
of
the
operation
is
create
and
that
the
port
is
not
443.
B
If
it
is,
then
they
deny
the
request
and
print
an
error
message
and
again
this
can
be
loaded
as
a
config
map
and
then
on
the
right.
We
have
a
load
balancer
service.
This
would
fail
when
created
since
it's
trying
to
use
port
80..
To
recap,
the
kubernetes
api
server
is
configured
to
query
opa
for
emission
control
decisions
when
objects
like
pods
or
services
are
created,
updated
or
deleted.
B
So
now
our
friends
at
hipster
store
have
policies
for
the
infrastructure
they
want
to
make
sure
are
they're
using
while
deploying
containers
that
meet
their
compliance
requirements.
So
they
make
sure
that
only
trusted
images
are
deployed
in
certain
environments.
To
do
this,
they
are
using
open
source
projects,
graphes
and
credas.
B
It's
worth
noting
that,
while
cretis
is
a
kubernetes
specific
project,
graphios
can
be
used
to
store
more
than
just
container
image
metadata.
So
the
credence
policy
example
on
this
page
shows
a
policy
used
to
prevent
deployment
of
pods
with
critical
vulnerabilities
unless
that
vulnerability
has
been
whitelisted.
B
So
putting
this
all
together
when
a
developer
code
is
checked
in
a
github,
it
triggers
a
build.
In
this
case.
It's
cloud
build
cloud.
Build
then
generates
a
new
container
image.
It
will
create
a
build
record
that
contains
information
on
the
image,
including
the
location
of
the
source
from
which
the
image
was
built.
The
vulnerability
scan
is
also
done,
and
then
the
results
of
that
scan
are
stored
as
part
of
the
metadata
for
that
container.
B
In
graphas,
when
a
deployment
request
is
made,
the
pod
spec,
which
includes
the
container
that
was
just
built,
goes
to
the
cube
api
server
and
like
opa
creatus,
is
deployed
as
an
emission
controller
web
hook.
Kritis
checks
the
policy
against
the
metadata
and
attestation
starting
of
phase
and
either
accepts
or
rejects
employment
into
the
hipster
cluster.
B
Okay,
runtime
security,
so
runtime
security
allows
you
to
identify
containers,
acting
maliciously
in
production
or
any
other
environment,
and
take
action
to
protect
your
workload.
So
we
just
talked
about
how
to
validate
compliance
requirements
before
you
even
deploy
something
into
production,
but
what
about
post
deployment?
In
other
words,
you
did
all
this
work
to
make
sure
your
containers
are
going
to
be
secure
and
meet
compliance
requirements.
But
how
do
you
make
sure
it
stays
that
way?
B
So,
when
we
look
at
some
of
the
compliance
requirements
that
you
need
to
meet
a
lot
of
them
say,
yes,
you
really
need
to
log
all
the
things,
but
there
are
very
specific
things
you
need
to
log
and
monitor.
You
need
to
be
able
to
track
events
back
to
the
actual
user.
You
need
to
monitor
for
security
events,
and
then
your
logs
need
to
contain
information
like
user
event,
date
and
time
and
etc.
B
So
many
logs,
really
don't
change
significantly
for
containerized
environments,
for
example,
network
logs,
look
pretty
much
the
same
as
long
as
you
can
tie
an
ip
address
back
to
a
single
pod
rather
than
the
node
it's
running
on.
We
typically
focus
on
four
types
of
logs,
so
your
infrastructure,
logs
kubernetes
logs
os
logs
and
application
logs.
B
B
So
kubernetes
audit
logs
are
actions
taken
in
kubernetes,
so
a
given
request
will
generate
events
at
multiple
points
in
this
life
cycle.
So
when
a
request
is
received
when
a
response
is
started
when
a
risk
and
when
a
response
is
completed,
the
kube
api
server
processes.
These
events,
according
to
your
audit
logging
policy
and
then
we'll
log
them
and
just
like
other
types
of
logs
kubernetes
log
events,
can
be
at
a
different
depths
of
detail
based
on
the
information,
that's
included
with
them.
B
B
B
B
B
So
you
get
a
few
minutes,
so
zeal
touched
on
the
importance
of
diagrams
early
on,
but
I
just
want
to
reiterate
it
here.
It
doesn't
really
matter
how
cloud
native
bleeding
edge
or
uber
secure
your
application,
stack
or
cloud
is,
if
you
can't
explain
it
to
your
auditor.
This
is
why
good
diagrams
are
so
important,
so
start
with
something
simple
like
segmentation
here
and
then
deal
drill
a
little
bit
deeper.
B
So
maybe
then
you
talk
about
how
the
network
is
segmented
and
the
controls
you
have
in
place,
and
you
know
the
slide
looks
very
similar,
similar
to
most
networks.
So
then,
you
maybe
will
you'll
dive
a
little
bit
deeper,
and
this
is
where
you
get
into:
maybe
the
kubernetes
and
container
specific
network
controls
like
network
policies,
istio
ingress
configurations,
etc.
B
All
right,
I
admit,
yaml,
is
not
that
cool,
but
as
far
as
compliance
goes,
the
yaml
used
for
declaring
your
kubernetes
plus
your
git
workflow
is
self
documenting,
meaning
you
don't
have
to
do
anything
differently
to
drag
down.
Who
did
what,
when
your
change?
History
can
be
tracked
in
your
git
history.
This
isn't
just
for
your
load.
Balancer
changes
like
this
slide.
It
applies
to
any
changes
in
your
cluster
managed
the
same
way.
It
is
good
to
walk
your
auditor
through
this
and
show
the
change
history
and
peer
reviews
great.
B
B
So
if
you're
working
on
developing
a
cloud-native
application
that
needs
to
meet
compliance
requirements,
the
makers
are
most
likely
the
folks
you're
working
with
on
a
day-to-day
basis.
You
probably
don't
need
to
convince
some
of
the
benefits
of
cloud
native
technology,
but
you
can
be
one
of
the
advocates
for
the
compliance
team,
so
explain
the
controls
you
need
to
meet
and
how
having
clear
documentation
and
diagrams
will
pay
off
dividends
in
the
end.
Explain
how
the
git
workflow
they're
already
using,
can
be
used
as
an
audit
trail
later.
B
The
internal
checkers
are
the
teams
whose
butts
are
probably
on
the
line.
If
you
found
out
your
application
does
not
meet
compliance
requirements.
They're
also
also
less
likely
to
understand
cloud
native
technologies,
since
it's
not
really
part
of
their
day-to-day
job.
This
is
where
empathy
comes
in.
Put
yourself
in
their
shoes.
B
Understand
you
all
work
for
the
same
company
and
ultimately
want
the
same
thing:
to
make
money
from
awesome
products
and
keep
the
company's
name
out
of
the
news
from
security
incidents,
so
invite
these
folks,
like
the
security
or
grc
teams
early
and
often
to
your
standups
or
architecture
reviews
and
then
make
them
feel
part
of
the
team
and
that
their
opinion
matters.
You
know
invite
them
to
learning
sessions
and
brown
bags
and
then
check
in
with
legal
on
your
diagrams
or
documentation.
B
So
just
a
side
note,
I
went
to
pci
isa
training
last
year.
Let's
just
say
my
eyes
are
really
open.
The
trainers
couldn't
answer
a
lot
of
my
questions
when
it
came
to
pci
and
containers
and
because
of
this
zl
and
I
have
been
actively
involved
with
pci
council
and
we're
working
with
them
and
other
cloud
providers
on
better
documentation
and
cloud
training.
B
So
the
tldr
on
this
presentation-
and
yes,
we
could
have
started
with
this-
we
might
not
have
stayed,
is
kubernetes
and
cloud
native
makes
compliance
a
lot
easier
in
places
in
some
places
like
logs.
It's
pretty
much
the
same
teach
people
what
you
know
make
cloud
native
security,
compliance,
less
scary
and
then
automate
things,
including
infrastructure's
code
and
policy,
is
closed
as
much
as
you
can,
because
this
will
make
compliance
less
burdensome
and
then
understand
the
shared
responsibility
model
between
you
and
your
cloud
provider
and
we're
here
to
help.