►
From YouTube: CNCF CNF WG Meeting - 2021-12-06
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
folks,
we'll
get
started
at
about
five
after
hey
oliver
welcome
kishore.
A
A
Hello
greetings.
Everyone,
let's
see
we'll
get
started
here
in
just
a
moment.
You
can
add
your
name
and
any
agenda
items
or
if
you
have
an
agenda
item
you
can
say
it
out
loud.
A
B
If
it's
not
a
problem
for
you
taylor,
could
you
do
the
sharing
well,
I
did
yeah.
C
Right
so
the
first.
B
Item
is
simply
the
upcoming
events.
As
usual,
we've
got
kubecon
imminently.
B
So
yeah
kubecon
at
the
end
of
the
week,
that's
the
china
version.
So
for
those
of
you
who
are
a
little
bit
more
in
a
civilized
time
zone
and
who
have
signed
up
to
it,
I
hope
you'll
go
to
that.
I
don't
know
if
anyone's
got
any
specific
sessions
they
want
to
raise
while
they're.
Here
I
see
we
have
one
listed
in
the
minutes
there
if
anyone's
interested.
B
B
B
Well
got
very
quiet
meeting
today,
then
this
is
going
to
be
very
quick
if
we
don't
think
of
something
soon,.
C
A
All
right
yeah,
so
if
anyone
has
any
topic
just
anything
you
want
to
talk
about
regarding
cns
cloud
native,
we
can
just
add
that
or
look
into
something.
If
you
have
questions
about
something
we
can
put
you
on
the
agenda.
D
Hey
taylor
good
morning
yeah,
I
think,
yeah.
I
wanted
to
check
with
you
on
the
proposal
thing.
I
think
we
had
a
brief
conversation
over
the
email.
Can
you
share
more
details
about
that?
Is
there
any
link
or
something
that
I
can
go
through.
A
Regarding
contributions,
I
think
there's
a
couple
of
topics:
the
con
talk
contributions
to
the
working
group
or
the
blogging.
I
don't
know
we
had
a
couple
of
things
going.
A
D
C
C
A
D
Yes,
so
yeah
so
best
practice
yeah,
I
got
the
topic
so
what
I
am
currently
working
on
right,
I
think,
as
discussed
in
our
previous
meetings,
I
was
basically
working
on
integrating
our
kubernetes
into
cncf
and
also
we
have
a
bunch
of
best
practice
policies
that
that
can,
you
know,
be
used
to.
D
A
All
right,
so
it
might
be
good
to
I
I
guess
for
folks
on
this
call
that
haven't
seen
and
give
a
little
bit
of
background.
So
kyverno
is
a
project
that
can
it's
a
policy.
Can
I
guess,
a
policy
agent
for
kubernetes
and
you
can
set
different
policies,
there's
different.
A
I
guess
projects
out
there
like
opa
and
other
things
that
can
do
it
in
a
different
way
and
kyverno's
one
of
them
and
there's
been
some
interaction
with
caverno
and
the
the
cnf
test,
suite
around
testing
and
checking
things,
and
so,
with
regards
to
the
working
group,
I
think
what
we'd
be
looking
at
is
not
the
test
specifically.
But
what
why
are
you
testing
something
like
what
is
the
best
practice
behind
it
that
that
we
would
want
to
capture
and
tell
people?
You
should
try
to
cover
this,
whether
they
end
up
using
kyverno
or
directly?
A
A
So
there
could
be
many
different
ways
to
test
for
the
use
of
root
users
and
containers
that
a
process
is
being
run
as
root
versus
a
a
non-root
user
or
potentially
a
related
thing
would
be
users
above
uid
1000
and
there's
many
different
ways
that
you
could
test
this
with
different
there's
different
projects
that
try
to
test
this,
including
cubescape,
which
we've
got
ben
on
the
call
from
keepscape
falco.
Does
some
testing
around
that
there's
a
lot
of
different
ways.
A
So
the
best
practice
we're
not
recommending
in
the
working
group
we're
not
recommending
the
use
of
specific
projects
and
that's
up
to
implementation.
It's
the
best
practice
in
general,
so
we'll
say
don't
run
not
your
process
is
root.
Well,
user
may
say
we're
using
this
project
that
does
rootless
containers
or
they
say.
Oh
we've,
we've
refactored
and
broken
things
up
and
we
do
it.
We
handle
it
in
some
other
way.
A
And
I
I
can
stop
there
or
we
can
kind
of
dive
into
process
that
many
of
us
know.
I
guess,
from
the
working
group
side.
A
B
Yeah,
I
mean
I'm
just
looking
at
the
caverno
website
and
list
of
policies
that
it's
got,
which
effectively
says
you
know
these
are
things
you
could
be
doing
to
a
container
as
part
as
it
starts,
and
the
question
would
be
the
open
question
between
those
policies
and
what
we're
talking
here
would
be.
What
is
the
need
for
doing
that
in
the
first
place?
What
helps
with
that?
B
And
you
know
why
does
using
one
of
those
policies
improve
matters?
Why
would
you
want
to
make
it
a
default
of
the
cluster,
so
you've
kind
of
got
to
join
the
dots
between
well,
you
know
we
strongly
recommend
you
do
x
and
the
reason
we
recommend
you
do
x
is
this
reason.
D
F
A
So
this
would
be,
I
mean
it's
literally
labeled
in
your
category
best
practices.
A
So
if
we
said
this
was
a
a
best
practice
that
we
think
the
cnf
working
group
should
promote,
it's
a
recommendation
for
service
projects,
service
providers
to
adopt
and
say
we
want
everyone,
that's
creating
these
and
it's
a
best
practice
for
people
creating
these
networking
applications
to
adopt
when
they're
building
them.
A
So
we're
saying
we
think
you
should
drop
all
capabilities,
then
what
we're
going
to
want
to
do
is
go
through
and
and
communicate
that
so
this
is
kind
of
the
quick
summary
which
would
be
related
to
what
you're,
what
you're
going
for
here
capabilities
right
here.
So
all
of
these
should
be
a
drop,
that's
kind
of
the
summary
and
then
you
go
in
and
talk
about
the
motivation,
here's
our
goals.
So
how
is
this
going
to
help
so
we're
wanting
to
communicate
to
the
end
user?
Why
do
why
are
we
proposing
that?
A
You
drop
all
capabilities,
and
then
you
can
kind
of
go
in
here
and
talk
talk
about
it.
One
of
the
important
areas
is
going
to
be
a
user
story
or
a
use
case.
So
for
the
non-root
there's
a
whole
bunch
of
reasons
to
do
it.
We
have
a
set
of
user
stories
under
this
area
called
supply
chain
attacks.
A
Then,
if,
if
you're
running
non-root,
then
it's
going
to
have
less,
probably
just
by
thinking
about
this,
these
drop
all
capabilities
would
be
able
to
also
reference
that
same
set
of
user
stories,
because
if
you
have,
if
you've
dropped
all
capabilities-
and
you
have
a
supply
chain
attack
of
some
sort,
then
you
they're
going
to
cause
less
damage.
So
potentially
this
whole
section
here
on
non-route
would
be
usable
for
a
best
practice
of
drop-off
capabilities.
B
A
B
The
the
question
that's
coming
up
in
my
mind,
if
you
were
to
use
falco,
is
what
you're
doing
is
effectively
of
changing
default.
Well,
you're
changing
default
behavior
of
kubernetes
in
as
much
as
a
container
that
would
run
on
kubernetes
without
falco
will
not
run
in
the
way.
You
expect
sorry,
not
falco
caverno.
It
will
not
run
in
the
way
you
expect.
B
If
caverno
is
running
right,
if
a
container
requires
capabilities,
then
you
know
thinks
it
requires
capabilities,
expects
capabilities
then
kiverno
will
either
prevent
it
from
running
or
make
it
run
in
a
way
that
it's
not
expecting.
So.
The
question
is:
how
do
we
fold
kind
of
enforced
policy
information
like
this?
That
would
either
modify
or
prevent
a
pod
from
running
with
an
application
that
does
not
expect
that
to
be
working.
D
Yes,
so
basically,
this
policy
red
drop,
all
that's
going
to
initially
drop
all
the
capabilities
and
only
add
the
ones
that
you
need
based
on
your
application
requirements.
That
way,
you
know
the
we
are
explicitly
mentioning
the
capabilities
that
we
only
need,
but
before
that
we
need
to
drop
all
the
capabilities.
B
I
mean
another
example
of
a
similar
thing
that
kivono
seems
to
want
to
offer
is,
for
instance,
preventing
anything
from
accessing
the
host
name
space
which,
to
my
mind,
is
a
very
good
idea,
because
if
I
allow
a
pod
to
access
the
host
namespace,
I'm
basically
giving
it
the
power
to
destroy
the
cluster
or,
alternatively
escalate
its
privilege
in
a
the
sense
of
you
know,
find
out
what
else
is
going
on.
The
cluster
modify
the
cluster
change
the
cluster's
behavior
in
a
way.
B
That
means
that
the
infrastructure
is
not
independent
of
that
application.
It
might
break
because
of
this
application.
So
policies
like
that
potentially
a
good
idea.
However,
if
you
are
going
to
say
that
you
should
use
kiverno
on
every
cluster
to
ensure
this
happens,
or
even
you
know,
kiverno
is
an
option
to
use
on
a
cluster.
Then
it
comes
with
consequences
because
an
application.
May
you
know
there
are
three
actors
here:
there's
the
people
providing
the
infrastructure,
the
people
providing
the
application
and
the
operators.
B
If
the
infrastructure
prevents
things
that
the
application
developers
did
not
expect,
then
you
know
the
the
operator
is
going
to
find
when
they
bring
the
two
things
together.
The
application
doesn't
work,
so
you
might
argue
that
another
way
of
phrasing,
this
would
be
to
say
you
shall
not
use
this
and
then
a
best
practice
would
be
use
caverno
to
enforce
that.
A
Right,
the
kyverno
part
should
be
separated
so
that
there's,
if
you're,
we
can
have
a
suggestion,
a
recommended.
You
should
drop
all
capabilities
and
then
we
we're
checking
for
that
and
as
far
as
someone
that
says,
hey,
we
want
to
have
as
much
as
these
as
possible.
Then
we
could
say:
oh
you
did
great
and
then
for
those
who
say
no,
you
must
it's
required.
A
We
will
not
let
you
similar
to
non-root.
So
on
some
platforms.
They
don't
allow
root.
Sc
linux
platforms.
You
can't
run
as
root,
so
a
service
provider
could
say
no.
We
will
not
allow
it
and
we're
going
to
have
deny
by
default
and
for
those
they
could
require
that.
But
I
would
say
the
requirement
to
drop
all
capabilities
should
could
be.
It
could
be
a
completely
separate
like
requirement
from.
I
guess
it's
a
it's
a
different
decision
to
say
it's
a
must
versus
a
recommended.
B
F
There's
also
another
thing
to
consider
is
as
well
so
the
drop-off
capabilities,
even
if
you
don't
end
up
enforcing
it
and
saying
it's
a
must,
you
are
able
to
to
say
that
if,
if
dropbox
capabilities
fails
as
in
you,
you
decide
that
you
don't
want
to
run
the
dropball
capabilities,
but
you
still
see
that
the
test
itself
that
determines
whether
capabilities
are
present,
fails
then
that
could
trigger
an
audit
and
that
you
can't
that
gives
you
a
an
inventory
of
everything
that
doesn't
meet
your
your
best
practice,
and
you
may
have
exceptions
as
to
why
you
don't
end
up
dropping
all
the
capabilities
and
some
of
those
exceptions
may
never
be
resolved,
but
at
the
very
minimum
it
gives
you
an
ablate
of
where
your
of
where
some
of
your
your
risk
is
at.
F
So
it's
not
just
everything
like
don't
run
it
if
it
doesn't
fail
or
if
it
doesn't
pass,
it
could
be
just
audited
if
it
doesn't
pass.
D
Right,
I
think
so
these
all
these
policies
right,
they
can
be
run
in
two
modes
either
and
force
or
audit
mode.
So
you
can,
let's
say
you
don't
want
to
run
it
against
the
workloads.
You
can
basically
run
it
in
audit
mode.
That
way,
it
will
just
generate
a
policy
report
saying
that
hey
this
particular
resource
violated
this
policy
and
here
are
the
details,
but
that
workload
will
still
be
able
to
run
it
so
that
that
should
not
really
block
you
from
running
your
applications.
A
Yeah,
I
I
I
I
can
we
go
back
to
maybe
start
building
some
potential
ideas
based
on
these,
like
we,
we
put
out
best
practices.
G
Yeah,
I
I
think
that
we
have
to
differentiate
between
best
practices
and
what
is
enforced.
These
are
two
completely
different
things
and
I
asked-
and
I
agree
with
ayan-
that
in
that
that
that
the
that
there
are
there,
we
can
break
applications
but-
and
it's
not
generally
not
a
good
idea
we
have
to,
but
as
a
best
practice,
it
is
a
best
practice
to
drop
out
capabilities.
It
is
it
is.
It
is
the
best
thing
to
do,
but
you
have
application
which
must
have
those
capabilities
so
yeah
either.
B
Yeah,
I
think
all
I
would
say
is
that
what
we're
doing
here
right
now
is
probably
rules
which
are
defined
by
their
exceptions,
so
the
auditing
possibility
here
that
this
is
fishy,
and
you
need
to
understand
why
this
is
happening
is
probably
more
useful
to
us
than
you
ain't
gonna.
Do
this
and
we're
gonna
stop
you.
B
I
would
love
one
day
for
there
to
be
a
platform
where,
in
fact,
you
can't
have
capabilities,
it's
simply
not
possible,
but
the
problem
with
a
platform
like
that
right
now
is
given
there
aren't
very
many
options
for
running
cns,
then
I
don't
think
you
get
to
see
enough
to
run
on
it
because
they're
all
going
to
want
privilege
for
some
reason.
F
Yeah,
the
in
in
general,
when
you
model
trust
in
in
this
area,
because
the
the
entire
goal
of
for
this
type
of
an
auditing
path
is,
is
to
determine.
Do
I
trust
this
thing
and
for
and
how
do
I
trust
it,
and
so
generally
you
want
to.
We
don't
have
enough
information
here
to
be
able
to
tell
what
the
context
is
whether
a
given
thing
should
or
should
not
have
privileges.
F
So
instead
we
have
to
enable
the
operators
to
be
able
to
tell
whether
to
have
the
conversations
as
to
whether
they
should
trust
something
or
not.
The
second
part
of
on
it
is
is
time
based
because
things
change
over
time.
So
how
long
do
I
want
to
trust?
Do
I
want
to
trust
something
for
there's
a
there's,
a
third
aspect
of
trust,
which
is
whether
it's
symmetrical
or
what
trust
is
not
symmetrical,
but
that's
we'll
leave
that
part
out
so
just
based
on
the
first
two.
F
What
generally
from
an
audit
perspective,
what
we
want
to
be
able
to
say
is
this
thing
will
run
and
we'll
give
it
an
exception
for
a
period
of
time.
It's
best
practice
to
re-review
the
the
capabilities
on
a
regular
basis,
so
that
way
that
you
continue
to
understand
your
your
infrastructure
and
you
can
also
make
different
decisions
where
maybe
there's
an
update,
and
you
don't
need
these
privileges
anymore,
then
you
can
drop
them
so
so
I
would
add
a
time-based
component
to
any
to
any
audit
in
this
particular
path.
F
If
or
to
any
exception
to
to
this
path.
H
Well,
the
other
thing
that
I
was
thinking
and
also
is
regarding
what
said,
is
what
are
they
well
taylor
mentioned
about
different
implementations.
Obviously,
if
those
implementation
can
allow
us
to
treat
those
deception
as
as
that
mentioned,
or
that
they
need
to
modify
the
way
to
handle
perceptions,
or
so
I
think
that
we
have
to
be
also
connected
with
the
the
current
implementation
to
talk
about
qr
nonfalco.
A
Or
multi-way
so
between
projects
and
the
working
group
between
projects
and
the
test
suite
which
is
trying
to
test
those
practices,
we
want
to
have
a
two-way
conversation
and
and
improve
the
projects,
as
well
as
improve
the
best
practices
and
the
tests
happening,
and
then,
of
course,
we.
We
also
want
the
same
with
people
creating
cns
or
consuming
them.
The
service
providers.
A
And
I
don't
know
exactly
what
we
would
say
on
that
because
you
could
say
they
run
policy
checks
run
on
every
deployment
policy
checks
run,
but
you
know
what
happens
if
someone
pulls
in
updates
that
on
and
it
doesn't
end
in
line
update.
So
do
you
want
to
check
every
hour?
Do
you
want
to
check
every
day
and
have
alerts,
or
are
you
just
running
a
report
and
sending
a
report
once
a
week?
So
there's
a
lot
of
different
ways
to
do
it
but
seems
like
we
could
potentially
write
something
up.
A
I
don't
even
know
if
this
is
would
become
a
best
practice.
It
might
become
like
more
of
a
just
another
document,
a
white
paper
or
document
that
we
could
so
we
don't
just
have
to
create
we.
We
can
create
these
best
practices
that
we're
doing
like
this.
We
have
user
stories
that
we're
doing.
We
could
also
have
other
documents
where
we
talk
about.
A
G
Taylor,
you
remember,
I
had
two.
I
had
we
discussed
two
shortly
two
ideas
regarding
the
network:
best
practices
around
the
protection
of
the
kubernetes
control
plane.
I.
E
Don't
know
if
we
should
so
discuss
this
here
or
what
are
they?
Let's
just
add
them
in.
G
Yes,
so
they're
working
or.
G
Yes,
so
I
will
try
to
do
it
in
parallel,
but
but
to
you
know,
to
put
you
into
the
discussion,
the
idea
was
well.
We
have
two
basic
network
protection
concepts,
very,
very
basic
production
concepts
around
the
the
control
plane
of
kubernetes.
One
is
the
api
server
protection,
making
sure
that
the
api
server
is
only
answering
authenticated
users
and
doesn't
enable
insecure
port
and
stuff
like
that.
E
What
what
is
the
control
it
did?
There
is
no,
there
is
not
one
yet.
G
Okay,
so,
first
of
all
api
server
protection,
making
sure
that
authent
only
authenticated
users
get
answers
from
the
api
server.
G
This
is
one
thing
which
which
also
in
which
we
all
usually
include
also
the
enforcement
of
of
our
arbuck,
which
we
can
discuss
whether
it
is
really
how
deep
it
is
related
or
not.
But
from
what,
from
our
perspective,
it
is
important
to
enforce
that
the
the
greatest
cluster
uses
our
bug
and
anonymous
user
is,
it
doesn't
have
any
access
rights,
and
the
second
is
actually
is
not
is,
is:
is
removing
public
internet
text
list
from
from
from
api
server?
G
So
you
know
from
the
public
internet.
You
cannot
access
the
api
server
itself.
Whichever
thing
that
this
is
our
two
very
very
basic,
the.
G
Yeah,
so
again,
this
is
in
the
sense
of
telcos.
It
isn't.
I
think
that
it's
less
so
an
issue,
okay,
but
but
still,
I
think
that
this
is
something
as
a
best
practice.
It's
something
that
you
know
should
be
there,
and
it
should
be
clear
to
everyone
and
also
okay.
We
we,
we
suggested
also
to
make
sure
that
every
kubernetes
control
plane
component,
like
you
know,
cubelets
and
and
scheduler,
and
control
manager
and
stuff
like
each
talking
to
each
other
in
tls,
with
with
bilateral
authentication.
G
So,
in
order
to
make
sure
that
this
is,
you
know
the
the
things
which
we
saw,
that
these
are
really
the
the
101
of
of
the
network
security
around
the
kubernetes
components,
and
this
should
be
enforced.
I
will,
I
will
follow
up
and
I
will
add:
okay,
the
controls.
G
We
are
adding
right
now,
also
to
make
sure
that
these
are
covered
in
our
test
kit,
but
this
is
a
as
again.
This
is
the
best
practice
so,
for
example,
public
access
to
to
cover
this
api
server
is
not
necessarily
something
okay
that
can
be
easily
tested.
G
Since
you
know,
how
do
you
prove
that
you
don't
have
public
access?
You
cannot
cover
cover
this.
You
know
100
percent
yeah.
These
were
the
things
which,
which
I
thought
would
be.
You
know
good
things
to
to
best
for
best
practices.
A
All
right,
I
actually
think
that
some
of
those
might
be
related
to
stuff.
We
had
listed
for
least
privilege
yeah
select
api
access-
that's
similar,
it's
not
exact,
but
that's
similar.
So
that's
good
continue
on
that.
A
Security
controls
yeah
feel
like
there
was
something
about
our
back,
I'm
not
seeing
it
now,
but
maybe
it
was
in
the
actual
notes.
A
A
This
would
be
content
that
could
be
pulled
for
something
like
around
our
back.
We
get
there's
a
lot
of
things
on
our
backs,
so
we
can
the
more
specific
we
get
on
something
you
know,
potentially
the
easier
it
is,
but
what
whatever
whatever
it
is,
I
think
we
got
a
lot
of
content
on
our
back,
okay
and
likewise
cigar.
We
have,
I
think,
on
these,
like
drop
all
capabilities.
A
If
I
look
up
these
well
number
one,
we
have
like
exceptions
and
stuff
which
ian
was
talking
about
like
when
what
do
we
do
with
all
the
applications
that
need
it
right
now,
this
no
privilege
or
capabilities
granted.
So
this
is
kind
of
related
to
that.
What
you're
suggesting
it's
pretty
much
the
same,
but
it's
definitely
something
we
thought
would
be
good
and
I
think,
there's
probably
other
content
here
besides
the
supply
chain
attacks.
A
So
if
you
can,
you
probably
take
this
non-root
as
a
a
good
example,
there's
also
literally
like
here's,
here's
the
template
that
anyone
can
use.
That
explains
what
it's
about.
Actually,
here's
the
template-
and
this
says
what's
the
process,
what
do
we
want,
but
here's
a
template
and-
and
this
is
yeah-
I'm
sorry.
D
Oh
sorry,
I
was
saying
if
you
could
share
that
link
for
the
template.
A
Yeah
sure
I'll
just
drop
these
all
in
here
so
example,
or
creating
creating
a
new
best
practice
proposal,
so
example
non-rate.
A
Let
me
grab
that
so
probably
user
story
example
supply
chain
attacks.
A
The
all
of
these
can
be
adjusted
to
as
needed
when
we
created
this.
It
was
without
before
having
an
example.
So
we
have
this
section
user
stories
use
cases
it
can
be
whatever
makes
sense.
The
the
main
point
here
is:
I'm
not
seeing
it
there.
We
go
to
give
context
to
the
end
user.
Okay.
Why
is
this
relevant
this
best
practice
relevancy?
A
But
if,
if
you
are
giving
relevance
in
another
way,
that's
okay,
these
are
just
to
help
guide
us,
but
it's
not
strictly
required.
There's
some
of
the
things
that
we've
marked
as
required
and
if
you
feel
like
it's
not
relevant,
then
come
back
and
same
thing
been
on
anything
that
you
all
come
up
with
here.
It's
not
relevant,
then
just
come
back.
A
A
Yeah
all
right
is.
Is
there
any
other
ideas
for
potential
practices
that
anyone
wants
to
and
it
doesn't
have
to
be?
Some
of
these
are,
I
would
say,
more,
security
oriented,
so
we
don't
have
to
just
do
that,
but
any
any
ideas,
whether
it's
more
security
or
other
stuff,
that
people
want
to
put
forward
and
say
this
would
be
a
really
good
one
for
people.
D
There
was
one
more
which
which
requires
read-only
root
file
system.
I
don't
know
if
that's
already
part
of
the
cncf
specific.
A
Essentially,
I
I
don't
know
on
the
test
suite
side,
there's
a
lot
of
different
things
there,
but
what?
What
is
it
if
we're
talking
about
it
from
a
best
practice,
standpoint.
D
Yeah,
this
policy
ensures
that
you
know
there
is
only
you
only
have
a
read,
only
root
file
system.
A
All
right
yeah
this
is,
I
think,
there's
agreement
between
many
different
projects.
Kyverno
cubescape,
I
think
you'll
have
something
about
read.
Only
falco
has
read
only
there.
So
if
we
have,
you
know
a
lot
of
different
projects
that
are
focused
on
kubernetes
and
cloud
native,
and
everyone
is
saying
you
should
have
you
should
do
this,
then
it's
probably
a
good
indication
that
it's
a
best
practice.
D
I
think
taylor
there
are
others
as
well,
but
let
me
pull
those
one
second.
D
A
Ben,
would
you
add
a
link
under
this
armo
cubescape
area
to
I
think,
he'll
have
a
best
practice
set
yep
and.
A
All
right
so
check
for
deprecated
apis.
A
All
right-
and
I
know
that
there's
several
projects
for
this
too
there's
been
there's
one
project.
That's
actually
used
with
the
sig
testing
for
checking
test
coverage
for
all
kubernetes
apis,
and
it
can
tell
you
whether
it's
alpha
beta
or
production,
I'm
not
sure
if
it
checks
for
deprecated
apis,
but
that's
great
that
kyverno
can
do
that
so
check
for
deprecated
apis.
I
think
that
would
definitely
be
one
from
an
audit
standpoint
for
service
providers.
D
Yeah,
so
so
taylor,
I
think
one
more
thing
was:
I
was
working
on
integrating
those
policies
right.
I
have
made
some
progress
on
that,
especially
you
know,
formatting
the
output,
I
think,
with
the
help
of
akash
and
view
now,
it's
more
formatted,
so
I'll
update
my
policies
accordingly
and
probably
show
like
a
demo
sometime
this
thursday.
Will
that
be
okay.
F
A
Yeah,
that's
why
we're
going
to
keep
it
separate,
best
practice,
drop
capabilities
and
don't
set
your
container
privilege
to
true
don't
use
root.
We
just
keep
piling
them
on
so
the
more
you
use
the
safer
you're
going
to
be
perfect
and
someone
may
decide
to
only
use
a
subset.
That's
fine!
As
long
as
we
can
tell
what
are
you?
What
are
you
doing.
A
F
A
F
D
G
Yeah
I
just
bring
in
the
check
yeah.
The
point
is
to
limit
from
which
image
registry
someone
can
pull
to
the
pods.
A
B
B
F
Yeah
signing
signing
may
not
be
enough
in
some
in
some
use
cases
absolutely,
and
so,
for
example,
I
may
we
may
end
up
with
a
with
a
signed
root
image,
for
let's
say,
like
you,
pick
a
database
and
that
won't
give
a
specific
database
name.
But
let's
say
you
have
like
some
database
that
you
use
and
that
database
are
to
be
compromised
and
an
image
uploaded.
Then
you
start
pulling
from
that
specific
one
rather
than
the
ones
that
you
vet
so
generally.
F
What
ends
up
happening
is
that
there's
additional
scans
that
are
put
onto
the
private
repo
and
the
organization
may
want
to
ensure
that
those
scans
are
performed
before
they
deploy
anything,
so
they
won't
want
to
pull
from
public.
For
for
that
specific
reason,
even
if
they're
not
modifying
the
images
themselves,.
A
Idea
of
having
a
trusted
testing
place
that
signs
after
testing
scanning
and
testing,
but
anyways
we're
getting
into.
How
would
you
design
all
of
this.
A
And
if
you
think
of
something
later,
then
you
can
feel
free
to
come
in
and
add
it
to
the
notes
or
go
into
another
good
place.
To
add
it
later
would
be
put
a
discussion
item
if
it's
related
to
something
here
feel
free
to
add
it
or
just
create
a
new
discussion
area,
and
then
we
could
talk
about
it.
You
know
the
following
week.
If
you
really
think
this
is
a
really
good
one,
we
definitely
should
do
this.
Then
please
go
add
an
issue,
so
we
have.
A
A
You
should
drop
capabilities,
so
go
ahead
and
create
an
issue
that
we
should
propose
as
a
best
practice,
and
then
you
can
start
iterating
on
it
with
a
draft
that
you
can
share
and
we
can
all
work
towards
creating
and
then
we
create
a
pull
request
and
we'll
be
good
to
go
so
with
that
ian.
Why
don't
you
go
ahead
and
open
the
pull
request,
we'll
move
on
we're
nearly
at
the
top
of
the
hour.
B
Oh
review?
The
open
pull
request?
Yes,
okay!
Well,
there
is
in
fact
only
one,
which
is
the
one
that
we've
had
open
for
a
while
to
create
air-gapped
environments.
B
Oh
well,
sorry,
the
the
pull
request
is
called,
create
a
catch
environment,
big
button,
but
yes
to
to
discuss
the
best
practice
of
using
an
air,
gapped
environment
and
the
implications
that
it
has.
B
I
don't
think
there's
much
worth
discussing
on
this
meeting
and
in
any
case
I
don't
think
in
six
minutes
we
would
get
very
far
but-
and
it
looks
like
we've
got
a
few
open
bits
of
commentary
that
haven't
been
addressed
in
the
pull
request
at
this
point
in
time,
but
I
think
I
would
just
simply
suggest
that
people
have
a
read
of
it.
A
So
this
is
user
stories
which
potentially
could
be
referenced
by
any
of
the
best
practices
that
we've
been
talking
about
or
other
best
practices
later.
B
Yeah,
I
mean,
I
think,
what
jeff
I
I'm
not
I'm
just
skimming
this.
I
have
to
admit
I'm
a
bit
lacks
on
this.
I
haven't
done
my
own
review,
but
I'm
just
skimming
this
and
I
think
his
his
storytelling
needs
a
bit
of
work.
But
the
idea
is
that
we
know
in
many,
if
not
all,
service
providers,
that,
when
they're
doing
network
functions
of
whatever
kind
of
software,
they
don't
just
pull
it
from
the
internet
and
they
certainly
don't
pull
it
on
the
internet
from
the
end
device.
B
They
they
basically
distribute
it
within
their
network,
which
is
a
closed
system,
that
they
only
allow
new
software
images
to
enter
under
limited
circumstances,
and
that
was
the
point
that
jeff
was
trying
to
get
across.
B
But
yes,
anyway,
this
one's
open,
it's
up
for
review
as
we
speak,
so
anyone
who's
got
the
time
to
basically
read
through
it
and
see
whether
it
makes
any
sense
to
them.
That
would
be
useful
and
we
again
right
at
the
top
of
the
hour,
give
or
take
so
unless
there's
anything
particularly
urgent,
that
people
want
to
talk
to
talk
about
for
three
minutes,
then
I
think
we
might
be
done
for
the
morning.
A
B
Yeah,
absolutely
don't
feel
that
you
can
propose
a
change
in
github
and
I
strongly
suggest
you
do.
If
you
are
doing
comments,
then
you
know
simply
putting
the
change
you
would
like
to
see
is
often
for
small
changes,
a
lot
easier
than
basically
telling
someone
else
that
they've
got
work
to
do
so
you
know,
do
do
make
sure
you
do
that.
Can
you
demonstrate
taylor
yeah
that
thing
I.
B
A
A
It
makes
it
real
easy
to
for
folks
to
move
along
and
quickly
take
stuff.
That's
been
put
in
there.
We
can
have
fast
iterations
of
changes,
so
please
use
those
and,
if
you're
not
using
them
in
your
own,
then
I
suggest
you
do
so
with
your
pull
request
and
if
you
mess
up,
you
can
always
delete
and
try
again
like
I
just
did
all
right.
I
think
we're
at
the
end,
unless
anyone
that's
muted
needs
something
has
anything
else.