►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 11 March 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
It
will
be
a
very
informal
one,
it's
mainly
for
developers
either
developers
are
writing
the
driver
for
their
organization
or
developers
who
are
writing
cozy
code
itself,
that
that
want
to
understand
any
parts
of
the
architecture
or
how
to
go
ahead
with
the
feature
and
for
developers
or
writing
applications.
A
What
do
you
all
think
one
about
this
timing?
That's
one
of
them
and
two
is
just
you
know
the
concept
of
office
hours
as
a
whole.
B
A
Well,
it's
a
it's
a
open,
zoo
meetings.
How
is
thinking
of
it?
And
there
are
some
people
who
already
signed
up.
I.
B
B
B
A
B
A
Yeah,
so
you
know
there
are
some
people
like
janus
is
joining
from
ireland.
He's
not
able
to
be
at
the
meetings
and
and
9
a.m
is
the
one
time
that
works
for
him.
That's
also,
you
know
possible
for
us,
so
so,
and
you
know
nicholas
just
said:
it's
7
p.m
there.
A
D
In
general,
I
think
we
should
first
have
a
channel
that
allows
for
or
is
more
actively
used
for
kind
of
asynchronous
communication,
because
that
is
the
easiest
way
to
basically
reach
everyone
around
the
globe,
no
matter
which
time
zone
they
are
in
and
only
have
because
we
already
have
two
calls
a
week
only,
even
though
those
are
not
necessarily
for
the
the
the
target
audience
you
just
described
it
still,
and
and
only
add
that
when
there
is
like
a
concrete
need.
A
Yeah
yeah,
that's
that's
so
I
would
go
about
it
too,
so
we
already
have
a
slack
channel.
A
Even
with
that,
I
think
the
project
is
really
early,
but
we
have
interest
coming
in
from
different
vendors,
I'm
just
looking
at
it
as
a
way
to
enable
them.
Maybe
we
could
do
it
like
this?
We
could
try
it
for
a
few
weeks
and
and
then
you
know,
participation,
I
I
don't
expect
everyone
to
be
there,
it's
more
like
it's
really
for
people
who
are
writing
code
and
and
if
really
nobody's,
participating,
it'll
it'll,
slowly
taper
out
by
itself.
B
Though,
right
like
this,
is
the
slack
channel
aimed
at
like
developers
in
the
sense
of
people
who
want
to
write
drivers,
not
people
who
want
to
contribute
to
the
cozy
project.
B
Okay,
well,
that
seems
like
an
argument
to
say:
hey
like
please
bring
your
questions
to
the
slack
channel,
we'll
try
to
answer
them
asynchronously
within
24
hours
and
then
and
and
make
it.
Of
course,
we'd
have
to
make
an
effort
to
look
for
those
questions
in
the
channel
and
not
miss
them.
But
then,
if
someone
like
needed
a
more
high
bandwidth
discussion
on
a
topic
like
scheduling
a
one-off
at
a
time,
that's
convenient
for
everyone
involved
might
be
a
way
to
reach
more
time
zones.
Well,.
A
That's
what
I've
been
doing
for
the
past
few
weeks
and
it
hasn't
been
good
enough.
It's
just
the
number
of
you
know
calls
I'm
doing
are
increasing.
A
E
Repeating
the
same
thing
to
different
developers:
okay,
well
so
it
sounds
like
we
need
some
documentation
for
startup
on
a
developer.
Here's
how
you
get
started,
and
I
know
we
probably
have
some
right
now,
but
maybe
it
needs
to
be
improved.
E
F
G
Hey
I
let's
go,
I
wanted
to
suggest,
maybe
maybe
making
some
you
know.
Videos
will
help
as
well.
I
think
people
are.
G
Nothing
we
discuss
is
really,
you
know,
zero
time
right
and
anything
will
take
some
time
so.
H
One
of
the
things
that
we
do
is
make
sure
to
record
these
meetings
and
put
them
on
youtube
and
part
of
the
reason
for
that
is
so
that
people
can
asynchronously
consume.
The
content
is
that
insufficient
are
people.
G
D
G
From
my
experience
I
did
it,
but
I
I
was
involved
and-
and
I
was
in
the
call,
so
I'm
it's
much
more.
You
know
relevant,
but
I
would
imagine
that
somebody
who
who's
never
been
on
on
the
calls-
and
it's
you
know
just
starting
off
with
having
questions.
It's
not
really
a
consumable
format
for
watching.
B
Yeah
I
mean
we
generate
two
two
hours
a
week
of
these
videos
yeah
and
that
that's
a
huge
amount
of
stuff
to
catch
up
on
if
you're
not.
H
Worried
about
is,
if
we're
having
you
know,
the
the
one
of
the
problems
is
having
sid
scale
said
cerini
and
the
core
folks,
and
so,
if
we're
saying
create
more
videos,
that's
not
going
to
help
us
just
maybe
maybe.
I
B
A
A
Like
that
idea,
too
sid
all
right-
let's,
let's
do
that-
I
still
have
to
figure
out
a
way
to
communicate
with
the
folks
in
ireland
because
for
them
it's
too
late
to
join
the
11a
meeting
on
monday,
or
even
this
10am
meeting
here
on
thursdays
yeah,
maybe,
like
you
said,
we'll,
take
a
recording
of
those
officer
meetings
from
those
alternate
mondays
and
share
it
with
them.
A
Last
week
we
were
talking
about
api
review
and
one
of
the
concerns
that
or
one
of
the
design
proposals
that
we
didn't
have
enough
time
to
finish
talking
about
was
what
jeff
brought
up
so
jeff.
Do
you
wanna
share
your
screen
and
talk
about
it
or
how
do
you
wanna
go
about
it.
E
E
E
Let
me
know
if
you
can
hear
me
and
if
you
can
see
my
screen
here,
that
sh
it's
a
diagram
yeah,
you
can
see
it
you
guys.
Sometimes
I
get
an
echo
okay.
Well,
so
you
know
sid,
and
some
of
us
have
been
talking
about
you
know,
maybe
there's
a
tweak
we
could
make
to
the
api.
That
would
be
good
to
do
sooner
rather
than
later.
Motivation,
for
me
personally,
at
least,
was
not
liking
the
cloning
of
bees
in
brownfield
and
maybe
down
the
road.
It's
automated
cloning.
E
Somehow,
but
at
least
initially
it's
a
manual
cloning
done
by
the
admin
for
every
brownfield
and
the
other
part
I
don't
like
about
the
brownfield
has
been
the
a
bucket
request
is
needed
and
a
bar,
but
all
you
really
want
to
do
is
access
the
bucket.
Why
do
you
need
two
of
these
resources?
E
The
third
thing
that
I'm
not
you
know
happy
about
is
the
abstraction
in
our
current
design
and
that
we
have
multiple
buckets
instances
representing
a
single
back
end
bucket
physical
bucket.
So
these
were
thoughts
that
have
been
percolated
in
my
head
for
quite
a
while,
and
I
got
some
time
and
and
drew
this
diagram
that
you
see
the
the
left
side
of
this
diagram
is
exactly
what
we
have
now
you
can.
E
You
can
share
a
bucket
within
a
namespace
bars
reference,
a
common
br
all
in
the
same
name,
space
that
br
references
a
back
end,
a
bucket
abstraction
which
references
or
abstracts
a
backend
bucket,
and
and
that's
what
we
have
today.
So
the
new
design
doesn't
change
sharing
within
a
namespace,
but
where
it
differs,
is
sharing
across
namespaces.
E
Our
current
design
involves
the
cloning
of
the
b
as
you're
familiar
with,
and
to
share
a
bucket
across
name
spaces.
You
need
the
br
pointing
to
that
b.
So
you
have
to
figure
out
the
name
of
the
b.
You
have
a
create
a
br
that
points
to
the
b.
Then
you
create
a
b,
a
r
that
points
to
your
br,
and
now
you
can
share
across
name
spaces.
That's
today,
so
this
per
this
idea
here
is
that
is
to
make
that
simpler
and
so
in
namespace
2.
E
We
want
to
access
the
same
bucket
that
had
been
created
out
of
the
namespace
1br
and
and
all
we
do
is
create
a
bar.
We
just
want
access,
so
we
we
don't
need
a
br.
We
just
create
a
b,
a
r,
and
it
points
to
the
bucket
the
same
bucket.
That
br1
has
been
linked
to
and
a
ba
is
created,
ba3
in
this
diagram
and
and
that's
it
and
so
they're
still
just
a
single
bucket
instance
in
in
consideration
of
design,
ben
and
some
others
are
brought
up.
E
You
know
the
deletion
workflow.
What
happens
if
you
delete
name
space,
one,
for
instance,
what
happens
to
the
to
the
bucket
bar
3
might
still
exist.
A
workload
might
exist,
but
you've
deleted
br1.
So
you
know,
we've
discussed
these
workflows
and
we
we
believe
we
have
solutions
which
I
can
go
into
or
sid
can
another.
Another
criticism
or
comment
has
been
that
this
is
not
symmetric.
E
The
current
design,
it's
very
neat
and
tidy.
You
have
a
br,
a
b,
a
r,
a
b
a
and
a
b
and
they're
all
present
for
every
access,
and
so
you
have
the
symmetry
and
this
design
in
namespace
2.
You
can
see
it
doesn't
look
like
namespace
one,
so
it's
potentially
more
confusing
up
front.
E
I
I
don't
know
how
many
people
agree
with
that,
but
I
I
want
to
get
that
out
there
that
that
has
been
mentioned
and
I'm
just
going
to
follow
up
and
just
show
you
what
in
in
our
view,
or
at
least
my
view
are
some
benefits
of
this
approach.
I
wrote
easier
for
the
user.
I
should
have
also
said
easier
for
the
admin
and
that
you're,
not
cloning
b's.
E
Maybe
I
say
that
I
haven't
looked
at
this
for
a
little
bit
anyway.
I
guess
you
can
ignore
mutations.
I
think
those
are
going
to
be
fairly
limited
initially,
but
if
you
think
about
mutations
down
the
road
and
you're
going
to
mutate
a
b,
you
know
which
one
do
you
mute.
Mutate
we've
talked
about
having
the
concept
of
the
original
b
and
the
clone
bees
through
an
annotation
or
something.
E
But
mutations
seem
a
little
ugly
when
you
have
multiple
b's
out
there
for
the
same
back
end
bucket,
and
how
do
you
keep
them
in
sync?
Do
you
keep
them
in
sync?
Do
you
not
worry
about
that?
A
single
b
makes
mutation.
If,
if
once
we
get
there,
I
think
much
more
intuitive
anyway.
That's
it
in
a
nutshell,
sid,
and
I
can
take
any
questions.
A
When
we
spoke
last
time-
or
you
know
a
better
way,
to
put
it,
I
would
say
the
user
experience
is
going
to
be
different.
If
it's
greenfield
versus
brownfield,
where
in
greenfield,
they
can
just
point
their
application
to
point
to
bar
well,
no,
they
would.
They
would
point
their
bar
to
point
to
the
br
and
in
case
of
brown
field
they
would
point
their
br
to
the
b
right.
E
A
E
E
B
B
I
guess
so.
If,
if
if
it
was
the
very
first
app
to
point
to
a
given
brownfield
bucket,
we
would
still
create
the
br
or
we
could
you
just
have
no
brs
and
just
create
the
bucket
and
the
bar
and
start
using
it.
What
would
you
do.
B
Yeah
yeah,
I'm
realizing
that
you
know
for
a
brownfield
use
case.
You
actually
need
zero.
Brs
right,
you
have
the
admin
create
the
bucket,
because
it's
a
non-namespace
object
and
he
has
to
do
it
to
point
to
the
real
bucket
or
some
controller,
acting
on
the
admins
behalf,
and
at
that
point
you
start
creating
bars
and
pods
and
there
is
no
br
and
it
would
work
yeah
and
is
that.
Is
that
what
we
would
desire
to
to
support
a
use
case
where
there's
no
brs
there's
just.
E
Well,
brown,
so
brs
are
for
creating
a
bucket.
It's
a
request
for
a
new
bucket
right
and
it
influences
a
bucket
class
and
bucket
class
gives
you
some
more
information
about
what
the
bucket
it
should
look
like
and
who
the
driver
is
and
so
forth
and
access.
You
know,
I
don't
need
any
of
that.
I
mean
I
just
want
access
to
the
bucket
and
I
go
through
a
bucket
access
class.
E
Of
course
that's
still
the
classes
aren't
drawn
in
here,
but
they
still
exist
and
that
that
defines
some
properties
of
my
access
and
allowed
name
space
bill
exists
in
the
b
that
that's
not
removed.
So
I
still
have
to
pass
that
criteria
and
yeah.
I
think
ben
you
don't
need
any
bars
in
a
full
brown
field.
B
B
E
A
B
Bbc
in
yeah
like
if
the
bucket,
if
you
guessed
the
name
of
a
bucket
that
was
in
use,
you
would
fail
to
bind
to
it.
Somebody
would
have
to
create
a
new
bucket
in
order
for
your
br
to
bind
to
it,
which
means
an
admin
would
definitely
be
involved
in
the
creation
of
your
or
importation
of
your
of
the
bucket
into
your
namespace.
B
Now
we
have
a
self-service
way
to
just
obtain
access
to
a
bucket
with
no
admin
helping
you
so
it
the
security
mechanism
matters
more
if,
if
we're
circumventing
any
admin
access,
because
it
so
so,
where
I
want
to
get
to,
is
the
allowed
namespaces
scheme
works?
If
you
trust
it,
but
like
can
you
change
the
list
of
allowed
namespaces
and
is
it
who
can
change
it?
And
how
do
you
change
it
like?
B
I,
I'm
starting
to
think
of
you
know
if
you
really
have
a
shared
bucket
and
you
don't
want
to
just
open
it
up
to
the
whole
cluster
like
managing
the
list
of
loud
name
faces
could
become
a
hassle,
interesting.
B
E
F
A
About
this,
so
you
know
in
amazon
the
way
iam
works.
Is
you
choose
a
set
of
nodes
which
have
an
iem
policy
set
on
them
and
on
those
nodes
based
on
the
policy
you
can
access
amazon
resources?
Could
we
do
something
similar
here
with
namespaces
and
pods?
A
E
E
Well,
isn't
there
still
an
extra
layer,
the
bar
still
references
a
bucket
access
class
and
the
bucket
access
class
has
a
pointer
to
config
map
right
we're
still
doing
it
that
way,
policy.
E
Action
configman
and
then
that
that
data
is
inserted
into
the
ba.
So
if
I'm
trying
to
get
access
to
a
bucket
that
I'm
not
supposed
to
have
access
to
and
I
get
and
I
guess
the
name
of
the
b.
So
I
know
that
now
and
I
I
know
the
name
of
the
bac
to
use.
E
A
The
concept
of
allowed
namespaces
is
not
it's
more
like
an
acl,
but
not
really
an
acl
even
and
and
acls
are
being
phased
out
even
by
amazon.
I
would
like
a
more
fine-grained
approach,
but
we
can't
do
per
bucket
access
control
using
just
our
back,
so
you
know
we
need.
We
need
something
better.
I
think
is
that
what
you're
trying
to
say
ben.
B
E
B
E
B
Okay,
I'm
just
trying
to
think
so.
So
some
people
won't
care
about
this.
Some
people
implicitly
trust
everyone
in
the
cluster
and
they're
just
going
to
want
to
do
the
easy
thing
which
is
don't
control
access
and
so
like
that's
fine,
because
they
don't
care
about
security.
For
someone
who
did
care
about
security
yeah
they
would
they
probably
on
a
one
by
one
basis,
add
the
name
spaces
that
they
that
they
wanted
to
have
access
to,
and
that
would
just
become
part
of
the
workflow
involved,
with
exposing
a
bucket
to
a
new
namespace
as
well.
B
You
have
to
first
you
go
edit,
the
b
to
add
the
the
namespace.
Then
you
give
him
the
name
of
the
b,
so
he
can
create
his
bar
and
then
you're
done,
and
he
can
do
the
rest
himself
and
then,
when
you
want
to
decommission
it
you
I
don't
know
what
you
do.
Can
you
can
you
remove
the
name
space
when
a
bar
already
is
bound
to
it
like?
Can
you
reverse
that
process
to
revoke
access,
yeah.
A
A
No
we've
already
talked
about
this,
because
working
access
is
simply
just
either
either
invalidating
the
credentials
or
just
pulling
the
yeah.
It's
invalidating
the
credentials
and
revoke
access
is
a
defined
call
in
our
grpc.
B
Right
but
like
what
the
admin
is
going
to
do
is
he's
going
to
cube
cuddle
edit
bucket.
You
know
mybucket,
and
this
delete
a
line
from
the
list
of
allowed
namespaces
right
and
so
some
controller
will
see
the
bucket
changed.
The
name
spaces
got
smaller
and
have
to
do
something.
What
will
it
do?
Will
it
go
find
all
of
the
bars
in
the
name,
space
that
just
got
removed
and
like
changed
them
somehow
or
so?
There's
always
going
to
be
a
reference.
A
From
the
b
to
the
bar,
because
the
bucket
needs
to
know
who
are
all
accessing
it
when
it
needs
to,
you
know,
go
away,
it
needs
to
delete
them
or
wait
for
them
to
finish
running
so
the
list
of
references
is
going
to
be
there.
A
Yes,
so
so
ben
again,
are
we
really
making
it
more
insecure?
Simply
because
it's
you
know,
admin
is
not
involved
in
this.
No.
B
B
Like
like
the
anytime,
you
create
a
self-service
model
instead
of
a
an
a
and
an
admin
controlled
model
like
you
know,
it
becomes
easier
to
to
perform
attacks
right
like
that's.
That
should
be
obvious
this,
and
so
so
in
the
old
model.
The
security
mechanism
didn't
matter
as
much
because
you
could
always
fall
back
to
well.
The
admin
just
didn't
give
him
access.
B
If
it's
self-service,
then
the
security
mechanism
matters
more,
but
I,
but
more
than
that,
I'm
just
worried
about
the.
What?
What
are
people
going
to
do
on
a
day-to-day
basis
here
and-
and
I
just
wanted
to
think
through
the-
how
do
you
expand
access
and
how
do
you
contract
access
so
that
the
expansion
doesn't
sound
too
bad
right,
adam's
still
involved?
You
want
that
yeah
yeah.
B
Careful
in
that
anyone
who
has
right
access
to
buckets
implicitly
can
perform
this
this
security
operation,
which
means
that
any
controller
that
mutates
buckets
also
has
a
security
function,
sort
of
implicitly
included
in
it,
or
or
at
least
an
attacker
who
can
attack.
That
controller
can
also
attack
your
security
mechanism.
A
Yeah
yeah
yeah.
We
need
a
way
to
contract
access
like
ben,
saying
and
also
expand
for
namespaces
that
haven't
been
created
yet
and
also
with
the
current
model.
We
can't
restrict
it
within
a
namespace,
so
for
say,
for
instance,
some
apps
are
allowed
to
get
access
to
the
bucket,
but
not
others.
We
couldn't
do
that
right
now.
B
Okay,
so
I
mean
overall,
I
like
this-
I
I
feel
like
you
just
need
some
soap
time,
because
it's
a
new
new
idea
and
in
the
past
we
haven't
realized
the
problems
with
our
new
ideas
for
a
couple
of
weeks
right
right.
But
I
have
a
good
feeling
about
this
and
I
agree
with
everything
you
said
jeff
about
the
grossness
of
the
existing
proposal
and
and
how
this
feels
like
an
improvement
to
that.
B
E
Then
I
I
I
like
the
observations
I
hadn't
made,
the
connection
that
there
this
was
getting
us
a
little
closer
to
a
self-service
model.
I
I
see
that
as
a
plus
but
you're
right,
then
the
the
then
the
next
obvious
thing
is.
You
have
to
make
sure
that
there's
security
in
a
self-service
month,
the
users
can't
you
know,
do
things
they're
not
allowed
to
do.
I
agree
with
your
content
allowed
namespaces.
E
It's
just.
We
haven't
really
come
up
with
anything
better
yet,
but
it's
always
been
a
little
bit
of
a
area
I
was
uncomfortable
with
mainly
because
I
don't
see
it
in
other
kubernetes.
I
don't
see
it
used.
Yeah.
B
B
E
E
We're
talking
about
a
loud
name
spaces,
this
list
of
namespaces
that
are
allowed
to
do
something
right
allowed
to
create
a
br
or
or
bar
and
ben,
is
saying
it's
he's
felt.
It
feels
a
little
uncomfortable
with
that
concept.
I
I
agree
with
him.
I
do
too,
and
my
reason
is
because
I
don't
see
it
anywhere
else
in
kubernetes
and
ben
said.
E
Well,
maybe
that's
because
it's
been
thought
of
but
rejected,
and
then
I
asked
you
sod
if,
if
you're
aware
of
examples
where
this
idea
has
been
where
where
a
list
of
namespaces
has
been
used
as
some
sort
of
security
mechanism
and
has
been
rejected,.
H
I
I
thought
that
gateway
api
thing
actually
has
something
like
that.
Does
that
allow
namespaces
I
can
check,
but
it's
it's
different
like
this
model,
you
the
breath,
run,
field
and
greenville.
This
is
very
different
right,
for
I
think
the
gateway
model.
You
always
have
like
two
objects.
I
D
Should
we
be
focusing
on
namespaces
here,
rather
than
what
a
particular
user
service
account
a
entity
can
do,
in
which
case
something
like
the
what's
used
in
the
port
security?
What
is
again,
port
security
policy
could
be
used
where
you
look
at
rbac
stuff.
B
Well,
I
think
the
namespace
is
the
right
granularity
for
control,
because
once
you
have
once
the
object
is
in
a
namespace
any
pod
in
that
namespace
can
bind
to
it,
and
so
the
namespace
is
sort
of
the
natural
security
boundary.
What
our
back
does
is
it.
It
says
what
actions
can
be
performed
on
what
types
of
objects
not
like
exactly
which
objects
do
you
have
access
to
right?
G
G
G
I
have
a
rest
api
and
some
namespace
anybody
can
curl
that
right,
it's
just
a
service
in
the
cluster,
but
but
authenticating
to
that.
How
do
I
self-serve
that
namespace
to
authenticate
like
from
other
names?
Should
I
choose
a
specific
namespace
and
give
access
to
a
secret?
What
do
I
do?
I
ask
somebody
to
copy
a
secret
to
another
namespace.
A
A
K
An
example,
let
me
just
consider
a
bucket
as
a
so
generally
when
we
define
a
row,
we
specify
a
resource
like,
for
instance,
pods
or
whatever,
but
you
can.
We
can
also
specify
sub-objects,
so
we
could,
for
instance,
close
the
access
and
bucket
slash
foo,
foo,
being
the
name
of
the
bucket,
for
instance,
and
then
we
would
use
verbs
like
interesting.
K
B
I
A
D
Oh,
but
here
resource
names,
my
config
map,
oh
so
rbc.
B
K
B
D
B
B
A
Yeah,
okay,
so
shane,
could
you
maybe
share
a
link
to
the
the
gateway
documentation
or
something
that
that
I
can
project
here.
B
E
Here,
medium
spaces,
I
can
add
a
link
in
storage
cozy
to
that
document.
If
you
guys
want
to
look
at
it,
you
know
close
up.
A
D
I
I
wanted
to
bring
up
the
selector
as
well,
when
ben
mentioned
what
happens
when
new
namespaces
are
edited,
etc.
Something
that
this
relates
to
is
an
email
that
went
on
kate's
devil
a
while
ago
about
how.
I
think
it
was
the
gateway
guys
who
asked
for
the
name
of
a
namespace
to
automatically
become
a
well-known
label
on
the
namespace
object,
except
exactly
for
this
use
case.
A
B
E
B
A
Yeah,
this
is
good
thanks
for
sharing
this
shane.
I
have
another
question:
how
do
we
revoke
access
from
namespaces
now.
B
Well,
you
would
in
this
model
you
would
probably
edit
the
label
of
the
namespace,
so
they
no
longer
match
the
selector
or
or
you
would
change
the
selector
in
some
way
so
that
it
didn't
match
anymore.
So
some
controller
would
have
to
be
keeping
track
of
for
any
given
bucket,
which
namespaces
are
supposed
to
have
access,
and
then,
when
something
changed
such
that
a
namespace
should
no
longer
have
access
you'd
have
to
change.
I
don't
know,
go
edit.
The
ba
or.
A
B
Well,
yeah,
I
guess
we'd
have
to
decide
like.
Would
the
revocation
of
access
affect
existing
pods
that
are
that
are
attached,
or
would
it
only
affect
new
pods
that
are
trying
to
attach
the
latter
is
easier
because
then
you
can
perform
all
of
your
checks
at
attach
time
and
say
you
know:
does
everything
match
up
and
if
not
deny
it,
but
if
so
allow
it?
B
And
then
you
can
just
ignore
situations
where
you've
revoked
access,
but
a
pod
is
still
using
it,
although
that
now
that
I
say
it
out
loud,
it
feels
weird
because
you
feel
like
you
need
a
way
to
sort
of
force
revoke
access
when
you
really
want
to
yeah.
B
D
B
D
D
B
I
I'm
presuming
an
admin,
would
make
this
decision.
He'd
say
I
want
to
revoke
access
on
this
namespace
to
this
bucket
and
after
I
do
that
I'm
going
to
go,
find
all
the
pods
in
the
namespace
and
kill
them,
because
I'm
the
admin
and
I
I'm
I
wanted
to
provoke
the
access
right
like
you're
right.
You
wouldn't
want
to
automate
that
too
much
you'd
want
a
human
in
the
loop,
because
there
could
be
a
used
case
where
it's
appropriate
to
leave
the
pods
alive,
but
a
human
could
make
that
decision.
D
B
B
Yeah
well,
but
but
but
then,
what
he
is
saying
is
something
needs
to
go
process,
those
those
those
key
revocations
or
access
key
revocations
synchronously
at
at
access,
revocation
time
so
that
it
propagates
to
the
pod
and
the
pod
doesn't
retain
access.
But
shouldn't
that
happen
when
the
va
gets
deleted.
B
B
A
I
mean
like
just
like:
we
have
those
two
options
in
teams
or
calculations
where
you
have
no
schedule
and
no
execute.
If,
if
it's
that
no
execute
kind
of
deletion,
then
you
know
existing
parts
that
use
the
buckets,
don't
have
access
anymore.
If
it's
the
no
schedule,
then
only
new
parts
that
have
access
don't
get
access
anymore.
E
B
Yeah,
so
that
was
my
that
was
my
opening
bid
and
then
and
then
you
could
say
well
if,
if
as
the
admin,
you
not
only
wanted
to
do
revoke
the
access,
but
you
also
or
you
not
only
wanted
to
prevent
new
pods
from
accessing
it.
But
you
wanted
existing
pods
to
lose
access
to
it.
Then
you
could
instruct
the
admin
go,
delete
the
relevant
bas
and
then
those
pods
will
lose
access
and
leave
it
as
an
exercise
to
the
admin
to
figure
out
which
bas
he
wants
to
delete
and
how.
B
That
in
the
resource,
what
do
you
mean?
It's
not
our
problem.
If,
if
we
just
say
look
the
the
allowed,
namespaces
is
processed
that
attach
time,
and
if
you
want
to
force
detach
it,
you
got
to
go,
find
the
ba
and
delete
it.
And
it's
not
our
problem.
B
A
A
It
sounds
fine
like
we're
not
really
restricting
them
too
much,
and,
and
you
know,
forced
revocation
is
an
extreme
step.
So
having
it
be
manual
is
good.
B
But
that
that
that's
the
opposite
of
what
jeff
was
saying
with
like
a
no
schedule
or
no
execute
we're
basically
saying
we're
not
implementing
that
we're
just
implementing
the
no
schedule.
B
Well,
no
executives
where
you
you,
you
know,
instead
of
if
you
were
to
do
it
automatically.
That
becomes
no
execute
right
right,
and
so
so
we're
saying
look,
let's
not
do
that,
because
it's
harder,
yeah,
yeah.
B
A
A
If
someone
wants
to
take
that
extreme
step
of
revoking
credentials,
then
the
admin
would
have
to
do
it
manually.
We
won't
do
it.
We
only
do
it
during
attach
time,
like
you
said,
I
think
that's
that's
fair
enough,
because
the
the
risk
of
the
risk
of
doing
it
automatically
means
one.
A
A
And
and
the
other
is
I
don't
know
how
we're
gonna
represent
that
in
the
in
the
api
object,
saying
if
I
remove
this
namespace
or
this
selector
from
this
namespace,
then
buckets
are
deleted,
but
from
another
namespace
sorry,
the
bucket
access
are
deleted
and
another
namespace
they're.
Not.
How
would
you
represent
that.
A
A
Because
that
policy
applies
when
we
are
taking
access
away
from
a
name
space
or
taking
a
selector
out
of
a
namespace.
B
So
yeah,
just
a
simple
thing
that
says
you
know
this
is
the
list
of
this.
This
selector
determines
which
namespaces
can
attach
to
the
bucket,
and
it's
checked
at
the
moment.
You
try
to
bind
the
ba
to
the
b
and
at
no
other
time,
and
if
you
ever
change
it,
and
you
don't
want
to
be
a
to
have
access
anymore,
you
go
delete
that
ba.
A
Well,
actually,
it's
even
easier
than
that.
You
just
go
delete
all
the
bars
from
the
name
space
I
mean
like
you,
don't
have
to
do
a
list
and
filter.
B
H
B
You
could
do
it
yeah
yeah,
it's
not
just
a
list,
all
bass,
it's
still
fit.
I
guess
I
guess
my
concern
with
deleting
the
bars
is
what,
if
there's
a
finalizer
that
keeps
them
alive
as
long
as
the
pod
is
using
them,
then
then
deleting
them
does
nothing
as
long
as
the
mod
is
still
hanging
around.
So
you
really
have
to
go
after
the
ba
and
just
delete
it
so
that
the
cozy
controller
that
talks
to
the
cozy
driver
can
perform
the
the
revocation
that
it
needs
to
perform.
G
That
by
but
when
deleting
when
admin
deletes,
the
ba,
which
controller
is
the
one
that
revoked
like
removes
the
credentials
from
the
name
space,
is
that
one
is
one
of
those
controls
in
the
namespace.
A
So
so,
there's
no
controller
per
namespace.
There
is
a
control
that
is
namespaced
to
the
provisioner.
We
call
it
the
production.
G
B
B
G
Okay,
I
thought
thought
you.
You
meant
that
this
process
was
meant
to
update
the
ba
aar
at
some
point
in.
B
G
Okay,
and
that
just
affects
the
the
back
end
of
the
object,
store
right
right:
okay,
yeah.
It's
revolved.
A
Yeah
yeah,
so
so
so
that
you
know
this
seems
to
effectively
deal
with
well
so
far,
like
ben
said,
we
might
have
to
spend
more
time
on
it,
but
so
far
it
seems
to
effectively
deal
with
you
know,
privilege
or
bucket
access
restriction
and
expansion.
A
A
Is
is
same
name,
space
yeah
like
there
could
be
like
a
default
policy
where,
if
a
bucket
is
created
by
a
br
in
a
particular
namespace,
then
by
default
it
can
only
access
by
the
other.
You
know
other
workloads
in
the
same
name
space.
A
Would
that
be
like?
Do
you.
B
A
Yeah
we're
actually
out
of
time.
I
think
this
is
a
very
good
discussion.
Let's,
let's
continue
this
discussion
on
on
monday.
A
Maybe
not
this
one,
because
we
will
get
through
this
first.
A
Yeah
we
will
start
with
the
next
monday.
I
mean
the
monday
after
next
week
and
and
on
monday
we
will
flush
this
one
out
the
whole
name,
spaces
and
and
the
rest
of
this
this
this
design,
yeah,
like
you,
said
it's
going
to
take
a
few
weeks
of
discussing
this
design
before
we
know
this
is
the
right
way
to
go
forward.
A
I
Was
it
checking
their
the
code,
repo
that
seems
to
be
different
from
the
stock,
so
I'm
not
sure
which
one
is
newer?
If
you
take
a
look
and
ask
the
it's
about
way,
who
send
this
out,
maybe
ask
him
to
verify
yeah.
A
I
A
I
B
I
I
saw
that
so
actually
I
I
I'm
just
seeing
this
again,
so
this
is
actually
under
the
listeners
and
routes
yeah.
Okay,
so
I
think
that's
correct.
I
was
thinking
this
is
directly
under
specs,
it's
not
so
so
I
think
this
is
consistent
with
the
with
the
code.
I
think
so.
Yeah
no
worries.