►
From YouTube: Webhook Fatigue? You're Not Alone: Introducing the CEL Expression Language Features...- Joe Betz
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.
Webhook Fatigue? You're Not Alone: Introducing the CEL Expression Language Features Solving This Problem - Joe Betz, Google
Speakers: Joe Betz
In Kubernetes 1.23 we integrated the CEL expression language into open source Kubernetes, making it possible to support the vast majority of CRD validation use cases without a webhook. This includes multi-field validation rules, immutability checks and more. And this is just the beginning, we plan to extend admission control to support CEL expressions as well, which will make it possible to replace far more of those operationally troublesome webhooks with a much simpler alternative. We're convinced this leads to a better development experience for anyone extending Kubernetes. And more importantly, it makes cluster operations simpler and safer. Learn about this future of Kubernetes extensibility from a contributor who has been involved in Kubernetes extensibility for over 5 years, including the projects to bring CRDs and Webhooks to GA, and who has been involved in improving the stability of Kubnernetes control planes in GKE for years. In this talk I'll introduce CEL and how we've integrated it into Kuberentes and answer questions including: What can you do with CEL in Kubernetes today? What future features are planned? Can there really a future where webhooks are the exception instead of the norm?
A
All
right
I'm
going
to
go
ahead
and
get
started.
Thank
you.
Everybody
for
coming
this
morning.
I'm
excited
about
this
talk,
I
hope
it
is
interesting
to
you
all.
My
name
is
Joe
Betts
I'm,
an
engineer
at
Google
I've
been
working
on
kubernetes
for
about
five
years.
I
spent
a
couple
years
as
an
FCD
maintainer
and
quite
a
bit
of
time
as
a
contributor
to
Sig
API
Machinery,
where
I've
been
working
on
extensibility
features.
A
It's
going
to
help
us
solve
problems.
I'll
then
dive
into
two
major
use
cases.
The
first
use
case
is
going
to
be
crd
validation,
which
most
people
would
prefer
not
to
use
a
web
hook
to
do,
and
then
the
second
one
is
admission:
control,
usually
focusing
on
policy
enforcement
use
cases
I'll
then
wrap
it
up,
tie
it
together,
talk
about
the
future
and
some
areas
where
we
can
use
some
help.
So,
let's
get
started
by
talking
about
the
history
of
web
admission
web
hooks,
so
these
were
introduced
back
in
kubernetes
1.7
roughly.
A
A
So
they
had
identified
that
organizations
needed
better
policy
control
that
cloud
providers
needed
better
extension
points
to
integrate
with
kubernetes
and
that
extension
authors
need
a
better
way
to
perform
crd
validation,
it's
actually
a
pretty
accurate
list,
and
at
the
time
there
was
a
couple
different
options.
There
was
a
feature
called
initializers.
That
was
an
alpha
at
the
time
there
was
the
built-in
admission
controllers
and
kubernetes
that
are
compiled
into
the
API
server,
and
then
there
was
an
early
form
of
admission
web
hooks.
A
And
people
were
successful
in
implementing
a
lot
of
what
they
needed
to
build.
With
this,
a
ton
of
great
stuff
has
been
built.
You
can
see
web
hooks
in
pretty
widespread
use
across
kubernetes,
but
unfortunately
that's
where
things
started
to
get
into
trouble.
Reports
started
coming
in
of
people.
You
know.
Cluster
admins
and
Cloud
providers
were
reporting,
control,
plane,
outages
from
web
hooks.
They
were
reporting
filled
upgrades,
they
were
even
recording,
reporting
failed
rollbacks
and
it
took
a
while
for
everybody
to
kind
of
start
to
get
their
head
around.
A
What
had
gone
wrong,
but
I
think
there
was
two
major
categories
of
problems
that
were
causing
web
hooks
to
cause
so
much
trouble.
One
is
that
they're
operationally
complex,
so
every
time
you
want
to
introduce
a
web
hook
into
a
cluster
you're
introducing
a
new
binary,
it
has
to
run
somewhere.
You
have
to
figure
out
how
to
deploy
that
binary,
upgrade
it
roll
it
back
monitor
it
have,
you
know,
run
books
to
deal
with
any
problems
with
it.
A
The
other
problem
is
they're
way
too
easy
to
misconfigure.
I.
Think
the
the
most
obvious
example
of
this
is
that
whenever
you
install
a
web
hook,
you
have
to
decide
what
its
failure
policy
is.
You
either
have
to
choose,
fail
open
or
you
choose
fail
closed.
If
you
choose
fail
open.
What
you're
saying
is
that
if
my
web
hook
fails
the
binary
stops
serving
requests
either
it's
become
unavailable
or
it
starts
returning
errors.
Then
I'm
just
going
to
let
the
request
through
anyways,
even
if
that
web
hook
would
have
rejected
them.
A
So
if
the
purpose
of
your
web
Hook
was
to
enforce
some
security
policy,
that's
clearly
a
problem.
On
the
other
hand,
if
you
choose
to
fail
closed,
what
you're
saying
is,
if
that
webbook's
having
a
problem,
let's
return
theirs,
if
it's
unavailable
I'm
going
to
reject
all
requests
that
that
were
being
routed
to
that
web
hook
right.
So
if
I
was
matching
all
pods
or
all
deployments
now,
I'm
going
to
reject
all
those
requests
and
I'm,
basically
losing
my
control,
plane,
availability.
A
I
think
over
time,
cluster
administrators
have
become
aware
of
this
and
have
become
more
and
more
wary
of
web
hooks,
but
we're
stuck
in
the
situation
where
there's
a
large
classes
of
functionality
that
we
want
and
web
hooks
is
the
only
way
to
do
it.
So
the
story
isn't
over
we're
going
to
try
and
tell
the
rest
of
the
story.
Hopefully
we
can.
A
We
can
turn
some
things
around
here
and
one
of
the
one
of
the
pieces
of
good
news
is
that
if
you
actually
go
and
look
at
what
web
books
are
doing,
the
vast
majority
of
them
are
doing
super
simple
stuff.
They
maybe
need
to
make
sure
that
a
particular
field
in
a
crd
is
immutable.
They
need
to
make
sure
that
a
label
works
the
way
they
want.
A
So
maybe
they
always
check
that
a
label's
value
conforms
to
a
specific
format
or
maybe
if
they
have
a
policy
in
their
company
where
they
want
all
pods
or
containers
to
have
some
particular
value
set
in
a
particular
way.
Most
of
these
share
the
common
property
of
being
able
to
be
expressed
in
just
like
a
line
or
two
of
code,
so
this
is
a
good
chance
to
apply
the
80
20
rule.
A
We've
already
made
a
huge
amount
of
progress
on
this
problem,
so
I'm
going
to
focus
on
that
today
and
the
tool
that
we're
going
to
look
at
is
called
the
common
expression
language.
Let
me
give
you
just
a
couple
examples
of
what
that
looks
like
so
here's
some
code,
there's
three
examples
here.
The
one
thing
I
hope
everybody
notices
is
that
this
is
a
pretty
unsurprising,
syntax
right.
This
is,
if
you've
worked
in
any
c
style
programming
languages,
you
can
probably
guess
what
this
code
does
and
you're,
probably
right.
A
I'm
not
going
to
read
through
all
those
examples,
but
I
am
going
to
give
you
a
little
bit
of
access
to
some
of
the
documentation
from
cell
I.
Think
the
authors
have
done
a
pretty
good
job
of
explaining
what
the
purpose
of
this
language
is.
Now
you,
it
is
only
an
expression
language,
it's
not
a
scripting
language,
so
you're
only
going
to
write
a
single
expression,
assay
program
and
that
limitation
causes
some
problems,
but
I
think
in
our
case,
it's
more
of
a
benefit
than
anything.
It's
easy
to
run,
sell
quickly.
A
It
comes
with
a
really
nice
syntax
Checker.
You
can
run
a
type
checking
pass
on
it.
It's
easy
to
extend
and
it's
really
easy
to
embed
and
integrate
with
languages.
So
we've
been
able
to
successfully
integrate
this
with
the
with
the
kubernetes
data
system,
very
well,
both
for
crds
and
Native
types,
and
it
works
really
well.
So
here
are
two
of
the
major
limitations
you
should
know
about
cell
right
away.
The
first
is
because
you
can
only
write
a
single
expression.
A
You
don't
get
any
native
for
or
while
looping,
instead
you're
going
to
be
using
kind
of
a
comprehension
form.
So
there's
there's
the
comprehensions
listed
here.
Also,
you
don't
have
an
explicit
if
else,
so,
instead
we're
going
to
be
using
the
ternary
operator.
I
just
wanted
to
show
a
couple
examples
of
that,
because
this
is
one
of
the
less
obvious
things
about
cell.
A
A
The
second
example
is
even
more
complicated,
so
what
we're
doing
is
we're
taking
a
list
of
objects
where
every
object
has
a
priority
field
and
we're
making
sure
that
no
two
of
those
objects
have
the
same
priority
value.
This
is
possible
to
do
it's
kind
of
on
the
edge
of
what
you
can
do
with
cell,
and
it's
not
super
obvious
how
to
write
this.
One
I
wanted
to
show
a
more
difficult
example
to
give
people
an
idea
of
kind
of
where
the
limits
of
some
might
be.
A
Now
one
of
the
things
that
you'll
you'll
probably
occur
to
you
pretty
quick
is
well
if
I
can
only
write
a
single
expression
that
does
limit
me
in
many
ways.
Are
there
utility
libraries
that
I
can
take
advantage
of
to
do
more
things,
and
the
answer
of
course,
is:
yes.
Cell
comes
with
a
pretty
good
standard
Library.
A
There
are
extension
libraries
for
things
like
strings
regex
matching,
and
things
like
that
that
we're,
including
in
kubernetes,
we
also
went
and
looked
at
four
or
five
major
programming
languages
and
just
kind
of
went
through
all
of
the
most
fundamental
utilities
available
in
those
languages
and
built
out
an
even
more
extended
library
that
we're
going
to
make
available
with
kubernetes.
So
that
includes
more
things
for
regex
more
things
for
list
processing.
A
We
also
identified
that,
even
though
you
could
handle
like
URL
parsing
with
reg
X
that
that's
pretty
awkward
to
ask
people
to
do
so,
we're
going
to
provide
first
class
support
for
that.
So
here's
some
examples
of
some
things.
You
can
do
a
cell
using
the
function,
libraries,
you
do
get
kind
of
like
a
method,
type
syntax
or
if
you
go
a
receiver
type
syntax,
where
you
can
say
dot
to
call
functions.
A
A
If
you
want
to
learn
more
about
cell
I,
would
encourage
you
to
check
out
the
spec
it's
being
used
in
a
variety
of
policy
systems.
It's
been
used
in
some
systems
that
extend
kubernetes
it's
being
used
in
other
cloud
provider
systems.
It's
pretty.
It's
got
pretty
solid
adoption
and
we've
been
working
a
lot
with
the
authors,
we're
pretty
confident
in
it.
A
A
A
So
in
this
example,
the
self
variable
refers
to
the
location
in
the
schema
where
we
put
this
crd
validation
rule.
So
this
rule
is
written
right
under
the
spec,
so
self
refers
to
spec
and
the
spec
contains
both
a
replicas
and
a
Max
replicas
integer
field,
so
you
can
access
both
of
those
in
the
dot
operator.
If
you
then
update
your
crd
after
writing,
this
any
any
c
any
custom
resources
that
you
try
and
write
will
be
validated.
A
A
Foo
they're
the
same
Rule
and
they
do
exactly
the
same
thing,
but
the
one
on
the
foo
field
is
more
convenient
because
the
Field's
optional,
if
you
put
the
rule
up
at
the
top
at
the
spec
level,
you
have
to
first
check
if
the
Field's
present.
But
you
don't
need
to
do
that
if
you
put
it
on
the
actual
field
itself,
because
it'll
only
be
run
if
that
value
is
present.
A
So
there
are
some
conveniences
that
you
can
get
for
choosing
where
to
scope.
The
rule.
We
encourage
you
to
scope
rules
as
narrowly
as
possible
because
it
makes
them
easier
to
write.
Sometimes
you
need
to
put
this
the
rule
higher
in
the
schema
tree,
so
you
have
access
to
more
Fields
if
you're
doing
things
like
Cross,
Field,
validation,.
A
In
addition
to
the
self
rule,
we
give
you
access
to
an
old
self.
What
old
self
is?
It
is
the
value
before
your
update.
So
if
you're,
updating
the
full
value
from
four
to
five
old
self
will
be,
four
self
will
be
five.
You
can
use
this
to
do
things
like
an
immutability
check,
which
is
what
we're
doing
here.
You
could
do
things
like
enforce
that
a
value
is
only
a
monatomically
increasing.
You
could
have
an
append
only
list,
there's
a
large
variety
of
use
cases
for
this.
A
So
the
good
thing
is
cell
is
by
Design
preventing
a
lot
of
types
of
abuse.
The
way
it's
interpreted
means
that
you
can't
really
break
out
of
a
Sandbox.
The
fact
that
you
can't
allocate
variables
means
that
there's
tight
memory
constraints,
but
there's
still
the
ability
to
write
programs
that
could
take
way
too
long
to
run
so
we're
take
we're
using
a
kind
of
a
three-prong
safety
approach
against
this.
A
So
if
you
try
and
write
a
if
you
intentionally
write
a
cell
rule
that,
like
does
like
an
O
cubed
operation
on
the
longest
possible
list,
we're
going
to
actually
detect
that
when
you
write
the
rule
into
your
crd,
we're
not
going
to
allow
you
to
do
it.
You'll
get
a
narrow,
say
in
something
that
you've
exceeded
the
estimated
cost
limit
and
you're
going
to
either
need
to
rewrite
that
rule
or
give
it
hints
about
the
size
of
lists
and
things.
A
So
that's
our
kind
of
our
first
prevention
that
happens
statically
when
you,
author,
crds
the
second
safety
functions
very
similarly,
but
happens
at
runtime.
So
again
we're
going
to
use
this
abstract
cost
unit
measure
and
when
your
program's
running
cell
is
going
to
start
accumulating
the
cost
and
that's
platform
independent.
A
So
it
doesn't
really
matter
if
your
CPU
is
running,
slow
or
you've
got
a
lot
of
load,
it's
still
going
to
run
the
same
programs
towards
to
the
same
completion,
but
if
you
do
hit
that
limit,
we're
going
to
Halt
sell
execution
to
prevent
it
from
running
indefinitely.
We
even
have
a
third
fallback,
which
is
we
wired,
goes
contacts
context
cancellation
into
cell,
so
that
if
the
request
is
canceled
in
any
way
either
because
the
client
went
away
or
because
we've
hit
a
timeout,
we're
also
going
to
stop
sell
execution
immediately.
A
So
we
put
a
lot
of
safety
nets
in
place
to
try
and
keep
cell
runtime
under
control.
Just
to
summarize,
you
can
use
crd
validation
rules
to
write
complex
validation
for
your
crds.
You
just
use
cell.
You
put
it
into
these
x
dash
kubernetes-validations
Fields.
You
can
do
complex,
multi-field
validation.
You
can
use
transition
rules
to
do
things
like
immutability.
We
think
this
is
a
sufficient
substitute
for
the
vast
majority
of
things
people
are
using
web
hooks
for
when
they
do
crd
validation.
We
think
this
is
mostly
a
solved
problem.
A
A
So
once
we
got
that
in
place,
we
started
looking
for
other
opportunities
to
use
cell.
In
fact,
one
of
them
was
the
thing
I'd
wanted
to
use
self
for
in
the
first
place,
which
was
policy
enforcement.
When
we
looked
at
all
the
things,
people
were
using
admission
web
hooks
for
this
was
by
far
the
largest
bucket.
Everybody
was
kind
of
telling
us
generally
the
things
I'm
trying
to
do
fall
into
this
category.
A
This
is
a
big
and
complicated
space.
There
are
many
systems
built
to
do
policy
enforcement
and
it
took
us
a
while
to
get
our
heads
around
a
lot
of
the
things
that
people
were
trying
to
achieve
and
we
looked
beyond
just
kubernetes.
We
looked.
We
talked
to
other
people
doing
policy
enforcement,
other
parts
of
cloud,
Cloud
infrastructure.
A
There
are
entire
programming
languages
written
around
this,
it's
a
big
space,
but
what
we
did
is
we
tried
to
focus
down
on
what
we
needed
to
do
in
kubernetes
to
make
this
possible
with
a
minimal
use
of
web
hooks.
Ultimately,
we
wrote
a
cup
for
this.
It's
called
sell
for
admission
control,
you're,
welcome
to
check
it
out
and
what
I'm
going
to
try
and
do
next
is
explain.
A
What's
proposed
in
that
cut,
we're
working
on
implementing
this
right
now
we're
hoping
to
get
our
first
Alpha
in
1.26,
which
should
be
out
in
around
a
month
or
so,
and
to
kind
of
motivate
what
we're
trying
to
do.
We
wanted
to
make
a
clear
distinction
between
two
major
roles
when
you
do
policy
enforcement,
you
have
the
policy
author
and
you
have
the
cluster
administrator.
A
The
policy
author
is
concerned
with
the
correctness
of
a
policy,
so
there
in
our
case
they'll
be
writing
cell.
They
want
to
make
sure
they
wrote
that
right
they
want
to
test
it.
They
also
want
to
write
reusable
policies,
usually
they're,
trying
to
support
more
than
one
organization,
so
they're
very
concerned
with
making
their
policy
sufficiently
configurable
to
handle
more
than
just
one.
Customer
cluster
administrators,
on
the
other
hand,
are
very
concerned
with
making
sure
that
a
policy
matches
the
goals
of
their
organization
and
they're
very
interested
in
the
operability
of
those
policies.
A
So
the
policy
author
is
going
to
be
responsible
for
writing
a
validating
admission
policy
here,
they'll
Define
in
the
match
constraints
which
resources
that
policy
applies
to.
This
is
very
similar
to
how
an
admission
web
hook
works.
Today
then
they're
going
to
write
cell
rules
that
Express
what
that
policy
does
in
that
cell
rule
they
can
reference
both
the
object
and
some
other
fields,
and
they
can
reference
the
params
that
they
use
to
make
this
configurable
last.
They
Define
a
params
kind,
which
says
what
type
of
resource
they're
using
to
parametize
their
policy.
A
In
this
case
they're
using
a
crd
in
a
simpler
case,
you
could
choose
to
use
a
config
map.
Next,
the
cluster
administrator
is
going
to
create
what
we
call
a
binding.
The
Binding
is
what
connects
this
policy
definition
to
their
cluster
and
they
do
this
with
a
couple
Fields.
The
policy
name
says
which
policy
they're
binding
to
their
cluster.
The
params
ref
says:
Which
object,
they're
using
to
parametize
that
policy,
and
then
lastly,
they
can
have
what's
called
match
resources
which
further
constrain
what
resources
in
their
cluster
this
policy
applies
to.
A
A
They
could
create
an
additional
policy
policy
binding
for
their.
You
know,
production
environment
and
set
this
to
a
different
limit
for
that,
so
you
can
have
more
than
one
binding
for
a
policy
and
you
can
have
as
many
params
as
you
want.
You
can
share
params
between
policies
if
you
need,
or
you
can
create
new
ones
for
each
now.
One
thing
you
might
notice
about
this,
which
is
a
bit
of
a
downside,
is
this
is
quite
a
few
resources
to
create
to
get
something
done
right
here.
A
In
this
example,
you're
looking
at
four
different
kubernetes
resources,
we
can
simplify
that.
If
you
don't
need
parametrization,
we
can
go
down
to
just
two
resources.
If
the,
if
the
policy
author
doesn't
specify
any
need
to
parametize
their
policy,
then
the
cluster
administrator
just
needs
a
single
bind
and
you're
done
we're
down
to
two
resources.
We
take
that
even
further
in
the
most
basic
case.
If
you're
writing
a
one-off
policy,
you
can
write
the
whole
thing
just
in
the
validating
admission
policy.
A
Basically,
what
you're
going
to
do
is
inline
your
bio,
your
binding
information
into
that,
and
you
can
do
that
as
a
single
resource.
We
think
that's
useful
for
cases
where
somebody
just
needs
to
do
something
simple
as
a
one-off
case
and
they're
not
building
like
a
larger.
You
know,
policy
engine
or
something
like
that.
A
We're
just
getting
started
with
this
feature.
So
this
is
we're
working
to
try
and
get
it
out
in
1.26,
which
is
in
development
now
in
the
future.
Before
we
bring
this
to
Beta,
we
hope
to
support
a
variety
of
other
things.
We
hope
to
support
more
actions
than
what
we
support
now
so
right
now
you
can
only
admit
or
deny
a
request,
but
we
don't
think
that's
enough.
We
want
to
be
able
to
have
you
support
like
creating
an
audit
annotation
or
sending
a
warning
back
to
the
user,
but
not
blocking
the
user.
If
the.
A
A
A
We
also
intend
to
add
a
lot
more
support
for
the
rollout
of
new
policies.
So
that's
a
cluster
administrator,
you
probably
when
you
first
introduce
a
new
policy.
You
probably
don't
want
it
enforcing,
yet
you
probably
want
to
just
turn
it
on
in
kind
of
a
dry
run
mode
and
see
what
happens
so
we're
looking
at
some
ways
to
do
that
in
a
really
safe
way.
So
you
can
gather
metrics,
you
can
look.
A
You
can
see
what
the
policy
would
do
before
you
turn
it
fully
on
there's
a
fuller
list
of
features
here
in
the
cup.
I
would
encourage
you
to
check
it
out
if
you're
interested.
This
is
still
in
development,
so
we're
very
much
looking
for
feedback
from
the
community
on
what
would
be
the
most
valuable.
A
All
right,
I'm
going
to
start
drawing
some
conclusions.
The
way
that
I've
been
trying
to
think
about
the
work
that
we've
been
doing
is
that
you've
got
this
established
set
of
use
cases
for
kubernetes.
Many
of
these
are
supported
by
declarative
apis.
This
is
the
stuff
that
you're
most
familiar
with
jobs
and
deployments
and
are
back.
Then
you've
got
this
other
category
of
emerging
use
cases.
This
is
the
kind
of
stuff
that
I've
been
talking
about.
A
A
We
want
to
move
that
boundary
and
make
these
supported
by
declarative
apis,
so
you
don't
need
to
get
web
hooks
involved
in
things
like
this,
there
will
always
be
things
that
you
need
web
books
for,
and
that's
okay,
but
we
want
to
lower
the
barrier
of
Entry
to
get
things
done.
You
should
be
able
to
do
a
lot
of
these
use
cases
without
the
operational
complexity
of
web.
Hooks
cell
moves
the
boundary
for
these
use
cases.
We
think
there
are
a
variety
of
other
use
cases
that
we
have
and
have
not
thought
of.
A
That
would
also
be
useful.
I've
identified
a
couple
of
them
here
so
right
now,
if
you
do
have
multiple
versions
of
a
crd,
you
need
to
do
crd
conversion.
We
think
that,
right
now
you
have
to
introduce
a
web
hook
to
do
that
as
well.
We
think
that's
another
good
place
to
use
cell.
The
kcp
project
has
already
been
working
on
implementation
of
this
we've
been
talking
to
them.
We
really
like
the
work
they've
been
doing.
We
hope
to
bring
that
into
kubernetes.
A
You
don't
get
all
the
validation
rules
that
are
compiled
into
the
API
server,
but
if
we
were
to
express
those
in
cell
and
then
put
them
on
the
open
API,
then
that
would
be
available
to
tooling
much
earlier
to
check.
So
a
lot
of
kind
of
the
static
analysis
that
we
actually
know
for
sure
would
be
invalid.
We
could
then
check
much
earlier
and
like
get
get
Ops
flows
and
things
like
that.
A
The
other
thing
I
was
going
to
mention
is
right.
Now
we're
focusing
mostly
on
validating
admission
but
there's
a
whole
other
class
of
admission
called
mutating
admission,
and
we
are
interested
in
supporting
those
use
cases
in
the
future.
This
would
probably
be
a
separate
cap,
but
sell
does
support
the
construction
of
data
in
the
manipulation
of
data
in
a
way
that
would
work
for
this.
It's
one
of
the
things
that
we
considered
when
we
chose
cell.
So
we
think
it's
possible.
We
hope
to
do
it
sometime
in
the
future.
A
If
you
want
to
learn
more
here's
a
couple
links
the
documentation
for
crd
validation
rules
is
in
the
main,
kubernetes
documentation,
documentation
for
crds.
The
cap
has
a
lot
of
useful
information.
You
can
learn
a
lot
about
cell
just
Google
for
it
you
can
reach
us
at
the
API
Machinery
mailing
list,
and
we
also
have
our
own
slack
Channel.
Just
for
talking
about
cell
you're,
welcome
to
drop
in
we'd
love
to
hear
from
you,
I
am
going
to
stop
there
and
take
questions.
A
Do
you
think
this
is
a
replacement,
so
one
of
the
co-authors
of
this
cap
is
Max
Smythe
that
works
on
Oppa.
So
we
have
been
working
very
closely
with
the
OPA
team
on
making
sure
that
we
build
something
that
they
can
use
now,
it's
possible
that
they
might
not
be
able
to
get
all
their
rules
directly
into
the
API
server
this
way,
but
we
believe
that
the
vast
majority
of
opa
would
not
require
a
web
hook
once
we
do
this
and
they're
they
intend
to
work
on
an
implementation
yeah
here.
B
A
A
I
have
seen
people
do
things
like
run
little
kind
clusters
and
or
mini
cubes
as
a
way
to
get
a
control
plane
and
just
test
things
that
way
so
for
like
a
stock
crd,
you
can
actually
like
do
a
lot
with
that,
because
you
don't
need
the
rest
of
the
cluster,
so
that
might
be
a
way
to
do
it.
We
are
also
providing
a
lot
of
our
sell
stuff
as
a
pretty
accessible
Library.
C
A
So
it
is
it's
extensible,
in
the
sense
that
whoever
brings
it
into
a
binary
can
change
the
libraries
that
it
uses.
There
are
some
settings
that
you
can
change,
so
it
is
going
as
a
kubernetes
author.
We
can
extend
it
by
adding
more
functions
and
things
like
that,
if
you
were
to
use
it
in
your
own
programs,
you
could
also
do
that.
We
don't
have
any
way
to
like
say:
have
you
register
new
functions
at
this
time?
So
in
that
sense,
it's
not
extensible
I
hope
that
makes
sense.
A
F
F
A
A
So
we
think
that
we
want
to
do
that
before
we
go
to
Beta,
so
you'll.
The
way
that
it's
defined
right
now
is
everything
is
at
cluster
level,
but
we
think
that
it
make.
It
makes
sense
to
also
have
like
a
local,
validated
admission
policy
binding,
so
you
could
bind
it
at
the
namespace
level.
You
could
put
that
that
resource
in
the
namespace
and
it
will
automatically
only
apply
to
that
home
space.
That's
something
we
have
also
listed
as
a
feature
before
we
go
to
Beta.
B
B
G
A
H
A
H
A
A
Cross
cross
field
stuff's
harder.
We
don't
have
any
immediate
plans
for
it.
I
would
love
to
talk
to
people
and
understand
more
of
the
use
cases
right
now.
We're
mostly
focused
on
the
per
resource
case,
because
that's
really
useful
I
know
when
you
talk
more
about
the
policy
admission
case
which
I
talked
about.
Second,
that's:
there
are
people
very
interesting
cross,
cross,
object
checks,
so
I
would
love
to
understand
more
of
those
use
cases.
D
A
Oh
yeah,
so
the
the
order
execution
is
pretty
well
defined,
so
validation
is
comprehensive,
so
crd
validation
happens
at
the
same
phase.
That
crd
validation
has
always
happened,
and
it's
comprehensive.
You
get
all
the
errors
that
you
get
back
right.
So
it's
going
to
check
all
your
rules.
The
admission
policies
are
going
to
happen
in
the
admission
control
chain,
which
has
a
very
particular
flow.
So
first
it
runs
all
the
built-in
controllers
and
it
then
it
runs.
A
Then
it's
going
to
run
the
policy
ones
and
then
it's
going
to
rub
them
when
the
web
hook
ones
last.
We
always
run
mutators
before
we
run
validators
so
that
your
validator
is
guaranteed
to
see
something
whatever
is
going
to
be
written.
So
there's
a
very
well
defined
order.
Yeah,
all
right,
I
think
we
are
at
time.
Thank
you,
everybody
for
coming
appreciate.
It.