►
From YouTube: Hands-on Workshop: Zero Trust Networking in Practice with a Service M... Jason Morgan & Ashley Davis
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Hands-on Workshop: Zero Trust Networking in Practice with a Service Mesh Workshop - Jason Morgan, Buoyant & Ashley Davis, Jetstack
In this hands-on workshop, participants will learn the basics of adopting a zero-trust approach to Kubernetes network security using a service mesh. Topics will include encryption, authentication, and authorization of traffic within the cluster; PKI considerations and setup for in-cluster and cross-cluster mutual TLS; applying a deny-by-default / principle of least privilege approaches to authorization; the relationship between zero-trust and perimeter security; and more. Participants will learn the elements of overall Kubernetes security that must be in place before a service mesh can be effective, including a basic threat model for Kubernetes clusters as a whole. This workshop will use Linkerd, cert-manager, and Kyverno but the techniques will be applicable to many different projects.
A
All
right,
so,
if
you
haven't
seen
it
yet
we're
gonna
do
live
Hands-On
stuff
with
everybody
today,
so
you're
going
to
need
to
be
using
a
kubernetes
cluster.
It
would
be
convenient
if
you
could
get
one
that
wasn't
located
on
your
laptop
and
the
folks
at
sivo,
giving
away
credits
for
people
that
sign
up
at
that
link
if
anyone's
planning
on
doing
this
and
you
need
the
link,
raise
your
hand,
otherwise
we're
going
to
move
on
pretty
quickly.
Okay,
so
we'll
wait
a
bit.
A
Let
me
know
when
you're
done
and
then
we'll
put
it
in.
If
you
are
done,
that
the
actual
live
Workshop
portion
we'll
be
using
that
GitHub
repo.com
you
can
clone
it
or
well,
you'll
need
to
clone
it.
Actually,
so
you'll
need
to
clone
it,
but
you
could
also
visit
that
URL
on
GitHub
and
it'll
have
the
instructions
on
a
nice
friendly
to
read
readme
file,
all
right,
because
we're
going
to
be
doing
you're
only
going
to
be
typing
stuff
in
from
that
readme
doc.
A
B
A
A
A
B
Yeah
hi
everyone,
I'm
Ash,
Ashley
I,
don't
mind
either
way,
I'm
a
software
engineer
at
jetstack,
which
is
the
originating
company
for
cert
manager,
so
I'm.
Also
a
cert
manager,
maintainer
I'm
kind
of
a
TLS
certificate,
cryptography
kind
of
person
I
mean
that
mold
I've
really
been
looking
forward
to
this
I've
got
to
say
it's.
My
first
like
in-person
thing
like
this.
This
is
a
bit
of
a
milestone
for
me.
It's
really
cool
to
have
people
here.
A
All
right,
so,
let's
start
with
why
use
cryptographic
identity
so
that
the
basic
talk
here,
the
the
theme
that
we're
going
to
get
at
is
when
you're
trying
to
secure
traffic
between
workloads
in
a
kubernetes
class
there.
We
think
the
only
thing
you
should
be
relying
on
is
the
cryptographic
identity
of
the
pod
I
think
that's
really
important,
and
that
is
fundamental
to
being
able
to
securely
communicate
within
a
cluster
right.
A
It
relies
on
delegating
trust
to
third-party
authorities.
Right
essentially
gives
us,
like
the
the
source
of
our
trust
for
applications.
Becomes
this
chain
of
certificates
right
that
are
based
on
something
that
we
can
all
every
workload
can
rely
on
yeah
and,
of
course,
you
can't
go
visit
your
bank
or
Netflix,
or
look
at
these
slides
or
access
GitHub,
or
do
any
of
this
stuff
without
TLS.
So
we
feel
like
it's
a
pretty
good
foundation
to
build
on
and
with
that
we're
going
to
ask
Ashley
Ashley.
A
B
To
be
honest,
I'm
not
sure,
there's
many
people
in
the
world
who
would
say
they
can
use
open
SSL,
it's
very
tricky
tool,
so
yeah
we
asked
earlier
if
anyone
would
use
certain
manager
before
and
there
were,
a
few
hands
went
up,
which
I
think
we
would
kind
of
expect,
because
a
lot
of
people
have
heard
of
search
manager
right.
It's
it's
almost
like
a
standard
part
of
a
kubernetes
cluster.
B
It's
not
standard
but
like
people
treat
it
like
that
they
install
it
at
the
beginning
of
when
they're
setting
up
a
cluster
and
that's
super
cool.
The
idea
is,
if
you've
not
heard
of
it
before,
and
you
don't
need
to
have
heard
of
it
to
get
through
this
Workshop.
The
idea
is,
if
you've
used,
kubernetes
you've
written
something
like
a
pod
or
a
service
or
a
deployment
or
some
yaml.
That
will
specify
what
you
want.
B
Cert
manager
adds
that,
but
it
does
it
for
certificates
and
issuers
and
the
kind
of
Concepts
around
that
sort
of
stuff,
and
it
ends
up
putting
your
certificate
into
a
kubernetes
secret
where
it
can
be
used
by
your
application.
There's
all
the
all
the
plugins
you
could
really
think
of
whatever
you
want
to
use
to
issue.
Your
certificates
was
probably
something
for
it.
B
One
thing
that's
really
cool
is
that
we
actually
just
hit
incubating
in
the
cncf
I've
been
a
son,
hey
we've
been
a
Sandbox
project
since
mid-2020
I
think
if
I
remember
the
history
right
and
yeah
we
made
incubating
in
October
this
year.
So
that's
it's
very
recent.
It
still
feels
like
an
announcement.
Every
time
I
say
it.
A
All
right,
so
we
talked
a
little
bit
about
cert
manager
right
and
like
an
important
concept.
Insert
manager
is
like,
what's
the
what
allows
us
to
actually
get
our
individual
certificates?
Do
you
mind
sharing
a
little
bit
about
issuers
in
cert
manager
and
how
they
relate
to
what
we're
going
to
be
doing
today,
I.
B
B
We
kind
of
broadly
split
them
into
two
types
right:
there's,
there's
the
one
that
most
people
actually
use
server
manager
for
which
is
to
get
certificates
from
external
apis
like
let's
encrypt,
that's,
probably
what
you
want
to
you
want
a
public
facing
certificate.
It
also
is
probably
what
you
want
if
you
want
to
store
your
ca
certificates,
your
issuing
certificates
in
something
like
how
she
got
Vault
or
venify
TBB,
or
anything
like
that
sort
of
outside
of
your
cluster,
but
sir
manager
can
also
do
in
cluster
issuance
as
well.
A
Okay,
and
so
with
that,
let's
talk
about
what
can
we
do
with
some
of
these
certificates
and
a
little
bit
of
an
overview
of
what
is
mtls
or
Mutual
TLS,
so
regular
TLS?
You
have
a
client
and
a
server.
So
when
you
go
to
GitHub
right,
your
computer
is
a
client
or
your
browser's,
a
client
and
the
server.
A
You
know,
since
we're
already
doing
a
TLS,
handshake.
You'll
see
this
doesn't
really
add
or
doesn't
really
add
a
lot
of
overhead
and,
like
the
reason
you
don't
use,
Mutual
TLS
when
you're
talking
to
GitHub
is
GitHub,
doesn't
care
about
the
clients
right.
It
can't
know
about
you
and
it
can't
have
can't
sit
there
and
figure
out
who
everybody
is
that's
coming
in.
That's
what
authentication
is
for
right
in
our
kubernetes
cluster.
C
B
One
thing
that
that
brings
to
mind
is
that
you
need
a
lot
of
certificates
to
achieve
this
right.
Every
every
pod,
in
theory,
is
going
to
need
a
certificate
and
therefore
an
identity,
to
use
when
it's
authentic,
again
authenticating
against
other
services.
That
brings
up
the
problem
of
how
do
you
manage
all
of
those
identities
and
those
certificates
and
certain
manager
can
do
the
mechanical
aspect
of
that,
but
it's
useful
to
have
something
else
which
will
help
with
managing
the
identities
at
a
different
level.
I
think
that's
where
Jason
comes
in.
A
Yeah,
so
let's
talk
about
Linker
D,
so
Linker
D
is
a
cncf
project.
It
is
the
only
service
mesh
to
hit
graduated
status
within
the
cncf,
so
it
means
it's
on
par
with
you
know
things
like
kubernetes
when
it
comes
to
maturity,
it's
created
by
the
folks
over
at
buoyant
company.
That
pays
me
to
do
talks
like
this
been
around
for
a
while
and
it's
in
use
by
small
startups
by
really
big
companies.
A
A
Is
an
example
of
generic
kubernetes
cluster
with
an
application,
so
we
have
an
Ingress
which
could
be
nginx
could
be
you
know,
Ambassador
could
be
whatever
pick
your
Ingress,
then
we've
got
a
web
front
end
and
we've
got
two
back-end
Services,
Foo
and
bar.
So
the
way
Linker
D
works.
Is
you
install
a
control
plane?
This
is
what
we're
going
to
do
today.
A
To
have
information
about,
how
is
this
thing
performing
be
able
to
make
intelligent
load,
balancing
decisions
stuff
like
that?
That's
beyond
the
scope
of
the
workshop,
but
it
will.
The
liquidity
proxies
are
going
to
intercept
your
traffic,
do
some
stuff
with
it
and
that's
going
to
be
that's
going
to
be
the
core
of
how
that
works
and
you're
going
to
interface
with
liquidity
through
its
control
plane
and
with
that
I
hope.
You've
had
enough
slides
because
now
we're
going
to
go
into
the
demo
and
actually
live,
do
our
Workshop.
A
Great
all
right,
so,
if
you
haven't
done
it
yet,
no
wrong
one,
if
you
haven't
done
it
yet
go
to
oinio
cert
manager,
Workshop.
That
was
that
link
on
the
being
slide,
and
we
can
pull
that
back
up.
If
you
need
it
and
we're
going
to
check
out
this
readme
right,
we're
going
to
be
going
through
that
today,
as
this
exercise,
I'm
good
cool.
A
So
at
this
point,
if
you
have
questions
raise
your
hand
either
Ashley
or
myself
will
come
over,
we
also
have
Flynn
in
the
back,
we'll
be
happy
to
help
you
with
any
of
these
things.
If
you
run
into
problems
and
I'm
just
going
to
walk
you
through
the
steps
and
we're
going
to
do
them,
do
them
live
as
we
go,
sound
good.
B
A
A
A
if
you
need
some
help
getting
a
cluster
running,
please
let
me
know
and
we'll
be
over
to
you
in
a
few
minutes.
Okay,
so
for
those
of
you
that
have
a
cluster
running,
make
sure
that
you
have
Helm
Cube
CTL
curl,
you
might
want
JQ
and
openssl,
but
you
can
you
can
get
through
without
it
just
talks
about
k3d
and
root,
full
Docker
or
kind.
A
So,
let's
go
into
the
actual
step,
so
the
first
thing
I
want
you
to
do
those
of
you
that
have
a
a
cluster
we're
going
to
go
ahead
and
deploy
deploy
our
application.
So
this
is
going
to
be
the
demo
application
that
we're
actually
going
to
set
up
policy
for
so
first
we're
gonna,
we're
gonna,
take
this
app
and
then
we're
going
to
add
it
to
our
LinkedIn
mesh
and
then
we're
going
to
apply
some
policy
to
it
to
lock
down
who
can
access?
What
sound
good.
A
All
right,
so
we're
going
to
start
here,
you
can
see
I've
got
a
couple
terminals
open
we're
going
to
be
doing
our
work
on
the
left
side
and
we're
going
to
be
showing
things
about
our
cluster.
On
the
right
hand,
side
can
focus,
see
this.
Okay,
sorry
and
like
I
said.
Please
do
please
do
follow
along.
So
the
first
thing
I'm
going
to
do
is
I'm
going
to
create
my
bookshap
namespace
I'm,
going
to
go,
download
and
run
my
demo
application.
A
All
right
see
on
the
right
side:
I've
got
some
components.
Creating
books.
App
is
a
fairly
simple
application.
It's
got
a
traffic
generator,
it
has
a
web
front
end
and
has
two
back-ends
books
and
authors
that
allow
us
to
manage
who's
talking
to
what
let's
go
back
right
now,
we're
going
to
want
to
we're
going
to
want
to
actually
install
cert
manager,
so
we're
going
to
use
Helm
for
all
of
our
installs.
A
Today
in
general,
we
recommend
that
when
you're
running
Lincoln,
especially
if
you're
going
to
run
it
in
a
in
a
production
or
near
production
scenario,
that
you
look
at
using
Helm
to
manage
your
liquidy
installs
same
is
true
for
cert
manager,
everyone
familiar
with
Helm
or
fairly
familiar
with
them.
Do
you
want
me
to
walk
through
what
the
help
commands
do
all
right?
Well,
I'm,
just
gonna!
Do
it
anyway,
because
I'm
paranoid.
A
All
right
next
we're
going
to
actually
install
cert
manager
and
let's
talk
about
what
this
command
does
so
we're
doing.
Helm
install
the
search
manager
package,
we're
referencing
the
actual
package
name,
so
you
give
it
a
name
than
than
the
name
of
the
package
right
or
the
reference
of
the
package
within
the
Repository.
A
C
B
A
A
A
I
remember
how
to
use
a
computer
all
right
now
that
we've
done
that
we're
going
to
install
another
cert
manager
component,
called
cert
manager,
trust
we're
using
a
different,
install
command
just
because
we
like
to
keep
you
on
your
toes,
so
here
we're
using
the
helm,
upgrade
command
with
the
install
flag.
So
this
lets
you
it.
Basically,
it
would
upgrade
it
if
it's
there
and
if
it's
not
there,
it'll
do
the
install
for
you.
It's
pretty
handy.
A
B
I
did
the
wrong
one
there's
a
bit
of
background
on
the
tool,
trust
manager,
it's
quite
a
new
project,
it's
kind
of
something
that
we've
been
focusing
on
a
lot
recently.
If,
if
there's
something
that
I
should
get
as
a
tattoo,
it's
getting
a
certificate
is
only
half
the
problem.
That
would
be
the
chest
tattoo.
That
I
need
to
get
right
like
trusting.
That
certificate
is
the
other
half
of
the
problem
and
there's
not
much
done
currently
to
talk
about
that
or
solve
that
problem.
B
There's
some
Upstream
work
going
on
for
it
in
kubernetes
itself,
but
actually
we
really
want
to
get
involved
and
like
help
solve
that
problem
and
Trust
manager
is
a
big
part
of
that.
So
it
helps
you
to
get
your
cluster
to
a
point
where
you
can
trust
certificates
effectively,
and
that
goes
back
to
what
Jason
mentioned
earlier
about
trust
delegation
and
having
third
parties
verify
the
certificate
you've
got.
A
All
right
with
that
done
we're
going
to
go
ahead
and
create
a
namespace
for
our
Linker
D.
Install
we're
doing
this
now,
because
we're
about
to
we're
about
to
tell
cert
manager
to
create
a
bunch
of
certificates
for
it
and
they're
going
to
need
a
home
and
specifically
their
home,
is
going
to
be
the
Liberty
namespace.
A
B
The
way
we
do,
that
is
to
link
back
to
those
issuers
that
I
talked
about
earlier.
We
have
issuers
and
cluster
issuers,
the
distinction
isn't
so
important,
but
clusterisha
was
applied
to
every
every
namespace,
whereas
issue
as
a
namespace.
So
here
we're
just
going
to
use
a
cluster
issuer,
so
we
create
a
self-signed
issuer
which
does
pretty
much.
Nothing
is
incredibly
simple.
B
It
just
tells
the
certificate
to
sign
itself
using
its
private
key
that
makes
it
a
root
certificate
and
that
root
certificates
for
several
reasons
and
what
we
use
for
the
basis
of
trust
within
TLS.
So
we
we
want
one.
If
you
were
doing
this
actually
in
production.
I
would
maybe
suggest
that
you
generate
this
outside
of
your
cluster
in
in
pki.
That's
in
installations,
I've
managed
before
in
production
a
pretty
big
companies.
B
They
we
tended
to
use
like
a
Raspberry
Pi
and
do
this
entirely
offline,
like
we'd
sold
like
desolder,
the
ethernet
port,
so
you
couldn't
go
online
with
it
and
generate
it
all
offline,
we're
not
going
to
walk
that
mile.
Here
we
haven't,
bought
everyone,
a
Raspberry
Pi
and
we're
not
going
to
damage
a
load
of
Raspberry
Pi's
because
they're
really
hard
to
get
at
the
moment.
B
So
we'll
just
do
it
in
our
cluster,
because
that's
fine
here
this
certificate
is
kind
of
the
core
of
how
cert
manager
Works
we're
asking
for
a
certificate
with
a
particular
name
telling
cert
manager
with
the
secret
name
where
we
want
to
store.
It
will
need
to
last
for
quite
a
while,
because
root
certificates
are
a
bit
of
a
pain
to
rotate,
so
you
they
tend
to
last
longer
and
that's
why
we
make
them
more
secure
and
we
also
specify
which
issuer
we
want
to
use
to
issue
this
certificate.
B
We
then
use
what
we
call
a
CA
issuer.
It's
kind
of
hard
to
see,
but
you'll
see
on
on
line
49.
There
CA
issuer
is
using
a
different
certificate
in
the
cluster
to
issue
other
certificates.
So
in
this
case
we
were
creating
a
c
or
CA
issuer.
Using
that
root
certificate,
we
generated
to
generate
the
intermediate
certificate
that
we
need
now.
So
this
is
a
process
that
you
might
need
to
repeat
in
the
future,
someone's
really
enjoying
the
workshop
yeah.
B
This
is
a
process
that
might
need
to
be
repeated
because
the
intermediate
certificate
won't
last
as
long
as
the
route.
If
it
did,
there
wouldn't
be
any
point
in
having
two
certificates
in
the
first
place.
You
just
use
the
one
so
yeah
this
intermediate.
Actually
you
see
here
is
only
48
hours
long
and
we,
you
can
see
we're
referring
to
that
issue,
that
cluster
issuer
sorry,
which
represents
the
root
certificate
we
generated
and
there's
a
bunch
more
tlse
stuff
that
is
in
there.
B
We
don't
really
need
to
worry
about
it
apart
from
is
CA
at
the
top,
because
we
do
need
to
make
sure
that
this
certificate
is
marked
as
a
CA
certificate.
So
it's
able
to
issue
others,
that's
really
all
we
need
to
do
to
set
up
the
the
issuance
certificates
that
we
need,
so
we're
not
going
to
be
writing
yaml
for
the
individual
certificates,
for
the
components
for
the
pods
that
we're
going
to
run,
because
that's
something
that
Linker
D
will
do
using
this
certificate
that
we're
generating.
B
So
it's
just
the
cas
that
we're
using
cert
manager
for
here,
but
the
one
last
final
step
we
need
is
to
generate
a
bundle.
So
this
is
coming
back
to
that
trust
problem,
and
this
is
actually
the
trust
manager
component.
That's
coming
in
to
help
we're
taking
the
ca
certificate
that
we
generated
the
route
and
we
need
to
copy
that
into
the
Linker
D
namespace,
so
it
can
be
injected
into
sidecars
and
used
for
trust
purposes.
B
So
to
summarize
all
of
that
tlse
certificate,
stuff
I've
just
said
we
have
the
root
certificate,
which
is
the
basis
of
all
trust
and
that's
the
foundational
for
our
service
measure.
Only
the
root
certificate
needs
to
be
distributed
and
redistributed
using
trust
manager.
Here,
we've
used
cert
managers
to
generate
that
route
and
to
generate
an
intermediate
off
that
route
and
the
intermediate
will
be
rotated
semi-frequently
because
it's
short-lived
and
that's
the
reason
we
have
it,
because
it
may
need
to
be
rotated
more
frequently.
Yeah.
A
So,
right
before
this
Workshop
earlier
today,
we
did
a
workshop,
the
Liberty
folks
in
a
workshop
on
running
and
production
right
and,
if
you're,
using
something
like
cert
manager
to
handle
this
intermediary
certificate.
This
issue,
where
that
you
use
it
dramatically,
simplifies
operations
and
it
lets
you
do
something
like
set
a
40-hour,
48
hour
lifespan
on
your
cluster
certificate
and
have
that
be
like
essentially
trivial
operation
for
your
cluster
admin
right.
A
So
we
can
set
up
clusters
with
this
basic
configuration
know
that
any
individual
cluster
will
never
have
an
issue
or
last
more
than
48
hours,
and
it
will
rotate
for
us
automatically
without
us
doing
any
work.
And
then,
if
you're,
starting
to
think
about
doing
things
like
multi-cluster
and
Linker
d
right,
each
individual
cluster
inside
your
environment
will
only
be
able
to
be
trusted
for
maximum
48
hours.
At
a
time.
A
Are
we
still
able
to
follow,
along
with
the
with
the
readme
feel,
if
you
do
feel
free
to
go
ahead
right,
do
feel
free
to
go
ahead
and
we'll
just
talk
about
it
when
you
get
stuck
all
right,
so
we
just
looked
at
the
we
looked
at
the
file,
we
can
actually
do
some
inspection
on
the
certificates.
What
do
we
get
and
Ashley's
going
to
tell
us
a
little
bit
about
what
what
this
is
telling
us?
Sorry,
let
me
do
this
again,
less
so
that
you
can
talk
about
it.
B
So
yeah
this
this
I
will
admit,
is
a
mess
like
we're
using
openssl
here,
because
most
people
have
it
installed.
There
are
other
tools
for
viewing
these
things.
I
mean
there's
ways
to
get
open
SSL
to
print
this
out
in
a
prettier
way.
But
who
knows
how
to
do
that?
It's
a
pretty
complicated
tool,
so
I'm
not
going
to
dive
into
every
line
here
and
I.
B
That
means
there's
no
other
way
to
trust
this,
except
explicitly,
but
we're
not
going
to
go
too
deep
into
the
details
of
how
TLS
trust
works,
but
unless
you're
interested,
then
you
can
come.
Ask
me
I
always
like
to
talk
about
it,
but
it's
important
that
we
need
something
to
distribute
this
trust
for
others
to
be
able
to
consume
it,
because
this
is
self-signed.
B
B
This
time
so
yeah
again
it's
a
mess.
It's
still
a
mess,
it's
still
I
hope
it
doesn't
SSL.
This
is
the
intermediate
certificate,
so
you'll
notice
in
the
command
that
Jason
just
ran.
This
is
looking
at
the
link
of
these
namespace
now
because
that's
where
the
certificate
is
and
crucially
you'll
see
that
this
time
the
issuer
and
the
subject
are
different,
because
this
was
issued
by
the
root
certificate
and
the
issue,
obviously,
is
the
the
name
of
the
root
certificate.
B
Again
importantly,
this
is
a
CA.
It's
you
see
at
the
bottom
there,
but
there's
really
not
much
more
to
say
about
it
other
than
to
notice
that
the
validity
duration
of
this
is
very
low.
So
if,
if
something
goes
horribly
wrong
and
this,
the
private
key
for
this
certificate
was
exposed,
the
absolute
worst
case
is
that
someone
could
use
it
for
two
days
and
revocation
is
actually
a
pretty
difficult
thing
to
do
with
certificates
in
in
production,
so
the
shorter
live
just
certificates
are
the
less
blast
radius.
B
A
Okay,
so
now
we're
actually
going
to
do
a
link
ready,
install
so
we're
gonna.
Today
we're
gonna,
install
linkready2.12.2,
I'm,
pretty
sure
2.12.2
I'll
double
check
what
version
I
actually
put
in
there,
but
we're
going
to
solve
liquidy
and
as
of
LinkedIn
212.
The
core
control
plane
of
linker
D
is
installed
with
two
different
Helm
charts.
We
have
one
specifically
for
the
Linker
dcrds
and
one
for
the
liquidy
control
plan
itself.
So
that's
what
we're
doing
here
and
then
there's
a
lot
of
comments.
A
There's
a
ton
of
comments
in
there
read
me
about
what
we're
doing
and
why!
So,
if
you
have
more
questions
or
if
I
miss
something,
please
do
check
out
what
we're
saying
in
there.
So
we're
gonna.
Do
the
crd
install
that's
happy,
we
see
no
new
containers
get
created
and
then
we're
going
to
go
ahead
and
install
Linker
d
a
little
bit
about
this
Command
right.
When
we
install
Linker
d,
we're
going
to
tell
it
we're.
B
A
Default,
install
behavior
and
we're
going
to
say:
Hey,
listen,
set
the
identity
external
CA,
and
this
is
this-
is
the
scheme
that
we're
going
to
use
to
figure
out
what
we're
doing
and
then
we
specialize
specify
the
chart.
This
tells
us
tells
it
to
look
for
Secrets
already
existing
in
the
Liberty
namespace
that
are
going
to
allow
it
to
actually
start
giving
it
certificates
to
the
individual
workloads
again.
This
is
the
last
time
I'll
talk
about
the
hierarchy.
Right.
A
You've
got
a
Routier
which
establishes
trust
for
linkerty
at
all
right
and
you
would
use
a
root
C8
to
sign
the
individual
cluster
certificates
for
each
Linker,
D
install
that
you
use
right
and
then
inside
the
cluster
we
have
our
intermediary
or
what
we
call
in
lucrative
terms
call
it
our
issuer
certificate
right.
That
is
the
certificate
that
Lincoln
will
use
to
create
individual
workload
certificates
so
that
they
can
trust
each
other
and
they
can
communicate
securely
over
the
network.
A
A
A
core
linkready
install
include
it's
three
basic
components:
we
have
the
component
of
liquidy
that
is
responsible
for
creating
these
identities,
for
using
all
these
certificates
that
we've
just
spent
the
last
35
minutes
talking
about
30
minutes.
Talking
about
right.
That's,
that's
the!
Let's
see:
identity
service.
We
have
the
proxy
injector,
which.
A
To
start
adding
the
link
ready
proxy
to
our
workloads
right
because
we're
not
going
to
Define,
not
Define
the
whole
proxy
in
the
ammo
you
just
Define
an
annotation
either
on
your
namespace
or
on
your
workload.
It's
going
to
say:
hey,
please
inject
the
proxy
on
these
things
and
that
the
proxy
injector
is
going
to
take
care
of
that.
And
then
last
but
not
least,
we
have
the
destination
service.
B
C
B
A
It's
one
of
the
few
ways
that
you
can
get
linkready
to
cause
your
production
traffic
to
stop.
It
is
something
we
can
safely
ignore
if
we're
using
something
like
cert
manager
to
rotate
our
certificates.
It's
certain
manager
is
one
of
those
things
where
the
automation
makes
your
life
dramatically
easier.
A
So
now
that
we've
done
that
we're
actually
going
to
install
the
Linker
dashboard,
so
this
is
called
Linker
dviz
we're
going
to
use
this
UI
a
little
bit
during
the
demo
and
I'm
going
to
run
some
commands.
That'll
help
us
see
what's
going
on
with
our
traffic
as
we
actually
start,
locking
down
our
cluster.
C
B
B
A
A
A
So
with
that
we're
going
to
run
Linker
D
check
again,
we
are
actually
just
going
to
run
like
an
eviz
check,
so
you
can
do
checks.
Language
text.
Cli
has
got
a
couple
a
couple
idiosyncrasies.
You
can
check
all
of
linker
D
or
you
can
check
a
specific
component
in
this
case,
we're
just
going
to
check
the
viz
component.
A
It's
good
to
go
close
this
out
and
now
that
we've
got
it
right,
we're
actually
going
to
add
an
application
to
the
service
mesh
I
talk
about
a
lot
in
the
text
right,
but
essentially
what
we're
going
to
do
here
is
we're
going
to
tell
the
cube
API
that
these
ponds
need
to
be
injected,
and
then
our
proxy
injector
is
going
to
watch
for
things
people
trying
to
create
pods.
If
they
see
someone
trying
to
create
a
pod
with
this
annotation,
it's
going
to
it's
going
to
mutate
it.
A
C
A
A
A
This
makes
sense.
What
we're
doing
everyone
who
is
following
along
have
gotten
at
least
to
this
point
awesome.
Thank
you
folks.
We
can
see
on
the
right
hand,
side
it's
actually
happening
pretty
fast,
but
I
have,
whereas
before
I
had
a
bunch
of
containers
running
or
a
bunch
of
PODS
running
with
one
container
per
pod,
now
they've
all
been
destroyed
and
they
all
have
two
containers
per
pod.
That
second
container
is
the
Lincoln
proxy.
So
what's
happened.
A
A
So
one
of
the
things
that
we
can
do
is
we
can
see
details
about
the
traffic
between
these
applications
I'm
going
to
make
this
a
little
bit
smaller
and
hope
that
you're,
seeing
it
locally
so
suddenly
without
me,
changing
anything
on
my
application
without
creating
any
custom
resource
definitions
without
doing
anything,
fancy
I
just
added
this
injection
everything's
still
talking
to
each
other.
It's
just
now
behaving
a
little
bit
better
than
before,
and
I
can
see.
The
percentage
of
the
requests
hitting
each
API
that
are
successful.
A
I
can
see
the
latency
and
I
can
see
the
volume
of
traffic
in
my
environment.
It's
important
because,
as
we
go
into
the
policy
side
of
actually
locking
down
our
cluster,
we're
going
to
break
all
this
traffic,
and
so
now
we
can
see
what's
happening,
live
and,
last
but
not
least,
we're
gonna
run
on
watch
command.
A
A
A
A
This
makes
sense,
quick
dive
into
policy
in
Linker
d,
right,
Linker
D
handles
the
auth
Z
side
of
auth,
N
and
Aussie,
or
off
side,
I'm
going
to
say
Aussie,
so
that
I,
don't
we
delegate
like
link
the
way
Lincoln
e
works,
and
one
of
the
things
that
allows
us
to
keep
linkerty
fairly
simple
to
use
is
that
we
rely
on
kubernetes
Native
objects
wherever
possible
to
do
stuff.
So
when
we
Route
traffic
between
services
and
kubernetes,
we
use
kubernetes
Services
when
we
figure
out
the
identity
of
a
pod.
A
We
go
for
the
identity
of
the
Pod.
That
kubernetes
assigns
it
right.
So
our
our
authentication
mechanism
is
the
kubernetes
API
and
specifically
the
service
count
that
you've
assigned
to
your
individual
workloads
and
that's
how
the
that's,
how
the
certificates
are
going
to
get
created,
they're
going
to
be
based
off
that
that
surface
count
that
you
gave
your
pod
so
right
now
we
see
a
lot
of
traffic
flowing
through.
Nothing
is
unauthorized.
We
have
a
good
bit
of
traffic
that
is
authorized.
A
Okay,
great
and
we're
gonna
totally
mess
that
up
as
we
go
here
we
can
run
another
link.
Would
you
check
because
I
like
to
show
off
how
fancy
this
tool
is?
We
can
run
linkage
again
in
the
books,
app
namespace
just
to
validate
that
our
proxies
are
in
good
shape
and
look
at
that
it's
happy,
but
of
course,
that
issuer
certificate
is
going
to
expire
in
less
than
60
days,
so
watch
out.
A
All
right
so
I
put
in
the
readme
the
commands
that
I
just
put
under
that
watch.
If
you
have
a
terminal
that
you
can
split
it
to
the
side,
I
would
really
highly
recommend
setting
up
Linker
D,
Vis,
stat,
deploy
and
Linker
Dave
is
auth
z,
deploy
in
separate
terminals,
because
it's
I
find
it's
really
useful
to
watch
what
happens
as
I
apply
policy.
A
Great
with
that
I'm
going
to
send
the
applications
and
books
app
into
namespace
jail,
so
the
first
half
of
this
thing
or
I
guess
the
whatever
middle
third
of
this
is
going
to
be
isolating
the
applications
in
the
books
at
namespace.
So
they
can
only
talk
to
each
other.
Well,
well,
I'm
lying
actually
a
little
bit,
so
they
can
only
talk
to
each
other
and
they
will
allow
our
our
likerty,
Vis
or
dashboard
to
figure
out
how
they're
doing
right
get
some
statistics
about
how
they're
performing.
B
A
A
A
One
thing
that
you're
going
to
notice
is
after
I
set
that
annotation
nothing
happens
like
nothing
changes,
I've
still
got
traffic,
I,
don't
see
any
new
policy.
None
of
my
pod
suddenly
crashed
and
burned,
and
the
reason
that
is
is
that
default
annotation,
which
can
either
be
done
at
a
cluster
level
or
can
be
done
at
a
namespace
level
that
is
read
by
the
proxy
when
it
starts
so
in
order
to
have
it
take
effect
and
start
causing
us
problems,
we're
going
to
need
to
actually
restart
these
pods.
A
So
now
we're
going
to
see
our
traffic
crading
but
you're
actually
not
going
to
get
a
ton
of
details
on
that,
because,
while
the
components
of
books
app
can't
talk
to
each
other
anymore,
viz
actually
can't
talk
to
bookshap
anymore
either.
So
it's
not
getting
any
any
updated
details.
So
we've
well
and
truly
broken
this
I.
Guess
I!
Guess
we're
not
going
to
worry
about
that!
Oh
shoot!
I
did
want
that
sorry
give
one
sec.
A
Pawns
great
because
there's
going
to
be
one
more
thing
that
we're
going
to
want
to
know
about
our
pods.
So
now
that
we've
done
the
rollout
restart,
we
see
that
everything
came
back
up
and
is
actually
perfectly
fine.
That's
some!
So
one
thing
we
do
allow,
even
when
everything
else
is
banned
by
default,
Linker
D
will
explicitly
carve
out
exceptions
for
the
cubelet
to
do
liveness
and
Readiness
checks
on
your
pods.
So
that
means,
if
nothing
else,
Works
we're
at
least
going
to
allow
your
pods
to
start
okay.
A
The
Lincoln
viz
component
to
speak
to
our
individual
applications,
so
we
can
get
some
metrics
back.
So
let's
show
you
that,
and
by
now
we
should
have
yeah
great.
So
now
you
see
no
authorization
rules
on
the
bottom.
We
see
absolutely
no
traffic
for
our
environment
at
the
top
right
right
and
the
reason
that
is
one
because
there's
no
traffic
but
two,
because
our
dashboard
can't
talk
to
can't
talk
to
linkready
anymore.
A
So
what
we're
going
to
do
is
we're
going
to
create
two
manifests
and
I'm
going
to
read
we're
going
to
read
them
in
a
second,
but
first
I'm
going
to
define
the
admin
server
port
on
all
of
these
on
all
of
these
pods
right.
That
is
the
linkordy
admin,
port
and
I'm,
going
to
assign
a
policy
that
allows
our
Prometheus
incidents
and
our
metrics
API
to
talk
to
talk
to
that
admin.
So
let's
actually
read
that
out
manifest
Bookshop
allow
admin.
A
Was
it
I
just
did
this
oh
admin
server
there
we
go
so
just
to
talk
about
hierarchy
of
objects
and
linked
policy
so
or
even
stepping
back
a
little
bit
with
Liberty
by
default
to
get
Mutual
TLS
to
get
metrics
to
get.
You
know
the
way
it
makes
writing
decisions.
We
need
Zero,
Custom
resource
definitions.
A
When
you
add
in
policy
like
this
is
a
place
where
you
can
break
your
applications
and
where
you
have
to
start
getting
into
custom
resource
definitions.
So
it's
kind
of
like
like
Spider-Man,
you
know
like
with
great
power,
comes
great
responsibility
right.
If
you
want
the
power
policy,
you're
gonna
have
to
take
on
more
administrative
work
for
you
as
platform,
Engineers
I'm,
making
an
assumption.
A
Here,
work
in
and
around
platform
engineering,
okay
killer.
So
that's
what
I
was
hoping
to
see.
So
this
hierarchy
of
objects,
so
the
first
thing
that
we
have
so
we
have
our
custom
resource
definitions
are
servers,
hcp,
reps
mesh,
TLS,
authentication,
Network,
authentication
and
then
an
authorization
policy.
So
a
server
defines
a
port.
It
tells
linkerty
about
a
particular
port
and
how
it
works
in
this
case,
I'm,
creating
a
port
I'm,
creating
a
server
called
linkerty
admin
in
the
bookshap
namespace.
It's
going
to
find
all
the
pods,
whatever
your.
A
A
A
So
that's
going
to
explicitly
authorize,
Prometheus
and
tap
to
talk
to
our
workloads,
talk
to
workloads
on
the
Linker
admin
Port
right,
because
that
that
object
above
that
server
or
that
authorization
policy
that
binds
our
rule
about
mcls
to
the
port.
Okay,
so
we
have
Port
rule
rule
binding
with
the
the
authorization
policy
still
making
sense
killer.
A
All
right
so
now,
now
that
we've
done
now,
we've
done
this
actually
I
do
want
to
show
you
this
on
the
terminal
we're
going
to
see
is
where,
before
we
didn't
have
any
metrics
now
we're
starting
to
see
some
things
appear
now
we're
starting
to
see
some
things
appear
right,
so
I
once
again
have
stats
in
the
top
right
about.
What's
going
on
in
our
environment,
we
see
there's
very
little
traffic
right.
It's
basically,
just
the
health
checks
are
rolling
through,
but
there's
some
traffic,
which
is
nice
and
I,
can
see
that
there's.
A
B
A
So
now
we've
got
that
we're
actually
going
to
allow
allow
some
traffic
through
so
I
created
a
server
created.
One
server
object
for
all
my
LinkedIn
admin.
Ports
I've
got
three
more
ports
that
I
care
about
my
web
front
end
my
book
service
and
my
author
service.
So
we're
going
to
create
we're
going
to
give
each
one
of
those
a
server
object
and
then
we're
only
going
to
look
at
one
of
those
server
objects
because
they
all
look
basically
identical.
A
A
So
if
you
look
at
the
the
books,
app
yaml
like
if
you
go
back
and
look
at
what
you
curl
down
you're,
going
to
see
under
the
definition,
a
port
to
find
called
server
right
or
service,
we're
telling
link
Rd
hey
explicitly,
it's
going
to
be
an
HP
one
connection
right,
so
you
don't
have
to
worry
about
protocol
detection
and
then
we
add
in
a
selector
so
very
similar
to
a
service
right.
A
community
service
you're
gonna
have
to
find
a
way
to
identify
what
pods
belong
to
that
service.
A
A
A
I'm
gonna
I'm
gonna
go
through
one
of
these
and
the
other
three
are
going
to
be
identical,
so
we
created
one
policy
per
server
and
we
bind
every
single
policy
to
the
same
mesh,
TLS,
identity
right
and
the
mass
TLS
identity
we'll
see
in
a
second.
It
gives
access
for
anything
in
books,
app
to
talk
to
anything
anything
else
in
the
books,
app
namespace.
If
you
look
at
our
traffic
on
the
top
right,
there
you're
going
to
see
that
now
we're
back
to
our
lightly
broken
application
as
opposed
to
our
totally
broken
application.
A
Now
we
look
at
the
end,
this
was
my
favorite
part.
I
thought
it
was
really
nice
to
be
able
to
do
star.books
app.
So
if
you're
a
service
account
and
the
bookshap
namespace,
you
are
valid
to
access
the
server
port
on
any
of
these
components.
So
now
we've
restored
traffic
to
our
environment.
Right
we
can
get
metrics,
we
can.
We
can
have
our
components
talk
to
each
other,
and
this
is
the
core
of
setting
up
a
namespace
deal.
A
All
right
so
I
have
a
question
then
for
The
Confident,
focusing
of
our
audience
here.
If
I
wanted
to
allow
say
I'm
using
an
nginx
Ingress
and
it's
in
the
Ingress
nginx
namespace
and
it's
under
a
service
account
called
Ingress
nginx.
Do
you
all
have
a
general
idea
of
what
I
would
need
to
do
to
allow
it
to
access
my
web
front
end.
B
A
So
it's
you're
in
the
right
general
direction,
but
so
the
first
thing
we
need
the
first
thing
we
need
or
I
guess
yeah.
Let's
start
with
that.
What
are
like?
What
are
the
objects
we
care
about?
So
what
what
server
object
do?
I
need
to
bind
it
to
whatever
my
authorization
policy
is,
in
this
case
I'm
trying
to
access
the
web
front
end.
A
So
it
is
the
web
app
server
object,
so
we're
going
to
take
the
server
object
for
web
app
and
we're
going
to
bind
a
new
policy
to
that
web
app
server
right
and
then
we
need
to
create
a
mesh
TLS
authentication
policy
for
our
nginx
Ingress
right
and
we
bind
that
new
mesh
TLS
object
to
the
web
app
server
and
that
would
allow
traffic
from
our
Ingress
through
to
our
application
that
make
General
sense,
yeah
yeah.
Thank
you
very
much
for
trying
I
really
appreciate
it.
I'm,
definitely
going
to
give
you
a
head
tomorrow.
A
Long
story
short
right,
like,
as
you
all
probably
figured
out.
This
isn't
like
a
trivial
exercise.
There
are
really
good
docs
inside
this
readme
I
point
you
at
the
docs
file
for
the
policy
reference
and
just
exercise
caution
test
things
out
in
a
reasonable
way
before
you
go
roll
it
through
into
production.
This
is
you
know
our
our
founder
when
he
talked
about
it.
This
is
the
biggest
foot
gun
that
Lincoln
is
ever
given
our
users
right.
So
don't
don't
use
it
to
harm
yourself.
A
So
where
are
we
on
time?
Do
we
have?
We
have
a
bit
more
right,
so
we
have
a
90-minute
session,
so
the
next
section
of
this.
So
this
was
this-
was
the
coarse
grain
policy
in
Linker
D.
So
what
I
mean
by
that
is
I
guess
that's
course
grade.
That
was
bad.
I
know
all
right
point.
Is
we
bound
rules
to
a
port
right,
but
it
didn't
allow
us
to
didn't.
Allow
us
to
get
any
more
in
depth
than
that
right.
A
So,
with
with
Linker
d212,
we
can
do
more
fine-grained
policy,
so
I
can
because
linkerty
is
aware
of
your
API.
It
understands
what
it's
doing
who's
talking,
what
it
understands
the
HP
verbs.
It
stands
who's
calling
what
path
we
can
actually
make
rules
that
go
down
to
the
perverb
and
per
path
level
inside
your
environment,
right.
A
In
fact,
the
way
that
we
set
default
exceptions
for
Readiness
and
lightness
checks
is
we
use
fine-grained
policy
built
on
top
of
HTTP
routes
to
allow
the
cubelet,
even
though
it's
not
part
of
the
mesh
and
will
never
be
part
of
the
mesh?
We
allow
it
to
talk
to
the
whatever
predefined,
Readiness
and
liveness
checks.
You
have
inside
your
workloads,
okay,
I'm,
going
to
show
you
how
to
break
that
in
your
environment.
Does
anyone
need
a
break?
A
A
Okay,
so
we've
isolated
namespace.
Now,
let's
do
some.
Let's
do
some
locking
down
right,
so
we're
going
to
use
we're
going
to
use
HP
routes
to
do
it.
So
the
first
thing
I'm
going
to
do
is
create
a
route
for
our
author
service
I.
Want
you
to
see
a
bit
about
what
happens
when
we
do
it
in
particular,
if
you
could
watch
the
get
pods.
Something
interesting
is
going
to
happen
when
we
run
this
command
right.
So
we've
created
our
first
HTTP
ramp
policy.
A
A
A
Oof
and
it
did
it
so
now,
if
you
look
at
our
environment,
the
author's
service
or
the
authors,
pod
just
became
unready
right,
so
we
have
two
containers:
a
link,
ready
proxy
and
the
actual
authors
container
and
authors
is
no
longer
ready.
So
what
happened
here?
Let's
actually
take
a
look
at
this
object.
We
created
an
HP
route
and
what
it
said
is
Hey,
listen
for
these
paths
and
on
these
verbs
right
we're
going
to
we're
going
to
set
specific
rules
about
who
can
talk
to
what
right
we
haven't.
C
A
This
talks
through
again
like
a
lot
of
this,
is
intended
for
you
all
to
do
self-paced
right,
but
the
the
gist
of
it
is
it's
not
working
because
linkerty
deleted
the
routes
that
it
created
for
you.
So
now
we're
going
to
set
up
the
probe
right.
The
probe
object
is
actually
going
to
create
a
route
and
it's
going
to
create
a
type
of
authentication
and
then
it's
going
to
create
a
policy.
So
let's
just
look
at
that
object.
A
So
we
create
a
route
for
slash
ping.
We
basically
say
that
Hey,
listen!
Anybody
on
any
IP
address
if
they're,
not
part
of
the
network,
may
talk
to
that
right
and
then
we
bind
them
together
with
this
authorization
policy.
Now
we
bound
the
network,
authentication
called
the
author's
probe
to
the
to
the
policy
that
is
or
to
the
hcp
route.
That
is
that
authors
probe
all
right.
A
So
now
our
pod
becomes
ready
once
again
because
it's
allowed
and
now
all
right,
that's
what
I
just
did
and
now
we're
going
to
actually
allow
some
traffic
to
come
in
worth
noting
right
before
I.
Do
this
the
success
rate
for
the
web
app
service
has
cratered
down
to
11.
That's
because,
as
it
tries
to
talk
to
authors,
which
is
doing
a
lot,
it
always
gets
denied
right
and
we
can
see
that
we've
got
well.
You
can
maybe
see
it,
but
there
are
a
bunch
of
unauthorized
bits
of
traffic
rolling
through
hold
on.
A
A
A
A
B
A
A
Sorry,
Neil,
Gaiman,
you're
out
man,
I
hated
Sandman.
It's
gone!
No
can't
do
that
either
because
I
have
no
no
policy.
Also
I
didn't
hit
Sandman,
it's
amazing!
It's
not
that
same
guy
I
feel
like
it's
the
same
guy
anyhow
right.
That's
that's!
What's
going
on
here
and
we
also
see
their
success
rate
for
web
app
is
like
staying
low
right
well,
because
web
app's
actually
doing
a
lot
of
trying
to
update
and
delete
authors,
and
that's
not
going
to
work.
So,
let's
see
how
we
can
make
that
work.
A
A
A
A
C
A
I
can
talk
to
authors.
I
can't
make
any
changes
to
the
authors.
I
can
only
do
that
through
the
web
app
front
end,
because
it's
the
only
service
that
should
be
allowed
to
make
those
changes.
Authors
is
a
protected
backend
make
sense,
and
that's
the
demo
right.
So
it's
it's
meant
to
show
you
how
you
would
do
this
in
practice
right
for
those
that
have
done
it
right.
A
B
All
right,
one
thing
I
would
say:
is
that
I'm
not
employed
by
buying
or
anything
I'm,
not
even
a
link,
ID
user
really,
but
I've
really
really
been
struck
at
how
simple
it
is
to
use
in
this
kind
of
thing
like
we're
talking
about
some
pretty
complicated
Concepts,
and
it's
really
impressive
to
me
how
simple
it
is
relative
to
other
surface
batteries
that
I've
used
I.
Think
it's
a
it's
a
really
great
tool.
I'm,
certainly
going
to
be
playing
with
it
a
lot
more
following
this
thanks.
A
A
If
this
is
cool,
you
want
to
learn
more
buoyant
IO
SMA.
That
will
get
you
like
all
the
workshops
that
we
published
online
they're
recorded.
You
can
go
through
them.
There
are
examples
out
there
for
all
this
stuff,
The
Next
Step
we're
going
to
do
a
deep
dive
into
everybody's
favorite
topic,
cni
plugins,
and
how
do
we
modify
your
IP
tables
on
Cube,
plus
there,
keeping
it
fast,
paced
and
exciting
beyond
that?
If
you
think
Linker
D
is
cool,
but
you
think
gee
I
wish.
B
A
C
A
B
Oh
yeah,
we're
also
going
to
have
a
jet
stack
and
a
cert
manager
booth
in
the
project.
Pavilion,
the
search
manager
Booth,
is
well
worth
a
visit.
This
is
your
advanced
notice,
so
you
can
get
in
early.
We
have
a
Raspberry
Pi
and
a
little
printer
and
we
will
print
out
a
little
certificate
that
you
can
take
home
in
person,
a
sort
of
memorabilia.
It's
really
fun.
It
was
really
successful
and
popular
at
cubecon,
Valencia,
I'm
told
unfortunately,
I
wasn't
there,
but
yeah
really
really
popular
there.
B
Please
do
come
along
and
get
your
own
certificate
with
a
little
seal
and
everything
it's
a
really
neat.
Little
thing
also
like
do
check
out
the
jet
stack
blog.
We
have
some
pretty
cool
stuff
on
there
and,
if
you're
like,
when
you're
dealing
with
certificates
in
any
sort
of
meaningful,
large-scale
deployment,
usually
that
introduces
sort
of
management
challenges
like
how
do
you
keep
track
of
them?
That
kind
of
thing
that's
jet,
Stack's
product
area.