►
From YouTube: Combine WG Meeting 2022/03/09
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
Or
define
an
authorization
policy,
then
we
would
like
to
have
a
way
to
check
that
this
request
is
coming
from
an
application
owner
and
not
from
let's
say,
cluster
administrator,
who
might
not
be
authorized
to
make
this
change
to
the
application
and
the
way
we're
thinking
to
go
about.
This
was
by
doing
three
things.
First
of
all,
basically
define
a
verifiable
configuration
so
saying
this
is
the
set
of
settings
that
must
be
signed
in
order
for
them
to
be
applied
to
the
sidecar
containers.
A
For
instance,
we
can
say
all
the
mirroring
policies
must
be
signed
or
all
the
authorization
policies
must
be
signed.
The
the
the
second
thing
was
to
have
basically
a
configuration
generation
tool
that
in
in
our
we,
we
just
tried
to
implement
as
a
prototype
and
basically
what
we
did.
A
We
took
like
the
istio
testing
framework
and
we
use
the
istio
libraries
to
basically
translate
the
content
of
the
crd
into
xds
api
messages
and
then
use
a
signing
service
such
as
cosign
to
basically
sign
the
contents
of
the
policies
that
we
are
interested
in,
for
instance,
in
here,
would
sign
this
field
for
for
a
traffic
mirroring
policy,
then
the
second
part
of
the
approach,
the
way
we're
thinking
to
go
about.
A
It
is
once
we
add
these
signatures
to
the
crds,
then
we
need
to
have
an
enhancement
in
the
easter
control
plane
to
basically
propagate
these
signatures
so
that
they
are
received
by
the
by
the
sidecar
proxies.
A
And
finally,
the
final
block
is
to
have
a
filter
in
the
sidecar
containers
where,
upon
receiving
this
configuration
settings
so
they're
receiving
here
the
xds
api
resources.
A
A
However,
if
this
configuration
doesn't
follow
the
doesn't
pass
the
signature
verification,
then
we
we
could
potentially
drop
it
and
not
apply
it
to
the
to
the
configuration
of
the
sidecar
proxies,
and
these
are.
These
are
basically
the
the
the
three
components
that
we're
thinking
as
a
potential
design
for
verifying
these
policies.
B
Yeah
thanks
thanks
for
sharing,
I
have
a
couple
questions.
I'm
a
bit
confused.
How
I
I
guess
how
this
all
actually
works,
because
it
seems
like
I
don't
understand
how
you
can
not
trust
the
control
plane
because
you
may
say
like
yes,
I
applied
this
our
back
policy
and
then
it
sends
me
an
our
back
policy
and
I'm
gonna
verify
it's
what
I
wanted.
B
But
how
do
you
know
the
control
plane
didn't
just
put
that
our
back
policy
in
some
filter
that's
never
executed
or
that
it
didn't
add
a
rule
in
front
of
it.
That
says
you
know
all
traffic
goes
here
like
unless
you're
verifying
the
entirety
of
the
config,
it
seems
like
it
doesn't
matter
if
you're
verifying
a
small
subset,
because
the
control
plane
can
already
do
whatever
it
wants
and
if
you're,
if
you're
signing
the
entire
config,
then
why
have
the
control
plan?
Why
not?
B
Just
you
already
know
what
the
config
is
going
to
be
so
just
use
that
right.
So
it
seems
problematic
to
me
like
we're
putting
a
lock
on
the
door,
but
our
windows
wide
open,
basically.
A
A
B
Now
I
send
the
message
to
the
sidecar
and
it
says
I
found
the
policy
I
wanted
great.
This
config
is
sound.
I'm
going
to
reject
all
post
requests
like
I
wanted,
but
in
reality
you're
not
actually
rejecting
any
post
request
requests.
That's
just
dead
code
right.
How
do
we
prevent
that.
A
A
B
Yeah
I
mean
you
can't
just
look
at
xgs
in
in
isolation.
You
can't
look
at
just
one
piece
and
say
like
oh,
yes,
this
piece
is
fine.
It
was
the
one
I
signed
because
xds
is
so
powerful.
You
can
do
almost
anything
with
it
and
there's
a
hundred
different
ways
to
do
it.
It's
like,
if
you
were
looking
at
like
signing,
go
code,
and
you
say
this
must
have
a
function
like
that.
I
defined
here
and
then
the
user
is
like.
B
Okay
I'll
go,
write
this
function
here,
I'll,
never
call
that
function,
though,
and
I'm
just
going
to
write
whatever
I
want
and
it's
go
so
I
can
you
know
it's
touring
complete.
I
can
write
literally
anything.
The
same
applies
to
envoy.
It
can
do
literally
anything,
so
it
doesn't
seem
reasonable
that
you
could
possibly
not
trust
the
control
plane.
C
B
C
Under
camera,
it's
a
it's,
it's
a
partial
trust
model
right.
You!
You
want
the
control
plane
to
be
sending
you
some
updates
like
the
new
ip
addresses
of
pods
when
they
restart,
maybe
some
other
xds's.
You
don't
want,
and
maybe
some
xds
types
you
want
them
to
be
signed.
So
they're
only
accepted
if
they
have
certain
types
now,
there's
some
xts
types
that
are
sort
of
constructed
by
the
control,
plane
and
merged
with
other
things.
You
can't
really
sign,
but
others
are
passed
right
down
and
that's
where
constantine's
work
does
well.
C
B
B
Like
sure
I
signed
the
mirror
policies,
that's
great,
but
I've
also
hijacked
all
your
traffic.
I
don't
see
how
like,
why
do
you
have
an
untrusted
control
plane?
Do
you
not
trust
the
kubernetes
api
server
either?
It
seems
that.
B
A
The
the
reason
is
because
we
have
so
if
we
have
an
let's
say
on
a
on
premises,
cloud
deployment
and
then
you
know
we
have.
Then
the
the
the
cluster
is
running
on
an
application
owner
infrastructure,
but
then
it
might
be
installed
and
managed
by
a
third
party.
It
might
be
installed
and
managed
by
by
basically
by
a
cluster
administrator
who
might
not
be
the
same
person
as
the
application
owner.
And
then
you
have.
A
You
know
you
have
some
kind
of
a
trust
that
needs
to
exist
there
between
the
cluster
administrator
and
the
application
owner.
And
that's
something
that
you
know
normally
is
a
big
impediment
to
deploying
applications,
because
it's
very
hard
for
an
application
owner
to
trust
a
third-party
administrator
and
believe
that
they
will
not
try
to
get
their
data.
Or
you
know.
B
I
don't
get
how
you
can
not
trust
the
platform
like
you're
running
on
a
kubernetes
cluster
right
that
cluster.
They
can
do
literally
anything
they
could
swap
out
your
images.
They
can
read
all
your
files
in
the
image
they
can
enter.
The
process
like
keyboard
is
root
on
the
node
right,
so
you
have
to.
C
C
There's
a
secure
boot
up,
it
runs
in
a
virtual
machine,
so
people
are
using
this
thing
with
these
kata
containers
to
keep
their
kubernetes
from
being
fully
trusted.
So
the
kubernetes
administrator
itself
can't
look
at
a
computation
that
it
doesn't
want
to
be
output
and
we're
trying
to
extend
that
partially
into
the
mesh.
So.
B
B
C
You
you,
but,
but
so
we
have
istio
doing
mtls,
so
you
can't
totally
send
your
traffic
somewhere
that
doesn't,
you
know,
have
the
matching
mtls
and
what
we're
doing
is
we're
locking
down
that
even
more
we're
saying.
Well,
you
know
we're
we're
not
going
to
trust
these
any
of
these
particular
types
or
particular
field
values
in
other
xds
types.
C
It's
not
it's
not
perfect.
In
that
you
know
you
could
send
to
a
different
mtls
pod
than
the
one
you
expected,
but
it's
providing
more
security,
yeah.
B
I
I
see,
I
understand
your
point,
but
I
don't
agree
in
my
opinion
is
that
this
is
adding
an
extraordinary
amount
of
complexity
and
it
doesn't
actually
solve
any.
It
gives
you
one
percent,
more
trust
and
it's
either
all
or
nothing
untrust
in
my
opinion,
and
so
I
don't
think
that
this
is
I
I
don't
see
this
as
a
good
idea
is
my
opinion,
but
I've
been
talking
for
a
long
time
so
I'll,
let
others
talk.
B
So
how
would
this
my
recommendation?
Sorry
again,
my
recommendation
is:
if
you
want
this,
then
just
have
the
have
something
trusted
generate
the
xds.
Don't
use
the
echo
control
plane.
If
you
want
to
trust
your
xds
and
only
the
application
for
us
itself,
then
the
application
must
generate
its
own
xds
go
ahead
mitch.
E
I'm
just
curious
how
this
would
differ
from
solving
the
problem,
using
our
back
so
in
the
in
the
situation
where
you
have
an
application
developer
and
then
a
third-party
cluster
administrator,
and
they
don't
have
trust
between
them.
Usually,
the
way
that
you
would
solve
that
is
in
kubernetes
are
back
setting
the
sorts
of
objects
that
the
application
administrator
can
set
versus
the
sorts
of
objects
that
the
cluster
admin
can
set.
C
C
C
So
the
idea
is,
if
we
put
our
security,
not
in
the
control
plane
which
the
cloud
vendor
provides,
but
in
the
sidecar
the
agent
sidecar,
we
can
run
our
own,
build
of
just
that
so
constantine's
whole
implementation,
or
most
of
it
is
this
filter
that
runs
in
the
sidecar
that
checks
for
the
signatures
that
are
being
provided
earlier.
So
you,
the
complexity,
is
mostly
mental.
It's
you
know.
I
have
to
do
these
things.
The
I
can.
C
E
Okay,
so
then,
how
does
the
sidecar
verify
the
signature
like?
If
I
sign
a
virtual
service,
you
can
run
a
checksum
against
that
virtual
service
and
see
that
my
key
signed
the
virtual
service,
but
once
that
virtual
service
is
translated
into
say,
15
different
xds
configs.
How
do
we
verify
the
signature
on
those
xds?
Configs
came
from
that
virtual
service.
A
So
basically,
we
are
using
this
configuration
sign
tool
that
replaced
the
the
conversion
of
the
crd
into
xds
api
messages.
A
So,
given
a
crd,
we
are
saying:
okay,
if
we
run,
if
we
instantiate
an
xds
server,
a
fake
sds
server
or
a
test
xds
server,
then
it
will
generate
this
xds
api
resources
and
then
we
take
those
and
we
sign
their
content,
and
this
is
how
we
we
translate
between
the
crd
and
the
xds
api
messages
that
are
being
then
signed
and
verified
at
the
sidecars.
C
So
john
you're,
the
most
critical
about
this,
we
really
do
want
to
get
the
ability
to
run
computations
where
your
own
cloud
vendor.
Doesn't.
Let
you
see
it.
Is
there
any
advice
you
have
for
constantine
on
the
direction
he
should
go
on
this
work?
That
would
be,
in
your
opinion,
more
beneficial
to
the
goal
that
we
have.
B
The
only
path
that
I
see
forward
is
to
generate
the
xds
config
in
your
trust
domain.
So
if
you
only
trust
yourself,
your
own
app
container
then
generate
it
there
and
it
seems
like
you're
already
doing
that,
because
you
already
take
the
virtual
service
and
then
you
generate
xds,
and
then
you
sign
that
xds.
B
B
Or
if
you
really
want,
then
go
ask
easter
just
for
the
ips
and
then
locally
generate
all
the
xds,
but
I
don't
think
that
any
of
this
stuff
needs
to
be
like.
I
don't
think
the
use
case
of
I
don't
trust.
Istio
control
plane
is
something
that
is
applicable
to
a
wider
audience
and
I
feel
like
this
should
be
like
a
custom
thing
where
you
go
generate
all
your
own
xds
as
your
own
app
control
plane,
and
maybe
it
does
fetch
endpoints
from
east
geo.
It
seems
very
odd
to
me,
but
it
can
do
that.
B
E
I
know
that
louis
was
working
on
a
model
where
one
sidecar
could
pull
xds
from
multiple
control
planes
and
effectively
merge
that
config,
and
I
can
imagine
a
model
where
you
could
say
this
control
plane
is
the
trusted
control
plane.
Here's
these
sensitive
types
that
I
can
only
take
from
this
one,
this
other
control
plane
is
the
untrusted
control
plane,
I'll,
take
less
severe
or
less
sensitive
types
like
endpoint
slices
from
this
one.
B
There's
nothing
native,
but
you
can
all
obviously
go
write,
a
custom
thing
that
goes
and
fetches
xds
from
one
place:
fetches
it
from
the
other
place
and
merges
them
right.
But
there's
no
existing
thing
that
does
that
today.
C
B
Yeah,
that's
basically
what
I
was
suggesting.
The
one
downside
I
would
say
is
that
that
eastv
needs
to
have
privilege
to
read
all
the
config
from
kubernetes,
which
may
be
problematic,
so
you
may,
like
you
need
to
figure
out
how
your
local
xgs
control
plane
gets.
B
It
gets
its
config,
assuming
it's
not
all
static,
but
there's
various
ways
to
do
that
right.
You
could
run
another
e2d
that
it
fetches
from
you
could
give
it
our
back
permission
to
read
from
kubernetes.
There's
there's
a
lot
of
options,
but
yeah
that
sounds
very
reasonable
to
me.
I
actually
have
a
example
that
I
set
up
a
few
versions
back,
but
I
think
it
mostly
applies
of
doing
that
for
a
gateway.
It
wasn't
for
trust
reasons.
G
Hey
guys,
I
joined
a
little
bit
late,
so
I
just
want
to
understand
what
the
the
thing
we
are
discussing
here
so
looks
like
there
is
a
configuration
signing
tool
that
is
assigned
in
the
crds
and
the
translator
cit
into
xds.
Now,
how
do
you
validate
the
signature
on
the
data
plane.
G
Is
after
you,
after
the
site
card,
gets
the
signed
configuration?
How
do
you
verify
it?
A
G
Okay-
and
you
put
the
signature
in
the
in
the
xds
message
sent
to
the
proxy-
is
that
how
you're
doing
that.
A
So
if
you're
thinking
to
have
the
signature
in
the
crd,
to
put
it
under
metadata
annotations
and
then
would
have
a
change
in
the
istio
control
plane,
so
basically
to
take
the
the
signature
from
the
crd
and
add
it
to
the
xds
api
resource
and
then
it
it
gets
propagated.
Together
with
the
xds
api
resource.
G
Okay
and-
and
you
want
to
do
that
because
yeah
I
I
believe
all
the
traffic
is
already
mts
right
between
the
control
plane,
the
data
plane
and
you
want
to
add
the
additional
signature.
A
Basically,
the
reason
why
originally
we
wanted
to
do
it
is
because
there
are
cases
where
the
owner
of
an
application
is
deploying
their
application
on
a
third-party
cluster
and
they
don't
necessarily
trust
the
cluster
administrator
that
they'll
not
try
to
to.
You
know
to
define
some
policy
that
they
don't
intend
them
to
do
so.
That's
fine!
I.
G
I
see
so
they
don't
trust
the
cluster
itself,
but
okay
and
they
signed
using.
Basically,
the
signing
choice
is
controlled
in
a
more
like
a
better
secure
place.
Yeah
like
the
private
keys.
A
B
H
A
B
Okay,
jerome,
or
are
you
here.
F
Yeah,
I'm
here
hey
everyone.
This
is
shiram
from
intuit
and
I
have
anil
with
me.
He's
also
come
into
it.
So
just
wanted
to
talk
about
one
of
the
I
like
an
issue
or
kind
of
like
a
recommendation
or
whatever.
So
I
think
during
the
last
release
there
was
a
feature
that
we
implemented
it
kind
of
extended
enabling
tls
on
site
car
proxy.
F
Yeah,
I
hope
you
can
see
my
screen
yeah.
So
in
order
to
do
that,
we
kind
of
extended
the
sidecar
api
sidecar
apis
istio
ingress
listener
to
include
the
tls
configuration.
F
After
adding
this,
we
were
able
to
perform
both
one-way,
tls
and
mtls
from
outside
the
mesh,
and
so
this
was
working.
But
then,
while
we
were
implementing
this,
things
came
up
like
what
how
this
would
interact
with
peer
authentication
set
either
on
name
space
level
or
on
the
on
a
mesh
level.
So
I
think
we
talked
to
john
about
it
during
the
implementation
and
during
our
conversation
I
think
we
kind
of
decided
that
for
our
first
iteration
we
could
we
would
need
a
appear
authentication.
F
Config
that
would
set
on
the
app
itself
would
have
to
disable
peer
authentication
on
the
port
that
we
are
allowing
tls
on
so
reason
was,
we
would
want
we
wanted.
We
did
not
want
plain
text,
because
I
think
the
the
default
authentication
is
permissive,
so
we
did.
But
when
we
have
tls
set
on
the
sidecar,
we
did
not
want
any
plain
text
traffic
to
be
allowed
so
yeah.
F
So
in
that
case
we
kind
of
use
disconfig
to
disable
it
on
the
port,
but
then,
after
the
implementation,
we
kind
of-
I
think,
facilia
also
brought
this
up,
because
they
also
wanted
to
use
this
feature.
To
do
mtls
from
outside
the
mesh,
adding
this
additional
config
of
peer
authentication
kind
of
adds
like
a
little
bit
of
confusion,
because
first,
it
says
disable
which
is
more,
which
isn't
at
all.
F
This
is
not
all
intuitive
as
to
what's
happening
and
adding
additional
configuration
kind
of
increases,
the
complexity.
So
we
want
to
reduce
this
complexity.
Remove
your
authentication,
I
think,
when
I
created
this
issue
here.
Actually
there
was
a
lot
of
good
feedback
coming
from.
I
think
I
don't
know
how
to
pronounce
just
the
gentleman's
name
here
but
and
john's
feedback
as
well.
I
think
we
also
suggested,
I
think,
provided
three
different
solutions.
F
One
was
to
ignore
peer
authentication.
If
tls
is
set
on
the
sidecar,
we
would
take
tls
as
the
the
tls
on
the
side
card
configuration
takes
precedence
and
ignores
the
peer
authentication.
That
was
a
solution
one.
I
think
john
mentioned
that
the
solution
would
not
work
with
because
there
are
different
personas
working
on
on
it,
so
that
would
not
work.
Then.
F
I
think
the
second
solution
was
to
add
another
mode
kind
of
like
external
tls,
but
that
doesn't
help
much
because
it
still
requires
us
to
configure
appear
additional,
like
a
configuration
of
peer
authentication
here
and
the
solution
three
was
to
move
the
tls
setting,
which
is
currently
on
the
sidecar
is
during
this
listener,
move
that
to
pure
authentication
itself.
F
So
this
keeps
it
in
one
place
and
then
we
don't
need
an
additional
configuration.
So
that's
so
that
was
the
three
solutions
here,
so
I
just
wanted
to
bring
that
up
and
share
it
with
a
larger
audience
here,
so
that
we
can
like
discuss
and
see
where,
if
we
can
come
up
with
like
a
consensus,
open
solution
or
we
can
or
come
up
with
a
solution
here,.
B
My
one
feedback
would
be
that
I
think
the
option
after
which
option
was
sorry,
but
that,
like
a
lot
of
things,
look
at
pure
authentication,
both
in
istio
as
well
as
external
tools,
and
so
if
we
do
the
one
that,
like
kind
of
overrides
pure
authentication,
I
would
be
a
bit
concerned
about
that,
because
we
may
break
those
tools
and
or
that
code.
B
Yeah,
I
don't
know
it
seems
okay,
it
feels
like
I
should
be
able
to
come
up
with
the
reason
it's
a
bad
idea,
but
I
can't
so
I
don't
know
lehman.
Do
you
have
any
issues
with
that?
I
mean
it
is
kind
of
weird
that
the
field's
called
poor
level
mtls
and
then
it's
not
fcls.
G
Yeah
sorry,
I'm
still
trying
to
catch
up.
So
the
proposal
is
to
add
one
field
to
the.
F
The
proposed
proposal
is
to
add
tls
configuration
to
peer
authentication,
basically,
right
now,
the
config
is
inside
the
istio
english
listener
inside
the
sidecar
api.
So
the
proposal
is
to
move
this
to
the
peer
authentication
itself,
so
that
we
don't
have
to
configure
these
this
in
two
different
places.
B
D
F
Okay,
so
there's
a
this
issue
is
still
open.
So
if
you,
if
you
folks,
have
any
other
feedback
or
any
concerns
with
this
solution
of
moving
it
to
peer
authentication,
please
feel
free
to
add
it.
I
wanna,
I
think
they're
only
20
minutes
left.
So
I
don't
want
to
take
any
more
time.
B
B
All
right
up:
next,
we
have
auto
sni.
J
Hi,
I
also
won't
take
much
time
because
there
are
more
items
left
in
the
agenda,
so
I
have
created
this
rfp
for
auto
sni
and
autosan
validation
in
destination
rule.
I
think
john
has
already
started
reviewing
the
rfc
and
it's
a
very
simple
one,
so
I
would
request
everybody
else
to
do.
J
An
offline
review
no
need
to
present
it
for
right
now,
because
it's
quite
simple,
I
think
the
use
case
already
had
interest
in
the
community,
because
I
already
see
an
api
pr
for
the
same,
which
was
done
like
an
year
ago,
but
there
was
no
activity
on
it
afterwards.
So
I
would
like
to
resume
the
task
from
wherever
it
was
left
and
take
it
to
completion.
B
K
Okay,
let
me
see
if
I
can
present.
K
All
right,
great
yeah,
so
this
is
a
proposal
related
to
the
telemetry
api
for
those
of
you
that
are
somewhat
familiar
or
maybe
not
familiar
at
all,
with
telemetry
api.
There
are
really
two
parts
right,
so
there's
the
configuration
of
telemetry
behavior
and
then
there's
a
reference
to
a
provider
and
right
now,
all
that
provider
config
is
defined
in
the
mesh
config
itself.
K
In
this
extension
providers
section
and
so
we've
had
a
number
of
requests
to
improve
the
user
experience
around
extension
providers,
and
so
this
proposal
is
a
proposal
to
deal
with
those
requests
in
a
way,
that's
extensible
and
doesn't
really
change
much
about
the
the
setup
that
the
breakdown
between
extension
providers
and
telemetry
api.
K
It's
really
we
want
to
expand
the
provider
ref
message:
the
schema
there
to
support
the
ability
to
reference
custom
resources
as
well
as
services
directly
and
then
there's
a
third
sort
of
separable
proposal,
which
is
that
if
you,
if
we
have
that
support
introducing
a
custom
resource
for
like
stream
based
access
logging,
so
that
you
can
configure
different
access
logging
parameters
without
having
to
change
mesh
config.
K
And
so
I
have
a
couple
use
cases
in
here
of
what
this
might
look
like,
that
we
can
go
through
if
there
are
questions.
K
So
this
is
this
one
right
here
is:
if
you
wanted
to
change
the
format
of
your
local
access
log,
you
could
create,
in
in
your
name
space
a
local
access
log
configuration
and
then
point
to
it
in
your
in
a
telemetry,
telemetry
resource
and
say:
okay
for
anything
that
has
a
response
code
greater
than
500
log
it
in
this
fashion,
for
the
direct
services
one,
you
know
what
we
need
is
a
type
and
then
this
uses
sort
of
the
backend
object
reference
from
the
gateway
api
schema
for
for
selecting
that
service,
so
you
could
say
for
tracing.
K
I
just
want
to
use
this
this
yeager
instance
here
based
on
the
service
definition
and
point
at
it.
So
that's
really.
The
extent
of
this
proposal
is
just
to
see
if
what
people
feel
like
in
terms
of
is
this
something
that's
worth
pursuing,
and
then
you
know
we
can
figure
out
the
the
sort
of
naming
and
details
on
that
later.
K
K
Well,
by
not
defining
all
the
crds
ourself
right,
so
I
think
we
would
start
with
maybe
just
the
file
access
log
one
and
then
say
you
can
point
at
services,
which
is
mostly
what
those
extension
providers
are
right:
they're,
they're,
really
just
names
and
services
with
very
little
extra
config,
and
then
we
say
if,
if
other
or
you
know,
other
open
source
projects
create
their
own
custom
resources,
we
can
slowly
add
support
for
pointing
at
those
if
you're
already
using
them.
K
B
K
Yes,
but
I
think
we
can
say
that
the
way
to
do
that
for
the
short
term,
is
you
point
at
the
service
for
them
and
that's
that's
the
extent
of
the
configuration
we
support
and
if
you
want,
if
you,
if
you
need
provider
specific
config
that
isn't
that
service
and
things
that
are
available
from
istio
apis
that
impact
calling
services,
then
that
should
be
done
it
then
we
don't
you,
then
you
have
to
use
mesh
configure,
we
don't
support.
It
would
be
my.
B
That's
yeah,
I
I
get
what
you're
saying
it
seems
a
bit
concerning
to
me
because
one
that
means
that
we
have
to
support
mesh
config
indefinitely
and
we
have
two
ways
to
configure
the
same
thing
and
if
we
don't
do
that,
then
we'd
lose
config
until
these
third-party
things
provide
their
own
crds.
B
K
All
those
other
things
looking
at
the
tracing
ones,
so
this
doesn't
cover
xlrc
right.
This
is
this
is
not.
This
is
not
for
authorization
policy
and
I
think
it
would
be
nice
if
they
had
a
similar
one
and
I'd
be
curious
what
their
policy
is,
but
for
telemetry
the
tracing
ones
we
can.
I
just
looked.
We
can
promote
max
tag
length
and
then
it's
the
access
tokens
is
basically
the
only
other
thing
that
the
tracing
providers
use
logging.
K
I
think
we
we
can
move
some
of
that
format,
stuff
up
and
use,
maybe
one
or
two
crds.
There
is
already
logging
crds
that
have
been
defined
by
other
mesh
projects
and
we
can
think
about
supporting
those
instead
of
defining
our
own
and
then
metrics.
There
isn't
anything
that
really
needs
configuration
in
that
way
from
from
prometheus
or
stackdriver,
which
are
the
two
that
we
support
anyways
at
this
point.
B
K
I
mean
that's,
that's
fair
right,
we
could
yeah.
So
I
I
think
the
question
is,
you
know:
can
we
define
some
limited
set
like
a
couple
of
logging
ones
and
have
that
be
enough,
and
I
mean
I'm
would
love
to
hear
someone
saying
you
know
strongly
one
way
or
another
on
that
that
uses
some
of
the
other
integrations
I
mean
putting
it
in
mesh.
Config
is
not
ideal
for
a
lot
of
reasons,
one.
K
It
makes
it
somewhat
inflexible
in
the
sense
that
we
have
to
you
know
you
have
to
have
access
to
mesh
config
which
people
might
not
have
access
to
and
having
some
extensible
way
around.
That
would
be
nice.
I
don't
you
know,
I
thought
there
were
lots
of
different
ways.
This
is
the
one
that
is
currently
what
I'm
favoring,
but
I'm
open
to
other
suggestions
or
other
approaches.
K
K
Yeah
we
had,
I
mean
in
some
sense
that
service
service
reference
with
a
type
is
sort
of
doing
that.
It's
just
saying
that
you
know,
because
you
could
then
maybe
even
add
another
field,
which
is
some
sort
of
structure.
Structured.
Config
of
you
know
types
config
sort
of
like
the
envelope
style.
So
maybe
this
is
the
gateway
drug.
To
that
I
I
don't.
K
Yeah
I
I
guess
I
would
like
other
opinions
on
that,
so
that
I
don't
feel
like
I'm,
where
I'm
operating
in
a
vacuum
there.
So.
K
I
B
K
Okay,
well,
it
doesn't
sound
like
we're
getting
any
extra
feedback
here
so
I'll
defer
to
whatever
the
next
topic
is.
B
That
would
be
john
okay,
yeah
I'll
think
about
it,
some
more
doug
and
we
can
talk.
I
may
just
be
in
a
a
no
mood
today.
B
B
B
Okay,
so
for
some
background,
external
name
service
looks
something
like
this.
This
is
a
kubernetes
thing,
so
you
say
that
my
service,
which
is
named
here
be
external,
is
actually
for
this
external
name,
which
is
some
other
hostname.
B
This
could
also
be
something
like
google.com,
and
what
this
would
all
you
do
is
to
say
something
like
curl
b
x
and
it
would
actually
go
to
this
address,
which
could
be
google.com
or
something
else,
so
it
kind
of
allows
for
like
legacy
migrations,
like
you
know,
maybe
you
can
make
a
dv
external
name
service
and
it
points
to
some
aws
instance.
B
So
the
problem
is
that
we
implement
this
totally
wrong
basically,
and
that
causes
a
lot
of
problems.
If
there's
there's
been
a
number
of
issues
reported,
I
tried
to
list
them
all
here.
You
can
see
it's
quite
large.
B
Some
of
them
are
quite
bad,
like
breaks
outgoing
https
connections,
incorrect
config,
hijacks,
all
traffic
on
the
port,
so
there's
a
lot
of
issues
and
kind
of
the
root
cause.
Is
that
the
way
that
kubernetes
influences
is
completely
different
than
what
we
do
so
crew
in
kubernetes?
This
literally
just
creates
a
cname
record
in
the
dns.
That's
all
it
does.
Por
does
not
use
it
all.
Nothing
else
changes.
B
As
part
of
that
you
know
we
do
this
matching
on
host
header
sni
report
for
tcp,
and
what
ends
up
happening
is
that
you
get
totally
different
behavior
when
you
use
e-steel,
so
my
goal
here
is
kind
of
to
make
it
so
that
with
and
without
istio
you
get
the
same
behavior
and
the
istio
behavioral
changes
are
only
for
things
that
are
intentional
and
actually
improve
the
user
experience,
not
just
because
we
happen
to
implement
it
differently.
B
So
my
proposal
is
to
kind
of
change
our
implementation
to
much
more
closely
match
kubernetes
and
how
that
would
work.
Is
we
essentially
treat
these
like
aliases?
So
we
don't
control
dns,
but
what
we
would
do
is
quite
similar
in
that
anywhere
that
we
would
have
matched
the
other
service.
So
in
this
example
anywhere
that
we
would
have
matched
be
whether
this
is
a
host
header
or
sni,
we
will
also
match
the
alias
for
it.
B
B
Now
there
are
kind
of
three
caveats
to
that.
One
is
obviously
this
is
behavioral
change,
so
we'll
need
to
handle.
You
know
roll
out
and
breaking
change
migration
docs
all
that
stuff,
but
the
other
two
are
kind
of
more
fundamental
is.
B
If
we
do
this
aliasing,
then
we
no
longer
have
like
this
external
name
service
as
its
own
independent
thing
that
can
be
referenced
and
configured
differently.
So
I
can't
say
like
for
yeah
like
in
this
example
for
google.com
use
five
retries,
but
for
google,
the
external
name,
alias
use,
10,
retries
or
whatever,
or
a
different
destination
row
config,
or
something
like
that
so
like
these
are
truly
now
the
same
thing
I
I
think
that's
probably
fine,
but
that
is.
B
That
is
one
caveat,
and
one
of
the
reasons
I
think
it's
fine
is
that
largely
our
intent
with
support
for
external
name
is
to
support
people
that
are
taking
an
existing,
e-studio
or
kubernetes
cluster,
and
then
they
just
use,
they
just
add
easter
to
it,
and
so
I
think
we
should
prioritize
maintaining
the
existing
behavior
and
if
people
want
to
do,
you
know
custom
config
for
these
services,
they
can
use
service
entry,
which
already
does
it
and
so
they're
still
unable
to
do
it.
B
The
other
issue
is
that
if
you
actually
do
like
explicitly
forward
to
this
google
service
as
part
of
like
a
virtual
service,
especially
at
like
a
gateway
or
something
like,
we
don't
have
a
cluster
for
for
google,
and
so
we
might
have
a
cluster
for
the
referred
service
google.com
if
they
defined
a
service
entry,
at
which
point
we
would
just
kind
of
resolve
that
alias
and
forward
it
there.
But
if
there
was
no
service
entry
for
google.com,
then
this
would
no
longer
work
when
it
previously
did.
B
So.
I
tried
to
look
at
what
other
ingress
implementations
do
for
external
name
like
referring
to
his
external
name,
and
it's
very,
very,
very
murky.
I
could
not
find
two
implementations
that
did
the
same
thing.
Some
of
them
just
don't
work
at
all.
Some
of
them
do
dns
resolution
and
send
there
some
of
them
have
flags
to
do
different
things.
So
there's
not
really
any
standard.
B
Yeah,
that's
that's
basically
it.
I
talked
a
long
time
and
I
don't
know
if
it
made
any
sense
so
feel
free
to
ask
me
any
questions.
Does
this
seem
like
something
that's
desirable
worth
pursuing.
L
Oh
sorry,
I'll
take
a
look
at
this.
None
of
our
users
actually
use
external
name
in
this
capacity
like
we
don't
recommend
it,
because
it's
but
yeah
I
mean
I'm,
I'm
okay,
at
least
like
on
the
surface
of
you
know
us
making
it
better
so
so
so
I
think
that's
kind
of
how
we
should
operate
anyway,
right
so
external
name.
I
know
it
kind
of
has
some
like
hacks
within
the
code
anyway.
So.
B
Like
if
you're
using
istio,
already
you're,
probably
not
using
external
name,
because
it's
totally
broken,
and
so
we
won't
impact
many
easter
users
and
if
you're
not
using
istio,
then
you
adopt
istio
if
you're
using
a
strong
name,
you'll
probably
be
broken,
because
it's
broken
in
easter
today.
So
this
seems
like
for
the
vast
majority
of
users.
It
would
be
beneficial
output.
B
Okay,
cool,
we
don't
have
time
to
discuss
the
other
one,
but
last
week
I
had
a
broader
proposal
that
was
similar
in
goal
of
make
things
behave
more
like
kubernetes,
but
still,
you
know,
add
benefits
of
easter,
obviously,
but
kind
of
holistically
doing
it
across
the
board
instead
of
just
like
stronger
name.
B
B
D
We
will
see
everybody
next
week
and
we'll
see
about
if
we'll
have
a
another
time
zone
meeting
as
well.
J
Oh
one
more
thing
I
wanted
to
say
I
was
not
able
to
access
the
last
week's
recording.
Can
somebody
help
me
to
understand
where
exactly
it
gets
uploaded.
D
I
think
mitch
fell
off
and
I
want
to
say:
mitch
was
the
one
who
recorded
it
last
week,
so
he
might
know
where
they
show
up.
Okay,
do
you
know
john
when
you,
when
you
click
record,
does
it
actually
get
sent
to
you
or
does
it
show
up
somewhere
and
we
just
have
to
move
it
to
youtube?
It
gets
sent
to
one
person.