►
From YouTube: CNCF CNF WG Meeting - 2021-02-15
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
Where
they
were
actually
trying
to
put
data
center,
like
many
data
centers
in
everyone's
homes,
to
heat
the
homes
and
then
so,
the
heat
isn't
wasted.
It's
used
to
heat
the
home
and
then,
like
you,
have
like
a
data
center,
and
so
you
get
free
heating
and
you
get
paid
to
host
a
data
center
or
something
like
that.
It's
an
interesting
concept,
yeah.
A
A
Okay,
it's
five
after
now,
so
it's
also
president's
day,
so
I'm
assuming
some
people
aren't
joining
it
in
ottawa
or
in
canada.
It's
like
ottawa
day
or
something
so
canadians
are
also
on
vacation.
So
I
think
we
can
probably
get
started
yeah.
So
once
again,
the
link
to
the
meeting
minutes
is
in
the
chat.
B
B
Okay,
so
I
haven't,
I
haven't
written
down
the
use
case
yet,
but
I
have
a
second
use
case
to
add,
for
which
it
said
next
to
eden's,
bgp
and
I'd
like
to
have
a
short
discussion
on
it
and
if
people
like
the
idea,
then
I'm
happy
to
write
down
the
actual
use
case
and
put
together
a
document
on
it.
A
Okay,
I
think
we
can
probably
jump
in
yeah,
so
the
first
one
is
a
merge,
pull
request
from
claudio
at
equinox,
so
just
adding
equinox
to
the
interested
parties.
I'm
just
using
this
as
a
reminder
that
if
you
are
contributing,
if
you're
interested
in
this
just
go
ahead
and
add
your
company
as
an
interested
company,
so
then
we
can
kind
of
show
who's
interested
in
this
and
show
kind
of,
like
the
value
of
the
work
that
we're
doing
here.
A
It's,
I
think,
pretty
straightforward.
There's
nothing
crazy
in
here
it's
just
kind
of
guiding
new
contributors
where
they
can
get
involved,
and
obviously
I
think
this
can
kind
of
be
fleshed
out
in
the
future,
as
we
define
more
what
each
of
the
work
streams
do.
But
I
think
this
is
a
good
first
framework.
This
is
not,
I
don't
think
it's
anything
controversial.
We
have
a
a
couple
like
approvals.
Does
anybody
have
any
strong,
any
strong
opposition
to
me
merging
this.
A
Okay,
hearing
none
all
merged
this
and
I
guess
we
closed
another
issue
now
so
sweet
yeah,
so
there's
now
a
contributing
document.
So
if
anybody
that
you
meet
is
interested
in
contributing
that
you
can
point
them
to
this
document
and
they
can
figure
out
where
to
jump
in
from
there.
A
Okay,
the
next
one
is
this
pull
request
from
watson's.
This
came
up
on
the
call
two
weeks
ago
and
the
change
is
basically
to
remove
the
optional
from
the
user
stories,
because
this
is
going
to
be,
I
think,
a
big
part
of
what
we
do
and
also
changing
it
to
trade-off
caveats
and
notes
and
then
just
doing
that
down
below
too
so
this
has
been
open
for
a
week
now
it
has
four
approvals
unless
there's
any
opposition
on
this
right
now
I'll
also
merge
this
one
too.
C
Yeah,
it
literally
reads
the
mark
down
and
says:
are
the
links
right
and
it
runs
as
a
github
action,
so
it
should
run
on
pull
requests.
It
does
seem
to
have
checked
itself
when
I
committed
it.
So
I
think
it's
working.
I
make
no
promises
that
it's
not
that
it's
flawless,
but
on
the
other
hand,
it's
still
better
than
nothing,
so
I
would
say
commit
it
now
and
we
can
always
fix
it.
A
Yeah
cool:
does
anybody
have
any
strong
opposition
to
committing
it.
A
Okay,
the
next
one
is
book
on
the
call.
A
I
don't
see
him
because
he
volunteered
last
week
to
create
a
template
for
the
user
stories.
I
wanted
to
see
if
he
had
an
update
on
that,
but
since
he's
on
my
call
since
he's
not
on
the
call,
I
guess
we
can
wait
one
more
week.
I
am
having
a
call
with
him
tomorrow
actually
to
discuss
with
erickson
if
they
would
be
interested
in
contributing
like
one
of
their
cnfs
to
be
tested
so
I'll
follow
up
with
him.
Then
the
next
one
is
we're
still
looking
for.
A
A
A
A
We
can
also
leave
it
open
for
right
now.
This
is
just
something
that
needs
to
happen
at
some
point
so
that
we
can
have
similar
terminology
we're
not
talking
about
different
things,
but
it's
okay.
If
we
don't
have
anybody
for
right
now,
the
next
one,
so
the
next
ones
are
ian
with
your
two
best
practices.
I
guess
is
there
anything
you
want
to
like
discuss
about
either
the
the
bgp
or
the
use
of
privilege?
Maybe
we
can
start
the
discussion
there,
which
one
do
you
want
to
start
with.
C
So
the
use
of
privilege
once
is
an
issue
for
a
reason
it
wants
justifying,
rather
than
just
throwing
in
as
as
a
surprise
to
people,
because,
arguably
using
privilege
in
any
application,
whether
or
not
it's
a
cnf
is
a
bad
idea,
but
on
the
other
hand
everybody
does
it.
So
we
know
full
well,
there's
a
reason
for
that.
So
you
can't
claim
that
it's
just
a
universal
best
practice
that
applies
to
everybody,
even
though
we
think
it's
a
really
good
idea.
C
So
I
need
to
create
a
user
story
that
basically
says:
if
you
didn't
have
privilege,
then
this
thing
you
want
to
do
would
not
be
possible
and
therefore
we
should
not
have
privilege-
and
I'm
fairly
sure.
I
know
where
I'm
going
with
that
I'll
have
a
go
at
it
later
today
and
try
and
write
something
up.
B
Yeah,
my
my
recommendation
would
be
to
also
try
to
push
it
towards
the
multi-tenancy
shared
shared
use
case,
where
you're
running
in
a
container
versus
running
in
a
vm.
It's
clear
vms
would
give
you
that,
at
the
cost
of
of
density,
which
they're
looking
for
which
case
a
lot
of
the
benefits
people
are
searching
for
out
of
kubernetes,
not
all
of
them,
but
some
of
the
benefits
end
up
being
reduced
and
in
value.
So
I
I
would.
I
would
drive
the
multi-tenancy
story
pretty
pretty
hard
in
that
one.
C
Yeah,
I
I
think,
that's
a
fair
statement.
We
have
to
recognize
and
I
don't
know
that
it's
written
well.
It
certainly
isn't
written
down
in
the
bgp
user
story.
Since
that's
the.
C
It's
not
written
down,
but
we
have
to
recognize
that
our
use
cases,
multiple
applications
on
one
platform,
and
that
is
an
outlier
compared
to
what
people
normally
do.
And
if
that's
the
case,
then
that's
where
the
use
of
privilege
would
become
problematic.
So,
yes,
absolutely
understood.
A
Yeah-
and
I
guess
maybe
this
is
an
interesting
point
from
michael
peterson
from
intel-
is
like
how
would
this
change,
or
these
cases
you're
going
to
write
up
when
using
like
containers
or
something
similar.
C
E
And-
and
I
think
I
I
agree-
I
just
added
it
there,
as
kind
of
I
think
it
was
mentioned
in
the
discussion
earlier,
but
it's
to
the
point
where
anything
you
kind
of
want
to
use
privilege,
for
you
want
to
use
it
on
the
I
guess
underlying
system,
regardless
and
and
running
it
in
cata
containers.
You
won't
really
be
able
to
get
the
functionality
you
might
be
looking
for
anyways.
B
Fair
yeah,
like
kind
of
containers,
you
tend
to
have
two
primary
paths:
either
it
uses
something
like
I
think,
kvm,
which
you
don't
get
the
density
on
in
the
same
degree
or
you
go
with
the
firecracker
approach,
in
which
case
firecracker,
you
cannot
use
any
pinned
memory
in
your
system,
which
means
no
devices
or
somewhere
that
you
can
drop
in,
which
is
nice
if
you're
doing
a
a
simple
web
application,
but
it
may
invalidate
properties
that
were
that
we're
looking
for
for
density,
so
cata
containers
can
help
in
some
of
these
areas,
but
it's
but
it's
it's
definitely
a
trade-off
and
there's
also
issues
when
you
start
to
do
shared
memory
as
to
how
do
you
actually
get
shared
memory?
B
How
do
you
actually
get
the
those
support?
Those
inodes
in
and
out
of
the
system
is,
is
sometimes
problem
problematic.
There
still
not
an
intractable
problem,
but
certainly
one
that
we
would
need
to
look
into.
E
Yeah-
and
I
guess
it
kind
of
also-
I
guess-
removes
the
idea
of
having
a
generic
cnf
in
any
way
since,
since
you
might
be
able
to
run
it
in
cata
containers
and
it
might
not
crash
immediately.
But
then,
if
you
try
to
run
it
on
a
system
where
it's
operating
directly
on
the
host
system,
then
all
of
a
sudden,
you
probably
won't
be
allowed
to
even
run
the
thing.
B
C
Which
is
certainly
possible,
but
yeah.
Can
we
start
a
discussion
on
that,
because
it
seems
what
we're
saying
is
that
there
are
reasons
why
you
might
have
a
legitimate
reason
to
choose
the
runtime,
and
it
would
be
absolutely
excellent
if
that
weren't
true,
because
you
know
in
theory,
if
we're
a
if
we
have
an
application
and
it
runs
in
containers,
then
yeah
the
runtime
shouldn't
concern
us.
B
Yeah
and
as
an
aside,
I
do
expect
other
types
of
containers
to
eventually
pop
in
as
well
so
event.
I've
heard
multiple
parties
talk
about
things
like
webassembly
as
an
example
of
something
that
can
be
encapsulated
and
injected
in
in
interesting
locations
and
yeah.
So.
C
Yeah,
so
I
mean
you,
you
can
do
two
things
that
I
think
work
against
each
other,
because
I
can
always
obviously
run
web
assembly
in
a
runtime,
that's
built
into
the
container
and
similarly,
on
a
suitable
platform,
I
ought
to
be
able
to
run
a
virtual
machine
inside
a
container,
not
a
virtual
machine,
to
run
the
container.
So
there
are
questions
about
whether
for
any
of
these,
it
makes
sense
for
them
to
be
infrastructure.
C
B
Absolutely-
and
it
comes
down
to,
I
think,
a
lot
of
it
comes
down
to
how
do
you
want
to
orchestrate
this
stuff
like?
Presumably,
if
I
have
a
privileged
pod,
I
could
run.
I
could
probably
run
firecracker
and
now
that
I'm
thinking
about
it
or
her
or
something
else
and
just
make
the
guarantee
that
I'm
not
going
to
do
anything
beyond.
C
That
particular
that
affects
all
the
yeah,
the
step
from
there
is
to
ask
yourself
if
you
had
an
unprivileged
pod,
what
would
it
take
to
run
firecracker,
for
instance,
we're
trying
to
find
the
balancing
act
between
a
platform?
C
That's
not
too
complicated,
because
more
complexity
means
more
likely
that
it's
broken
and
lets
you
earn
one
that
lets
you
do
everything
you
might
want
to
do,
and
I
don't
know
you
know
so
we'll
get
there
eventually,
but
you
know,
building
applications
that
run
in
you
know
the
16
possible
run
times
may
not
be
the
answer
or
on
the.
On
the
other
hand,
it
may
be
that,
if
you've
defined
what
a
runtime
does
clearly
enough,
then
yeah
absolutely
it
should
work
and
we
shouldn't
stand
in
the
way
of
it,
but
we're
not
there.
C
B
We
can
always
draw
a
line
and
say
this
is
in
scope,
and
this
is
not.
Somebody
can
solve
this
problem.
But
that's
not.
Our
purpose
like,
like,
I
think,
it'd,
be
easy
to
say.
If
you're,
if
you're,
managing
your
own
runtime
and
your
own
application
in
there
like
webassembly
in
a
I'm
in
an
unprivileged,
pod
and
you're
handling
the
webassembly
side,
then
it's
clearly
something
that's
application
driven
and
you
can
bring
your
own
things
to
manage
it.
B
C
Yeah,
exactly
and
and
the
trade-off
there
is
you
know,
more
features
is
great
in
theory,
but
also
more
features,
there's
more
complexity
in
a
more
fragile
platform
and
we're
not
expecting
one
person
to
implement
this
platform.
So
every
platform
has
to
be
compliant
and
you
may
be
asking
too
much.
So
that's
why
I
say
we
need
a
discussion
on
this.
It's
not
going
to
solve
itself
without
actually
having
a
conversation.
F
F
To
say
you
know,
don't
use
privilege,
but.
C
F
That's
also
true,
but
the
the
real
point
is:
what
are
you
trying
to
do
with
privilege,
you're,
probably
trying
to
access
some
sort
of
hardware?
So
if
the
platform
doesn't
enable
that,
then
privilege
might
be
your
way
around
it
right?
You
know
if
you're,
if
you're,
building
a
box,
that's
a
complete
infrastructure,
plus
a
cnf
package
right
and.
B
The
the
pattern
we
want
to
try
to
encourage,
though,
is
because
like
we're
talking
about
like
kubernetes
native
type
stuff,
as
opposed
to
just
what's
for
us
generic
cloud
cloud
native
approach
and
the
recommendation
I
would
push
in
that
scenario,
would
be
to
have
something
act
as
an
intermediary
such
as
device
plug-in,
is
a
great
example,
because,
ultimately,
it's
about
the
making
the
the
systems
in
such
a
way
that
you
don't
have
side
effects
in
a
way
that
you
that
you
can
affect
others,
because
I,
if
and
that's,
and
that's
ultimately,
what
we're
I
think,
we're
trying
to
drive
down
towards
us,
too,
is
to
minimize
side
effects
of
to
two
other
systems,
and
second,
is
so
that
we
have.
B
We
have
a
clear
path
towards
things
that
need
to
be
orchestrated,
like
hardware
get
orchestrated
get
initialized
and
that
the
minimum
set
of
privileges
necessary
to
operate
that
piece
of
hardware.
So,
in
other
words
you
don't
it's
sort
of
like
a
really
good
example
of
this
is
with
dpdk,
and
the
assumptions
made
around
dbdk
around
the
assumptions
made
around
kubernetes,
like
the
kubernetes,
makes
the
assumption
that
infrastructure
is
immutable.
It
doesn't
mean
it's
hard
immutable.
It
means
that
kubernetes
owns
it.
B
In
the
two
process
models
or
the
two
guess,
you
say
privilege
models
and
that
needs
to
be
reconciled
before
you
could
start
to
effectively
pair
something
like
like
kubernetes
and
dpdk
and
get
it
to
scale
up
across
multiple
groups,
multiple
containers
of
tenants
and
so
on,
and
so
like
these
are.
These
are
the
type
of
of
questions
that
I
think
we
we
need
to
pare
down
to
is
it's
not
about
the
privileges?
B
It's
about
the
side
effects
that
come
with
the
privileges
that
and
how
you
can
impact
others
not
only
from
a
security
perspective
but
from
a
but
from
an
uptime
and
performance
perspective.
F
Right,
I
I
think
that's
well
put,
and
this
is
exactly
what
I'm
hoping
to
achieve
with
the
networking
orchestration
task
force
right.
The
the
idea
is
that,
if
you
can
orchestrate
these
things,
then
you
don't
have
to
use
privileges
or
other
hacks
right
we're.
We
basically
don't
want
you
to
hack
kubernetes.
F
We
want
you
to
use
the
cloud
native
concepts
but,
as
I
said,
it's
somewhat
aspirational,
because
the
platform
itself
is
just
not
good
enough
yet
right
if
you're
using
multis.
F
Well,
you
know
you're
injecting
cni
configurations
right
at
the
level
of
a
kubernetes
resource
it
works,
but
we
we
want
to
reach
solutions
that
are
truly
portable
and
truly
isolatable
right
workloads
that
you
could
deploy
potentially
anywhere.
That
has
some
sort
of
minimum
aspect
to
that
platform.
Right
we're
not
there
yet.
So.
This
is
why
I
feel
like
this
is
somewhat
aspirational.
E
F
C
So,
firstly,
the
people
who
use
privilege
are
cnf
developers
which
are
again
I'll,
keep
saying
this,
not
necessarily
the
best
representative
audience
in
the
public
because
they
tend
to
get
shut
in
the
room
to
write
cnfs
and
you
know
gay
basically
gets
his
whip
out
and
cracks
it
over
the
people
who
work
for
nokia-
and
you
know
I
gently-
persuade
people
who
work
for
cisco
and
so
on,
but
you
know
the
other
part
of
this
is
that
they're
deeply
market
driven,
so
they
will
take
any
path
that
gets
their
code
to
market,
so
it
can
be
sold
and
it
tends
to
mean
that
what
they're
doing
is
taking
pragmatic
solutions
rather
than
necessarily
saying
well.
C
If
we
change
kubernetes
like
this,
then
we
could
do
that.
It
isn't
that
you
can't
do
this
necessarily
it's
that
nobody
is
nobody's
really
taken
the
time
to
explore
what
you
could
do
here.
So
I
don't
want
us
to
throw
it
out,
because
pragmatism
says
it
can't
be
done.
I
want
us
to
at
least
give
it
serious
consideration.
What
would
it
take.
C
B
That
they've
made
a
conscious
decision
as
to
why
they've
broken
out
of
it
and
not
just
made
a
a
decision
just
because
it
was
necessarily
expedient,
even
though
that
will
still
happen,
but
to
give
to
give
them
something
very
quick
and
easy
to
digest
that
they
that
they
can
have
some
sense
of
what
the
consequences
are
and
even
if
they
decide
to
exercise
a
workaround
and
not
follow
the
best
practice,
then
knowing
those
they
can
at
least
try
to
do
things
to
mitigate
the
issues
that
that
that
are
present
there
as
well,
and
some
of
these
could
be
best
practices
that
are
prone
to
the
operator
side.
B
Like
best
practices,
don't
use
privileges
when
you
use
privileges.
The
best
practice
is
to
then
isolate
those
those
workloads
into
a
separate
part
of
your.
If
your
infrastructure,
through
maybe
a
node
pool
or
something
similar,
so
that
if
they
get
broken,
you
don't
compromise
the
systems
that
were
following
best
practices
and.
F
I
wonder
if
we're
we
should
also
state
why
we're.
F
F
C
That
that
was-
and
there
are,
there
are
other
things
than
privilege.
Actually
rooting
a
container
is
not
the
same
as
privilege,
which
is
another
one
you
might
throw
in
there,
but
yeah.
I
mean
the
whole
point
about
not
using
privilege.
I
think
the
strongest
argument
for
it
is.
If
you
want
your
cnfs,
not
to
be
able
to
break
the
platform
or
other
cnfs,
then
they
can't
use
privilege
because
privilege
is
literally
unscoped.
C
C
You
can
write
the
best
practice
precisely
as
you
shall
not
use
privilege,
because
if
you
do
use
privilege
these
are
the
things
that
will
happen
and
then,
if
somebody
decides
well,
I
don't
like
that
best
practice
and
I
won't
insist
on
it.
Then
they
know
what
they're
buying
into.
C
Not
security,
I
would
argue
there
are
things
which
are
purely
security,
for
instance,
not
running
route
in
a
container
is
it's
an
application
choice
and
it
does
get
you
better
security,
because
somebody
can't
go
tampering
with
the
the
parts
of
your
container
image
that
are
not
that
are
not
intended
to
be
tampered
with.
Like
actual
you
know,
pieces
of
software,
for
instance,
so
saying
no
root
in
a
container.
Gets
you
something
that's
purely
security.
E
F
Right,
it's
like
installing
an
app
on
your
phone
and
it
it
tries
to
explain
why
it's
asking
for
access
to
your
contacts.
C
There's
a
that
becomes
a
bit
of
a
meta
here,
which
is
if
we
list
100
best
practices
and
some
party
in
this
only
wants
to
subscribe
to
95.
Then
how
do
they
say?
That's
what
they're
doing
you
know?
Wouldn't
you
want
a
report
from
them
saying
these
are
the
95
we
subscribed
to,
and
here
are
the
five
exceptions
and,
assuming
you
know,
it's
a
cnf
vendor
trying
to
sell
something
or
a
telco
design
team
trying
to
persuade
ops
that
they
aren't
basically
making
their
job
impossible.
C
Then
aren't
you
looking
for
yeah?
We
subscribe
to
this
set
of
best
practices
and
we
have
these
exceptions
and
we
have
these
reasons
for
doing
it,
and
this
is
how
you
work
around
it,
because
you've
got
to
make
you've
got
to
persuade
somebody.
It's
not
like
these
best
practices
are.
Firstly,
it's
not
like
they're,
all
or
nothing,
but
you're
not
doing
them,
because
they're
written
down
as
best
practices
you're
doing
them,
because
they
are
actually
a
good
idea.
C
So
if
you're
about
to
you,
know
document
what
you're
doing
you
have
to
come
up
with
reasons
for
the
exceptions
I
can
see,
nikolai
has
been
the
good
citizen.
D
I
just
want
to
want
to
add
some
some
like
slightly
different
perspective
and
point
of
view,
so
I'm
obviously
not
directly
involved
with
cnf
development,
but
I
might
my
current
employment
is
an
affiliation
is
with
like
the
higher
level
of
the
stacks
where
we
live
in
the
happy
world
of
tcp
sockets.
So
once
I
have
a
tcp
socket,
that's
all
I
need
and
I
can
do
whatever
I
I
want
to
do
to
do
my
job
effectively,
but
still
I
need
a
privilege
during
my
init
phase.
D
D
C
So
nikolai
that
that's
actually
quite
interesting
when
you
say
you
need
your
ip
tables
set
up
what
I
mean,
what
application
you're
running
that
starts
playing
with
ip
tables,
because
that
would
generally
be
considered
to
be
overstepping
the
boundaries
of
what's
civil.
D
C
This
istio.
B
Rather
than
part
of
the
application,
it's
it's
not
envoy
as
well.
It's
it's
the
stuff
around
envoy,
the
actual
like
istio
and
linker
d.
Humboldt
doesn't
care,
so
this
is
just
to
be.
D
One
I
just
just
a
slight
addition.
One
way
to
avoid
this
is
actually
there
is
the
cni
layer
where
you
can
either
use
the
instruction
or
we
have
our
own
cni,
where
actually
you
delegate
this
setting
of
ip
tables
to
the
cni
chaining
mechanism,
which
is
actually
running
in
a
privileged
mode.
So
you
can
do
these
things
there
and
you
don't
need
previous
edges
for
your
init
container.
That
will
settle
the
iptells.
F
I
I
think
this
is
a
really
good
point.
As
I
said
we,
this
is
a
rabbit
hole
but
an
important
one.
I
do
want
to
present
yet
another
scenario.
You
know
we're
talking
about
cnfs,
but
there's
a
way
to
move
the
privilege
requirement
elsewhere.
F
For
example,
you
have
a
kubernetes
operator
that
manages
a
piece
of
hardware,
say
fpga
accelerator
or
something
that's
in
the
system
so,
rather
than
the
cnf
requiring
the
privileges
privilege
to
do
modifications
it
could
potentially
update
a
crd
or
call
an
api,
and
a
different
component
would
be
the
one
that
requires
that
privilege
to
access
that
hardware.
F
So
it's
passing
the
book
in
a
way
right,
but
but
then
you
can
say
well
if,
if
the
cnfs,
if
we
want
cns
not
to
use
privilege,
one
strategy
could
be
to
centralize
that
the
solution
that
requires
privilege
to
a
component
that
is
more
manageable
and
more
secure
or
etc.
F
So
you
still
get
isolation
and
portability,
though,
might
be
more
of
a
challenge
right,
because
if
you
need
to
deploy
that
operator
for
that
hardware
well,
that
operator
would
require
the
the
privilege.
So
it's
passing
the
buck,
but
it's
it's.
F
I
would
say
it
still
could
be
a
best
practice
right,
because
it's
a
suggestion.
How
do
you
solve
the
problem
of
privilege?
You
know
more
holistically.
B
Yeah
and
that's,
and
that's
one
of
the
first
steps
that
we
took
with
network
service
mesh
and
we
actually
presented
the
same
thing
in
the
in
the
istio
community
shortly
afterwards.
B
Was
this
this
exact
pattern,
because
it's
a
very
effective
one,
you
it's
it's
about:
shifting
the
control
away
from
the
client
or
the
or
the
application
to
shifting
that
control
to
something
that
can
be
that's
part
of
the
orchestrator
or
designed
to
work
with
the
orchestrator
and
gives
you
that
that
level
of
control
over
it,
so
that
you
can
ask
for
something,
but
it
doesn't
mean
that
you're
going
to
gain
the
actual
privilege
to
do
it
in
the
same
way
that
the
kernel
will
do
things
upon
on
your
behalf
or
kubernetes
will
do
things
on
your
behalf,
but
you're
not
guaranteed
to
those.
B
If,
like
you,
you
have
to
go
through
it
through
the
orchestrator
itself.
So
it's
a
it's.
I
think
it's
probably
the
most
effective
pattern
in
kubernetes
that
we're
going
to
find
that
that
that
walks.
That
particular
balance
at
this
point,
because
it's
clear
that
there's
significant
limitations
in
in
cni
by
itself,
you
need
something
to
help.
It
or
it's
clear
that
that
device
plug-in
by
itself
doesn't
have
the
right
set
of
properties
there
based
upon
how
it
was
designed.
B
So
you
do
need
something
there,
whether
whether
it's
nsm
or
an
operator
or
nsm,
creating
an
operator
that
then
or
working
with
an
operator
or
similar.
All
these
part,
like
these
type
of
patterns,
are,
are
definitely
very
valuable
in
this
particular
space
for
the
limitations.
C
Think
I
want
you
to
think
in
terms
of
linux
for
a
second,
I
can
always
do
one
of
two
things.
I
can
write
something
as
an
application
or
I
can
embed
it
in
the
kernel.
C
C
If
you
want
to
run
a
process,
it
should
run
as
you
with
no
privilege
whatsoever,
not
start
tampering
with
low-level
system
components,
and
I
think
this
has
got
strong
parallel
with
that.
If
you
are
effectively
a
thing
that
needs
privilege
is
a
thing
that
the
platform
provider
should
deal
with,
not
a
thing
that
the
application
should
bring
along.
Ideally,.
F
Well,
we
can
ignore.
You
know
the
application
aspects
too.
Right,
kubernetes
offers
a
very
basic
rbac
security
right
service,
accounts,
etc,
but
your
application
might
need
something
probably
will
need
something,
much
more
elaborate
authentication
and
authorization,
its
own
user
system,
other
kinds
of
privileges
right,
you
know,
if
you
think
of
some
operator
running
and
doing
something
well,
not
every
pod
running
should
be
able
to
to
just
connect
and
use
it
right.
This.
D
C
C
C
F
F
C
F
B
Yeah,
there's
there's
also
a
whole
set
of
work
going
around
with
trying
to
to
work
out
these
particular
types
of
of
questions
in
a
more
in
in
ways
that
also
don't
necessarily
bind
you
to
the
cluster
itself,
because
all
of
these
authentication
authorization
are
very
cluster
centric
and
when
you're
trying
to
manage
a
fleet
of
systems,
then
they
certainly
help
because
they
do
give
you
some
level
of
granularity
there,
but
they
don't
give
you
the
capability
to
manage
these
things
cross-cutting.
B
When
you
start
talking
about
user
authentication
or
policies
between
systems
that
you're
trying
to
connect
to
each
other,
then
this
is
a
whole
layer
of
stuff,
above
that
that
needs
to
be
that
needs
to
be
handled,
and
there's
groups
like
in
the
ieee
as
an
example,
I
can
point
to
for
for
looking
at
these
exact
type
of
questions
for
network
slicing
for
edge
automation,
because
they're
they're,
very
relevant
kubernetes
gives
them
a
lot
of
fantastic
things.
But
but
it's
it's
similar
to
a
linux
box.
F
Yeah
there's
an
issue
of
roles
here
too
right,
you
think
of
the
system
admin
whoever
installed
the
cluster,
it's
kind
of
like
installing
an
operating
system
right.
So
if
users
need
a
specific
package
installed
well,
only
root
can
install
those
specific
packages.
Perhaps
so,
if
you
install
an
operator,
that's
part
of
setting
up
the
cluster
right
onboarding
the
cluster
itself,
the
cloud,
but
then
the
workloads
are,
we
think
of
it
in
terms
of
what
users
put
later.
But
a
cnf
developer
could
argue.
F
Well,
you
know
they
have
certain
requirements
for
the
cnf
running,
so
they
need
during
installation
of
the
cluster,
for
example,
to
install
certain
operators
that
are
required
for
the
for
the
cnf
to
run.
So
these
roles
sometimes
blend
right.
A
cnf
provider
can
think
of
themselves
as
as
we're
admins
right,
we're
installing
something
very
low
level
in
the
system
right,
it's
not
just
a
a
workload
like
installing
a
database
or
installing
a
web
app
server.
F
These
roles
just
are
hard,
I
think,
to
map
so
cleanly
on
kubernetes,
at
least
as
kubernetes
is
designed
right
now.
It
would
be
interesting,
for
example,
if
kubernetes
would
allow
you
to
create
a
custom
resource.
Well,
there
are
actually
right
cluster
roles
that
you
can
provide
service
accounts.
That
would
let
them
install
an
operator.
B
So
I'm
happy
to
put
together
patterns
that
we
use
and
we
can
show
them
how
these,
how
that's
handled
in
this
particular
scenario,
in
a
way
that,
in
order
to
help
drive
some
of
those
conversations
or
some
of
those
and
some
of
those
patterns,
and
ultimately
we
in
the
nsm
side
we
don't
really
the
data
plane
portions
is,
is
an
implementation
detail,
so
we
don't
really
care
if
it
turns
into
something.
That's
that's
multi-driven
or
you
drop
in
an
operator
or
something
similar.
B
It's
it's
primarily
about
ensuring
that
that
it's
not
the
the
application
itself.
Having
that
those
privileged
bits-
and
if
I
recall,
I
believe
privilege-
is
set
across
the
entire
pod.
So
it's
it's
not
like
an,
but
it's
it's
it's.
I
believe
it's
an
all
or
nothing
I'll
double
check
that
to
see
if
the
pod
specs
have
changed
in
the
past
few
few
versions,
but
basically
the
pod
has
privileges
or
it
doesn't
have
privileges.
B
And
if
the
pod
has
privileges,
then
not
only
does
your
admit
have
privileges,
but
so
does
your
main
workload
as
well,
and
so
there's
getting
that
particular
getting
that
particular
thing
sliced
off
so
that
you
don't
have
to
run
privilege
in
your
main
workload.
F
B
And
so,
if
you
have
privileges,
then,
if
that
system
is
compromised,
you
may
have
an
r
back
put
on
you,
but
something
that's
collocated
with
you
may
have
a
different
or
different
service
account,
but
a
different
system
that
is
connected,
that
is
on
the
same
system,
may
have
a
different
service
account
and
then
it's
it
has
access
to
everything.
At
that
point
it
is,
it
is
effectively
root
on
those
systems.
F
So
this
is
why
I'm
leaning
towards
you
know
I'm
feeling
uncomfortable
about
this
guideline
and
as
a
best
practice.
I
think
that
the
best
practice-
it's
not
a
black
and
white
issue
of
don't
use
privileged
containers,
it's
rather
minimize
and
isolate
the
use
of
privilege
if
it's
through
our
backs
and
making
sure
that
only
a
specific
service
account
can
do
it
in
a
specific,
namespace
or
otherwise
limited.
So
if
you
do
need
privilege
for
some
reason
find
a
way
to
manage
it
in
a
way,
that's
not
black
and
white.
B
Right
and
that's
the
reason
for
for
separating
the
privileged
part
out,
you
still
need
privileges,
but
you
give
control
to
something:
that's
orchestrated
not
by
the
application
but
by
the
by
the
operator,
so
the
operator
can
make
the
decision.
Am
I
going
to
allow
you
to
have
this
effect
on
my
system
and
isn't
the
application
request
for
it,
but
it's
not
the
application
of
that
school
control
and
can
push
that
forward,
and
so
it
prevents
it
from
affecting
other
systems
and
simultaneously.
B
If
the
system
is
compromised,
it
can
request
for
other
things,
but
it's
not
going
to
get
it.
It
has
to
compromise
something
else
as
a
next
step,
so
it
has
layers
of
security
at
that
point.
So
that's
why
the
privileged
separation?
You
still
have
privileges,
something
has
to
have
privileges.
You
can't
get
around
it,
but
you
don't
have
to
it's.
You
don't
have
to
have
that
privileged
thing
present,
while
you're
on
your
primary,
your
primary
workload.
Best
practice
would
be
to
do
the
privileged
thing
in
in
some
in
some
other
sectioned
off
portion.
F
Right,
that's
one
strategy
right.
I
think
there
could
be
others
as
well
that
that
you
know
it's
a
complex
strategy.
B
Yeah
yeah,
I
I
believe
this
deal
was
heading
in
that
same
direction
as
well
like
if
they,
if
they
haven't
implemented
it
that's
the
same
path.
They
were
heading
because
they're
running
into
the
same
problems
and
the
other
another
approach
could
be
to
try
to
get
an
init
container
that
has
privileges
attached
to
it
and
then
to
be
able
to
drop
privileges
from
from
there.
And
I
I
don't
know
if
kubernetes
does
at
this
point
if
it
does,
and
that
certainly
is
fantastic
and
helpful
and
that'll
work
during
the
initialization
time.
B
C
So
the
the
question
there
is
less
about
you
know,
technologically
what
options
have
we
got
but
more
who's
responsible
for
that
code?
Right
if
it
is,
if
I'm
you
know
tasked
with
holding
a
platform
together,
that
runs
a
bunch
of
applications
and
any
one
of
the
application.
Coders
can
basically
break
the
platform
by
doing
things
that
I
actually
let
them
do.
C
Then
I'm
not
building
a
stable
platform
and
building
a
platform
that
is,
you
know,
actually
deeply
fragile
and
problematic,
whereas
if
they
need
to
do
something
that
requires
privilege-
and
I
offer
them
a
way
of
doing
that-
that's
safe,
then
we're
golden,
because
they
can
only
use
paths
to
privilege
that
I
audit
and
check
right.
So
they
need
an
init
container
that
does
something
dubious
in
their
ip
tables.
C
F
Another
strategy
right,
in
addition
to
the
kind
of
putting
it
in
an
operator,
so
if
it's
something
that
can
only
needs
to
happen
once
that's
great
you've,
minimized
and
isolated
it
right.
C
C
Yeah
I
I'm
trying
to
I
mean
we're
up
and
down
the
stack
here.
There's
there's
use
cases,
user
stories
and
requirements
and
design
right
the
use
cases,
the
user
stories
dictate
what
we're
trying
to
do
the
requirements
we
we
pull
out
of
that
the
design
of
which
there
may
be
many
may
be
a
good
designer,
a
bad
design.
You
know
we
have
both
of
those
in
the
world
tries
to
say
how
we
would
do
that,
and
then
we
derive
best
practices
from
that.
C
We're
init
containers
with
privilege
with
mutating
ndis
controller
is
very
emphatically
a
design
choice,
but
on
the
other
hand,
it
does
say
that
you
know
well,
there's
two
things:
regardless
of
whether
we
can
think
of
a
design
using
current
tools,
it
doesn't
necessarily
make
the
user
story
invalid.
It
just
means
that
it's
kind
of
difficult,
the
other
one
is.
You
know
we
do
have
design
tools
here,
lots
of
them.
C
There
might
be
a
number
of
ways
we
might
think
of,
but
we
still
need
to
say
why
we
want
to
do
this
before
we
can
start
down
that
path.
Yeah
and.
B
And
part
of
it
as
well
is,
if
part
of
it
is,
how
do
you
build
and
manage
these
systems,
but
there's
there's
also
another
side
of
as
well,
which
comes
down
to
to
a
risk
profile.
So
imagine
you're
the
operator
of
a
particular
system,
like
you,
you
put
controls
in
in
order
to
prevent
certain
types
of
things
from
from
occurring.
One
of
those
controls
is
you
by
policy
say
default,
deny
access
for
privileges.
If
everyone
is
asking
for
privileges,
then
that
makes
it
very
difficult
to
use
that
as
a
as
a
control.
D
B
No,
it's
it's
about
giving
the
creating
a
balance
about
having
the
application
developers
have
a
path
towards
how
do
I
get
my
system
in
with
less
friction,
because
if
they're
going
to
go
to
every
system-
and
they
have
to
argue
why
you
have
to
have
privileges
in
every
system,
you
may
just
go
through
the
extra
work
of
cutting
those
parts
out
so
that
it's
much
easier
for
me
to
argue
this
initial,
this
emit
pod
or
this
this
went
off
workload
pod
or
this
operator
has
access
to
it.
B
Not
the
main
workload
is
a
much
easier
thing
to
push
then
install
this
thing.
It
requires
root
very,
very
different
set
of
communications
that
need
to
happen
in
those
two
and
so
so
think
of
it
not
only
from
the
application.
What
do
I
need
to
do
to
get
my
application
out,
but
also
think
of
it
from
the
operator
side
like
I
have
to
manage
a
fleet
of
potentially
tens
of
thousands
or
hundreds
of
thousands
of
these
systems?
B
A
Cool,
so
I
think
this
is
a
great
discussion.
I
think
I'm
going
to
pause
it
here,
because
we
do
have
about
six
minutes
left
this
frederick.
Do
you
want
to
just
talk
about
your
use
case?
In
the
time
we
have
remaining.
B
B
We
have
a
good
set
of
use
cases
such
as
the
one
that
ian
is
discussing
with
egp
enterprise
vpn,
but
we
also
need
something
that
we
can
that
we
can
also
compare
and
look
at
our
systems
on
from
something
that's
very
simple
like
it
could
be
something
like
a
bump
in
the
bump
in
the
wire
firewall
as
an
example,
something
that
we
asked
the
question:
if
we,
if
we
run
this
particular
if
we
build
towards
this
bigger
path
like
are,
we
handling
a
complex
use
case
which
could
be
which
could
be
a
a
private,
private,
5g
or
carrier
grade
vpn
or
whatever,
and
then
are
we
handling
the
the
simple
use
cases
and
we're
not
and
we're
making
these
simple
use
cases?
B
How
much
are
we
complicating
the
simple
use?
Cases
is
really
the
question,
so
I
I
think
a
bump
in
the
wire
firewall
would
be
a
good
example
of
a
simple
thing
that
could
be
that
representative,
but
I
also-
but
I
also
would
like
for
if,
if
anyone
would
like
to
to
also
think
of
what
other
type
of
very
simple
things
we
can
do,
that
are
not
telecom
focused,
but
it's
something
that
is
useful
also
in
the
enterprise
space,
because
I
think
part
of
our
ambition
should
not
just
be.
B
How
can
we
enable
telecom
part
of
our
ambition
should
be?
How
can
we
enable
enterprise
to
enter
into
the
space
and
make
use
of
these
things
and
and
ideally
best
case
scenarios?
We
get
a
unification
of
both
enterprise
and
telecom
apis
and
tools,
not,
of
course
the
workloads
will
be
different,
but
but
if
we
can
manage
to
maintain
some
coherency
at
that
level,
then
there's
significant
benefits
down
the
line
for
for
both
communities.
A
B
Correct
and
and
then
we
have
one
up
front
so
that
as
we're
building
these
things
out,
where
we
can,
we
have
something
to
benchmark
that.
We
can
ask
the
question
like
okay
are:
are
we
over
complicating
the
simple
things
as
well
or
in
best
case
scenarios?
We
find
simple
patterns
that
work
across
both
and,
and
you
know,
we're
having
that
thing.
B
A
B
A
Okay
cool,
so
we
do
have
two
minutes
left,
so
I
just
want
to
give
a
short
update
also
on
the
self
nomination
taylor,
and
I
were
going
to
be
working
on
that
like
right
after
this
meeting
like
to
send
the
email
out,
but
obviously
he's
out
of
power.
So
I'm
not
sure
if
it's
gonna
come
out
either
today
or
tomorrow
same
thing
with
the
voting
pr.
So
that's
it's
still
in
progress.
It
just
got
delayed
because
of
natural
disasters.
A
So
yes,
I
guess
that's
all
I
have
for
today.
Does
anybody
else
have
anything
they
want
to
bring
up
or
discuss
in
the
two
minutes
we
have
remaining.
F
So
if,
if
frederick
is
mentioning
a
press
releases
at
red
hat,
we've
just
had
a
reorganization
internally,
we
now
have
something
called
ecosystem
engineering,
which
is
where
I
belong
to
right
now.
So
telco
and
red
hat
is
becoming
more
organized
and
internally
coordinated.
F
B
Sorry
my
mine
was
mine
was
a
an
acquisition,
an
acquisition,
so
my
company
is
being
acquired
and
then
followed
by
shortly
afterwards
by
that
company,
possibly
a
liquidity
event.
So
it's
that's
what
I
was
saying.
It's
been
crazy
like
like
these
are
seriously
like
one,
not
one
time,
company
events
that
are
occurring
so
yeah.
It's,
I
feel,
like
I'm
living
in
silicon
valley,.
A
A
It
here,
first,
okay,
okay,
fair
enough,
so
we'll
look
forward
to
it
in
future
meetings,
then
so
with
that
we're
at
the
top
of
the
hour.
So
thanks
everyone
for
coming
today,
look
out
for
the
voting
pr
and
the
self
nominations
email
to
be
coming
out
as
soon
as
the
weather
cooperates.
So
thanks.
Everyone
for
joining
today.