►
From YouTube: CNCF CNF WG Meeting - 2023-02-13
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
A
A
A
Okay,
then
sucks
sometimes
I
enjoying
here.
No
that's
about
five
after
I
drop,
the
mating
notes
and
you
have
any
agenda
items,
the
Russian
name.
A
All
right,
so
the
coupon
Amsterdam
schedule
is
live.
I.
Don't
know,
check
that
out.
There's
a
lot
of
events
going
on
the
cloud
native
Telco
day,
cfps
close
this
past
Sunday
and
if
you
got
your
cfpn
and
your
picked
as
a
speaker,
then
you're
going
to
get
a
all
conflicts
pass.
So
that'll
include
all
the
the
kubecon
and
everything.
C
So
are
the
nginx
side,
I
think
might
be
I
know
they're
going
to
have
a
booth
there
at
kubecon,
I'm,
not
sure
if
they're
speaking.
C
A
I
did
not
know
that
nginx
emerged
or
whatever
was
F5.
C
Yeah,
a
five
acquired,
nginx
I
think
2018
2019
somewhere
around
there.
So
yes,
the
nginx
is
part
of
F5.
C
I
think
Gus
has
moved
on,
but
a
lot
of
the
core
developers
are
still
there.
A
All
right,
it's
an
interesting
project.
The
way
it's
built
and
embedded.
A
A
Well,
we
were
thinking
that
we
would
have
I,
guess.
I
can
add
it
down
here.
A
Cnf
CNF
working
group
informal
birds
of
a
feather
session
at
coupon,
so
this
wouldn't
be
a
schedule.
It
would
be
more
of
we're,
gonna
find
an
area
and
a
table
whatever
just
sit
down
and
have
a
session.
Maybe
even
have
you
know
if
anyone
wants
to
present
or
talk
about
something
for
a
short
again,
birds
of
a
feather
just
real
short
foreign.
C
Yeah
I
think
so
I'm
trying
to
get
the
I
think
we're
having
a
conversation
this
week
about
potential
sponsorship,
and
so
just
in
addition
to
nginx
but
also
F5
as
well,
and
so
once
I
hear
back
from
that
I'll
I'll,
let
you
know
who's
going
to
be
there
from
the
FI
side.
A
A
Okay,
I'd
like
to
hear
from
y'all
like
what
would
be
something
that
isn't
you
know
important
or
motivates
F5.
That
would
be
maybe
something
the
working
group
and
then
the
broader
talk
on
it.
Cncf
initiatives
would
look
good
and
this
can
be
talked
about
for
kubecon,
but
if
there's
something
to
go
in
there,
one
thing
that
I've
been
looking
at
with
Victor
Morales
and
some
other
effects
that
we
like
what's
happening
with
nephio
the
whole
onboarding
of
cnfs
and
potentially
some
best
practices
that
can
come
into
this
working
group
and
go
other
places.
A
C
Yeah
I
think
nephew
is
definitely
I
mean
we're.
We
sit
on
the
technical,
where
we
have
one
person
on
the
technical
steering
committee
of
nephew
and
so
that
that
I
think
the
the
intersection
between
you
know
this,
this
CNF
working
group
and
what
they're
proposing
there
would
be
of
interest.
A
C
Silva
Silva,
sorry,
Sylvia,
Silva,
that's
correct
and
so
I
think
that's
it's!
You
know,
it'd
be
interesting
as
well.
I
think
that's
kind
of
European
lead,
but
I
still
think
what
they're
trying
to
do
is
is
Define
a
standard
way
of
building
a
kind
of
a
Telco
Cloud
environment,
and
you
know
running
cnfs
on
it
and
so
I
think
understanding
that
intersection
there
is
is
also
interesting
for
us.
We're
not
part
of
Silva
right
now,
but
we
are
definitely
looking
and
keeping
an
eye
on
it.
A
We're
definitely
interested
in
Silva
and
we've
talked
to
us
some
folks
there.
Some
of
them
went
to
the
elephants
one
Summit
this
past
year
and
we
met
up
with
some
of
those
folks.
A
C
C
A
Yeah
I
mean
there's
I,
I,
guess
figuring
out.
What
are
the
differences
that
have
people
if
I
think
of
like
open
source?
One
is
someone
Fork
and
it
can
be
politics
course
that
conveying
someone's
just
interested
in
understanding
or
maybe
there's
features
missing
and
what
you're
building
so
there's
something
that
the
folks
said.
So
that's
Linux,
Foundation
Europe,
but
we're
Silva's
homed
and
you
know
there's
something
that
they're
wanting
that
wasn't
happening.
A
It
seems
from
the
other
projects
and
I
know
that
there's
a
lot
of
you
know,
there's
quite
a
few
groups
that
are
involved
in
that
Vodafone
is
a
CSP
that
has
at
least
a
portion
of
you
know
when
he's
when
you
say
anything
about
a
large
work.
A
There's
always
lots
of
different
groups
within
the
Orcs,
but
part
of
Vodafone
is
involved
in
help
kick
off
Silva,
so
yeah
definitely
shouldn't
collaborating
and
whether
we,
our
Upstream
project,
feeding
stuff
into
those
which
is
fine
because
we're
providing
for
lots
of
different
areas
and
I
think
that's.
Okay,
I
think
open
source.
You
can
do
that
and
then,
where
we
can
learn
and
pull
stuff
in,
because
it
would
be
good
for
feeding
stuff
directly
into
the
the
CNC
of
Telecom
as
well
as
any
project.
A
C
B
C
And
maybe
just
I'll
throw
out
one
other
thing
is
something
that
we
started
to
look
at
from
an
F5
perspective
is:
are
you
familiar
with
the
Gateway
API
working
group
out
of
the
Sig
networking
foreign.
C
C
You
know
there's
different
protocols
that
Telco
support
that
that
you
know
the
standard.
Kubernetes
networking
doesn't
support
natively
and
it
looks
like
there
was
there's
good
work
being
done
out
of
the
Gateway
API
to
you,
know,
kind
of
enhance
or
have
a
standard
way
of
you
know
configuring
and
defining
the
objects
related
to
kubernetes
networking.
That's
what
the
Gateway
API
is
about,
and
they've
been
a
lot
very
focused
on
Ingress.
C
One
of
the
things
that
were
looking
to
do
is
help
also
Define,
some
of
the
the
egress
kubernetes
egress,
networking
and
I.
Think
I,
don't
know
if
you
met
Phil
at
kubecon,
North
America,
but
Phil
Clancy
who's,
one
of
our
product
managers.
C
He
wrote
a
document
and
kind
of
presented
that
to
the
Gateway
API
working
group
last
week.
Talking
about
some
of
the
egress
networking
I
can
share
that
with
you
or
point
you
to
that,
because
I
think
it's
up
on
Google
Docs,
if
you're
interested.
A
Yes
sounds
great:
can
you
drop
a
link
in
this
section
here.
A
Do
you
know
if
those
objects
that
they're
looking
at
adding
is
related
to
the
multi-network
working
group
efforts
to
add
more
support
for
expand
the
network
objects
that
are
supported
there
beyond
the
single
interface.
A
I
mean
it
seems
like
if
I
mean
it
there,
I
know
that
it's
could
be
independent,
but
it
seems
like
right.
It
probably
is
and
should
be
designed
to
work
independently,
so
that
you
can
take
advantage
of
each
like
that,
but
building
them
together
seems
like
you
could
have
more
complex
and
advanced
implementations
that
are
using
the
these
kubernetes
objects
and
make
it
all
Native.
C
I
mean
so
some
of
the
things
that
we've
done
around
kubernetes
networking.
You
know
we
use,
you,
know,
custom
crds
or
you
know,
defining
that
networking
and
it
looks
like
the
Gateway
API
Group
are
kind
of
more
standardizing
that
than
using
using
apis
to
define
the
networking
objects,
and
so
that's
we'd,
like
the
idea
of
having
a
more
of
a
standard
way
of
doing
that.
Instead
of
you
know,
people
building
crds,
and
so
that's
why
we
got
involved
so.
A
A
multi-network
side
seems
like
it
would
be
consuming
the
different
these
different
type
of
connections
that
could
happen
to
those
objects
with
the
whole
multi
on
the
on
the
actual
pods
having
if
you're
going
to
have
multiple
interfaces
should
have
just
spent
on
the
flat
network.
If
you
need
that,
but
you're
wanting
to
set
up
the
connections
from
something
that's
standardized
in
the
community,
instead
of
building
the
custom
crds,
so
you
have
used
it
the
Gateway,
these
new
objects,
and
then
you
have
multiple
interface
objects
that
are
set
up.
A
C
Yeah
Ingress
is
well
supported.
You
know,
there's
like
I,
think
HTTP
object,
there's
TCP,
you
know
I
think
they
have
some
other
protocols
and
in
the
beta
version
for
Ingress,
but
egress
is
really
hasn't
been
looked
at.
I
think
it
was
interesting
when,
when
Bill
presented
this
last
week
at
the
working
group,
there
seemed
to
be
a
lot
of
interest
or
not
a
lot,
but
there
was
definitely
interesting
from
people
in
the
working
group
of
wanting
to
look
at
the
egress
side.
B
A
Side
as
far
as
new
ones
go,
I
think
we
may
have
talked
about
this
during
the
call.
So
this
is
just
some
cleanup
that
needs
to
happen.
A
A
On
a
best
practice
that
I'll
get
to
here
in
a
minute,
we
were
thinking
the
term
lease
privilege,
and
maybe
some
of
the
security
items
should
move
into
the
cncf
glossary
or
be
added
so
put
this
here.
A
We
already
have
a
whole
document
on
least
privilege,
so
we
could
definitely
reference
that
this
one
is
just
one
length,
but
we
have
a
whole
Google
doc
with
a
lot
of
content,
but
we
keep
referencing
the
least
privilege
and
different
security
best
practices,
so
that
could
be
good.
It's
not
there.
Yet
it
seems
you've
done
and
I'll
open
this
here,
A
second,
so
to
get
we'd
like
to
get
more
best
practices
published
into
the
working
group.
A
Ideally
we'll
have
this,
you
know
filled
out
with
a
lot
of
different
best
practices.
You
can
go
and
click
and
read
about
each,
and
we
can
point
people
to
this
document
like
it's
a
starting
Place.
Here's
where
you
can
go
some
of
the
wording
and
scope
of
how
we
talk
about
the
group
they
need
to
change,
but
the
the
point
has
always
been
having
similar.
A
A
Victor
Morales,
Simpson
and
I
were
working
on
this
best
practice.
So
it's
a
draft.
We
have
a
link
here,
we're
wanting
to
get
some
feedback
and
would
like
to
get
this
into
the
GitHub
and
and
we're
going
to
start
working
on
some
other
ones,
but
we
already
have
a
best
practice
about
not
running
across
not
running
processes
as
the
uid
0
or
privileges
or
root
in
containers,
and
this
is
kind
of
related.
A
A
So
it's
simply
we're
saying
best
practice,
don't
run
your
containers
as
privileged
so
that,
yes,
they
have
a
bug,
they're
compromised,
for
whatever
reason
they
will
have
less
likely
access
to
any
host
resources
and.
A
So
this
is
specifically
about
the
privilege,
flag
being
except
false
and
then
go
into
Wyatt's
problematic
and
linking
to
other
areas
to
talk
about
that
a
little
bit.
A
So
this
is
non-system
POD
types,
so
Cube,
cubelet
and
there's
other
system
pots
that
are
going
to
have
their
running
privilege.
We're
we're
talking
about
a
best
practice
for
most
pause.
We
must
CNS
on
the
pods
and
containers
should
run
non-privileged
and
to
give
more
context.
A
A
That
has
it's
well,
someone
may
I'll
say
product,
so
you
may
have
a
product
or
a
larger
project
that
has
a
lot
of
different
sub
pots,
and
yours
may
not
have
privilege
set
to
true,
but
you
need
to
make
sure
in
chapter
that
are
the
other
ones.
If
it's
unexpected
and
of
course
some
of
them
may
need
to
be
running
privileges,
so
the
system
pods
will
be
an
example,
but
also
stuff
like
side,
cars
and
stuff.
So
communicating.
A
And
then
there's
a
related
item
about
raising
privileges,
so
there's
different
things
that
can
happen
where
a
pod
could
actually
go
from
unprivileged
privileged.
Well,
those
are
some
things
we
probably
need
to
address
somewhere,
maybe
in
a
different
best
practice
or
something
or
a
write-up
that
we
that
we
reference
that
that's
something
to
keep
in
mind.
And
then
we
have
a
lot
of
references
here,
including
all
the
discussions
that
we've
done
the
least
privileged
document.
A
We
probably
need
to
publish
in
in
the
docs
section
or
somewhere,
since
it
has
a
whole
lot
of
content
and
then
just
links
to
where
a
lot
of
folks
have
talked
about.
Essentially
this
best
practice
and
then
some
Alternatives
right
now
we
just
have
a
pretty
simple.
Far
back
after
five
fine
grain
policy
management.
A
And
the
other
part
would
be
if,
if
we're
talking
about
a
best
practice,
is
it
something
that
we
think
we
can
test?
Or
is
it
just
a
concept
and
an
idea,
so
this
particular
best
practice
we
know
is
testable.
We
can
actually
look
and
see.
A
We
can
do
static
analysis
and
say:
do
the
definitions
have
the
privilege
flag
set
to
true
or
false.
We
can
also
look
at
the
running
containers
and
the
Manifest
via
the
kubernetes
API,
so
this
one's
testable,
which
means,
if
you're
a
developer
and
wanting
to
check
you're
building
a
product
and
have
a
part
of
your
Ci
or
you're
a
operator
and
do
an
onboarding
for
a
CNF.
You
could
test
this
and
any
questions
or
comments.
A
Hooray
well,
y'all
can
share
this
with
folks
who
would
like
to
get
any
feedback.
Add
stuff,
modify
whatever
we'll
get
a
pull
request
in
and
then
try
to
get
it
published
soon,
working
on
some
other
things,
and
we
do
have
in
mind
to
have
some
best
practices
on
the
onboarding
side
and
looking
at
highlighting
best
practices
that
we
think
and
should
be
adopted
more
commonly,
or
maybe
already
are,
that
the
nephio
group
is
doing
so
rich.
If
y'all
have
insight
into
any
best
practices
there.