►
From YouTube: Policies and Telemetry WG Meeting - 2018 03 28
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
On
the
services
for
ingress
and
egress
traffic-
and
it
became
clear
that
we
have
kind
of
an
inconsistent
model,
we
don't
services
or
really
just
destinations,
they're,
not
sources.
So
that
made
me
look
at
what
is
source
that
service
that
we
have
in
our
in
our
attributes,
which
led
to
the
kind
of
there's
a
bunch
of
issues.
That
already
is
news
to
me,
but
everybody
else
know
this.
If
you
effectively
so
source
sources,
we
can't
ensure
that
source
dot
service
is
correct.
A
It's
it's
a
derived
thing
that
it
can
easily
be
spoofed
and
I
believe
that
exposing
that,
in
its
current
form
to
the
user
is,
is
doing
them
a
disservice.
Lulling
them
as
into
a
false
sense
of
security
and
considering
security,
is
one
of
our
big
selling
features.
We
shouldn't
do
this,
so
we
can
either
cut
it
or
fix
it,
but
I'm
a
little
dubious
about
the
fixing
part.
So,
fundamentally,
architectural
II
work
loads
of
the
things
that
are
sending
sending
traffic
throughout
the
mesh.
A
B
Yeah
I
mean
so
I
think
it
depends
over
the
course
of
the
lifetime.
This
project
people
have
been
adamantly
worried
about
the
fact
that
there
is
no
source
service
to
saying
that
we
must
find
one
and
declare
a
canonical
one
for
all
all
workloads
and
all
traffic
so
that
we
could
do
things
like
policy
into
industry
in
a
consistent
fashion.
B
A
Just
my
spidey
sense,
er
2
is
tingling
that
I
suspect
that
lying
effectively
that's
what
it
boils
down
to
lying
and
pretending
this
cert.
This
traffic
is
coming
from.
This
particular
service
will
lead
to
downstream
things
that
we
don't
like
misattributed
things.
The
user
is
going
to
set
rules
through
this
food
because
he
thinks
it's
service
foo,
but
service
who
actually
never
sends
traffic
because
it's
it's
not.
It's
not
been
this
designated
as
the
as
risk
as
as
being
the
recipient
of
all
traffic
from
the
given
workload.
A
C
A
A
Multiple
services,
that's
fine
all
the
way.
In
the
way
out,
we
can't
tell
the
single
set
of
binaries,
which
service
are
they
representing
when
they're
making
requests?
We
can't
enforce
this.
We
can
derive
this.
So
therefore,
having
sourced
out
service
in
that
context
is
misleading.
It's
the
traffic
is
not
coming
from
a
particular
service
is
coming
from
a
bunch
of
it's
coming
from
a
bunch
of
running
binaries,
somewhere
and
yeah
right,
so
that
there's
a
there's,
a
a
symmetry
there.
A
The
internal
Google
system
has
a
notion
of
a
service
yet,
and
but
when
that
service
is
describing
sources
of
traffic,
it's
done
in
terms
of
you
in
Google
is
called
MDB
groups,
basically
in
terms
of
service
accounts,
so
you
got
service
as
the
destination
for
traffic
and
service
accounts
or
the
source
of
traffic.
So
it
was
kind
of
stunning
to
me
that
after
all
this
meandering
on
the
steel
side,
I
ended
up.
We
ended
up
at
the
same
suggesting
the
same
model
that
already
Google
has
had,
certainly
for
I.
A
A
A
B
C
Yeah
I
mean
I
would
hope
that,
as
we
move
into
some
of
the
the
tracing
stuff,
we're
doing
that,
we
might
actually
be
able
to
separate
different
source
services
from
a
single
workloads
traffic.
You
know
if
you
know
that
a
request
came
in
to
a
particular
service
and
you
have
some
kind
of
tracing
key
that
you're
actually
extracting
then
you
can
probably
then
identify
the
outgoing
traffic
is
also
being
from
that
service.
A
There
are
legitimately
services
that
have
that
are
self
driven
that
are
not
driven
by
input
by
the
user
by
external
inputs
right,
so
those
only
would
need
to
be
modeled
as
well.
So
the
issue
is
that
we're,
where
is
Tio's
initial
claim
to
fame
is
hey.
We
can
come
into
a
cluster
and
this
just
works
without
changing
code.
A
So
if
you
have
some
code
that
can
act
as
multiple
services
there,
without
changing
the
codes
to
have
that,
that
code
tell
us
which
service
it's
acting,
as
as
we
just
can't
make
that
those
determinations
just
so
the
common
case,
so
I
expect
in
a
fully
modernized
at
the
common
cases,
we
have
one
workload
per
service
per
service
account.
It's
all
single,
can't
cardinality
works
great
in
the
migration
path.
I
would
expect
that
you
start
with
a
jumbo
service
jumbo
binary
that
implements
one
service
you
now.
The
next
step
is
jumbo.
A
Binary
implements
multiple
separate
services
and
then
the
next
step
is
start
teasing.
The
magento
binary
to
be
separate
binaries
each
implementing
one
service,
so
I
think
the
reality
is.
Our
customers
are
going
to
see
a
lot
of
cases
where
there's
one
binary
with
multiple
services
and
we
need
to
cater
to
that
in
a
reasonable
way.
Absolutely.
C
A
C
A
All
so,
if
all
we
do
so,
there's
two
there's
two
sides
of
this.
First
there's
eliminating
these
attributes,
which
by
itself
has
its
own
set
of
impacts
and
then
there's
a
configuration
model
we're
looking
at,
which
is.
We
were
just
going
to
configure
services
and
now
we're
going
to
convict
your
services
and
workloads
as
separate
things
and.
A
A
C
B
A
So
I
don't
have
the
answer
to
that.
Yet
so
I
had
been.
My
expectation
is
yes.
Indeed,
the
workload
configuration
it's
actually
not
workload.
It's
service
account
config,
but
it's
getting
that's
it.
That's
kind
of
I
think
that's
getting
a
little
too
far,
conceptually
so
I'd
say
this
is
a.
This
is
a
workload
like
workload.
Config
it's
associated
with
a
particular
service
account
beyond
validate
I,
don't
know
how
we
do
validation
and
what
level
is
certainty
we
can
offer.
There
does.
C
A
B
B
A
Thing
you
get
from
source,
that
user
is
a
spiffy
account
right,
yep,
yeah,
so
source.
That
user
is
in
fact
the
thing
that
you
need
to
use
to
apply
your
policies.
Is
that
the
same
as
ID
workload
done?
Well,
it's
a
service
account,
that's
running
the
workload,
and
yes,
those
would
be
it.
We
would
consider
the
same
thing
effectively
so.
A
From
a
security
perspective
yet,
and
if
you
think
about
it,
makes
sense
so
from
a
security
standpoint,
the
same
service
account
can
be
running
multiple
different
binaries,
but
they
all
had
the
same
authority.
So
if
I
apply
it,
if
I
deny
something
to
one
particular
binary,
fine,
the
operator
user
can
go
and
add
that
functionality
to
the
other
binary
and
allow
so
from
a
security
standpoint.
They're
all
the
same
sure.
D
B
A
Labels
so
I'm
trying
to
make
a
clear
distinction
between
what
we
can
guarantee
and
what
we
cannot
and
and
to
me,
it's
fine
to
say:
hey
labels
are
whatever
the
user
set
at
the
on
the
source
pod
or
whatever
it
environment
you
you're
running
and
it
co
washes
its
hands.
It
is
what
it
is,
but
for
the
as
much
as
possible,
the
other
stuff.
We
need
to
be
able
to
provide
some
level
of
guarantee
that,
yes,
this
is
correct.
So.
B
In
that
Center,
okay,
can
we
it
is
acceptable
to
make
the
claim
that
if
you
want
to
do
something
that
is
more
precise,
everything
must
be
in
terms
of
source
user,
with
auth
enabled
and
otherwise
just
like
kubernetes.
We
derive
your
service
from
the
labels
on
the
PI
through
label
selectors.
If
there
is
no,
that
is
a
best-guess
or
we
have
a
special
label
or
something
right,
but
we
don't
need
to
throw
away
those
attributes.
B
A
So
that's
effectively,
the
plan
were
all
now
and
I
consider
having
the
users
generally
a
like
a
major
of
being
in
the
pit
to
failure
here.
If
you
look
at
our
vocabulary
of
attributes,
the
number
two
attribute
that's
listed
this
source
service
and
there's
no
mention
anywhere
about
this
being
dangerous
and
certainly
as
I'm
as
I'm,
using
it
I'm
going
to
forget
the
fact
that
oh
this.
C
A
C
Think
sto
should
endeavor
to
to
authenticate
as
many
attributes
as
it
possibly
can
all
right.
If
it
knows
it's
running
on
kubernetes,
then
it
can
go
and
validate
even
down
to
the
single
container
level
of
the
thing.
That's
making
the
request.
Yeah
I,
don't
see
why
it
shouldn't
didn't
authenticate
those
attributes.
C
B
C
Do
you
call
it?
How
would
you
pick
something
well.
B
C
Still
need
an
answer
for
what,
if
that
attribute
is
missing
or
that
label
is
missing
or
incorrect
right.
If
the
drop
in
case
of
you
already
have
a
kubernetes
cluster,
a
dis
tio
you're
not
going
to
have
those
labels
set,
and
someone
might
set
it
to
something
that
isn't
actually
pointing
at
the
bottom
and
in
both
those
cases
you
need
to
still
have
some
fallback
behavior.
A
Yeah
I'm
also
the
the
it's
a
matter
of
a
scope
of
authority
as
a
if
you
imagine,
a
large
mesh
which
has
a
mesh
operator
and
several
service
operators
as
the
as
the
the
guy.
That's
configuring,
a
service
I
can't
vouch
for
what
the
other
teams
are
doing.
Other
service
operators
are
doing
with
their
labels
on
their
pods.
So
right
in
the
current
model,
II
anybody
can
spoof
to
pretend
to
be
anybody
any
any
other
service
and
there's
no
control.
So.
A
A
Yes,
all
right
we're
not
using
it
that
way,
though
right
cause
my
source
not
serve
it.
So
it's
sorry,
but
it's
the
same
argument,
so
we
yes,
we
killed,
enhance
the
authentication
model
to
support
this
right
now,
it's
that
it's
not
participating
at
this
level.
Solar
service
is
just
a
label
that
we
read
from
the
source.
A
B
So
I
think
whatever
labels
you
put
on
there
I
didn't
match
the
pot
to
the
service
right
I
mean
so
there's
a
couple
issues
with
how
we
do
this.
But
if
you
were
doing
it
I'll
understand
properly
the
set
of
labels.
That
service
subscribes
is
the
selector
for
paws
the
Thurman
self-service
traffic
flows
down
to
that.
So,
if
you
started
attacking
the
labels
that
define
your
service
to
the
five,
almost
dozen
traffic
coming
in
to
the
service
you're
claiming
to
be
would
be
going
to
your
pod
and
you
have
start
having
failures
right.
B
B
A
C
I
mean
I,
see
this
as
the
moment
into
an
empty
LS
provisioning
question
I,
think
you
should.
We
should
be
able
to
pack
arbitrary
sets
of
attributes
into
the
MT
LS
provisioning,
and
then
it's
on
that
provisioning
process
on
the
certificate
provisioning
process
to
figure
out
how
to
validate
those
attributes.
A
Okay,
nice,
so
I,
agree,
I,
think
we
could.
We
could
safely
deliver
that
information
and
then
are
we
content
saying
about
the
you?
Don't
want
too
many
problem,
just
ignoring
that,
so
there's
a
canonical
service,
that's
associated
with
every
workload.
It
doesn't
matter,
it's
it
might
be
unrelated
to
any
the
incoming
traffic.
We
just
say
that's
what
it
is
so.
C
A
B
A
D
D
A
B
A
So
what
I
was
looking
at
this
I
realized?
You
know
I'll.
We
have
several
attributes
that
are
just
derived
from
the
same
one.
Why?
The
heck?
Are
we
sending
this
over
from
envoy
on
every
request?
We
could
just
derive
this
on
mixer
on
the
other
way.
I
said
is
there's
just
string,
manipulations,
but
stuff
like
source
dot
name
is
a
sub,
is
particular
string,
part
of
source
service
and
that
kind
of
stuff
right
side.
B
Yeah
so
I
mean
this
was
sort
of
the
intent
behind
the
curtain
is
in
the
doctor,
and
mixer
right
was
to
derive
things
from
source
you
IDE
or
destination
UID
like
pod
name
and
everything
else,
so
that
some
counties
sort
of
exists
within
mixer
today
and
some
of
the
things
they
lifted
like
destination
domain
and
destination
namespace,
or
that
maybe
decision
name
states.
But
the
station
name
is
destination
to
me
and
I,
don't
think,
are
populated
by
envoy
and
certainly
aren't
derived
today's
and
mixer.
D
B
B
B
A
B
A
F
See
seed
men
are
on
the
open
issue.
Currently,
everything
is
built
kind
of
dynamically
at
runtime,
because
you
need
to
account
for
any
adapters,
it'll
call
long
yeah,
whereas
in
pilot
you
know
they
just
have
a
static
list
of
all
the
kinds
that
they're
able
to
search
for,
but
I'm,
not
sure.
If
we
can
have
that
luxury,
if
we
always
want
to
have
us
explicit
CRD
for
each
after
or
if
there
was
supposed
to
be
like
a
bundled
adapter
sort
of
thing,.
A
So
right
now
we
do
have
a
co
deeper
adapter.
What
Mandar
was
suggesting
is
there's,
there's
an
adapter
config
CRD,
that's
the
type
and
then
inside
of
it
is
basically
a
pro.
No,
not
any
so
that's
adapter
specific
so,
but
there's
only
one
C
or
D
flavor,
so
that
would
I
think
that
would
simplify
things
and
to
end
in
how
we
do
stuff.
But
it
is
a
change
relative
to
what
we
have
all
the
configs
are
invalid.
After
that.
A
B
A
So
what
I
plan
on
doing
is
making
it's
over
on
a
and
the
per
component
basis,
you
can
define
the
user
and
the
command
line
can
list
the
zones
by
default.
If
you
output
without
a
zone
within
their
component,
that's
that's
what
they
usually
see.
If
you
turned
on
debug
level,
output
and
and
then
the
user
can
then
start
adding
more
zones
and
then
seeing
more
stuff
so
like
in
the
case
of
make
sure
you
could
have
a
zone,
that's
the
attributes
of
home
and
those
debug
statements
only
come
out
when
that
zone
is
enabled.
E
A
G
A
B
There
is
one
thing
that
came
up
I,
think
Scott's,
aware
of
it
too
was
just
providing
adapters
with
resources
like
persistent
disk
and
I.
Don't
know
what
what
we
want
to
do
in
terms
of
having
some
sort
of
canonical
way
of
doing
that,
or
we
want
to
sort
of
clumping
that,
but
that's
something
that
comes
up
in
terms
of
reliability
for
things
that
data
before
dumping
it
somewhere
else
so
I
just
wanted
to
to
read.
That
is
something
we
might
want
to
start
having
a
story
around,
especially
for
analytics
pipelines
or.
A
A
D
D
A
B
I
didn't
have
anything
else,
but
I
think
it's
worth
mentioning
that
with
the
helm
templates
chart
the
helm,
charts
that
went
in
earlier
this
week.
We
now
no
longer
have
an
SEO
mixer
service.
We
have
SPO
telemetry
in
sto
policy,
and
so
it's
just
something
to
be
aware
of
moving
forward.
Other
work
mixers.
F
B
B
F
Related
to
the
mixer
client,
we
have
an
open
issue
on
buffering,
which
seems
to
happened
in
the
mixer
filter
and
it'll
prematurely.
Cutoff
requests
over
a
certain
size
I
can
attach
in
the
issue
here
it's
actually
on
the
envoy
repo,
but
they're,
saying
it's
potentially
a
buffering
problem
in
the
mixer
that
we
have
not
sure
if
anyone
on
the
call
is
familiar
with
this
or
if
I
should
take
it
somewhere
else.
Well,.
F
There's
a
specific
setting
per
connection
buffer
limit,
bytes
and
so
much
trying
to
post
like
a
one
mega
byte
file
against
I
think
it
was
just
a
demo
app
or
something
and
they
notice
they
got
a
413
air
and
on
the
envoy
side,
they're
saying
most
likely
it.
This
should
not
happen
because
you
just
be
expected
or
accepting
streaming
and
we're
not
going
to
do
anything
to
cut
that
off.
D
D
A
F
B
F
That
that
one
has
been
open
just
recently,
but
we
have
one
in
the
sto
repository.
That
was
the
original
thing
and
I
think
it
doesn't
open.
Maybe
close
to
a
month
ago.
I
could
post
that
in
here
as
well,
yeah.
B
A
Let's
start
there
from
the
face
of
it:
I
just
can't
it,
it
just
doesn't
appear
to
be
magic
here.
No,
it's
almost
as
though
we
need
to
let
the
data
flow
through
and
then
cut
it
if
we
found
if
the
check
comes
back
with
false
who's
there,
okay
close
the
connection,
otherwise
you
you'll
always
end
up
with
Giants
and
buffering
problems.