►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 9 December 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Sidhartha Mani (Minio)
A
Earlier
this
morning,
earlier
this
morning,
I
updated
the
cap
with
all
of
the
latest
changes
we
had.
We
discussed
specifically
starting
out
with
the
iem
im
style
authentication
that
that
we've
been
discussing
the
last
few
weeks.
A
B
Doing
well
thanks
yeah,
I'm
I'm
pretty
glad
not
to
have
a
conflicting
meeting
today
for
the
first
time
in
quite
a
while.
Thank
you,
yeah.
A
And
yeah,
and
and
thanks
for
leaving
the
review,
we
I
I
do-
want
more
people
looking
at
the
cap,
I
think
it'll
help
make
it
better.
So
so
I
have
fixed
the
tab
issue.
You
should
be
able
to
take
a
easy.
You
know
better
look
at
it
now
so
so
I
have
so
the
major
change
in
the
cap
this
this
iteration
or
this
round
of
fixes
from
our
was-
was
about
iem
style
authentication.
A
Specifically
talking
about
how
the
user
experience
is
going
to
be.
A
I
haven't
gone
too
much
in
detail
about
how
we're
going
to
orchestrate
it
in
the
in
in
the
cozy
side,
because
most
of
it
is
abstracted
away
from
from
the
from
the
cozy
system
itself,
from
from
the
kubernetes
side
of
cozy
and
and
the
responsibility
primarily
falls
on
whoever
the
driver
is
so
I've
been
light
on
those
details,
even
even
though
we've
gone
into
the
depths
of
this,
with
the
with
gcs
and
aws
and
and
in
in
this
in
this
api.
A
C
A
A
Oh
no
worries
so
I
was
just
I
was
just
letting
everyone
know
that
I
made
another
round
of
updates
to
the
cab
and
while,
while
writing
the
im
part,
a
few
questions
came
up,
I
I
think
we
might
have
discussed
it,
but
I
still,
I
still
want
to
bring
it
up
just
to
make
sure
that.
A
Make
sure
that
it's
addressed
really
so
it
should
be
fine,
so
so
the
new
names
for
resources
bucket
still
remains
bucket
bucket
claim,
is
going
to
be
similar
to
a
pvc.
A
persistent
volume
claim,
as
in
it's
it's
someone
requesting
a
bucket
be
created,
or
this
claim
be
bound
to
an
existing
bucket
bucket
access
is
the
object
that
is
used
to
gain
access
to
a
bucket
and
classes
you're
already
familiar
with
we've
kind
of
gone
with
naming.
That's
that's
congruent
with
how
pvp
vc's
are
named
earlier.
A
We
called
bucket
claim,
as
bucket
request
and
bucket
access
had
had
a
symmetric
style
to
to
buckets
itself
where
we
had
a
bucket
access
request
and
a
bucket
access
from
the
beginning.
We've
we've
we've
kind
of
maintained
that
it
might
not
be
entirely
needed.
I
mean
we
didn't
need
it
bucket
access
request
and
bucket
access
was
redone
and,
and
we
flattened
them
into
just
one
object,
bucket
access.
C
A
Well,
there
was
no
technical
reason
to
do
it
either
from
the
user.
Well,
not
just
technical
from
from
the
user's
perspective.
Also,
there
wasn't
a
good
reason
to
keep
access
credentials
away
from
from
the
name
space
where
the
bucket
is
going
to
be
accessed
and
technically
either.
There's
there's
really
no
reason
to
do
it.
So
so
we
were
just.
We
were
just
like.
Why
add
the
extra
complexity
adding
more
apis?
A
Yeah,
I
was
just.
I
was
just
trying
to
say
that
we
we
weren't
yeah,
I'm
not
sure
if
we
were,
if
we
thought
one
was
better
than
the
other
all
right.
So
I
am
still
authentication
here.
Okay,
now
let
me
go
up
a
little
bit:
yeah,
okay!
So
here's
here's
what
I've
written
and-
and
this
is
what
we
discussed
so
when
when
doing
im
style
authentication,
we
expect
oh,
it's
attaching.
A
A
A
A
Since
I've
been
renaming,
there
are
some
places
where
I
have
I
have
missed.
So
please
bear
with
me
all
right.
So.
A
Okay,
so
here
it
is
so
here's
how
I've
defined
the
bucket
access
in
the
bucket
access
class
now,
so
the
admin
creates
initially
that
and
creates
a
bucket
access
class,
which
has
information
about
what
kind
of
authentication
type
is
supported
by
this
class
and
then
other
than
that.
The
regular
fields,
provision
and
parameters
are
still
there
and
on
the
bucket
access
side
that
the
user
will
create.
A
We
specify
what
the
name
of
the
class
the
name
of
the
claim
and
a
credential
secret
name.
This
credential
secret
name,
is
what
will
contain
the
finally
generated
secrets.
So
once
cozy
goes
ahead,
calls
the
driver
and
gets
credentials
for
this
bucket
access.
It
puts
the
actual
credentials
into
that
secret
defined
in
this
field.
A
Now
authentication
type
in
the
bucket
access
class
can
be
key
or
iam,
and
this
is
this
is
what
we
discussed
about
two
weeks
back:
the
names
themselves
that
that
we
we
make
them
key
based
or
im
based
authentication,
so
we
just
went
with
key
or
I
am
now.
If
you're
doing,
I
am
style
authentication,
then
the
bucket
access
class
will
look
different.
A
Just
like
I
mentioned
it
will
have
the
authentication
type
set
to
im
and
on
the
bucket
claim,
we
are
going
to
have
a
credential
secret
name
still
and
service
account
name,
so
the
credential
secret
name
is
going
to
be
the
exact
same
as
before,
once
credential,
once
keys
are
generated
in
the
previous
case,
once
keys
were
generated,
it
would
be
put
into
this,
except
in
this
case
we
won't
have
any
keys
because
we're
going
with
iam
style
authentication
where
pods
implicitly
get
privileges
to
access
the
bucket,
but
instead
this
will
have.
A
This
will
be
our
mechanism
to
prevent
the
pod
from
starting
up
until
the
bucket.
You
know,
access
our
provision
and
also
this
will
be
a
mechanism
to
provide
information
about
the
name
of
the
bucket
the
end
points
and
other
protocol
or
random
specific
parameters.
A
In,
in
addition
to
credential
secret
name
in
case
of
im
at
the
user
would
also
have
to
supply
a
service
account
name,
this
service
account
name
is,
is
going
to
be
a
kubernetes
service
account,
and
I
use
that-
and
I
say
kubernetes
service
account,
because
there
is
another
service
account
involved
in
the
mix
here,
which
is
the
service
account
on
the
object,
storage
site
on
the
infrastructure
side,
so
in
im
style
authentication,
this
service
account
and
the
the
the
infra
providers,
the
object
service
provider
service
account
are
mapped
together,
such
that
any
part
with
this
mapped
service
account
can
simply
just
access
a
bucket.
A
So
here's,
where
a
question
popped
up,
I
think
we've
brought
it
up
before.
We
can
only
specify
one
service
account
in
a
pod.
A
I'm
not
sure
if,
if
if
we
want
to
have
like
is,
is
this
a
use
case
that
we
should
be
concerned
about?
Is
my
question?
What
if
we
have
two
bucket
claims
or
two
bucket
accesses?
A
Yeah
so
so
two
bucket
accesses
and
and
both
and
and
you
want
both
these
bucket
access
or
you
want
access
to
two
buckets
in
a
card
and
and
each
one
of
them
points
to
a
different
service
account.
You
can't
have
them
point
to
the
same
service
account
is.
That
is
that
is
that
a
possibility.
C
A
Like
like
super
admins
like
like
very
highly
privileged
like
they
get
to
do
much
more
than
like,
like
one
service,
account,
is
going
to
have
just
a
lot
of.
A
More
along
the
lines
of
what,
if
I
want
to
revoke
only
one
one
part
of
the
access
that
can
still
be
done
right,
yeah
that
can
still
be
done.
I.
C
Though
the
whole
point
of
im
is
like
you
already
have
a
service
account
that
you're
using-
and
you
just
want
to
use
the
credentials
that
you
already
have
to
authenticate
to
your
bucket
so
like
at
that
point
anything
else.
The
service
account
is
being
used
for
it
isn't
relevant
to
us.
It's
just
that
hey!
I
already
have
the
service
account.
I
want
to
use
it
to
access
my
bucket.
C
Please
give
me
a
mechanism
to
do
that,
and
the
mechanism
is
create
a
bucket
access
that
points
to
your
bucket
and
has
the
same
service
account
that
your
pods
gonna
have
and
and
that
that's
that's
our
job
and
then
whatever
else
you
do
with
your
service,
account
is,
is
on
you
and
and
in
theory.
Lots
and
lots
of
bucket
access
are
very
cheap
right.
So
you
could
have
a
handful
of
buckets
and
a
handful
of
pods
and
they
could
all
be
using
different
service
accounts.
C
A
And
when,
when
when
are
we
still
declarative
as
in,
is
there
a
is
there
a
dependency
on
service
account
already
existing
or
and
is
there?
Is
that
a
problem?
Let
me
that's:
that's
right.
Yeah.
C
I
I
think
we
said
that
if
you
create
a
bucket
access
that
points
to
a
non-existent
service
account
it'll
just
sit
there
right
because
there's
not
there's
nothing
for
us
to
do.
The
sidecar
will
see
that
it
will
attempt
to
look
up
the
information
for
the
service
account,
so
it
can
invoke
the
cozy,
plugin
and
it'll
say.
Oh,
I
can't
find
anything
here
and
it'll
just
go
into
a
retry
loop.
A
Yeah,
that
seems
that
seems
logical.
That
seems
that
seems
reasonable
yeah.
I
just
I'm
just
making
sure
we
address
everything,
so
just
bring
up
these
questions.
So
so
would
you
say
that
we
we
check
if
service
account
or
credentials?
C
Like
if
it's,
if
it's
gke-
and
you
want
like
a
google
credential
like
we're,
going
to
be
handed
the
kubernetes
crown,
so
we're
going
to
have
to
go,
do
what?
Whatever
the
relevant
thing
is
to
map
that
kubernetes
service
account
to
a
google
service
account
before
we
pass
that
down
to
the
to
the
rpc
right.
C
D
C
D
C
A
A
D
A
I
I
think
I
think
you're
right
and
even
if
the
current
clouds
or
all
the
object
search
providers,
do
it
in
one
specific
way,
there's
no
guarantee
the
next
one's
going
to
follow
that.
C
Yeah,
I
I'm
cool
with
leaving
it
to
the
driver
right
again,
someone
someone
who
knows
the
details
should
tell
us
what
the
appropriate
thing
is.
I
guess
I
was
just
responding
to
the
the
service.
Account
must
exist
and
regardless
of
whether
the
details
of
how
service
accounts,
kubernetes
service
accounts,
get
bound
to,
for
example,
a
google
service
account.
I
still
think
the
sidecar
would
want
to
validate
that.
There
is
a
kubernetes
service
account
with
the
given
name
before
before
passing
it
down
to
the
to
the
grpc
right,
and
it
could
just
say
no.
A
Yeah
that
should
work
all
right,
so
the
next
question
was
going
to
be
around,
so
I
do
want
to
discuss
reference
policy,
but
before
that,
I'm
just
I'm
just
thinking
through
and
seeing
if
there
was
something
else
left
over
in
the
service
account
thing
so
yeah.
This
is
going
to
be
straightforward.
So,
once
once
we
once
we
map
the
service
account
to
an
object,
storage
service
account
or
a
cloud
service
account.
A
Someone
can
just
specify
it
in
their
part
and
just
like
that
they
have
access
to
the
bucket
and
and
they'll
know
the
details
of
the
bucket
itself
by
looking
at
the
credentials
secret,
that's
mounted
at
a
at
a
part
of
their
choosing,
oh
yeah.
This
is
what
I
wanted
to
go
over
in
this
in
this
itself.
So
bucket
info.json,
so
so
in
case
of
a
regular
key
based,
authentication,
authentication
type
is
going
to
be
set
to
key.
A
A
So
so
so,
in
this
case,
I've
put
out
a
sample
bucket
info
here
and
in
case
of
key
based
authentication.
It's
going
to
be
key,
and
in
case
of
I
am
still
authentication
it's
going
to
be.
I
am
in
key
ways:
authentication
is
pretty
straightforward.
You
just
have
the
access
key
and
secret
key
in
imstar
authentication.
A
I've
put
this
in
there.
The
metadata,
url
and
the
service
account
token
path.
A
The
idea
behind
the
metadata
url
is
that's
the
client
sdks
or
pretty
much
all
of
the
object,
storage,
client,
sdks,
utilize,
a
metadata
url
or
talk
to
a
metadata
service
of
some
sort
to
figure
out
or
to
exchange
their
service
account
token.
For
a
token
that
can
be
used
to
get
access
to
the
bucket.
A
So
my
you
know
one
is
you
can
assume
that
the
client
sdks
know
how
to
do
this
and
you
don't
have
to
specify
the
metadata
url,
but
specifying
it
allows
you
know,
gives
us
greater
flexibility.
So
my
question
is
really
any
thoughts
on
that.
Anyone
knows
more
about
this
then
than
I
do
anyone
who's
worked
with
metadata
service.
C
I
think
I
had
made
a
similar
suggestion
earlier
on,
mostly
just
because
it
gives
implementers
flexibility
to
invent
something
else
and
have
the
scheme
still
work,
but
I
think
the
argument
at
the
time
was
well.
Is
anyone
actually
going
to
do
that
and
the
answer
is
probably
not
so
I
don't
have
a
strong
feeling.
C
A
C
Not
if
you
wanted
to
be
backwards
compatible,
I
mean
either
we
force
people
to
start
using
it
from
the
beginning
or
we
or
we
leave
it
out,
and
then
we
never
add
it
right
because
backwards
compatibility
means
adding
new
required
fields,
breaks
everyone.
When
you
add
them.
D
C
C
C
A
I
think
where
ben
is
coming
from
is
it's
it's
a
new
field
for
an
existing
workflow,
so
the
the
same
thing
that
you
could
do
without
that
field
now
requires
that
field,
so
the
meaning
of
the
workflow
or
the
workflow
itself
changes.
I
I.
D
C
That
the
changes
back
that
the
other
changes
backwards
compatible,
but
then
it's
not
a
new
required
field.
It's
a
new
optional
field.
It's
a
new
field,
that's
safe
to
ignore,
so
so
that
that's
the
key
is
anything
we
add
is
going
to
be
optional
and
therefore
all
of
the
required
stuff
we
have
to
have
in
on
day.
One.
D
A
But
aren't
we
aren't
we
telling
aren't
we
telling
our
users,
you
can
safely
ignore
this
field
and
it
will
work
say
for
s3
while
you
know
so
so
so
I
guess.
D
D
A
They
were
unsupported
before
and
now
we
say
you
know
it's
supported
now,
except
we
don't.
We
also
have
to.
I
mean
I
guess
if
we
also
communicate
and
say
that
in
order
to
use
the
this
this,
this
new
vendor,
that
that
has
a
different
metadata,
url
you'll
also
have
to
use
a
different
sdk
and,
and
so
we're
not
really,
you
know,
drag
and
drop
replacement
between
between
different
vendors
at
that
point,
because
the
application
will
need
to
change
the
sdk
as
well
as
as
the
definition
in
in
in
the
cozy
objects.
D
Yes,
but
I
think
that's
kind
of
like
I
don't
see
a
good
way
around,
that.
D
A
Fair
enough
yeah,
that's
that's
kind
of
why
I
brought
this
up.
So
it
seems
like
we're
all
in
the
in
agreement
that
this
field
isn't
isn't
required
right
now
and
we
can
add
it
going
forward.
C
You
know
the
the
details,
because
at
the
end
of
the
day,
cozy's
not
going
to
say
like
we're
compatible
with
sdks
a
b
and
c,
we
want
to
say
like
what
cozy
gives.
You
is
this
file
at
this
path
with
these
contents,
and
this
is
what
they
mean
and
if
your
sdk
can
just
read
that
great.
But
if
not,
you
have
work
to
do,
and
I
would
rather
that
that's.
C
The
kind
of
statement
we
make
is
is
you
know,
cozy
is
providing
the
following
json
file
in
the
following
place
with
the
following
fields,
and
and
and
maybe
you
need
to
go
access
an
http
api,
in
which
case
the
protocol
is
as
follows.
You
know,
and
we
spell
it
out
and
then
hopefully,
sdks
can
just
work
with
that,
but
it's
not
our
job
to
keep
the
sdks
up
to
date
or
make
them
compatible.
It's
just
you
know
our
job
is
to
provide
the
same
information
down
into
the
workload
every
single
time.
A
All
right
so
yeah,
so
so
there's
another
field.
The
service
account
token
path
that
that
I
added
it,
because
I
wasn't
sure
at
that
point
if,
if
we
ever
as
in,
if
you're
going
to
choose
a
particular
token
and
and
kind
of
specify
it
in
the
bucket
info.json
to
say
that
this
token
is
the
one.
That's
that's
going
to
give
you
access
to
the
bucket.
A
Is
I
don't
know
if
that's
even
possible
or
realistic
at
this
point,
the
idea
behind
it
was
in
case
you,
you
couldn't
specify
the
service
account
name,
because
at
that
point
I
still
wasn't
sure
in
case
you
couldn't
specify
the
service
account
name
and
you
directly.
Then
you
could
directly
just
use
a
have,
have
credentials
be
granted
or
actually
granted
for
a
different
service
account
and
just
have
the
token
mounted
in
in
in
this
path
here
that
was
kind
of
an
other
thought
that
I
had.
So.
A
C
To
be
like
putting
second
or
third
service
account
tokens
into
the
pod,
I
I
don't
understand
when
that's
a
win
relative
to
just
creating
access
to
the
service
account
that
the
pod
is
running
as
yeah.
A
A
A
A
So
as
soon
as
you
said
it,
I
remember
it,
let's
just
quickly,
look
it
up.
C
A
You
know
for
some
reason
in
this
chrome
profile
of
mine.
I
control
f,
doesn't
work,
but
in
this
other
profile
it
works.
I
don't
know
the
configuration
that
does
that
so.
A
That's
all
it
is
okay,
so
it's
multiple
tokens
I
just
wanted
to
verify,
even
if
it's
just
for
me
just
for
just
for
understanding
it
better
coming
back
here,
all
right,
so
so
so
this
is
where.
So.
This
is
what
I'm
gonna
update
the
kept
with
then
I'm
gonna
take
out
metadata,
url
and
service
account
token
path,
which
yeah
doesn't
even
make
sense
anymore,
so
the
so.
The
next
thing
is,
I
want
to
talk
about
bucket
sharing
so
in
alpha.
A
First,
I
want
to
confirm
this
in
alpha,
which
is
our
next
milestone.
We
are
saying
that
bucket
buckets
created
in
one
name,
space
is
freely
shared
with
others
or
with
the
other
name
spaces.
A
That's
that's
the
kind
of
stance
that
that's
how
we're
starting
out
with
this
and
and
the
reason
for
it
is
we're
still
flushing
out
the
idea
of
how
to
restrict
access
and
the
best
plan.
We
have
right
now
or
best
alternative.
A
We
have
right
now
to
this
is
a
reference
policy
using
reference
policy
and
reference
policies
where
you
get
to
set
a
policy
that
defines
what
can
you
refer
to
from
a
particular
resource,
so
you
so,
for
instance,
you
could
say
from
from
this
namespace
a
user
can
only
refer
to
buckets,
you
know
specific
buckets
and
but
not
all
of
them.
Reference
policy
lets
you
specify
that
so
so
we're
still
flushing
it
out.
A
Like
that's,
that's
kind
of
the
the
approach
the
the
gateway
api
team
is
following
and,
and
we've
been,
we've
been
encouraged
to
go,
look
at
it
and
and
that's
how
it
works
with
you
know,
for
them,
and-
and
I
think
we
can
adopt
something
similar
here,
but
I
wanted
to
first
confirm
if
that,
if
that
stands
for
alpha
is,
is
what
we
indeed
decided
on
long
back
when
we
last
discussed
it
where,
where
bucket
is
you
know,
it
can
be
freely
shared
and
and
in
the
future
we're
going
to
move
to
reference
policy,
any
thoughts
or
objections
to
that.
A
C
Well,
the
the
problem
was
that
we
we
know
we
need
a
security
mechanism
and
we
we
went
through
several
different
ideas,
all
of
which
got
rejected
and
the
the
least
bad
one
was
the
the
reference
policy
which
which
we
liked,
but
I
think,
there's
a
is
it
a
timing
issue?
You
said
that
we
can't
get
the
reference
policy
stuff
in
the
in
the
alpha,
so
we
were
going
to
just
say
well,
this
is
coming
as
part
of
the
alpha
2
or
beta
or
whatever.
A
A
We're
not
we're
not
really
restricting
us
and
we're
not
we're,
not
really
saying
you
can't
do
that.
We're
just
saying
you
have
to
do
that
with
the
policy.
Now
I
mean
it's
alpha,
it's
understood
that
things
will
change
and-
and
I
think
I
think
saying
no
reference-
sorry
no
sharing
at
all
is
is,
it
could
be,
could
be,
is
probably
less
desirable
than
than
saying
anyone
can
anyone
in
my
classic
can
just
can
just
access
the
bucket
if
what
we're
trying
to.
C
Say
is
like
here's,
the
proof
of
concept.
Please
go
out
and
use
this
and
and
tell
us
what
you
like
and
don't
like
about
it
as
a
user
I'm
I
would
rather
be
in
a
situation
where,
like
I
can
use
it
securely
and
it's
missing
some
features
to
be
in
a
position
where
I
it
has
the
features,
but
it's
not
secured
yet.
C
A
I
find
that
I.
A
Yeah
or
start
without
the
insecure
things
yeah,
I'm
I'm
fine
with
that
either
either
stances
are
okay,
so
so
it
does
raise
a
few
questions,
though
what
happens
to
a
bucket
when
the
name
says
that
originally
created
it,
and
that
kind
of
now
this
this
kind
of
this
concept
of
ownership,
like
the
namespace
that
originally
created
the
bucket,
is
gone.
The
name
itself
is
gone,
so
nobody.
A
C
B
A
I
think
I
think
what
michelle's
saying
is
is
similar
to
what
you
mean
by
rebinding
pen,
so
so
importing
of
an
existing
bucket.
When
we
say
we
generally
mean
importing
a
bucket
that
was
created
outside
of
cozy-
something
that's
already
there,
but
not
in
the
cluster.
Yet.
G
C
A
A
C
B
A
Okay,
okay
sounds
good
to
me,
so
just
to
summarize
we're
saying
that
right
now,
the
way
we
do
bucket
sharing
is
that
we
don't
do
bucket
sharing
and
it's
really
not
accessible
by
two
namespaces
at
once.
But
if
the.
D
G
I
thought
that
should
be
possible
right.
You
just
you
just
need
to
have
two
bucket
api
objects,
pointing
to
the
same
similarly
to
snapshots
because
snapshot
you
can.
You
can
share
that
way.
It's.
G
Provide
a
api
for
youtube
for
you
to
do
that.
Basically,
like
the
what
is
that
reference
policy,
we
don't
provide
that,
but
you
can
actually
do
this
manually
by
creating
a
new
bucket
api
object
pointing
to
that
bucket.
You
should
be
able
to,
and
then
you.
G
A
C
A
G
G
A
Yeah,
okay,
so
so
we
do
have
this
concept
of
ownership
and
then
kind
of
I
mean
we
don't
want
to
say
it
that
way.
I
think,
because
it's
not
going
to
be
relevant
right
after
alpha,
but
we
kind
of
do
where
bucket
is
owned
by
a
namespace
until
until
it's
not.
D
I
guess
one
interesting
question
I
have
in
general
about
the
sharing
use
case
is
is
like
we're
tying
things
to
service
accounts
and
but
like
pods
in
different
name,
spaces
are
going
to
have
different
service
accounts.
A
Oh,
the
the
so
we
have
the
concept
of
creating
or
binding
a
bucket,
and
that's
that's
separate
from
accessing
the
bucket.
The
service
accounts
are
tied
to
bucket
access
objects
which
are
namespaced
so,
okay,.
B
A
But
currently
we're
gonna
only
allow
multiple
bucket
accesses
for
the
same
bucket
from
the
same
name,
space
where
the
bucket
was
claimed
well
from
the
same
name,
space
where
you
know
which
triggered
the
creation
of
the
bucket.
So
so
this
also
adds
another
concern,
which
is
what,
if
we're
exporting
a
bucket
that
wasn't
created
in
any
name
space
who
gets
to
be
the
owner
of
this
bucket.
Let's
say
I
have
two
different
bucket
claims
from
two
different
name:
spaces
trying
to
bind
to
this
bucket.
D
The
does
the
bucket
object
have
a
like
back
pointer
to
the
bucket.
C
A
A
So
yeah
it's
fine
yeah.
So
so
please,
please,
take
a
look
at
the
cap
and
I'll
make
the
small
updates
needed
to
just
catch
up
to
everything
we
talked
about
today,
but
other
than
that.
I
think
I
think
it's
ready
for
another
review
and-
and
if
anyone
here
has
any
questions
now
is
a
good
time
to
bring
it
up.
D
D
That's
actually
melting,
a
volume
with
the
information
like
the
credentials
and
stuff
access
tokens
into
the
pod.
A
We
got
rid
of
that,
so
we
don't.
We
don't
have
that
anymore.
We
originally
had
it
just
for
only
one
reason,
which
was
to
prevent
the
part
from
starting
up
until
the
credentials
were
ready.
A
D
A
Right,
yes,
that
would
be
at
this
time.
I've
called
it
attaching
buckets
it's
it's
not
the
same
as
attaching
a
block
device,
but
I've
just
used
the
term
attaching.
Maybe
if,
if
someone
knows
a
better
word,
we
can
use
that
here.
Let's
just
call
it
attaching
buckets
and
yeah.
It
talks
in
detail
about
how
to
go
about
doing
that.
D
Okay,
so
basically
the
pod
needs
to
add
this
secret
volume
out
to
their
spec,
okay,
cool
and.
F
A
Yeah
yeah,
we
actually
implemented
it
even
and
it's
it's
unnecessary
again,
just
technically
speaking
and
the
one
argument
for
it
was
what,
if
what
if
we,
what
if
the
secret
already
exists
so
so
in
the
in
this
case,
there's
a
possibility
of
a
user
wrongly
specifying
the
same
secret
name
for
two
different
bucket
accesses.
A
You
know
secret
one
for
bucket
one
and
as
well
as
bucket
two,
and
in
that,
in
this
case,
depending
on
the
order
of
creation,
one
of
the
buckets
you
know
the
access
is
a
big
round
for
one
of
them,
but
not
both
with
the
node
agent.
We
could
auto
generate
these
secrets,
have
them
have
random
names
and
user
would
never
have
to
know,
and
and
this
this
the
secret
would
be
mounted
into
the
pod
and
we
were
going
to
eventually
put
it
in
in
the
cubelet.
A
D
I
mean
you
could
mitigate
that
by
setting
the
r
back.
Well,
I
guess
our
back
is
at
the.
D
A
D
C
Michelle,
I
think
the
problem
that
sid
is
alluding
to
is
that
in
when
you're
running
as
a
controller,
you
don't
necessarily
know
which
user
created
each
individual
object
so
like.
Unless
you
have
additional
information
about
which
service
account
or
which
user
is
supposed
to
have
access
to
something
like
the.
In
the
context
of
a
controller.
C
C
D
I
guess
that's
why
we
need
the
that's,
why
we
need
the
bucket
access
right,
because
I
guess
by
default,
by
default,
you
create
a
bucket,
but
no
one
can
actually
access
it
until
you
create
the
bucket
access
object
right.
A
The
user
has
to
use
it
correctly
and
I
mean
if
we
can
also.
A
D
Cool
yeah
sounds
good
to
me.
I
know
maybe
some
food
for
thought
for
the
next
discussion,
but
I
know
in
our
back
there
is
this
general
concept
of
privilege
escalation,
which
is
like
basically
being
able
to
grant
yourself
permission
that
you
don't
have.
D
A
D
Yeah
like
like
there's
this
there's
this
like
issue
scenario
where
it's
like.
If
you
have
permissions
to
create
roles
and
role
bindings,
could
you
actually
create
a
role
binding
to
some
resource
that
you
actually
don't
have
permissions
to?
D
D
But
it's
like
special
logic
that
has
to
be
implemented,
and
so
it
I'm
wondering
since,
like
you
know,
bucket
access
is
like
kind
of
similar
to
our
back.
So.
C
A
We
can
address
that
with
a
reference
policy
saying
that
bucket
access
can
only.
C
Yeah,
but
anyone
anyone
in
that
name,
space
who
can
modify
or
create
bucket
reference
policies
can
also
just
create
a
new
one
of
those.
I
I
think
our
security
model
has
been.
If
you
have
a
bucket
in
your
namespace,
you
can
and
you
can
create
bucket
access
in
the
namespace.
You
can
in
principle,
grant
access
to
anyone
in
the
namespace.
C
A
C
D
A
G
Thank
you
oh
hold
on,
so
for
the
reviews
it
looks
like
you
will
need
to
update
the
cap
again
before
you
pin
tim.
G
And
then
also
michelle
is
also
reviewing
it
right,
make
sure
you
already
in
the
cab
right,
yes,
and
you
can
also
sneak
out
with
team.
I
think
that'll
be
good.
If
you
know
him.
D
Yeah,
I
also
have
like
I
say
I
technically
have
more
time
than
tim,
but
also
I'm
finding
myself
pretty
busy
lately
so
but
yeah.
I
will
try
to
make
an
effort
to
to
take
a
little
bit.