►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 30 September 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
So
the
I
like
to
think
of
it
in
terms
of
how
the
controller's
going
to
implement
this.
So
you
have
all
these
resources
floating
around
and
there's
a
controller
watching
all
of
them
and
it
and
it's
going
to
see
a
request
to
bind
bar
to
a
b
b
and
the
bar
is
in
the
name
space
and
the
br
is
not,
and
so
it
has
to
decide.
B
Do
I
allow
this
or
not,
and
so
there
needs
to
be
an
algorithm
starting
from
that
bar
and
that
b
to
go,
find
the
reference
policy
to
consult
or
policies,
because
the
way
we
specified
it
last
week,
you
could
have
more
than
one
that
referred
to
the
same
bucket
in
principle
so
that
you
just
and
the
the
two
ways
we
thought
of
it
was
one
you
could
start
from
the
bucket
find
a
bound
br,
go
to
that
br's
namespace
and
then
scan
the
whole
namespace
for
reference
policies
referring
to
that
bucket
and
then
all
of
them
get
enforced.
B
That
was
one
algorithm.
The
other
one
was
the
bucket
could
have
a
pointer
to
a
namespace
on
its
own,
separate
from
the
binding
to
the
br.
Such
that
you
don't
need
a
br,
you
can
just
create
a
bucket
with
a
reference
to
a
namespace,
and
you
go
look
in
that
name
space
for
reference
policies
either.
One
of
those
tells
you
which
name
space
to
go.
Look
in
for
reference
policies,
and
then
I
think
we
agree
that
there's
no
reason
you
can't
have
two
or
more
reference
policies
referring
to
the
same
bucket.
C
B
And
so
that
that
is
a
workable
scheme
and
it's
clear
what
the
user
is
supposed
to
do
in
either
of
those
cases.
So
I
guess
pick
the
one
that
seems
less
less
gross.
A
A
So,
okay,
so
so
go
over
the
second
one
again,
so
you
said
in
the
second
one
you
can
have
multiple
reference
policies
for
the
same
bucket
is
that
is
that
the
distinction
you
might
be
making.
B
B
There
could
be
two
or
more
reference
policies
that
refer
to
the
same
bucket
and
the
only
rational
thing
to
do
from
a
controller's
perspective
is
to
do
an
either
or
or
union
kind
of
an
approach
to
access,
and
that
applies
to
either
approach
right.
As
long
as
there's
no
one-to-one
mapping
between
reference
policies
and
buckets
or
anything
you're
going
to
have
a
situation
where
there
could
be
two
or
there
could
be
three.
B
B
A
How
does
that
get
filled?
If
you,
you
know,
re-bind
a
bucket.
B
A
Well,
you'll
need
oh
yeah,
you
don't
even
need
a
admin
permission
for
that
right.
You
just
create
a
br
that
just
binds
to
it.
A
It's
just
yeah,
no,
I
see
what
you
mean
the
thing
with
the
this
kind
of
forced
you
know
always
requiring
a
br.
Is
you
you
might
end
up
with
some
brs
that
don't
bind.
A
Right
because
there's
a
race
condition
that
would
only
occur.
B
When
you
were
attempting
to
to
create
brs
for
static,
buckets
or
anytime,
you
create
a
br
with
no
bucket.
It's
understood
to
be
a
request
for
dynamic
provisioning,
in
which
case
the
dynamic
provisioning
will
eventually
bind
it
to
a
bucket.
Unless
there's
an
error,
but
yeah
anytime,
you
create
a
br
that
tries
to
bind
to
a
static
bucket,
yeah
there's
a
risk.
I
guess
that
it
doesn't
bind.
A
Yeah
yeah
so
so
cross
cluster.
Let's
say
we're
going
one
cluster
to
another.
I
I
I.
I
also
think
the
this
approach
is,
you
know
it
sounds
cleaner.
I'm
just
trying
to
make
sure
we
think
about
all
the
use
cases
so
cross
clusterism
we're
going
from
one
cluster
to
another,
or
you
know.
Let's
say
one
cluster
is
down
what
would
be
the
reason,
so
all
the
buckets
that
were
created
by
cosy
in
namespace
one?
Do
you
just
recreate
those
references?
A
B
You
need
to
be
careful
to
set
the
deletion
policy
to
retain
in
case
there
was
a
br
that
got
deleted
and
you'd
need
to
be
prepared
to
deal
with
the
fact
that
someone
on
the
original
cluster
could
delete
the
bucket
out
from
under
you,
in
which
case
you're
just
sol.
B
But
that
doesn't
seem
like
I
mean,
that's
a
that's
an
inevitable
problem
right,
anytime,
you're,
sharing
resources,
someone
has
the
right
to
delete
them
and
when
he
does,
anyone
else
who
was
still
trying
to
use
them
is
going
to
have
problems.
That's
just
you
know.
A
There's
nothing
you
can
do
about
that
fair
enough.
Okay-
and
I
remember
one
more
thing:
we're
trying
to
decide
was-
should
how
a
reference
policy
api
looks
as
in
what
is
what
are
the
fields
that's
going
to
be
in
it,
and,
and
if
I
remember
correctly,
we
were
trying
to
decide.
A
So
let
me
let
me
pull
that
up.
I
was
writing.
D
B
Okay,
I
think
that
the
salient
question
was
again
like:
if,
if
we
always
require
there
to
be
a
br
in
the
namespace,
where
the
reference
policy
is,
then
the
reference
policy
could
just
prefer
the
br
by
name
in
the
same
namespace
or
you
could
have
it
referred
directly
to
the
bucket.
If
you
don't.
A
Okay,
so
that's
where
it
gets
weird
for
me
so
yeah.
I
remember
this
so
so
the
question
here
is
so
the
reference
policy
would
refer
to
the
br,
but
then
really
the
reference
policy
is
being
set
on
the
bucket,
like
you
know,
that's
what
you're
doing
right.
B
Yeah
yeah,
because
the
the
person
who
created
the
bar
in
the
other
name
space
has
no
idea
what
your
br
is
named
or
what
namespace
you
are
in.
They
just
know
that
there's
a
bucket
and
they
want
access
to
it,
and
you.
A
B
A
B
Well,
if
we
go
with
the
br
approach,
then
you
just
every
reference
policy
can
refer
to
one
or
more
brs
and
one
or
more
name
spaces
and
and
then
the
controller
that
implements
the
the
enforcement
of
of
these
rules
just
has
to
compute
the
union
of
all
of
all
the
policies.
A
Okay,
so
let
me
share
my
screen:
I'm
just
trying
to
understand
how
that
would
look.
So
so
you
know
this
is
the
reference
policy.
You
know,
we've
we've
been
kind
of
looking
at
so
far.
So
do
we
say
you
know
from
some
let's
say
bucket
is
greater
than
bob's
name
says:
bros
creating
bob's
namespace.
A
So
do
we
say
you
know
if
you
want
to
give
access
to
alice's
namespace,
we
just
say
group,
you
know
core
v1
and
kind
namespace
or
our
kind
bucket
request
and
namespace,
alice
and
and
two
would
be
not
to
the
bucket,
but
to
the
br
correct.
B
I
can't
remember
to
be
honest,
like
do
you
have
that
emac
stock
that
you
were
working
on
because
we
had,
I
mean
which
one
is
the
from
and
which
one
is
it
to
is
kind
of
debatable
like
just?
Does
the
name
space
have
access
to
the
bucket
or
does
the
bucket
give
access
to
the
name
space
like
the
from,
and
the
two
are
strange.
B
But
but
one
of
them
should
be
a
signifier
of
of
namespaces
and
the
other
one
should
be
a
signifier
of
buckets
whether
it
refers
to
the
bucket
request
or
the
bucket
directly
and
whether
the
namespace
just
refers
to
a
list
of
namespaces
or
whether
it
refers
to
bars
in
namespace
x.
You
know
you.
C
B
The
benefit
to
changing
it
to
bucket
request
is
it
lets
you
choose
the
name.
So
if
you're
doing,
if
you're
doing
a
configuration
as
code,
you
can
create
your
bucket
request
for
the
name
of
your
own
choosing
and
create
your
reference
policy
that
refers
to
the
bucket
request,
whose
name
you
chose
and
then
the
only
challenge
is,
of
course
getting
that
vr
bound
to
the
right
bucket.
B
But
but
I
guess,
if
an
admin
created
the
bucket,
then
he
also
controls
the
name
of
the
bucket.
I
don't
know
it's
a
it's
just
an
ergonomics
thing.
It
doesn't
really
affect
what
you
can
and
can't
do.
A
Well,
it
does
right,
I
mean,
like
you
said,
configuration
is
code,
you
wouldn't
be
able
to
upfront,
create
a
reference
policy
until
you
know
the
name
of
the
bucket
and
that's
not
okay,
I
think
well,
but
again.
B
B
You
don't
right
in
the
dynamic
case
you
don't,
but
in
the
dynamic
case.
Well,
let
me
think
how
this
would
work.
How
would
you
want
to
do
a
dynamic
like
provision
bucket
and
then
share
it?
You
just
create
an
ordinary
br,
let
it
bind
and
then
say
I'm
going
to
share
that
with
alice
by
creating
a
reference
policy.
A
B
A
Or
a
or
bucket
request
from
name
face
alice,
referring
to
a
bucket
what,
if
we
actually
and
then
the
name
of
the
resource,
maybe
you
know
I
was
gonna
say
that.
A
Oh
so
so
hold
on.
So
we're
saying
the
bar
will
directly
refer
to
the
br
in
the
other
namespace,
not
the
bucket.
A
What,
if
we
did
it
like
this,
where
reference
policy
actually
just
points
to
a
bucket,
but
we
drive
it
through
the
br.
B
A
No,
no,
the
problem
with
allowed
namespaces
was
the
problem
with
the
allowed
namespaces
was
we
just
couldn't
I'm
trying
to
fully
remember
it,
but
it
just
wasn't
an
approach
that
that
kind
of
fit
into
the
whole
kubernetes
ecosystem.
B
A
But
but
while
while
breaking
the
semantics
of
the
reference
policy,
because
you're
not
referring,
if
I
said
bucket
request
here,
right,
nobody's
gonna
refer
to
this
bucket
request,
are
they
well?
I
mean.
C
Sorry,
like
I
want
to
interrupt,
select
the
from
part
like.
Why
need
to
be
bucket
taxes?
Okay,
so
for
each
bucket
access
request,
I
need
to
put
a
preference
for
all
of
you
right.
No.
C
A
Yeah
yeah
yeah
same
question
so
so
again
he's
asking
the
same
thing
that
I
was,
which
is
the
reference
policy,
is
supposed
to
mean
the
reference
from
a
bucket
access
request
in
you
know,
namespace
alice
to
a
bucket
in
namespace.
You
know
created
by
namespace
bob,
except
we're
pointing
it
to
a
bucket
request
in
namespace
bob
and
that's
just
not
intuitive
like
it.
A
I
mean
we
can
define
it
to
be
this
way,
but
but
I
think
you
know
what
I
mean
right.
A
B
B
A
And
there
is
another
issue
here:
what,
if
I
I
feel
like
there's
a
race
condition
here.
A
Right,
because
if
you
were
to
do
that,
what
if
I
create
the
bar
in
alice's
namespace
before
bob
creates
the
bucket
and
someone
in
bob's
name
says
other
than
bob
goes
and
creates
a
fake
bucket
with
fake
data
to
mislead
alice.
Is
that
a
problem.
B
Well,
we
did
talk
briefly
last
week
about
what
is
the
behavior
when
the
bind
fails.
So
if,
if
the
controller
responsible
for
binding
mining
bars
sees
a
new
bar
and
it
goes
and
consults
the
rules
and
says
yeah,
there's
a
real
bucket
here,
but
you
don't
have
access
so
bind
fails.
Will
it
retry
30
seconds
later,
you
know
to
see
if
the
rules
have
changed
and
it's
no.
A
Point
forever:
no
I'm
saying
it'll
succeed,
it's
just
because,
because
I
anticipated
the
pr
name
to
be
something
else:
it's
possible
that
another
user
in
the
same
name
space,
can
take
up
that
slot.
A
It's
a
kind
of
binding.
If
you,
if
you
think
about
it
from
the
reference
policy,
makes
from
from
alice's
namespace
to
br
and
bob's
namespace,
I
mean
the
expectation
is
by
directly
referring
to
the
br.
The
expectation
is
I'm
expecting
a
br
by
this
name
to
exist
there
or
I'm
just
gonna,
wait
until
that
br
shows
up.
B
And
yeah,
but
I
mean
but
we're
binding
by
name.
So
if
someone
else
creates
a
different
thing
with
the
same
name,
then
it's
working
as
defined
it's
working
as
expected
right.
You
should
never
use
a
name
that
you
don't
have
control
over
it.
If
alice,
if
alice
chooses
a
name
to
bind
her
bar
to
the
bob,
doesn't
really
control,
then
then
that's
her
fault
for
using
that
name
or
that's,
that's
their
joint
fault
for
agreeing
on
a
name
that
they
that
they
didn't
control.
Yeah.
A
B
But
I
mean
that's:
users,
don't
really
share
name
spaces
or
if
they
do
like
they
have
to
cooperate,
and
it's
just
understood
that
if
they
don't
cooperate,
bad
things
happen
right.
I
mean
like
if
you
and
I
are
sharing
a
namespace
and
you
create
a
pod
and
I
delete
it.
You're
not
going
to
be
happy,
but
like
what
else
were
we?
What
else
did
you
expect.
A
So
you
know,
generally,
you
know
just
looking
at
how
enterprises
use
kubernetes
if
developers
do
get
access
to
it,
they
all
get
access
to
a
single
name
space
and,
and
these
things
you'd
be
surprised.
I
guess
that's
what
I
want
to
say
with
with
how,
with
how
badly
some
users
can.
B
Screw
things
up,
but
I
mean
how
can
that
be?
Our
problem
like
this
is
the
this
is
what
the
airbag
system
is
for
right.
The
rbac
system
is
to
put
rules
around
what
people
are
allowed
to
do
and
if
users
decide
to
just
give
everyone
the
power
to
delete
each
other's
stuff,
then
then
the
system
will
allow
you
to
delete.
You
know
everyone
else's
stuff
and
it's.
The
system
is
just
doing
what
you
told
it
to
do
fair
enough.
It's
not
it's
not
something
we
can.
We
can
architect,
or
you
know,
solve.
A
Okay,
fair
enough
all
right,
so
let's
figure
out
fine
lines
on
this
design,
then
of
this
api.
So
so
did
we
say
this
is
going
to
continue
being
a
list.
B
Because
because
nothing
prevents
you
from
having
multiple
policies
referred
to
the
same
bucket,
so
refer
to
multiple
buckets
and
multiple
namespaces
like
at
the
end
of
the
day.
The
controller
is
going
to
have
to
consider
every
reference
policy
in
the
namespace
and
and
sift
through
them
to
find
all
of
the
matches.
B
A
B
Mean
I
it
gives
people
more
flexibility
to
have
one
policy
that
has
a
lot
of
information
in
it.
So,
okay,
I
mean,
if
I
have
10
buckets,
I
want
to
share
with
10
namespaces
it's
nice
to
be
able
to
do
that
in
one
policy
rather
than
needing
100
policies.
A
B
Or
like
like
so
so
so
of
course,
bars
can
always
point
to
brs
in
the
local
name
space
right.
That
was
the
original
case
for
bars.
The
question
is:
if
you
want
to
create
a
bar
to
a
bucket
from
someone
else's
namespace,
do
you
point
to
the
bucket,
or
do
you
point
to
the
bar
or
the
br
in
the
other
namespace.
A
I'm
just
trying
to
think
if
there
are
any
other
issues
that
we're
missing
going
down
this
route,
because
we
we
we've
maintained
this
stance
of
the
b.
A
r
should
be
able
to
point
to
both
p
r
and
b
and
now
we're
saying.
B
A
D
B
A
Okay,
so
I
mean
I
don't
think
we
need
a
whole
object,
but
I
don't
think
that
that
conversation
we
should
have
right
now
self-service,
let's
figure
out
this.
I
mean.
Let's
agree
that
this
is.
This,
is
the
final
cross
for
namespace
resource
sharing
approach
and
then
we
can
go
there.
B
Well,
the
the
one
other
unresolved
question-
I
I
forget,
the
answer
was:
what
do
we
do
in
case
of
errors
like
when
do
we
retry
forever
and
then
or
do
we?
Is
it
a
one-shot
behavior?
Because
I
thought
we
were
we
were
talking
about
last
week
because,
like
it's
actually
very
hard
to
do
one-shot,
behaviors
in
kubernetes
yeah,
because
any
attempt
to
do
that
opens
you
up
to
failures
due
to
random
errors,
and
that's
really
unfriendly.
A
Until
until
either
of
those
become
true,
yeah
yeah,
that's
that's
pretty
straightforward.
A
Now
do
we
want
to
define
levels
of
access
like
do
we
want
to
say
something
like
from
alice's
namespace?
C
A
So
bars
are
for
the
bucket
access
classes.
So
if
an
admin
wanted
to
control
yeah
that
does
make
it
complicated,
I
mean
you
could
have
two
bacs
the.
B
B
Right
I
mean
if
you
wanted
to
really
be
able
to
say
I
want
to
share
bob.
You
know
bob
wants
to
share
this
bucket
with
alice,
but
only
read.
Only
if
alice
still
needs
the
ability
to
have
read,
write
buckets
for
other
purposes,
then
you
would
have
to
encode
the
bac
directly
into
this
reference
policy.
Somehow.
A
A
It
seems
to
fit
in
you
know
and
solve
many
of
the
problems
we've
been
facing
so
far.
It
seems
to
ease
up
the
complexity
of
self-service.
A
It
seems
like
it's
it's
it's
easier
to
solve
the
problems
that
we
were
facing
earlier,
which
tells
me
when
generally
something
like
this
happens.
It's
because
we
found
a
clean
abstraction
and
I
think
that's
what
we've
got
here.
A
B
A
So,
let's,
let's
quickly
go
over
how
they
do
it,
they
can
refer
to
or
they
can
create
routes
that
point
to
a
service,
as
in
you
know,
they
create
http
route.
That
says
forward
this
to
a
service
somewhere
else.
A
Okay,
so
think
of
it
as
there's
a
central
team
that
manages
routing
across
namespaces
so
or
across
different
properties
or
different
suburbs
in
your
company,
so
you
create
a
http
route.
Let's
say
you
have
a
global
load
balancer
for
your
company
and
you
say
if
you
know,
let's
say
yahoo.com
and
because
I
just
know
yahoo.com
a
little
better
like
kind
of
so
so
you
know
if
it's
yahoo
sports,
you
go
to
yahoo.com
sports.
A
If
it's
yahoo
movies,
you
go
to
yahoo.com
movies,
so
on
and
and
the
namespace
for
sports,
so
the
name
space
for
movies
isn't
going
to
manage
these
global
routes.
This
global
routing
has
to
be
done
from
a
centralized
steam
and
http
route
stands
for
that.
The
http
route
defines
that
for
this
global
route,
slash
bar,
it's
forwarded
to
the
namespace
bar
and
the
name
of
the
service
is
also
bar.
B
So
you're
saying
you're,
saying
if
I'm
in,
if
I'm
in
namespace
bar
all
I
do,
is
create
the
service
and
I'm
done
yeah.
And
then
this
is
going
to
front
end.
My
service
out
to
the
world.
B
B
C
C
So
I
have
like
I
have
on
top
in
this,
so
whether
this
means
all
the
loads
in
the
http.
All
the
http
looked
in
the
namespace
for
yeah.
D
C
A
So
what
was
so
your
question
is.
A
Okay-
okay,
okay,
so
yeah
here
the
name
is
unique.
Think
of
it
that
way:
okay,
yeah,
the
name
space
is
what
we're
referring
to
so
anyone
from
namespace
who
can
refer
to
any
service
in
namespace
bar
the
one
difference
yeah.
So
that's
what
this
before
I
go
into
the
difference,
that's
what
it
means.
A
So
so
any
http
route
from
namespace
4,
so
it
can
be
another
http
route
from
namespace,
for
it
can
be
like
xyz
or
http
route.
2.
C
B
A
Yeah,
so
it's
like
the
you
know,
I
look
at
it
as
like
push
versus
pull
kind
of
api
in
in
in
this
case,
in
case
of
http
route.
It's
like
it's
like
a
push.
It's
like
you're
saying
these
people
are
allowed
to
push
data
into
my
service
in
other
cases
like
a
pull
api.
It's
like
saying
these
people
are
allowed
to
pull
data
from
my
bucket.
A
B
B
You
have
the
same
question
about
when,
when
does
the
access
check
occur?
Is
it
just
at
creation
time
and
then,
after
that
you
can
delete
the
policy
and
access
remains
or
like
after
the
http
route
is
created
and
bound
to
my
service?
Can
I
then
delete
the
reference
policy
and
thereby
revoke
access
or
yeah.
B
A
That
we
said
that
that
matters,
because
we
wanted
to
yeah
that
we
said
that
that
would
be
okay,
because
we
said
we
said
we
can
you
know
if
you
really
wanted
to
take
access
away,
we
could
go
and
delete
the
vr
or
something
right.
B
You
didn't
want
to
delete
the
bar,
because
what
will
happen
is
the
moment
that
bar
is
allowed
to
bind
and
the
sidecar
goes
down
to
the
driver
and
says
me
a
credential,
and
then
they
go
plumb
that
credential
into
some
pod
somewhere.
At
that
point,
the
user
in
the
other
name,
space,
has
the
credential
and
it
doesn't
matter
what
you
do.
Unless
you
delete
the
actual
credential,
they
are
going
to
continue
to
have
access.
A
Yeah,
that's
different
from
http
route
right,
I'm
just
thinking
it
through
in
our
case
that
makes
sense,
and
that
should
be
fine
in
terms
in
terms
of
http
route.
If
I
wanted
to
change
the
route
say,
I
wanted
to
stop
having
bar
0.2
or
slash
bar
point
to
bar
service.
Instead,
I
wanted
to
have
slash
bar
point
to
you
know:
xyz
service.
A
B
A
B
There's
also
a
service
named
bar
and
a
reference
policy
name:
okay,
yeah,
that
that
is
bad
because
that's
super
confusing
yeah.
I
guess
I
guess
the
presumably
like
the
form
that
an
http
route
takes
is
there's
some
there's
some
demon
running
that
has
an
http
listener
and
it's
parsing
urls
and
then
opening
up
http,
client
sockets
to
other
http
services
and
acting
as
an
http
proxy,
presumably
yeah
and
and
the
thing
is
once
that
thing
is
told
what
to
do.
B
In
the
bar,
namespace
might
not
be
listening
anymore,
he
might
have
taken
the
service
away,
but
I
don't
see
how
it
could
stop
from
sending
them
there,
because
once
once,
the
once
the
demon
in
the
food
name
space
knows
where
to
send
the
requests.
You
can't
revoke
that
knowledge.
A
I
mean
it's
not
about
the
revoking
the
knowledge,
it's
more
about
changing
the
configuration.
D
B
A
A
That
is,
that
is
during
run
time
versus
during
buying
time,
we're
more
in
the
you
know
during
buying
time,
and
these
guys
might
need
to
be
in
the
run
time
where
the
reference
is
checked
constantly,
which
is
weird,
but
that's
one
difference
that
we're
seeing
the
other
is
it
the
reference
policies
they
have
here
allows
two
to
be
any
to
be
in
any
service
in
a
particular
name
space
or
in
the
in
the
name
switches
as
a
reference
policy.
In
our
case,
the
from.
A
Is
the
is
the
more
a
generic
one?
In
our
case,
it's
it's
from
bucket
access
request
in
namespace,
so
any
bucket
access
request
can
point
to
a
bucket
request
in
namespace
bob.
A
B
B
A
Want
to
stick
with
that,
so
the
reason
we
did
that
was
because
we
just
you
know
you
just
asked
the
question
of
how
will
a
controller
take
care
of
it?
If
you
know
our
reference
policy
changes
and
we
realize
that
we
need
a
different.
The
reference
policy
semantics
differ
between
different
implementations,
and
so
we,
instead
of
calling
it
a
reference
policy,
we
thought
we'd
call
it
a
bucket
reference
policy
just
to
make
sure
that
we
don't
start.
B
B
But
if
we're,
if
we're
going
to
reuse
their
object,
then
then
yeah
we
have
to
fill
out
these
other
fields
and-
and
we
have
to,
we
have
to
describe
what
happens
if
you
put
garbage
in
here,
because
you
know,
given
that
they're
lists,
you
have
a
mixture
of
bars
and
other
stuff
in
the
from
list
and
a
mixture
of
brs
and
other
stuff
in
the
to
list,
and
we
have
to
specify
that
we
ignore
anything.
That's
not
a
bar
in
the
from
list
and
not
a
br
on
the
two
list
or
something.
A
B
B
B
B
A
B
I
like
the
uuid
idea,
because
then,
if
you
have
have
an
object
with
a
specific
name
and
it
gets
a
uuid,
you
can
grant
access
to
that
one
and
then,
if
they
delete
that
object
and
create
a
new
one
with
the
same
name,
it
won't
have
access
because
you
granted
access
by
you
id.
I
guess
you
just
need
to
be
clear
that
if,
if
you
omit
these
fields,
it's
like
a
wild
card.
A
So
the
reason
I
did
that
is
to
allow
the
kind
of
semantics
that
they
have
here.
I
can
see
this
becoming
a
thing
where
they
say
any
any
service,
or
you
know
some
service
from
well
actually
to
allow
this
to
happen
and
our
thing
to
happen.
You
know,
I
think
we
need.
We
need
to
specify
the
names
precisely
that
is
in
in
in
case
of
buckets
it's
the
two
field
that
specifically
refers
to
a
resource
in
case
of
a
gateway
api.
It's
the
from
field
that
specifically
chooses.
A
A
resource
in
this
case
anything
from
namespace
anything
any
http
route
from
namespace
who
can
point
to
a
service.
It's
just.
If
you're
doing
the
generic
reference
policy,
I
can
anticipate
use
cases
where
the
from
field
specifically
points
to
a
particular
resource,
and
that's
where
I'm
coming
from.
You
know
adding
this
name
here
and
give
you
80.
B
The
other
thing
that,
as
we
think
about
this,
and
as
we
think
about
sharing
the
object,
I'm
starting
to
worry
that
someone's
going
to
wonder
about
the
kind
of
access
at
some
point,
because,
depending
on
how
generic
this
object
is,
it
could
be
used
for
all
all
kinds
of
weird
things.
And
we
mean
a
specific
thing
by.
B
You
know
reference
policy
in
our
context
but
like
if,
if
reference
policies
could
end
up
using
you
get
it
end
up
getting
used
for
some
other
purpose
that
accidentally
overlaps
with
our
purpose
and-
and
you
don't
have
a
kind
of
access
specified
anywhere.
Like
our
controller,
could
just
see
those
reference
policies
and
say:
oh,
I
guess
I
better
give
access
to
to
these
buckets
to
this
person.
B
Like
you
know,
if
we
treat
any
blank
field
as
a
wild
card
and
someone
creates
a
reference
policy
that
says
everything
in
namespace
alice
has
access
to
everything
in
my
namespace
and
the
person
who
created
that
policy
wasn't
thinking
about
cozy
because
they
were
thinking
about
some
entirely
different
use
case
involving
reference
policies.
And
then
we
ship
our
controller.
That
goes
and
sees
that
reference
policy
and
says:
oh,
I
guess
I'd
better,
give
alice
access
to
all
bob's
buckets.
B
B
A
Think
about
different
ways:
we
could
solve
that,
but
none
of
them
seem
like
the
clean
like,
for
instance,
you
could.
You
could
have
like
a
downstream
reference
limiter
or
something
it's
just
saying.
If
you
refer
to
this
bucket,
you
can
only
refer
to
these
bucket
access
classes.
A
B
B
A
A
Constrained
by
it
I'm
more
coming
from
the
idea
of
is
that
okay,
I
mean
like
okay,
fair
enough.
It's
a
brand
new
object.
We
can.
We
can
go
down
that
road,
so
you're
saying
there
might
be
a
good
reason
to
love
wildcard
group
wildcard
everything
really
yeah.
B
B
And
then
we
can
have
a
field
that
says
that
that
the
reference
policy
is
granting
cosy
bucket
access.
You
could
be
like
an
enum
type
for
what
kind
of
reference
policy
is
this,
so
that
the
machinery
of
the
reference
policy
might
be
in
common,
but
the?
What
do
you?
What
is
this
reference
policy
trying
to
express
could
be
a
an
explicit
field?
D
B
On
how
this
gets
shared
in
the
future,
that
that
could
be
a
concern,
yeah
reference
type
reference.
B
You
know
what
I
mean
it
would
be.
There
would
be
some
magic
value
that
would
be
recognized
by
our
controller
and
we
would
ignore
ones
that
didn't
have
that
value
that
that
way
in
case
someone
did
have
a
use
case
that
involved
wildcarding
everything.
We
wouldn't
just
pick
up
that
reference
policy
and
try
to
interpret
it.
A
No,
this
is
fair
interesting.
So
so
something
like
that,
because
if
it's
the
http
route
reference
you
you
might
say
in
properties
or
some
I
don't
know
like
you
know
we
can.
I
I
don't
want
to
make
it
like
super
complicated.
I
just
want
no,
I'm
just
trying
to
make
sure
there
is
a
path
forward.
A
If,
if
this
does
come
up
because
I
can
see
it
coming
up
even
for
buckets
like
we,
we
want
to
define
what
kind
of
access
is
allowed
in
this
case,
and
you
know,
reference
type
could
couldn't
have
some
properties
encoded
in
it.
That
said,
they
could
be
typed
right
now,
let's
just
go
with
the
string
string,
but
you
could
have
properties
and
and
code
in
it.
That
say,
the
kind
of
references
allowed
here
is
read
only
or
something
like
that.
D
About
that
I
will
stop
the
recording,
so
so
I
do
want
to
ask
you
something
so
about
the
the
pr
I
know
the
the
cap
review,
so
you
can
easily
pin
the
team
right
and
then
whatever
that
is
in
the
cap
right
now,
that's
up
to
date.
D
D
D
A
D
D
A
D
Okay,
I
can
try
to
ping
him.
Okay,.