►
From YouTube: Kubernetes SIG Auth 20170419
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170419
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
Alright
or
recording
okay,
so
can
everyone
see
my
screen
or
in
someone's
my
screen?
Yep
yep?
Okay,
so
this
is
the
cig
off
meeting
for
Wednesday
April
19th
2007,
as
in
terms
of
a
pull
request,
a
note
that
have
happened
since
last
time.
It's
been
a
relatively
quiet
couple
weeks
for
author
ablated
PRS.
A
couple
of
these
are
still
open
from
last
time,
notably
the
role
that
will
give
all
users
access
to
read
things
like
storage
classes,
we're
still
looking
for
a
name
for
that.
A
So
if
you
have
any
opinions,
hopefully
somebody
we're
just
going
to
send
something
to
the
sing-off
mailing
list
other
than
that,
the
only
one
I
really
checked
on
was
the
producing.
They
are
allocations
by
the
our
Beck
authorizer.
This
is
a
little
bit
more
into
the
API
machinery
side
of
things,
but
will
hopefully
reduce
the
memory.
Sort
of
the
Arabic
are
authorized
are
specifically
when
things
are
hitting
it
that
are
getting
lots
of
denial
requests
other
than
that.
Unless
anybody
else
has
some
PRS
of
note.
B
A
A
A
The
other
ones
that
I
put
here
were
the
one
that
got
sent
to
the
sing-off
mailing
list
pretty
recently
about
proposing
the
way
that
we
might
do
auth
set
up
for
federated
control
planes.
This
is
actually
spun
out
of
a
separate
document.
That
was
maybe
a
more
overarching
thing,
and
this
is
specifically
talking
about
proposals
around
how
Federation
might
act,
as
particular
users
when
talking
to
the
underlying
clusters.
So
if
I
create
something
in
the
Federated
API
control
plane,
how
does
the
fact
that
I
created
that
translate
to
you
know
what?
A
How
that
for
the
right,
federated
API
server
actually
talks
to
thee
on
the
underlying
clusters
that
is
trying
to
create
into
actual
resources.
One
I
know
that.
Thank
you.
You
are
actually
on
yeah.
Do
you
want
to
take
a
few
moments
and
talk
about
that?
And
maybe
you
know
what
give
us
some
overall
comments.
Yeah.
E
So
what
you
said
is
is
a
very
great
summary.
We
want
to
decide
what
identity
should
the
Federation
control
in
use,
while
sending
requests
to
the
underlying
clusters,
and
this
specific
proposal
proposes
that,
like
we
make,
we
allow
multiple
implementations
and
the
two
primary
ones
that
we
want
to
support
is
a
single
identity
where
the
Federation
control
plane
uses
Singh,
do
send
all
requests
underlying
clusters
and
the
other
one
is
well
user
identity,
so
it
impersonates
the
user
which
triggered
that
request.
E
E
We
are
going
to
add,
like
it
says,
Federation
identity
provider
and
they
can
be
multiple
implementations
of
it,
which
is
similar
to
like
we
have
an
authorization
mode
flag
in
kubernetes,
like
no
other
implementations
as
well.
So,
similarly,
this
is
this
design
proposes
a
new
flag
and
you
can
say-
and.
E
So
this
doesn't
talk
about
that,
but
we
have
a
separate
proposal
where
we
want
to
support
our
back
relation
API
as
well.
That
way,
even
if
you
create
other
crews
in
Federation
control,
plane
they'll
be
synced
across
all
the
clusters,
so
that's
a
way
to
ensure
that
you
have
modules
in
all
your
list:
authorization
rules
in
all
your
clusters-
and
that
is
a
separate
issue
not
discussed
in
this
one.
This
is
more
about
what
identity
should
the
Federation
control
in
use?
I.
B
Know
the
the
per-user
where
the
Federation
control
plane,
replays
requests
as
the
user
that
created
the
resource
or
updated
the
resource
that
that
is
kind
of
going
over
territory
that
we
touched
on
in
the
main
control
plane.
Where
people
were
wanting
an
annotation
or
a
attribute
on
objects
that
would
track
the
user
that
created
it
or
the
user
that
updated
it
and.
E
E
In
fact,
what
we
are
discussed
before
was
well
field
annotation,
so
that
we
got
which
user
updated
each
field,
but
this
proposal
says
let
me
start
with
just
like
a
resource
owner
also
and
pile
resource
owner
rather
than
per
field.
At
least
that
is
simplified,
but
yes,
it
still
proposes
adding
an
annotation
to
this
yeah.
B
It's
a
little
concerning
that.
The
just
touching
an
object
means
your
powers
are
going
to
be
used
to
replay
that
object.
So
if
a
user
that
is
not
allowed
to
create
something
on
the
underlying
cluster,
creates
it
in
the
Federation
cluster
and
then
that
that
thing
keeps
getting
rejected
by
the
underlying
cluster
because
the
user
is
not
allowed
to
and
then
someone
else
labels
stuff,
you
know
the
labels
get
applied
technically,
they
updated
the
object.
E
So
the
understanding
there
is
the
users
intent
was
like
the
second
users
intent
for
was
also
that
this
replica
said
should
exist
with
this
level,
so
it
like
that
is
the
desired
state
from
the
second
user
that
this
replica
said
should
exist
with
this
level.
So
that
is
what
Federation
control
plane
is
doing
for
that
user.
So
I
might.
A
B
E
Making
for
the
second
point,
if
the
admin
wants
to
set
up
the
odd
set
up
in
this
way,
that
if
a
user
creates
a
resource
in
the
Federation
control
plane,
the
same
user
should
have
authorization
to
do
it
in
the
underlying
control.
Plane
underline
clusters,
and
only
then
that
request
will
succeed.
Then
they'll
use
like
the
user
identity
mode.
E
D
So
why
doesn't
the
fit
like
if
I
want
to
invite
suppose
I
had
no
Federation,
so
it's
Eric's
job
to
like
make
sure
there's
always
three
replicas
sets
and
every
in
all
three
of
our
data
centers
clusters
and
let's
say
I-
have
to
go
on
vacation.
So
I'm,
like
hey
Matt
in
case
we
get
a
new
data
center
while
I'm
on
vacation.
Can
you
add
a
fourth
one
and
so
I
give
Matt
permit
permission
to
do
it
now,
let's
say
I'm
like
I'm
talking
like
mad
and
I
both
are
on
occasion.
D
B
D
E
F
And
I
think
one
of
the
other
things
I
just
want
to
bring
up
for
the
folks
who
haven't
heard
this,
like
one
of
the
things
that
is
important
over
the
long
term.
Is
that
model
that
one
Federation,
if
compromised,
can
compromise
every
underlying
cluster
is
a
very
dangerous
one,
and
works
is
not
that
risky
when
you're
talking
about
a
small
set
of
people
accessing
both
the
cluster
in
the
Federation,
but
the
larger
the
clusters
getting
the
larger
the
Federation
gets.
E
Yeah
so
I'd
like
to
add
one
more
point
that
yes,
we
do
want.
The
more
Dietetic
is
talking
about,
but
there's
also
another
case
like
when
Eric
set
up
Federation
only
for
himself,
and
in
that
case
he
can
give
like
a
specific
fall
Federation
service.
But
what,
if,
like
in
his
example,
Eric
and
Matt,
both
want
to
use
Federation
but
for
different
purposes
like
like
multi-tenancy
in
Federation.
E
A
It
may
be
helpful
to
review
some
of
the
one
thread
that
actually
was
going
to
introduce
this
annotation
to
the
core
control
plane.
This,
the
actual
decision
was
not
even
to
was
to
not
even
add
information
about
who
created
a
particular
object,
because
people
felt
that
it
was
easy
to
get
wrong
or
act
upon
incorrectly,
and
I
think
that
that
articulated
pretty
well
sort
of
the
a
lot
of
the
concerns
around
these
type
of
patterns
of
you
know.
Labeling,
this
person
created
the
object
and
therefore
I'm
gonna
make
decisions
based
off
of
that.
E
But
I
think
the
kubernetes
mode
controller
model
is
a
bit
different
because
says
the
understanding
is
that
it
is
part
of
the
system
so
like.
If
the
the
kubernetes
system
accepted
my
resource
months,
then
the
system
components
are
acting
to
make
the
desired
state
happen
and
they
can
they
don't
need.
My
identity,
like
system,
has
already
accepted
my
input,
but
Federation
is
sort
of
like
above
the
system.
E
We
want
the
underlying
clusters
to
be
able
to
do
authorization
as
well
like
they
should
not
just
trust
that
Federation
accepted
my
replica
set
and
now
Federation
is
creating
like
pods
or
replica
sets
in
handling
jesters.
They
want
to
do
authorisation
that
does
Nikhil,
have
access
to
create
replica
sets
in
these
and
the
link
sisters.
F
F
E
F
So
I
guess
I
would
say
like
if
you
have
a
federation
that
has
a
security
breach,
the
assumption
is,
isn't
the
federate,
Federation
is
compromised,
and
so
the
containment
mental
model
usually
applies,
which
you
try
to
you're
concerned
about
a
security
breach
between
two
groups.
Those
two
groups
shouldn't
be
able
to
security
breach
and
affect
the
other,
and
the
way
you
would
do
that
is
run
different
Federation's
right,
for
whatever
your
threat
model
is
so
there's
some
level
of
the
more
that
you
have
to
worry
about
the
robot
getting
confused
or
the
robot
being
compromised.
E
As
a
condition,
I
would
say,
one
of
our
goal
is
also
like
providing
a
single
pane
of
glass
rather
than
you
having
to
go
through
multiple
endpoints.
We
are
also
doing
stuff
like
single
point
for
policy
enforcement.
Like
some
people,
some
deployments
can
only
go
to
Europe
clusters
or
not
to
a
shared
clusters,
and
some
like
some
production
jobs
can
only
go
do
some
specific
clusters,
so
we
are
having
those
policy
enforcement
as
well.
So
we
want
to
have
a
single
Federation,
then
divide
them
into
multiple
I.
Don't.
F
Think
I
mean
I,
I,
think
you're
right,
like
there's
no
way
you
can
keep
adding
things
to
a
federation
to
do
this,
so
let
the
Federation
be
a
single
pane
of
glass
until
the
impact
of
a
compromise
becomes
too
great
and
best
of
all
I
was
trying
to
highlight.
Was
single.
Pane
of
glass
is
great
until
single
pane
of
glass
lets
you
route
your
entire
business
and
destroy
a
single
button.
F
E
F
I
think
I
was
just
kind
of
highlighting
the
the
impersonation
model
adds
a
lot
of
complexity
on
the
client
side
and
doesn't
reduce
the
probability
that
the
underlying
that
there's
a
confused
deputy
problem
much
and
it
doesn't
limit
the
security
impact
of
compromise
the
Federation.
What
it
does
do
is
ensure
that
there's
a
clear
audit
trail
from
the
from
the
Federation
down
in
the
cluster,
but
there's
potentially
other
ways
to
solve
that
yeah.
E
That
request
will
fail,
because
it's
using
my
identity
and
I
have
access
only
to
one
namespace
and
I'm,
not
sure
how
the
namespace
specific
identity
would
help
it
confuse
deputy
as
well,
because
if
names
all
Federation
has
access
to
five
different
namespaces
I
get
the
confused.
A
PD
can
still
lead
to
a
bug
affecting
all
those
five
names
faces,
because
Federation
does
have
access
to
those
five
name
services.
It
will
use
the
corresponding
identity
to
send
those
requests
in
each
of
those
five
namespaces
and
all
of
them
would
succeed.
But.
F
Are
there
more
bugs
in
that
direction,
so
we
yet
fix
those
bugs
regardless
anyway,
if
we
have
a
complex
way
of
assigning
who
did
what
that
adds
more
bugs?
Are
we
more
secure
or
less
secure
and
I
think
that's?
The
trade-off
is
there's
just
as
many
ways
that
the
field
level
tracking
can
be
raw
yeah
I
would.
A
You
know
I
think
that's
a
good
example
of
we're
tracking
users
actually
does
add
a
lot
more
of
complexity
in
terms
of
the
setup
and
having
to
say
you
know
in
their
initial
proposal,
there
was
an
actual
thing
saying:
oh,
you
know
we're
gonna
keep
track
of.
This
user
actually
means
this
user.
If
you're
talking
to
this
cluster
are
the
is,
it
seems
like
the
the
biggest
concern
here
is
that
this
is
sort
of
a
rabbit
hole
that
we're
going
to
go
down,
but
doesn't
really
have
a
clean
or
even
a
correct,
possibly
answer
so.
F
I
was
gonna.
Add
you
like
the
mental
idea
that
you
have
to
you,
have
to
be
able
to
act
as
both
yourself
and
the
actor
I
mean.
We
could
certainly
some
like
assuming
you
have
a
robotic
count
on
each
of
the
individual
clusters,
a
service
account
or
whatever
that
is
materialized
up
into
the
Federation
through
credentials
or
whatever,
and
it's
granted
our
back
access
to
the
clusters,
there's
nothing
that
necessarily
prevents
us
from
adding
an
additional
layer
on
top
in
the
Federation
that
says
before
you
can
even
edit.
F
You
must
still
have
access
in
that
namespace
for
you
to
do
edit
actions
on
the
underlying
cluster,
which
defends
against
the
class
of
action
of
you
know
you
at
the
Federation
level,
had
access
and
it
was
taken
away,
but
the
Federation
still
lets
you
in
and
that's
kind
of
a
we
can
make.
If
we
make
those
the
intersection,
we
might
do
more
access
control
checks,
but
it
adds
another
layer
of
you
defend
against
the
possibility
that
the
user
shouldn't
have
access
to
the
Federation
and
you
require
them
to
have
access
at
the
underlying
cluster.
F
E
F
Say
that
I
think
you
start
getting
into
those
scenarios
and
somebody
who
has
access
to
a
namespace
that
has
access
to
lots
of
clusters
when
you're
trying
to
prevent
the
person
in
that
namespace
from
accessing
those
underlying
clusters
or
like
you're,
already
kind
of
in
a
weird
spot,
which
is
you
trust
them
enough
to
destroy
entire
applications?
But
then
you're
worried
about
them.
F
E
Yeah
I
mean
it
depends
on
how
much
control
D
one.
Is
it
that,
if
you've
added
your
cluster
to
the
Federation,
then
you're
fine?
With
finish
and
adding
everything
that
it
wants
to
to
your
cluster,
you
want
to
have
control
over
what
all
like
what
subset
of
those
or
which
one
of
those
resources
do
make
up
into
your
cluster.
So
then,
you
explicitly
want
to
give
access
to
users
to
your
clusters.
E
If
not,
if
you
don't
want
the
control,
you
just
give
the
Federation
identity,
you
use
the
single
identity
model
and
give
Federation
access
to
it.
Some
namespaces
on
your
cluster
and
all
those
objects
and
those
names
faces,
make
up
to
your
cluster
as
well.
Yeah,
like
which
model
do
you
want,
and
the
proposal
is
to
support
both
but
I
guess
some
of
the
comments.
I'm
getting
is
you're
saying
these
user
identity
is
not
as
valuable
like.
Maybe
admins
don't
want
it.
I
mean.
B
It
adds
a
lot
of
complexity
and
it
requires
a
lot
of
trust
in
the
Federation
server
to
allow
impersonation,
and
you
start
to
get
into
like
the
user
identity
mapping
stuff,
where,
if
you
have
different
awesome
methods
for
Federation
and
underlying
clusters,
and
you
have
to
map
between
one
provider
and
another
provider
like
I.
It
just
seems
like
the
the
number
of
issues
it
introduces
are.
E
The
federated
identity
or
like
mapping
the
identity
scenario,
which
was
brought
up
earlier
as
well
I,
see
I,
was
looking
at
the
comments
on
the
enterprise
control
for
Kate's.
The
other
discussion,
which
was
supposed
to
happen
as
well
and
they're
like
I,
saw
a
company
in
that
sort
of
I
agree
that
most
people
would
want
federated
identity,
and
that
discussion
has
happened
at
other
places
as
well
that
maybe
most
people
have
like
the
same
identity
provider
across
clusters.
E
E
I,
just
sort
of
complete
by
saying
once
and
I
like
to
summarize
that
this
proposal
doesn't
like
is
a
small
subset.
It
doesn't
in
the
first
milestone.
We
are
not
saying
we
will
implement
the
sole
user
identity,
because
the
majority
scenario,
at
least
for
it
seems
to
me,
is
that
people
who
would
have
federated
identity
and
we
who
need
that
mapping
and
similarly
doesn't
say
we
won't
have
field
based.
E
A
D
Got
ray
Wang
here
who
actually
worked
extensively
on
Google
cloud
platforms,
authorization
and
and
on
our
tenancy
and
actually
one
of
the
people
I
consulted
with
when
we
were
first
starting
out
with
kubernetes
trying
to
design
our
Mac
and
it
had
some
good
insight.
So
I'm
pleased
to
have
rain
Wang
here
to
talk
about
a
proposal
for
a
hierarchy.
I
guess
an
automation
of
namespaces
go
ahead
right.
G
You
know,
as
we
kind
of
over
the
last
year
we've
been
talking
with
enterprise
customers,
both
using
TCP
as
well
as
just
using
kind
of
kubernetes
from
prime
or
cross
cloud.
One
thing
that
stands
out
is
that
they,
they
say
this
dilemma
of
both
wanting
to
have
a
single
cluster.
So
they
can.
You
know
impact
as
well
as
having
a
single
management
entity
where
they
can.
G
H
Alright,
well
let
me
let
me
see
how
I
can
do
here
I'm
on
vacation,
so
I'm
looking
at
a
piece,
but
you
know
so
anyways
the
the
goal
this
is
is
to
take.
You
know
two
things
one
is
to
make
one
cluster
be
able
to
be
partitioned
and
segmented,
for
different
workloads
and
to
our
customers.
Also
explain
it.
You
know
exclaim
to
us
that
they
want
to
run
multiple
clusters
because
they
want
to
run
them
in
different
regions
right
or
they
want
to
run.
H
You
know
different
workloads
on
them,
but
they
want
to
be
able
to
have
one
central
point
of
administration,
so
in
general
these
companies
tend
to
have
one
DevOps
team
which
may
have
ten
or
fifteen
people.
You
set
up
everything,
but
they
have
hundreds
and
hundreds
of
Engineers
that
they
wanted
to
take
care
of,
and
so
they're
thinking
about
how
they
can
use
kubernetes
in
this
in
that
kind
of
setup.
H
So
the
thought
that
we
have
on
the
proposal
is
if
we
can
make
have
a
central
database
of
all
namespaces
right
and
so
I
just
picked
on
LDAP,
but
it
really
could
be
anything
and
you
could
set
up
a
namespace
there
and
then
a
cluster
could
effectively
look
at
that
database
as
the
source
of
truth
for
all
namespaces
and
then,
in
addition
to
looking
at
the
source
of
truth
for
namespaces
and
also
looking
at
a
first
source
of
truth
for
various
authorizations.
So
you
could
think
about
quota.
You
could
think
about.
H
You
know
the
ability
to
run
a
particular
job
there.
So,
even
though
the
namespace
may
be
present
or
active
in
a
cluster,
it
may
not
have
the
ability
to
run
any
jobs
there
because,
for
example,
they
don't
want
to
give
capacity
to
you
know
where
maybe
they
have
something
in
Asia
where
they
have
limited
capacity.
They
want
to
be
able
to
say
nope.
H
This
particular
team
in
namespace
can
only
run
in
US
and
EU,
and
this
team
can
run
in
all
all
clusters,
and
so
we
thought
about
this
in
terms
of
technically
of
just
having
the
idea
of
I
think
we
called
it
a
namespace
controller
but
again
I'm.
Not
that
could
really
be
expert,
but
the
idea
is
is
that
we
would
have
this
database
like
LDAP,
sync
all
of
the
namespaces
into
the
clusters
that
are
subscribed
to
it
and
then
also
control
their
their
access
authorization.
H
So
for
LDAP
you
could
imagine
that
we
create
a
DN
for
each
namespace
and
then
through
LDAP
hierarchy.
We
actually
can
start
to
to
attach
policies
that
are
hierarchical
in
nature
through
the
LDAP
pirate,
and
so
now,
when
we
go
to
authorize
the
the
the
system
that
took
talks
to
LDAP
can
say:
okay,
this
is
cool.
Let
me
go
ahead
and
look
this
up
and
it
can
use
the
hierarchy
in
the
DN
to
give
the
answer.
H
A
Yeah,
nothing,
it
I
mean
it's
important.
We
use
up
there
that
it's
not
actually
tied
to
LDAP.
The
LDAP
is
the
you
know
the
thing
that
you're
using
in
the
examples
more
that
the
idea
would
be
to
control
the
hierarchical
policies
around
namespaces
to
potentially
on
different
clusters
through
some
central
administration
unit.
That's.
H
Right,
we
feel
that
if
the
clusters
are
all
enrolled
so
to
speak
into
trusting
that
names
using
all
my
source
of
namespaces
come
from
the
central
place
right
and
you
can
use
any
number
of
systems
I
not
to
be
that
central,
so
LDAP
is
one
of
them,
but
you
could
imagine
that
various
cloud
providers
use
your
own
inherent
systems
that
they
have
that
do
similar
activities.
I.
D
G
G
I
F
Other
one
I
thinks
a
few
like
like
philosophy
things
where
the
core
project
tries
to
not
break
this
kind
of
mental
model
or
the
endorses
or
guests
or
recommends
around
the
idea
of
you
know.
Programming
down
and
main
space
is
being
consistent
across
clusters
and
not
creating
things
that
that
cut
against
the
grain,
or
at
least
leaving
affordances,
for
it
I
think
that'd
be
the
other
one,
which
is
a
little
bit
more
of
a
philosophical
yeah.
D
Designs
being
considered,
maybe
and
they're
not
clear
one
was
that
like
when
you
try
to
create
a
namespace
like
it
goes
off
in
checks
to
see
Val
def,
that's,
okay
and
the
other
one
was
only
the
LDAP
sinker
can
create
namespaces.
So
that
might
be
a
role
change
and
then
it
just
creates
them
from
LDAP
and
I.
Don't
think
that
one
requires
an
admission
controller
at
all
right.
I
H
D
H
Okay,
so
I
can
just
give
you
the
background
and
again
this
could
just
be
my
lack
of
understanding,
but
what
we
want
to
be
able
to
do
with
these
namespaces
and
these
objects
and
attribute
classes
in
LDAP,
as
picking
on
LF
again,
is
to
be
able
to
say
certain
things
like
this.
Namespace
is
allowed
to
do
certain
things
and
it's
not
allowed
to
do
certain
things.
So,
for
example,
in
this
namespace
the
only
valid
container
registry
is
X
or
you'll
only
can
run.
H
I
Great
so
I
think
it's
it's
interesting
to
actually
view
this.
In
terms
of
you
know
not
one
design,
but
a
pattern
that
you
know,
as
you
build
up,
say,
some
restriction
in
terms
of
which
containers
you
can
run
in
which
namespace
that
knows
how
to
actually
read
from
a
policy
engine
that
may
be
back
by
LDAP
I.
Don't
think
that
that's
like
I,
think
you
know
finding
ways
to
decompose
this
like
I'll,
take
another
examples
that
you
you
propose
her
an
authorizer
as
a
web
hook
right.
I
B
Having
to
program
down
means
that
we
can
support
like
a
wide
variety
of
use,
cases,
including
something
I
think
Clayton
mentioned
as
a
call
out
here,
which
is
like
supporting
things
driven
by
LDAP,
but
also
supporting
someone
implementing
the
same
policy
just
by
themselves.
So
the
the
primitive
if
we
support
those
primitives
and
you
can
program
those
down
from
LDAP
or
manually
or
from
out
some
other
source,
it's
powerful
and
it
lets
the
individual
clusters
coast
like
instead
of
having
like
eight
points
of
failure,
whereas
any
of
the
central
LDAP
things
are
down.
H
I
There's
a
philosophical
design
here
of
really
a
sort
of
loose,
pushing
a
policy
down
instead
of
a
live
sort
of
sinking
and
and
and
decomposing
the
features
so
that
they
can
be
mix
or
match
and
be,
you
know,
have
independent
utility
outsider.
You
know
the
scenarios
that
you
have
here.
One
thing
for
the
admission.
B
Stuff
that
could
be
interesting,
I
think
the
team
that
was
looking
at
some
of
the
OPA
policy
had
demoed
something
I
want
to
say
like
six
months
ago
here.
So
if
you
scroll
down
the
notes,
you
can
probably
find
a
link
to
that,
but
I
think
Clayton
was
talking
to
him
about
possibly
putting
together
an
admission
plugin
that
would
take
just
an
OPA
policy,
and
so
you
could
use
that
to
program
down.
You
distribute
the
the
policies
that
you
wanted
on
a
particular
coaster.
Let.
H
Me
just
ask
one
question
again,
for
my
clarification,
so
in
terms
of
like
are
bat,
the
webhook
versus
are
back
authorized,
which
I
think
might
be
related
here
is
that
you
talked
about
syncing
our
back
policies
in
two
clusters
versus
having
them
call
out
to
a
web
localizer
right.
How
do
we
make
that
reliable
in
terms
of
the
fact
that,
like
you
know,
our
users
expect
that
when
they
go
ahead
and
at
the
LDAP
or
the
backend
database
level
turn
off
an
authorization
that
that
reliably
get
squished
into
all
the
clusters?
So
in.
F
H
F
Rule
of
thumb
here
is
that
when
everybody
says
they
wanted
to
take
place
immediately,
the
dirty
little
secret
in
enterprise
software
is
that
what
they
really
mean
is
within
five
minutes
or
within
10
minutes
or
within
an
hour,
and
so
usually
and
again
like
this
can
vary
like
don't
get
me
wrong
on
this
there's
a
little
bit
more
of
a
when
you
actually
start
digging
into
these
scenarios.
It's
been
my
experience
that
you
can
push
back
and
say
well,.
H
F
I'll
say
this:
I,
don't
think
I
mean
I'm
not
personally
opposed
to
a
webhook
call-out
model.
I.
Do
think
that
a
useful
default
is
reconciliation,
but
it
comes
with
a
lot
of
edge
cases,
and
we
want
to
make
those
educators
less
sharp
and
have
tools
that
make
it
easy
to
do
reconciliation
cleanly,
but
there
will
always
be
cases
like
external
omission,
external
up
hook.
Those
are
all
very
reasonable
one
of
the
challenges
with
admission
and
external.
F
What
hooks
is
that
they
don't
give
you
any
tools
to
go
deal
with
the
fact
that
policies
change
over
time,
and
so
you
can
do
things
like
say:
hey
this
person
can
access
the
cluster
anymore,
but
it
doesn't
give
you
any
tools
to
say
the
thing
that
the
person
did
would
be
worth
indicated
also
is
not
working
if
they
put
a
secret
in
place,
if
they
so
usually
anything
that
deals
with
admission
or
external
web
hooks
still
needs
some
sort
of
reconciliation
policy.
You
need
to
be
able.
D
I
F
H
I
B
Yeah
I,
like
the
I
like
the
conceit
of
driving,
namespace
creation
and
quota
and
policy
for
the
things
we
support,
driving
that
via
some
external
source
of
truth
and
possibly
where
it
makes
sense,
pairing
it
with
call-outs.
If
the
existing
primitives
that
we
support
are
insufficient
or
you
know,
you
have
other
kind
of
specialized
policies
that
aren't
cleanly
expressed
in
objects,
I
think
that
is
a
good
direction
to
drive.
Yeah.
D
You
can
a
spreadsheet
exactly
CSV,
whatever
demo
file,
yeah
yeah
and
then
just
you
know
whose
pattern
that
shows
a
couple
of
key
things
like
quota,
namespace
creation
and
then
the
basic
you
know
initial
are
back
roles
for
that.
For
those
namespaces
show
that
pattern,
and
then
we
can
start
to
talk.
Come
back
to
us
and
talk
about
okay,
now,
I
need
to
add
image.
Policy
now
I
need
to
add
pod
security
policy.
How
do
want
to
add
all
those
things
yeah.
I
F
Dirty
little
secret
to
is
that
things
like
you
can
control
apply
and
all
those
should
work
on
both
cluster
scoped
and
regular
scoped
resources
the
same
way
and
if
they
don't,
we
need
to
go
fix
them,
and
that
pattern
is
something
we
want
to
be
able
to
do.
Bounded
scoping
for,
like
people
to
say,
like
I'm
gonna,
go
apply
all
these
auerbach
rules,
whether
they're
cluster,
scoped
or
namespace
scoped,
or
whether
you're
creating
the
namespaces
yourself
most
of
the
time.
Those
are
things
that
we
should
be
able
to
just
make
work
through
reply
and.
D
H
I
Think
a
great
a
great
pattern
here
is
the
core
OS
Dex
stuff,
as
a
way
of
having
an
external
project
that
integrates
with
a
bunch
of
the
kubernetes
stuff,
not
as
a
controller,
but
it
is
sort
of
like
something
that
can
live
on
its
own.
That
brings
in
a
lot
of
the
this
sensibility,
and
it's
also
sort
of
centralized.
D
And
kind
of
addresses
like
the
identity
Federation
a
little
bit,
because
a
neat
overlap
here
would
like
right,
not
right.
Now,
coupe
Fed
creates
namespaces
if
they're
missing
in
all
the
things
this
thing
would
be
taking
that
over
from
coop
fed
I
think
they
can
play
together,
but
I.
All
kind
of
think
like
this
thing,
is
the
better
place
to
own
that
than
coop
fed
yeah.
F
We
actually
nikhil-
and
I
talked
about
this-
like
I-
don't
know
that
we
brought
it
up
in
the
last
one,
but
the
design
model
that
I'm
hearing
a
lot
is.
Most
people
want
central
LDAP
for
identity
and
in
any
model
where
you're
mapping
that
in
there's
a
there's,
a
very
useful
intersection
between
who
has
access
to
these
clusters
aged
independently.
F
I
Contrast
with
the
the
cube
fed
stuff
is
the
cube
fed
stuff.
If
I'm
not
wrong,
it's
like
a
push
model
where
you
have
a
centralized
thing
that
has
keys
to
everything,
whereas
with
this
type
of
model,
you
could
run
a
synchronized
controller
on
each
cluster
that
reads
out
to
LDAP
and
has
overlapping
policy
that
it
verifies,
and
so
it
ends
up
being
a
pull
model,
and
it
can
it
can
be
so
this
means
that
you
don't
necessarily
have
one
place
really
for
all
clusters.
Yeah.
B
D
Mitch,
the
LDAP
reminds
me
of
another
pattern
that
Google,
which
I
think
works
well,
which
we
might
want
to
promote
with
kubernetes
is
in
the
google
internal
equivalent
of
kubernetes.
Every
engineer
with
a
person
who
probably
adopts
I
know
has
basically
when
they
start
on
day
one
they
get
a
namespace
created
for
them
that
is
named
after
their
username
and
that
they
have
a
limited
set
of
resources
and
they
have
constraints
on
what
they
can
do,
but
they
get
to
use
exactly.
G
Then
one
other
pattern:
we've
seen
a
little
bit
convenient
GCP
projects,
but
I
think
we'll
probably
reflecting
over
days
as
well
as
ad
means
more
and
more
getting
to
the
model
where
they
don't
actually
allow
their
together.
First,
you
just
create
kind
of
raw
resources
on
their
own.
They
templatized
things.
So
you
know
with
the
GC
projects
where
customers
will
build
a
dozen
internal
templates
and
those
if
they
have
to
you,
know,
B's
and
policies
have
to
be
applied
and
have
drawing
certain
things
and
those
are
dying
in
the
template.
G
The
only
one
asked
question
about
is
we're
starting
to
see
customers
coming
to
us
and
they're
gonna
confused
about
you
know
the
the
thing
that
affects
whether
something
can
talk
to
something
else.
Somebody
contempt
or
something
is
a
result
of
many
different
policies
that
have
different
data
model,
starting
different
places
and
is
starting
to
ask
about
how
to
how
to
debug
kind
of
across
this
room
policies.
G
B
So
there
are
a
lot
of
layers
where
you
might
have
permission
to
create
an
object,
but
then
the
resulting
object
gets
denied
because
of
quota
or
the
resulting
object
it's
created.
But
then
it
can't
talk
to
anything
because
of
network
policy,
and
so
there
there
are
a
lot
of
layers
where
things
can
run
up
against
tackle
boundaries
or
policy
boundaries.
There
is
a
proposal
for
like
advanced
auditing,
which
is
trying
to
tie
together
more
and
to
end
information.
B
It
doesn't
connect
all
of
those
layers,
but
it
it
helps,
especially
with
the
API
layers,
so
that
you
would
be
able
to
see.
Oh,
this
was
allowed
because
this
authorizer
allowed
it
because
of
this
role
found
this
way
so
that
that's
a
there's
basic
audit
in
place
now,
but
there's
a
proposal
for
improving
that
and
trying
to
tie
together
some
of
those
layers
and
bring
out
more
of
those
there's.
D
You
know
as
three
buckets
like
you
might
store
the
credentials
it
needs
for
those
external
services
somewhere
external,
and
then
you
have
this,
like
you
might
lift
those
in
LDAP,
for
example,
and
then
say
like
okay,
you
need
this
key
ring
for
this
namespace
and
then
sink
those
secrets
in
or
indirectly
provide
access
to
them
as
part
of
the
definition
of
that
namespace.
That's.
G
G
So
we
have
a
lot
of
kind
of
sad
customers
about
trying
to
debug
like
what
are
all
the
policies
that
I
need
to
flick,
flip
for
something
to
assess
something
or
to
start
something
processing,
something
to
the
point
we're
starting
to
consider
like
maybe
building
you
know,
indexing
all
those
policies
or
at
least
a
central
place.
You
didn't
go
and
say
what
are
the
things
that
might
affect
this
particular.
You
know
vm
upon
or
something
yeah.
F
We
want
to
have
better
I
think
one
of
the
challenges
is.
We
started
from
the
assumption
that
we
want
to
have
a
lot
of
tools
that
can
be
used
together
and
provide
the
most
power
for
people
and
some
of
like
the
happy
path
like
no
razor
blades
flows
are
pre
configuration
or
examples,
or
things
that
we
haven't
really
thought
I've
been
created,
yet
that
walk
people
through
unfolding
those
ideas
so
that
they
don't
have
to
necessarily
know
it
all
up
front.
F
I
Think
you
know
some
guidance
for
users,
and-
and
we
should
be
clear
on
this-
is
that
the
namespaces
that
thing
right,
like
like
Network
policy
within
any
sort
of
like
policy
that
restricts
things
within
a
namespace-
is
gonna,
be
error-prone
and
probably
subject
to
confuse
deputies
and
all
sorts
of
other
things,
and
so
we're
at
all
possible
guiding
users
to
say
you
know:
do
the
namespaces,
your
security
boundary.
Then
then
things
will
be
a
lot
cleaner.
F
I
I
started
a
company
around
kubernetes
instead
of
a
company
around
spiffy,
but
is
is
driving
some
of
this
stuff
and
there
are
sort
of
discussions
and
process
going
on
there.
I
haven't
brought
it
up
to
this
group
just
because
it's
not
baked
to
know,
but
we're
gonna
need
it.
Especially
if
we
look
at
things
like
every
time
you
have
a
web
hook.
We
end
up
with
like
a
mess
of
new
TLS
flags
that
nobody
understands
right.
So
spiffy
is
useful
not
only
for
stuff
running
on
kubernetes,
but
also
for
stitching
together
kubernetes
itself.
I
D
The
way
I've
been
thinking
about
it
is
new
spaces
like
form
the
security
boundary
for
humans,
that
collaborate,
but
service
accounts
which
are
scoped
to
namespaces,
are
used
by
those
equally
trusted
humans
to
further
scope,
stuff
that
runs
in
that
namespace,
including
like,
if
you
run
like
a
front
end
and
a
back
end
and
you,
the
whole
team
runs.
Both
you
might
choose
to
like
use
to
name
to
service
accounts,
to
provide
service
to
service
identity
amongst
the
many
micro
services
that
you
manage,
but.
B
Know
we're
almost
out
of
time
just
just
to
go
back
to
the
debug
abilities.
David,
that's
one
of
the
reasons
we
prefer
policy
expressed
in
objects
over
policy
and
force
through
opaque
web
hooks
if
you're
chaining
together,
two
or
three
web
hooks
to
do
something
and
something
goes
wrong
or
something
is
allowed
that
you
don't
expect.
Well,
suddenly
you
have
to
go
to
the
other
system
and
talk
to
the
administrator
of
the
web
book
and
try
to
figure
out
like
what
is
even
behind
this
thing.
B
D
The
whole
infrastructure
as
code
thing,
like
you
know,
I,
think
it's
very
powerful.
Kubernetes
cleared
of
api's
are
great.
We
need
more
of
them
and
the
whole
sinky
thing
fits
in
with
the
whole
infrastructure
is
code
and
LDAP
is
just
the
revision
control
system.
For
your.
You
know,
infrastructure
code.
I
I
A
All
right,
so
we're
pretty
much
at
that
time
that
there's
one
last
design
PR
that
I
did
see,
which
is
about
securing
the
security
model
for
user-facing
services.
This
is
notably
has
a
little
bit
of
overlap
with
the
threat
models,
design
proposal
that
Clayton
put
together
Ivan
taken
a
huge
look
into
that,
but
for
anybody
interested
in
that
space,
good.
B
Take
a
look
yeah,
there's
a
really
good
interaction
between
Quentin
and
Clayton,
so
pretty
sunbed
there
yeah.