►
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
Hello,
everyone
welcome
to
cloud
native
live
where
we
dive
into
the
code
behind
cloud
native.
I'm
annie
and
I
am
a
cncf
ambassador,
as
well
as
a
senior
product
marketing
manager
at
communda,
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
native
technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions
so
join
us
every
wednesday
to
watch
live
so
this
week
we
have
mate
david
here
to
talk
with
us
about
mutual
tls
or
communities
with
linkedin
and
a
few
other
exciting
announcements
from
the
cloud
native
sphere
is
the
cloud
native
survey.
2022
is
happening
as
we
speak,
so
remember
to
give
your
answers
and
provide
input
and
as
well.
A
If
you
are
attending
the
marketing
committee
meetings.
That
meeting
will
be
next
week
instead
of
this
week,
as
well
as,
if
you
are
looking
to
have
these
kind
of
great
events
happening
in
your
company
or
whatnot
q3
calendar
booking
for
cncf
events
has
kicked
off,
so
get
your
slot
now
and
as
always,
this
is
an
official
live
stream
of
the
cnc
and
as
such
it
is
subject
to
the
cncf
code
of
conduct.
A
B
All
right,
thank
you
very
much
and
welcome
everyone.
I'm
just
going
to
start
by
sharing
my
screen,
as
we
typically
do
with
these
presentations
cool,
so
yeah
welcome
to
mtls
on
kubernetes
with
linkerd
I'm
going
to
go
to
the
next
slide
in
just
a
second
right,
so
my
name
is
mate,
I'm
one
of
the
linkery
maintainers
and
I'm
also
a
software
engineer
at
buoyant.
I
also
do
not
look
like
in
a
picture
anymore,
but
it's
the
only
one
I
have
so
I'll
have
to
make
do
for
now.
B
I've
been
with
the
linguity
project
for
about
two
years
and
a
bit
now
I
actually
started
as
an
external
contributor
when
I
was
a
student
and
I
was
involved
as
a
mentee
through
a
cncs
community
bridge
program
and
yeah
been
around
the
project
for
a
long
time,
worked
on
a
lot
of
different
bits
and
pieces,
and
if
you
have
any
questions
after
this
presentation,
you
have
my
handles
right
here
on
the
slides
on
the
slide.
You
can
reach
me
on
twitter,
slack
or
github,
so
yeah
say
hi
or
if
you
have
any
questions.
B
Let
me
know
cool
so
today,
we'll
talk
about
mtls,
but
before
we
actually
get
into
what
mtls
is
and
covering
protocol
details,
I'm
just
going
to
give
a
brief
introduction
to
computer
security.
So
we'll
talk
a
little
bit
about
authentication
and
authorization
and
stuff
like
that.
We'll
move
on
and
cover
tls
as
a
protocol,
then
mtls
they're
super
similar
just
a
bit
of
a
spoiler
there
and
then
I'll
have
a
demo
with
how
you
can
get
mtls
out
of
the
box
with
linkedin.
B
So
super
simple,
I
usually
like
to
be
a
bit
more
theoretical,
but
I
think
for
the
purpose
of
this
presentation,
we're
gonna
see
more
of
a
demo
and
sniff
some
traffic
with
d-shark
and
just
yeah,
try
to
understand
what's
happening
there
and
how
we
can
verify
mtls
in
a
kubernetes
cluster
cool.
B
So
with
that
out
of
the
way,
I'm
pretty
much
ready
to
get
started
so,
like
I
said,
I
want
to
cover
some
computer
security
basics
first
and
I
think
if
we
talk
a
little
bit
about
authentication
and
authorization
and
what
those
words
actually
mean
and
how
they
sort
of
fit
in
the
computer
security
context.
B
It's
gonna
be
a
bit
more
evident
on
the
value
that
ntls
brings
and
and
why
we
need
mtls.
To
begin
with,
so
authentication
is
the
foundation
of
communication
security,
or
at
least
that's
what
I
like
to
say:
I'm
not
a
security
expert
by
the
way
by
any
means.
So
this
is
all
just
stuff
that
we're
sort
of
dealing
with
and
and
stuff
that
I've
been
learning
on
the
job
and
in
my
personal
time,
but
when
we
say
authentication,
we
pretty
much
mean
the
process
of
identifying
a
user
or
a
system
or
a
device.
B
So
it's
nothing
too
complex.
It
just
means
that
when
we
do
have
a
communication
channel,
we
just
want
to
make
sure
that
the
person
that
we
think
we
are
talking
to
is
the
person
that
we
actually
want
to
talk
to,
and
this
matters
in
computer
security,
because
oftentimes
people
think
that
you
know
once
you
have
encryption,
you
have
security
and
those
two
can
be
used
interchangeably
and
you
know
they're
synonyms,
but
that's
kind
of
far
from
truth,
at
least
in
communication
security.
B
So
when
we
talk
about
communication
security,
we
typically
want
to
have
more
than
just
encryption.
We
want
to
have
some
guarantees
placed
around
our
communication
channel
to
sort
of
give
us
this.
The
security
and
generally
security
experts
and
people
in
our
industry
like
to
use
a
simple
model
when
they
first
start
to
create
security
systems
or
when
they
first
start
to
put
security
into
place.
This
model
is
called
cia.
It's
the
cia
triad,
it's
a
kind
of
a
handy
mnemonic
to
sort
of
understand
it
and
to
sort
of
remember
it.
B
So
this
is
where
encryption
sort
of
shines
through
and
also
where
authentication
comes
into
play,
because,
first
of
all,
we
want
to
make
sure
that
our
data
is
encrypted
and
nobody
has
access
to
it.
But
we
also
want
to
make
sure
that
we
only
send
this
data
or
receive
data
from
the
device
or
the
person
that
we
want
to
communicate
with.
B
Data
also
needs
to
have
integrity,
so
you
don't
want
your
data
to
be
tampered
with
while
it's
in
flight,
you
know
you
send
some
bytes
over
the
wire.
It
would
be
a
bit
awkward
if
you
receive
some
other
bytes
and
it
doesn't
make
sense
and
availability
sort
of
speaks
for
itself.
Right,
like
you,
can
have
a
very
complex
and
secure
system.
A
B
Yeah,
I
can
share
a
link
to
the
slides,
no
problem
I'll.
Do
that
I'll
try
to
do
that
after
the
presentation,
but
we'll
see.
Maybe
I
can
do
it
while
I'm
presenting
speaking
and
typing
is
not
really.
My
strong
point,
though
so
we'll
have
to
see
how
it
goes.
But,
yes,
I'll
share
the
slides.
A
Perfect
and
the
recording
of
the
this
live
will
be
also
available
in
youtube
afterwards,
so
everyone
can
check
that
out
as
well.
B
Cool,
thank
you
very
much
for
the
question
all
right
anyway.
What
I
want
you
to
remember
from
the
slide
is
that
authentication
kind
of
falls
into
the
confidentiality
part
of
security
and
mtls
and
tls's
protocols
give
us
confidentiality
through
authentication
and
through
encryption
as
we'll
see
in
just
a
second,
but
before
we
go
to
the
tls
protocol,
there's
one
more
thing
that
I
want
to
cover
and
that's
authorization,
and
I
think
in
my
job.
B
B
Authorization,
on
the
other
hand,
is,
are
you
allowed
to
do
what
you
want
to
do,
and
obviously
that
requires
authentication
because
to
tell
a
device
what
it's
allowed
to
do?
You
first
need
to
identify
that
device
and
in
the
real
world,
authorization
comes
in
a
form
of
access,
control,
lists
or
policies
generally,
but
not
always
awesome,
so
we're
ready
to
start
digging
into
tls
as
a
protocol.
But
before
I
go
into
the
diagrams,
a
really
quick
example
of
how
tls
looks
like
in
the
real
world.
B
The
certificate
looked
at
the
key
material
sort
of,
and
it
knows
to
trust
it
because
it's
been
signed
by
another
certificate
or
or
an
authority
that
browsers
implicitly
trust
and
out
in
the
world.
I
think
there
are
like
seven
or
eight
such
authorities
and
they're
the
authorities
that
generally
issue
certificates
for
for
other
people
and
other
devices.
B
So
that's
why
your
browser
trusts
it.
It's
basically
bootstrap
the
trust,
whatever
certificate
signed,
google
certificate.
So
with
that
in
mind,
don't
worry
if
it
doesn't
make
sense,
yet
I'm
ready
to
to
go
into
the
belly
of
the
base
so
to
speak
so
over
here.
I
have
just
obviously
a
very
simple
diagram
that
kind
of
details:
what
happens
with
the
tls
protocol?
So
tls
stands
for
transport
layer,
security,
it's
a
connection,
oriented
security
protocol
and
it
runs
on
top
of
tcp.
B
Once
you
have
a
protocol
that
runs
on
top
of
tcp,
it
means
that
whatever
application
layer
protocol
you
use,
it
could
be
http
or
grpc
over
http,
which
I
guess
is
still
http.
You
can
still
use
it.
So
it's
pretty
much
protocol
agnostic.
If
you
think
about
it
that
way,
but
anyway,
I'm
I'm
digressing
in.
A
This
sorry
audience
question
or
again
already,
which
is
great
by
the
way,
there's
up
eastman,
who
asks
ssl
certificate
question
mark.
B
B
Nicole,
thank
you
for
the
question.
I'm
just
gonna
go
for
forward
now
so
yeah
anyway.
In
the
example
that
I
gave
with
the
browser
and
stuff
we
we
have
a
client
and
the
client
is
our
browser
and
we
connect
to
a
server
and
that's
google
and
what
happens
at
least
on
the
surface
level,
I'm
not
going
to
get
into
the
nitty
gritty
of
the
protocol
details,
but
at
a
surface
level
we
connect
to
the
server.
B
A
We
can
take
it
at
spots
if
you
want,
but
there's
a
they're,
not
asking,
can
we
use
self-signed
certificate
as
well
or
it
has
to
be
ta
science
certificate.
B
That
depends
on
the
system,
so
with
tls
you
would
probably
need
to
have
a
ca
stand
certificate,
but
with
linker
d,
for
example,
you
can
use
a
self-signed
c8
bootstrap
identity
in
your
cluster,
so
it
it
depends,
that's
the
answer.
I
know
it's
not
very
straightforward,
but
it
will
always
depend
on
what
workloads
you
have
and
what
sort
of
communication
you
have
going
on
cool.
Thank
you
very
much
for
the
question
and
yeah.
B
B
Tls
has
a
handshake
mechanism
in
the
same
vein
as
tcp's
handshake,
so
the
client
will
connect
to
the
server
it'll.
Give
it
a
client,
hello
and
it'll,
say:
okay,
server,
I'm
ready
to
negotiate
some
tls
here,
it'll
send
some
configuration
parameters
they'll
both
the
client
and
the
server
agree
on
the
configuration
and
then
the
server
will
reply
with
its
certificate
and
it
will
ask
the
client
okay.
Are
we?
Are
we
good?
Can
you
verify
me?
The
client
verifies
the
server.
B
They
both
agree
on
an
encryption
secret
and
after
that
you
pretty
much
have
established
secure
communication,
easy
peasy
when
you
just
talk
about
it,
but
anyway,
before
we
move
on
to
mtls
as
a
protocol,
just
going
to
give
you
some
some
quick,
nerd
facts
about
all
of
this
stuff,
so
tls,
like
I
said,
is
implemented
on
top
of
tcp.
B
B
You
know
they're
public,
but
I
do
see
a
lot
of
people
who
sometimes
send
me
manifest
to
look
at
or
they
send
me
some
repro
steps
and
the
public
keys
are
obfuscated
or
hidden.
I
just
want
you
to
know
it's
totally
fine
to
share
public
keys
and
certificates,
because
they're
public
and
with
that
being
said,
we're.
Finally
on
the
topic
of
mtls
and
two.
B
A
A
A
Yeah
perfect
yingdong
says
self
sign
needs
to
be
pre-configured
as
trusted,
since
it's
not
from
one
of
the
ca
fox
more
of
a
statement
than
a
question
about
any
thoughts
there.
B
B
So
with
linker
d,
for
example,
I
know
I'm
going
to
give
some
spoilers
here,
but
if
it
answers
the
question,
then
I
don't
really
mind
with
linkerid.
When
you
install
it,
you
generally
have
to
provide
a
root
ca.
We
call
it
a
trust
anchor
and
this
trust
anchor
can
be
self-signed.
We
actually
encourage
people
sometimes
to
have
it
still
signed.
B
So
it
does
not
need
to
be
signed
by
someone
else.
You
can
sign
it
by
your
enterprise
ca.
You
can
sign
it
yourself,
whatever
actually
works.
The
thing
is
because
this
sort
of
forms,
the
trust
group
and
it
bootstraps
the
whole
identity
for
linkery
for
linkerd.
It's
enough,
if
you
trust
it
so
generally,
with
self-signed
certificates
in
general,
if
you
bootstrap
your
identity
system
with
that
self-signed
certificate,
it's
enough
for
you
to
know
that
you
you
created
it
and
then
implicitly
everything
will
trust
it.
B
But
if
you
have
like
a
publicly
accessible
web
service
again
like
google
or
anything
else-
that's
that's
on
the
web,
then
I
think
generally,
it's
better
to
have
it
signed
by
one
of
the
major
folks
and
I'll
quickly.
Give
you
an
example
before
I
move
on,
but
if
you
have
ingress
termination
in
kubernetes,
for
example,
you
would
very
likely
expose
this
sort
of
ingress
point
to
a
broader
audience.
So
in
that
case
you
might
want
to
have
your
ca
signed
by
one
of
the
major
ca
folks.
A
B
Well,
it
depends
I'm
not
sure
in
kubernetes
exactly
what
version
the
api
server
uses.
I
would
have
to
check
the
docs
in
linkery.
I
think
we
use
tls
1.2
or
1.3
yeah,
that's
kind
of
the
answer,
and
should
we
take
a
few
more
now
or
move
on.
A
We
can
maybe
take
one
more
and
then
progress
the
presentation
a
bit
and
then
then
get
through
the
rest.
So
we.
B
B
It
depends
on
what
you
mean
by
that
you
can
definitely
have
a
chain
of
certificates
where
one
certificate
signs,
the
other,
then
signs
the
other
and
so
on.
Until
you
get
to
the
bottom
certificate,
that's
not
signed
by
anything,
but
you
cannot
have
two
cas
sign
the
same
certificate.
It
doesn't
really
work
like
that
in
a
sense
yeah.
B
I
hope
I
hope
these
answers
were
like
satisfactory
to
all
of
you
and
I
love
seeing
that
you're
also
enthusiastic
about
this.
It's
actually
really
great.
B
Yeah,
there's
more
exciting
material.
I
promise
you'll
have
more
questions.
At
least
I
hope
you
do
if
I've
done
my
job
right,
cool
anyway,
mtls
really
easy
to
understand
compared
to
tls,
because
it's
symmetric
authentication.
Suddenly
we
have
a
client,
we
have
a
server.
The
client
connects
to
the
server
they
negotiate,
all
of
those
tls
parameters
or
mtls
parameters.
We
should
say
the
client
authenticates,
the
server,
the
server
authenticates
the
client
and
then
the
communication
is
secure.
You
might
be
wondering,
well,
you
know,
how
does
this
help?
B
Is
this
more
helpful
than
just
doing
tls?
And
the
question
is
well
the
question
the
answer
is,
it
depends
basically,
you
would
use
tls
when
you
have
a
public
website
where
people
connect
and
you
actually
don't
care
about
the
identity
of
who
connects
to
you,
and
certainly
that
is
the
case
with
google.
B
Google
doesn't
really
care
what
browser
connects
to
it
or
where
you're
from
they
might
care,
but
not
you
know,
for
the
purpose
of
security,
but
if
you
have
an
api
gateway
or
an
api
service,
the
scenario
kind
of
changes,
because
once
you
have
an
api
that's
accessed
by
by
other
clients,
then
first
of
all,
you
want
to
authenticate
it
because
you
want
to
prevent
malicious
requests.
You
don't
want
just
anyone
to
hit
your
api
endpoint
and
get
data
off
of
it,
and
then
you
also
want
to
know
which
clients
connect
to
you.
B
So
you
can
do
a
bunch
of
cool
things,
such
as
rate
limiting
right
like.
If
you
don't
know
who
connects
to
you,
then
how
can
you
rate
limit
their
calls?
You
need
to
have
some
information
there,
and
this
is
where
mtls
shines
through,
because
it
allows
you
to
do
this
at
a
sort
of
platform
level
because
suddenly
and
I'm
moving
on
to
the
next
slide.
Now,
suddenly,
you
have
cryptographic
proof
of
both
the
client
and
the
server
identity.
B
So
mtls
is
exactly
like
tls,
but
it
has
these
extra
steps
where
you
perform
symmetric
authentication
of
both
parties.
This
gives
you
the
cryptographic
proof,
and
because
you
have
this
cryptographic
proof
you
can
do
really
cool
things
such
as
client
based
authorization
or
rate
limiting
or
anything
else.
That
crosses
your
mind
and
can
use
this
identity.
B
One
more
thing
about
mtls
in
general
is
that
for
cloud
native
environments,
it
allows
you
to
do
zero
trust,
and
this
is
sort
of
a
buzzword,
or
at
least
I've
noticed
it's
it's
becoming
a
buzzword.
So
what
I
mean
by
zero
trust
is
that
you
basically
do
not
trust
the
network.
You
implicitly
assume
everyone
on
the
network
is
out
to
get
you,
so
you
only
trust
everything
at
a
security
level,
not
a
platform
level.
B
In
this
way
when,
when
you
do
mtls,
you
can
get
true
workload
identity
because
you
have
very
clear
security
boundaries,
you're,
not
tied
to
the
network.
Topology
right,
you
don't
care
what
subnet
this
request
came
from
or
stuff
like
that
and
for
enforcement
is
granular
and
everything
happens
at
a
pod
level,
and
you
can
also
extend
it
to
arbitrary
cluster
topology.
So,
for
example,
if
you
have
two
or
three
clusters,
you
can
still
do
mtls.
B
B
Also,
you
have
a
mechanism
for
secret
loss
at
almost
any
level,
there's
a
bit
of
an
asterisk
there,
because
sometimes
you
can
get.
You
know
your
root
case,
private
key
lost
or
you
have
to
revoke
the
root
ca,
so
you
do
have
a
mechanism
for
secret
loss,
but
depending
on
what
level
this
happens
at
it
might
be
a
bit
painful
to
to
do
everything,
but
certainly
better
than
you
know,
having
people
access
your
data
when
they
shouldn't
access
your
data.
A
Yes,
there's
a
few
so
then
there
was
a
question
from
hardeep
other
than
identity
of
the
server
slash
client.
What
other
advantages
does
it
provide
over
just
having
the
https
server
serving
apis.
B
Okay,
other
than
identity.
What
other
advantages?
Well,
it
doesn't
really.
This
is
it's
a
tough
question
and
I'm
I'm
glad
you
kind
of
asked
it.
I'm
not
sure
I
fully
understand
it.
So
the
basic
thing
that
you
have
is
the
ability
to
look
at
the
client's
cryptographic
identity
so
other
than
that
it
doesn't
really
have
any
other
advantages
over
plain
tls.
B
That's
kind
of
what
makes
mtls
better
in
that
sense
is
that
you
know
authentication
just
happens
both
ways
so
other
than
that
it
doesn't
necessarily
have
any
advantages,
at
least
that
I
know
I
don't
want
to
be
super
generic
here
and
say
that
you
know
maybe
it
does
have
other
advantages,
but
for
the
purpose
of
this
presentation
and
for
the
purpose
of
what
we're
doing
in
linkedin.
What
we're
really
interested
in
is
authenticating
the
client,
as
well
as
the
server.
B
I
find
it
hard
to
believe
it
depends
again
what
you
mean
by
multiple
cas
or
implemented
in
istio
like
multiple
cas
sign
the
same
certificate,
because
I'm
not
sure
it
would
work
like
that
due
to
how
signatures
are
actually
done,
but
you
know
I'm
not
going
to
say
it
doesn't
happen.
I
would
definitely
love
to
read
up
on
it.
B
So
if
you
do
have
a
link,
let
me
know-
or
if
you
have
a
feature
request
for
linkedin,
you
think
that
would
be
a
thing
and
if
it
can
be
done,
we're
also
not
opposed
to
it.
A
B
Yeah,
I
can
definitely
elaborate
a
bit
more,
but
I'm
not
sure
exactly
what
you
would
want
to
know.
So
why
don't
we
do
this?
If
you
tell
me
exactly
what
you
would
want
me
to
elaborate
on,
or
you
know
what
I
could
say
to
make
it
a
bit
clearer,
I
can
come
back
to
it
and
and
try
to
explain
it
a
bit
more.
A
Great
waiting
for
more
info
from
you,
yingdong,
then
looking
forward
to
that,
and
then
the
last
one
so
far
is
best
practice
for
storing
tls
certificates.
Coming
to
here,.
B
Okay,
I
can
give
you
some
best
practices
or
at
least
like
what
we
think
about
the
operational
model
and
linkery.
So,
first
of
all,
in
linguity
for
the
operational
model,
we
deal
with
trust
anchor,
which
we
call
the
root
ca
and
we
deal
with
an
identity
issuer
which
is
an
intermediate
ca
now
for
the
trust
anchor.
B
We
generally
do
not
advocate
that
you
mount
the
private
key
anywhere
the
public
key.
You
can
distribute
it
in
whatever
you
want.
You
can
use
a
config
map.
You
can
store
it
in
memory.
You
can
store
it
in
the
environment.
You
can
store
it
in
a
volume.
You
can
pull
it
off
the
web.
It
doesn't
matter
because
it's
public,
but
the
private
keys.
You
need
to
be
very
careful
what
you
do
with
them.
So
my
general
rule
of
thumb,
at
least
in
lingerie
land,
is
your
trust.
B
A
Perfect
and
then
there
was
a
bit
of
extra
info
that
hopefully
helps
from
gong
on
thanks
cool
how
it
works.
I
guess
that
is
a
bit
of
a
big
question,
but
if
you
have
any
thoughts
there.
B
Yeah,
I
do
wait
just
two
three
minutes
and
I'll
get
to
the
certificates
bit
and
I'll
try
to
expand
there
a
bit.
I
won't
forget.
I
promise
anyway,
just
to
sort
of
end.
The
chapter
on
mtls
is
mtls,
all
you
need
in
kubernetes
or
in
whatever
distributed
system
that
you
have,
and
the
answer
is
no
and
if
I
would
say
yes,
I
would
probably
have
to
expect
a
bunch
of
security
experts
with
pitchforks
outside
of
my
window.
B
So
no,
it
is
not
all
you
need,
but
it
does
provide
a
lot
of
value
when
it
comes
to
on-path
attacks.
So
that's
when
someone
wants
to
sniff
traffic
whenever
you
try
to
connect
to
a
target
and
someone's
in
the
middle,
because
you
have
encryption,
then
you
have
confidentiality
right.
B
So
they
can
sniff
the
traffic,
but
there's
just
nothing
to
understand
there
and
we're
actually
going
to
do
something
similar
when
we
get
to
the
demo
bit,
it
protects
against
spoofing
attacks
when
an
attacker
pretends
to
be
the
client
or
the
server,
because
you
do
authentication
so
again,
sort
of
in
the
confidentiality
side
and
it
protects
against
malicious
requests
because,
like
I
said
before,
pls
you
know
only
only
authenticates
the
server,
but
now
you
also
authenticate
the
client.
B
However,
it
will
not
protect
from
any
malicious
attacks
that
happen
from
localhost,
unless
you
also
want
to
do
tls
over
localhost,
but
that's
a
bit
of
a
waste,
because
if
someone
has
access
to
your
pods
network
namespace
and
kubernetes,
then
I
guess
you
know
someone
sniffing
traffic
is
the
least
of
your
worries,
at
least
in
my
opinion,
it
does
not
protect
against
unauthorized
access
to
nodes,
so
an
attacker
might
be
able
to
access
keys
or
you
know,
do
nasty
stuff
if
they
have
access
to
the
host.
B
This
generally
tends
to
happen,
especially
if
your
proxy
runs
on
the
host,
because
it
becomes
susceptible
to
like
the
confused
deputy
problem
and
also
it
does
not
provide
encryption
at
rest.
Mtls
is
about
communication
security.
It
does
not
really
encrypt
your
database
or
your
disk
or
anything
else
so
and
now
I'm
going
to
be
talking
about
certificates.
B
So
first
an
analogy
if
I
want
to
fly
into
a
different
country
this
summer
and
if
I
want
to
go
on
holiday-
and
I
most
certainly
do-
but
if
I
want
to
go
on
holiday-
and
I
want
to
take
a
flight-
I
need
to
go
to
the
airport
and
I
need
to
see
that
I'm
authorized
to
go
to
whatever
country
I
want
to
go
to,
and
then
I
can
travel
and
generally.
They
need
to
know
your
identity
right.
B
They
need
to
know
my
name,
my
date
of
birth
and
everything
else
like
where
I
live,
and
what
nationality
I
am
and
stuff
like
that.
If
I
write
all
of
this
stuff
on
a
piece
of
paper-
and
I
just
go
at
the
airport-
and
I
present
this
to
someone
in
the
best
case
scenario-
I
will
just
be
turned
away
and
they
laugh
at
it
and
the
worst
case
scenario.
B
Well,
it's
probably
going
to
be
pretty
bad,
but
if
I
go
with
my
passport
all
of
that
changes
right,
even
though
it's
the
same
information,
whatever
information
I
have
in
my
passport,
I
can
just
write
on
a
piece
of
paper,
but
the
difference
is
that
my
passport
was
issued
by
a
government
agency
and
government
agencies
are
implicitly
trusted
by
people
unless
you're
an
anarchist.
I
guess
but
they're
implicitly
trusted
by
people
and
that's
why,
when
I
present
my
passport,
they
can
look
at
that
information.
They
can
look
at
me
and
say:
okay.
B
Well,
I
trust
that
this
is
your
identity,
and
now
I
can,
you
know,
authorize
you
to
go
or
tell
you
to
leave,
but
with
the
piece
of
paper,
there's
really
no
trust
there
for
them
to
to
check
right.
They
they
have
no
guarantee.
They
have
absolutely
no
guarantee
that
you
know
all
of
that.
Information
is
real.
They
they
don't
trust
me
so
certificates
work
in
a
very
similar
way.
You
have
a
name
or
you
have
some
identifying
piece
of
information,
and
you
have
a
public
key.
B
This
public
key
is
bound
to
the
name
or
to
the
identifying
information
by
a
signature,
and
the
signature
comes
from
another
certificate,
a
certificate
that
they
trust.
If
they
don't
trust
that
certificate,
they
have
to
check
whoever
signed
that
certificate
and
so
on-
and
this
is
probably
where
jinong
I'm
gonna
start
to
talk
a
bit
about
root
ca.
So
I
wasn't
planning
on
doing
this,
but
I
think
it
is
valuable
to
know
when
we
verify
certificates.
B
We
generally
go
through,
what's
known
as
a
verification
chain
right.
So
I'm
sorry,
I
don't
actually
have
a
diagram
for
this.
You'll
just
have
to
listen
to
me
talk,
but
basically,
when
a
client
and
a
server
talk
to
each
other,
they
have
what's
known
as
a
lease
certificate.
That
certificate
is
just
signed
by
other
certificates.
That
certificate
doesn't
sign
anything
itself.
B
B
Another
certificate
will
sign
the
signature
with
that
certificate's
private
key,
and
then
we
can
use
that
certificate's
public
key
that
we
get
from
the
certificate
itself
to
undo
the
signature
and
check
you
know
that
it's
been
signed.
Basically,
if
we
can
actually
you
know,
decrypt
the
signature,
then
it
means
it
works
and
the
public
key
belongs
to
that
certificate,
or
rather
the
public
key
and
the
private
key
are
associated.
B
B
So
when
you
have
a
bunch
of
certificates,
they
all
sign
each
other
and
the
root
most
certificate
is
the
one
responsible
for
you
know,
signing
the
next
one,
and
you
know
the
next
one
signs,
the
other
one
and
so
on.
But
when
you
go
through
this
verification
chain,
you
basically
end
up
at
the
root
certificate
and
that
root
certificate.
Where
you
have
two
choices,
it
either
signs
itself
or
it
is
signed
by.
B
You
know
one
of
the
agencies
that
sign
certificates,
like
let's
encrypt
you
know,
with
a
with
someone
like,
let's
encrypt
everyone,
sort
of
unanimously
trusts
them
kind
of
like
the
government,
but
a
self-signed
certificate
is
a
bit
different
right
generally
in
a
cluster.
If
you
use
a
self-signed
certificate,
you
sort
of
implicitly
trust
it
because
you
create
it
right.
B
So
you
created,
let's
say
on
your
local
machine:
it's
probably
not
the
best
example,
but
you
create
it
on
your
local
machine
and
then
you
put
the
you
know
public
key
or
whatever
you
put
it
in
the
cluster
or
you
start
taking
csrs
you
get
an
intermediate
ca
and
that
signs
other
things
and
other
things
and
so
on
and
when
it
gets
to
the
root
mode
certificate,
it
will
trust
that
implicitly,
because
that's
what
bootstrapped
the
whole
identity
does
that
make
sense.
Have
I
answered
the
question
now.
A
Hopefully
yingdong
you
can,
let
us
know,
how
did
it
go
and
there's
a
few
questions
as
well?
We
can
take
them
now
or
or
in
a
while.
How
do
you
feel.
B
Yes
and
no
certificates
have
an
expiry
date
and
they're
refreshed,
as
often
as
you
want
to
refresh
them
with
link
rd.
For
example,
the
proxies
are
refreshed
every
24
hours.
That's
like
the
maximum
amount
of
time.
They
can
go
without
refreshing.
B
The
issuer
certificate
that
signs
proxy
leave
certificates
that
can
be
refreshed
every
three
days,
every
seven
days,
every
10
days
you
know
so
on
and
so
forth.
It
depends
on
how
you
want
to
do
it
generally.
Our
recommendation
is
that
you
know
intermediate
certificates
are
rotated
every
week
for
some
people.
That's
a
bit
overkill
because
it's
kind
of
a
an
operational
responsibility,
so
yeah
the
answer
is
depends
the
quicker
you
refresh
them
the
better
because
it
lessens
the
chance
of
them.
You
know
actually
being
stolen
so
to
speak,
but
yeah.
A
A
B
Okay,
I
that's
actually
part
of
the
demo,
so
you'll
have
to
stick
until
the
end
to
see
I'm
not
telling
you
on
it.
I
promise,
but
I'm
going
to
cover
it
up
next,
because
that's
oh
no
first,
I'm
going
to
talk
about
linkerie
and
then
I'm
going
to
actually
do
the
demo.
So
real,
quick,
quick
introduction
to
linkrd
so
linkedin
is
a
service
mesh
which
is
yet
another
buzzword,
kind
of
like
xero
trust,
but
a
service
mesh
is
basically
just
a
platform
tool.
B
You
put
it
in
your
cluster
and
it
provides
you
with
observability
reliability
and
security
at
a
platform
level.
Instead
of
having
to
do
this
in
your
application,
what
I
basically
mean
by
that
is
linkery
as
a
tool
ships
with
a
data
plane.
B
We
call
it
a
data
plane,
that's
made
up
of
a
bunch
of
proxies.
These
proxies
will
run
next
year
application
and
they
will
intercept
your
application's
traffic.
They
will
talk
between
themselves.
So
you
know
proxy
intercepts
the
client's
traffic.
It
talks
to
the
server
it
sends
stuff
to
the
server
proxy
and
then
the
server
proxy
sends
everything
back
to
the
server.
But
the
proxy
is
between
themselves,
they
do
ntls
and
they
also
pull
all
of
the
metrics
that
you
sort
of
want
to
look
at.
B
So
that
will
be
you
know,
success
rate,
latency,
throughput
and
and
so
on
and
so
forth,
and
because
the
two
proxies
talk
together,
it
also
allows
them
to
do
retries,
timeouts,
load,
balancing
and
everything
in
between
now
the
real
value
comes
from
not
having
to
implement
all
of
this
stuff
on
an
application
by
application
basis.
So
imagine,
for
example,
you
had
three
or
four
micro
services
that
talk
to
each
other,
but
you
know
two
of
them
are
written
in
a
different
stack.
So
you
have
you
know
a
rust
service.
B
You
have
a
java
service
and
a
c
bus
service.
You
know,
suddenly
you
have
to
do
mtls
in
all
of
them
and
you
have
to
get
metrics
in
all
of
them
and
you
have
to
handle
retries
and
all
of
them
and
while
you
know
for
free
microservices
that
might
not
be
too
hard,
it
does
make
it
more
more
cumbersome
to
do
right.
So
that's
sort
of
the
the
problem
that
service
meshes
want
to
resolve.
You
know.
B
Instead
of
having
to
do
all
of
this
in
your
application-
and
trust
me
like
implementing
mtls
is-
is
really
not
as
easy
as
it
sounds.
The
spec
is
a
bit
underspecified,
there's
a
lot
of
stuff
to
go
through
and
there
are
a
lot
of
corner
cases
in
edge
cases.
So,
basically,
all
of
this
happens
at
a
platform
level
without
you
having
to
make
any
changes
to
your
application.
B
A
Yeah
sure
it's
from
vinod
and
it
goes
during
any
compromise-
is
it
possible
to
rotate
the
certificate
automatically
or
is
it
manual
process.
B
It
depends,
I
think,
if
you
know
it's
been
compromised,
so
say
you
know
you,
you
know,
there's
a
security
incident
or
you
think
there
might
be
a
security
incident
and
your
certificate
expires
in
10
days
and
you're
like
no.
We
need
to
change
it
now.
Otherwise,
you
know
we're
liable
for
stuff
to
happen.
B
You
would
have
to
do
it
manually
or
you
would
have
to
kick
the
process
in
whatever
tool
or
pki
that
you
use
inside
of
the
cluster
to
manage
these
certificates.
So,
for
example,
with
linkery
you
can
manage
the
certificates
yourself
or
you
can
use
some
pki
like
cert
manager
to
manage
these
certificates
for
you.
So,
depending
on
what
process
you
use,
you'll
have
to
definitely
kick
this
process
manually.
If
you
think
they
they've
been
compromised.
B
A
It's
starting
to
look
quite
good
to
me,
but
if
the
audience
has
any
wishes
they
can
let
us
know
it
could
be
a
bit
bigger.
Maybe
I'm
guessing.
B
Cool,
I
I
am
running
a
bit
out
of
time,
so
I'm
going
to
speed
through
the
first
part
and
the
first
part
was
just
to
show
you
kind
of
how
linkery
looks
like.
So.
Let
me
just
look
at
what
cube
cluster
I'm
using.
So
sorry,
I'm
gonna
be
using
an
alias
here
and
k
stands
for
cube
cuddle
and,
yes,
I
am
pronouncing
it
cube,
cuddle,
but
anyway,
over
here
and
of
course,
sorry
in
advance
for
the
clicking
over
here.
B
B
We
have
an
identity
service
that
serves
proxy
certificate,
signing
requests.
We
have
a
destination
service
that
does
service
discovery
and
policy
policy
discovery,
and
then
we
have
a
proxy
injector.
That's
an
admission
web
hook,
server
in
kubernetes,
and
I
also
have
a
demo
application
called
the
moji
photo
where
I
have
a
couple
of
microservices
running
and
what
I
quickly
wanted
to
show.
B
You
is
the
state
that
we
want
to
end
up
in
after
we,
you
know,
install
everything
fresh
in
a
cluster
without
linkedin,
so
I'm
going
to
use
the
viz
cli
tool
this
light
tool.
We
have
called
pap
which
allows
us
to
tap
into
the
traffic
stream,
and
this
is
basically
going
to
confirm
for
us
that
we
have
tls.
So
we
turn
to
the
traffic
stream.
B
B
So
if
I
go
into
my
emoji
photo
namespace,
I'm
not
going
to
spend
too
much
time
talking
through
the
dashboard,
because
you
know,
I
think
it's
it's
not
what
the
presentation
is
really
about,
but
basically
at
the
bottom
of
the
screen.
Here
we
can
see
the
edges
for
this
particular
pod
and
we
can
see
which
name
space
and
which
service
traffic
is
coming
from
and
whether
that
edge
is
actually
secured.
B
So
linkery
already
gives
you
the
tools
to
check
for
mtls,
but
I
figured
you
know,
since
this
is
a
presentation
about
security,
you
might
not
want
to
take
the
word
of
a
random
person.
You've
just
met
on
the
internet,
and
you
might
want
to
verify
everything
yourself,
which
you
probably
should
do.
In
most
cases
I
mean
we
are
pretty
trustworthy,
but
you
know
it's
always
good
to
double
check
these
things
anyway.
B
Over
here
I
have
a
new
cluster
or
namespaces.
Sorry,
it's
sometimes
hard
to
type
and
speak
at
the
same
time,
like
I
said
multitasking,
not
my
strong
point,
but
this
cluster
doesn't
really
have
any
linkery
stuff
in
it.
It
doesn't
have
any
manifest
deployed,
so
it's
just
whatever
shipped
with
a
cluster
I'm
using
k3d
by
the
way,
so
we
don't
have
anything
in
there
and
what
I'm
going
to
do.
B
B
It
connects
to
two
other
microservices
to
get
information
about
offers
and
about
books,
and
it
also
has
a
traffic
generator
that
sends
you
know
synthetic
traffic
to
the
front
end
as
part
of
this
books
app.
I
also
have
another
container:
it's
a
debug
container,
so
link
rd
does
ship
with
a
debug
container.
B
You
can
pretty
much
inject
it
into
your
service,
so
you
can
check
stuff,
but
I
wanted
to
cheat
a
little
bit
and
just
add
it
here,
because
I
want
to
have
access
to
a
tool
called
t-shark
that
we're
going
to
use
to
stiff
the
network
so
yeah
just
a
normal
debug
container.
It
has
some
tools
inside
I
give
it
some
system
capabilities,
so
I
have
to
avoid
you
know
running
into
any
issues
because
live
demos
aren't
always
smooth.
A
B
Can
we
use
yeah,
I
I
suppose
you
can
so
if,
if,
for
example,
you
want
to
generate
the
trust
anchor
in
your
pki,
then
you
can
definitely
do
that.
You'll
just
need
to
make
sure
that
the
public
information
is
available
in
the
cluster.
So,
like
I
said,
keep
the
key
in
aws
secret
manager,
but
then
you'll
need
to
make
sure
that
when
you
install
linkerd
you
provide
the
certificate
to
linguity
just
a
public
bit
but
yeah.
You
definitely
can.
A
Great
there's
two
more
then,
if
we
have
some
waiting
time
still
so
jose
asks
what
is
the
difference
between
uncle
service,
mesh
and
linker
d.
B
It's
a
good
question
and
I
do
not
mean
to
sound
super
ignorant,
but
I
do
not
know
much
about
antos
service
mesh.
So
if
you
can
give
me
some
material
to
to
read
up
on,
I
can
give
you
more
information
about
it.
I
can
tell
you
what
stands
out
with
linkery
in
general
and
I'm
not
sure
that
the
team
from
antos
does
the
same
thing,
but
we
run
our
own
proxy.
B
So
we
do
not
rely
on
envoy
and
our
proxy
is
written
in
rust
and
it's
purposely
built
for
link
kerdi's
control
plane
and
for
interacting
with
with
linker
d's.
You
know,
philosophy
of
keeping
things
simple
and
operationally
simple
in
general,
but
if
you
give
me
more
information
and
if
you
want
to
reach
out
to
me,
I
can
definitely
talk
to
you
more
about
it.
B
I'll,
I
will
quickly
go
through
this
just
so
I
have
more
time
at
the
end
for
questions.
So
anyway,
we
have
our
deployments
running
and
I'm
just
going
to
exec.
You
can
see
the
autocomplete
there,
I'm
going
to
exec
onto
this
pod,
I'm
going
to
do
it
in
an
interactive
mode.
I'm
going
to
choose
the
debug
container
and
the
command
that
I
want
to
execute
with
is
bash,
so
I
planned
on
giving
you
an
like
not
in
depth
but
a
bit
of
an
introduction
on
t
shark.
B
It's
not
hard
to
make
sense
of,
but
it's
also
not
super
fun
to
read
anyway.
So
key
shark
is
a
capture
tool.
It
can
snip
traffic
and
capture
on
interfaces.
We
can
see
what
interfaces
we
have
available
if
we
do
iplaying
show
and
that
will
show
whatever
interfaces.
We
have
attached
a
pod's
network
namespace.
So
in
this
case
we
have
ethernet.
We
have
a
tunnel
and
loopback
and
when
you
start
capturing
packets
with
t-sharp,
you
can
specify
the
interface
that
you
want
to
capture
on.
B
B
This
is
going
to
start
a
capture
and
it's
just
going
to
print
out
the
packet
summaries
so
over
here,
I'm
just
going
to
do
a
quick
cube,
cuddle
get
pods
just
so
you
can
see
how
the
eyepiece
that
we
have
for
the
pods
correlate
with
what
we're
seeing
here.
So,
for
example,
in
the
last
in
the
last
packet
summary
in
this
capture,
we
can
see
that
we
have
the
source
of
the
traffic
here.
1042-012
that
corresponds
to
our
traffic
pod
and
the
traffic
pod
is
the
source
and
the
destination
is
104209
and
zero.
B
Nine
corresponds
to
our
current
pod
web
app
over.
Here
we
have
some
tcp
things,
including
the
tcp
flag.
Here,
the
sequence
number
the
act
number
the
length
of
the
packet
and
so
on
and
so
forth.
So
these
things
are
not
super
important
right
now,
but
basically,
where
I'm
going
to
go
with
this,
is
I'm
going
to
show
you
how
using
t-shark
we
can
actually
sniff
the
traffic?
B
We
can
tell
what
http
information
we
have
in
in
plain
text
and
then
after
we
install
linkery,
we'll
see
that
it's
not
possible
anymore,
or
at
least
I
hope
it's
not
possible
anymore.
No,
I'm
kidding
it
won't
be
possible
anyway,
so
with
t-shark.
What
I'm
going
to
do
is
I'm
going
to
decode
all
so
that's
what
the
o
means.
B
I'm
only
going
to
decode
information
for
http
packets
and
I
will
have
the
output
as
json
and
again
I'll,
choose
tcp,
but
this
time
I'll
go
for
port
7001,
and
this
is
one
of
the
services
that
our
web
app
is
connecting
to
to
get
information.
B
So
we'll
see
that
again
we
have
a
lot
of
things
that
are
being
printed
out,
but
this
time
we
also
have
information
about
all
of
the
other
protocols,
so
protocols
are
sort
of
multiplexed
on
top
of
each
other
in
a
packet
and
we'll
basically
take
all
of
this,
and
we
can
see
we
start
from
the
layers.
B
We
start
demultiplex
and
everything
we
start
from
the
frame
we
go
down
to
the
ethernet
information
iptcp
and
finally,
we
get
to
our
application
layer
protocol,
which
is
http
and
you'll
notice
that
here
we
get
all
of
the
information
that
has
to
do
with
http.
We
can
get
the
server.
We
can
get
the
content
length
for
the
header.
We
can
get
the
response
number
and
also
the
file
data,
so
we're
sending
everything
as
application
json
and
the
content,
I
think,
is
somewhere
up
there.
B
But
basically,
if
we
combine
this
with
something
like
grep-
and
we
say
we
want
to
see
file
data,
we're
going
to
be
able
to
see
everything-
that's
being
sent
here
in
plain
text
now.
Obviously
this
is
not
ideal,
but
imagine
that
someone
would
run
something
like
this
and
they
would
sniff
your
traffic.
They
don't
have
to
be
in
the
exact
onto
the
pod
like
I
am
now
they
can
just
sniff
the
traffic
and
see
all
of
this
stuff.
So
imagine
these
books
are
super
secret.
B
Maybe
they
are
maybe
they're
not,
but
yeah
you'd
be
in
a
lot
of
big
trouble.
Basically,
especially
if
you
process
credit
card
numbers
or
just
anything,
I
think
the
rule
of
thumb
is
that
we
don't
want
people
to
to
see
what
we
are
actually
sending
through.
So
now,
I'm
going
to
install
linkedin
link
ready,
install
is
just
going
to
actually
print
out
the
manifest
it's
not
going
to
install
anything.
So
you
can
have
a
look
through
the
manifest
again.
B
You
know
don't
take
my
word
for
it,
but
I'm
just
going
to
install
linker
d,
pipe
it
to
keep
puddle
and
wait
until
everything
is
deployed
and,
while
that's
happening,
should
we
take
some
questions.
A
Yes
perfect,
so
there
is
a
question
from
hari
haran
who
asks
with
service
mesh
enabled
sometimes
troubleshooting
might
be
a
bit
difficult.
Any
pointers
on
how
troubleshooting
is
better
in
linkedin
versus
istio
or
any
other
service
mesh.
B
Like
I'm
going
to
be
general
here
and
sort
of
flop
them
all
into
the
into
the
same
pot,
so
to
speak,
I
think
yes,
troubleshooting
might
be
a
bit
more
difficult
because
suddenly
you
know
traffic
is
being
taken
over
by
something
else
that
you
don't
necessarily
own,
but
what's
really
great
about
service
meshes
in
general
is
that
everything
is
open
source.
So
you
can,
you
know,
go
and
look
for
the
code
yourself
and
more
than
that,
we
basically
put
all
of
these
metrics
available
for
you
to
use.
B
So
I
would
argue,
it
actually
makes
troubleshooting
a
bit
more
easier
because
suddenly
you
have
metrics
available.
You
know
where
stuff
breaks
you
can
correlate
it
with
logs
and
usually
proxies
as
software
can
have
like
variable
log
levels,
so
you
can
go
as
verbose
or
you
know
as
quiet
as
you
want
to
be
and
with
the
proxy
itself.
Actually
we
support
modifying
the
lock
level
on
the
fly,
so
you
can
say:
okay,
you
know
everything
is
at
an
info
level.
Now,
suddenly
I
want
to
make
a
debug,
because
I
have
a
problem.
B
It
would
actually
be
much
harder
to
track
what's
going
on,
but
you
know
with
flinkerd
we
put
all
of
these
tools
available
and
also
have
the
metric
stack
that
helps
you
sort
of
troubleshoot
this
further,
because
we
don't
believe
that
you
have
to
actually
be
a
proxy
expert
to
realize
what's
happening
there
anyway.
So
my
deployment
is
done.
B
Now
you
can
do
this
on
a
pod
bipod
basis
or
you
can
do
it
on
a
namespace
and
then
the
pods
will
inherit
this
from
the
namespace
and
that's
what
I'm
going
to
do
now.
It's
a
bit
easier
than
annotating
all
of
our
workloads,
so
I'm
going
to
inject
it
pipe
it
apply
it
and
then,
if
we
get
the
pods
in
booksec,
you'll
notice
that
nothing
changed.
That's
because
we
have
to
restart
all
of
the
deployments,
so
they
can
be
picked
up
by
the
admission
webhook.
B
Cool
and
now
this
should
be
pretty
quick.
I
have
time
for
a
quick,
quick
question.
A
Okay,
perfect:
is
there
any
authorization
policy
supported
like
opa
or
oigt
for
massage.
B
Yeah
so
linkrd
does
its
own
server-side
policies,
so
we
have
our
own
server
side
policy,
crd
that
basically
lets
you
restrict
traffic
or
allow
traffic
or
require
mtls
and
stuff
like
that.
We
don't
have
any
opa
integrations
ourselves,
but
it's
something
that
you
could
integrate
with
opa.
If
you
want
to
spend
time
doing
that.
B
But
generally
we
found
that
for
user
experience,
it's
just
a
bit
easier
for
us
to
roll
out
our
own
stuff.
And
then
you
know
the
user
experience
around.
It
is
sort
of
dictated
by
us
and
you
don't
introduce
another
tool,
but
you
know
check
it
out.
I
think,
if
you
just
do
a
quick
google
linkerity
offset,
you
should
be
able
to
find
information
on
that
anyway.
B
What
I'm
going
to
do
is
go
into
this
web
app
pod
again
and
I'm
going
to
go
back
into
the
debug
container
and
again
I'm
going
to
start
a
capture
and
I'm
going
to
skip
everything
that
I've
done
before
I'm
just
going
to
go
straight
in
for
the
kill.
So
I'm
going
to
decode
the
packets
as
http
json,
tcp
port.
B
I
think
it
was
7001
and
then
I'm
going
to
grab
for
http
file
data
and
I'm
going
to
wait
and
nothing
displayed
so
far,
but
the
packet
count
is
going
up
so
we're
capturing
packets,
but
nothing
is
being
displayed
and
you
know
I
wonder
why
but
secretly.
I
know
why
this
is
just
a
prompt:
it's
because
we
no
longer
actually
have
any
http
flags
and
http
packets
in
here
I'm
just
going
to
scroll
up
right
instead
of
http,
we
now
have
ssl.
B
B
I
actually
didn't
choose
the
port,
I'm
going
to
say
only
tcp
traffic,
port
7001
and
again
it's
going
to
start
the
capture,
and
this
is
just
going
to
print
the
exact
same
thing
as
before,
but
it's
going
to
do
it
in
a
in
a
different
format,
and
we
can
see
here
that
this
would
normally
print
application,
traffic
and
application
content.
But
now
there's
just
this
application
data
for
tls
and
well.
We
can't
actually
make
sense
of
whatever
else
is
in
here
and
you
know
again
don't
take
my
word
for
it.
B
B
So
I
guess
what
I
wanted
to
show
with
all
of
this.
Sorry,
I
don't
actually
have
a
dramatic
ending
to
this
presentation
or
to
this
demo
is
that
you
know
linkery
adds
out
of
the
box
mtls
and
it
adds
tools
for
you
to
verify
if
mpls
is
working.
But
if
you
want
to
roll
up
your
sleeves
and
do
it
yourself,
you
can
definitely
do
it
and
you
know
you
can
use
a
packet
sniffing
tool
like
d-shark,
but
basically
what
I.
B
We
we
didn't,
have
to
be
exact
in
this
container
and
we
would
see
everything
in
plain
text,
and
now
you
can't
do
that,
except
if
you're
in
the
container
and
you're
listening
on
localhost
and
like
I
said
if
someone
gets
access
to
your
pods
network
namespace
or
they
exec
into
the
pod,
then
you
know
mtls
is
not
gonna
save
you
from
that
anyway,
so
but
yeah
that
kind
of
wraps
it
up.
So
I'm
just
gonna
go
back
to
my
slides
here
and
I
think
we
have
a
quick
minute
for
questions.
A
Yeah
we
have
about
two
and
a
half
minutes,
maybe
so
rapid
fire
questions
is
actually
coming
up.
Yeah.
So
there's
a
question:
is
this
the
same
functionality
as
kiali.
B
B
It
depends
it
does
not
like
it
does
work
with
ebpf
and
cni
plugins,
but
it
doesn't
do
any
ebpf
on
its
own.
We
still
use
ib
tables
for
routing,
but
we
have
people
who
use
it
with
calico
or
psyllium.
So
it's
not
a
problem.
A
Great
then
there
is:
can
you
demo
how
to
uninstall
linkery?
If
I
happen
to
run
into
an
unexpected
issues.
B
Yes,
of
course,
I'm
just
going
to
exit
from
here
and
I'm
going
to
do
linkery
uninstall,
I'm
going
to
pipe
it.
The
cube
cuddle
delete.
Well,
I
guess
I
don't
need
the
that
chef
flag.
Well,
I
first
need
to
inject
all
of
these,
so
I
am
going
to
get
the
name
space.
B
We
do
the
more
you
know
you
know.
Actually
I
do
not
install
it
very
often.
I
just
delete
the
cluster
itself,
but
then
we
roll
out
the
pods
and
then
we
do
linkerity
not
install
well
still
complains
about
something,
but
you
kind
of
get
the
point.
A
Right
then,
I
think
there's
maybe
time
for
one
more
or
so.
What
do
you
use
for
search,
rolling.
B
Rolling
as
in
rolling
certificates,
I'm
not
sure.
I
really
understand
the
question.
I'm
sorry
about
that.
A
Or
we
can
continue
to
continue
the
discussion
in
the
cloud
native
live
slack
channel
by
the
way
for
everyone.
Okay,.
A
B
So
you
can,
if
I
understand
a
question
correctly,
you
can
also
inject
your
ingress
controller.
Linker
is
not
going
to
handle
any
ssl
termination
at
the
ingress
level.
Your
ingress
controller
is
going
to
take
over
that,
but
linkard
is
going
to
take
over
anything.
So
it's
going
to
encrypt
anything
that
goes
from
your
ingress
controller,
to
whatever
target
that
you
have.
A
Great
so
there
were,
there
are
about
three
questions
that
we
didn't
get
to,
but
as
mentioned
before,
every
you
can.
Everyone
can
hop
into
the
cognitive
live
slack
channel
within
the
cncf
or
kubernetes
slack.
Essentially-
and
I
see
that
you
have
some
academic
years
I
mentioned-
maybe.
B
Yes,
so
just
a
quick,
yeah,
quick
announcement,
we
also
present
all
of
these
things
related
to
linkedin
and
service
meshing
at
what
we
call
the
service
mesh
academy.
So
this
is
all
free
training
and
free
knowledge.
We
do
love
to
spread
the
knowledge
yeah
if
you
want
to
see
more
material,
especially
around
certificate
management
or
failover
or
multi-cluster
yeah
check
it
out
and
with
that.
Thank
you
very
much
for
your
attention.
A
Yeah,
thank
you.
Everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
an
amazing
session
by
mate.
Thank
you
so
much.
We
also
really
love
the
interaction,
so
much
interaction
from
the
audience
today,
really
great
to
see
that
and
as
always,
we
bring
you
the
latest
cloud
creative
code
every
wednesday,
so
join
us
in
the
upcoming
wednesdays
as
well
see
you
later,
everyone.