►
From YouTube: Identity Based Segmentation for a ZTA - Zack Butcher, Tetrate & Ramaswamy Chandramouli, NIST
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 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.
Identity Based Segmentation for a ZTA - Zack Butcher, Tetrate & Ramaswamy Chandramouli, National Institute of Standards and Technology
Zero Trust is all about replacing implicit trust based on the network -- traditional perimeter security and an "access is authorization" model -- with explicit trust based on identity and runtime authorization. This means applications must authenticate and authorize service communicate in addition to end users. This gives rise to patterns like identity aware proxies and the service mesh for enforcing access. We'll discuss a quick-and-easy definition for a what a "zero trust architecture" is and discuss how a common use case -- application communication from cloud to prem through a DMZ -- can be simplified with identity aware proxies (and policy!), leading to organizational agility.
A
So
what
Zach
and
I
are
going
to
talk
today
is
about
the
identity
based
segmentation
for
a
zero
test
architecture.
So
naturally,
so
we
have
to
give
some
leading
information
on
what
is
zero
thrust
architecture
and
voice
zero
test,
and
then
we
dwelled
into
what
is
identity
based
segmentation
and
then
all
the
nuances
to
the
policy
text.
A
B
B
Responsible
for
running
a
lot
of
the
SPs
that
you
all
need
to
go
Implement
in
practice,
so
his
fault,
but
also
awesome,
work
and
I'm
Zach
I'm,
one
of
the
founding
engineers
at
touchrates
and
I
work
very
closely
with
muli
to
help
author.
Some
of
these,
in
particular,
we've
written
a
lot
of
the
SP
800
204
series
together,
which
is
the
set
of
security
recommendations
for
microservices
and
multi-cloud.
However,
we're
actually
going
to
be
working
on
together
on
some
things
around
zero
trust
very
soon
and
you'll
get
a
nice
sneak.
A
Yeah
so,
first
of
all,
as
Zach
mentioned
in
the
keynote
address,
zero
trust
has
been
around
for
quite
some
time,
but
then
he
says
sudden
for
focus
on
zero
trust.
Right
now
is,
of
course,
we
know
all
the
good
reasons
that
no
longer
there
is
something
called
a
parameter
exist,
because
people
are
sitting
all
over
the
place
and,
secondly,
the
applications
themselves
have
become
quite
distributed.
So.
B
A
B
A
And
take
into
account
all
the
contextual
variables,
because
there
are
very
many
variables
involved,
and
it
should
be,
of
course,
conformed
to
the
good
old
Cardinal
principles
of
least
privilege
and
so
on
and
so
forth,
and
naturally
it
should
be
so
naturally
means
it
is
to
be
identity
based
so
under
who
are
all
the
entities
carrying
identity?
You
know
the
users
and
services
and
devices.
So
that's
what
we
are
going
to
focus
on
today
about
the
identity
based
segmentation
and.
B
A
A
And
now
that
we
venture
into
the
zero
trust
the
initial
thinking
was:
can
we
do
a
segmentation
of
the
network
itself
so,
but
the
existing
techniques
on
network
segmentation,
like
you
know,
based
upon
subnets
as
well
as
some
labels,
as
we
case
in
the
case
of
vlans,
are
no
longer
sufficient,
because
all
the
virtually
is
containing
is
workloads.
They
move
all
over
the
place.
You
can't
pin
them
through
a
particularly
even
the
network
address,
or
a
subnet
and
so
on.
So
that
is
why
we
need
an
identity
based
architecture.
So,
in.
A
Of
the
things
that
we
want
to
concentrate
as
far
as
the
zero
trust
architecture
is
concerned,
and
then
this
error
set
architecture
is
the
fundamentally.
It
is
based
upon
the
identity
based
segmentation,
so
it's
another
name
for
zero
test
segmentation
also,
and
then,
of
course,
as
we
all
know,
identity
based
means
what
the
name
implies.
You
know
it
is
not
based
upon
any
network
parameters
and
it's
a
place
to
Services
users
and
devices,
and
also
it
should
be
not
just
any
identity,
orbital,
like
user
ID
and
so
on.
C
C
B
Concerned
yeah
and
a
couple
of
things
here
to
note
is
you
know
that
and
in
that
second
bullet
point
is
doing
a
lot
of
heavy
lifting
there
right.
So
we
need
not
just
a
service
and
a
user
identity,
but
we
also
want
to
know
where
you
know
the
device
that
it's
originating
from,
and
you
know
we
may
even
use
things
like
the
network
parameters
as
part
of
a
risk-based
assessment
to
give
you
permission
or
scope
or
things
like
that.
But
it
cannot
be
the
only
check
that
you're
doing,
because
that
is
not
sufficient.
B
A
Distributions,
we
know
consist
of
not
only
runtime
checks,
but
also
the
whole
process
is
in
place
and
also
the
monitoring
and
continuous
preformulations
of
policies
and
so
on.
So
that
is
the
whole
food
process.
But
in
this
presentation
we
are
just
focusing
on
the
identity
based
segmentation
aspects.
B
A
So
it
is
a
runtime
technology
that
we
are
focusing
on
this,
and
then
we
are
identified,
at
least
in
the
concept
of
microservices
environment,
with
service
mesh,
that
we
do
need
at
the
minimum.
These
five
things.
First,
the
the
section
itself
should
be
secure
for
that
we
need
encryption
in
transit
and
then,
of
course,
we
do
need
to
validate
service
identities
and
then
once
identity
is
validated.
We
need
some
means
of
authorizing
authorization
at
the
service
level
and
then,
of
course,
the
end
user
is
also
an
integral
part
of
the
whole
picture.
A
C
B
Yeah
and
just
you
know,
kind
of
paint
a
picture
here,
you
know
you
can
imagine
moving
up
the
tiers.
We
we
go
from
subnet
based
connectivity
and
and
micro
segmentation.
At
that
level,
we
can
start
to
layer
in
identity
based
controls,
but
policy
gets
really
powerful,
very
compelling
when
I
can
combine
both
service,
runtime
policy
and
user
access
policy
together
right.
B
So
you
can
write
a
policy
that
says,
for
example,
not
just
the
front
end
can
call
the
back
end,
but
the
front
end
can
call
a
particular
method
on
the
back
end,
only
in
the
presence
of
a
valid
end
user
credential.
That
has
the
permission
to
read,
for
example,
right
and
so
again
the
game
is
all
about
bounding,
an
attack
in
space
and
in
time,
those
more
comprehensive
policies
that
combine
both
physical
location
and
application,
as
well
as
end
user
credential.
A
A
So
those
that's
where
all
our
focus
on
policies
and
everything
comes
into
the
picture
so
and
not
only
because
this
beautiful
entity
called
the
proxy
that
is
part
of
the
data
plane
in
the
service
mesh
that
actually
really
acts
as
a
security
Kernel,
because
it
is
a
non
bypassable
and
also
it's
verifiable.
It
is
outside
the
application
code
right
and
then
so
then,
actually
we
just
give
a
brief
description
of
how.
C
A
A
B
B
A
A
Providers
to
give
you
the
end
user
authentication,
the
end
user
credentials
and
then
at
the
Ingress
point
in
the
gate
on
the
Ingress
Gateway,
you
can
exchange
it
for
a
job
token.
You
know
which
contains
you
will
give
the
a
local
identity
and
so
on,
and
it
can
also
populate
it
with
claims
and
then
the
same
in
the
end
user
when
they
are
inside
the
mesh
and
making
a
call.
So
those
the
claims
in
the
jaw
token
can
be
used
and
compared
against
the
resources
that
are
being
requested,
that
particular
resource
or
again.
B
And
you
know,
specifically
in
SB
800
204b,
which
movie
and
I
wrote
we
talk
about
extra,
and
so,
if
you
want
to
dig
into
some
of
these
ideas
in
more
detail,
go
check
that
out.
We
talk
about
pulling
out
things
like
authentication
into
this
common
layer
into
the
service
mesh
so
that
it
can
be.
You
know,
audited,
so
that
we
can
have
higher
Assurance
in
the
code
because
it's
not
delegated
across
every
application.
B
You
know,
there's
a
lot
of
really
strong
properties
from
a
security
perspective
that
we
can
get
push
pushing
this
out
into
a
common
layer
right
as
long
as
the
application's
still
ensures
that
those
checks
have
been
applied
when
it
gets
at
things
like
you
know,
looking
at
a
job
that
the
system
mints
validating
that
jot,
that
it
came
from
a
trusted
source
and
then
using
those
claims
to
actually
apply.
Authorization
is
one
way
that
you
know
a
an
application
can
attest
that
these
checks
have
happened
before
the
the
request
reaches
it.
B
B
And
and
not
just
jots,
it
doesn't
have
to
be,
and
you
know
one
thing
I'll
just
point
out
is
you
know
there
are
actually
multiple.
You
know
High
Assurance
deployments,
you
know
hitting
things
like
fedramp
moderates
and
high
controls,
leveraging
things
like
the
service
mesh
to
offload
user
authentication
and
authorization
to
the
to
a
common
infrared
layer
to
the
mesh
right,
and
so
this
is
not
just.
You
know
something
that
we
can
do,
but
this
is
something
that
actually
is
done
in
the
wild
in
high
criticality
environments
that
are
Security
First.
A
A
That's
sitting
on
top
of
the
individual
service
meshes
so
that
you
can
apply
uniform
policies
throughout
the
Enterprise
for
all
the
service
measures
and
so
on,
and
secondly,
that
is
really
a
reality,
because
not
only
there
are
multiple
clusters
within
the
organization,
but
the
common
scenario
is
that
you
do
have
hybrid
environments.
You
do
have
some
resources
in-house
in
the
data
centers
and
Branch
offices,
and
some
in
clouds
and
some
in
even
multiple
clouds.
B
A
B
A
B
A
B
A
Gateway
and
so
on,
and
then
of
course,
on
top
of
it,
as
Zac
said,
we
can
layer
all
the
goody
service
identity
based
publicity
policies
on
top
of
this
network
policy
is,
and
so
the
beauty
of
this
is
we
can.
This
policies
can
really
coexist
this
and
they
don't
have
to
conflict
with
each
other,
so
the
multi-tier
policy
is
the
most
desirable
thing
and
and
as
just
now
described
can
be
the
network.
A
Tier
policies,
which
is,
can
be
both
course
grained
and
fine-grained,
and
then
right
into
your
tier
policies,
which
are
more
really
Dynamic.
So
that's
why
so?
The
network
tier
policies
can
be
really
be
static,
so
you
don't
have
to
really.
In
some
sense,
it
is
allows
for
relaxation
of
those
policies
in
favor
of
higher
level
policies.
B
And
really
this
is
before
before
we
hop
on
you
know.
This
is
really
all
about
kind,
trying
to
pave
a
path
for
organizations
and
the
Auditors
who
check
the
organization's
compliance
to
understand
the
move
from
a
perimeter
model
into
an
identity-based
model,
and
so
we
view
these
multi-tiered
policies.
One
is
a
stepping
stone
to
facilitate
that.
But
two
exactly
like
muli
said
as
a
is
to
help
with
defense
in
depth
more
layers
for
an
attacker
to
have
to
Traverse.
You
know
more
ways
to
bound
the
attack
in
both
space
and
in
time.
B
B
Exactly
and
so
just
to
help
kind
of
make
some
of
these
ideas
concrete
and
how
kind
of
paint
the
picture
for
how
they
might
help
you
bridge
a
traditional
perimeter
model
I
want
to
you
know,
walk
through
some
cases,
so
you
know
suppose
we
have
these
two
Services,
communicating
and
suppose
one
you
know
they're
either
different
sites,
or
maybe
one
is
in
Cloud.
One
is
in
the
data
center
right,
and
so
we
have
a
traditional.
B
You
know
DMZ
and
a
whole
class
of
policy
that
we
want
to
apply
to
that
traffic
as
it's
coming
into
kind
of
our
trusted.
Data
Center
often
times
that
requires
rule
changes
per
app
right,
and
that
is
where
we
get
the
pain
in
managing
outbound
firewalls.
This
is
where
we
get
the
pain
in
managing
the
network.
Oriented
rules
right.
B
You
look
at
a
set
of
subnets
that
are
allowed
to
egress
to
a
set
of
IP
addresses
like
what
does
it
mean
right,
and
this
is
where
we
have
a
spreadsheet,
where
we
record
it
somewhere
right.
That
is
clearly
brittle
and
painful,
and
we
see
it
regularly
create.
You
know
slowdowns
in
organizations
right.
So
one
of
the
ideas
that
we
put
forward
is
using
basically
identity,
aware
gateways
to
help
us
bridge
that
perimeter.
So
the
idea
is
that
we
can
have
you
know,
gateways
on
both
sides
of
the
of
the
perimeter.
B
We
can
establish
relatively
static
policies
to
facilitate
those
gateways,
communicating
and
we
don't
need
to
change
those
policies
per
app,
because
those
gateways
are
static
deployments
on
our
site.
Then
we
can
leverage
identity-based
policy,
which
is
which
can
be
much
more
Dynamic
and
hopefully
easier
to
maintain
about
who
can
go
over
that
connection?
Who
can
go
over
that
Transit.
B
B
B
Yeah
exactly,
and
so
we
see
these
exactly
overlay
on
top
of
each
other
right,
and
so
we
have
exactly
like
Molly,
said:
coarse
grain
firewall
policy
at
the
bottom.
Obviously,
these
are
not
like
you
know,
real
real
policies,
but
a
shorthand
for
you.
They
kind
of
get
the
idea
right.
We
have
firewall
to
firewall
policy.
We
need
micro
segmentation
as
well
on
each
half
very
hard
to
manage
how
they
go
over
that
that's
by
the
way,
with
things
like
a
cni,
it
becomes
challenge.
B
It's
not
easy
to
bridge
across
the
two
halves
of
our
policy.
The
service
mesh
can
sit
on
top
of
that
and
and
facilitate
consistent
policy
across
our
different
deployments
right.
So
we
know
you
know,
lower
level
policy
is
going
to
live
at
the
site
right.
The
the
micro
segmentation
is
bound
to
a
cluster,
usually
right
or
a
set
of
vpcs,
and
we
typically
don't.
You
know
we're
going
to
open
up
firewall
rules
between
the
two.
We
typically
don't
see
micro
segmentation
across
these.
B
That's
again
where
we
can
start
to
layer.
We
can
start
to
relax
some
of
those
policies
that
can
be
hard
to
maintain
and
replace
them
or
augment
them
with
mesh
level,
identity,
level,
policies
that
can
be
consistent
across
the
entire
infrastructure
and
when
I
say
consistent
across
the
entire
infrastructure.
What
I
mean
is
like
literally,
we
can
instantiate
the
same
policy
document
in
every
mesh
without
having
to
specialize
it
or
change
it
for
each
deployment
and
have
it
be
correctly
enforced
because
identities
flow
in
the
end.
B
So
as
we're
looking
at
how
we
realize
this,
this
Enterprise
ETA,
you
know
the
first
step
is
we
want
to
start
to
implement
this
identity
based
segmentation
right?
We
want
to
start
to
migrate
towards
identity-based
policy
and
we
can
leverage
some
of
these
patterns
to
help
make
our
lives
easier,
dealing
with
things
like
the
traditional
perimeter.
B
You
know,
as
we
said,
yeah,
you
know
we
need
some.
You
will
likely
want
some
Central
coordination
infrastructure
that
sits
above
a
service
mesh
to
help
manage
some
of
these
right.
So
if
we
look
at
a
traditional,
you
know
corporate
topology
of
of
three
zones.
This
is
pretty
standard
stuff
that
we
see
all
the
time
we
can
start
to
insert
these
identity.
Aware
policy
enforcement
points,
these
gateways
fundamentally
an
Envoy
proxy
in
the
data
path
there
to
start
to
leverage
higher
level
policy
at
all
of
these
locations.
B
Yeah
exactly
because
there's
a
certain
amount
of
like
service,
Discovery
information
you'll
need
to
propagate
across
clusters.
Right,
for
example,
you
know
your
Ingress
Edge
may
want
to
load
balance
across
multiple
clusters
behind
it
in
in
the
same
VPC
or
in
the
same
data
center.
So
there's
some
service
discovery
that
you
need
to
to
wire
up.
There's
policy
that
we
want
to
push
to
these
layers
as
well.
You
know-
and
so
we
can
start
to
leverage
things
like
your
CD
pipeline
as
one
of
the
ways
to
implement
this
coordination
infrastructure
right.
B
B
Fundamentally
again,
you
know
we
see
this
as
layering
on
top
of
each
other.
So
again,
this
is
a
you
know,
kind
of
a
rough
picture,
but
you
know
we
still
anticipate
these
traditional
perimeter-based
controls,
we're
gonna.
Have
you
know
segmentation
or
micro
segmentation
underneath
that
inside
of
that
perimeter
right,
you
typically
cni
will
sit
even
on
top
of
that
as
another
layer,
and
we
want
the
mesh
to
fit
exactly
on
top
of
all
those
right
and
again.
B
Yeah
so
again,
you
know:
why
do
we
do
this?
The
main
motivation
for
you
know
in
in
general
identity-based
segmentation.
Hopefully,
people
gets
why
we
would
want
to
do
this
in
the
context
of
moving
towards
a
ZTA.
Why
might
we
want
to
manage
multiple
tiers
of
policy
at
the
same
time,
while
we're
doing
that,
you
know
again,
it's
really
all
about
appeasing
your
current
regulatory
requirements,
your
current
control
requirements
and
the
knowledge
of
your
current
security
team
and
the
Auditors
Regulators
you
have
to
deal
with
right.
They
may
not
be
in
some
places.
B
A
B
B
B
And
again,
these
can
continue
to
exist
in,
and
we
expect
them
too
we'll
end
and
take
questions
for
for
whatever
time
we
have
left,
but
just
to
give
you
a
teaser
here,
SB
800
207a
will
be
coming
out
in
this
calendar
year
in
2023
around
these
ideas.
This
idea
of
starting
to
use
identity
based
policy
enforcement
points
to
help
span
traditional
perimeter-based
controls
and
with
that
I
think
we
have
hopefully
a
little
bit
of
time
left
for
for
some
questions,
I
think
maybe
about
five
or
seven
minutes.
D
B
A
back
yeah,
exactly
yeah,
and
so
we
and
you
know,
for
example,
ngac
Next
Generation
access
control
is
an
access
control
standard.
That
nist
is
working
on.
That's
an
ABAC
kind
of
a
similar
conceptually
to
what
Zanzibar
is
used
to
implement
and
so
yeah
exactly.
You
know
we
can
Implement.
You
know
all
of
these
orange
pieces
are
policy
enforcement
points
and
we
can
choose
whether
we
integrate
with
an
external
system
to
apply.
B
You
know,
potentially
very
rich
policy,
because
we
have
like
a
full
ABAC
like
a
Zanzibar
kind
of
a
system,
but
we
can
also
apply
much
simpler
policies
that
are
like
already
built
into
Envoy
right.
For
example,
you
know
just
simple
service
to
service
access
with
our
back
right,
and
so
that's
a
spectrum
there
so
yeah
the
the
mesh
is
bringing
enforcement
and
what
you
choose
to
use
as
your
decision
system.
You
know
as
long
as
it
integrates
with
the
mesh.
B
B
A
D
A
D
B
C
B
So
it
can
be
any
number
of
things
yeah,
it
can
be.
You
know
they're
yeah.
Typically,
it's
going
to
be
like
a
CD
system.
That's
coordinating,
there's
also
a
variety
of
like
vendor
products
that
do
online
policy
pushing
and
like
multi-cluster
management
and
stuff
like
that
as
well,
and
you
know
any
of
those
are
good
ways
to
do
it.
B
B
Yeah-
and
it
doesn't
necessarily
so
control
plane
implies
runtime.
It
doesn't
necessarily
have
to
be
a
runtime
system,
it
can
be
a
system
like
a
CDE
system,
that's
pushing
it,
but
it
can
also
be
a
runtime
online
system.
That's
acting
as
a
control
plane
getting
data
and
pushing
it
around
both
of
those
are
good
ways.
It
depends
on
what
you
need
out
of
the
system
and
what
are
the
properties
and
what's
the
operational
investment
you
want
to
make
for
what
is
right,
all
right.
B
It
could
potentially
right
so
like
yeah.
You
know
it
doesn't
really
matter
how
we
encode
that
identity
as
long
as
we
all
agree
on
what
the
identities
mean,
and
we
have
some
mechanism
of
runtime
to
authenticate
it
right.
So
at
a
service
you
know
at
a
service
service
layer.
Of
course
we
want
to
leverage
spiffy
because
that's
a
good
standard,
but
you
know
at
the
end
user
layer
it
could
be.
C
B
B
Exactly
and
to
be
clear,
you
know
encryption
and
Transit,
we
just
to
tee
off
that
a
little
bit.
Why
do
we
say
encryption
and
Transit
is
required?
It's
not
because
encryption
Trends
is
good.
It's
because
we
want
message,
authenticity
and
we
want
eavesdropping
protection
right,
and
so
we
can
achieve
the
like
message
and
message.
B
Authenticity
is
the
really
important
one
right
you
may
or
may
not
care
about,
eavesdroppers
being
able
to
see
what
the
requests
are,
but
you
certainly
want
to
know
that
it
hasn't
been
tampered
with,
because
otherwise
all
these
other
checks
are
meaningless
right.
Who
cares
what
the
identity
is
If?
The
message,
if
somebody
stuffed
the
envelope
with
something
different
right,
and
so
it
really
has
to
start
there
with
the
Assurance
of
the
data
on
the
wire
and
then
we
can
use
that
to
to
kick
off
policy
down
any
other
questions.
Yeah.
B
Yeah
exactly
so,
the
question
is,
is
roughly
just
a
paraphrase:
you
know
can't
have
Auditors
actually
approve
this
can
I
can
I
actually
do
this
pattern?
Is
that
roughly
it
yeah?
And
the
answer
is
yes
across
the
board
we've
seen
a
bunch
of
different
Auditors
under
different
regulatory
regimes,
approve
these
style
things,
whether
that's
folks,
like
the
air
force
AOS,
who
have
approved
ATO
for
a
lot
of
you,
know
Federal
moderate
to
high
systems
on
this
kind
of
thing.
B
B
Not
because
it's
it's
brand
new
and
like
we
think
it's
a
cool
idea,
but
we've
seen
this
implemented,
we're
seeing
Regulators
start
to
accept
it,
and
so
our
goal
in
codifying
it
as
an
SP,
is
to
really
push
that
to
those
Regulators
to
those
approvers.
To
say
this
is
a
good
thing.
You
should
accept
this
as
a
first
step
for
educating
them
to
move
the
ball
to
get
to
the
end
state
that
we
all
want,
which
is
like
identity
based
policy.
So.
B
Yeah
so
we're
starting
to
build
those
out.
So,
for
example,
there
is
an
istio
to
nist
SB,
853
mapping,
for
example,
and
that's
actually
in
the
form
of
an
oscow
manifest
that
can
be
used
to
feed
that
in
and
check
the
Assurance
of
the
system
at
runtime
right.
So
that's
it's
early
days
for
that,
but
those
are
things
that
are
being
developed
there
and
the
goal
is
to
push
a
lot
of
this
into
open
source
right.
So
things
like
oscow
to
open
source
compliance
assessment.
Language
lets
us
do
programmatic
checks.
B
A
computer
can
verify
that
you're
implementing
controls,
not
a
human
auditor,
who's
quinting
at
it
and
checks
the
box
right
that
moves
us
to
a
world
where
we
can
do
it
continuously.
My
goal
is
that
we
can
get
basically
all
the
the
big
infrastructure
projects
that
we're,
depending
on
to
produce
and
maintain
oscow
definitions
of
their
components.
That's
the
you
know,
that's
one
of
my
longer
term
goals
to
try
and
implement.
B
So
the
the
important
part
here
is
not
how
the
policy
enforcement
is
implemented
right.
So
I
mentioned
Envoy
a
few
times
here,
but
you
know
all
the
concepts
that
we're
talking
about
are
independent
of
the
data
plane,
implementation
right.
So
as
long
as
you're
doing
those
five
checks,
I
don't
care,
you
know
you
shouldn't
care,
nobody
really
needs
to
care
if
it's
evpf
or
if
it's
Envoy
or
or
if
it's
some
or
a
VPN
like
you,
you
know
it's
not.
That
part
is
not
very
important
right.
B
There
will
be
Security
in
runtime
and
operational
trade-offs
to
different
implementations,
and
we
are
starting
to
do
some
write-ups
kind
of
starting
to
analyze.
That
right,
I
fully
expect
a
lot
of
this
policy
to
move
into
ebpf
as
an
accelerator
right,
anything
that
we
can
move
out
of
user
space
and
into
the
kernel
to
be
able
to
reject
a
request
earlier
without
having
to
do
those
context.
A
B
B
Yes,
they,
yes,
they
will
be
available.
The
conference
should
make
them
available.
If
not
I,
think
we
have
our
contact
info
here.
You
know
just
shoot
an
email
worst
case.
If
they
don't
they
don't
pop
up
in
a
week
already
awesome.
Well,
hey
y'all
have
been
an
awesome
audience.
I
really
appreciate
the
good
questions.
Thank
you.
Thanks
for
your
time,.