►
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
Hello,
everyone
and
thanks
for
joining
us
today,
to
talk
about
policy
as
code,
and
how
can
you
use
it
to
manage
risk
in
your
kubernetes
environment
before
we
begin,
let
me
introduce
myself.
My
name
is
cesar
rodriguez
and
I'm
the
head
of
developer
advocacy
at
acurix,
and
I've
been
working
on
the
cloud
security
space
for
most
of
my
career,
helping
secure
public
and
private
cloud
environments
in
the
military
and
financial
industries.
A
A
Another
challenge
in
the
traditional
security
world
is
that
we
have
security
appliances
like
firewalls
ideas,
ips
waves
and
proxy
securing
our
environment,
but
only
a
handful
of
people
on
the
security
team
have
visibility
into
how
these
are
configured
and
most
developers
and
operators
don't
really
know
how
these
affect
their
applications
and
systems.
This
usually
leads
to
having
unnecessary
calls
to
the
security
team.
A
The
final
challenge
that
I
want
to
highlight
with
traditional
security
is
that
everything
was
manual,
starting
with
the
way
you
engage
with
the
security
team.
For
example,
if
you
need
a
spiral
rule
updated
you
open
a
ticket
with
security,
wait
for
them
to
look
at
it,
maybe
schedule
a
meeting
to
understand
what
you're,
asking
probably
saying
they'll
say:
no,
the
first
time
you
go
back
and
forth
and
once
everything
everyone
is
on
the
same
page
and
the
schedules
change,
then.
Finally,
someone
manually
makes
the
change
and
we
all
hope
it
goes
well.
A
A
So
from
our
previous
example,
if
you
want
to
ensure
that
encryption
at
rest
is
applied
to
your
environment
instead
of
manually
checking
all
of
your
storage
systems
with
policy
skilled,
you
will
write
a
rule
or
a
policy
that
can
be
used
to
programmatically
check
that
the
code
that's
going
to
provision
and
manage
your
storage
system
is
using.
Is
half
encryption
properly
configured.
A
So
the
first
step
to
start
implementing
policy
as
code
is
to
start
defining
your
infrastructure
and
its
configuration
as
code.
Let
me
give
you
an
example
of
how
I'm
how
I've
used
it
on
my
experience
and
how
I've
used
the
declarative,
apis
and
infrastructures
code
to
improve
the
security
posture
of
an
organization
I've
worked
for
so
a
few
years
ago
I
was
working
on
a
big
cloud
migration
project
for
a
financial
firm
to
kick
off
the
cloud
migration.
A
We
were
tasked
on
developing
and
deploying
a
significant
customer
facing
application
in
three
months
as
part
of
an
mvp.
We
form
a
cross-functional
teams
with
members
of
the
business
developers,
infrastructure,
engineers,
operations
and
obviously
security,
and
the
idea
was
to
build
the
initial
core
cloud
infrastructure
for
the
firm.
At
the
same
time
that
the
development
team
was
working
on
the
application.
A
There
were
some
engineers
where
this
was
their
first
cloud
project
and
they
wanted
to
learn
everything
using
the
console
and
doing
things
manually
to
them.
This
seemed
like
a
good
idea
to
so
to
start
learning,
but
once
they
try
to
replicate
what
they've
done
manually
through
the
different
environments
and
into
production,
things
were
painful
and
delayed.
A
A
Application,
one
of
the
great
things
about
doing
infrastructure
is
code,
was
now
that
the
security
controls
of
our
environment
were
codified
and
were
easy
to
govern
in
a
way
that
was
transparent
to
the
development
teams.
So,
for
example,
if
the
development
team
and
if
anyone
in
the
development
team
needed
an
update
on
a
security
group,
it
was
just
a
matter
of
opening
a
pull
request
to
the
repository
and
have
someone
just
review
emerge.
A
Having
this
type
of
git
ups
workflow
also
enabled
scalability,
as
once,
we
started
migration
and
modernizing
the
rest
of
the
application
portfolio,
the
same
repositories
we
set
up
for
the
initial
project,
we're
able
to
support
hundreds
of
applications
in
multiple
environments
and
regions
in
that
original
mvp.
It
was
also
important
to
iterate
quickly
on
security
policies
to
deliver
our
business
objectives,
while
keeping
our
environment
secure.
So
with
infrastructure
skilled,
we
unlock
the
ability
to
codify
the
security
policies
and
programmatically
apply
them.
A
So
I
looked
online
and
at
the
time
there
weren't
that
many
tools
to
do
this,
so
I
decided
to
build
my
own
and
release
it
as
open
source
to
help
anyone
looking
to
secure
their
cloud
environment
and
that's
how
terascan
was
born.
Zoteroscan
is
an
open
source
tool
that
can
help
you
define
your
security
policies
as
code
and
enforce
these
on
your
infrastructures
code.
The
tool
currently
supports
scanning
of
terraform
of
kubernetes
json
and
yaml
configuration
files.
A
It's
packaged
as
an
executable,
so
you
can
easily
integrate
it
into
your
workflow
by
running
it
locally
on
your
desktop
as
part
of
your
ci
or
export
your
ci
cd
pipeline.
It
can
also
be
executed
in
server
mode,
and
this
allows
you
to
centrally
govern
iec
scanning
by
having
a
central
hub
with
rules
to
me.
Help
meet
your
organization
standards.
A
We
also
wrote
the
tool
so
that
it's
easy
to
add
support
for
additional
iec
tools.
So
the
idea
here
is
that
policies
will
be
decoupled
from
the
iac
language
so
that
a
policy
reading
for
a
particular
technology
will
be
applicable
regardless
of
the
iec
tool.
So,
for
example,
the
kubernetes
policies
are
the
same.
Whether
terascan
is
evaluating
your
kubernetes
yaml
files
directly
or
if
you're,
using
customize
or,
if
you're,
using
terraform,
to
manage
your
kubernetes
environment.
A
Here's
how
we
visualize
integrating
terascan
into
your
workflow,
where
you
can
run
the
tool
natively
in
your
local
development
environment.
So
you
can
catch
any
security
issues
as
early
as
possible.
You
can
also
have
a
pipeline
that
verifies
compliance
to
your
policies
before
pushing
any
changes
into
your
cloud
environment,
and
you
can
also
run
terascan
in
server
mode
where
you're
feeding
it
infrastructure
configuration
files
before
making
any
changes
in
your
environment.
A
A
So
now,
let's
talk
about
how
to
use
terascan
to
find
kubernetes
vulnerabilities,
and
today
I
want
to
talk
about
two
recent
vulnerabilities,
where
we've
published
blog
posts
in
our
website
to
discuss
in
details
how
to
how
to
detect
this
vulnerabilities
in
your
systems,
how
to
use
policy
as
code
to
prevent
these
detect
and
prevent
these
types
of
vulnerabilities.
A
The
issue
in
this
one
is
a
man
in
the
middle
of
vulnerability
where,
if
a
potential
attacker
has
access
to
create
or
modify
services
and
pots
in
a
multi-tenant
cluster,
the
attacker
may
be
able
to
intercept
traffic
from
pots
or
other
nodes
in
the
system.
So
the
initial
reaction
to
a
vulnerability
like
this
might
be
that
you
think
that
it's
not
that
important
as
there's
a
limited
number
of
people
or
systems
with
access
to
create
pots
in
your
environment,
but
even
if
you've
accepted
insider
threats
as
part
of
your
threat
model.
A
So
if
an
attacker
has
access
to
create
a
service
such
as
the
one
depicted
here,
the
attacker
will
be
able
to
redirect
any
cluster
traffic
destined
for
tcp
port
80
on
the
ip
addresses,
1.1.1
or
8.8.8.
A
A
A
So,
on
the
right
hand,
side
we
have
an
example,
regal
policy
to
help
prevent
this
in
this
policy.
We're
checking
that,
given
a
service,
we're
going
to
do
a
type
check
to
verify
that
it's
a
cluster
eyepiece
service
type
and
then
we're
going
to
check
whether
the
external
ip
attribute
is
defined
and
we're
going
to
alert
on
that.
A
A
A
This
here's,
the
output
that
we
get
where
it's
saying
on
the
violations
that
we're
vulnerable
to
cbe,
2020
8554,
it's
giving
us
the
file
and
it's
saying
that
it's
a
medium
type,
vulnerability.
A
The
next
vulnerability
I
would
like
to
talk
about
is
cve
2020
8555,
which
is
a
was
rated
as
a
medium
severity
vulnerability,
and
the
issue
here
is
a
potential
server
side,
request,
forgery
or
ssrf
on
vulnerable
versions
of
cube
controller
manager.
You
do
have
to
be
authorized
to
create
pods
to
exploit
this
vulnerability
and
use
one
of
the
affected
volume
types
like
cluster
fs.
A
A
At
the
bottom
of
this
slide,
I
have
the
link
to
the
blog
post,
where
you
can
learn
more
about
in
details
about
this
vulnerability
and
what
are
the
effective
versions.
So
now,
let's
take
a
look
at
how
to
use
policy
s
code
to
defend
this.
A
So
here's
an
example
yaml
file
that
can
expose
your
environment
if
you're
using
one
of
the
affected
versions
of
cube
controller
manager.
So
the
steps
from
the
attacker's
perspective
are
to
number
one
create
a
pod
in
your
cluster
number
two
mount
the
cluster
fs
volume
since
that
volume
type
of
type
is
subject
to
the
vulnerability.
A
A
So
the
best
way
to
prevent
this
particular
vulnerability
will
be
to
upgrade
to
the
latest
version
of
kubernetes,
where
this
has
been
patched.
If
you
can't
upgrade
the
next
best
solution
will
be
to
use
policy
as
code
to
detect
and
restrict
usage
of
the
effective
volume
types
or
to
restrict
storage
class
right
permissions
through
rbac.
A
A
So
let
me
go
back.
These
are
the
two
demo
files
that
I
have
here.
So
let
me
cat
the
cpe
2020
8555.js,
and
this
is
where
we
got
where
we're
using
the
clusterfs
volume
type,
which
is
one
of
the
effective
volumes.
A
This
one
has
a
few
a
few
issues,
so
there's
a
little
issue
which
is
we're
using
the
default
namespace.
A
A
A
A
Last
one
is
visibility,
and
these
are
this:
do
you
want
to
make
that
you
want
to
make
sure
that
you
have
the
proper
information
capture
as
part
of
monitoring
and
logs?
So
in
case
of
a
security
incident,
you
have
the
ability
to
reconstruct
how
the
incident
happened
and
have
a
trail
of
of
what
was
what
actually
happened
in
your
system,
so
outside
of
security.
But
related
tourists
can
also
have
a
category
for
operational
efficiency
policies
that
we
think
are
important
to
consider
from
a
best
practices
perspective.