►
From YouTube: How We Survived Our First PCI/HIPAA Compliant Check with Kubernetes - Travis Jeppson, Nav
Description
Join us for Kubernetes Forums Seoul, Sydney, 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
How We Survived Our First PCI/HIPAA Compliant Check with Kubernetes - Travis Jeppson, Nav
At a high level, Travis will go over what it took for Nav to pass their first compliance check with their application in Kubernetes. At a lower level, he'll discuss what PCI/HIPAA compliance is like in a world of containers. How to translate, and prioritize, the requirements from a traditional model, using virtual machines, to using a containerized model. What tools are already provided with Kubernetes, such as taints and tolerances, which tools are plug-ins, such as network policies; and what is missing and requires an external service. D70He'll briefly cover Nav's build pipelines and why adding in security checks into the docker builds is important to maintaining a compliant environment. Finally, he'll discuss how moving forward you can reach a point of attaining a state of constant compliance; there is no reason to struggle to "become" compliant on a quarterly, or yearly, cadence.
To learn more: https://sched.co/Gra0
A
Thanks
for
coming,
everyone
we're
gonna,
get
started,
I
guess
so.
This
talk
is
basically
the
journey
that
we've
taken
over
the
past
year
at
my
company
and
around
how
we
survived
the
first
PCI
and
mostly
PCI,
but
HIPAA
kind
of
included
compliance
check.
So
I
work
for
a
company
called
nav.
What
we
do
is
we
help
try
to
decrease
the
death
rate
of
small
businesses.
A
The
way
that
we
do,
that
is
around
trying
to
help
educate
them
around
business,
credit
and
their
personal
credit,
and
how
those
two
correlate
together
and
help
them
be
able
to
use
those
two
to
empower
them
to
be
able
to
gain
access
to
capital
when
the
time
comes
so
hi,
I'm,
Travis
I
am
a
director
of
engineering
there
at
nap
time.
Here's
my
information.
You
can
always
come
and
download
this
stuff
and
pull
this
up
later.
So
I'm
gonna
skip
that
part.
So
should
you
stay
and
listen
so
my
goal
here
is
really
to
help.
A
So
if
that
interests
you,
then
maybe
you
should
stay.
If
not,
then
you're
more
than
welcome
to
get
up
and
go
I
won't.
Have
my
feelings
hurt
that
bad
I
might
call
you
out,
as
you
walk
out,
though
so
be
warned,
but
okay,
so
to
set
up
some
common
languages
so
that
as
we
go
through
and
talk
about
these
different
things
we're
all
on
the
same
plane.
So
the
first
thing
regulations.
Basically
it's
just
an
authority
rule
dealing
with
decorate
or
details
or
procedure.
A
A
So
here
the
soil
going
from
this,
then
you
know
with
the
regulations
and
what
compliance
means
of
standards
and
classifications,
okay,
so
which
regulations
are
we
going
to
be
talking
about
today?
So
really
it's
any
regulation
that
deals
mostly
around
data
and
data
protection,
which
would
include
HIPAA
and
PCI
DSS.
So,
if
you're
doing
a
compliance
regulation
around
process
or
company
maturity,
this
doesn't
really
necessarily
apply.
A
So,
just
as
a
side
note
I'm
not
a
compliance
expert.
So
if
you
ask
me
about
PCI
regulation
3.2.1
and
ask
me
how
that
affects
global
warming,
I'm
not
going
to
be
able
to
tell
you
I'll
get
back
to
you
on
that,
but
I
typically
land
on
my
feet,
but
at
the
same
time
I,
don't
know
these
backwards
and
forwards.
A
Okay,
so
I
know
that
this
page
is
really
hard
on
read,
that's
there's
a
point,
but
basically
within
PCI
DSS
there
are
six
major
areas
to
it
and
then
there
are
twelve
particular
requirements.
So
within
each
of
these
you
first
have
build
and
maintain
a
secure
Network,
and
that
means
you
have
to
install
and
maintain
a
firewall.
And
then
you
also
you're
not
supposed
to
use
vendor
supply
and
it
defaults
or
system
passwords
and
other
security
parameters.
A
You
also
have
to
maintain
a
vulnerability
management
program,
so
you
have
to
have
anti-virus,
and
then
you
also
have
to
develop
and
maintain
secure
systems
and
applications
then
know
one
thing:
I
forgot,
though,
actually
I
mean.
Let
me
get
through
the
rest
of
these
and
we'll
go
back
to
the
part.
I
forgot
so
implementing
strong
access
control
measures.
A
A
So
it's
a
start.
Data
protection.
You
know
I
just
found
out
that
my
mouse
is
on
there
in
this
giant
screen,
even
though
I
can't
see
it
really,
maybe
in
the
corner,
it'll
be
better
okay,
so
we're
gonna
start
with
data
classification,
so
the
most
important
thing
is
being
able
to
know
what
data
is
in
your
environment
and
being
able
to
know
how
to
classify
that
data
into
different
categories
and
dealing
with
that
data
appropriately,
depending
on
its
classification.
A
So
at
now
what
we
do
is
we
kind
of
classify
into
3
categories.
We
start
with
what
we
call
red
data.
Red
data
would
also
be
what
you
would
say
is
confidential
information?
Ok.
So
this
is
the
kind
of
information
you
don't
want
to
hand
out
on
the
street
and
you
don't
really
want
people
to
get
access
to
being.
Like
your
social
security
number
and
your
passport
information
credit
card
information,
your
driver's
license
number
like
this
stuff
being
used
to
personally
identify
you
and
who
you
are
so.
The
yellow
data
is
data
that
taken
individually.
A
It's
really
hard
to
personalize
to
a
particular
person
so
like.
If
you
take
one
of
the
questions,
I
haven't
gone
here,
I
thought
I
put
your
pet,
maybe
I
didn't
put
you
back.
Oh
then,
making
mall
of
your
first
car
like
I,
could
say
Toyota
you
know,
and
there
could
be
a
million
other
people
that
bought
a
Toyota
first
right,
but
with
yellow
data.
If
you
start
to
combine
a
lot
of
these
together,
then
it
starts
falling
more
in
the
realm
of
red
data.
So
the
idea
behind
yellow
data
is
that
individually.
A
A
Green
data
is
any
information
that,
regardless
of
how
much
of
it
you
have,
there
is
no
way
for
you
to
be
able
to
take
that
data
and
identify
an
individual
so
that
being
like
an
email
address,
username
a
unique
ID,
and
basically
you
know
if
you're
looking
at
a
database-
and
you
have
binary
information
in
there.
Obviously,
you
can't
use
that
tidy
someone,
so
anything
like
that.
You
can
classify
as
green
data
okay.
So
what
talking
about
services?
Your
service
classification
follows
the
data
that
it
houses?
A
Ok,
so
if
you
have
a
red
data
inside
of
your
database,
the
service
that
controls
that
database
is
will
be
classified
as
a
red
service.
And
likewise,
if
you
have
a
green
service,
our
data,
your
service,
can
be
classified
green
right.
So
then
you
get
the
red
green
show
any
of
you,
late-night
TV
fans
of
the
90s
I.
Don't
know
when
this
show
is
popular
a
long
time
ago.
A
So
if
you
have
a
green
service
or
a
green
data
in
a
database,
but
you
decide
to
store
one
piece
of
red
data,
that
least
common
denominator
rules,
and
it
will
actually
cause
in
the
top
middle
right.
So
it
will
cause
that
service
to
become
a
red
service
right.
So
you
can't
the
idea
and
I'm
not
gonna,
leave
this
up
here
long,
but
the
idea
is,
you
cannot
mix
red
and
green
data.
A
You
have
to
pick
one
or
the
other,
okay,
so
knowing
those
classifications
and
knowing
how
to
derive
that
into
a
service
notice,
look
at
environments
and
the
traditional
versus
a
distributed
environment.
So,
first,
if
you
with
your
traditional
environment,
a
very
very
basic
one:
you've
got
a
load
balance
front-end
and
you
have
a
multiple
back-end
and
then
those
backends
I'll
have
data
stores
right.
A
A
So
then,
if
you
look
at
a
distributed
or
kubernetes
service
cloud
native,
then
you
kind
of
get
the
same
thing.
But
if
you
look
at
the
middle
server,
the
problem
there
is
that
that
host
itself,
the
host
that
that
back-end
service
is
on
has
access
to
that
database
and
if
that
cost
is
a
problem
for
that
front-end
system
being
a
great
green
service
because
all
of
a
sudden
you're
exposing
your
your
red
data
to
a
green
service,
so
the
way
to
fix
that
is
to
segregate
those
hosts
away
from
each
other.
A
So
you
want
to
be
able
to
polarize
your
hosts.
So
not
only
do
you
have
to
classify
the
service
with
the
data
as
host
its
housing,
but
you
also
have
to
take
that
to
the
host
level.
You
have
to
take
the
hosts
and
classify
it
to
the
data
that
it
has
access
to.
So
you
have
to
segregate
those
off
and
you
can
do
those
with
logical
separations,
so
you
can
cause
the
two
to
repel
each
other
inside
of
kubernetes
natively.
This
is
already
available
to
us
through
teens
and
tolerances.
A
So
we
got
a
link
in
here
later
on.
If
you
want
to
go
look
at
them,
but
the
idea
with
a
taint
is
you
taint,
an
entire
node?
You
basically
put
a
key
value
against
a
node
as
a
taint
and
that
node
will
not
actually
schedule
your
pods
on
it
unless
those
pods
have
a
corresponding
tolerance
to
match
that
taint.
So
then,
a
tolerance
basically
is
the
reverse
of
that
taint
right.
So
if
we,
if
we
take
and
know
it
and
in
here
it
says,
you
have
the
key
and
then
the
value
no
schedule.
A
So
unless
you
have
a
tolerance
to
tolerate
that
no
schedule,
then
you
won't
the
positive.
Won't
deploy
to
that
so
you'll
get
that
logical
separation,
so
a
tolerance,
as
you
can
see
here,
you
can.
This
tolerance
can
be
defined
in
two
different
ways,
so
you
have
the
key
or
so
the
name
of
it
happened
to
be
key,
and
then
the
value
also
happened
to
be
value,
but
the
effect
was
no
schedule
so
adding
in
that
tolerance
into
this
pot
spec.
A
You
can
actually
classify
that
pod
as
OK
to
be
scheduled
on
to
on
to
that
node.
So
the
pod
spec,
if
you're
wondering
what
that
means.
If
ever
you
define
a
deployment
or
a
replica
controller
or
a
pot
in
and
of
itself,
and
you
get
that
little
spec
section,
that's
where
you
want
to
add
your
tolerance,
so
it
can
be
applied
to
a
pot
itself.
A
Ok,
so
the
other
thing
you
have
to
worry
about
is
pada
pada,
Network
communication.
So
within
this
now
we
have
our
hosts
segregated
off
and
we
have
all
of
our
read
data
on
one
particular
host.
We
have
all
our
green
data
on
other
particular
hosts,
but
at
the
same
time
we
have
we
have
an
API
or
a
front-end
or
something
that
wants
to
be
able
to
communicate
to
that
red
service.
But
we
only
want
one
of
them
to
be
able
to
communicate
to
the
red
service.
A
So
what
you
would
do
here
is
well,
you
have
to
worry
about
your
pod,
the
pod
Network
communication
right.
So
there
are
a
lot
of
different
resources
and
a
lot
of
different
ways
and
to
be
able
to
address
this.
So
some
of
the
one
on
the
first
one
is
using
network
policies.
Now
you
there
is
a
CNI
layer.
You
can
run
within
kubernetes
to
be
able
to
create
that
overlay
network
that
allows
all
the
pots
to
communicate
to
one
another
throughout
your
cluster,
and
you
can
choose
a
lot
of
times.
A
You
can
choose
what
that
CNI
layer
looks
like
now.
Sometimes,
if
you're
on
a
cloud
provider
and
you're
using
their
managed,
cube
root
in
any
service,
you
kind
of
just
get
the
service
that
they
provide
to
you,
but
a
lot
of
times.
Even
then
they
open
up
the
ability
for
you
to
create
network
policies.
Now,
if
you're
running
your
own
kubernetes
and
you
spin
up
your
own
CNI
networking
layer,
you
get
it,
you
can
choose
between
the
plethora
of
them
and
there
are
quite
a
few
more
actually
more
than
just
these
three.
A
A
So
my
advice
here
is,
if
you
are
using
a
cloud
service
that
is
providing
this
for
you,
you're,
probably
good
to
go
now,
if
you're,
not
in
your
spinning,
your
own,
just
be
aware
of
that.
So
talk
with
the
vendor
make
sure
that
everything
is
kosher
and
good
to
go
before
you
try
launching
this
into
production,
which
we
thought
we
did,
but
obviously
we
didn't
test
it
enough.
Once
we
started
putting
more
load
to
it,
then
we
started
having
issues
with
different
reasons.
A
Basically
talked
with
talk,
the
vendor
make
sure
everything
is
good
to
go,
and
then
you
have
some
support
there
so
that
you
don't
have
to
stop
and
rebuild
your
cluster
right
in
the
middle
of
the
day
when
something
starts
going
awry,
so
they
are
good
there
they're
out
there,
and
this
is
a
really
good
way
to
be
able
to
start
defining
the
network
policies
now.
I,
don't
think
I
have
this
on
the
next
one
yeah.
So
another
thing
with
the
network
policy
is
the
great
thing
about
them.
Is
that
it's
using
a
CR
D?
A
The
big
difference
here
is
that
you're
not
using
a
CNI
networking
layer,
so
this
is
stuff
that
typically
will
run
as
side
cars
along
with
your
pod,
which
makes
it
a
lot
easier
to
replace
if
you
do
end
up
with
issues,
but
at
the
same
time,
service
missing
the
down
side.
To
that
that
we
found
out.
Is
it
it's
really
not
a
drop-in
solution
yet
like
there
hasn't
been
one
that
we've
found,
that
we
can
fully
just
say,
go
and
stall
yourself
in
my
cluster
and
make
it
glorious.
A
It
usually
just
brings
it
down
all
right.
So
we
have.
We
have
yet
to
find
that
Golden
Rule
our
silver
bullets
re
not
going
the
rule
so
they're
great,
and
they
can
do
something
very,
very
similar
to
the
network
policies
in
the
sense
that
you
can
define
who
gets
to
talk
to
WHO,
and
that
makes
them
really
really
good,
plus,
on
top
of
that,
they
also
add
in
some
other
features
like
they.
They
open
up
a
ton
of
metrics
and
visibility
into
the
traffic
happening
within
your
network.
A
They
also
give
you
the
ability
to
add
in
TLS
everywhere
so
you're
encrypting,
even
internal
to
your
network,
not
only
on
the
Internet
I
mean
they
give
you
things
like
pop
fellow
verse
or
retries
and
stuff
like
that.
Like
there's
a
lot
of
really
good
reasons
to
use
a
service
mesh,
but
if
you're
using
it
for
strictly
Network
policies,
there
are
probably
easier
ways
to
go
about
doing
it.
So
the
next
one
is
cloud
native
firewalls.
A
You
know
I
kind
of
looked
around
for
these
a
little
while
and
I
really
only
found
two
but
then
I
walked
past
a
booth
that
happen
to
say
cloud
made
a
firewall
and
in
the
vendor
room.
So
apparently,
there's
a
third
one,
but
I
just
I
didn't
add
them
in
here.
I
didn't
have
time
so
anyway,
twistlock
in
aqua.
A
What
they
do
is
they
run
of
the
daemon
set
inside
of
your
cluster
and
they
sit
there
and
watch
the
traffic
happening
between
all
of
your
docker
pods
and
they
can
in
turn
and
then
be
able
to
monitor.
All
of
that
and
tell
you
like
what's
happening
within
your
infrastructure
and
then
within
that
within
a
separate
system,
you
can
go
and
define.
You
know.
This
is
how
my
services
should
be
talking
to
each
other
and
be
able
to
control
them
in
that
matter.
A
So
the
thing
that
we
found
with
cloud
native
firewalls
is
that
it's
actually
I
like
these
more
to
kind
of
just
tell
you
that
things
are
going
the
right
way
and
not
as
much
as
the
actual
way
to
define
this,
so
they
work.
So
the
twist
lock
is
the
service
that
we
ended
up
using
and
they
use
a
machine
learning,
API
or
not
API,
sorry,
a
firewall
which
is
great
because
it
kind
of
teaches
itself
what
services
should
be
talking
to
each
other.
A
But
at
the
same
time,
when
we
want
to
create
a
heart,
it
kind
of
makes
it
very
difficult
to
be
able
to
do
that,
because
the
way
to
teach
it
to
do
that
is
just
not
to
send
that
traffic
to
that
other
pod.
But
if
there
is
traffic
going
from
between
those
two
pods,
then
how
do
you
say?
That's
not
a
good
rule
right.
A
So
in
this
instance,
we
like
these
solutions
to
cloud
the
end
of
firewalls
a
lot
more
just
to
tell
us
if
there's
something
happening,
that
shouldn't
be
happening
and
not
as
much
around
the
actual
application
of
creating
those
divisions
between
the
depositing
to
one
another.
So
we
are
looking
more
at
the
service
mesh
or
the
CNI
networking
layer
to
actually
do
just
the
segregation
and
the
for
the
the
classifications
around
the
networking
so
the
next
part,
and
that
the
data
really
is
kind
of
the
biggest
one
being
able
to
segregate
your
data.
A
Keep
it
separate
being
able
to
know
what
services
have
access
to
that
data
and
which
ones
don't
and
being
able
to
control.
That
is
really
the
biggest
problem
that
we
ran
into.
You
know.
I
mean
so
that's
it
took
up
like
half
the
time,
so
the
next
one
we're
gonna
move
on
to
is
virus
protection.
So
this
comes
from
requirement
five.
This
has
using
regularly
update
antivirus
software
or
programs.
So
the
great
thing
about
virus
protection.
Do
you
go
to
the
docker
website
and
you
go
and
search
the
virus
protection
with
docker?
A
They
actually
get
taken
to
this
page.
I'm
gonna
read
this
really
quick.
It
says
when
a
my
antivirus
software
scans
files
used
by
docker
these
files
may
be
locked
in
a
way
that
causes
docker
commands
to
hang.
One
way
to
reduce
these
problems
is
to
add
the
docker
data
library
on.
Let
me
skip
the
parentheses
to
the
anti
viruses
exclusion
list.
However,
this
comes
with
the
trade-off
that
viruses
or
malware
in
docker
images,
writable
layers
or
of
containers
or
volumes,
are
not
detected.
A
If
you
do
choose
to
exclude
Dockers
data
library,
Dockers
data
directory
from
background
virus
scanning,
you
may
want
to
schedule
a
recurring
task
that
stops
docker
scans
data
directory
and
restarts
docker.
How
many
people
here
have
ever
stop
docker
on
a
node
running
in
production?
Yes,
so
have
I,
it
stops
everything
right.
So
don't
do
that.
It's
not
a
great
thing
to
do
so.
Anyway,
you
read
this
and
you're
just
kind
of
like
what
okay.
A
A
So
the
first
thing
you
have
to
look
at
the
containers
themselves,
so
if
one
of
the
big
pieces
of
this
is
being
able
to
do
static
scanning
of
the
images
now,
there
are
a
lot
of
different
offerings
in
here,
and
it
was
even
brought
up
today
in
in
the
keynote
from
Ocwen
themselves
that
this
is
something
that
some
of
these
tools
are
even
open-source
a
lot
of
the
times.
The
scanning
tool
is
open
source.
A
So
you
can
start
scanning
your
tools
today,
without
any
any
cost
to
you,
I'm
giving
you
do
have
to
go,
find
a
tool
and
start
scanning
them
to
see
what
happens,
but
at
the
same
time
it's
very
easy
to
be
able
to
drop
into,
and
it
gives
you
a
lot
of
information
and
a
lot
of
times.
These
scanning
tools,
they'll
scan
at
the
operating
system,
they'll
scan
the
software
dependencies
you've
installed
inside
of
that
image
for
your
application
and
any
third
party
libraries
or
dependencies
you've
included
as
well.
A
So
and
now
we
use
quite
a
few
languages,
but
Ruby
being
one
of
the
primary
wants
and
a
lot
of
times.
These
scanners
will
even
find
things
within
our
gems
and
they
will
tell
us
if
our
gems
are
outdated,
and
so
it
is
really
good.
You
know,
so
it's
really
good
and
it
gives
you
a
lot
of
information
around
the
software
dependencies
itself,
but
all
around
the
operating
system.
A
So
this
is
this
is
an
absolute
must.
You
absolutely
have
to
be
scanning
your
images,
and
there
was
a
side
note
to
this.
Don't
just
but
don't
just
go
and
scan
your
images
and
then
go
put
them
in
the
repository
and
then
have
your
repository
public
and
open
to
everyone
right.
So
it
does
you.
It
kind
of.
Brings
you
back
to
this
one
right
like
you're,
not
implementing
the
tool
in
the
correct
way.
A
So
what
you
want
to
do
is
you
want
to
scan
your
images,
but
then
you
want
to
have
a
repository
that
you
trust,
meaning
that
there
are
not
a
lot
of
people
that
have
access
to
it.
It's
not
open
to
your
entire
company,
it's
not
obviously
not
open
to
the
world,
but
it's
protected
and
it's
safe
and
is
secure,
and
you
know
that
anything
in
there
is
there,
because
you
put
it
there
right.
A
So
it's
kind
of
a
read-only
operating
system,
and
the
great
thing
about
that
is
that
pretty
much
anything
that's
running
on
that
is
gonna
be
a
container
for
the
most
part,
but
we
do
want
to
make
sure
that
if
anything
weird
happens
on
that
host
that
we
are
either
notified
or
it
gets
killed
or
whatever
else
so.
The
way
that
we
went
about
it
is
we
took
the
immutable
approach.
A
A
So
to
kind
of
give
you
an
example
of
this
within
the
twist
lock
system
itself,
so
they
have
a
section
called
radar
now
inside
of
here.
It
shows
you,
it
kind
of
doesn't
show
you
because
there's
this
giant
picture
in
the
front,
but
I
couldn't
find
another
picture,
but
it
shows
you,
you
taught
your
ecosystem
and
it
also
shows
you
like
the
rating
of
each
of
your
systems,
whether
you
can
see
one
in
the
corner
right
here,
but
you
get
a
green
one
versus
like
a
really
really
dark
red
one.
A
You
obviously
don't
want
the
really
really
dark
red
ones,
but
you
can
kind
of
see
where
your
vulnerabilities
may
lie
within
your
own
system
and
then
by
clicking
on
them-
and
this
is
as
far
as
I
know.
This
is
the
same
through
most
of
the
offerings,
but
when
you
click
on
them-
and
it
gives
you
a
detailed
report
as
to
which
issues
are
critical,
which
ones
are
high
and
how
to
address
those
and
fix
them,
which
is
even
better
so
and
then
here.
A
This
shows
you
an
incident
that
happened
within
a
container
and
either
you
get
a
hijack
process.
Someone's
poor
scanning
you
or
you-
have
some
lateral
movement
within
the
container
itself
and
then
again
like
we
just
let
twist
lock
shut
it
down.
So
the
next
piece
is
authorization
and
authentication.
Now
the
great
thing
about
this
one
is,
it
literally
is
one
slide,
so
kubernetes
role
based
access
control
for
the
way
here.
Kubernetes
already
has
role-based
access
control
built
in,
and
I've
got
a
link
here
for
you.
A
But
basically
you
get
a
define
a
roll
here,
we're
creating
a
pod
reader
where
you're
able
to
get
watching
list
on
pods
right.
Then
we
want
to
bind
that
to
someone
so
here
we're
taking
jane
and
we're
giving
jane
of
the
role
of
pod
reader
right.
So
jane
is
now
able
to
go
in
and
get
watch
and
list
pods
and
that's
all
she's
able
to
do
from
that
control
and
so
being
able
to
authorize
and
restrict
access
to
people
that
only
need
at
least
a
need-to-know
basis.
A
Right
Bob
may
not
need
to
be
able
to
list
the
pods
because
he's
in
marketing,
so
we
don't
want
Bob
to
be
able
to
come
in
and
start
looking
at
pods,
but
Jane
may
be
a
developer
and
is
something
that
she
needs
to
do
so
being
able
to
control
that
within
kubernetes
is
really
really
easy.
I'm
using
the
rback
system
now
the
last
piece
being
I
always
get
these
backwards
authentication.
A
So
what
we
did
with
authentication
is
we
used
our
Google
accounts
and
then
we
tied
that
to
the
kubernetes
open
ID.
Now
there's
even
a
script.
The
kubernetes,
oh
I,
CD
helper,
that
you
login
to
Google
and
go
authenticate
as
yourself,
and
then
you
can
use
this
to
then
generate
your
Kube
config
file.
So
then
that
cube
config
file
then
identifies
you
particularly
into
the
your
different
clusters
and
you
identify
as
you
and
then
with
our
back-end
this
tied
together.
A
A
From
requirement
10,
this
basically
just
means
that
you
know
you've
got
three
big
areas
to
worry
about.
Here.
You
need
to
be
able
to
audit.
You
need
to
have
logging
any
need
to
have
monitoring
so
the
auditing.
You
need
to
know
what
happened
in
your
system
when
things
change.
As
far
as
the
system
is
concerned,
logging,
you
want
to
know
what
your
system
is
doing,
what
your
applications
are
doing
and
monitoring.
A
A
So
two
things
make
it
easy
for
developers,
because
if
it's
not
related
to
barbequing
or
if
it's
not
related
to
the
latest
topic
of
functional
versus
object-oriented
programming
in
the
office,
then
a
lot
of
times
you're
gonna
lose
their
interest.
But
then,
at
the
same
time
you
need
to
make
it
easy
for
your
operations,
because
if
it's
not
related
to
Star
Wars
or
it's
not
related
to
teaching
them
how
to
throw
their
phone
off
the
window,
a
3m
when
they
get
paged,
then
they're,
probably
gonna
lose
interest
right.
A
So,
within
the
logging
and
monitoring
system
we
had
to
come
to
a
compromise
on
both
sides.
We
had
to
make
something
that
was
super
simple
for
the
developers
and
then
it
ended
up
being
their
code
themselves.
We
didn't
want
to
pull
them
into
a
different
codebase
use,
a
different
tool
or
something
else.
A
We
figured
out
tools
that
would
work
with
their
code
and
so
that
they
didn't
have
to
add
in
dependencies
or
anything
else,
and
they
loved
that
then,
on
the
operational
side
and
the
things
for
us
was
really
around
the
process
of
workflow
like
we
didn't
want
to
have
to
add
in
additional
steps.
In
order
to
to
do
more,
we
just
wanted
things
to
kind
of
run,
the
way
that
they
were
so
those
are
the
things
to
consider
when
looking
at
those
options.
A
So
finally,
vulnerabilities
and
I
think
I'm
running
out
of
time
so
pipeline
best
practices.
The
vulnerabilities
really
just
comes
down
to
using
things
inside
your
pipeline,
really
so
vulnerabilities
inside
the
applications
themselves,
but
you
want
to
move
your
static
image
container
scanning
to
your
pipelines
so
that
every
time
they
build,
they
know
whether
or
not
they're,
building
or
causing
new
vulnerabilities
inside
of
your
system,
and
this
is
again
very
simple
to
do.
A
lot
of
the
open
source
tools
are
very
centric
to
the
CLI
and
you
can
own
them
inside
your
pipelines.
A
Then
another
big
thing
for
us
is
that
you
want
to
use
images
that
you
trust,
so
we
created
an
Alpine
image
and
we
had
all
of
our
other
images
built
off
of
that.
So
if
we
wanted
to
push
out
an
operating
system
patch,
we
pushed
it
to
our
gold
master
image
and
then
that
would
then
at
any
time
a
developer
built
after
that
would
pick
up
that
fix
and
when
they
deployed
it
would
go
out
into
production.
A
Then
two
more
things
so
static
application
and
dynamic
application
security
testing.
So
there
are
again
our
tools
for
these,
but
again
try
to
as
much
as
you
possibly
can
add
them
into
the
pipeline,
so
that
all
of
your
security
and
all
of
your
tests
are
happening
in
the
pipeline
and
in
your
developers,
get
that
immediate
feedback
as
soon
as
possible
about
knowing
whether
or
not
they're
causing
any
new
vulnerabilities
or
issues.