►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
As
we
all
know
as
engineers,
we
all
strive
to
use
the
best
technology
to
solve
the
problems.
We're
facing
and
cloud-native
infrastructure
and
containerized
workloads
are
fueling
that
innovation.
Nowadays,
I
was
reading
a
cncf
survey
that
said
that
92
percent
of
the
organizations
surveyed
are
using
containers
in
production
and
83
of
those
are
using
kubernetes
in
production.
So
there
is
wide
adoption
of
kubernetes
and
the
use
of
kubernetes
is
increasing
at
the
same
time
we're
seeing
an
increase
in
cloud
adoption
through
our
research.
A
So
having
security
in
mind,
while
using
cloud
native
technologies
is
important,
so
let's
start
discussing
one
of
these
technologies
called
helm
and
I
think
the
best
way
to
do
that
is
to
take
a
look
at
similar
technologies.
For
example,
if
I'm
trying
to
install
a
package
on
my
mac,
I
usually
use
homebrew
to
install
that
package.
Whenever
I
have
an
option-
and
here
you
see
how
I
would
install
my
sql
on
my
laptop
and
homebrew-
takes
care
of
figuring
out
all
the
dependencies
necessary
and
any
updates.
A
A
Another
way
to
get
my
sql
is
to
use
docker
that
my
sql
docker
image
comes
pre-packaged
with
everything
you
need
to
get
a
mysql
database
running
as
a
docker
container.
Here's
an
example
of
how
you
would
run
that
if
you
already
have
docker
installed
on
your
laptop.
This
is
an
easy
way
to
get
mysql
without
having
to
bloat
your
local
system
and
it's
a
good
option.
If
you
need
an
informal
database
for
local
testing,
where
once
you're
done,
you
can
just
destroy
your
container.
A
A
So
I
like
to
break
down
the
steps
we
need
to
follow
to
use
helm
securely
into
three.
The
first
step
is
to
identify
the
security
requirements
and
the
best
practices
applicable
to
the
system
you're
trying
to
secure
this
is
going
to
be
specific
to
your
project
and
the
business
objectives
of
that
project.
The
next
step
is
to
use
something
called
policy
as
code,
and
this
is
where
we
take
the
policies
and
requirement
that
we've
identified
and
convert
them
into
a
declarative
language
that
can
be
used
to
evaluate
our
infrastructure
configuration
code
and
the
helm
charts.
A
A
So,
let's
start
with
step
number
one,
and
this
is
where
we're
identifying
the
policies
that
are
applicable
to
our
system
and
capturing
our
requirements
and,
like
I
said,
different
systems
are
going
to
have
different
requirements.
So,
for
example,
a
banking
system
is
going
to
have
a
different
requirement
than
a
music
streaming
service
or
an
e-commerce
application,
and
the
important
thing
here
is
to
identify
what
are
those
requirements
going
to
be
early
in
the
project?
So
you
can
start
evaluating
your
infrastructure
and
configuration
against
the
requirements
as
early
as
possible.
A
What
we're
trying
to
visualize
with
the
triangle
is
that
if
we
make
the
most
secure
system,
that
system
is
probably
not
going
to
be
usable
or
functional.
For
example,
if
we're
trying
to
secure
a
network,
the
most
secure
network
will
be
the
one
where
I
kill
all
the
network
traffic
to
it,
and
no
one
can
access
the
network.
A
A
The
next
place
to
look
for
in
terms
of
security
controls
that
will
be
applicable
to
your
systems
are
frameworks
or
any
compliance
requirements
that
you
may
have,
or
industry
standards.
Depending
on
the
data
you're
collecting
or
the
type
of
system
you
may
be
subject
to
the
payment
card
industry
requirements
in
pci,
vs,
the
dss
or
hipaa
for
health
systems,
or
if
you're,
collecting
personal
information
in
europe,
you
may
need
to
be
gdpr
compliant.
A
A
So
once
you
have
those
requirements,
it's
helpful
to
think
about
the
security
risk
categories
and
how
to
categorize
the
requirements
in
these
data
protection
deals
with.
How
do
we
protect
any
sensitive
data
that
our
system
could
be
handling,
so
things
like
using
encryption
at
rest
or
encryption
in
transit
will
be
examples
of
security
controls
in
the
data
protection
category
access
management
is:
how
do
we
make
sure
that
any
system,
people
or
process
accessing
our
system
are
only
authorized
to
access
the
functionality
they
need
with
network
security
and
platform
security
controls?
A
A
A
And
looking
at
the
tldr,
we
can
see
how
straightforward
it
is
to
install
this
chart
with
the
clink
quick
glance
at
the
introduction.
We
can
see
that
the
chart
includes
mariadb
chart
as
a
dependency
and
that
the
memcache
chart
is
also
one
of
the
dependencies.
A
A
The
first
one
is
to
ensure
that
there's
no
secrets
in
environment
variables.
The
reason
this
is
important
when
you're
dealing
with
a
third
party
software
is
that
sometimes
there's
applications
that
dump
the
state
of
the
environment
as
part
of
error
logs
if
the
environment
contains
secrets.
That
means
that
anyone
with
access
to
the
error
logs
would
also
get
all
the
secrets
in
that
in
the
environment
variables.
So
we
want
to
make
sure
that
we
avoid
these
whenever
possible.
A
The
second
security
requirement
is
to
avoid
containers
running
as
root.
Although
there
are
runtime
security
features
in
kubernetes
that
protect
us,
we
will
still
have
the
increased
likelihood
of
processes
within
the
root
containers
breaking
out
and
escaping
which
affects
the
risk
of
your
host
and
other
containers
running
within
that
host
since
we're
using
third-party
containers
from
a
public
health
chart.
This
is
something
to
be
mindful
of.
A
So
there's
an
option
well
within
kubernetes
to
allow
parts
that
have
to
have
privileges
that
the
parent
process
did
not
have
such
as
set
user
id
and
set
group
id
file
file
mode,
and
you
can
control
that
with
the
allow
privilege,
privilege
escalation
parameter.
We
want
to
make
sure
that
this
is
set
to
false
on
home
charts
we're
using
to
avoid
privileged
escalations
in
those
containers.
A
A
A
The
more
traditional
approach
to
security
is
just
handing
over
security
requirements
to
engineers
and
then
perfectly
checking
through
scripts
tools
or
manually,
but
these
have
been
implemented
at
runtime.
There
are
multiple
benefits
of
using
as
policy
is
killed,
instead
of
or
in
combination
to
traditional
approaches,
and
I
want
I
want
to
highlight
a
few
of
these
benefits.
A
The
first
benefit
is
that
you
can
implement
your
security
requirements
with
low
friction
when
we're
delivering
security
requirements
as
code
and
as
a
declarative
language.
There's
no
ambiguity
into
what
needs
to
be
accomplished
in
order
to
meet
the
requirements.
You
can
reduce
the
number
of
gates
and
interactions
between
engineers
and
security,
and
the
system
can
be
tested
throughout
the
sdlc
to
ensure
that
the
requirements
are
met.
A
The
next
benefit
is
that
your
system
will
be
secure
from
the
get-go
having
implemented
security.
Upfront
would
reduce
the
number
of
issues
that
need
to
be
addressed
once
you're
in
a
run-time
production
environment.
Since
we've
identified
the
requirements
we
need
to
implement
from
the
beginning
and
have
tested
our
system
against
these
with
automation,.
A
A
So,
let's
look
at
how
we
can
implement
policy
as
code
using
an
open
source
tool
called
open
policy
agent
or
opa.
Opa
is
a
cncf
graduated
project
and
the
tool
allow
us
to
have
a
unified
language
and
framework
to
do
policy
evaluations
in
our
systems.
So
we're
going
to
take
the
three
security
requirements
that
we
identify
in
step
number
one
of
our
example
architecture
and
convert
them
into
a
policies
code,
language
using
the
regal
language
from
opa.
A
So
let
me
walk!
You
walk
you
through
this
line
by
line
what
we're
trying
to
detect
in
this
regal
rule.
So
if
you
look
at
line
number
one
we're
trying
to
extract
the
api
definition
from
our
deployment,
then
on
line
number
two
three
and
four
we're
getting
the
environment
variables
in
our
containers
specification.
A
All
these
lines
so
far
contain
variables
that
we're
using
to
walk
through
the
kubernetes
yml
file
that
we're
evaluating,
and
that
will
be
a
little
bit
more
clear
on
the
next
slide
line.
Number
six
is
the
expression
where
we're
testing,
if
there's
a
value
named
secret,
key
ref,
which
would
mean
that
there's
a
secret
being
used
in
an
environment
variable
which
is
the
issue
we're
trying
to
detect
with
its
regal
rule.
A
So
here's
the
regal
next
to
the
yaml
file
that
violates
the
rule.
So
looking
at
line
number
six
at
the
demo
on
the
right,
we
see
where
the
container
are
specified
and
then
on
line
number
nine.
We
have
our
environment
variable
and
if
we
look
at
line
number
12
and
number
17,
we
see
where
there
are
a
couple
of
variables
for
a
username
and
password
being
used,
which
would
be
in
violation
of
our
regal
rule
and
would
trigger.
A
A
So
in
this,
in
this
second
regal
we're
going
to
identify
when
the
allow
privilege
escalation
parameter
is
set
to
true
or
when
it's
not
defined,
as
we
don't
want
the
platform
or
help
chart
to
be
able
to
escalate
privilege,
a
regal
rule
is
specified
in
lines
one
through
five
and
we
have
a
couple
of
helper
functions
in
the
bottom.
So
the
first
couple
of
lines
of
the
vehicle
we're
getting
the
contents
of
the
security
context
and
our
deployment
specification.
A
A
So
now,
let's
look
at
the
regal
rule
for
the
third
security
requirement
we
have-
and
this
is
one
this
one
is
about
avoiding
our
containers
running
as
root.
We
want
to
protect
our
environment
from
the
possibility
of
container
escapes
and
it's
the
best
practice
to
avoid
running
containers
as
roots,
so
I
cut
the
regal
rule
from
this
snippet
as
it
was
similar
to
the
last
one.
I
wanted
to
focus
on
the
functions
that
we're
using
here
in
the
first
and
the
second
function
highlighted
here.
A
A
Undefined
so
I
have
a
couple
of
yaml
snippets
here
that
are
in
violation,
so
we
can
visualize
these
issues
on
the
first
one.
If
we
look
at
line
number
two
run
as
non-root
is
set
to
false,
so
this
is
in
violation
of
our
policy
and
on
the
second
yama
snippet
in
line
number
two.
We
see
that
rona's
user
is
set
0,
which
is
the
reducer,
and
that
will
be
in
violation
of
our
regal
rule
as
well.
A
So
there's
two
main
types
of
security
guard
rails,
proactive
and
reactive
reactive
are
more
of
the
traditional
security
controls
where
we
update
the
wrong
time
environment
after
we
notice,
a
violation
has
occurred
so,
for
example,
when
doing
a
vulnerability
scan
of
a
server
and
we
detect
that
there's
a
critical
vulnerability
that
needs
to
be
patched.
We
could
have
a
reactive
guardrail
to
automatically
patch
the
system.
A
So,
there's
an
open
source
tool
that
allows
you
to
implement
your
policy
as
code
guardrails
that
we
had
accurate,
maintain
called
tauruscan.
And
what
I
like
about
terascan
is
that
it's
packaged
as
an
executable.
So
you
can
easily
integrate
it
into
your
workflow
by
by
running
it
locally
on
your
desktop
or
as
part
of
your
ci
cd
pipeline.
A
The
tool
leveraged
the
regal
language
from
the
opa
projects
as
part
of
its
policy
engine.
So
you
have
a
standard
way
to
implement
policy
as
code,
and
it
includes
a
lot
of
policies
by
default
that
you
can
use
as
a
baseline,
to
evaluate
your
system
or
enhance
your
current
policy
set
with
the
ability
to
scan
terraform,
kubernetes,
yaml
files,
helm
and
customize.
A
Works
so
the
first
and
most
straightforward
guardrail
is
to
use
a
policy
skilled
scanning
tool
on
your
engineer's
local
environment.
So
here's
an
example
where
we're
using
terascan
to
scan
the
example.
Wordpress
architecture
we've
been
using
through
the
presentation
and
finding
the
three
issues
that
we've
discussed
on
the
deployment
the
channel
file.
A
A
The
next
place
to
apply
guard
rails
is
on
your
ci
cd
pipeline,
and
this
is
where
you
can
prevent
any
code
that
deviates
from
your
standards
to
be
introduced
by
having
a
ci
job
fail.
If
there
are
any
issues
that
you
would
like
to
block
on,
and
we
have
to
keep
in
mind
that
it's
always
easier
to
fix
issues
on
your
code
rather
than
at
runtime.
So
you
want
to
make
sure
that
changes
to
your
runtime
kubernetes
clusters
are
only
done
through
code,
and
this
will
help
you
use
ci
cd
as
part
of
your
security.
A
Also,
we
know
that
there
might
be
break
glass
situations
where
we
might
not
be
able
to
use
declarative
code
to
make
changes
to
our
clusters
and
need
to
make
a
quick
change
at
runtime
because
of
an
emergency.
So
using
this
approach
we
would
have
an
additional
control
to
prevent
issues
from
being
introduced
through
those
break.
The
glass
changes.
A
A
It
cloned
this,
so
I
have
this
stored
locally,
but
one
of
the
things
I
wanted
to
show
you
was,
if
you
don't
want
to,
if
you
want
to
have
a
repository
you
want
to
scan,
which
is
not
local.
You
can
use
stereoscan.
A
Slash
I
helm
slash
our
git
and
put
the
github
repository
in
there
and
under
the
hood,
terascan
will
download
that
repository
and
run
their
scan
on
it
without
you
having
to
necessarily
clone
that
repository
and
give
you
the
results,
which
is
an
easy
way.
If
you
have
remote
repositories
that
you
want
to
scan,
so
I'm
just
going
to
scan
it
real
quick
to
show
you
what
are
the
things
out
of
the
box
that
we
get
from
tara
scan
when
scanning
this
repository.
A
So
if
you
see
here
are
some
of
the
results
that
we
got
from
running
terrascan
on
the
repository-
and
this
is
what
the
default
policies
that
terraskin
has
so
you'll
get
a
lot
of
results
which
may
or
may
not
be
relevant
for
what
you're
trying
to
do
so.
One
thing
I
did
with
this
repository
on
my
local
copy
of
the
repository
was,
I
added.
A
A
A
And
you
just
looking
at
it
locally
on
our
deployment.jml
file,
and
I
had
this
open
previously,
so
it's
redirected
me
right
there,
but
looking
at
this
file,
if
you
search
for
this
value,
that's
all
what
all
of
what
we're
doing.
If
we
were
going
to
do
this
manually,
that's
all
what
we're
doing,
but
but
this
time
we're
using
a
tool
to
look
for
that
secret.
Key
ref,
and
here
you
see
that
they're
using
a
there's,
they're
storing
that
secret
for
the
wordpress
database
password
and
also
the
username.
A
So
that's
what
they're
doing
here
and
we'll
volunteer
again
shortly.
So
we
can
see
how
these
three
policies
evaluate
the
code.
A
So,
let's
take
a
look
at
this
one
where
we're
looking
at
the
security
context
and
seeing
if
allow
privilege
escalation,
is
set
to
true
or
if
it's
undefined,
so
I'm
just
going
to
look
real
quick
to
see
if
they
set
this
on
the
deployment.yaml.
A
A
The
one
thing
here
is
that
the
way
that
teraskin
works
is
that
it
will
automatically
use
the
variables
in
the
helm,
chart
and
populate
the
values
for
it
before
doing
a
policy
evaluation.
A
So,
although
I'm
doing
a
quick
find
in
this
deployment.gmo
file,
although
I'm
not
seeing
the
values
that
would
trigger
these
policies,
it
doesn't
mean
that
they're
not
there.
It
might
mean
that
they're
that
they're
using
variables
for
these.
So
this
is
an
example
where
it's
saying
so
run
as
user.
It's
using
a
variable
here.
A
A
A
So
now,
let's
run
turret
scan
to
see
if
what
which
ones
of
these
policies
are
going
to
be
triggered
by
our
local
helm
chart.
A
So
we
can
do
tariffs,
scan
scan
dash
p
and
the
dash
p
flag
is
where
you
can
specify
a
directory
containing
your
regal
policies.
So
this
will
override
so
that
you
don't
use
the
default
policies
included
in
terascan.
So
we're
only
going
to
be
using
the
three
policies
that
we've
created
here.
A
A
So
this
is
where,
on
our
deployment
for
the
gmo
file,
I
showed
that
the
database
credentials
were
were
there
and
then
the
second
one
being
triggered
here
is
that
the
container
should
not
run
with
allow
privilege
escalation,
and
this
one
is
triggering
because
if
you
remember
our
policy,
we
said
that,
if
you're,
if
you
don't
have
the
allow
privilege
escalation
set
to
false,
we
will
trigger
this
policy.
A
A
A
So,
let's
recap
on
what
we
did
today
and
how
we
implement
helm
securely
in
our
system.
The
first
step
was
to
identify
and
define
the
requirements
that
were
applicable
to
our
system.
In
the
example,
we
captured
three
different
requirements
that
came
from
the
cis
benchmark
for
kubernetes
that
were
important
to
us
and
step
number
two.