►
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
B
B
A
C
A
C
B
A
All
right
and
my
name
is
kendall
miller.
I
am
technically
an
evangelist
here
at
fairwinds
and
excited
to
be
with
you
all
we're
going
to
be
diving
into
a
number
of
different
things
related
to
misconfigurations,
but
first
tell
you
why
we're
the
ones
talking
about
it?
So
this
is
not
a
hard,
fair
wins
pitch,
but
to
give
you
background
on
why
we're
here
talking
about
this
fair
winds
has
been
in
the
kubernetes
space.
For
a
long
time,
we've
been
in
business
seven
years
over
seven
years,
seven
and
a
half
ish
wow.
A
It's
been
a
long
time
and
working
with
kubernetes
almost
the
entirety
of
that
time.
Helping
organizations
use
kubernetes
correctly,
get
over
the
the
hurdles
of
using
what
is
for
most
people
a
new
paradigm
and
it's
complicated
to
learn.
Today
we
developed
open
source
software
as
well
as
a
sas
product
that
specifically
addresses
misconfigurations
organizations
out
there
are
worried
when
I
move
to
kubernetes.
Am
I
going
to
mess
everything
up?
How
do
I
do
this
correctly?
It's
a
new
paradigm.
I
know
how
to
think
about
the
old
paradigms.
A
How
do
I
get
used
to
this
new
one
and
that's
what
fairwinds
does
so
we
build
open
source
in
that
space,
we're
going
to
be
talking
a
lot
about
some
of
that
open
source.
Today,
we
also
build
a
sas
platform
that
addresses
this,
so
misconfigurations
is
literally
the
water.
We
swim
in
it's
what
we
do
all
day,
long
at
fairwinds
and
that's
why
we're
addressing
this
topic
today
for
for
y'all,
so
proper
configuration
counts
and
let's
dive
into
some
of
the.
Why
about
this?
First
of
all?
A
What's
what's
different
well
well
before
we
do
that.
Let's
talk
about
some
of
the
common
misconfigurations
that
we
see,
and
one
of
the
first
things
here
we
have
is
only
35
of
organizations
have
correctly
configured
90
of
their
workloads
with
liveness
and
readiness
probes.
Now
we
can
dig
into
this
specifically
here
in
just
a
second,
but
I
want
to
begin
with
huge
percentages
of
organizations
leave
things
off,
partly
because
kubernetes
is
just
a
fundamentally
different
paradigm.
Right,
liveness
and
readiness
probes
in
kubernetes
is
a
different
way
of
thinking
about
things
than
previously.
A
Where
you
know
there
was
a
time
in
your
career
where
you
could
tell
a
machine
went
off
because
it
was
you
know
in
your
closet,
in
the
server
room
in
the
back
or
something
you
might
have
had
liveness
and
readiness
probes
for
that
kind
of
thing
too,
but
it's
a
whole
new
paradigm.
So,
let's
start
with,
what's
just
fundamentally
different
about
kubernetes
and
then
let's
get
into
some
of
the
specifics
of
this
particular
common
misconfiguration
and
ivan.
You
want
to
kick
us
off.
Why
is
kubernetes
so
fundamentally
different.
B
I
think
what
relates
to
to
this
is
that
with
kubernetes,
things
are
typically
a
lot
more
ephemeral
than
your
server
room
back
of
the
closet
under
the
desk
scenario.
So
even
though,
we've
always
had
some
kind
of
monitoring
some
kind
of
thing
that
in
the
kubernetes
world
we're
calling
liveness
and
readiness
probes.
What
I
think
is
appreciable
difference
here
is
that
containers
are
coming
and
going
and
scaling
and
moving
around
a
lot
more
than
applications
tended
to
move
around,
and
so
it
sort
of
exacerbates
makes
much
more
important.
A
And
in
kubernetes
world
aren't
we
declaring
the
state
that
we
want
in
a
way
that's
different
from
previous
models
of
actually
writing
code
to
go,
create
the
state
that
we
want.
I
mean
isn't
that
one
of
the
big
fundamental
shifts
here
is
we're
just
we're
just
defining
what
the
end
state
is
and
letting
kubernetes
figure
out
all
the
configuration
to
get
us
there
rather
than
having
to
like
say,
hey,
go
out
and
build
me
a
box
build
me
a
box.
A
B
We
are,
and,
and
while
it
happens
often
very
quickly-
and
it
feels
very
similar
to
that
scripted
or
configuration
managed
way
of
implementing
something
that
was
more
imperative.
It
is
that
declarative
control
loop
that
happens
in
kubernetes
that
keeps
things
as
close
to
the
desired
state
as
it's
possible
for
kubernetes
to
do,
and
that's
what
helps
things
heal
when
you
have
things
break
in
your
app
or
you
lose
a
kubernetes
node
et
cetera.
Kubernetes
sees
that
there's
that
difference
now
between
desired
and
actual
state
and
works
to
fix
it.
A
Great
so
with
that
in
mind,
and-
and
I
I
like
to
use
the
analogy
that
moving
the
kubernetes
is
like
moving
from
windows
to
linux-
it's
not
that
linux
is
really
really
hard
to
use.
It's
that
if
you've
never
used
linux,
it's
a
whole
new
paradigm.
Once
you
get
used
to
it,
you
will
adjust,
it
will
start
to
feel
normal,
but
if
all
you've
ever
used
is
this
other
thing.
This
new
thing
feels
very
different,
and
so
that's
part
of
why
people
are
so
afraid
of
misconfigurations.
Is
they
just
know?
A
I'm
gonna
mess
things
up.
So
how
do
I
avoid
that?
So
now
talk
I
mean
ivan.
You
touched
on
this
kind
of
you
know
almost
in
passing,
but
let's
talk.
Let's
talk
specifically
about
the
liveness
and
readiness
probes
like
how
does
that
relate
to
what
you
were
just
talking
about
in
the
new
world
of
kubernetes.
B
So,
when
we're
defining
these,
we
also
need
something
for
kubernetes
to
talk
to
on
an
application,
and
if
your
application
doesn't
listen
on
some
http
port,
for
example,
you
can
also
exec
a
command
in
the
container,
but
one
one
important
aspect
of
this
is:
is
that
whatever
you
are
querying
for
these
probes,
you
want
it
to
be
relatively
efficient.
These
get
queried
pretty
often
potentially
once
a
second
for
a
single
pod
and
you're,
probably
running,
hopefully
running
more
than
one
pod
for
your
application.
B
A
A
C
C
You
know,
for
some
value
of
successful,
be
able
to
successfully
deploy
a
workload
without
these
things
set,
but
that
workload
is
likely
to
experience
downtime
if,
if
it's
not
set,
it's
likely
to
you
know
have
have
issues
that
don't
get
caught
if
they're
not
setting
them.
So
you
really
need
do
need
some
kind
of
proactive
approach
to
check
for
these
things
and
make
sure
every
individual
team
is
doing
it.
A
Yeah-
and
so
I
mean
we
have
a
couple
more
slides
like
this-
and
we're
going
to
get
into
some
more
specifics
here
in
a
little
bit,
but
just
to
give
you
a
feeling,
like
the
reason
we
have.
These
statistics
in
here
is
to
show
you
organizations
struggle
with
this.
So
only
42
percent
of
organizations
today
manage
to
lock
down
most
of
their
workloads
and
54
are
leaving
over
half
of
their
workloads,
open
to
privilege,
escalation
and
thus
security
holes.
A
I
I
feel,
like
that's
that's
that
sounds
obvious,
but
you
know
in
the
same
way
that
I've
seen
people
move
to
the
cloud
and
never
implement
things
like
auto
scaling,
which,
like
the
whole
promise
of
the
cloud,
is
that
you
can
scale
up
and
scale
down,
and
so,
if
you're,
using
the
cloud
and
you're
not
using
something
simple
like
auto
scaling,
okay,
simple
is
hand
wavy.
It
can
be
complicated
but
you're
not
using
one
of
the
greatest
promises
of
the
cloud
you're,
getting
it
wrong
or
you're.
A
You
know
you're
you're
messing
up,
probably
similarly,
when
you're
using
kubernetes
and
it's
in
it
just
is
different
because
it's
cloud
native
at
scale
in
whatever
cloud
you're
running
it
in
it's
very
easy
to
mess
up
these
common
things,
and
it's
just
not
worth
doing
when
kubernetes
is
a
different
paradigm.
You
can
get
it
right.
We're
going
to
show
you
tools
to
help
you
get
it
right,
but
kubernetes
is
a
different
world.
Okay,
I've.
I
think
I've
belabored
that
point
long
enough.
A
Okay,
here
we
go
security,
so
there
are
a
number
of
common
misconfigurations
that
we
see
in
security.
Let's
talk
about
over-permissioned
containers
and
then
we'll
dig
into
some
some
broader
other
things
that
we
talk
about,
but
we'll
go
deep
on
this
one
to
start,
we'll
go
deep
on
on
one
specific
issue
with
with
each
of
these
and
then
talk
about
the
broader
common
kinds
of
things
that
we
see
but
robert.
You
want
to
start
with
over
permissioned
containers.
What
what
is
an
over
push
permission
container?
C
Yeah
so
again,
the
defaults
for
kubernetes
are
not
always
the
most
secure
way
to
run
a
container.
There
are
a
lot
of
things
that
kubernetes
will
allow
you
to
do
by
default,
that
you
don't
necessarily
need
to
do.
For
instance,
running
a
container
as
root
kubernetes
by
default
will
allow
a
container
that
runs
as
root,
but
you
can
specify
in
your
configuration.
C
C
Most
likely
you
can.
You
can
run
your
application
perfectly
fine
without
root.
This
goes
for
several
other
different
configuration
options
that
are
available
in
the
kubernetes
security
context,
so
whether
that
container
runs
is
privileged.
What
capabilities
have
been
added
to
that?
Added
to
that
container?
These
are
all
things
that
basically
a
workload
that
is
misbehaving
or
that
gets
compromised
by
an
attacker.
C
A
Yeah-
and
I
mean
I've-
I've
said
before
in
in
other
webinars.
I
feel
like
the
the
average
response
from
a
person.
Who's
not
tuned
into
this
is
to
think
like
nobody's
gonna
break
out
of
a
container
and
get
access
to
other
things
right
like
like
that,
just
it
sounds
far-fetched
except
in
the
world
we
live
in.
We
know
of
lots
of
people
who
make
a
career
out
of
breaking
out
of
containers
like
that
is.
That
is
a
thing
that
people
are
like
hey.
I
escaped
a
container
in
this
situation.
A
I
escaped
a
container
in
that
situation.
I
mean
one
of
the
ones
that
I
saw
was.
I
think
it
was.
I
escaped
a
container
running
on
a
cluster
in
a
mainframe
or
something
you
know
it
was
just
like
yeah,
that's
that
was
more
just
for
street
cred,
because
that's
not
gonna
be
a
thing
that
we're
going
to
run
into
a
whole
lot
in
regular
life.
I
have
anything
to
to
to
add
specifically
over
permission
containers.
B
Just
a
bit
of
an
underscore
robert
robert
covered
it
all,
but
this
is
harder
I
think,
to
put
time
and
effort
into
implementing
correctly
than,
for
example,
the
thing
we
just
talked
about
readiness
and
liveness
probes.
So
if
you
want
to
limit
the
linux
capabilities,
which
is
essentially
what
colonel
calls,
is
it
possible
for
your
container
to
make
that
takes
effort
to
minimize
those
and
then
run
your
application
through
its
typical
qa
testing?
B
If
you
want
to
make
sure
that
all
the
things
your
app
needs
to
do
are
still
possible
for
it
to
do
while
it's
running,
so
this
is
an
easy
one
to
ignore,
because
it's
hard
to
do
and
you've
got
to
set
that
time
aside.
So
it's
it's
a
a
bigger
gap
for
sure
that
we
see
and
when
you
take
the
time
to
do
the
first
few,
like
don't
run
as
root,
have
your
file
system
be
read
only
in
your
container
those
type
of
things?
That's
an
awesome
start.
A
A
It's
in
a
container.
It's
going
to
be
fine,
it's
not
going
to
have
access
to
anything.
You
know,
I
think,
of
the
the
famous
log
4j
example
from
recently
you
know.
First
of
all,
you
want
to
stop
known
cves
that
are
running
in
your
workloads
or
running
in
your
containers
from
being
deployed
into
a
production
environment.
You
want
to
stop
that
from
happening
period.
A
If
that's
going
to
happen
and
you've
at
least
kept
your
container
pretty
locked
down
that
does
limit
some
of
the
attack
radius
that
it
can
have
right.
So
so
when
it
when
we,
when
we
think
about
security,
there's
the
big
picture
things
and
you
work
down
to
the
granular
level
and
everything
in
security
and
operations
is
a
trade-off.
But
there's
there's
huge
trade-offs
to
be
made.
It
like.
There's
huge
mistakes
to
be
made,
and
this
may
be
more
complicated
to
do.
But
really
limits
the
attack
or
the
the
blast
radius
of
an
attack.
C
A
B
B
But
it
also
is
a
risk
similar,
similarly
host
ipc
having
access
to
that
inter-process
communication
or
host
pid
as
well
means
the
container
can
see
processes
that
are
running
on
the
host,
not
limited
to
the
processes
that
only
run
in
the
container.
So
that
gives
you,
even
if
the
container
is
not
running
as
root,
gives
you
some
visibility
into
what
else
is
running
on
the
host,
which
is
you
know,
intel
for
some
attacker,
for
example,.
C
Yeah
ivan
brings
up
a
really
good
point
there,
the
the
reason
you
know
these
security
options
are
available
is
that
sometimes
they
are
necessary.
If
you're,
you
know
running
a
workload
that
does
like
you
know,
network
telemetry,
it
probably
does
need
access
to
that
host
network
to
be
able
to
do
its
job,
and
so
that's
an
example
where
you
would
want
to
create
an
exemption
for
some
of
these
rules
and
say:
okay,
this
particular
workload
does
get
access
to
this
particular
security
feature.
C
The
the
issue
is
that
the
vast
majority
of
workloads,
especially
the
ones
that
you're
building
internally
at
your
company,
don't
need
access
to
these
things.
They're,
probably
just
api
servers
they're
serving
a
website,
something
like
that.
They
don't
need.
You
know
deep
telemetry
into
you,
know
the
network
operations
going
on
inside
the
cluster.
So
I
think
I
think
it's
important
to
note
that
sometimes
these
options
are
appropriate,
but
it's
in
very
rare
and
isolated
cases.
Yeah
yeah.
A
C
The
other,
like
broad
category
that
we
haven't
really
mentioned,
is
something
like
the
control
plane
level,
so
that
would
include
things
like
if
you're,
if
you're,
managing
your
own
control,
plane
you're,
not
on
like
eks
or
gke,
making
sure
that
that's
not
you
know
a
publicly
available
control
plane
so
that
you
know
anybody
from
the
internet
can
just
you
know
log
in
and
start
messing
with
your
kubernetes
cluster.
You
know
making
sure
that
it's
using
ssl
that
cd
is
encrypted
there's
a
whole
bunch
of
stuff.
C
C
So
if
you
can
go
with
one
of
those
providers,
but
if
you're
managing
it
yourself
there's
a
lot,
you
need
to
do
to
make
sure
you're
doing
it
right,
there's
also
kind
of
analogous
to
the
control
plane.
A
lot
of
topics
are
on
roll
rate,
role-based
access
control,
making
sure
that
you're
using
the
principle
of
least
privilege
to
ensure
that
you
know
different
personas
at
your
company
have
the
right
level
of
access
to
your
cluster.
C
You
know,
maybe
the
sres
need
to
be
able
to
delete
and
modify
things
on
the
fly,
but
the
developers
only
need
read-only
access
that
kind
of
thing,
and
also
the
individual
workloads
in
your
cluster.
The
service
accounts
that
are
doing
some
automated
operations.
Those
those
two
should
adhere
the
print
to
the
principle
of
least
privilege.
They
should
only
get
permissions
to
do
the
things
they
need
to
do
in
order
to
get
their
job
done.
A
And
it's
worth
making
a
plug
there
for
one
of
our
open
source
projects.
It's
called
our
back
manager,
so
rbac
role-based
access
control.
That
robert
just
mentioned
is
for
managing
role-based
access
control,
which
part
of
the
reason
that
that
project
exists
is
we
see
people
struggle
with
it
more
than
than
we
would
like
them
to
so
we've
tried
to
ease
some
of
that
process.
A
A
Okay,
so
I'm
I'm,
I
want
to
wrap
up
security
with
just
a.
There
are
a
lot
of
misconfigurations
that
you
can
you
can.
How
do
I
explain
this
reliability
costs
you
something
immediately.
Oh
this!
This
is
slow.
This
isn't
up
user
tried
to
get
on
my
website.
I
cost
me,
you
know
I
think,
of
how
much
money
it
has
to
cost
amazon
if
they
have
two
minutes
of
downtime
right.
A
That's
why
you
basically
never
ever
see
amazon's
website
down,
because
it's
probably
millions
of
dollars,
for
you
know
a
minute
if,
if
not
more
than
that,
your
website
is
similarly
affected
by
reliability,
misconfigurations,
which
we're
going
to
get
into
in
just
a
second
but
security
misconfigurations
you
can
get
away
with
until
you
can't
it's
free
until
it's
so
expensive,
it
puts
you
out
of
business,
it
can
do
damage
to
your
brand.
It
can
do
damage
to
your
user
base.
It
can
do
damage
to
everything
and
so
having
a
correct
security
posture.
A
I
guess
anybody
who's
been
in
this
space
knows
this,
but
I
feel
like
it's
worth
it
reiterating
it
matters
to
get
this
right.
In
fact,
security
is
like
one
of
the
number
one
reasons
we
see:
people
interact
with
our
software,
both
open
source
and
our
sas.
Software
is
because
they
want
a
security
posture
in
kubernetes
that
they
have
confidence
in.
So
it's
not
a
it's,
not
a
minimal
thing.
Okay,
now
we're
gonna
do
something
similar
here
talk
about
reliability.
Let's
talk
about
health
probes
ivan
you
can
start
and
we'll
we'll
talk
about.
A
B
Yeah,
so
I
don't,
I
won't
explain
these
probes
because
it
we
actually
kind
of
talked
about
them
earlier
when
we
were
starting
with
kind
of
the
overall
overview
of
these
topics,
but
I'll
say
a
little
bit
more
about
the.
What
happens
if
you
get
it
wrong
part.
So
if
you
don't
have
readiness
and
liveness
probes
defined
for
your
application,
then
kubernetes
doesn't
have
any
way
of
knowing
what
the
health
of
your
pods
containers
are
and
the
impact
of
that
apologize
for
the
fire
engine.
B
In
the
background,
the
impact
of
that
is
that
if
you
have
a
container
that
hangs
or
becomes
unhealthy
stalls
in
some
kind
of
way,
kubernetes
won't
know
that
it
can
go
ahead
and
restart
or
that
it
should
restart
that
container
without
a
probe.
Kubernetes
definition
of
a
healthy
container
is
that
the
process
you
ran
for
the
container
to
start
is
still
running
and,
as
we
know,
that
process
could
be
quote
unquote
running,
but
it
could
be
deadlocked
for
some
reason.
The
readiness
probes
without
those
kubernetes
won't
know
whether
it
should
send
traffic
to
that
pod.
B
So
if
you
have
a
service
defined
in
kubernetes,
that
could
either
be
used
internally
for
other
applications
to
talk
to
your
application,
like
a
microservice
architecture
or
a
service
that
is
leveraged
by
your
ingress
controller
or
directly
attached
to
a
load,
balancer
you're,
getting
traffic
in
to
your
application
through
that
service
and
without
a
readiness
probe.
If
you
have
that,
similarly
unhealthy
or
unresponsive
pod
kubernetes
will
otherwise
then
continue
to
send
traffic
to
that,
and
so
now
that
means
that
your
users
and
your
customers
are
accessing
an
application
pod
that
isn't
able
to
do
work.
B
A
C
C
A
good
like
symptom
that
you've
got
an
issue
here;
either
they
haven't
been
set
or
they're.
Misconfigured
is,
if
you
see
you
know,
every
time
you
deploy,
there's
a
big
spike
in
500
errors
or
some
other
type
of
error
message
in
your
logs.
That's
like
there's
a
good
chance
that
you
know
you're
seeing
this
kind
of
downtime.
As
you
know,
a
new
pod
spins
up
it
starts
getting
served
traffic
before
it's
actually
ready
for
that
traffic.
So
keep
an
eye
out
for
those
kinds
of
you
know:
spikes
and
errors.
Every
time
you
deploy.
A
Yeah,
I'm
trying
to
think
of
a
an
analogy
there,
but
it's
it's.
You
know
basically
think
of
a
think
of
a
new
person
coming
into
your
organization
and
on
day
one
you,
you
know
hand
them
a
mountain
of
paperwork
and
ask
them
to
file
your
company's
taxes
like
there's,
no
way
they
have
the
context
to
be
able
to
do
that.
A
To
be
able
to
do
that,
they're
not
going
to
do
it
well
and
they're,
going
to
stare
at
you
with
a
very
blank
face.
The
same
way
a
workload
is
going
to
respond
with
not
yet
not
yet
not
yet,
except
it's
not
smart
enough
to
say
not
yet
so
it
just
says
no
anyways.
What
are
some
other
common
reliability
issues
that
we
see?
I
mean
you
know
building.
Yes,
I
need
to
build
my
cluster,
so
it's
secure.
A
A
Yeah
that
I
mean
to
to
add
to
that
very
simply,
you
know,
there's
there's
a
big
difference
between
how
much
traffic
you
serve
as
a
e-commerce
website
on
a
tuesday
in
february
than
there
is
what
you,
what
you're
serving
on
black
friday,
and
if
you
don't
have
the
ability
to
scale.
You
know
if
you're
trying
to
serve
ten
thousand
times
the
customers
with
the
same
amount
of
computing
power,
you're
not
going
to
have
a
reliable
experience.
That
is
good
for
your
users
ivan
anything.
To
add
to
that.
C
A
Other
other
reliability
issues
that
come
to
mind
right
off
the
top
of
your
head.
I
mean
we're
gonna
some
of
these
bleed
into
one
another
and
we're
gonna
talk
about
cost
in
a
second
and
some
ways
to
get
cost
right
and
some
of
the
effects
of
getting
cost
and
and
settings
around
cost
wrong,
and
some
of
that.
A
B
B
C
B
Like
you
said
about
the
you
know,
efficiency
and
reliability
and
how
they
kind
of
overlap
and
security,
and
so
does
this.
So
so
as
far
as
cost
cost
goes,
we've
got
two
big
key
things
here:
around
resource
requests
and
resource
limits
and
the
the
cost.
No
pun
intended
of
getting
these
incorrect
is
that
you
end
up
having
a
noisy
neighbor
problem,
among
other
things,
in
your
kubernetes
cluster.
So
if
you've
got
over
provisioning
of
your
nodes,
so
you've
got
nodes
that
are
too
large
or
too
many
nodes.
B
Then
now
you've
got
cost
overruns
happening.
If
you
have
under
provisioning
on
the
other
side
of
that
coin,
then
now
you've
got
instability,
so
an
instability
is
its
own
thing.
The
overlap,
but
also
you
know,
there's
a
cost
to
instability
which
is
downtime
and
impact
your
business
and
your
data
and
your
customers,
so
developers
or
folks
that
are
deploying
your
apps
need
to
be
specifying
cpu
and
memory
requests
and
limits
and
requests
are
essentially.
B
What
are
the
resources
that
you
think
your
app
is
going
to
need
that
that's
a
baseline
and
then
limits
is
how
much
should
your
application
use
as
a
maximum
as
a
cap
of
sorts
and
there's
a
lot
of
technical
detail
that
I
think
we'll
avoid
for
now
about
what
happens
when
you
reach
those.
But
this
relates
to
all
kinds
of
other
functions
in
kubernetes,
depending
on
how
you
have
these
requests
and
limits
set,
they
get
you
used
for
scaling
new
nodes
into
your
cluster
and
putting
the
workloads
on
the
correct
nodes.
A
Yeah,
so
these
do
bleed
together.
I
you
know,
I
just
think
of
the
reason
that
we
have
cost
problems
around
inappropriate
resource
requests
and
limits
is
tied
to
reliability.
I'm
an
engineer
deploying
my
workload.
It
works
on
my
machine.
I
literally
click
the
apple
in
the
top
corner,
see
how
big
my
machine
is
and
make
sure
I
provision
a
container.
That's
the
same
size,
that's
probably
overkill
for
what
I'm
probably
doing
in
that
container.
Probably
in
huge
huge
quotes,
you
never
know.
A
C
No
just
that
you
know
there
there
is,
like
you
said,
there's
a
natural
tension
here
between
the
folks
who
are
charged
with
making
sure
this
application
is
up
and
running
all
the
time.
So,
namely
you
know,
the
developers
who
are
gonna
want
to
over
provision
and
say
give
me
all
the
cpus
give
me
all
the
memory
versus
you
know,
finance
and
ops,
who
are
you
know
ultimately
responsible
for
that
aws
budget?
That's
getting
a
portion
to
these
containers,
you
know
sometimes
incorrectly.
C
C
So
you
know,
okay,
you
can
come
to
the
table
and
say
you
know
this
workload
has
never
used
more
than
half
of
a
cpu
at
any
given
time
and
we've
got
four
cpus
provisioned
like
we
definitely
need
to
take
that
down
to
at
least
like
one
cpu,
which
would
still
be
way
over
provision,
but
save
us.
You
know
75
percent
of
our
bill,
so
so
having
data
for
those
discussions
is
super
super
helpful.
A
And
it's
one
thing:
when
your
organization's
very
small
and
you
have
one
or
two
pods
running
it's
another
thing
when
your
organization
is
very
large
and
you
have
thousands
of
pods
running
and
all
of
them
are
even
a
little
bit
over
provisioned
that
just
spirals
out
of
control
really
really
quickly.
So,
okay,
so
we've,
given
you
lots
of
examples
of
ways
to
mess
things
up,
and
now
we
want
to
talk.
You
know
a
little
bit
about
open
source
tooling
to
actually
identify
those
misconfigurations.
A
So
we
play
a
bunch
in
this
space,
we're
going
to
talk
about
some
fairwinds,
open
source
tools
and
then
we're
going
to
talk
about
a
few
other
open
source
tools
that
are
non-fairwinds
and
and
go
from
there.
So,
let's,
let's
dive
in
first
with
polaris,
so
a
back
story
for
polaris
today
today,
fairwinds
is
a
software
company.
A
C
Yeah
I
mean
so
polaris
checks
for
pretty
much
everything
we've
talked
about
today.
All
the
misconfigurations
we've
talked
about
from
cpu
limits
missing
to
security
context,
issues
to
liveness
and
readiness
probes.
We
have
built-in
checks
for
that.
I
think
the
the
really
important
thing
to
note
about
polaris
is
that
you
know
it's
not
just
going
to
look
inside
your
cluster
and
tell
you
here
are
all
the
things
you're
doing
wrong.
It
actually
can
be
implemented.
You
know
not
just
as
a
dashboard.
C
Looking
at
you
know,
what's
inside
your
cluster
already
can
also
be
implemented
as
an
admission
controller,
so
it
can
block
things
from
getting
into
your
cluster
if
they
don't
meet
a
certain
level
of
configuration
and
it
can
also
run
in
ci
cd.
So
it
can
look
at
your
input
infrastructure
as
code
changes
as
somebody's
making
a
pr
and
say
hey,
you
know
you
added
this
new
deployment
that
doesn't
have
a
liveness
probe
specified.
You
know,
I'm
gonna
block,
you
block
you
for
merging
this
pr.
C
A
So
it
gives
you
an
overview
of
the
cluster,
gives
you
a
grade.
A
health
score
talks
about
all
the
things
that
it's
checking.
What's
passing
and
what's
failing,
this
is
great
to
deploy
across
one
or
two
clusters.
It's
really
difficult
to
deploy
across
an
organization
and
check
everything
and
make
sure
it's
all
implemented
in
the
right
way
across
lots
and
lots
of
clusters.
And
you
know
if
you
want
to
operationalize
any
of
these
tools
at
scale
check
out
fairwinds
insights.
That's
our
sas
platform.
I'll
probably
mention
that
a
few
more
times.
A
But
what
insights
does
is
adds
a
few
things.
Proprietary,
above
and
beyond
this
to
add
value,
but
also
makes
it
really
easy
to
operationalize
at
scale
write
the
policy
once
enforce
it
across
all
your
clusters
in
your
organization.
So
if
you
want
something
similar
check
that
out
goldilocks
and
ivan,
you
want
to
give
a
high
level
overview
of
goldilocks.
A
Yeah,
it's
called
goldilocks,
so
you
can
get
it
just
right
and
also
you
know
just
just
to
add
on,
and
we
do
got
to
speed
up
the
wrap
up
here
in
time,
but
everyone
struggles
with
the
resource
requests
and
limits
you
you
tell
an
engineer,
get
that
right:
they
don't
have
any
clue
how
to
get
that
right.
Goldilocks
makes
that
easy.
C
Yeah,
so
this
is
actually
our
newest
project.
It's
it's
a
really
cool
way
to
basically
validate
whether
or
not
you're
ready
to
upgrade
to
a
new
version
of
a
home
chart
so
often
for
home
charts
like,
for
instance,
cert
manager
is
very
popular
one
for
managing
certificates.
They
will
make
breaking
changes
from
you
know.
One
version
to
another:
you'll
have
to
update
some
crds
and
the
way
you're
doing
things
in
order
to
be
compliant
with
the
new
version.
C
It
can
look
inside
of
containers
and
understand
if
there
are
any
known
vulnerabilities
inside
of
those
containers
by
cross-checking
them
with
a
very
large
database
of
known
vulnerabilities,
so
very
powerful
tool
for
container
scanning
oppa
is
the
next
one.
In
line
here,
oppa
allows
you
to
implement
custom
checks
so
similar
to
polaris,
but
even
a
little
bit
more
powerful.
C
It's
it's
really
like
a
not
quite
turing
complete,
but
a
full-fledged
programming
language
for
doing
these
kinds
of
checks-
and
this
is
great
for,
if
you
have
you
know
very
special
custom
needs
in
terms
of
you
know,
making
sure
that
every
workload
has
a
particular
label
set
like.
Maybe
you
want
a
cost
center
code
label
on
everything
you
know,
things
that
are
very
specific
to
your
organization
can
be
implemented
as
opa
checks
and
then
last
we
have
cube
bench
here
which
will
look
inside
of
a
cluster
and
help.
C
You
understand
how
well
it
conforms
to
the
sysbenchmark
for
kubernetes,
which
is
a
set
of
guidelines
for
how
to
configure
particularly
the
control
plane
of
a
kubernetes
cluster.
So,
if
you're,
managing
your
own
control,
plane,
coupe
bench
is
a
great
way
to
understand
how
secure
that
configuration
is
and
what
you
might
need
to
do
to
really
get
that
security
profile
tightened
up.
A
Great
and
finally,
we
do
just
want
to
give
a
quick
plug-
I
mentioned
in
passing
fairwinds
insights,
but
this
is
for
kubernetes
governance.
Putting
guard
rails
around
the
ways
that
people
are
deploying
things
into
kubernetes
from
ci
cd
through
to
production,
write
policy
once
enforce
it
everywhere.
We
cover
security,
cost,
optimization
policy
and
guard
rails.
It
includes
polaris,
goldilocks,
trivia,
coop
bench
oppa
and
a
few
more
as
well.
A
So
if
you
need
an
all-in-one
solution,
that's
going
to
make
it
easy
to
operationalize
policy
enforcement
in
kubernetes
across
your
organization,
check
out,
fairwinds
insights
and,
finally,
we're
going
to
wrap
up
with
go
check
out
a
white
paper.
We
have
for
common
kubernetes
misconfigurations,
where
we
cover
these
topics,
kubernetes
the
good,
the
bad
and
the
misconfigured.
So
we
have
a
white
paper
on
that
and.