►
From YouTube: Cloud Native Live: Enforce Configuration & Security Checks for YAML Files & Helm Charts w/KubeLinter
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
A
All
right,
I
guess
we're
live
now
so
hello,
everyone.
Thank
you
for
joining.
Welcome
to
cloud
native
live
where
we
dive
into
the
code.
Behind
the
cloud
native,
I
am
itai
shakuri,
I'm
director
of
open
source
for
aqua
security,
I'm
also
a
cloud
native
ambassador
and
I'm
joining
as
co-host
for
today's
show.
So
I'm
happy
to
be
here
cloud
native
live
is
where
our
weekly
show.
Every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
your
questions,
so
this
happens
every
wednesdays
at
8,
00,
pacific
and
today
we
have
our
friends
from
stockworks
here
to
talk
about
cubelinter,
just
a
quick
reminder
to
join
us
at
kubecon
and
cloudnativecon
in
europe
early
next
month
to
hear
the
latest
from
the
cloud
native
community
and
a
quick
admin
before
we
hand
it
over.
This
is
an
official
live
stream
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
A
B
Vishway,
hey
everyone.
My
name
is
vishwa
and
thanks
for
coming,
depending
on
where
you
are,
whether
either
early
in
the
morning
or
later
in
the
day
to
attend
this
talk,
so
I'm
vishwa
and
I'm
an
engineer
at
stack,
rocks
or
what
was
formerly
stuck
rocks.
It
feels
funny
to
say
that,
because
about
two
months
ago
stack
rocks
was
acquired
by
red
hat
and
now
we,
our
product
and
our
team,
are
joining
the
red
hat
portfolio
of
of
our
products
and
companies.
B
If
you
would
like
to
get
in
touch
so
definitely
gonna
keep
it
informal
and
please
at
any
time,
feel
free
to
ask
your
questions
in
the
chat,
we'll
be
monitoring
them
and
we'll
definitely
have
a
dedicated
time
for
questions
at
the
end.
But
if
something
doesn't
make
sense,
please
feel
free
to
ask
questions.
You
don't
have
to
wait
for
the
end
either.
B
So
before
I
jump
into
the
demo
itself,
just
a
very
quick
overview,
so
kube
linter
is,
as
the
name
probably
suggests,
a
linter
for
kubernetes,
specifically
for
kubernetes
configurations,
which
are
typically
in
the
form
of
yaml
files,
and
the
idea
is
that
the
the
real
problem
we're
trying
to
solve-
and
it's
one
that
we
had
internally
back
at
stack
rocks-
is
that
a
lot
of
kubernetes
configurations
are
a
complicated.
You
know,
there's
like
a
lot
of
fields
that
you
can
fill
in
in
the
yaml
file.
B
Most
of
them
are
optional,
so
you
don't
know
what
is
required
or
what
what
you
can
kind
of
get
away
without
and
b,
a
lot
of
defaults
are
not
secure
and
there's
a
couple
of
reasons
for
that.
One
is
you
know
they?
The
google
kubernetes
initially
did
not
have
a
lot
of
security
features,
and
so,
when
they
added
them,
they
had
to
kind
of
default
them
to
off,
because
otherwise
it
would
break
backward
compatibility,
and
another
reason
is
kubernetes-
is
kind
of
complicated.
The
part
of
the
reason
for
its
success.
B
It's
the
level
of
flexibility
it
offers
and
flexibility
always
comes
with
some
complexity
and
the
the
the
challenge
they
had
is
you
know
they
want
to
make
it
possible
for
people
to
actually
see
something
up
and
running
with
the
tool,
and
what
that
means
is
some
of
the
defaults
that
are
geared
to
some
of
the
defaults
are
geared
towards
that,
and
not
necessarily
towards
security,
because,
as
we
all
know,
there's
always
there's
generally
a
trade-off
between
something,
that's
more
secure
and
something
that's
like
quicker
to
get
up
and
running.
So
those.
B
So
those
are
the
two
big
problems
that
we
tried
to
solve
with
google
enter
and
the
I
the
way
we
tried
to
do
that
is.
We
looked
tried
to
make
it
so
that,
if
you
run
kubelntor
by
default,
it
will
complain.
If
you
have
your
configuration
in
a
way.
That's
not
secure
and
then,
when
you
run
kubelntor
against
your
yaml
files,
you
can
see
the
errors
that
it
prints
out
and
update
your
configurations
to
be
more
secure.
B
So
that's
a
very
high
level
overview
of
the
tool
itself.
You
can
see
the
tool
in
you
can
see
the
link
to
the
tool
in
the
the
banner
on
the
on
your
screen
and
feel
free
to
check
it
out,
but
I'll
definitely
be
diving
more
into
the
repo
later
on,
as
well.
So
with
that
preamble
out
of
the
way,
let
me
get
started
with
the
demo.
So
just
give
me
a
second
to
share
my
screen.
B
C
Good,
I'm
pauline.
I
will
work
here
today
with
italy.
I
just
just
a
few
questions
before
you
start
your
demo
yeah
of
course
yeah
sure
I
I
look.
I
look
at
the
the
the
project.
There
is
a
open
source
brush
right
and
the
the
idea
is
check
the
configuration.
It's
amazing
project,
it's
very
good,
and
maybe
maybe
you
can
explain
a
little
a
little
bit
for
us
what
what
what
it
was
right
in
go
link
right,
so
it
functions.
C
B
Yeah,
I
think,
are
you
referring
to
the
decision
to
like
build
it
and
go
in
a
similar
client
to
coupe
control?
If
is
that
the
case?
Yeah?
Okay,
so
basically
the
idea
there
is
that
it
was
honestly
just
what
is
easiest
for
us.
So
the
the
thing
is
like
kubernetes
itself
is
written
in
go,
and
so
we
by
writing
in
go.
We
get
to
take
advantage
of
the
libraries
that
kubernetes
offers,
which
is
a
like.
You
know.
B
The
biggest
heavy
lifting
in
our
coop
linter
code
comes
from
the
kubernetes
code
itself,
which
we
use
as
a
library,
and
the
second
is
you
know
by
using
the
similar
similar
tool.
We
also
get
a
very
similar
feeling
clay
and
so
one
that's
very
familiar,
I
think,
to
people
who
are
in
this
ecosystem
and
are
used
to
using
tools
like
coupe
control
and
other
tools
in
the
ecosystem,
so
just
giving
people
the
kind
of
familiar
feeling.
You
know
it's
just
like
it's
just
like
a
static
binary.
B
C
Very
great,
so
we
can
say
that
we
have
a
one
one,
two,
two
to
put
in
the
sre
and
developers
toolbox
right
like
on
live
control.
You
have
this
cube,
lit
linter
to
to
use,
during
my
daily
job,
checking
the
code,
checking
the
the
compliance
of
the
code,
etc.
So
it's
a
more
one-two
inside
of
the
toolbox
for
us
right.
B
Happy
to
hear
and
definitely
will
will
keep
that
in
mind
cool,
so
I
am
going
to
share
my
screen
and
itai
and
paulo.
I
will
in
case
I'm
sharing
the
wrong
screen
or
I'm
not
sharing
my
screen
correctly,
please
let
me
know,
but
otherwise
I
will
assume
that
it's
working
as
intended
cool.
So
here
we
are
and
like
I
said
that
this
is
going
to
be
a
demo
of
the
capabilities
of
of
kube
linter
and
the.
B
B
So
now,
how
does
kublenter
itself
work
so
I'll
go
over
installation
and
stuff
later,
but
it's
extremely
straightforward,
but
you
know
I
obviously
have
coblinker
already
in
the
system,
so
you
can
see
that
I'm
able
to
run
it
and
it
has
like
a
few
sub
commands
and
things
like
that
and
the
way
the
most
important
couple
inter
command,
that
you're
going
to
use
day
to
day
is
the
kubelinter
link
command,
which
links
kubernetes,
yaml
files
and
hem
charts.
So
here
you
can
see
I'm
in
this
directory.
B
I
have
this
myapp.yaml
file,
which
is
the
same
one
that
you
can
see
on
the
right
side
of
my
screen
and
then,
when
I
run
kublenter
lint
and
pass
it
the
name
of
this
file,
you
can
see
that
it.
It
basically
is
going
to
run
against
this,
a
bunch
of
checks
and
output,
the
results
of
those
checks.
So
when
I
run
it,
you
can
see
it's
found.
Nine
lint
errors
over
here
and
there's
a
list
of
output
of
these
are
the
errors
it's
found.
B
So
so
what
I'm
gonna
do
now
is
just
kind
of
go
over
these
errors
and
how,
like
basically
kind
of
this
scenario
here
is
you
know
you
are
a
developer
you're
like
trying
to
configure
your
deployment
yaml
files,
or
you
probably
typically.
This
is
how
I
do
it
and
I'm
guessing.
This
is
how
most
people
do
it.
B
You
just
copy
something
that
you
know
works
and
then
change
whatever
you
need
until
you
have
your
specific
deployment
and
then,
after
that,
when
you
run
kubelntor,
it
can
tell
you
if
there
are
things
that
you're
doing
that
are
not
security,
best
practices
right.
So,
for
example,
here
we
see
that
it's
telling
you
that
this
object,
which
is
a
deployment
in
my
namespace,
called
non-compliant,
which
is
this
one
mounting
an
n
n
variable
as
a
secret,
and
so
you
can
see
you
can
see
that
here
uv.
B
I
mean
this
is
obviously
not
a
real
secret
key.
I
just
put
a
random
string
in
there,
but
you
can
see
that
here,
we've
used
aws
secret
key
and
just
put
it
directly
in
the
end
of
the
container
and
kublenter's
recommendation
is
to
not
do.
That
is
it's
to
mount
the
secret
as
a
file
or
use
a
f,
and
the
reason
for
that
is
that
n
variables
that
are
stored
this
way
are
much
more
exposed.
B
A
B
B
B
A
B
No,
it
does
not
right
now.
Coupe
linter
is
entirely
static,
so
so
we
don't
need
or
to
talk
to
the
kubernetes
api
like
we
just
look
at
the
files
and
we
don't
care
about
like
the
actual
cluster.
So
that's
how
we
are
that's
how
we're
architected
right
now.
Having
said
that,
we
do
have
plans
to
do
this
in
the
future,
or
there
are
some
things
we
can
do
where
we
can
help
the
customer
the
user
know.
Is
there
a
way
that
is.
A
B
B
You'll
only
find
out
when
you
actually
try
to
deploy
your
deployment
in
this
that,
oh,
it
isn't
working,
because
the
service
account
doesn't
exist
and
so
you're
not
able
to
do
the
api
access
that
you
want,
but
kublenter
kind
of
since
it
has
this
global
view
of
the
of
all
your
files
and
all
the
objects.
It
sees
that
okay,
there's
no
service
account
that
I
can
see
called
non-existence.
So
are
you
sure
this
is
correct
and
sure
enough?
B
You
know
our
service
account
here
is
called
like
my
dash
service
dash
account
and
if
I
go
and
change
this
to
be
my
service
account
and
I
rerun
kublenter.
You
can
see
now
there's
only
six
where
there
were
seven
and
that
first
error
is
gone.
So
again,
we've
managed
to
work
through
work
to
do
that
as
well.
So.
B
A
B
You're
deploying
having
said
that
there
are
some
of
our
users
who
do
who
just
use
it
for
one
file
at
a
time
and
or
they
may
want
to
disable
checks
like
the
service
account
one
because
you
know
maybe
the
service
account
is
already
in
the
cluster,
and
they
know
that.
But
to
go
back
to
your
point
like
this
is
another
thing
where,
if
we
had
the
coupe
config
access
like,
maybe
we
could
make
this
also
more
seamless
as
well,
but
right
now.
As
I
said,
we
don't
do
that.
B
Oh
cool
yeah
and
then
you
know,
there's
a
few
other
errors
here
which
I'll
go
over
very
quickly.
I
don't
want
to
necessarily
use
up
all
the
time,
because
there's
a
bunch
here,
but
here
we're
seeing
that
this
object
is
not
running
as
non-root,
which
is
another
good
security
practice
again.
I
should
mention
that,
with
things
like
run
as
non-root
read-only
root
file
system,
like
you
cannot
blindly
change
to
them,
you
need
to
be
sure
that
your
app
doesn't
depend
on
it
most
of
the
time.
B
Apps
don't
really
depend
on
or
running
as
root.
So
that's
something
that
should
be
safe
with
read
only
root
file
system.
You
need
to
make
sure
that
you
know
your
code.
Your
code
is
taking
that
into
account
that
maybe
you
only
write
files
in
like
a
well-known
directory
like
slash
temp,
and
then
you
make
it
so
that
it
can
only
write
it
in
temp,
but
just
wanna
throw
that
out
there
that
you.
These
are
security
settings
that
constrain.
B
I
have
a
compliant
container,
that
kind
of
has
all
this
already,
so
I'm
just
gonna
copy
copy
what
it
has
in
its
configuration
and
again
you
know
these
are
things
that
are
gonna
take
longer
to
in
practice,
because
you
don't
actually
know
what
the
cpu
requests
and
limits
are.
That
may
require
you
to
do
some
measurement
or
have
some
understanding
of
like
the
workloads
that
your
container
is
how
your
container
workloads
are
expected
to
work
in
our
experience.
That
does
take
its
own
time
as
well.
B
Maybe
some
containers
need
privileges,
so
let's
assume
that,
for
whatever
reason
you
know,
I
want
to
run
this
as
privileged.
Now,
how
do
you?
How
do
you
do
that
in
kube
linter
right?
So
you
have
two
options.
One
is
you
can
disable
this
check
itself?
Which
means
you
don't
care
about
running
things
as
privileged
or
like.
It
doesn't
matter
to
you
at
all,
and
we
support
that
via,
like
an
exclude
flag,
so
you
can
exclude
checks
by
name
and
sorry.
I
think
I
spelled
that
you
can
exclude
checks
by.
B
Oh
sorry,
I
don't
know
what
happened.
You
can
exclude
checks
by
name
and
you
can
explore.
Obviously,
multiple
checks,
so
this
is
a
check,
that's
run
by
default,
and
so
you
need
to
explicitly
exclude
it
and
then,
when
I
run
with
this
check
being
excluded
and
you
get
the
name
of
the
check
from
the
output,
sorry,
I
seem
to
be
struggling
to
spell
when
the
word
is
wrapping
around.
B
B
So
the
way
that
annotation
is
structured
is
is
like
this,
so
you
basically
have
a
key
which
is
ignorecheck.coublinter.io,
and
then
you
pass
in
like
the
name
of
the
check
which
you
again
copy
from
there,
and
then
you
just
say
true
right
and
then,
when
you
do
that,
you
can
see.
Oh
sorry,
maybe
I
think
I
missed
a
dash
when
you
do
that.
B
You
can
see
that
the
check
goes
away,
and
this
is
because,
although
we
are
running
the
privilege
check
like
we
haven't
excluded
it,
we
are,
we
are
basically
running
it
saying
that
this
check
is
ignored
just
for
this
deployment,
so
that's
kind
of
how
how
you
would
deal
with
exceptions
in
cases
like
that,
and
you
can
ignore.
You
know
any
number
of
checks.
There's
also
a
way
to
ignore
all
checks
for
a
specific
deployment.
B
B
You
can
see
that
we
support
things
like
include,
exclude
in
the
configuration
file
itself,
so
you
can
include
some
checks.
You
can
exclude
checks,
you
can
also
say,
do
not
auto,
add
defaults,
and
what
that
does
is,
if
you
set
that
to
true,
then
the
default
checks
are
not
added
automatically.
As
you
saw,
you
know,
we
tried
to
make
a
lot
of
checks
run
by
default.
B
When
you
just
run,
google
enter
linked
with
no
arguments
so
that
again
it's
like
security
by
default,
but
if
you
don't
want
that
behavior
and
you
just
want
to
explicitly
include
the
checks
you
care
about,
you
can
do
it
here.
All
these.
We
we've
made
it
so
that
everything
in
the
config
file
under
checks
can
be
also
configured
directly
as
command
line
arguments,
so
you
can
do
dash
dash
exclude
like
we
did.
You
can
do
dash
dash,
do
not
auto,
add
defaults.
B
So
all
that
works-
and
you
know
if
you
specify
both
in
a
config
file
and
in
command
and
and
as
a
client
flag,
we
will.
We
will
give
precedence
to
what
you
pass
on
the
command
line
versus
what's
in
the
config
file,
so
definitely
try
to
be
flexible
with
configuration
there,
and
the
other
thing
I
wanted
to
go
over
is
custom
checks,
so
kubelinter
does
support
custom
checks
and
the
way
you
do
custom
checks
is
you
need
to
pass
like.
B
So
this
is
an
example
of
a
custom
check
and
you
need
to
pass
like
the
name
of
a
template
and
based
on
the
name
of
the
template.
Each
template
is
a
basically
a
piece
of
go
code.
That
does
something
so
the
template
here
in
this
case
is
called
required.
Annotation
and
the
way
you
would
kind
of
figure
out
you
know
the
list
of
templates
is
is,
if
you
go
to
the
kubelinter
documentation
you
can
see.
B
We
have
like
a
list
of
templates
that
we
support
and
this
specific
one
is
called
required,
annotation
right
and
basically,
what
it
does
is
it
flags
objects
that
are
not
carrying
at
least
one
annotation.
That
matches
the
provided
patterns
so
you're
saying
that
basically
you're
saying
all
my
objects
are
required
to
have
this
annotation
and
the
way
it
works.
Is
you
and
the
way
it
works?
B
Is
you
specify
like
parameters
to
the
check,
so
you
need
to
specify
like
a
key
and
optionally
a
value
as
well,
and
what
we've
done
here
is
we've
said:
there's
a
required
annotation
and
the
parameter.
We're
passing
is
that
the
key
is
steam,
and
so
what
we're
doing
in
practice
here
is
that
we're
saying
that
all
yaml
all
objects
that
I
configure
need
to
have
an
annotation
team,
and
maybe
this
is
because,
when
I'm
actually
running
this,
I
want
to
know
which
team
owns
which
object
right.
B
So
the
way
I
would
run
kubelenter
with
this
is
I
just
passed
a
dash
dash
config
and
you
can
see
like
I
just
this,
pointing
to
the
file
I
just
opened,
and
you
can
see
you
know
this.
There's
an
error
now
or
the
non-compliant
app.
It's
saying:
there's
no
annotation
found
matching
team
equals
any
where
it
means
that
the
key
is
team
and
the
value
can
be
anything
and
it
doesn't
have
that
annotation,
whereas
here
you
know,
we
do
have
that
annotation
for
the
service
account
as
well.
B
We
do
have
that
annotation
and
if
I
kind
of
copy
this
annotation
here
and
stick
it
into
this
deployment,
no
no
lint
errors
are
found.
So
that's
that's
kind
of
how
you
can
do
your
custom
checks,
and
this
is
just
a
particularly
simple
example,
but,
as
you
can
see,
we
support
a
lot
of
written
templates
and
you
can
go
over
the
documentation
to
figure
out
what
is
supported
and
we're
adding
more
to
these
all
the
time.
B
Yeah,
so
adding
your
own
templates
requires
a
code
update,
so
you
need
to
send
you
know
you,
you
need
to
send
the
pr
for
that
and
basically,
you
need
to
update
the
google
enter
version,
so
the
templates
right
now
are
go
code
and
kind
of
bundled
into
koblenter
and
where
this,
the
flexibility,
this
gives
you
know
covers
what
we
found
is.
It
covers,
like
maybe
80,
90
percent
of
the
use
cases.
B
B
Maybe
one
of
our
templates
is
just
like
supporting
oppa
right,
like
we
allow
people
to
write
like
lego
policies
that
can
be
arbitrary
and
put
that
and
make
that
like
a
template
and
then
for
like
advanced
users
who
have
like
a
very
specific
thing.
They
want
they
just
use
rego,
but
if
it's
something
more
commonly
common
and
is
supported
by
kubelinter,
then
they
can
just
use
our
like
use.
A
Yeah,
it
makes
complete
sense.
Actually
I
was
wondering,
as
you
were
explaining
what's
your
take
on
oppa
is
because
a
lot
of
similar
approaches
or
concepts
shift
left
for
infrastructure
is
code
scanning
very
prevalent
with
rego
slash,
oppa
technologies,
so
so
yeah,
it
ringed
the
bell
so
and
it
makes
completely
sense
if
you
are
going
to
support
or
planning
to
support
oppa
as
well.
A
B
That
and
that's
kind
of
what
we
focused
on
here
and
but
tools
like
oppa
are
extremely
useful
because
they
are
so
expressive
right
like
that.
You
can.
If
you
have
like
this
very
specific
thing
that
you
want,
you
can
do
that
in
opa,
like
no
matter
what
it
is,
and
so
we
think,
like
the
right
way,
is
to
like
give
like
a
simple
configuration
mechanism
for
users
for
like
the
80
of
cases.
A
Yeah,
there's
definitely
a
learning
curve,
I
think
for
writing
gregor
policies.
I
hear
it
myself
as
well
and
also
just
a
comment.
I
it
kind
of
ring
the
bell,
also
the
separations
between
the
templates
and
the
instantiations
of
the
of
them
or
the
the
the
usage
of
them.
From
my
experience
in
the
oppo
world,
something
similar
like
in
a
contest
or
gatekeeper,
they
have
the
constraint
template.
A
So
maybe
some
of
the
listeners
are
familiar
and
to
me
it
sounds
exactly
like
the
same
concept,
which
is
a
it's
a
great
concept
where
you
have
defining
the
the
template
once
and
then
you
can
reuse
it
multiple
times
so
kind
of
for
me.
It
helped
me
understand
what
you
are
after
here,
so
maybe
it
will
have
the
readers
as
well.
B
A
B
B
This
is
an
issue
that,
like
an
open
issue
on
our
github,
that,
like
has
quite
a
few
thumbs
up
the
last
time
I
checked,
and
it's
something
we're
trying
to
figure
out
the
the
challenge
is
you
know
trying
to
keep
our
simplicity
of
configuration
that
we
have,
while
also
giving
people
like
a
good
way
to
plug
in
their
crds
and
we're
still
working
that
out,
but
right
now?
No,
you
cannot.
B
A
Thanks,
we
also
had
another
questions
about
integrating
in
the
pipeline,
but
you
already
mentioned
that
you
are
going
to
address
that
in
the
demo
we
had
a
an
earlier
question
kind
of
a
more
general
one
about
now
that
red
hat
acquired
stack
rocks.
What
are
the
plans
in
regards
to
the
open
source
nature
of
the
project
or
the
governance
of
it?.
B
No,
it's
not
something
we
currently
do,
but
it's
something
that
we're
planning
we're
planning
to
do,
and
it's
one
thing
we're
trying
to
we're
kind
of
struggling
with
here.
Is
you
know
it's?
Our
back
is
a
more
complicated
kind
of
configuration
as
anyone
who's
worked
with
kubernetes.
Our
back
probably
knows.
There's
like
all
these
links
that
you
have
to
kind
of
keep
track
of,
and
so
we're
trying
to
see.
Does
it
make
sense
to
have
it
in
a
tool
like
kublenter
or
does
it
require
kind
of
its
own
tool?
B
A
B
Yeah
so
right
now,
the
selective
application
is
at
the
level
of
the
top
level
object,
also
at
the
level
of
the
deployment.
So
you
know
if
you,
this
is
a
very
good
question
like
if
you
ignore
the
check,
then
that
ignore
propagates
to
all
the
spec
containers
in
the
deployment
and
not
just
not
just
the
one
that
you
like,
not
just
the
one
that
maybe
you
want
as
privileged,
so
that
is,
that
is
a
valid
question
and
a
gap
in
our
current
way.
B
B
B
It's
very
simple
because
you
know
it's
a
command
line
tool
that
that
you
just
download
and
it
works
out
of
the
box.
It's
a
statically
linked,
go
binary
like
no
other
dependencies.
You
just
need
to
make
sure
you
get
the
right
one
for
your
operating
system
and
of
course,
if
you
have,
if
you
have
the
go
command,
it's
just
a
simple
go
get,
so
you
don't
even
need
to
make
sure
to
download
the
binary,
and
then
you
just
run
it
on
your
files
right.
So
here
you
know.
B
I
have
like
an
example,
a
pr
where,
let's
say
I'm
like
running
running
like
a,
I
have
like
a
few
yaml
files
in
a
directory
and
then
I'm
basically
running
kubeblinter
against
them
in
ci,
and
basically
you
can
see
that
what
happens
is
it
just
run
like
kubelander
lint
dot,
and
then
this
dot
is
at
the
root
of
the
git
repo.
Also,
I
think
someone
had
a
question
earlier
about
this
about
directories
so,
basically
by
default.
B
I
ran
this
last
night
in
advance
for
the
demo
so
that
you
know
just
so
that
it
was
ready
for
you
all,
but
you
can
see
the
build
failed.
You
can
see
the
output,
the
same
output
that
you
were
seeing
on
my
terminal
earlier.
Maybe
I
should
zoom
in
actually
or
the
same
output
that
you
all
were
seeing
on
my
terminal
earlier
and
then
at
the
bottom.
It
tells
you
like
how
many
errors
were
found
and
then
over
here
it.
It
tells
you
like
it's.
B
I
think
the
link
has
been
on
the
stream.
So
I'm
sure
all
of
you
have
seen
this,
but
this
this
has
like
all
the
information
you
need
to
get
started
like
a
lot
of
the
things
I
covered
written
down
here,
how
to
install
them
things
like
that.
One
thing
I
wanted
to
call
out
is
that
we
do
have
a
slack
workspace
and
you
can
see
the
link
over
here
if
you
scroll
down
to
community
in
the
readme.
B
B
We
also
have
a
doc
site
which
is
linked
to
over
here,
which
I
think
I
showed
you
earlier,
but
we
we
know
that
from
our
experience,
that
with
open
source
projects
like
documentation
is
one
of
the
biggest
barriers
for
a
user,
and
so
we've
tried
to
invest
and
make
our
documentation
as
as
comprehensive
as
possible.
That
doesn't
mean
there
are
no
gaps
and
that
there
are
not
things
we
can
improve.
B
They
definitely
are,
but
hopefully
this
documentation
has
enough
for
you
that
you
can
kind
of
figure
out
how
to
use
the
tool
and
configure
it
to
your
needs,
so
definitely
encourage
you
to
check
it
out
at
docs.googlinter.io,
and
in
case
you
have
you,
there
are
any
in
case.
You
have
issues,
you
find
a
bug,
or
you
have
a
feature
request.
B
We
also
maintain
our
roadmap
itself
on
github.
So
if
you
go
to
project
slash
roadmap,
you
can
kind
of
see
these
other
things
that
we
have
to
do,
and
these
are
all
all
of
them
are
things
that
if
you
are
ever
interested
in
contributing
you
know,
you
can
feel
free
to
go
to
the
road
map
find
something
that
you're
interested
in
doing
maybe
comment
on
it
and
ask:
does
your
approach
make
sense
and
if
you
send
a
pr
we're
like
more
than
happy
to
happy
to
take
pr's?
B
So
that's
that's
how
you
can
contribute
and
of
course,
if
you
have,
if
you
want
to
discuss
in
more
detail,
you
can
join
the
slack
workspace
as
well,
and
then
that's
yeah.
That's,
I
think,
all
I
kind
of
had
on
kind
of
the
how
to
find
things
how
to
get
in
touch
with
us,
and
so
you
know
feel
feel
free
to
file
issues
and
prs
get
in
touch
with
us.
B
A
Yeah
a
great
demo
and
presentation
vishwa.
Thank
you.
Let's
see
if
we
have
something
interesting
from
the
chat
actually
something
I
thought
about.
While
we
were
speaking
so,
we
talked
about
linting
kubernetes
yaml
files
manually
using
the
cli,
so
that
would
be
like
at
development
time
before
I
push
changes,
and
then
we
talked
also
doing
the
same
thing
during
the
pipeline.
Have
you
thought
about
shifting
it
right
a
little
bit
into
the
cluster
itself
and
like
lint,
yama
or
workload,
definitions
from
the
cluster
or
continuously
do
that?
B
B
What's
what's
running
and
that's
more
and
we
know
that
because
that's
a
lot
of
what
we
do
in
our
commercial
product-
and
maybe
you
know
once
our
commercial
product
is-
is
open
source
there'll
be
like
a
easier
way
for
us
to
kind
of
do
like
you
leverage
some
of
that
work.
We've
done
there
in
coop
winter
as
well,
but
right
now
we
are
kind
of
just
focused
on
the
linting
and
ci
use
case.
B
And
but
we
do,
I
do
know
of
some
users
who
are
who
have
used
the
approach
of
just
running
like
coop
cuttle
get.
You
know
all
dash,
oh
yaml
and
then
piping,
that
to
google
enter
and
that
that
gives
you
like
effectively
this.
But
it's
not
as
as
nice.
As
you
know,
all
the
stuff
that
you
would
get
by
running
in
the
cluster
like
a
new
admission
controller
and
things
like
that.
A
B
Yeah,
so
we
don't
have
a
ui
right
now.
This
is
the
only
output
format
we
are.
We
do
have
a
pr
out.
One
of
the
open
pr's
is
actually
for
json
output,
and
our
hope
is
that
we're
trying
to
output
json
in
a
sarif
standard,
just
like
a
standard
format
for
static
analysis
reporting,
and
our
hope
is
that,
once
we
do
that,
there's
actually
a
whole
ecosystem
of
tools
that
that
kind
of
will
understand
that
output
and
be
able
to
work
with
them.
B
B
Yeah
there
are,
and
the
way
to
do
that
is
you
know.
I
only
went
over
the
kublenter
lint
command,
but
there's
a
kubelenter
checks
command.
That
gives
you
like
a
list
of
checks
and
then
the
same
list
is
also
there
in
our
documentation
as
well.
So
that's
that's
the
way
you
can
see
and
then
you
know
you
can
use
those
names
in
the
include
and
exclude
to
customize
which
checks
from.
C
I
I
have
a
question
here.
My
my
last
question.
Please
I
I
like
the
interaction
of
link
linker
with
the
kubernetes
annotation.
I
I
think
that's
a
good
good
approach.
We
can
say
that
when
you
have
a
team
working
on
a
team-
and
maybe
you
you
get
a
configuration
file
in
common
for
the
team,
but
someone
can
have
a
specific
case,
etc.
So
it's
a
we
can
say
that
is
a
good,
a
bad
spread.
So
a
good
practice.
You
adopt
the
annotation
for
control.
C
B
C
A
All
right,
I
think,
we're
close
to
the
end
great
demo,
great
presentation
and
good
interactions
from
the
people.
You
already
mentioned
how
to
get
started.
Your
guitar
repo,
your
slack
channels.
I
would
also
mention
that
we
have
the
cloud
native
live
channel
over
the
cncf
slack,
so
if
people
want
to
keep
being
engaged
once
this
stream
is
over
that's
another
option
and
if.
B
A
Yeah,
it
was
great
to
have
you
vishwa
and
talk
about
the
cube,
linter
and
just
a
reminder.
This
is
a
weekly
show.
We
meet
every
wednesday
at
8
am
pacific.
By
the
way
this
has
changed.
The
time
has
changed
from
the
from
previously
so
make
note
it
used
to
be
3
p.m.
Eastern
and
yeah
so
see
you
again
next
week
on
cloud
native
live.
Thank
you.
Everyone.