►
From YouTube: OCB AMA: KubeLinter Introduction and Road Map - Viswajith Venugopal and Michael Foster (StackRox)
Description
KubeLinter is a static analysis tool that analyzes Kubernetes YAML files and Helm charts, and checks them against a variety of best practices, with a focus on production readiness and security.
KubeLinter runs sensible default checks, designed to give you useful information about your Kubernetes YAML files and Helm charts. This is to help teams check early and often for security misconfigurations and DevOps best practices. Some common examples of these include running containers as a non-root user, enforcing least privilege, and storing sensitive information only in secrets.
In this session, StackRox’s Viswajith Venugopal and Michael Foster will give an introduction to Kubelinter, demonstrate it’s use, and talk about the road map for future releases.
A
Well,
hello,
everybody
happy
monday
and
welcome
to
openshift
commons
today
we're
going
to
do
another
ama
briefing
on
a
wonderful
project,
cube
linter
brought
to
us
from
some
of
the
folks
at
stack
rocks,
and
we
have
michael
foster
here,
he's
going
to
introduce
himself
and
his
colleague
vishwa
and
we're
going
to
get
an
introduction
to
the
project
where
it's
at
the
road
map
and
have
time
for
q
a
at
the
end.
So
without
any
further
ado,
michael,
please
tell
us
all
about
cube,
linter,
the
community
and
and
where
it's
going.
B
Awesome
yeah
thanks
for
the
intro
again,
I'm
mike
foster,
I'm
a
cloud
native
advocate
at
stackrocks
and
I'm
joined
by
vishwa.
Hopefully,
bishop
will
give
a
give
a
hello,
hello,
everyone,
hey
and
vishwa
is
the
lead
maintainer
for
the
cube
linter
project,
so
he's
here
to
direct
me.
If
I
get
off
course
about
anything,
ish
was
going
to
be
my
go-to
guy,
as
I
would
just
walk
through
cube,
linter
talk
to
you
about
the
community
demo,
its
functionality
and
hopefully
have
you
joining
the
community
after
so,
let's
just
get
started
so
again.
B
What's
what
I'm
going
to
cover
just
going
to
go
through
an
introduction,
why
we
decided
to
create
cubelinter
where
it
fits
into
the
ecosystem
again,
show
you
how
to
get
started
download
integrate
into
your
pipelines,
I'm
just
general
workflow.
So
I'm
going
to
show
you
how
to
use
cube
linter
in
the
cubelinter
link
functionality
I'll
show
you
some
of
the
more
advanced
features
like
configuration
and
configuring,
the
policies
and
and
setting
you
know
some
flags
so
that
we
can
ignore
checks
and
and
enable
checks.
B
Lastly,
I'm
going
to
get
into
integration
so
show
you
kind
of
where
the
real
power
of
cubeblender
takes
over
as
part
of
your
ci
pipeline
and
we're
going
to
talk
to
vishwa
about
what's
coming
next
in
the
pipeline,
you
know
some
issues.
What
the
project
roadmap
looks
like
for
cubelender
and
again
how
you
guys
can
all
join
in
already
introduced
ourselves,
but
again,
that's
vishwa,
I'm
michael
and
I'll
I'll
send
some
some
links
at
the
end.
B
B
They
can
be
just
regular
yaml
files,
and
what
we're
going
to
do
is
we're
going
to
use
the
default
policies
that
are
baked
into
the
cli
to
then
let
you
know
you
know
if
there's
some
configuration
configuration
mismatch,
if
you
have,
you
know
elevated
privileges
and
things
of
that
sort.
So
because
we
have
all
these
policies,
we
can
configure
certain
policies
enable
them
disable
them,
so
we
allow
for
some
fine-tuned
policy
enforcement
and
because
it's
a
cli,
it's
go
based.
We
have
simplicity
and
design,
something
easy
for
you
to
integrate.
B
B
And
again,
why
cube
linter?
Because
you
know
there's
all
these
different
policy
options
out
there
right
now,
and
so
we
at
starcraft
kind
of
saw
that
devsecops
really
wasn't
catching
on
and
there's
a
reason
for
it.
You
know
you
can
have
all
these
tools
doesn't
necessarily
mean
your
developers.
Buying
doesn't
necessarily
mean
it's
easy
to
use.
There's
a
there's,
a
knowledge
gap
right
for
some
of
these
tools.
Maybe
you
have
to
learn
another
language,
though
we
wanted
to
keep
the
project
simple,
keep
a
relatively
low
knowledge
gap
in
terms
of
being
able
to
implement
it.
B
It
is
a
kubernetes
focused
project,
so
some
of
the
other
policy
applications
are
a
little
bit
more
wide
in
scope.
This
is
for
kubernetes,
so
you
know
that
that's
what
we're
going
to
support
and
that's
what
we're
moving
forward
with
in
terms
of
policies
and
and
all
our
integrations
and
really
qblinter
is
just
there
to
identify
misconfigurations
as
close
to
the
source
as
possible
right.
B
So
we
want
to
enable
developers
and
ci
pipelines
to
catch
just
issues
as
close
as
possible
in
a
declarative
way,
and
the
the
checks
are
also
there
to
give
knowledge
for
further
for
further
growth
for
users.
So
not
only
are
we
linting
the
files,
but
we're
also
showing
you
why
the
policy
was
created,
documentation
if
you're
unaware
of
why
the
policy
is
there,
you
can
go
into
cubelint
into
kubernetes
documentation
and
find
out
more
in
the
end.
The
end
goal
is
that
you
can
build
operational
policy.
B
B
Not
dark
mode
for
me,
but
yeah,
so
we
have
everything
here:
installing
cube
linter
building
from
source
the
usage
how
to
get
involved
in
the
community
and
the
license
as
well.
So
again
you
can
install
because
to
go
binary,
you
can
build
using
go.
You
can
build
from
source,
you
can
use
a
a
docker
container,
run
keyblender
as
well
and
there's
a
bunch
of
other
actions
in
here.
So
let's
say
you
wanted
to
implement
cube
linter
into
your
github
as
a
github
action.
B
There's
options
for
that
as
well,
and
a
couple
of
demos
that
just
examples
that
I'll
showcase
as
well
moving
forward.
Now,
one
of
the
big
things
that
I
want
to
show
you
before
I
go
on
to
the
c:
the
command
line
and
showcase
cube
link.
There
are
the
default
checks,
so
cubeblender
has
19
default
checks
and
not
all
of
them
are
enabled
there's
13
enabled
by
default,
and
this
will
correct
me
if
I'm
wrong,
but
really
the
the
reason
for
having
13
was.
We
didn't
want
to
overwhelm
users.
B
Not
all
these
checks
are
necessary,
and
so
we
wanted
people
to
be
able
to
go,
use,
cube,
linter
and
see
the
core
checks
without
being
overwhelmed
by
all
the
errors.
So
you
know
focus
on
those
core.
You
know
six
to
eight
checks
that
tend
to
pop
up
and
then,
as
you
start
to
get
more
comfortable,
you
enable
all
the
checks
and
then
you'll
get
things
like.
You
know:
unset
cpu
requirements
on
set
memory
requirements
which
aren't
necessary
but
should
be
enforced.
B
C
That's
that
is
this:
there's
some
that
you
know.
We
want
people
that
we
think
we
are
opinionated
and
we're
like
everybody
should
follow
them
and
there's
some
where
we
know
not.
Everyone
is
going
to
be
able
to
follow
them,
but
these
are
like
good
practices.
So
we
want
the
checks,
but
we
didn't
want.
We
wanted
them
to
be
more
opt-in,
yeah.
Just
to
add
to
what
you
were
saying.
B
B
This
will
come
up
a
little
bit
later
too,
as
we
get
into
customizing
checks.
But
keyblender
is
built
off
of
these
templates
that
you
can
actually
change
and
alter
depending
on
your
needs.
So
there
is
a
required
annotation
check.
That
basically
just
says
you
know
you
should
have
an
email
of
some
sort
for
somebody
to
contact
you
for
this
kubernetes
object.
You
know
we
don't
necessarily
need
that,
but
you
can
also
alter
it.
B
B
People
might
be
like.
Why
is
there
so
many
folders
here?
I
did
it
to
kind
of
showcase
how
cute
blinter
works
and
works
effectively.
You
could
realize
that
they
put
all
these
ammo
files
in
a
single
file
and
just
link
through
them
in
one
go,
but
we
wouldn't
really
want
to
do
that.
It's
not
really.
It
doesn't
make
sense
and
can't
scale
right.
So
what
I
find
really
useful
is
cubelinterlint
lends
everything
underneath
a
folder
right,
so
we
break
it
up.
We
apply
the
policies
to
each
folder
respectively,.
A
B
Just
wanted
to
solve
that
question
because
it
comes
up
kind
of
often
people
enter
simple,
install.
I
use
brew
to
install
it
because
I'm
using
a
mac
right
now,
but
it's
very
similar
to
cube
ctl
cube
winter.
It's
going
to
have
the
available
commands
for
me.
There's
the
checks,
help
lint
templates
and
version
command.
Help
is
always
there.
You
know
dash
dash
help.
Dash
h
will
always
help
you
and
give
you
a
description
as
to
what
the
commands
are
version.
Is
there
to
show
you
the
version
that
you
downloaded
obviously.
B
B
B
The
templates
are
there
to
help
you
build
custom
checks
off
of
and
the
checks
are
the
default
ones
that
are
built
into
cubelinter,
all
right,
moving
on
to
the
good
stuff,
so
we
have
cube
linter
lint
and
we
can
technically
lint
and
it
will
take
all
the
yaml
files
underneath
that
folder.
So
because
I
have
all
the
yama
files
split
up
into
all
these
different
folders,
you
can
see.
I
have
54
linked
errors.
B
A
B
Eight
length
errors,
so
what
this
yemo
looks
like
is
right
here,
so
it's
a
non-compliant
app.
We
have,
for
example,
an
aws
secret
sticky
key
that
is
in
the
emo
file
should
not
be
there.
We
have
a
service
account
that
doesn't
match
up
in
terms
of
labels,
so
there's
and
there's
also
what
we're
forgetting
is.
There's
a
lot
of
information
missing
here.
So
we
have
to
have
uns
that
you
know
privilege
access.
We
don't
have
any
drop
capabilities,
any
less
capabilities
that
are
set
up.
B
B
So
we
like,
I
said
I
ran
the
checks
and
these
are
the
default.
13
checks
right
and
we
found
eight
lint
errors.
This
is
not
the
default
19
or
the
the
total
19..
So
you
can
see
we
have
an
environment,
var
secret.
You
know,
don't
use
raw
secrets
in
an
environment
variable
instead
either
mount
the
secrets
as
a
file
or
use
a
secret
key
ref,
and
then
we
showcase
you
know
if
you
want
more
documentation,
here's
how
you
would
solve
this
problem
right
same
thing:
there's
no
read-only
root
file
system.
B
The
remediation
is,
you
know,
set
read
only
root
file
system
to
true
in
your
container's
security
context
and
go
from
there
right
this,
it's
pretty
straightforward
for
that
example.
Now
what
I
can
also
do
is,
if
I
use
the
help
flag,
I
can
see
the
list
of
flags
that
are
available
to
me
using
cube
lender
lint
right.
So
I
have
a
bunch
of
flags
here
I
have
at
all
built
in.
B
B
And
all
built
in
and
now
we
have
12
errors
right,
so
we've
run
six
more
checks
against
it.
We've
realized
that
it
violates
four
of
those
default
checks
and
these
are
going
to
be
yeah.
So
there's
no
memory
request
or
limit
set,
there's
no
cpu
request
or
limit
set
run
is
not.
Root
is
not
set,
for
example,
and
you
know
one
of
the
ways
we
go
through
this
is:
we
could
just
take
them
off
one
by
one
in
here
until
we,
you
know,
fix
the
issue,
so
something
as
simple
as
hey.
B
B
You're
going
to
get
a
warning,
no
checks
enabled
now
one
of
the
reasons
why
and
I've
had
this
brought
up
a
couple
times
is:
why
do
we
even
add
that?
Why
do
we
add
a
do
not
auto
add
defaults,
like
you're
running
the
commands?
What's
the
point?
Well,
the
reason
is
is
because
you
think
we
have
19
checks,
we
can
either
add
all
of
them
and
disable
them
as
we
go
down
or
we
can.
B
You
know,
disable
all
of
them
and
include
them
as
we
go
up
right.
So
if
we
say,
maybe
we
really
only
care
about
running
as
non-root.
Maybe
you
know
we
just
want
to
make
sure
that
our
containers
are
not
running
as
root
and
if
they
are
we're
flagging
them
for
an
exception
right.
What
we
can
do
is
we
can
do
a
do,
not
auto,
add
defaults,
and
then
we
can
do
an
occlude
string.
B
The
run
is
non-root
command
right,
and
so
now
I've
found
one
lint
there
so
really
useful
for
flexibility.
Now,
the
next
thing
that's
coming
up
is.
Why
would
I
be
doing
this
on
the
command
line?
I
mean
you
just
see
me
like
scroll
up
and
down
go
and
copy
and
paste.
It
doesn't
really
make
sense.
It's
not
fast.
It's
not
scalable
right,
that's
where
config
files
come
in.
So
instead
of
running
something
like
this,
I
can
use
a
config
file
in
order
to
run
the
checks,
show
you,
for
example,
what
that
looks
like
now.
B
You
saw
the
flag
for
the
add
all
built-in
set
to
true.
I
can
create
a
config
file
to
basically
run
the
same
sort
of
flag
and
then
I
can
also
list
all
of
my
include
and
exclude
arguments
as
well
for
this
config
file.
Normally
you'd
have
an
exclude
here.
I've
just
commented
it
out.
I
have
all
these
checks
they're
all
set
to
true,
so
I
should
get
that
12
lint
error
message
that
I
had
before.
Let's
just
make
sure
that
I'm
in
the
right
space,
though
pigs.
B
Unless
I'm
skipping
something,
maybe
I
have
something
that
skipped
out,
but
you
can
do
the
exact
same
thing
with.
I
have
a
do
not
auto
add
default
set
to
true
as
well.
So
just
like
the
other
one,
there's
a
do
not
add
or
there's
an
ad
and
there's
a
do
not
add,
and
I
can
run
the
exact
same
check
against.
B
B
B
B
B
Again,
everything's
declarative.
We
want
to
comment
things
out
when
we
make
changes,
so
we're
going
to
you
know,
exclude
this
specific
run
as
non-root
check
and
we
have
seven
errors.
So
if
we
go
through
we'll
see
that
that
run
is
not
root,
check
is
not
there
now
right
and
one
of
the
reasons
for
the
config
file
and
being
set
up.
That
way
is
the
declarative
nature
of
yaml
files
and
kubernetes
objects
right.
We
want
to
use
that
declarative
nature
so
that
we
can
pass
on
information
to
other
teams.
B
So,
for
example,
let's
say
if
a
user
was
using
cubelinter
and
you
found
out
that
that
team
and
that
micro
service
that
they
were
working
on
had
some
specific
requirements
in
terms
of
checks.
Well,
we
can
set
up
a
policy
around
just
kind
of
that
baseline
enforcement
of
checks,
and
we
just
create
comments
to
say:
hey,
you
know
this
specific
operator
or
container
or
pod,
or
something
like
that
requires
root
access
on
the
host,
and
we
can
basically
make
a
comment
in
the
ml
file
and
in
the
config
file
as
well.
B
So
the
next
person
coming
in
understands
why
that
decision
was
made.
One
of
the
interesting
ways
is
because
it's
a
cli,
you
can
really
just
apply
it
because
just
throughout
all
the
different
folders.
So
not
only
do
I
need
to
do
it
to
the
non-compliant
ammo,
but
you
basically
can
string
all
the
commands
together.
So
what
I
found
really
useful
is
to
create
kind
of
these
default
config
files.
So
you
can
see.
I
have
a
couple
examples
here
like
maybe
I
have
specific
checks
that
I
want
for
the
cart
database
down
here.
B
Well,
I
create
a
config
file
and
then
I
just
point
the
cli
towards
the
config
file
check
that
folder
and
I
have
I
do
it
as
a
as
a
process
of
a
couple
steps
in
the
ci
process,
right
with
like
a
github
action
or
a
gitlab
runner,
or
something
like
that,
the
you
can't
always
use
config
files,
though,
and
there's
always
like
specific
exceptions.
So,
instead
of
just
having
everything
in
the
config
file,
we
also
wanted
to
give
you
the
ability
to
comment
things
out
in
the
excuse
me
in
the
emo
file
as
well.
B
B
You
don't
necessarily
need
to
write
a
description.
However,
it's
highly
recommended
you
do.
You
can
leave
this
an
empty
string,
but
the
the
whole
purpose
was
for
to
allow
users
to
document
why
they
were
ignoring
checks
or
whether
they
were
disabling
or
enabling
checks.
You
know
directly
in
the
yaml
file
right
and
it's
just
one
way
that
we
can
say
hey.
We
are
you
know
avoiding
this
security
process.
We're
aware
that
you
know
this
is,
let's
say
not
necessarily
the
best
practice
for
securing
our
container,
but
this
is
required.
B
Just
to
give
you
another
example,
let's
say
we
a
developer
would
probably
put
this
in
just
to
not
have
any
limits,
but
we
can
get
rid
of
that
and
it
got
rid
of
two
linked
errors.
The
reason
is
because
you're
getting
rid
of
memory
requirements
high
a
limit
and
a
request,
so
we
got
rid
of
two
errors
there,
and
you
know
you
can
continue
down
do
cpus.
B
So
I
find
it
really
a
good
workflow,
for
you
know,
looking
at
applications
to
have
a
config
file
that
allows
all
the
defaults
enabled
and
then
you
just
go
through,
and
you
just
basically
pick
off
and
document
exactly
why
you're
making
these
decisions
and
do
they
need
it.
Is
there
something
I
forgot
to
mention
right
and
you
know
just
simple
descriptions
in
order
to
help
you
out
now
I've
got
a
question.
B
B
B
So
one
of
the
things
that's
in
the
pipeline
is
basically
so
that
even
if
there's
an
annotation
for
disabling
it,
it
still
prompts
basically
an
output
of
like
this
is
the
check
that
was
disabled
in
this
yaml
file
right,
so
that
even
if
somebody
did
annotate
it
and
somebody
else
was
reviewing
the
work,
they
would
still
it's
still
trip
triple
wire,
but
actually
no,
there
is
not
a
yeah,
basically
you're,
saying
like
you,
you
can't
disable
any
of
the
checks,
don't
believe
vishwa.
Is
there
an
option
for
that.
D
B
B
There
are
a
couple
that
are
services,
and
you
know,
as
the
project
moves
forward,
it'd
be
interesting
to
get
feedback
from
the
community
as
to
which
objects
and
checks.
You
know
that
they
would
like
to
see
so
for
some
of
the
custom
checks.
For
example,
I
find
really
useful
for
a
required
annotation
as
a
check,
if
I
showcase
that
demo.
B
Template,
let's
we'll
see,
basically
the
options,
the
parameters
that
we
can
change
in
these
checks.
So
here's
the
required
annotation
check
and
we
can
see
there's
a
flag
not
carrying
at
least
one
annotation,
so
it
has
to
match
the
provider
pattern.
So
basically
we
can
set
the
parameter
and
the
key
to
you
know
cube
linker
demo,
for
example.
So
if
I
went
to
the
key
I
went
to
this
non-compliant
app.
If
there
was
no
check
that
was
cube,
linter
slash
demo
here
it
would
ship
the
flag
right
now
I
can
set
my
own
remediation.
B
That
will
come
through
the
check
and
you
can,
you
know,
add
a
bunch
in
there
that
you
want
or
that
you
don't
want,
and
what
I
found
really
useful
about.
This
is
like
now:
admins
can
enforce
best
practice
for
annotation
for
other
yaml
files.
So
no
longer
can
somebody
push
something
without
their
email
attached
to
it
or
you
know
not,
actually
you
know
adding
the
correct
labels.
So
if
you
have
like
different,
let's
say
you're
in
github
and
you
have
different
repositories
for
different
teams
or
something
like
that.
B
The
other
thing,
too,
is
some
of
the
parameters.
Allow
you
to
change
the
object
kind.
So
this
is
an
example
where
I'm
specifying
labels,
but
I
want
to
specify
labels
to
the
service
object
kind,
so
it'll
check,
basically
the
services,
if
I
did
it
for
carts,
for
example,
it
would
check
the
service
to
say:
hey
is
the
right
label
here?
No,
it's
not!
We
need
to
make
sure
that
that
label
is
there
and
you
know
it'll,
give
you
some
sort
of.
Oh.
B
B
B
B
B
We're
calling
the
it's
a
specific
name
for
this
check.
So
we're
calling
the
template
is
required,
label,
template
and
then
we're
giving
it
a
unique
name,
we're
specifying
the
parameter
and
the
key
that
is
changing.
So
there
has
to
be
an
environment
annotation
there
and
then,
please
add
environment
labels.
So
you
do
you
know
annotation
environment
semicolon
and
then
your
explanation
for
which
environment
it
is
so
you
can
see
or
semicolon
equal
sign.
B
You
can
see,
there's
load,
no,
no
label
matching
right
there,
and
this
is,
I
think,
an
example
of
both
a
they're
looking
at
the
service
and
we're
doing
require
label
release
service.
It's
like
a
duplicate
here,
but
yeah
either
way
you
can
see
that
there's
both
checks
that
are
coming
out
and
if
I
wanted
to
get
rid
of
that
check,
for
example,
I
don't
want
to
really
it
allows
you
a
lot
of
flexibility
to
play
around
and
configure
your
policies
as
you
want
it
to
see
as
you
want
them.
B
B
You
know
they're
not
really
going
to
work
with
security,
so
we
wanted
to
do
is
want
to
create
a
tool
that
is
in
the
developers,
hands
that
can
be
applied
in
an
automated
way
as
part
of
their
pipeline
and
also
gives
you
a
lot
of
flexibility.
So,
let's
say
admins
want
to
enable
best
practice
onto
their
develop
development
team.
Well,
you
can
implement
this
as
part
of
your
ci
pipeline
without
actually
triggering
a
build
fail
just
to
give
educational
feedback
to
them
and
I'll
show
you
kind
of
what
that
looks
like
in
this
repo.
B
I
have
a
github
workflow,
so
I
have
a
config
file
for
a
github
action
now,
like
I
said,
if
you
trip,
if
keyblades
are
limped
trips
and
air
you'll
get
a
non-zero
exit
code
which
would
technically
excuse
me
cause
your
build
to
fail
now,
you
don't
necessarily
have
to
fail
it.
If
github
actions,
for
example,
allows
you
to
continue
on
air
right
so,
depending
on
what
branch
you're
working
with,
maybe
your
devs
are
starting
off
and
either
new
to
kubernetes.
B
B
Then
you
have
a
meeting
on
monday
and
you
say:
okay.
Well,
I'm
going
to
open
up
tickets
because
there's
54
linked
errors,
and
I
want
you
to
fix
these
eight
before
friday
right.
It
doesn't
necessarily
again
need
to
fail
the
build,
but
next
monday,
when
it
comes
back
we're
like
did,
we
fix
those
main
security
issues.
Yes,
okay.
Well,
maybe
we
can
fix
two
more.
B
So
I
can
see
that
the
test
phase
worked
and
one
of
the
reasons
why
it's
useful
to
especially
when
starting
off
have
that
cube.
Linter
not
fail
is
because
a
lot
of
the
times
when
you're
building
these
pipelines.
If
you
get
a
non-zero
exit
code,
it
fails,
you
actually
don't
get
to
continue
the
pipeline.
So
in
this
example,
I
have
two
two
commands
here,
so
I
have
like
a
lint
and
another
lens,
because
I
want
to
apply
different
config
files
right
now
applying
different
config
files.
B
This
means
that
if
this
first
command
fails
the
pipeline
just
stops,
it
doesn't
continue
through.
So
I
found
really
interest
or
really
useful
to
create
a
pipeline
where
it,
basically
it
gives
me
all
of
the
output
right.
So
I'm
going
into
github
actions
I
can
come
in
here.
I
can
see
all
of
the
output
from
both
commands
with
different
config
files.
B
I
can
then
look
at
them.
You
know
go
and
have
a
conversation
about
what
I
think
are.
Maybe
the
top
two
that
we
need
to
fix
right
run
is
not
root,
probably
a
top
one,
especially
if
it's
not
needed.
So
we
can
just
prioritize,
we
can
say
hey.
I
don't
really
care
that
much
about
your
service,
not
being
labeled,
because
it's
in
deployment
we'll
fix
it,
but
you
really
need
to
change
this
from
when
it's
not
root,
and
then
you
can
push
those
specific
policies
down
and
what
we
can
do
to
do.
That
is
well.
B
You
can
set
it
so
that
it
passes
on
tests,
but
if
they
want
to
move
it
to
the
staging
branch
or
if
they
want
to
move
it
up,
it's
going
to
fail
so
hey
by
the
way.
Here's
your
feedback,
if
you
want
to
keep
going,
you
know
we're
gonna
fail
to
build.
So
at
some
point
you
need
to
you
know,
bring
the
hammer
down
as
an
admin
and
and
say
hey.
B
This
is
not
what
we're
doing
and
one
of
the
great
things
about
you
know,
implementing
policy
this
way
and
sort
of
a,
I
guess,
sunshine
effect
to
it.
Where
we're
just
saying
hey:
these
are
the
policies
that
are
getting
tripped.
You
know
you
figure
out
what
to
do
with
it
is
it
allows
us
to
build.
You
know
realistic
security
policies
across
your
organization,
so
you
have
five
teams.
Eight
teams,
20
teams,
they'll,
need
to
also
go
and
say
hey
like
what
do
developers
need.
B
B
One
of
the
main
reasons
why
we
did
it
in
the
cli
phase
is
because
doc
rocks
has
rock
ctl,
which
is
like
an
image
scanner
and
all
and
gives
you
a
lot
more
functionality
towards
just
images
in
terms
of
for
the
developers.
So
we
have
kind
of
those
paired
clis
and
we
thought
it
was
really
useful
to
if
we're
going
to
be
kubernetes
focused
here's
your
image
scanning
and
then
here's
the
configuration
of
the
images
in
the
cluster.
B
I
thought
it
was
a
good
whole
life
cycle
approach
and
then,
obviously,
when
you
get
into
the
stack
rocks
the
sensor
collector
and-
and
you
know
more
of
the
the
the
user
interface,
then
you
get
whole
lifecycle,
kubernetes
security
management.
So
again
it's
that
first
stop
developer
checkpoint
for
figuring
out
where
your
security
vulnerabilities
lie
with
kubernetes,
and
hopefully
it
gives
you
enough
flexibility
to
be
able
to
adopt
it
and
grow
from
there.
E
B
C
C
So,
obviously,
one
big
component
of
what
we're
adding
is
more
more
checks
and
there's
a
few
different
things
here.
There's
like
one
there's
like
more
checks
along
the
lines
of
what
we've
written
another
is
of
feature
request.
We've
heard
from
some
people
is
to
have
some
checks,
that
map
specifically
to
certain
compliance
checks
and
allow,
and
not
just
add
those
checks,
but
allow
some
way
of
tagging
checks
with
metadata
as
to
like
these
checks
will
help
you.
C
These
texts
are
required
for
you
to
be
in
compliance
with
this
standard,
and
things
like
that.
We
want
to
consider
additional
resources
that
we
don't
yet
consider
in
our
checks,
like
network
policies
or
pot
security
policies,
and
things
like
that
and
like
checks
based
on
those.
So
a
simple
check
could
be
like.
C
Does
your
deployment
have
a
network
policy
and,
if
it
doesn't
it
should,
because
otherwise
it
can
talk
to
anything
and
more
complex
checks
could
be
allowing
people
to
to
write
like
more
fine-grained
rules
on
network
policies,
like
you
know,
don't
allow
network
policies
that
are
overly
broad
or
whatever
they
want,
and
so
that's
like
something
we're
thinking
of
another
one,
a
big
one
that
we've
heard
is
custom
resources
right
now
we
support,
like
all
our
checks,
basically
work.
Only
on
like
native
kubernetes
objects
like
deployment
services,
demon
sets,
and
things
like
that.
C
But
you
know
with
the
latest
versions
of
kubernetes
like
custom
resources
are
becoming
a
bigger
and
bigger
thing,
and
we're
trying
to
figure
out
what's
a
good
way
to
support
them,
and
this
also
includes-
and
it's
not
in
addition
to
custom
resources.
There's
like
other
things
like
you
know.
Openshift,
for
example,
has
its
own
resources
like
security
context,
constraints
and
deployment
configs,
and
that's
another
thing
we
would
want
to
support
as
well.
C
These
templates
that
we
provide
and
allowing
you
to
like
parameterize
those
templates,
but
we
are
thinking
of
ways
to
allow
more
flexible
specifications
of
checks
for
cases
where
that
works,
because,
right
now,
if
you
want
to
write
a
totally
new
kind
of
check,
you
will
need,
we
will
need
to
update,
go
code
and
like
release
a
new
version
of
kublet,
which
is
not
ideal,
so
we're
we're
still
figuring
out
how
to
design
this.
But
you
know
some
ideas
are
the
the
simplest
on
the
spectrum
is
like
something
like
using.
C
You
know,
like
json
paths,
allowing
people
to
specify
json
paths
or
something
to
say
like
this.
This
field
in
the
yaml
should
be
equal
to
this,
whereas
a
more
complex
thing
along
the
spectrum
would
be
like
allowing
people
to
put
in
you
know,
lego
policies
and
use
what
they
use
in
oppa
with
coop
linter.
C
Obviously,
it's
not
going
to
be
possible
everywhere,
because
in
many
cases
we
can
just
tell
you
like
something's
missing
and
you
need
only
you
know
what
is
to
be
added,
but
in
there
are
some
cases
where
we
can
fix
things
on
our
own,
similar
to
what
many
lenders
do
and
that's
something
we
would
want
to
support
and
then
more
convenience
command
line
flags.
So
you
know
people
have
asked
us,
there's
a
few
requests
on
this
and
we've
added
some
like
some
of
the
command
line.
C
Flags
you
saw
michael
use
were
added
in
response
to
user
feedback,
but
people
have
asked
us
for
things
like
you
know,
hours
to
ignore
certain
parts
easily
and
things
like
that.
So
we
there's
like
a
bunch
of
those
usability
related
things
that
we
need
to
do
and
then
finally-
and
I
did
see
there
was
a
question
about
this-
we
really
want
to
do
native
integrations.
So
that's
two
big
buckets
like
one
is
with
ides,
so
you
know
vs
code
is,
I
think
the
one
we've
got
the
most
requests
for.
C
You
know
we
do
have
a
github
action
that
we
publish,
but
we
do
want
to
make
it
easier
to
just
drop
it
in
or
to
like
circle,
ci
or
jenkins,
and
things
like
that.
It's
right
now,
it's
not
terribly
hard
to
use
because
it's
just
a
binary
and
you
can
download
it
and
then
run
it.
But
we
in
my
experience,
like
the
easier
you
make
the
more
plugable
you
make
these
things
the
more
it
just
removes
a
lot
of
friction
and
makes
people
much
more
likely
to
use
them.
B
B
Yeah
yeah
worries
you
and
I
have
talked
about
creating
a
repository
with
a
bunch
of
basically
best
practices
right
like
I,
I
have
six
config
files
in
that
repository.
I
think
it'd
be
very
useful
to
to
kind
of
showcase
like
hey
here's,
some,
you
know
default
config,
setups
that
you
can
use
along
with
different
actions,
whether
it
be
like
gitlab,
jenkins,
github
as
well
so
yeah
yeah.
I
think
we
should
definitely
add
that
to
the
roadmap.
C
Yeah
yeah,
absolutely
thanks,
michael
that
totally
agree
problem
yeah.
So
that's
that's
a
little!
That's
a
high
level
overview
of
the
roadmap
and
our
roadmap
is
managed
entirely
on
our
github,
so
we
use
github
projects
which
allows
us
to
basically
use
github
issues
as
tickets
and
then
put
them
put
them
in
this
context
of
the
roadmap
yeah.
B
C
C
Just
yeah,
I
think
the
last
slide
was
just
about
like
helpful
links,
but
you
know
we
already
went
over
those,
but
maybe
just
maybe
maybe
just
forward
one
more
yeah
definitely
well
yeah.
So
this
is
the
link
to
our
github,
which
you,
which
I
think
some
people
have
posted
in
the
chat
already
to
link
to
a
paul's
issue.
We
also
have
a
docs
website
that
michael
showed
you
we,
you
can
also
communicate
with
us
by.
C
The
link
to
join
the
slack
is
on
the
github.
So
if
you
just
go
to
the
github
page
and
search
slack,
we
have
a
invite
link
that
you
can
use
and
we'll
take
you
right
into
our
slack
workspace
and
all
of
us
are
on
it
and
you
know
we
try
to
be
pretty
responsive.
So
if
you
have,
if
you
just
want
to
like
talk
to
us
about
anything
like
that's,
probably
the
lowest
friction
way
for
you
to
reach
us
and
yeah.
Try
the
coop
linter
walkthrough.
That
michael
has
put
together.
C
C
We've
done
at
stack
rocks
we
and
we're
like
learning
a
lot
about
this
as
we
go
through
with
this
specific
project,
and
we
we've
been
happy
with
the
response
we've
received
so
far
and
we're
looking
forward
to
engaging
more
with
users
and
trying
to
figure
out
like
how
we
can
make
this
a
better
a
project,
that's
like
more
useful
to
our
community.
So
definitely
looking
forward
to
hearing
from
you.
I
think
one
one
thing
we're
specifically
interested
in
is
you
know
how
how
are
people
using
it?
C
I
think
we've
we
found
that
people
do
file
issues
when
they
run
into
bugs
or
when
they
have
feature
requests,
but
it
can
sometimes
be
hard
to
figure
out.
Like
is
this.
Are
these
just
like
the
tip
of
the
iceberg
of
people
using
it
and
like
there
are
many
people
who
use
it
but
don't
actually
get
around
to
filing,
so
any.
C
I
guess
what
I'm
trying
to
say
is
like
any
input
on
how
you're
using
it
is
welcome,
even
if
you
don't
have
like
a
concrete
suggestion
or
request
just
because
that's
interesting
to
for
us
to
hear
about,
but
that
I
think
that's
the
end
of
our
our
presentation.
So
thank
you
for
listening
and
I
guess
we'll
take
questions
now.
A
C
C
A
A
Well,
it
seems
I
was
talking
with
michael
a
little
bit
before
everybody
got
talking
today
and,
and
we
hit
the
record
button
about
how
this
seems
like
a
nice
complementary
thing
to
what
you
have
for
products
as
well.
The
products
are
more
based
on
examining
images,
so
you
know,
I
would
think
that
this
fulfills,
you
know
a
need
for
this,
this
piece
of
the
work-
and
I
was
just
wondering
how
this
relates
maybe
to
operators,
because
we
talk
a
lot
about
using
operators
versus
hem,
charts
and
yaml
files.
C
Not
not
specifically
like
we
haven't,
we
haven't
done
anything
specific
to
operators.
Here
we
again
like
since
we're
analyzing
the
yaml
files
to
some
degree.
You
know
if
you,
if
you're
able
to
render
the
operator
into
a
yaml
file
or
into
like
its
final
yaml
files
like
the
tool,
will
work
but
yeah.
The
things
that
we
are
we
focused
on,
at
least
at
the
beginning,
have
been
a
better
support
for
hand,
charts
so
with
hand
charts
we.
C
We
don't
require
users
to
render
them
like
we
kind
of
use
the
helm,
libraries
under
the
hood
and
if
we
detect
that
it's
a
hand
chart
we
just
automatically
like
render
the
yamls
or
the
templates
and
run
our
checks
on
them.
And
another
thing
we've
heard
requests
for
is
customize
as
well,
which
some
people
use
to
manage
their
configs,
but
yeah.
That's
a
good
suggestion
and
something
for
us
to
look
into.
A
Yeah
it'll
be
interesting
to
see
how
that
looks.
There
have
been
a
couple
of
things
that
have
come
up
in
the
chat.
Noel
has
a
list
of
issues
that
he's
seen
other
customers
from
his
perspective,
and
I
love
the
acronym
over
my
dead
body.
I
don't
know
noel
if
you
want
to
share
that
list
with
them
and
and
walk
through
that
a
little
bit.
A
C
C
What
we're
building
here
is
more
focused
on
kubernetes,
and
that's
that
allows
us
to
do
that
allows
us
to
do
some
things
which
are
more
kubernetes
natural,
like
for
example,
the
way
we
ignore
checks
by
annotations,
for
example,
like
we've,
been
able
to
build
that
into
the
tool,
because
we
have
this
assumption
that
we
are
working
on
kubernetes,
yaml
files
and
the
another.
One
is
how
we
are
building
native
support
for
hand,
charts
and
we're
just
like.
If
you
see
a
handshake,
we
just
render
it
like.
C
C
So
those
are
the
a
couple
of
reasons
we
decided
to
build
something
something
different
and
we
do.
I
do
still
think
that
the
oppa
language
is
very
powerful,
much
more
powerful
than
you
know
the
the
kind
of
language
we've
built
of,
but
that
comes
complexity,
but
we're
also
thinking
of
a
ways
to
ways
to
make
our
base
to
like
use
the
oppa
or
language
in
our
policy
configuration.
C
So,
like
I
mentioned
the
roadmap
within
your
ways
to
make
more
flexible
policies
and
one
of
the
ways
we
would
we
could
do
that
might
be
like
allow
people
to
specify
rego
files
and
so
essentially
for
people
who
want
that
added
flexibility.
They
get
that
right
and
coupe
linker,
but
they
also
get
the
convenience
of
you
know
all
our
other
specific
features
so
hope
that
answers
the
question
it.
A
F
A
F
Perfect,
so
I've
put
those
lists
of
things
together
over
the
last
while
because
it's
what
we're
seeing
with
very
large
customers
of
openshift,
is
it's
not
necessarily
the
developers
that
are
struggling
with
these
things?
It's
it's
large
operations
teams
are
up
or
even
small
operations
teams
that
have
a
large
number
of
third-party,
either
vendor
applications
or
in-house
development
teams
where
they
spend
the
majority
of
their
time
getting
stuff
onto
the
cluster
and
then
spend
the
rest
of
their
time.
F
Trying
to
figure
out
what's
gone
wrong,
so
things
like
missing
readiness,
probes
and
all
that
type
of
stuff,
and
especially
in
the
fsi
space.
We're
seeing
things
around.
You
know
when
you
you're
working
service
mesh
is
mtls
enabled
on
on
service
mesh
or
not
so
it's
kind
of
more
granular
things,
but
it
was
around.
Basically,
how
do
we
enable
those
customers
to
actually
kind
of
set
up
kind
of
standards
that
have
to
be
enforced?
F
B
B
Yeah,
no,
it's
it
it's
good
and
it's
actually
great
to
hear
that
the
developers
aren't
the
ones
having
an
issue.
I've
I've
always
found
when
I've
been
working
with
customers,
especially
like
an
in
consulting
role
it
it's
it's
just
the
issue
of
like
fine-tuning
policy
across
different
teams.
Right,
it's
it's
the
admin
aspect
of
kubernetes,
because
the
multi-tenant,
when
you
get
multi-tenant
setups,
it
just
becomes
a
little
more
complicated.
B
So
a
lot
of
our
tools
are
focused
around
users,
but
users
at
scale
right,
because
security
only
really
works
when
people
buy
in,
and
so
we
want
to
make
sure
that
the
tools
are
set
up
so
that
we're
not
just
kicking
people
out
of
the
cluster
we're.
You
know
it's
more
of
a
security
observability
tool
with
the
ability
to
enforce
policies.
Right,
that's
that's
the
goal,
but
yeah.
This
is
really
cool
repo.
Thanks
for
sharing
this.
B
A
It
sounds
like
a
game
plan
here.
This
is
great.
It
also
sounds.
You
talk
michael
a
little
bit
about
having
some
best
practices,
config
files
as
well,
so
setting
up
sort
of
recipes
and
cookbooks
for
people
to
to
use
as
best
practices
in
their
own
organizations-
and
I
think
maybe
some
of
what
noel
is
is
listing
here-
are
our
best
practices,
things
for
you
for
different
platforms
that
we're
deploying
to
so
it's
actually,
some
really
cool
work
to
go
through
and
collaborate
with
you
guys
on
so.
A
C
So
far,
I
think
we've
kind
of
been
focused
on
just
the
project
is
only
three-ish
months
old
at
this
point,
since
we
released
it,
and
so
we
just
been
kind
of
focused
on
understanding
like
how
are
people
using
it
and
trying
to
make
improvements
to
it,
and
I
think
you
know
when
we
released
it,
we
didn't
know
what
to
expect
whether,
like
nobody
would
care
or
whether,
like
people,
would
use
it
and
we've
been
happy.
It's
exceeded.
C
Our
expectations
for
like
people
have
been
interested
and
have
been
using
it,
and
I
think
you
know
now
is
a
good
time
to
think
about
things
like
that
again.
This
is
something
we
don't
have
a
ton
of
experience
with
at
stackdogs,
because
this
is
our
biggest
open
source
project,
and
so
I
think
this
is
something
we
need
to
figure
out
but
yeah.
To
answer
your
question
we
haven't,
given
that
a
lot
of
thought
so
far
to
be
honest,.
A
Well,
it
looks
like
from
the
interest
in
it
today
and
the
work
that
you've
done
you're
on
the
right
path,
so
I
think
you'll
think
we're
gonna,
follow
you
guys
actively
and
see
and
see
how
this
goes
and
have
you
back
again
with
the
next
release
of
it.
So
this
is
awesome,
so
thanks
very
much
for
coming
today.
It
we
totally
appreciate
the
the
overview
and
the
deep
dive
into
it
and
look
forward
to
working
with
you
guys
more
on
this.