►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Static Analysis of Kubernetes Manifests - Barak Schoster, Bridgecrew
Planning, provisioning, and changing infrastructure are becoming vital to rapid cloud application development. Incorporating infrastructure-as-code into software development promotes transparency and immutability and helps prevent bad configurations upstream. In this talk, we'll cover best practices for writing, testing, and maintaining infrastructure at scale using policy-as-code both in CI/CD and kubernetes cluster runtime. We'll compare the two methods and review sample use cases that showcase the benefits of each. In addition we'll cover the current state of open source repositories and kubernetes manifests found in the wild.
https://sched.co/ekEb
A
So
thanks
very
much
to
kupcon.
For
having
me
my
name
is
barack
shoster,
I'm
the
cto
and
co-founder
of
a
startup
name,
bridge
group
that
helps
to
solve
exactly
that.
Identifying
these
configs
at
infrastructure's
code
manifests
I'm
also
an
open
source
maintainer
of
a
cloud
security
project
named
chekhov
that
we're
going
to
talk
about
today
and
also
contributor
to
other
projects.
A
In
that
cloud,
security
space
all
of
the
slides,
are
going
to
be
available
on
our
bridge
group
blog
and
if
you
have
any
question
or
join
project
that
you'd
like
to
do
on
the
open
source,
feel
free
to
reach
out
either
on
twitter
or
follow
my
github
account
so
before
diving
in
to
check
out,
and
what
does
it
do?
Let's,
let's
give
some
background
on
a
story
of
an
engineer,
in
this
case
myself
having
to
maintain
a
kubernetes
cluster.
A
So
the
day-to-day
activities
of
me
as
an
engineer,
are
containing
the
sprint
planning,
where
I
have
a
predictable
amount
of
tasks
that
I
want
to
handle
during
the
next
two
weeks.
But
I
also
have
unpredicted
tasks,
which
are
security
tasks,
that
the
security
team
is
finding,
whether
on
my
production,
cluster
or
my
dev
environment.
A
Finding
misconfigs
in
my
kubernetes
manifest
and
my
terraform
terraform
infrastructure
code
is
creating
a
lot
of
jiras
and
is
hurting
my
original
planning,
and
this
is
where
my
story
begins.
I
I
just
had
too
much
jiras
and
too
much
too
low
amount
of
resources,
and
I
had
to
re-prioritize
my
sprint
over
and
over
again
within
the
sprint,
and
it
caused
me
to
a
destruction
from
the
plant
features
that
as
an
engineering
engineering
business.
I
want
to
deliver
to
my
customer.
A
So
I
decided
to
scan
the
entire
github
repos
and
let's
look
at
this
data
over
here.
We
have
a
sample
of
that
scan
that
I
performed
on
the
open
source
repositories
in
this
scan.
I've
looked
for
all
of
the
kubernetes
deployment,
manifest
that
I
could
find
crawling
crawling
github
and
at
least
a
sample
of
it,
and
I've
identified
several
disturbing
default
configurations
that
should
really
not
be
there,
and
the
reason
for
that
that
I'm
saying
that
should
not
be.
A
There
is
because,
as
an
engineer,
the
thing
that
I
do
the
most
is
hitting
copy
and
paste
from
stack,
overflow
or
open
source
repositories
and
getting
inspired
by
and
kubernetes
and
other
infrastructure
is
called
frameworks
have
so
many
configurations
that
it
is
really
easy
to
get
lost
and
and
not
identifying
that
some
of
those
configuration
might
be
a
risk,
while
others
are
just
an
opinionated
way
to
run
a
kubernetes
cluster.
There
is
nothing
wrong
about
it.
It
might.
A
So
over
here
we
have
some
of
the
top
misconfigs
that
can
be
found
on
on
the
on
the
public
open
source
repositories
over
here
there
are
some
disturbing
ones.
One
is
having
a
public
endpoint
accessible
from
the
entire
internet
or
not
disabled
and
others
are
more
of
auditing
capabilities,
like
have
logging
enabled
by
default,
having
secrets
encrypted
by
default
and
and
some
others
that
are
just
best
practices
to
have
if
you're
running
a
kubernetes
cluster.
A
So
the
thought
that
came
to
my
mind
is
that
infrastructure's
code
manifest
presents
a
risk
because
it's
another
configuration
layer
that
people
might
do
mistakes
in
and
like
the
juror
tickets,
that
we
just
saw.
My
engineering
team
and
myself
have
done
those
mistakes,
but
they
also
present
a
new
opportunity.
A
A
So
checkout
is
a
static
analysis,
open
source
tool
that
allows
you
to
scan
infrastructures
code
manifests,
it
was
released
class
last
december.
It's
under
the
apache
2
license
already
has
more
than
50
contributors.
So
thank
you
and
different
contributors
for
for
making
that
project
possible
have
more
than
8
000
downloads,
more
than
1
400
stars,
and
it's
basically
written
in
python.
So
it's
very
easily
extend
extended.
A
So
chekov
statically
analyzes
for
known
best
practices
implemented
across
infrastructures,
called
manifests
like
the
kubernetes
yaml
that
we're
focused
on
today,
but
it
is
also
doing
a
good
job
with
terraform
hcl
files,
cloud
formation,
ammos
azure
arm
templates
serverless
framework
and
can
easily
be
extended
to
other
other
infrastructures
code
frameworks
over
here
we
have
a
sample
output
of
checkout
scanning,
an
infrastructure's
code
directory,
and
we
run
that
as
a
demo.
So
so
checkoff
essentially
is
a
polycs
code
engine.
A
A
A
policy
can
be
peer-reviewed
as
part
of
a
pull
request.
Specifically
in
chekhov.
We
are
utilizing
the
python's
capability
to
create
inheritance
between
different
policies,
and
the
policy
can
also
be
a
part
of
your
development
life
cycle,
meaning
let's
say
that
you
are
developing
a
new
infrastructure
and
you
want
to
enforce
a
company
policy.
For
example,
each
cluster
should
have
an
owner
team
tag.
A
So
what
is
a
policy?
Here's
an
example
for
one
the
best
practice
in
kubernetes
cluster
is
cpu.
Limits
should
be
set.
I
created
a
name
to
that
policy
created
an
identifier
to
that
policy
set
what
kind
of
configurations
I
want
to
scan
and
basically
looked
for
resource
dispelled
resources
in
the
kubernetes,
manifest
the
limits
and
verified
that
cpu
is
being
set.
A
A
What
I'm
going
to
do
now
is
one
I
can
flip
install
checkout
check
up
spray
requirements
are
that
you
will
use
python
3.
So
if
python
3
is
not
the
default,
python
version
on
your
workstation
use,
pip3
install
checkout-
and
I
already
have
it
installed
over
here,
so
what
I'm
going
to
run
now
is.
I
want
check
off.
A
The
thing
that
I
would
like
to
show
you
is
the
amount
and
the
different
scans
that
we
currently
have.
So
if
you
go
into
check
of
io
hit
the
scans
and
resource
scans,
you
can
see
the
entire
list
of
checks
across
different
frameworks
that
it
can
scan
so
over.
Here
I
have
a
set
of
kubernetes
checks.
There
are
scanning
different
types
of
the
configuration
itself.
A
So
if
I'd
like
to
create
a
custom
checklist,
just
like
the
one
that
we've
seen
before
it's
just
creating
a
python
file
and
putting
it
in
a
directory,
I
can
also
put
it
in
a
github
repository
that
way.
The
policy,
the
custom
policy,
the
custom
checks
that
I've
created
can
be
peer,
reviewed.
It
can
be
version
controlled.
A
A
A
A
So
the
thing
that
I
should
probably
do
is
copy
the
following
section
and
put
it
inside
my
kubernetes
manifest,
and
then
my
test
will
pass.
My
checkout
test
will
pass
so
we
have
here
a
set
of
different
results.
Each
time
it
will
print
the
specific
section
inside
the
file
that
is
not
configured
correctly
and
will
guide
me
with
a
link
to
the
virtual
documentation
of
how
to
remediate
that.
A
Talk
about
another
option
that
I
can
run
so
obviously
I
can
run
chekhov
over
and
over
again
manually
on
my
workstation,
and
it
will
help
me
to
fix,
identify
and
fix
miss
configs
in
the
kubernetes
manifest
before
deploying
them
to
to
github
before
opening
a
pull
request.
But
how
can
I
automate
that
process?
A
The
thing
that
I
can
do
and
add
is
a
pre-commit
hook
where
I
can
try
to
do
a
change.
The
pre-commit
will
scan
it
and
will
either
block
or
accept
the
commit
locally
on
my
workstation
and
if
it
passes,
if
you
go
through
github
open
a
pr
and
start
the
deployment
in
into
my
kubernetes
cluster.
Let's
see,
how
does
that
look
like.
A
A
A
A
A
All
right,
so
we
have
a
pre-commit
hook
and
now
we
cannot
push
into
github
any
change,
but
that
actually
means
that
every
engineer
should
have
pre-commit
hook
deployed
on
his
workstation
another
way
to
validate
that
infrastructure,
as
code
manifests,
are
answering.
Those
best
practices
is
having
chekhov
as
part
of
your
cicd
pipeline.
A
Whenever
a
new
change
request
is
being
submitted
to
github
or
other
version
control
system,
you
can
run
chekhov
as
a
ci
job,
just
like
you're
running
unit
tests.
So
let's
call
it
infrastructure
security
tests
and
if
the
tests
are
passing,
you
can
trigger
a
deployment
trigger
of
your
infrastructure
into
your
cloud
account.
A
What
I
have
here
is
a
fork
of
kubernetes
goat
for
those
who
are
not
familiar.
It's
an
amazing
project
created
by
madhu.
Thank
you,
madu
for
creating
that
piece
of
a
variable
by
design.
Kubernetes
cluster
in
this
project,
you'll
find
some
educational
material
of
how
a
bad
cluster
configuration
looks
like
and
how
you
can
actually
hack
this
cluster.
A
A
A
A
Refresh
it,
I
can
see
that
the
kubernetes
gold
ci
have
failed
on
the
check
of
action,
and
if
I
was
not
an
admin,
it
would
have
blocked
me
from
merging
that
specific
branch
into
the
main
branch,
meaning.
I
cannot
deploy
a
bad
configuration
into
production.
If
I'm
I'm
working
with
a
githubs
operation.
A
Pre-Commit
past
commit
on
a
pre
on
a
pull
request
and
on
a
running
cluster.
That
way
we
can
have.
We
can
be
sure
that
the
misconfigs
are
not
happening
in
my
production
environment,
so
the
pre-commit
hook
and
the
pull
request
really
helped
me
to
develop
in
a
faster
pace,
because
I
have
a
very
fast
feedback
loop.
A
So
the
key
takeaways
to
have
is
to
one
keep
your
manifest.
Secure
have
a
fast
feedback
loop
instead
of
a
ton
of
gear
tickets,
monitoring
both
build
time
resources,
meaning
the
code
itself
and
the
running
cluster
and
have
an
ability
to
create
new
policies
and
version
control
them
and
peer
review
them.