►
From YouTube: Cloud Native Live: Locking down your cluster
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
thomastow
and
I'm
a
cncf
ambassador
as
well
as
senior
product
marketing
manager
at
camunda,
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
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
a
really
great
session
on
locking
down
your
cluster,
I'm
really
excited
for
that
which
is
really
great
and,
as
always
as
a
kind
of
like
a
housekeeping
item.
This
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
cncf
code
of
conduct.
A
B
B
I
work
as
one
of
the
maintainers
of
this
open
source
project
and
today
I'm
happy
to
talk
to
you
about
link
reduce
implementation
of
mutual
tls
and
how
we
leverage
the
authentication
that
mutual
tls
gives
us
to
implement
traffic
policy
all
right.
So
these
are
what
some
of
my
social
media
accounts.
If.
B
Just
to
make
we're
on
the
same
page
about
a
couple
of
concepts,
then
most
of
the
time
we'll
be
applying
all
these
things
so
empty
that
I
like
to
first
talk
about.
Tls
gives
us
guarantees
that
we
can
remember
using
the
cia,
so
first
computation.
That
means
that
connections
are
encrypted.
So,
if
anyone's
listening
to
the
data
that
you
can
see
the
packages,
they
me
they
won't
be
able
to.
B
Secondly,
entirely
that
means
that
we
have
guaranteed
whatever
we
get
is
we
have
to
guarantee
that
it
is
exactly
what
we
get
and
finally,
obesity,
which
is
what
we
are
most
interested
in
today,
means.
A
Yeah
and
there
seems
to
be
a
bit
of
audio
issues
if
you
can
do
anything
from
your
side,
that
would
be
nice,
but
I
also
advise
all
the
attendees.
Sometimes
I
think
there's
a
bit
of
audio
issues
that
gets
worse
if
you
have
a
multiple
tabs
open,
for
example,
or
you're,
using
your
bandwidth
of
your
browser,
for
example,
quite
a
lot,
so
I
do
recommend
trying
out
those
kind
of
fixes
as
well
or
refreshing,
your
page
and
so
forth.
That
would
be
that's
always
a
good
thing
to
do,
but
obviously
I
cannot.
A
I
can
at
least
hear
what
you're
saying
so
we
can
continue
as
well,
but
if
there's
anything
that
you
can
do
super
quickly.
A
B
A
In
theory,
I
think
this
is
it's
a
bit
different.
We
can
just
go
with
with
whatever
you
felt
the
best
and
we
can
see
there
are
some
people
saying
that
it
works
okay,
at
least
my
voice
is
working
quite
okay,
but
we
can
try
out
something
and
then
okay,
there's
still
a
few
comments,
but
at
least
I
was
able
to
hear.
B
B
All
right
I'll
go
on
then,
so
I
was
talking
about
tls
confidentiality
and
chair,
really
authenticity.
So
there's.
B
Next
to
authenticity,
because
until
usually
tls
only
cares
about
the
authentication
of
one
side
of
the
connection,
so
most
people
are
familiar
with
tls
in
the
context
of
web
browsing
where
the
server
presents
a
certificate
that
proves
who
that
company
or
that
person
behind
behind
that
person
is
behind.
That
page
is
and
if
usually
the
server
doesn't
care
about
the
identity
of
the
client
and
if
they
do,
they
implement
that
higher
up
the
stack
at
the
level
of
the
application
layer
through
things
like
logging
forms
or
things
like
that.
B
So
in
the
context
of
microservices
in
clusters,
we
are
interested
in
both
identities,
client,
side
and
server
side.
So
for
that
we
use
mtls,
which
is
nothing
more
than
tls,
with
authentication
on
both
sides
of
the
connection
and
what
is
what
certificates
certified
certified?
It's
just
a
subject
in
the
case
of
microservices.
In
the
case
of
linker,
this
mtls
implementation.
B
B
Well,
we,
even
though,
if
we
are,
we
might
not
have
total
control
of
what
runs
in
our
clusters
for,
for
example,
regarding
dependencies,
so
that's
one
vector
where
people
can
get
into
our
cluster
and
start
communicating
with
other
pots
that
they're
not
supposed
to,
and
so
ideally
we
should
secure
things
at
the
most
granular
level
as
possible,
and
this
is
in
a
few
words
what
the
zero
trust
of
these
all
about,
there's,
also
a
performance
concern.
B
It
is
true
that
ntls
entails
an
additional
handshake,
but
that
only
happens
at
the
beginning
of
the
establishment
of
the
session.
B
B
The
most
important
concern
is
that
it's
really
really
hard
to
implement
this
well,
in
particular,
what
regards
the
certificate
management?
There
are
multiple
layers
or
certificates
that
you
have
to
handle.
There's
the
issue
of
distributing
these
certificates
across
all
the
cluster,
and
also
you
have
to
run
renew
these
certificates
as
often
as
possible.
B
Thankfully,
linker
d
gives
you
all
of
these
automatically.
I
think
one
of
the
principal
reasons
why
people
start
getting
into
service
mesh
in
production
is
this
just
to
have
mtls
implemented
without
too
much
pain
and
in
lingard's
specific
case,
we
implement
this
through
a
layer,
a
three-layer,
hierarchical
model
of
certificates.
B
These
certificates
that
the
pots
received
are
shortly,
they
only
for
24
hours
and
they
are
automatically
renewed
by
the
proxies.
So
let
me
really
quick
summarize
how
the
linker
d
proxy
injection
works
whenever
a
new
pod
starts.
B
The
first
thing
that
happens
is
there's
a
web
hook.
That
is
called
that's
the
linker,
the
proxy
injector
component.
It
injects
the
proxy
inside
the
pod
and
it
as
a
sidecar.
B
B
Then
the
linker,
the
identity
component,
checks
that
against
the
cube
api
and
then
returns
the
shortly
certificate
to
the
pod
and
when
the
proxy.
B
Doing
this,
then,
the
main
container
can
start
so
that
it
has
a
guarantee
that,
at
the
start,
any
incoming
or
outgoing
connection
is
going
to
be
encrypted.
B
If
you
want
to
try
this
by
yourself,
it
requires
zero
configuration
if
you
try
it
through
the
our
cli
tool.
By
default,
it's
going
to
create
the
truss
route
and
the
issuer
certificates
there's
nothing.
You
have
to
do
to
start
playing
with
these
in
production.
By
contrast,
we
don't
recommend
using
the
cli,
even
though
there
are
people
that
are
successful
doing
that,
because
it
offers
you
all
the
features.
B
But
instead
of
that,
we
recommend
using
the
helm,
charts
the
the
functions
in
the
helm.
Charts
don't
allow
us
to
create
certificates
using
the
elliptic
curve
algorithm.
So
that's
why
we
cannot
provide
these
certificates
by
default,
but
anyways
in
in
production.
A
A
And
oh,
by
the
way
we
can
see
the
restream
studio
right
now
on
the
live,
beat.
Okay,
no
worries.
B
Let
me
move
that
to
the
other
screen:
okay,
how
it
doesn't
affect
the
communications
at
all.
I
I'm
not
aware
exactly
of
the
implementation
on
the
proxy
side
of
things,
but,
as
far
as
I
know,
it
doesn't
stop
communication
or
add
any
latency
at
all.
It's
all
rolled
out
seamlessly
so
that
ntls
deals
with
authentication,
that's
just
one
side
of
the
security
coin.
The
other
side
is
what
can
we
do
once?
We
know
that
a
client
is
what
who
they
claim
they
are.
So
this
is
authorization.
B
What
is
this
identity
allowed
to
do?
We
do
this
in
linkery,
through
authorization
policy
that
we
started
shipping
on
our
latest
stable
version.
That's
211
that
we
shipped
a
couple
of
weeks
of
months
ago.
This
is
similar
in
intent
to
what
network
policy
offers,
which
is
a
native
kubernetes
resource
network
policy.
In
a
few
words
lets
you
declare
which
pods
can
communicate
with
what
other
pods
given
their
network
identities.
So
that's
just
basically
eyepiece.
You
are
also
able
to
select
parts
through
label
selectors,
but
linkardi.
B
Instead
of
that
uses
workloads,
identity,
which
is
a
higher
abstraction.
That
is
much
more
expressive
and
lets
you
do
things
a
little
more
on
the
up
level
of
things.
So
we're
going
to
see
concrete
examples
in
the
demo.
B
It
is
important
to
keep
in
mind
that
this
policy
is
applied
and
verified
on
the
inbound
inbound
side
of
pods
pod
will
consult
these
policies
whenever
a
incoming
connection
comes
in
not
on
the
outgoing
side,
so
this
will
come
later
in
the
next
stable
version,
but
I
think
we
can
agree
that,
most
importantly,
the
policy
on
the
server
side
is
what
matters
most.
B
B
Similarly,
to
network
policy,
you
can
say,
for
example,
that
the
default
policies
to
deny
all
connections,
so
we
you
would
lock
down
all
all
the
connections
inside
your
namespace
and
then
on
a
case-by-case
basis.
You
can
override
that
policy
and
then
we
declare
a
couple
of
custom
resource
definitions
for
assist
server.
That
allows
us
to
select
what
pods
we're
interested
in,
what
workloads
and
what
ports
and
protocols
you
want
and
server
authorization,
which
is
actually
the
rules
themselves
and
to
what
servers
they
apply.
B
So,
for
example,
you
only
want
to
receive
connections
on
some
port
that
uses
grpc
and
only
coming
from
some
other
workloads
that
are
identified
through
some
specific
particular
way
or
you
may
allow
all
incoming
traffic
etc,
etc.
So
we
will
see
detailed
examples
in
a
moment.
B
So
now
I'm
going
to
move
to
a
demo.
First,
I'm
going
to
talk
a
little
bit
about
how
we
deal
with
mtls
and
then
we
will
see
an
example
of
authorization
policy
in
action.
A
Question
here
there's
a
few
follow-up
questions
after
that,
do
you
want
to
take
them
now,
or
do
you
want
to
take
them
at
the
end
of
the
like
a
whole
session.
A
Great,
so
there's
another
one
that
if
we
are
talking
about
cert,
what
is
the
good
way
to
secure
those
and
thank
you
so
much
evan
by
the
way
for
the
question
so
far,.
B
How
to
secure
the
certificates
where,
for
example,
if
you
are
installing
linker
d
with
trustroot,
that
you
create
yourself
linkery
only
only
requires
the
public
key.
That's
that
actually
is
stored
in
a
config
map.
It
doesn't
require
any
particular
security,
because
that's
public
the
key
linkery
doesn't
require
the
key,
so
you
should
store
it
securely
outside
your
cluster.
B
A
Perfect,
should
we
take
okay,
there's
three
more
questions
that
has
come
in.
Do
you
want
to
take
one
now
or
do
you
want
to
leave
them
to
the
end
of
the
presentation.
B
B
Okay
and
in
the
demo,
we
will
see
a
specific
example
of
how
to
isolate
namespaces,
which
is
a
common
use
case,
which
means
that
you
only
allow
traffic
from
within
the
namespace
and
anything
coming
from
outside
the
namespace
is
denied.
So
let's
jump
into
the
into
that
right.
So
here
I
have
a
cluster
mp
cluster
in
my
local
laptop
and
we're
going
first
and
foremost
install
link3d.
B
This
is
just
it
gives
us
some
extra
visibility,
okay
and,
as
I
said
by
default,
this
is
going
to
create
some
word
certificate
and
an
issuer
certificate
and
install
it
in
in
our
linker
installation.
So
let's
take
a
peek
at
those
specific
certificates.
B
B
B
B
B
First
thing
we
see
is
that
it's
it
lasts
for
a
full
year
starting
now.
This
is
the
subject,
the
certificate
very
simple
and,
most
importantly,
it's.
It
is
a
ca,
so
it
is
able
to
sign
and
create
other
derivatives
certificates,
which
is
what
linker
d
does
during
its
installation.
It
created
the
issuer
certificate
that
derives
from
this
one.
So
let's
take
a
look
at
that
one,
this
one.
On
the
other
hand,
since
it
is
both
the
public
key
and
the
private
key,
it
gets
stored
as
a
secret.
B
We
need
the
private
key
so
that
it
can
itself
create
all
the
certificates
for
the
pods,
so
that's
stored
under
the
identity
issuer.
B
Okay,
this
certificate
also
lasts
for
a
year.
It
has
the
same
subject
up
as
our
trustworthy
and
it
is
also
able
to
generate
other
certificates
below
it.
Okay,
so
now,
let's
get
back
to
our
cluster
and
let's
install
a
sample
app,
which
is
emoji
bottle,
something
that
we
always
use
for
interview.
Demos.
B
A
B
B
B
B
If
I
pause
this
for
a
moment,
you
can
see
all
these
requests
on
plain
text,
so
nothing
is
encrypted.
Yet
these
are
the
requests
that
are
originating
in
our
bot.
So
it's
this
part
here.
It
communicates
with
our
web
front
end
and
that
web
front
end
communicates
with
the
emoji
component,
which
returns
all
the
emojis
that
are
available
and
the
boating
component,
which
actually
proceeds
persists
the
votings
okay.
B
So
let's
leave
these
here
running
on
the
bottom.
Okay,
and
now
I'm
going
to
inject
this
app
emoji
bottle.
Let's
do
that
in
a
separate
window.
B
Yes
and
I
pipe
that
into
linkery
inject,
the
only
thing
that
linker
game
jet
does
is
add
an
annotation
so
that
when
the
pot
gets
created
the
web
hook,
that
gets
called
that's
a
link.
Reproxy
injector
will
see
that
annotation
and
it
will
inject
the
proxy
as
a
side
card
and,
let's
pipe
that
into
the
cluster
okay.
B
Okay,
we
can
see
now
that,
as
the
pods
get
rolled
out,
we
see
two
containers
per
pot,
so
one
is
the
main
container.
The
other
one
is
the
proxy
that
just
got
injected.
A
B
Okay,
let's
take
a
look
at
okay.
Yes,
I
hear
we're
still
sleeping
the
traffic
in
the
host.
We
no
longer
see
that
much
traffic
because
there
are
no
longer
get
requests
that
are
out
in
plain
text.
We
still
see
things
like
these
health
checks
that
are
coming
from
the
couplet,
because
the
couplet
doesn't
run
inside
a
pub,
so
there's
really
no
way
to
inject
the
proxy
there,
but
I
think
that's
fine,
so
we
just
achieved
mpos
to
this
app
okay.
How
else
can
we
make
sure
that
all
these
connections
are
secure?
B
There's
these
this
attack
command
that
we'll
inspect.
I'm
gonna
shut
this
down
here
that
inspects
in
real
time.
It
gives
us
the
samples
of
everything
that
goes
through
some
specific
part.
For
example,
here
the
web
deployment.
B
Here:
okay,
so
we're
interested
in
the
emoji
model,
namespace
and,
let's
see
the
web
deployment.
So
here
are
the
incoming
connections,
the
outgoing
connections.
Here
at
the
bottom,
we
see
everything
that
comes
in
and
comes
out
the
identity
of
each
one
of
those
connections
and
whether
they're
secured
or
not
so
here,
they're
all
secured.
B
B
We
see
that
the
proxy
has
access
to
the
certificate
through
an
environment
variable
that
is
the
truss
root
certificate,
since
all
of
the
certificates
in
the
cluster
are
are
rooted
at
the
trust
root.
We
need
the
trust
root
here
in
order
to
validate
that
those
certificates
from
the
connection
from
the
connections
that
come
into
the
pod
and
also
of
note
here
is
a
volume.
B
We
see
this
volume
here
that
gets
injected
by
the
proxy
injector.
It
is
a
memory
volume
and
that's
where
the
proxy
stores
its
certificate.
It's
a
24-hour
certificate.
It
doesn't
store
it
in
the
file
system,
so
in
case
there's
a
security
breach
or
anything
or
there's
a
rogue
process
running
the
host.
B
It
doesn't
have
access
to
the
file
system
and
see
the
actual
certificate,
along
with
its
privacy,
of
course,
so
there's
no
way
to
directly
inspect
that
certificate
like
we
did
with
the
trust,
root
and
the
issuer
certificate,
but
there's
a
command
here
to
enter
the
identity.
B
There
we
go
so
we
see
here
the
subject
of
the
certificate,
so
this
is
the
workload
identity
that
we
mentioned
many
times
before.
The
service
account
of
this
pod
is
called
web.
I
forgot
to
show
you
when
we
saw
the
the
podiamo
and
then
it's
the
namespace
and
everything
that
comes
is
the
same
everywhere.
B
B
So
one
thing
to
remember
is
that
all
the
workloads
in
this
name
namespace
will
share
this
suffix,
and
here
the
prefix
will
be
their
service
account,
which
usually
changes
amongst
workloads.
B
B
B
Okay,
so
all
this
means
that
it
is
able
to
successfully
send
these
requests
for
these
votes,
and
now
I'm
going
to
annotate
the
emoji
button
in
space
with
the
default
policy
of
the
knight.
So
we
can
lock
deny
all
the
connections
inside
the
cluster
inside
the
namespace,
so
I'm
going
to
copy
that
command.
Actually
there
we
go
so
the
default
policy
is
going
to
be
denied
for
the
entire
namespace.
B
B
Now
we
can
see
that
both
part
starts
failing
because
it
is,
its
connection,
is
getting
denied
now.
Okay-
and
another
important
thing
here
is
that,
though,
actually
the
web,
the
web
pod,
is
not
able
to
start
fully.
Only
one
container
is
running.
So
let's
take
a
look
what's
going
on
here
in
separate
window,
let's
describe.
B
B
Okay,
so
this
is
our
first
cr
server
that
says
that
this
applies
to
all
the
pods
that
have
a
port
called
liquidy
admin
that
uses
the
http
protocol.
B
So
this
happens
to
be
the
proxy
endpoints
that
take
care
of
serving
the
probes
and
we
want
to
give
well.
We
create
here
the
server
authorization
which
it
is
tied
to
that
server,
which
is
called
admin,
and
the
rule
is
just
open
to
reading
everything.
So
that's
unauthenticated
too.
It
means
that
everything
that
comes
in
is
allowed.
B
B
B
Okay
and
now
we
see
that
the
web
pod
is
able
to
successfully
run,
we
are
still
not.
The
boat
is
still
not
able
to
communicate
with
it
because
we
haven't
rolled
everything
up
yet.
So
let's
do
that.
B
Oh
actually,
I
forgot
yes,
this
is
not
going
to
work
yet
because
we
only
allow
traffic
for
the
probes.
We
need
to
actually
allow
traffic
for
the
actual
app
connections.
So
there's
this
other.
B
Policy
policy
here
so
we
have
this
server
resource
which
deals
with
grpc
connections
here,
so
the
port,
anything
that
has
a
port
named
grpc
and
that
uses
the
grpc
protocol
applies
to
this.
In
our
case,
that's
the
emoji
and
the
voting
pods.
A
B
B
B
B
And
it
is
not
working
actually
so
that
both
that
bot
on
the
moji
bottle
two
is
not
communicating
with
the
web
part
on
emoji
model
102,
but
on
emoji
boto.
You
can
verify
that
checking
it's
yamo
here.
B
B
So
there's
a
special
environment
variable
here
web
host.
That
indicates
where
it
should
direct
its
connection.
So
we
didn't
replace
this
when
we
installed
this,
so
it's
still
pointing
to
the
old
namespace
and
that's
why
it
is
getting
its
connections
denied
and
okay.
One
second.
B
B
So
this
is
all
the
visibility
you
get
by
default
to
catch
all
these
deny
services.
Buy-In
does
offer
this
sas,
offering
called
boeing
cloud,
which
gives
you
a
more
detailed
report
on
all
these.
You
can
set
up,
alarms,
notifications
to
email,
slack
or
whatever,
whenever
one
of
these
policies
gets
violated,.
B
B
Is
specific
that
I
just
demonstrated
you
can
follow
again
in
the
blog
post
that
I
posted
in
the
buoyant
blog,
I'm
going
to
paste
the
url
in
a
moment
I
just
mentioned
about
buying
cloud.
B
A
B
A
Me
my
voice
is
a
bit
wonky
today,
so
there
was
a
question
about.
Does
this
setup
take
care
of
a
root,
ca
verification,
or
is
it
limited
to
the
network
columns.
B
Sorry,
where
is
that
question?
I
don't
understand
that
way.
A
It
was
from
from
linkedin
yeah
during
when
we
were
talking
about
the
the
first
question
or
the
two
first
questions.
But
if,
if
if
it's
kind
of
is.
A
Or
if
the
the
user
is
still
listening
in
you,
you
can
clarify
the
question
and
answer
it
a
bit
later.
B
So
the
what
the
you
are
guaranteed
here
is
that
when
you
receive
a
connection
from
another
pod,
its
workload
identity
is
what
it
claims
it
is,
and
we
use
the
root
certificate
to
validate
that,
because
all
the
certificates
of
the
pots
are
rooted
at
the
truss
root,
not
sure.
If
that
answers.
The
question.
A
Great,
if,
if
you
want
more
clarification,
linkedin
user
just
send
another
question
in
and
we'll
get
to
it
soon,
great
so
far,
no
worries
so
another
one
from
sundar
authorization
policy.
How
do
you
relate
this
to
author
2
and
identity
management,
with
tools
like
keith
bloke.
A
B
I'm
not
familiar
with
key
cloak
in
linkery,
we
limit
ourselves
again
to
workload
identities.
I
don't
know
if
key
cloud
key
clock
can
be
configured
to
use
service
accounts
as
identities.
If
it
is,
then
I
guess
it
would
work.
Fine.
B
Yeah,
that's
that's
where
the
root
where
the
truss
is
rooted
at
as
the
name
implies
so
yeah.
If
your
root
certificate
is
compromised,
there's
nothing
you
can
do
so.
That's
why.
The
first
thing
you
have
to
avoid
is
storing
the
key
anywhere
inside
your
cluster.
The
private
key.
A
Great
and
then
there
was
the
last
audience
question
so
far,
which
way
do
you
prefer
one
certificate
for
all
workload
or
one
for
each
segment
and
what
kind
of
trade-off
do
you
think
you
will
have
given
that
we
have
already
new
capability.
B
A
Great
and
then
I
think
there
was
a
continuation
from
the
authorization
policy
question.
So
if
ignoring
key
cloak,
how
do
you
do
our
role-based
access
control
in
linkedin.
B
Linkardi
doesn't
offer
anything
specific
to
our
back.
It
just
relies
on
whatever
you
set
up
with
kubernetes
yeah.
One
of
the
goals
of
linkerid
is
to
try
to
leverage
as
much
as
possible
the
kubernetes
primitives,
without
trying
to
invent
so
many
things
on
top
of
it.
So
our
back
would
just
work
as
it
should.
Yeah,
mtls
and
authorization
policy
is
really
separate
from
our
back,
because
this
is
at
the
really
at
the
application
level.
Rbac
is
more
lets.
B
You
define
what
you
can
do
against
the
kubernetes
api,
not
so
much
as
within
the
app
the
connections
within
the
app
itself.
A
Great,
so
that
was
it
for
the
audience
questions.
There
are
a
few
questions
that
I
want
to
ask,
but
if
there's
any
more
from
the
audience,
would
you
have
a
bit
of
time
for
those
as
well
so
keep
on
coming?
Thank
you
so
much
for
them.
So
far
so
a
question.
What
kind
of
certificate
management
is
required
to
do
this.
B
Okay,
it's
a
very
simple:
you
have
to
provide
the
trustworthy
and
an
issuer
that
is
still
derived
from
it,
and
you
just
have
to
make
sure
that
you
rotate
that
whenever
it's
needed
there's
a
linkard
check
command.
That
will
warn
you
whenever
that
expiration
date
is
closed.
B
Usually
what
people
in
production
do
is
to
provide
these
through
external
specific
tools
like
cert
manager,
that
I
also
mentioned
that
will
generate
and
rotates
rotate
the
certificates
automatically,
and
so
it's
very
easy
to
integrate
that
with
linkery,
and
there
are
also
the
cert
manager
has
also
some
optional
hooks
that
you
can
also
use
in
link
in
linkery,
so
yeah.
I
I
think
certain
manager
for
now
is
the
best
practice
regarding
certificate
management.
B
B
I
think
it
would
be
hard
for
in
the
example
that
we
securing
up
just
a
single
namespace,
because
you
don't
have
a
way
to
express
which
workloads
you're
interested
in
besides
therapy,
which
is
something
that
can
change.
So
I
would
recommend
that
you
use
tools
that
are
higher
up
the
stack
as
possible,
so
you
can
better
express
things.
A
B
Yeah,
that's
interesting.
Emoji
butter
indeed
does
use
http
by
default,
but
you
have
mtls
on
top
of
that,
so
the
connections
are
still
encrypted.
There's
http
on
the
lower
layer,
but
that's
wrapped
around
ntls.
So
it
doesn't
matter
if
the
lower
layer
is
not
encrypted
itself.
We
don't
do
autumn.
Besides
that,
we
don't
touch
what
goes
under
the
mtls
layer.
B
You
could
so
we
don't
do
any
kind
of
upgrade.
In
that
sense,
you
could
you
could
have
your
connections
be
tls
from
the
get-go
and
linkery
will
just
let
them
through
well,
they
it
will
wrap
them
as
well
mtls,
so
it
can
provide
some
the
workload
identity,
but
it
works
just
fine
as
if
they
were
not
encrypted.
A
Great,
we
have
a
few
minutes
left
so
final
call
for
questions
from
the
audience
and
final
question
from
me.
So
how
do
I
ensure
that
I
always
know
which
communication
is
a
melody
is
and
which
isn't.
B
Okay,
we
showed
that
a
little
bit
with
both
a
command
in
in
the
console
there's
this
tab.
That
shows
you
a
sample
of
all
the
connections
going
through
some
specific
resource,
and
that
will
tell
you
whether
they're
mtls
or
not.
You
also
have
your
the
dashboard,
the
lingerie
dashboard
that
will
show
you
some
green
checks
for
a
given
resource,
the
incoming
and
the
outgoing
connections,
whether
they're
encrypted
or
not,
and
if
you
said
like
we
saw,
we
set
some
policies
to
allow
incoming
connection
from
the
namespace.
B
A
Great,
thank
you
so
much,
no
new
questions
from
the
audience,
but
we
answered
quite
a
many
already,
so
no
worries
we
got.
We
got
through
them
all,
but
yeah
time
to
wrap
up.
Then
you
can
obviously
always
continue.
The
discussion
in
the
cncs
slack
channel
for
cloud
native
live
everyone
so
tune
in
there.
If
you
want
to
chat
with
everyone
about
these
topics,
so
just
to
wrap
things
up
thanks
everyone
for
joining
the
latest
episode
cloud
native
live.
A
It
was
great
to
have
a
session
about
locking
down
your
cluster,
really
love
the
audience,
interaction
and
the
questions
from
the
audience.
Thank
you
so
much
and
as
always,
we
bring
you
the
latest
cloud
native
code
every
wednesday.