►
From YouTube: CNF WG Meeting 2021-07-19
Description
CNF WG Meeting 2021-07-19
A
A
A
A
A
A
A
A
A
Well,
you
can
add
your
name
to
the
10
ace
whenever,
let's
see
so
other
than
the
upcoming
events
and
the
tag
is
august,
2nd
monday
and
we
have
kubecon
and
o-n-e-s
in
october.
The
cfps
are
closed
for
that.
If
someone
has
something
interesting,
that's
going
to
be
in
one
of
those
if
you've
been
accepted,
then
maybe
we
can
add
that
as
a
list
to
the
list
that
folks
are
recommended
to
see.
A
C
I
can
see
it
okay,
good!
So,
yes,
I've
been
promising
this
for
a
while
and
it's
finally
ready
and
started
to
get
feedback
from
colleagues
and,
of
course
I
would
very
much
appreciate
feedback
from
this
group.
So
it's
a
very
long
document.
It's
as
I
said
it's
a
15
pages
in
length,
not
in
a
format
that
could
immediately
be
usable
within
our
working
group,
but
maybe
parts
of
it
can
be
or
it
could
be
the
starting
point
for
best
practices.
It
is
not
written
as
best
practices.
C
C
So
again
going
into
detail
and
of
course
I
would
be
very
happy
to
hear
feedback
if
there's
all
uses
that
I've
missed
or
uses
that
I
can
go
into
more
detail
or,
of
course
got
wrong.
So
any
of
you
can
comment
on
this,
as
I
noted
in
slack,
so
just
be
aware
that
this
document
is
publicly
globally
viewable
and
commentable.
C
C
C
What
is
called
operators
in
kubernetes
is
actually
has
nothing
specifically
to
do
with
the
operator
pattern
and
even
in
kubernetes
and
in
a
lot
of
presentations.
People
talk
about
the
operator
pattern
in
kubernetes
and
they
usually
top
mean
well
crds,
custom
resource
definitions
and
a
custom
controller
built
around
it.
That
doesn't
necessarily
apply
the
operator
pattern
in
the
classical
sense
in
which
it's
been
used
for
more
than
20
years
right
now,
computationally.
C
So
I
I
go
to
some
length
to
actually
separate
these
two.
Maybe
it's
a
little
bit
pedantic,
but
that's
the
kind
of
person
I
am.
I
feel
like
these
two
things
should
be
understood.
So,
despite
the
terminological
soup,
I
think
we
can
get
through
those
problems
of
names
and
really
most
of
the
document
is
discussing
the
meat
of
the
issue.
So,
yes,
there's
a
lot
here
to
go
over.
C
I'm
not
gonna,
as
I
said,
read
it
all
right
now,
but
I
would
be
happy
and
honored
if
people
in
this
group
would
read
through
it
provide
comments,
you
can
add
comments
directly
into
google
doc
and
oh,
and
I
should
also
mention
I
realize
not.
Everybody
has
access
to
google.
So
just
please
ask
me:
I
can
provide
a
pdf
too,
although
that
will
be
a
snapshot.
This
is
a
living
document.
I'm
constantly
editing
it,
so
I
could
provide
a
pdf
of
a
snapshot
right
now
and
pretty
much
it.
C
B
C
C
I
I
guess
the
conclusion
is
yes.
Operators
are
are
very
important
and
useful,
and
there
are
some
practical
challenges,
numerous
ones
that
I
discuss
briefly
but
they're
probably
worth
going
into
more
detail
on
our
end,
as
I
said
things
like
the
crd
and
what
to
do
with
it
things
having
to
do
with
namespaces,
I
see
ian
already
wrote
a
comment
and
and
we're
gonna
discuss.
The
next
aspect
of
the
agenda
is
the
aspect
of
privileges
and
how?
How
do
we
deal
with
the
containers
that
require
privileges?
C
C
And
yeah.
Well,
the
other
aspect
I
talk
about
is
well
it's
very
hard
to
write
good
operators.
I
leave
it
to
the
end,
but
that's
kind
of
that.
That's
a
big
deal,
I'm
I'm
very
concerned
about
the
quality
of
operators
that
I
see
sometimes
and
there's
really
no
simple
way
around
this
they're
just
complicated
because
of
the
the
way
kubernetes
is
designed
and
yeah.
My
conclusion
is
I
I.
I
strongly
believe
that
this
is
one
of
the
killer
features
of
kubernetes
and
I
would
love
to
see
our
working
group.
C
D
D
Well,
if
you're
doing
that,
you
need
to
sort
of
define
what
you're
providing
and
it
seems
to
me
if
you're
doing
that,
you're
actually
providing
something
a
bit
more
as
a
service.
A
little
more
like
to
take
a
bad
example,
eks
you're,
providing
something
that
delivers
a
service
you're,
not
providing
an
orchestrator
that
will
orchestrate
you
know,
container
images
that
the
the
cnf
you're
not
likely
to
be
providing
something
that
orchestrates
container
images
the
cnf
brings
along
with
it.
D
So
I'm
not
it's
got
a
useful
or
or
it's
there
are
certainly
potential
uses
for
that,
but
we
might
want
to
draw
our
boundaries.
So
the
thing
you
deliver
is
more
testable,
it's
very
hard
to
test
something
that
orchestrates
container
images
that
don't
live
with
it,
but
it's
quite
reasonable
to
deliver
something
where
the
end
result
is.
You
know
a
service,
a
microservice
that
might
form
part
of
the
application,
but
you
can
detail
what
microservice
is
good
for.
C
C
Than
part
of
your
workload,
I
ended
up
breaking
up
that
discussion
into
it's.
It's
woven
through
the
document,
but
you're
making
me
think
right
now
that
it's
worth
highlighting
as
its
own
section,
and
maybe
I'm
not
sure,
I
wonder
if
it's
here's
here's
my
thinking
on
this
is
that
I
I
think
in
to
an
extent
that's
a
practical
consideration,
because
in
the
end,
whether
it's
provided
as
part
of
the
platform,
you
know
who's
providing
it.
C
D
It's
a
part
of
it's
provided
independently
of
the
cnf.
You
can
bring
the
operator
and
the
software
it's
operating
on,
so
ultimately
you're
delivering
it
as
a
service
api
supported
independently
of
the
cnf,
and
then
you
can
bring.
Obviously,
if
you
bring,
it
is
part
cnf,
then
you're
bringing
both
operator
and
the
software
package
together
and
they
come
as
part
of
cnf
and
they
belong
to
that
cnf.
Nowhere,
the
cnf
will
use
it.
Those
are
three
patterns.
D
I
would
personally
discard
the
operator
alone,
one
out
of
hand,
because
I
don't
think
you
can
easily
define
what
an
operator
is
doing.
If
you
don't
describe
what
software
package
you
know
the
container
image
it's
operating
on,
it
doesn't
travel
together.
Because
again
I
don't
think
you
can
test
it,
but
the
other
two.
You
know
we
can
say
well,
if
you're
gonna
do
a
then
you
do
it
like
this.
C
C
If,
if
you
want
to
consider
it
a
problem
or
maybe
a
challenge,
is
that
no
two
distributions
are
equal
and
even
within
the
telco
you
know
they
could
create
clusters
with
a
certain
certain
base
requirements.
So
when,
when
you're
targeting
cnf,
you
have
to
list
well,
what
are
the
requirements
for
the
cnf
and
they
can
be
things
like
sdn,
environment
top
of
the
shelf
switches.
You
know
there's
top
of
the
rack
switches.
C
You
know
there
there's
a
lot
of
requirements
that
go
beyond
just
what
kubernetes
provides
as
a
platform
in
itself
right
there
you
might
need
certain
plug-ins
installed,
so
an
operator
becomes
another
aspect
of
those
those
requirements
and
yeah
yeah.
So
this
word
bleeds
into
exactly.
I
think
the
next
item
on
the
agenda,
which
is
you
know,
privileges
right
privileges,
are
also
a
kind
of
requirement.
D
Matter
of,
if
I'm
going
to-
and
I
I'm
using
air
quotes
here,
if
I'm
going
to
right
size,
the
cloud,
if
I'm
going
to
build
a
cloud
that
will
specifically
run
this
kind
of
network
function
from
this
this
provider,
then
I'm
going
to
have
to
meet
its
requirements
for
the
cloud,
because
there's
not
one
bunch
of
kubernetes
with
one
configuration,
that's
a
separate
topic
to
both
of
them
that
I
would
want
to
say.
Well,
these
are
the
features
I'm
going
to
come
looking
for
and
they
better
be
present,
which
could
include.
D
D
So
I
think
that's
another
one.
We
could
write
and
again
we
cross
the
line
between
simply
describing
your
best
practice
and
standardizing
it,
which
you
might
want
to
do
sort
of
as
a
sideline,
rather
than
with
the
authority
of
the
cnf
working
group.
But
if
we
said
right
with
you're
going
to
provide
a
network
a
cnf,
it's
got
to
come
with
a
manifest
that
details
its
requirements
from
the
cloud
and
it
might
require
operators.
D
C
Right
and-
and
this
is
again
where
I
see
the
the
big
benefit
of
operators,
because
it
lets
you
encapsulate
encapsulate
those
requirements
with
you
know
a
single
item
on
the
list.
You
know
this
is.
I
need
this
operator
now
that
operator
might
itself
have
all
kinds
of
requirements,
but
you're
you're
not
passing
the
buck
here.
You're
really
saying
that
this
is
you
know
another
system
that
you
need,
so
the
cnf
itself
becomes
more
minimal
right.
C
D
Then
the
point
is,
it
would
become.
It
wouldn't
necessarily
become
a
responsibility
of
the
cnf
supporting
ops
team.
It
might
become
a
responsibility
to
be
a
platformer
supporting
ops
team,
at
which
point
privilege
is
less
of
a
problem
because
everything
the
platform,
ops
team
does
implicitly
has
all
privileges
in
the
world
so
that
one
might
solve
itself.
If
we
approached
it
that
way,.
C
C
I
think
we
can
forget
about
ever
having
cnfs
running
on
public
clouds,
at
least
not
the
way
public
clouds
are
currently
designed.
It
ends
up
being
very
custom.
That's
my
point
that
you
have
it's
a
cnf
plus
a
very
tweaked
kubernetes
cluster
that
is
designed
to
work
together
with
hardware
accelerators
other
things
that
sometimes
come
with
their
own
operators
and
the
complete
solution.
You
know
you
have
a
bill
of
materials
for
everything
going
from
the
hardware
to
the
software
and
all
these
parts
are
really
designed
and
certified
to
work
together.
C
So
so,
in
the
end
you
know
making
these
kind
of
clean
separations
between
which
team
works
on
what
I
I
hope
we
can
reach.
That
point
I
mean,
I
think,
that's
something
that
we
would
like
to
see.
Those
are
one
of
the
benefits
of
the
cloud
and
what
it
can
give
us.
We
have
a
ways
to
go
to
that
and
maturity
both
in
the
platform
and
in
our
development
practices,
which
is
part
of
what
this
group,
I
hope,
will
move
forward
right.
Yeah.
D
The
question
there
is
going
to
be:
can
you
for
a
cnf
given
what
it's
got
to
do?
Can
the
whole
group
of
people
involved
supply
a
cnf
with
more
moving
parts
with
less
effort
than
they
can
supply
it
with
fewer
bigger
moving
parts,
even
if
that
includes
a
bit
of
duplication
and
at
least
with
the
level
of
technology
and,
frankly,
people
skills
that
we
have
around
at
the
moment?
I
think
duplication
might
make
life
easier,
but
it's
it's
a
topic
open
for
discussion.
We
shouldn't
block
off
the
option
in
the
future.
C
Right,
I
think
our
attitude
so
far,
which
I
agree
with
very
strongly,
is
that
we
keep
we're
we're
going
with
the
method
of
like.
If
you
want
to
do
this,
then
this
is
your
best
practice.
We
it's
very
hard
for
us
to
state
an
opinion
where
you
you
shouldn't,
do
something
some
things
right.
There
there's
a
reality
out
there
in
terms
of
what
telcos
need,
what
providers
can
provide
and
and
that
relationship
which
you
know
we.
We
can't
change
that
business
relationship.
What
we
can
do
is
look
at.
C
A
D
Thanks
for
that,
yeah
I
mean
so,
let's
start
from
the
beginning.
The
principle
of
least
privilege
is
not
a
use
case
and
it's
not
a
best
practice
either.
It's
it's
a
principle,
but
the
reason
it's
not
a
use
case
is
because
I
need
to
be
doing
it
for
a
reason,
and
it's
not
a
reason.
Just
because
I
say
it's
a
principle,
and
so
I've
got
to
justify
it.
D
The
reason
it's
not
a
best
practice
is
it's
not
measurable,
so
I
can't
say
you
shall
have
least
privilege,
because
you
know,
if
someone's
going
to
say
well.
This
is
the
least
privilege.
It
just
happens
that
I
need
like
root
access
to
the
whole
system
to
get
things
working.
So
so
it's
an
unmeasurable
statement
as
it
comes
so
to
break
it
down
into
use
cases
and
best
practices.
D
D
D
For
instance,
these
are
sort
of
things
that
start
to
look
dangerous
so
from
there
you
end
up
dropping
out
things
like
well.
This
is
a
thing
I
should
not
ever
do
one
other
thing,
because
we're
in
a
real
world
here
not
in
the
the
world
that
we
might
wish
to
be
in,
is
that
we
know
for
well
that
pretty
much
every
cnf
that
exists
in
the
world
is
not
sticking
to
the
principle
of
least
privilege
it.
It
lays
its
hands
on
all
the
privileges
available
to
it.
D
D
Yeah,
they
would
probably
say
this
is
what
I'm
doing,
and
it's
not
compliant
with
all
of
the
best
practices,
and
I
have
an
exception,
and
this
is
the
reason
for
it.
So
you
know
when
they
have
non-compliance,
they
would
want
to
document
why
they've
gotten
on
compliance
and
maybe
what
they're
going
to
do
in
the
future
to
remove
that
non-compliance.
D
So
we
should
be
thinking
in
those
terms
that
we
we
will
build
best
practices.
We
can't
limit
ourselves
to
best
practices
that
everybody
already
does.
We
have
to
come
up
we're
going
to
come
up
with
best
practices
that
people
don't
do
and
so
we're
going
to
have
to
give
them
a
way
of
saying.
Well,
I'm
not
compliant.
This
is
why
I'm
not
compliant.
This
is
how
I'm
going
to
become
compliant.
D
Anyway,
the
the
the
privileges
we
looked
at
and
taylor's
been
kind
of
making
notes
right.
He
basically
said
right.
I
want
my
platform
to
have
integrity
independent
of
the
app
that's
running.
I
want
applications
not
to
be
again.
If
we're
talking
in
the
world
of
vendors,
I
bought
my
applications.
I
don't
want
one
vendor
to
point
to
another
vendor
as
the
reason
why
their
application
is
not
working.
D
D
So
what
was
I
saying?
So
we
went
through
some
of
the
standard
ways
of
using
least
privilege
right.
One
is
again,
as
I
say,
documenting
your
exceptions,
where
you
can't
basically
run
with
zero
privilege,
but
which
you
can
explain
what
you're
doing
that
privilege
that
would
potentially
give
us
ways
of
documenting
you
know
best
practices
if
you're
going
to
use
cabinet
admin.
D
These
are
the
rules
you
must
follow,
and
these
are
how
we
will
check
that
you
are
following
those
rules
as
an
example,
bad
example,
but
it
will
do
when
it
comes
to
a
few
other
things.
I
know
we
discuss
routine
containers.
I
know
tau
has
a
specific
interest
about
rooting
containers
because
openshift
tends
to
deny
you
the
use
of
the
root
user
and
containers.
Theoretically,
the
root
user
in
containers
does
not
endanger
other
applications
or
the
platform
at
all.
So
it's
got
a
slightly
different
use
case.
D
D
Unrestricted
access
to
kubernetes
apis
is
obviously
dangerous.
There
are
kubernetes
applications
apis
that
you
probably
wouldn't
want
an
application
to
access.
We
might
want
to
set
some
rules
around
this.
The
obvious
one,
to
my
mind,
is
when
we
talk
about
cluster
wide
resource
types.
I
think
network
attachments
are
probably
the
most
dangerous
as
an
application.
D
I
don't
have
the
context
of
how
the
cloud
is
connected
to
the
wider
network,
so
I
can't
just
say:
use
vlan
on
this
port
without
really
that
consideration,
and
there
are
certain
vlans
in
certain
ports
that
are
probably
you
know
outside
the
scope
of
what
I'm
allowed
to
do,
and
there
are
certain
attachment
points
that
are
probably
designed
for
other
cns
to
be
using,
which
I
absolutely
shouldn't
be
fiddling
with.
So
we
need
to
figure
out
for
an
application.
D
What
kubernetes
apis
should
it
be
allow
access
to
and
what
shouldn't
it
be
allowed
access
to,
and
what
would
I
want
to
delegate
on
a
case-by-case
basis
like,
for
instance,
again,
access
to
an
existing
network
attachment
so
that
you
can
attach
a
network
function
to?
It
would
be
an
obvious
thing
to
give
to
a
network
function.
You
know,
I
I
want
your
input
to
be
here.
I
want
your
output
to
be
over
there.
D
C
A
quick
question
about
that,
if
I
may,
I
I
feel
like
it's
a
separate
aspect
here.
You
know
you're
we're
talking
about
privileges,
but
also
you're.
Talking
about
rights
and
service
account
our
back
roles.
A
privileged
container
doesn't
have
unrestricted
access
to
kubernetes
apis.
That's
no
unrelated
right.
D
Agree,
but
we're
not
talking
about
containers
with
what
kubernetes
calls
privilege
we're
talking
about
the
privileges
that,
in
general,
that
software
has
which,
among
other
things,
is
access
to
the
kubernetes
api
at
all
and
access
to
our
items
on
it.
So
I
want
to
keep
that
to
the
smallest
set.
That's
meaningful
that
allows
me
to
do
the
job
and
say:
well,
you
shouldn't
be
doing
this,
because
this
is
more
privileged
than
you
absolutely
need.
D
A
C
C
All
right,
because
you
know
root
and
containers,
is
you
know,
a
very
specific
aspect
of
privileged
containers.
There
are
other
alternatives
to
that,
too,
providing
capabilities
for
containers
rather
than
outright
privilege.
You
could
use
linux
capabilities
so
again,
that's
least
privilege
instead
of
going
completely
privileged
instead
of
setting
privilege.
True,
you
can
ask
for
specific
capabilities
and
those.
D
Are
yes
absolutely
so
so
the
privilege
there's
two
parts
to
this?
One
is
the
principle
of
least
privilege
literally
means
you
have
only
the
privilege
required
to
get
your
job
done
and
no
more.
But
again,
the
use
cases
we
might
write
up
here
are
things
like
privileges
that
exceed
a
certain
threshold
that
endanger
the
stability
of
the
platform,
for
instance,
should
not
be
given
to
applications
your
privilege,
you
know
I
could
turn
that
around.
You
only
have
get
privileges.
E
Yeah,
okay
and
the
thing
that
makes
me
a
little
bit
uncomfortable
in
this
particular
path
is:
is
that
the
the
like
I,
the
unders?
The
understanding
in
terms
of
these
privileges
is
that
the
application
says
these
are
my.
These
are
my
minimum
requirements.
So
if
you
end
up
with
a
with
a
pod
that
says,
I
need
capability
net
admin,
the
amount
of
damage
they
could
do
with
that.
Despite
the
fact
it's
not
root,
it's
not
sys.
E
Admin
is
absolutely
immense
and
it's
very
close
to
yeah
very
close
having
root
access
to
to
the
system.
So
that's
so
so
I
think
from
from
a
guidance
perspective
like
we
cannot
say
no,
you
can't
have
this
like
we're,
not
in
the
we're,
not
in
the
space
to
say
where
we're
gonna
block
you
from
having
it,
but
guidelines
would
say
like
if
you
really
need
something
like
cap
net
admin
you
should.
C
Yeah
very
good
point
I'll
add
you
know
if
we
could
make
suggestions
upstream,
it's
a
problem
in
kubernetes,
it's
very,
very
coarse,
it's
kind
of.
If
you
open
the
gate,
you
open
the
gate
for
a
lot
of
things,
even
if
you
want
to
enable
ping
from
a
container
you're
gonna
have
to
have
privileges
that
you
can
create
a
lot
of
damage
with
right.
E
E
These
are
these
are
our
privileges
that
they
look
small
in
the
front,
but
they
actually
have
huge
implications
for
for
an
attacker,
and
that
doesn't
mean
you
don't
need
cap
metal
or
you
shouldn't
have
it,
but
if
you,
but
if
you
do
need
it,
you
want
to
try
to
isolate
that
into
into
a
different
location
like
this
is
my
control
part.
This
is
where
most
of
my
application
exists.
That's
the
dangerous
part
right
there
that
I've
isolated,
so
I
can
better
defend
it.
D
We
can
do
the
same
thing
here.
I
don't
think
it's
possible
to
write,
for
instance,
a
best
practice
of
if
you're
going
to
use
cat
net
admin.
This
is
how
you
use
it.
I
think
it
is
possible
to
write
a
best
practice
is
if
you're
going
to
use,
capnet,
admin
or
sorry,
don't
use
technet
admin
and
then
an
exception
process
that
says
well,
you
get
to
explain
to
the
person
who's
going
to
operate
this.
D
This
network
function.
Why
your
use
of
network
admin
in
this
one
case
is
acceptable
and
not
dangerous,
and
so
on
and
so
forth.
Using
any
of
the
suggestions
that
frederick
was
saying
there
or
any
others
up
to
you,
but
you
know
you
aren't
following
the
best
practice,
but
you're
at
least
explaining
your
reasoning.
C
E
D
E
All
right,
okay,
I'd
like
to
point
out
that
integrity
and
availability
are
straight
up
in
the
security
domain
as
well.
So
if
you
look
at
any
security
literature
on
what
security
is
they
all,
they
always
point
to
the
cia
triad,
which
is
the
confidentiality,
integrity
and
availability,
and
so
these
are
very
cross-cutting
concerns
and
of
course,
you
can
have
integrity
and
availability
with
without
focusing
on
the
security
aspect,
but
in
terms
of
in
terms
of
that
particular
path.
Even
just
looking
at
the
stability
of
the
system
like
how
robust
is
the
system.
C
Right
absolutely
I'll
say
that
just
let's
take
into
account
that
we're
not
discussing
security
in
general.
Here
you
know
where
security
is
a
much
bigger
topic
than
just
this.
It's,
as
you
said,
it's
part
of
the
domain,
but
we're
not
really
dealing
here
with
attacks
right.
Actual
attacks
are
something
we
should
discuss
right,
how
what
are
the
best
best
practices
for
security
and
kubernetes?
That's
a
very,
very
big
topic
and
a
lot
of
companies
are
working
on
outside
of
telco.
A
We're
specifically
talking
about
one
sub
area
of
security
principle,
of
least
privilege,
we're
not
taking
on
all
of
it.
It's
fine
if
they
come
up
in
comments,
and
they
have
like
there's
a
lot
of
other
best
practice
ideas
that
we've
noted
while
working
on
this
one.
But
the
focus
for
this
is
primarily
on
least
privilege.
D
E
Yeah
and
typically
when
you
start
to
get
to
the
largest
organizations,
what
when
they
talk
about
security,
what
they
really
mean
is
risk
is
risk
management
so
and
what?
What
is
the
risk
this
thing
is
is
presenting
to
me?
Is
this
a
risk
that
I
can
accept
based
upon
the
business
requirements,
or
do
I
need
to
do
something
else
like
mitigate
or
eliminate
or
transfer
the
risk
somewhere?
And
so
it's
it's
in
a
code
that
is
acting
up.
E
You
know,
even
if
it's
just
someone
a
developer,
makes
a
mistake
and
accidentally
starts
deleting
databases
like
that
is
seen
as
a
as
part
of
the
security
domain
within
within
many
organizations
or
most
organizations
at
scale,
because
it's
considered
to
be
part
of
that
part
of
that
risk,
and
so
at
the
end.
At
the
end,
I
think
the
security
aspect
does
does
matter
here
and
we
can
tie
this
into
where
we
can
scope
the
the
part.
E
C
C
D
You
know
we
talked
about
fcd
and
we
would
probably
overload
it
if
you
really
put
your
mind
to
it.
You're
absolutely
right
on
the
lobbying
things,
I'm
sure
they're
only
two
of
I'm
sure
we'd
come
to
others
if
we
actually
went
lucky
but
yeah
where
a
resource
is
shared,
but
it's
not
shared
with
any
degree
of
enforcement.
A
C
D
At
least
designed
or
not,
it's
definitely
used
in
the
sense
that
a
single
application
is
running.
So
you
know
if
the
application
breaks
because
kubernetes
is
being
abused,
then
it's
still
the
application
team's
problem,
because
kubernetes
is
a
component
that
they're
supporting,
but
that
isn't
the
world
we're
expecting
to
move
to
here,
because
the
application
and
the
kubernetes
platform
come
from
potentially
two
different
sources.
C
C
D
D
D
It's
the
gamble
that
you
won't
make
so
much
work
for
me
that
I
don't
make
it,
and
in
order
for
that
to
be
true,
then
the
consequences
need
to
be
consequences.
I
brought
upon
myself
by
writing
bad
code
in
the
first
place,
so
I
have
some
control
over
the
amount
of
support
that
you
will
ask
from
me.
If
we're
saying
that,
I
can't
support
platform
without
also
knowing
everything
about
the
way
the
application
is
running
on
it.
Then
I
don't
understand
how
we
can
make
this
ever
work
in
the
service
provider.
So
we.
C
Well,
you
know
we're
not
talking
about
pass.
You
know,
platform
as
a
service
here
we're
talking
about
ownership
of
the
network
right,
you
know,
even
the
the
the
title
here
at
this
point
is
platform
integrity,
but
we're
talking
about
cnf,
best
practice
practices
to
maintain
platform,
integrity,
yeah,
everybody's
responsible
here
you
know
you're
responsible
for
the
end
to
end
of
the
network
so
which
parts
of
the
software
you
call
platform
and
which
aren't
are
you
know
it's
software
that
you're
using
it's
all
integrated.
D
D
But
the
the
thing
is
that
wasn't
true
I
mean,
but
in
an
ideal
world
I
know
who
to
call
it's
one
team
who's
not
living
up
to
the
responsibilities
I
set
for
them,
which
is
why
it's
useful
to
again
it
may
not
be
perfect,
but
it's
useful
to
put
boundaries
between
components.
So
you
can
say
this
is
not
doing
its
job.
It's
your
problem,
you
fix
it
as
soon
as
possible.
D
C
D
D
C
C
Security
is
a
very
important
topic.
I
think
we
need
to
discuss
it
unrelated
to
this
principle
at
all.
There's
a
lot
of
issues
having
to
having
to
do
with
that
they're,
not
necessarily
related
to
what
the
cnf
developer
can
do.
You
know
that
they're
they're
just
problems
or
challenges,
I
would
say,
with
the
technology
itself
well.
D
All
right,
let's,
let's
turn
this
around
the
thing
I
said
to
begin
with-
was
that
principle
of
least
privilege
can't
be
a
use
case,
and
it
can't
be
a
best
practice
by
itself.
So
you
need
a
use
case
that
justifies
the
things
that
the
principle
of
least
privilege
applies.
What
use
case?
Would
you
use.
C
D
Yeah,
but
I
mean
it's
not
necessarily
use
cases
where
you
need
privileges
if
you
need
privileges
and
there
are
no
consequences
to
certain
customers
of
privilege,
because
fine,
you
can
break
the
platform,
but
that's
fine
exactly
then
you
know
that's
a
use
case
where
it
actually
doesn't
matter.
If
you
have
that
privilege,
but
yeah
I
mean
I,
I
don't
want
you
to
answer
this
here,
but
I
want
you
to
go
thinking
about
this.
What
justifies
best
justifies
moving
the
least
privilege
what
makes
it
the
most
advantageous.
C
Well,
I
I
won't
answer
but
I'll,
ask
the
opposite
question.
You
know
that
cases
where
you
do
need
privileges
well,
what
now?
What
now?
Well,
that's
your
least
privilege.
Isn't
it
I
mean
that's
the
point
right
well,
okay
least
privilege,
but
there's
still
privileges
and
they
represent
challenges.
So
so
the
next
step
is
really
thinking
of
okay.
How
what
do
we
do
with
privileges
and
how
do
we
use
those
privileges
responsibly?
And
my
argument
is
that
you
need
to
in
kubernetes.
A
Starting
with
the
lowest
level
that
we
can
agree
on,
that's
the
point.
So
if
you
said
that
you
want
to
limit
the
privileges
when
you
need
it
even
an
app
and
you
could
talk
about
the
single
app
integrity.
So
if,
if
you
have
multiple
containers,
then
maybe
something's
compromised,
but
you
don't
have
the
one
that
needed
the
net
admin
privileges
is
completely
separate.
If
it,
if
you
don't
immediately
get
access,
then
it's
not
going
to
cause
problems
for
the
rest
of
the
that
app.
A
A
E
Yeah
and-
and
I
think
we
should
be
careful
not
to
not
to
propose
or
pretend
that
these
are
our
silver
bullets,
like
the
principle
of
least
privilege,
is
a
principle
that
should
be
followed
for
a
variety
of
reasons,
one
of
which
is
security,
related
things
and
with
the
goal
of
frustrating
the
attacker
and
where
they
gain
access.
They
have
to
take
yet
another
step
to
get
to
to
escalate
or
to
transfer
their
their
access
to
horizontally
to
to
another
location
which
increases
the
risk
to
to
the
attacker.
E
But
it's
it's
not
the
it's,
not
the
only
reason
why
we
want
to
have
least
privileges,
but
it's
it's
something
that
that
is
generally
a
good
principle
to
have,
but
it
needs
to
be
applied
across
across
the
board,
while
also
understanding
that
there
needs
to
be
other
things
put
in
place.
It's
the
reason
why
in
open
shift
environments
that
se
linux
is
recommended
strongly
recommended
to
to
remain
on
that
people
when
they
get
frustrated
with
that
climax?
Is
they
don't
just
say?
E
These
are
what
the
privileges
are,
because
in
that
scenario
it
also
allows
an
administrator
or
and
by
administrating
the
kubernetes
administrator,
but
as
in
like
the
administrative
control
and
leadership
and
apparatus
within
the
company
to
also
work
out
like
well,
what
systems
do
we
need
to
spend
more
time
auditing?
What's
where
do
we
need
to
spend
more
time
looking
where
systems
may
have
may
have
issues
and
things
like
disk,
iops
and
similar?
E
Yes,
they
can
be
negated
through
careful
control,
careful
application
of
eppf,
or
there
are
kernel
parameters
that
can
help
tune
that,
but
it
doesn't
it,
but
you
ultimately
need
to
have
good
observability
somewhere,
like
there's.
No
there's
there's
ways
to
bypass
the
the
kernel
iops,
depending
on
how
it's
configured
where
you
might
have
direct
modes
that
we
tend
to
use.
So
we
have
to
be
very
careful
on
how
on
how
we
on
how
we
approach
these
these
guidelines
to
say:
they're,
not
they're,
not
perfect,.
C
So
let
me
add
to
that
in
building
on
frederick
what
you
mentioned
last
time
and
taylor
just
hinted.
The
principle
is
not
only
least
privileged,
but
it's
also
isolated
privilege
we're
not
just
talking
okay.
So
let's
say
we
have
the
minimum
amount
of
privilege
required
right.
It's
not
going
to
be
zero.
Some
aspect
might
require
privilege.
We
want
that
component
as
separate
as
possible
exactly
to
allow
that
isolation,
single
point
of
failure,
observability
in
one
location,
etc.
So
that
to
me
is
the
fuller
expression
of
what
this
principle
is.
D
D
Use
cases
are
likely
to
be
related
to
it,
so
we
had
to
work
kind
of
we
work
this
problem
in
lots
of
different
ways,
one
of
which
is
what
reducing
privileges
would
template,
would
help
from
actual
use
cases,
and
the
other
is
what
our
typically
applied
principle
of
least
privileged
derived
rules
that
we
see
in
applications,
and
then
we
were
trying
to
join
them
together
in
the
middle.
So
you
know
security
is
not.
D
It
is
clearly
tied
to
principal
release,
privilege
and
it's
a
use
case
right.
Somebody's
invaded
one
bit
of
one
cnf.
What
would
you
want
to
happen
at
that
point?
What
could
you
do
about
that?
You
could
make
sure
that
that
cnf
doesn't
have
the
power
to
break
other
things
in
its
turn.
Definitely
good
use
case.
E
Yeah
and
this
this
breaking
up
a
part
of
things
just
makes
a
lot
of
sense
as
well
like
in
enter
in
enterprise
systems.
You'll
often
see
things
like
policy
will
say:
all
data
address
must
be
encrypted,
they'll
say
the
standard.
Is
we
use
a
yes?
The
procedure
is
we
use
bidlocker
on
windows.
Systems
to
implement
aes
and
guidance
will
be
don't
leave
your
laptop
in
the
car
so
we're
finding
the
right
level
of
what
we
want
to
call
these
things.
It's
like
principle
principle,
obvious
privilege,
looks
like
how
do
we
get
to
procedures.
D
I
I
again
I
I
would
also
make
it
clear
if
it
hasn't
occurred
to
people
that
a
best
practice
isn't
necessarily
driven
by
a
single
use
case
or
user
story
or
whatever
right
security
dictates
that
we
probably
want
to
restrict
privilege.
Stability
dictates
that
we
probably
want
to
restrict
privilege
as
well
so,
but
the
best
practices
of
how
we
restrict
privilege
is
one
thing:
the
reasons
why
we
do
it
is
another,
and
there
could
be
many
perfectly
fine
to
have
that
right.
D
Anyway,
we'll
keep
going
with
this,
we
do
rather
hope
to
have
a
few
kind
of
outputs
in
terms
of
both
user
stories,
use
cases
and
best
practices.
This
week
we
will
try,
based
on
prior
experience,
to
make
sure
that
these
commits
probably
live
in
a
branch
of
their
own,
but
are
independent
of
each
other,
so
that
we
can
commit
the
ones
that
people
like
and
continue
to
discuss
the
ones
that
people
have
issues
with.
D
Otherwise
we
get
into
a
log
jam
where
we've
got
lots
of
ideas,
but
we
can't
get
any
of
them
into
into
our
documentation,
but
we
will
keep
going
with
this
and
your
feedback's
welcome
by
the
way,
this
actually
helps
a
great
deal.
Thank
you
for
your
comment
about
auditing
victor.
I
I
think
we
do
have
to
weave
that
in
somehow
I'm
not
quite
sure
how
yet,
but
but
it's
a
perfectly
valid
thing
to.
D
A
Back
to
you
sounds
good
and
we're
out
of
time
for
anything
else.
At
the
top
of
the
hour
the
pull
request.
We
still
have
some
open,
including
the
glossary
I
haven't,
checked.
If
tal.
If
you've
gone
through
and
responded
to
some,
I
think
you
were
going
to
accept
some
and
had
some
comments,
but
if
folks
can
take
a
look
at
that,
the
other
pull
request
is
the
use
case
for
onboarding
cnfs
to
platform,
and
vuc
is
going
to
be
out
for
the
next
couple
of
weeks.
A
But
if
I
think
most
of
the
stuff
was
pretty
agreeable,
but
if
we
can
get
some
plus
ones
on
this,
then
we
can
get
it
merged
potentially
before
he's
back,
unless
there's
anything
that
we
want
to
update
so
check
those
two
use:
two
pull
requests
out:
the
onboarding
cns
and
the
glossary
from
tel
thanks.
Everyone
see
you
next.