►
From YouTube: What We Learned From the Gateway API: Designing Linkerd’s New Policy CRD - Matei David, Buoyant, Inc
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
What We Learned From the Gateway API: Designing Linkerd’s New Policy CRD - Matei David, Buoyant, Inc
Speakers: Matei David
Since the introduction of the new Gateway APIs, created by the SIG Network community, Linkerd maintainers have been working on leveraging a new pattern known as policy attachment in Linkerd’s authorization mechanism. In this talk, Matei, a Linkerd maintainer, will briefly cover the collection of Gateway APIs, what policy attachment represents, and how it works in practice, and uncover how Linkerd’s authorization policies have been revised with the policy attachment pattern in mind. Policy attachment, as outlined by the SIG Network community, allows platform-level policies, such as timeouts, retries, and custom health checks, to attach to any arbitrary Kubernetes type. This enables users to create custom policies that extend, and plug into the API instead of being a concrete part of it.
A
A
So
my
name
is
Alex
I'm,
a
software
engineer
at
buoyant
we're
the
creators
of
linkerty
I've
been
a
Linker
D
maintainer
since
the
beginning
of
the
project,
and
it's
something
I'm
really
passionate
about
I.
Think
service
meshes
are
very,
very
cool
and
we
have
recently
done
a
lot
of
really
interesting
stuff
with
the
Gateway
API.
That
I
want
to
talk
about.
A
Okay,
so
show
of
hands
who
is
familiar
with
linkerty
here:
okay,
a
lot
of
people
great
what
about
who's
familiar
with
the
Gateway
API,
still
a
good
number,
but
but
fewer
Okay
cool,
so
I,
I,
guess
I,
don't
have
to
spend
too
much
time
talking
about
linkready
itself.
It's
a
service
mesh!
It's
a
graduated
project
in
the
cncf.
It's
used
in
production
in
many
different
places
by
many
different
people
and
it's
a
very
collaborative
and
active
open
source
community.
A
So
as
a
service
mesh,
that
means
that
there
is
a
sidecar
proxy
in
every
pod.
That's
part
of
the
mesh
that
adds
a
lot
of
really
interesting
functionality
like
mtls
between
all
your
services,
reliability
features
like
retries
and
timeouts,
and
a
lot
of
observability
features
like
layer,
7,
metrics
on
success
rate,
request
rate
and
latency
and
with
a
major
focus
on
operational
simplicity.
So
the
whole
thing
kind
of
works
out
of
the
box
and
and
doesn't
require
you
dedicating
a
lot
of
brain
power
to
to
making
it
work.
A
So
the
main
focus
is
behind.
Likerty
are
just
that.
It's
supposed
to
be
very,
very
lightweight
both
in
terms
of
resource
usage,
which
means
that
it
doesn't
take
up
a
lot
of
memory
and
it
doesn't
add
a
lot
of
latency,
but
also
lightweight
conceptually,
in
that
it's
a
very
simple
model
that
you
don't
have
to
think
too
much
about,
and
you
can
operate
it
without
getting
bogged
down
in
the
details.
So
being
simple
and
secure
right
out
of
the
box
has
been
kind
of
a
guiding
principle
for
the
project.
A
Okay,
so
I'm
going
to
give
a
little
bit
of
background
here
about
how
authorization
Works
in
Linker
d.
So
this
is
a
fairly
new
feature
that
was
added
in
Linker,
d211
I.
Think
sometime
last
earlier
this
year
or
late
last
year,
maybe
and
that's
kind
of
kind
of
set
the
stage
for
why
we
care
about
the
Gateway
API
and
and
how
it's
going
to
help
us.
A
A
But
what
we
haven't
had
is
really
a
way
to
act
on
that
information,
a
way
to
do
authorization,
which
is
to
say
you
know,
I'm,
only
going
to
allow
certain
identities
to
talk
to
me
or
I'm
only
going
to
authorize.
You
know
certain
parties
from
from
establishing
connections,
and
so
we
wanted
to
add
that
unless
that
was
a
major
focus
of
linker
d211,
and
so
as
we
were
kind
of
Designing
that
feature
one
of
the
things
we
really
had
to
think
about
is
well.
A
Where
does
that
configuration
live
and
as
I
mentioned
in
one
of
the
earlier
slides?
One
of
the
guiding
principles
of
linkerty
is
to
kind
of
minimize
configuration,
make
it
easy
to
use,
make
it
just
work
out
of
the
box,
but
there's
a
few
places
where
you
really
do
need
user
input
in
order
to
decide
what
the
behavior
should
be.
A
You
know
we
can't
automatically
determine
who
should
be
allowed
to
talk
to
whom
that's
really
something
that
has
to
be
configured,
because
only
the
people
operating
the
the
cluster
know
what
that
behavior
is
supposed
to
be,
and
so
you
know
this
beginning
the
thought
this
began,
the
thought
process
of
how
should
we?
How
should
where?
Should
we
put
this
configuration?
A
A
There
I
think
the
Gateway
API
kind
of
refers
to
them
as
service
front
ends
and
service
backends
I
like
to
think
of
them
as
service
targets
and
service
receivers.
And
so
what
I
mean
by
this
is
that
the
service
kind
of
have
has
two
parts,
so
there's
the
service
front
end
or
the
service
Target,
which
is
usually
a
cluster
IP
or
a
DNS
record,
and
that
is
something
that
a
client
sends
traffic
to.
So
it's
a
Target.
A
On
the
other
hand,
there's
the
place
where
the
traffic
actually
goes
after
it
is
sent
to
that
service.
So
this
is
usually
a
list
of
endpoints
or
a
list
of
PODS
or
a
list
of
back
ends.
These
are
where
the
service
goes
or
this
is
where
the
traffic
goes,
when
you
send
it
to
this
service
and
a
service
object,
kind
of
co-mingles
those
two
concepts,
and
if
you
wanted
to
attach
policy
onto
that
authorization
policy,
you
run
into
this
problem
where
you
can
have
pods
back-end
pods,
which
are
in
multiple
Services.
A
You
can
have
back-end
pods,
which
are
not
in
any
service,
and
so
when
a
back-end
pod
receives
traffic,
it
really
doesn't
know
which
service
was
used,
which
service
was
targeted
to
to
send
traffic
to
me.
So,
in
other
words,
if
we
had
authorization
policy
attached
to
these
Services,
we
wouldn't
know
which
policy
to
use
and,
furthermore,
if
a
client
connected
directly
to
that
Pod
without
using
a
service,
does
that
mean
that
it
should
bypass
the
authorization
policy?
So,
of
course,
this
doesn't
make
sense.
A
A
So
we
came
up
with
these
new
resources,
server
and
server
authorization,
and
if
we
take
a
look
at
what's
here
in
the
server
resource,
it's
very
very
simple,
so
there's
just
a
pod
selector,
which
selects
which
pods
this
service
refers
to
or
This
Server
I'm.
Sorry,
this
server
refers
to
and
a
port,
and
so
this
is
another
difference
from
Services
where
a
service
can
have
many
ports
defined,
and
you
can
actually
use
a
service
and
Target
a
port.
That's
not
defined
on
that
service
with
a
server.
A
It's
specifically
talking
about
one
single
port,
and
so
this
defines
very
specifically
a
Traffic
Receiver,
and
so
therefore
we
can
set
authorization
policy
on
that
server
and
we
can
say
well
for
This
Server.
Here
are
the
clients
who
I
want
to
authorize,
who
I
think
should
be
allowed
to
talk
to
this
server,
and
so
that's
what
the
server
authorization
resources?
A
It's
a
resource
which
you
know
selects
which
server
it's
going
to
apply
to
and
then
it's
going
to
give
a
list
of
clients
that
are
allowed
to
connect
to
it
and
that
list
of
clients
can
be
defined
in
a
number
of
ways.
You
can
say
I'm
going
to
allow
anyone
just
unauth
attack
on
the
unauthenticated
and
and
anyone's
allowed
to
connect
to
it,
or
you
can
say
anyone
as
long
as
they're
in
the
match
and
they
have
a
valid
identity.
A
So
this
is
kind
of
taking
a
step
back.
What
that
kind
of
looks
like.
So
you
see
on
the
right
there,
there's
the
bar
pod
and
that's
the
one
we're
trying
to
control
access
to
above
it.
You
can
see
that
there's
a
server
that's
defined
for
it,
which
selects
a
certain
Port.
So
in
this
case
we're
just
talking
about
port
80.
A
A
So
what
does
this
have
to
do
with
the
Gateway
API?
Well,
let's
give
a
little
bit
of
an
overview
of
what
the
Gateway
API
is
for
those
who
aren't
familiar
so
the
Gateway
API.
Is
this
set
of
kubernetes
resources
that
are
very
useful
for
defining
the
behavior
of
gateways,
and
one
of
the
kind
of
key
ideas
here
is
that
there
are
a
bunch
of
different
resources
which
exist
at
different
layers
and
are
owned
by
different
personas.
A
A
So
this
is
kind
of
how
that
looks
as
an
Ingress
is
as
English
traffic
is
coming
in.
You
know
that
traffic
first
goes
to
the
Gateway,
and
then
it's
going
to
look
and
see
which
HTTP
routes
it
has
attached
to
it
and
whichever
route
matches
that
traffic
it's
going
to
determine
where
that
request
is
going
to
go
to.
A
So
what
does
this
have
to
do
with
service
measures
and
how
is
this
useful?
So
this
is
all
kind
of
to
do
with
Ingress,
which
is
not
something
that
Linker
D
really
does
right
now.
Linker
D
is
more
interested
in
managing
East-West
service
to
service
traffic
within
the
cluster.
So
so
how
does
this
apply?
A
A
So
in
all
of
the
Ingress
cases,
we
had
that
attaching
up
to
a
Gateway,
but
you
could
imagine
that
attaching
to
someone
else
something
else
you
could
imagine
having
an
HTTP
route
which
is
attached
to
a
server
or
a
service
in
your
cluster
and
a
defining
policy
for
service
mesh
traffic
rather
than
for
Ingress
traffic
and
then
down
at
the
bottom.
You
see
that
it's
kind
of
made
up
of
two
parts
down
there
there's
the
match,
which
defines
what
kind
of
traffic
is
going
to
match
that
rule.
A
So
that's
usually
a
path
either
path
based
matching
or
header,
based
matching
or
a
combination,
and
then
on
the
right.
You
have
the
behaviors
that
should
be
taken
for
traffic
which
matches
that
route,
so
either
a
set
of
filters
that
that
apply
some
logic
or
some
back
end,
refs
that
indicate
where
that
traffic
should
go,
and
so
this
is
kind
of
an
example
of
what
that
spec
might
look
like
in
yaml,
and
so
the
the
kind
of
idea
that
we
really
latched
onto
here,
which
we
thought
was
really
interesting,
is
well
one.
A
This
gives
us
a
way
to
talk
about
routes
which
allows
us
to
specify
policy
in
a
more
fine-grained
way.
It
means
that,
when
we're
talking
about
authorization
policy,
we
don't
have
to
authorize
an
entire
server
and
say
for
This
Server.
You
know
here
are
the
clients
that
are
allowed
to
talk
to
it.
We
can
be
a
little
bit
more
specific
and
say
well.
We
actually
only
want
to
authorize
these
clients
for
this
route
on
This
Server.
A
So
this
is
kind
of
the
structure
that
that
was
informed
by
that
in
Lincoln
we
adopted
the
HTV
route
type
from
the
from
the
Gateway
API.
We
had
to
modify
it
a
little
bit
in
order
to
fit
our
purposes,
but
we
now
have
support
for
HTTP
routes
and
those
can
attach
on
to
servers
so
that
you
can
authorize.
You
can
authorize
routes
rather
than
authorizing
an
entire
service.
A
A
Okay,
so
looking
to
the
Future
what
what's
coming
next,
so
if
anyone
is
kind
of
familiar
with
some
of
the
more
advanced
features
in
Lincoln,
one
of
them
is
called
service
profiles
and
so
service
profiles
are
a
feature
we
have
in
Linker
D
that
allow
you
to
configure
things
like
retries
retry
budgets,
timeouts
and
do
that
kind
of
on
a
per
route
in
a
per
route
way.
So
you
can
say
these
routes
are
retrievable.
A
So
these
are
kind
of
two
parallel
ways
of
doing
the
same
thing,
and
we
want
to
kind
of
slowly
unify
that
and
move
away
from
service
profiles
and
move
more
towards
this
Gateway
API
style
approach
of
policy
attachment
where
you
can
have
resources
which
represent
policies
like
you
know,
retryability
or
timeouts
or
authorization,
and
you
can
attach
those
policies
onto
HTTP
routes,
and
this
gives
us
a
much
more
an
approach.
That's
a
lot
more
consistent
with
the
way
things
are
done
in
the
Gateway
API
and
feels
more
kubernetes
native
than
what
we
had
before.
A
So
so
why
are
we
doing
this?
What
what
is
the
purpose
of
adopting
the
Gateway
API
I?
Think
there's
a
few
reasons
why
the
Gateway
API
is
really
interesting
for
defining
these
types
of
things.
One
of
the
primary
ones
is
that
these
Gateway
API
types
give
us
a
standard
way
to
define
this
rather
than
having
to
come
up
with
these
new
structures
or
new
types
ourselves.
A
So
that's
a
lot
easier
for
us
as
maintainers.
It's
a
lot
also
a
lot
easier
for
adopters
who
are
looking
to
use
these
technologies.
That
means
that
if
they
are
familiar
with
the
Gateway
API
they've
learned,
kubernetes
and
they're
trying
to
adopt
Linker
D,
they
don't
have
to
go
and
learn
an
entirely
new
set
of
apis
on
an
entirely
new
set
of
resources,
an
entirely
new
set
of
Concepts.
They
can
just
use
what
they
already
know
and
it
should
feel
intuitive
and
natural,
and
the
Gateway
API
is
just
a
well-designed
API.
A
The
cons
of
adopting
the
Gateway
API
are
that
it's
it's
still
fairly
new
and
it's
still
kind
of
evolving
a
little
bit,
so
there
may
be
still
things
that
we
don't
know
or
that
we
discover
over
time
and
there's
always
a
possibility
for
API
churn
as
it
continues
to
mature,
but
I.
Think
being
part
of
that
conversation
and
and
adopting
it
now.
A
So
we're
very
involved
in
these
discussions.
If
this
is
something
that's
of
interest
to
you,
I
highly
recommend
that
you
get
involved
as
well
and
kind
of
as
this
can.
These
discussions
continue
to
happen
and
we
continue
to
work
on
this.
You
know
we're
going
to
be
at
the
Forefront
of
of
supporting
whatever
gamma
recommends
for
using
the
the
Gateway
API
in
a
service
mesh
concept,
context.
A
Okay,
so
what
are
the
main
ideas
here?
I
think
the
main
things
we
learned
from
from
kind
of
working
with
the
Gateway,
API
and
and
and
and
trying
to
adopt
it
and
use
it
for
for
likerty,
is
that
this
difference
between
traffic
front
ends
and
traffic
back
or
service
service
front
ends
and
service
backends
was
really
important.
You
know
trying
to
reason
about
the
difference
between
a
traffic
Target.
A
You
know
in
the
case
of
a
service,
this
is
something
like
a
cluster
IP
or
or
a
DNS
record,
and
a
traffic
backend,
a
receiver
which
is
the
actual
endpoint
or
pod
that's
receiving
that
traffic.
It
is
really
important
to
keep
that
that
difference,
distinct
in
your
head,
otherwise
things
can
get
very,
very
muddy
and
I
think
the
Gateway
API
does
a
really
good
job
of
of
calling
out
that
difference
explicitly.
A
A
So,
if
you're
interested
in
kind
of
learning
more
kind
of
diving
deeper
into
a
lot
of
these
Concepts
around
the
way
that
lingardy
uses
the
Gateway,
API
or
other
Deep
dive
link
ready
Concepts,
there
is
a
service
mesh
Academy
that
I
can
highly
recommend.
It
is
a
monthly
Hands-On
training.
Their
next
one
looks
like
it's
from
November
11th
to
17th,
and
if
that
is
of
interest
to
you,
I
highly
recommend
you
check
it
out.
A
So
if
that's
of
Interest
I
highly
recommend
you
check
that
out
as
well
and
I
also
want
to
shout
out
once
again,
this
is
talk
is
by
my
colleague
mate.
He
did
a
really
good
job
with
it.
If
you
liked
this
talk,
please
make
sure
you
contact
him
on
on
slack
or
on
on
Twitter
and
let
them
know
I
can't
take
credit,
but
other
than
that.
Thanks
for
listening
and
happy
to
take
any
questions,
foreign.
B
A
C
C
A
No
I
don't
think
you're
jumping
the
gun,
so
I
think
these
are
kind
of
mostly
separate
concerns.
Right
you've
got
Kong
for
your
Ingress.
You
perhaps
have
service
mesh
needs.
You
can
use
Linker
D
for
your
service.
Mesh
I
think
there's
going
to
be
a
little
bit
of
a
Confluence
in
the
future
between
the
types
that
they
use
like.