►
From YouTube: CNF WG Meeting 2021-07-26
Description
CNF WG Meeting 2021-07-26
A
B
B
A
A
B
B
B
B
B
That
should
be
pretty
reasonable
to
have
agreement
on
and
we
can
work
on
others,
of
course,
but
this
would
be
a
first
and
maybe
the
other
thing
about
this
was
if
we
can
get
get
a
few
best
practices
in
there
yeah
into
the
repo,
then
it
may
be
easier
for
other
people
to
read
so
you're.
Looking
at,
we
have
a
template
and
we
have
the
only
one.
B
B
So
it's
twofold,
get
this
best
practice
in
and
have
it
as
an
example
anyways.
So
the
it
has
all
the
sections,
except
for
the
user
story,
section
there's
a
lot
of
other
content,
so
we're
pretty
close
to
writing
out
an
actual
user
story.
We'll
probably
link
that
to
a
new
pr
for
that.
But
it
has
all
the
other
sections,
including
a
pretty
pretty
extensive
reference
section
for
going
out
to
what
other
people
talked
about
on
this
one.
B
B
B
Some
of
the
trade-offs,
I
guess,
would
be
the
first
process
by
default-
may
be
running
as
roots,
so
you
have
to
think
a
little
bit
more.
I
guess
it's
a
little
bit
more
work
up
front.
There
may
be
upstream
images
that
didn't
think
about
setting
the
user,
the
uid
and
gid
so
that
they're
not
root,
which
means,
if
those
are
your
base
configurations,
you
would
have
to
take
that
into
account.
If
you're
building
on
a
existing
upstream
image.
A
B
Oh
yeah
totally,
and
if
you
want
to
jump
in,
I
guess
the
last
part
was
just
the
work
look.
I
can't
share
my
screen
unless
you
stop
there,
we
go
cool
right,
so
this
is
just
looking
on
the
diff
display
different
and
there's
all
the
references,
different
places,
workload
contacts,
so
this
would
be
everywhere,
is
by
default
and
pretty
straightforward
on
a
test
plan,
but
there's
a
split
between
doing
static
analysis
and
and
then
run
time
analysis
for
stuff
like
did
they
set
user.
B
B
B
C
I
didn't
write
this
as
a
comment,
but
maybe
we'll
just
phrase
it
now.
Another
issue
I
thought
about
is
it's
quite
rare,
but
there
are
pods
that
use
system
d,
various
reasons
to
do
it.
It's
not
so
simple
to
set
up,
but
it
you
can
definitely
set
it
up.
In
that
case,
you,
you
might
be
running
system
services
that
are
root.
C
So
it's
not.
You
know,
you
know
your
main
entry
point
might
not
be
root,
but
there
might
be
yes,
there
might
be
things
running
in
root
anyway,
and
I
can
think
of
other
things,
cron
jobs.
You
know
it
could
also
be
through
systemd.
It
doesn't
have
to
be
systemd
right,
it
could
be
any
kind
of
system
service,
but
given.
C
E
F
C
E
E
When
you're
talking
about
init
systems
on
occasions-
and
I
don't
know
how
systemd
is
implemented
here,
but
many
init
systems
make
the
assumption
that
they're
pid
that
they're
the
lowest
bid
and
if
they're
not
the
lowest
pid,
then
they'll
fail
at
doing
what
they
want
to
do
by
by
design.
So
it
may
not
be.
It
may
not
be
an
issue
in
systemd,
but
there
are
net
systems
where
your
your
pit
matters.
C
A
I
was
gonna
say
so
one
of
the
things
we
should
consider
capturing
right
is:
we
should
limit
like
one
best
practice
per
input
here
right.
I
think
that
there's
a
bunch
of
best
practices
that
could
come
out
of
this.
If
we,
you
know,
agree
and
move
forward,
that
running
is
root.
When
you
don't
need
to
as
a
best
practice,
then
we
should
cap
this
one
to
that.
A
I
do
think
that,
like
when
we
do
these
live
discussions,
it's
a
good
chance
to
talk
about
what
other
best
practices
would
potentially
fit
to
a
user
story
or
a
use
case.
So
that
way
you
kind
of
build
a
portfolio
against
it,
because
we
talked
about
you
know
getting
like
containers
from
vendors.
I
can
tell
you
like
one
of
the
challenges
I
deal
with,
and
this
ian
right
here
is
the
whole
black
box.
I'm
just
going
to
give
you
something
that
works
versus
you
know.
I
want
to
rip
it
apart.
A
Examples
of
I
don't
want
to
run
stuff
and
root
and
give
you
access
to
these
types
of
things
I
mean
I
have
you
know
a
big
multi-tenant
environment.
What
if
someone
comes
in
starts
doing
things
they
shouldn't
et
cetera
right
so
like
what
does
it
look
like
when
you
know
I
get
something
from
a
third
party
that
defaults
to
root
yeah.
F
So
the
there's
two
parts
to
that
one
is
this
best
practices
is
audience.
Is
the
cnf
developer
more
than
it
is
anybody
else?
You
might
care,
you
might
say,
follow
the
best
practices
when,
during
your
cnf
development,
but
the
cnf
developer
is
the
one
that
should
care
about
this
because
ultimately
running
as
roots,
give
or
take
the
fact
that
isolation
between
users
is
not
quite
what
it
could
be
in
kubernetes.
But
ultimately,
the
the
use
of
root
in
a
container
is
more
about
your
cnf.
F
F
You
know
a
set
of
acceptance,
tests
and
you're,
not
passing
them,
and
so
you
know
that
is
a
different
thing
from
I'm
going
to
break
my
support
contract
by
you
know,
making
changes
to
the
software
instead,
you're
saying
you
haven't
met
your
acceptance
test
and
the
deliverable
is
deliverable
is
not
acceptable.
I'm
not
paying
you
which
gives
you
the
leverage
you're
looking
for.
A
Yeah,
I
don't
think
it's
quite
that
clean
in
the
real
world,
because
product
people
like
to
come
up
with
deadlines,
and
you
know
things
need
to
go
to
market
and
all
this
I
think
in
an
ideal
world.
That's
how
it
would
work
and,
like
you
said
this
being
for
developers
like
we've
talked
about
this
in
the
past
right,
like
people
will
probably
look
at
these
repos
and
bake
some
of
this
stuff
into
an
rfp
right
so
like.
F
F
If
you,
if
I
supply
you
a
when
you're
wanting
b
right,
there's
no
way
for
you
to
get
b
out
of
a
I
either
have
to
supply
b
or
you
have
to
modify
it,
and
neither
of
those
things
you're
saying
is
in
the
real
world
going
to
be
anything
anyone's
going
to
be
happy
about
absolutely.
But
believers
are
there.
A
Yeah
and
in
the
I'm
just
wondering
that
this
negotiation
is
just
going
to
be
tricky
right,
because
this
is
going
to
come
down
to
the
system
operator,
telling
the
software
developer,
how
to
develop,
and
then
you're
going
to
have
someone
who
comes
and
I'm
just
playing
devil's
advocate
for
a
second,
because
I
do.
I
think
this
was
a
good
start.
I
think
that
this
needs
a
lot
more
meat
in
it
because,
like
you're
gonna
have
the
person
who's.
Like
listen.
A
F
So
we
need
to
at
some
point,
come
up
with
how
you
document
what
you
are
compliant
with
in
our
best
practice
baselines,
and
if
you
are
not
compliant,
you
write
down
what
you're
not
compliant
with,
and
you
know,
should
you
so
choose
why
you
are
not
compliant
because
you're
making
an
argument
that
the
receiver
should
accept
what
you've
given
them,
regardless
the
fact
that
you're
not
compliant
because
you
know,
because
presumably
it's
no
worse
than
it
would
otherwise
be.
I
mean
we
had
ridiculous
things
like
pretty
much,
don't
use
pointers
in
c.
F
F
A
A
I
would
make
this
a
little
bit
more
like
flushed
out
and
like
succinctly
just
clearly
I
mean
I
feel
like
the
second
bullet's,
pretty
pretty
clear-cut,
but
like
the
first
one
doesn't
really
read
like
a
goal,
so
I
would
just
call
out
like
distinctly.
These
are
the
goals
we're
trying
to
achieve
with
these
best
practices?
Then,
if
you
go
down
to
the
test
plan-
and
this
gets
to
your
exact
point
in.
A
A
But
it
all
kind
of
like
reads
weird
like
I
I
don't
know.
I
put
some
comments
in
like
like
motivation
like
it
does
both
the
benefit
like
it's
two
succinct
sections
but
lynn
like
you're
kind
of
like
just
inferring
from
the
summary
and
the
motivation
which,
depending
on
how
you
attack
this,
it
just
reads
weird.
So
all
right.
I
would
like.
A
A
We've
established
this
group
isn't
specifically
about
writing
code,
but
there
is
this
cnf
test
suite.
I
think
like
if
we
put
like
test
plans
together
that,
like
validate
that
a
best
practice
has
been
achieved
or
whatever
hey
this
give
somebody
to
like
grade
themselves
against
to
ian's
point.
So
then,
if
they
say
we're
just
not
going
to
do
this,
they
can
point
to
exactly
where
they're
making
their
compromises
and
then,
additionally,
if
people
did
want
to
get
more
on
the
code
contribution
side,
they
theoretically
could
automate
some
of
the
test
plan.
A
And
then
you
know
contribute
that
back
to
the
cnf
test
suite.
So
it
gives
our
group
a
way
to
tie
into
some
of
the
other
groups
and
for
the
people
who
want
to
write
some
code.
But
I
think
if
we
keep
the
test
plan
too
generic
then
like
the
best
practices,
like
did
you
put
somewhere
down
in
the
bottom
two
about
like
evaluating
cns
this,
and
that
I
mean.
F
A
F
A
I
think
maybe
we
just
have
different
definitions
of
the
test
plan
like
I
I
get
that
tells
me
what
I'm
looking
for
it
doesn't
give
layout
a
plan
of
what
I'm
testing
some
of
that
is
in
the
static
and
runtime
analysis,
like
I
said,
there's
some
inheritance
between
the
different
like
sub
sections,
but
well,
I
would
write
like
that's
what
I
want
to
hear.
What
would
you
write?
A
I
would
write
like
you
know,
expected
inputs
and
outputs,
and
this
is
what
we're
expecting
right
like
and
some
of
that
like
see
user
and
run
commands.
Some
of
that,
like
I
said,
is
in
the
static
analysis,
but,
like
I
mean
a
test
plan
to
me
infers
that
there
is
a
plan
that
you're
executing
against
and
then
that
would
have
predefined
inputs
and
outputs
to
validate
whether
or
not
you've
got
the
results.
B
C
B
C
F
C
F
Here
I
I'm
a
little
confused
by
what
you
mean.
By
that
I
mean
the
best
practice
is
literally
don't
do
this
thing
and
the
test
plan
says
I
will
look
to
make
sure
you
are
not
doing
this
thing
and
the
test
plan
is
written
in
such
a
way
that
it
is
testable
by
you
know.
Code
I
mean
I
wouldn't
care
if
it
was
testable,
I
wouldn't
be
happy,
but
I
it
would
at
least
be
acceptable
if
it
was
had
to
be
tested
by
a
human
being,
but
it
is
testable
by
code.
F
F
So
when
you
say
it's
principle,
not
a
best
practice,
the
principle
is
least
privilege
which
isn't
written
in
here.
The
best
practices
do
not
run
anything
as
rude,
which
is
a
yes,
no
answer.
Are
you
running
things
as
root?
Yes,
no.
Can
I
test
whether
you're
running
things
as
you
root?
Yes,
no.
If
these
tests
pass,
you
are
not
running
things
as
root.
There
is
no
way
you
can
get
to
root,
so
I
think
I'm
arguing
with
both
of
you,
but
I
I
mean
starting
with
tao.
C
I
well
if
it
is
a
best
practice,
I'm
a
little
worried
then
too,
with
the
tone.
I
didn't
read
it
that
way.
Why?
Because
sometimes
you
do
need
to
use
root,
and
then
the
question
is
okay.
What
guidance
can
we
give
to
people,
for
example,
pods,
but
I'll
give
you
one
example
right:
a
pod
does
not
need
to
have
one
kind
of
container.
It
could
have
multiple
containers,
but
the
way
kubernetes
works
privileges
are
granted
per
pod
and
not
per
container,
so
one
best
practice
could
be.
C
If
you
do
have
a
container
that
needs
a
root.
You
want
to
isolate
it,
maybe
into
a
pod,
rather
than
mix
it
with
with
other
containers
that
do
not
need
root
right
so
to
to
reduce
the
attack
surface.
If
we
will,
if
you
want
to
talk
security,
if
you
need
to
use
system
d,
then
use
system
d
with
a
user
rather
than
root
right.
There
are
all
these
things
that
you
can.
Why
do
I
need
roots
in
a
container?
C
I
don't
know
there
is
a
zillion
reasons
I
can
think
about
in
terms
of
of
specifically
network
functions
interactions
with
the
host
the
operating
system.
At
some
point,
you'll
probably
need
to
do
that
somewhere
and
the
idea
is
to
isolate
it.
So
the
principle
is
least
right:
it
doesn't
mean
zero
somewhere
there
there
will
need
to
be
some
sort
of
privilege.
So
then
the
questions
are:
do
you
want
it
to
be
even
a
workload
on
kubernetes?
C
The
idea
of
jumping
to
compliance
about
containers
seems
to
me
going
to
some
very
specific
use
case
here
to
me
to
me.
It
looks
like
a
step
too
far.
We
haven't
even
established
compliance
and
what
that
could
mean
and
why
a
compliant
application
has
to
have
all
containers
avoid
the
use
of
route
100
and.
B
B
To
all
things
yeah,
so
the
suggestion
then-
and
maybe
we
could
write
it
to
be
more
explicit
like
that.
So
then
we're
saying
if
this
is
a
best
practice,
then
it
just
because
you
don't
follow
this
best
practice
doesn't
mean
that
the
entire
cnf
or
application
is
not
cloud
native
or
anything
else.
We're
saying
try
to
avoid
using
root,
not
when
you
can't
so,
if
you
can
have
a
best
practice
that
you
decide
is
doesn't
work
for
you
and
that's
fine.
B
B
C
C
A
Disagree
a
little
bit
now.
I
I
want
to
disagree
on
that
point
like
I
think,
we're
supposed
to
be
probably
getting
guidance.
I
think
taylor
hit
the
nail
on
the
head,
though,
and
I
don't
necessarily
think
this
needs
to
stop
like
a
pr
from
being
accepted,
but
like
I
think
that
there
is
not
enough
context,
taylor
used.
A
I
slightly
disagree
with
you,
tal
and
like
I
do
think
we
should
be
somewhat
prescriptive
because
you
can
just
choose
not
to
follow
this
best
practice
and
be
like
these
are
my
reasons
why
I
just
don't
think,
there's
enough
context
in
this
for
someone
to
cleanly
articulate
their
reasons.
Why,
like
what
are.
F
I
intended
for
a
second
and
see
what
you
read
in,
because
it
might
not
have
come
across
in
the
document.
The
thing
that
container
roots
lets
you
do
literally
the
only
thing
it
lets
you
do,
because
most
of
the
things
that
root
can
do
really
aren't
allowed
in
containers.
Is
it
lets
you
change
it
lets
you
read
right
and
change
permissions
any
file
in
the
file
system,
which
is
probably
not
what
you
want.
F
F
E
F
E
E
We
we
need
to
be
able
to
say
that
this
thing
is
an
audit
mode
versus
this
thing
is
enforce
mode
and
get,
and
that
gives
the
the
various
groups
the
capability
to
pick
and
choose
the
things,
the
best
practices
or
future
compliance
things
that
they
exist,
the
ability
to
set
their
their
policies
and
baselines.
So
they
can
then
discover
and
and
optionally
enforce
things
that
they
care
about.
E
The
the
other
thing
as
well.
Is
you
look
at
it
from
a
vendor
and
consumer
perspective?
The
vendor
will
say
I
I
have
verified
or
ran
some
verification
program
that
that
has
given
me
information
about
whether
this
thing
meets
certain
requirements
and
the
testbed
can
can
help
there.
What
it
doesn't
do
is
it
doesn't
say
whether
this
thing
is
fit
for
purpose
by
the
consumer,
whether
it's
valid,
whether
it's,
whether
it's
a
validated
system,
that's
something
that
the
consumer,
in
this
case
jeffrey
and
his
team,
would
have
to
work
out.
E
Is
this
thing
fit
for
purpose,
and
this
is
where
the
we
we
want
to
have
some
of
the
best
guidance
or
best
practices
to
say
like?
Is
it
good
for
purpose?
Is
it
fit
for
a
purpose
from
a
security
perspective,
just
use
that
as
an
example,
in
which
case
you
could
say
we
want.
We
want
no
route.
We
want
to
have
privilege
escalation.
Disabled
there's,
actually
a
privilege
escalation.
We
did
within
kubernetes
that
doesn't
allow
you
to
that,
turns
off
the
suet
or
ignores
the
sewage
the
sewage
bit.
E
We
want
to
drop
all
capabilities,
except
for
the
ones
that
are
absolutely
minimum,
that
you've
compartmentalized
and
some
of
it
is
through
enter
the
mixture
of
the
verification
and
validation
combined.
Ideally,
you
should
get
to
somewhere.
That
is,
that
is
cons
consumable,
but
at
the
same
time
you
provide
that
information
out.
So
it
ends
up
becoming
a
conversation
between
the
two
and
not
not
an
enforcement,
which
I
I
don't
think
we'll
have
the
ability
to
do
from
here.
A
Right,
I
I
want
to
point
out
one
thing
too:
I
I
don't
think
that
it's
a
zero-sum
game,
like
I
think
both
ian
and
cal,
can
have
what
they
want.
I
think
ian,
if
you
do
a
better
job
of
describing
in
this
document,
what
you
just
described
in
words,
then
we
say:
okay,
this
is
what
we're
trying
to
achieve
with
this
best
practice.
A
Then,
if
tal
has
an
exception,
we
shouldn't
write
the
best
practices
with
the
mindset
of
all
these
exceptions,
but
we
should
just
tell
you
this.
You
say
like
look.
This
is
what
this
best
practice
is
seeking
out,
but
dot
dot
dot.
I
have
to
do
this.
Therefore,
I'm
gonna
run
this
container
as
root,
and
then
you
say:
okay,
I
accept
that
risk,
because
pal
needs
to
accomplish
x.
You
know,
but
like
we
shouldn't
water
down
the
best
practice
in
my
opinion,
tell
because
we
know
that
the
exceptions
are
coming.
C
Yeah,
I
I
don't
disagree
with
that.
I
think
my
point
is,
as
others
upset
you,
that
there's
there's
room
for
more
context
here
and
more
guidance.
I
would
say
and
more
I
think
you
know
jeffrey.
You
said
it
reads
a
little
bit
weird.
I
think
the
tone
is
just
the
word
compliance
I
find
a
little
bit
scary
right.
I
I
could
easily
see
a
telco
taking
this
and
saying.
Okay,
you,
you
need
to
do
this,
there's
a
test
suite
and.
B
B
F
A
perfectly
acceptable
one
to
use
there,
but
I
think
you're
saying
that
it
might
come
with
connotations.
We
don't
want
to
go
with
tal.
You
said
several
times
without
listing
them.
There
are
reasons
why
you
might
want
to
use
root,
and
I
think
what
we're
saying
here
is:
if
there
are
reasons
why
you
might
want
to
root.
If
we
can
list
those
out,
or
at
least
as
many
of
them
as
we
can
think
of
out,
then
we.
B
F
F
A
deviation
of
this
nature
is
normal
and
expected
you
might
want
to
just
give
them
the
green
light
on
that
or,
alternatively,
have
you
thought
of
this
alternative
way
of
doing
it
that
doesn't
require
root.
That
would
also
be
another
thing
you
could
do
there.
There
are
your
example
of
systemd.
To
take
an
example
is
basically
saying
there
is
software
in
the
world
that
people
want
to
use
which
shouldn't
need
root
but
insists
upon
it
anyway.
Perhaps
so,
we've
got
to
non-compliances
are
perfectly
fine.
F
They
are
an
expected
part
of
this
process.
Frankly,
nothing
is
going
to
be
100
compliant
at
least
to
begin
with.
So
we
just
need
to
help
people
through
the
process
of
using
what
we
write,
not
necessarily
changing
this,
because
a
best
practice
that
says
well,
you
might
not
care
to
follow
the
best
practice,
is
basically
not
best
practice,
whereas
a
best
practice
that
says
this
is
the
platonic
ideal
of
a
container
in
an
application.
F
E
The
framework
that
is
often
used
in
this
in
this
particular
path
when
you
start
looking
at
overall
governance,
is
you
end
up
with
policy
and
standards
at
the
top
policies?
Are
things
like
all?
Data
at
rest
must
be
encrypted
standard
would
be
like
we
use
aes
and
then
at
the
lower
end,
you
end
up
with
procedures
and
guidance
procedures.
Are
we
use
bitlocker
to
encrypt
windows
systems
with
aes
in
this
way
versus
guidelines,
which
is
like?
Don't
leave
your
laptop
in
the
car?
The
difference
between
the
two
is
that
procedures
are
always
mandatory.
E
Guidelines
are
optional,
but
very
tend
to
be
very
good
advice
in
this
scenario,
we're
focusing
primarily
on
guidelines,
but
it
is
possible
that
in
the
operational
side,
people
may
elevate
some
of
these
things
into
into
procedures,
and
so
we
want
to
make
sure
that
they're
that
they
are
testable
when
they
can
be
which
gives
the
which
gives
the
various
groups,
both
on
the
vendor
and
consumer
side,
the
ability
to
to
audit
and
enforce
when
they
want
to.
But
ultimately
those
knobs
become
become
tunable,
and
we
focus
only
on
guidance.
C
Everything,
you
said
is
perfectly
reasonable.
You
know
just
add.
Look
the
user
story
here
is
tbd
right.
We
we
didn't
really
start
with
the
user
story,
so
we
don't.
We,
we
kind
of
jumped
jumped
a
little
bit
ahead
here.
I
I
think
that
the
document
as
it
stands
right
now
just
feels
a
little
lopsided
to
me.
It
kind
of
jumped
to
the
end
of
okay,
no
root
and
there's
there's
a
big
story
along
the
way,
starting
from
the
user
stories
stories
right
and
going
towards.
C
Well,
you
know
the
user
thinks
they
need
root,
they
probably
don't
and
if
they
think
they
do,
they
don't
realize
what
the
problems
could
be
and
and
requiring
root.
So
we
kind
of
jumped
right
to
to
the
end
rather
than
than
than
building
something
along
the
way.
It
might
be
obvious.
You
know
to
to
all
of
us
reading
this,
but
I
I'm
not
sure
it'll
be
100
obvious
to
people
say
well.
Why
not?
B
B
B
F
I
I
I
would
suggest
that,
if
we're
going
to
come
up
with
advice
on
how
to
consume
this,
like,
for
instance,
those
things
where
again
tells
saying
you
know,
I've
got
a
laundry
list
of
reasons
why
I
might
want
to
use
root
that
we
don't.
We
try
not
to
build
it
into
the
best
practice.
We
try
and
keep
the
best
practice
short
and
sweet.
We
come
up
with
a
guidance
note
that
goes
along
with
the
best
practice
to
to
kind
of
say.
Well,
you
know
these
are
things
where
you
will
probably
find
deviations.
B
I
agree
with
that.
I
think
this
is
one
example,
but
we
don't
want
to
listen
and
we
didn't.
You
didn't
go
into
like
extensive
here's
how
to
how
to
handle
that.
I
don't
think
we
should.
I.
I
agree
that
we
shouldn't
have
all
the
examples
of
the
all
the
exceptions
listed
and
how
to
manage
them
as
well
as.
A
A
We
want
to
write
them
to
the
90
right
and
I
think
one
other
thing
that
would
help
when
we
talk
about
this
context
and
things
that
we
should
add
in
is
like
as
you're
reading
these
you
know
that
there's
going
to
be
complimentary,
best
practices
that
fit
underneath
one
of
these
principles
right
so,
if
least
privilege
is
our
principle.
No
root
is
one
best
practice,
another
best
practice.
You
know,
and
we
should
like
capture
this
and
you
know
keep
tabs
on
it
is,
you
know,
create
users
with
the
appropriate
amount
of
permissions
right.
A
This
gets
into
ian's.
Point
of
you
know:
are
there
going
to
be
times
when
we
might
need
to
use
your
root
sure,
but
the
best
practice
is
don't
run
root.
Another
best
practice
is
to
create
the
correct
user,
with
the
appropriate
permissions
to
execute
the
task
as
needed
right,
and
so
I
think
when
we
get
into
some
of
these,
like
you
know,
what-if
discussions
too,
if
we
just
track
what
other
best
practices
would
complement
this
one
and
how
you
kind
of
build
like
the
suite
of
best
practices
underneath
the
least
privileges
umbrella.
C
Well,
you
know,
I'm
I'm
really
interested
in
those
guidances
more
than
than
this
document.
I
have
to
say
I
get
questions
all
the
time.
For
example,
people
wanting
to
run
ssh
sshd
right
in
a
in
a
container
for
various
reasons.
If
it's
accepting
netconf,
if
it's
something
else
now,
how
do
you
do
that
with
it
without
access
to
it?
How
do
you
update
certificates?
How
do
you
do
other
things?
Where
do
you
put
it
in
the
build
process?
C
Nobody
wants
to
run
root.
I
think
I
think
this
any
decent
programmer
reads
this,
and
this
is
very
obvious
right.
Of
course,
we
don't
want
to
run
root,
but
what
do
you
want
us
to
do?
Instead?
What
do
you
suggest?
What
is
the
ecosystem?
What
is
an
alternative
to
sshd
that
can
run
in
a
more
cloud-native
environment
without
these
requirements?
C
B
That's
tal,
I
I
sorry
victor.
I
love
the
idea
of
recommendations
on
how
to
implement
something
so,
whether
that's
dealing
with
exceptions
or
people
that
are
saying,
oh,
I
I
lack
the
best
practice
now.
How
do
I
do
it
and
with
the
software
I
have,
because
it's
not
set
up
for
that,
so
helping
people
to
actually
implement
sounds
great,
and
I
think
that
could
be
a
new
section
that
we
could
have
within
the
cnf
working
group.
Where
we
talk
about
that,
here's
the
best
practice,
and
now
we
start.
B
So
if
we
had
a
best
practice
for
not
using
root
within
that
folder,
maybe
we
have
here's
a
bunch
of
other
documents
that
talk
about
what
about
images
that
use
systemd?
What
do
you
do
for
that?
And
then
we
could
talk
all
about
that
and
keep
it
separate
from
the
main
best
practice
document,
but
allow
us
to
add,
as
many
as
we
want
for
real
situations.
C
That
makes
sense
to
me
yeah
and
I'll
just
remind
myself
and
others
here
that
we
specifically
picked
this
one,
because
it's
a
low-hanging
fruit,
that's
very
obvious,
so
yeah
and
in
a
sense
this
is
a
very
trivial
best
practice
right,
but
even
here
we
see
that
there's
there's
some
subtlety
in
terms
of
actually
no.
This
is
non-subtle.
I
think
that's
what's
interesting
about
it.
This
is
not
a
non-subtle
best
practice
right,
just
don't
use
rube.
F
D
E
Having
something
that's
testable
is
good
and
again
how
you,
how
you
adjust
the
knobs
matters,
matters
a
lot,
and
I
think
part
of
what
we
need
to
do
is
make
sure
that
we're
very
clear
that
we're
developing
guidance
and
that
the
guidance
can
be
consumed
in
these
other
ways.
Other
than
just
enforcement
on.
C
I,
I
might
add
you
know,
I
said
this
is
a
very
blunt
best
practice.
There
is
a
tiny
little
subtlety
that
I
want
to
point
out,
and
that
is
that
there's
been
an
evolution
from
the
early
days
of
docker
to
truly
what's
cloud
native
in
kubernetes
right,
there's
something
very
cloud
native
about
this,
because
early
on
docker
was
exactly
about
the
point
of
isolation.
C
Sure
use
root,
do
whatever
you
want
inside
the
container,
because
it's
completely
isolated,
it's
not
the
real
root.
It's
not
the
host
group.
All
you're
doing
is
changing
stuff
inside
the
container.
We're
thinking
about
this
differently.
We've
evolved
our
thinking
over
time
right
because
we're
thinking
about
these
different
pods
different
containers
working
together
to
do
something
and
the
kind
of
reliability
that
we
want.
There
is
not
you
know,
do
whatever
you
want
inside
the
container.
C
It's
remember
that
you're
playing
as
part
of
a
bigger
system
here,
so
so
you're
thinking
about
attack
surfaces
as
being
not
isolated
in
one
place,
but
you're
saying
well.
This
is
one
dot
and
inside
a
larger
topology
that
I
need
to
think
of.
So
if
I
have
everybody
using
root,
I'm
I'm
really
it's
very
hard
to
tame
these
cats.
C
E
That's
an
excellent
point
and
we
ran
into
that
same
problem
when
docker
was
new,
so
in
2013
a
large
part
of
the
messaging
that
we
did
was
look
at
12-factor
apps.
We
know
that
they're
not
perfect.
They
don't
align
to
everything.
But
if
you
understand
the
guidance
there
then
it'll
help
you
achieve
what
you
want
within
docker,
and
I
think
that
they're
similar
that
this
this
can
help
in
that
same
path.
E
Where
we're
going
to
get
people
who
have
never
used
kubernetes,
they
don't
know
what
a
pod
is
and
we're
asking
them
to
go,
build
cns,
so
we're
going
to
run
into
the
same
problem.
Why
do
I
not
need?
Why
do
I
not
need
root?
Why
do
I
not
need
privileges?
What
why
why
do?
I
need
immutable
infrastructure
and
providing
that
that
guidance
as
to
why
it's
important
and
how
it
all
fits
together
is
crucial
towards
helping
them
be
successful.
C
Yeah
and
it's
it's
actually
a
huge
developer
problem,
a
lot
of
people
work
with
docker,
and
then
they
think
the
next
step
is
then
putting
it
on
the
cloud.
But
the
whole
idea
of
cloud
native
right.
We
we're
what
we're
trying
to
say
here
is
you
have
to
think
cloud
natively
from
the
very
beginning
from
your
architecture,
but
you
don't
write
a
single
line
of
code
right
of
a
network
function
before
you
understand
that
this
is
going
to
be
a
cloud
native
network
function.
C
That's
a
very
good
point.
That's
another
one
of
those
you
know
when
I
said
there
are
so
many
reasons
why
you
might
want
to
use
root.
You
know
I
I
don't
know
even
where
to
start
here's
one
potentially
right
so
again,
there
are
other
things
you
can
do.
Instead,
you
know,
there's
there's
never
only
one
way
to
do
something.
A
C
C
Is
just
to
state
the
principle,
I'm
happy
with
that.
I
think
it
kind
of
bleeds
into
other
thing
when
it
talks
about
test
plans.
I
think
that's
beyond
just
stating
the
principle:
that's
how
to
enforce
it.
That's
a
little
bit
different,
but
I
I
think
I
made
my
point
so
whether
people
agree
with
me
or
not,
I
I
have
nothing
more
to
add
all.
B
B
Anything
about
enforcement,
frederick
keeps
saying
I've
said
that,
are
you
a
difference
between
enforcement
and
just
notifying
whether
expectation
of
the
test
is
one
way
or
another?
That's
all
we're
putting
forward
when
you
have
a
best
practice,
can
you
implement
it?
Is
it
possible
at
all?
Yes,
it's
possible
to
use,
root
or
not
use
root.
C
B
B
C
C
Oh,
absolutely
I
mean
side.
Car
is
kind
of
it's
just
another
pot
in
the
container
they're.
Also
the
issue
of
innate
containers.
There
are
various
ways
you
can
put
containers
inside
pod,
a
pod.
The
thing
is
that
the
pod
concept
itself
is
very
interesting
right.
It's
a
it's.
The
pod
creates
a
context
that
is
shared
by
all
the
containers
that
are
running
in
there,
but
the
containers
are
still
containers
they're
still.
E
C
Yeah
I'll
give
I'll
give
a
very
popular
example,
which
you
know
when
people
hear
sidecar,
they
always
think
of
istio
right.
That's
the
the
one
operator
and
product
that
uses
probably
sidecars.
More
than
anything,
the
sidecar
is
changing
the
ip
tables
for
the
pod.
The
ip
tables
are
used
by
all
containers
in
the
pod,
so
the
sidecar
is
able
here
to
use
privileges
right
to
to
actually
redirect
all
the
network
traffic
coming
inside
and
outside
of
the
pod.
C
It's
a
very
powerful
thing
to
do,
and
that
is
all
based
on
privileges
right,
you're,
giving
your
sidecar
the
privileges
to
do
that,
because
you
trust
you
know
what
it's
going
to
do
and
the
features
is
one
that
you
want
so
yeah.
My
point
is
that
there's
there's
a
much
bigger
story
here
than
than
just
this
best
practice
as
it
is,
but
it's
it's
still.
You
know
I
agree
with
the
best
practice
right.
C
You
do
want
to
not
use
root
when
you
don't
have
to,
and
if
you
think
you
have
to
you,
probably
don't
so,
there's
a
narrative,
it's,
but
but
I'm
okay
with
making
it
you
know
short
and
sweet.
Is
the
word
that
people
seem
to
like
here?
Let's
make
its
extent
and
then
add
supplemental
documents
that
that
that
dive,
deeper.
E
Yeah,
if
you
want
to
hear
something
really
scary,
all
pods
by
default,
get
the
net
raw
capability,
which
means
that
they
can
read
and
write
things
directly
onto
the
onto
the
network
and
they
need
this
for
pinged,
because
icmp
responds
responding
to
icmp
requires
the
network
capability,
so
yeah
in.
In
short,
this
is
this
is
why
layering
and
other
things
like
setcomp
or
other
policy
engines
like
falco
and
similar,
become
very,
become
very
important
in
in
that
aspect.