►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 09 September 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
A
C
B
A
B
A
B
A
A
B
B
A
B
B
Address
is
half
the
bit
I'll
just
say
this,
because
I
don't
want
to
go
too
deep
down
this
rat
hole.
Unless
you
want
to
the
whole
discussion
around
like
transferring
of
brs
and
bars,
it
really
is
there's
two
separate
problems
that
we're
addressing.
One
is
the
intent
to
actually
share
like
where
you
you
want
multiple
users
and
multiple
namespaces
to
all
have
references
to
the
same
bucket,
but
then
there's
another
problem,
we're
trying
to
solve,
which
is
to
reassign
ownership.
C
B
A
An
answer
right
so
second
half
I
mean
we
still
need
to
talk
about
it,
but
but
I
think
the
first
half
is
a
pretty
clean
approach,
but
but
you
know
I
didn't
agree
to
it
or
anything
because
one,
I
think
I
think
everyone
needs
to
pitch
in.
We
all
need
to
agree
on
it
before
before
we
go
ahead
with
that,
but
number
two
about
this
ownership
issue.
I
think
this
you
know
we
can
solve
the
problem
in
a
simple
manner.
What
I
mean
is
we
can
keep
the
invariant
of
there's.
A
A
B
A
E
E
F
E
So
do
you
want
to
distinguish
like
considering
that,
from
user
point
of
view,
they
are
trying
to
use
existing
b
right
or
something
like
that,
like
the
b
was
already
the
and
that
we
removed
the
br
because
of
the
retained
policy,
the
b
is
still
there
right.
So
it's
like
a
brownfield
case.
If
you
think
in
that
way,.
B
B
Is
that
that's
totally
that's
totally
workable?
We
just
you
just
have
to
say
that
that's
the
plan
for
brownfield
is
you
know
you
have
to
do
this
legwork
and
then
and
then
one
person
will
end
up.
One
namespace
will
end
up
owning
it
and
if,
if
multiple
namespaces
need
to
have
access
to
it,
they'll
have
to
do
the
cross
namespace
sharing
thing.
Whatever
that
looks
like.
A
Makes
sense
all
right
so
so
it
seems
like
so
far
I
mean
we
haven't,
really
discussed
it
enough,
but
but
so
far
it
seems
workable.
Let's
keep
let's
keep
going
okay,
so
so
we
just
talked
about.
You
know
what
we
call
static,
brownfield
and-
and
we
know
this
works
for
greenfield.
Obviously,
and
we
also
know
with
reference
policy,
it's
going
to
work
for
buckets
created
in
other
name
spaces.
A
A
A
For
now,
I
think
it
looks
more
or
less
good
enough
if
any
other
questions
come
up
or
if,
if
you
feel
like
there
are
any
other
inconsistencies
or
issues
with
this
approach,
you
know
bring
it
up.
Please
we
want
to
make
sure
that
this
will
work
for
all
of
us,
yeah
all
right.
So
the
next
thing
that
he
mentioned
was,
let
me
just
share
my
screen
and
just
show
you
so
let
me
so
cross
ns
yeah.
A
A
A
A
B
B
C
A
D
C
To
user
name
spaces
right
right
just
to
cluster
scoped
resources,
so
that
was
a
b
and
a
ba
and
but
but
over
time
we
are
weakening
that
stance,
and
we
are
saying
said
you-
and
I
talked
about
this-
that
the
driver's
name
space
could
actually
have
get
access,
read
access
across
the
whole
cluster.
They
could
read
secretly.
B
C
D
A
C
B
Talking,
I
thought
we
split
the
responsibilities
between
some
central
controller
and
then
the
driver
when
it's
sidecars
and
yeah
and
if
the
central
controller
was
was
doing
its
job
or
if
it
was
structured
like,
for
example,
the
snapshot
controller.
Then
then
the
sidecar
wouldn't
need
access
to
the
to
the
namespace
resources.
It
would
only
need
access
to
the
non-namespace
resources
and.
A
No,
no,
so
that's
not
why
so
we
tore
it
down
because
so
the
architecture
changed.
So
we
were.
We
were
using
a
csi
node
adapter.
So
this
wasn't
a
month
ago
it
was
like
the
last
review
cycle,
we're
using
the
csi
node
adapter
to
to
hold
the
part
back
from
starting
and
and
mount
the
the
the
bucket
info.json
files.
A
But
after
the
review
we
all
talked
about
it,
and-
and
that
was
one
of
the
comments
as
as
to
why
we
needed
a
secret-
why
we
needed
a
csi
driver
when
we
could
just
do
with
the
secret,
and
so
when
we
went
to
the
simpler
secret
architecture,
the
csi
node
adapter
originally,
which
could
only
you
know.
We
said
the
node
adapter
would
be
able
to
get
get
secrets
from
only
one
namespace.
It
didn't
matter
anymore
because
it
doesn't
exist
anymore.
A
D
C
Namespace
of
the
driver
and
the
user's
namespace,
the
the
node
adapter
is
trusted.
It's
cozy,
it's
part
of
cozy,
so
we
we
trust
it
all.
We're
not
trusting
is
some
is
a
driver
written
by
a
vendor
or
someone
outside
of
cozy
right
and
and
that
driver's
in
the
same
name
space
as
the
sidecar
typically,
and
so
we
didn't
want
that
namespace
to
have
privileges
and
the
driver
could.
A
Mean
yeah
yeah
I
mean
talking
about
it.
That
way
I
mean
the
militias
are
malicious.
I
mean
the
cosy.
Will
not
you
know,
go
out
of
its
way
to
make
sure
the
user
is
not
a
bad
bad
actor.
All
we're
saying
is
if
you're
running
cozy,
if
you're
using
a
a
a
proper,
shipped
image,
you
know
you
ratify
the
shasam
and
everything.
Then
then
you
can
expect
a
good
behavior.
B
Well,
the
the
usually
the
the
concern
like
when
csi
that
the
concern
is
the
the
vendor
did
their
best
to
not
do
anything
bad
in
their
driver,
but
they
had
a
security
hole
in
their
driver
and
the
malicious
attacker
exploits
the
security
hole
in
the
driver
and
gains
control
of
the
process
in
which
the
csi
driver
is
running
and
from
there
they
launch
an
attack
on
the
rest
of
the
cluster,
using
the
privileges
that
the
that
the
driver
has
no,
usually
that
that's
the
threat
model
right.
Yeah.
A
E
F
B
A
Thanks,
no,
it's
that's
true.
So
so
you
know,
I
I
don't
think
that's
that's
really
an
issue.
The
csi
provision
is
still
is
pretty
overpowered
and
and
again
as
long
as
a
user
is
using.
So
are
you
saying
the
the
the
extra
power
that
you're
giving?
It
is
the
ability
to
write
secrets,
because
csi
provisioner
also
has
the
ability
to
read
secrets,
which
I
would
think
is
far
more
dangerous.
A
A
B
A
D
C
C
D
C
B
A
But
there's
no
point
in
that,
because,
because
the
information
is
going
to
be
revealed
to
all
the
users
in
the
namespace,
regardless
as
soon
as
it's
mounted,
possibly
so
so
let
me
explain
what
to
some
of
you
who
knew
or
who
may
not
be
able
to
follow
what
jeff
just
mentioned,
because
it
comes.
What
he
mentioned
is
based
on
a
lot
of
context
that
we
have
so
in
the
previous
architecture
or
the
way
we
were
building
cozy
the
way
we
had
architected
cozy.
Originally,
we
had
two
symmetric
resources.
A
A
A
So
we
have
an
architecture
where
the
driver
runs
alongside
one
of
our
components
called
cozy
sidecar
and
the
sidecar
only
had
access
to
cluster
scope,
resources,
the
bucket
and
bucket
accesses.
But
if
you
were
to
flatten
buckets
and
bucket
access
and
bucket
access
requests
into
one
and
just
end
up
with
a
namespace
resource,
say
just
bucket
access
request,
then
we
would
end
up
in
a
situation
where
the
sidecar
controller
would
need
additional
privileges
to
read
a
namespace
resource
which
is
bucket
access
requests.
A
So
we
we're
talking
about
whether
that's
a
security
concern
or
not,
and
so
far
I
mean
off
the
top
of
my
head.
I
I
don't
see
it
being
a
concern,
but
but
you
know
I
think
you
know
some
someone
might
bring
up
a
a
a
a
threat
that
maybe
I
haven't
thought
of
so
so
it's
open
for
discussion
right
now.
Jeff
did.
I
did
I
summarize
that
right,
yes,.
A
Okay,
so
just
so
everyone's
following
and
everyone
can
can
can
contribute
yeah.
I
don't
see
an
issue
with
the
sitecar
controller
or
or
the
part
where
driver
is
running,
which
need
not
be
the
case.
But
let's
say
the
part
where
the
driver
is
running.
I
don't
see
the
problem
with
it:
having
access
to
bars,
bucket
access
requests,
because
just
a
request
for
accessing
a
bucket
and
driver
already
has
privileges
to
access
the
bucket.
A
B
I'm
just
I'm
just
thinking
for
the
sidecar
that
has
to
call
grant
access
if
it's,
if
it's
getting
a
call
or
if
it
sees
a
bar,
that's
in
a
transitional
state
and
it
needs
to.
And
you
don't
know
if,
if
you
previously
called
grant
access
this
cozy
driver
or
not
because
maybe
the
last
time
you
called
it,
you
were
killed
in
the
middle
of
the
call.
B
F
A
Yeah
but
the
conversation
about
it
importancy,
I
I
don't
see
that
I
don't
see
it
being
any
worse
than
where
it
was.
I
don't
think
I
don't
think
there's
the
previously
accepted
way
and
now
there's
no
difference
rather
because
we're
never
passing
in
the
existing
secrets
to
the
driver
ever
to
you
know
to
make
sure
that
it's
not
giving
us.
You
know
it
doesn't
give
us
something
that
that
that
is
that's
already
there
yeah.
B
F
F
A
That
that's
good,
it's
it's
important,
it's
best
not
to
re-implement
or
create
whole
new
ways
of
doing
things
if
something
the
works
already
exist,
so
yeah.
Thank
you,
okay,
so
I
mean
talking
about
that
so
far.
So
what
it
seems
like
we're
saying
is,
is
if
you
just
had
a
bar
and
no
ba,
it
should
still
work.
B
A
B
G
A
Yeah
so
the
reason
to
so
we're
calling
it
credential
secret,
our
minted
credential
secret.
The
reason
we
we
give
the
name
up
front
is
so
that
you
can
start
a
pod
pointing
to
that
secret.
It
won't
start
up
until
that
secrets
available
otherwise
you're
making
it
imperative,
where
you're
waiting
for
a
secret
by
some
name
to
get
generated
before
you
can
start
a
part
and
it's
not
infrared.
It's
not
declarative
anymore.
A
A
B
B
What
is
I
mean
not
having
any
support
on
the
cubelet
side
to
plumb
things
through
automatically
for
you,
because
I
thought
that
from
an
api
perspective,
the
pod
was
supposed
to
refer
to
the
bar,
and
then
you
know
there
was
a
csi
driver
as
a
stopgap
mechanism.
But
the
point
was
cubelet
eventually
was
going
to
directly
implement
that
api
yeah.
A
B
C
B
A
A
B
A
C
Okay
and
then
that
means
cosy,
can't
respond
to
the
workload
terminating.
So
we
had
we
had
design.
I
don't
know
if
we
had
anything
coded,
but
we
did
have
design
for
down
for
deletion
using
your
business.
The
termination
of
the
workload
also
triggered
things,
and
if
the
workload
wasn't
terminated,
you
couldn't
actually
remove
the
bucket
and
and
because
it
was
being
used
so
that
we
lose
that
as
well.
Now
we.
A
And
then
we
discussed
different
ways
in
which
you
can
do.
You
can
do
the
patch
instead
or
all
these
merge
strategies
and
stuff,
but
in
the
end,
what
we
ended
up
deciding
was
we're
not
going
to
use
finalizers
that
way,
we're
not
going
to
have
a
billion
finalizers
one
for
each
part
on
the
ba
or
or
one
for
each
ba
on
the
b.
A
B
A
A
C
A
A
Maybe
if
we
really
need
to
figure
this
out,
we
could
think
about
sharding,
the
pod
name
somehow,
so
that
you
know
we
have
active
active
type
setups,
where
one
of
the
active
workers
deals
with
some
of
the
parts
and
another
one
deals
with
another
set
of
parts
that
we
load
balance
the
this
this
thing,
but
we
don't
even
need
to
go
that
far.
We
could
just
say:
there's
one
one
controller
that
just
listens
to
part
events
and
then
and
then
knows,
based
on
whatever
the
current
status.
A
A
C
A
D
C
A
C
A
C
Right,
I
I
understand
that
and
I'm
not
trying
to
raise
a
big
flag
here.
I'm
just
sharing
a
comment
in
the
past.
I
I
was
just
acknowledging
that
tim
didn't
see,
see
that
as
an
issue.
That's
all
I
wanted
to
just
get
it
in
the
recording
that
that
wasn't
an
issue
having
mix
of
sensitive
and
non-sensitive
in
the
same
secret.
A
C
A
A
A
E
A
E
A
That
would
be
good
all
right,
so
yeah,
just
just
saying
that
compromise
saying
that
that
design
choice
out
loud
so
that
so
we
know
what
compromise
we're
making
and
why
we're
making
them
again.
The
the
reason
we're
saying
is:
okay
is
because
it's
it's
a
stop
gap
measure.
This
is
not
the
long
term
plan.
A
A
A
A
A
A
B
I
don't
think
the
intention
was
was
to
to
punt
on
it.
The
the
intention
was
to
get
the
basic
one
standardized
like
the
the
the
issue
is
for
me,
has
always
been
the
downward
facing
apis.
What
does
the
pod
consume
and
what
can
it
expect
to
be
there
and
like?
I
think
we
do
need
to
figure
out
what
service
account
token-based
authentication
looks
like,
but
we
need
to
start
from
the
pods
experience
of
that.
G
Okay,
yeah
yeah,
I
think
so
as
a
user.
There
are
two
use
cases
depending
on
where
my
app
is
it's
more
nice.
It
could
already
be
used
in
our
workload,
identity
server,
but
if
it's
not,
then
it
might
be
probably
using
some
m
bars
that
might
be
mounted
from
the
secret
that
cozy
is
going
to
create
so
yeah.
C
G
G
It
goes
through
to
this
other
thing,
and
this
other
thing
understands
the
mapping
that
is
already
set
up
in
the
service
account,
and
it
understands
that
the
pot
has
is
tied
to
one
service
account
and
that
the
service
account
has
some
some
permissions,
for
example
backgrid
and
then
from
the
application.
That's
how
we
can
get
to
a
bucket
so
yeah,
those
those
are
the
use.
A
B
In
particular,
how
would
you
write
a
workload
that
could
deal
with
either
right?
Because
the
whole
point
is
a
bucket
should
be
a
bucket
and
you
you
should
be.
I
should
be
able
to
write
a
workload
that
that
says,
you
know,
give
it
a
cozy
bucket
and
it
will
run
and
then
not
care
about
how
how
you
supply
the
cozy
bucket,
and
so
so.
A
So
so,
for
that
I
thought
about
it
and-
and
you
know
pretty
much-
every
sdk
has
multiple
credential
provider
mechanism
mechanisms
and-
and
I
think
I
think
at
least
for
the
cloud
once
we
would
have
to
go
at
cosy
as
a
credential
provider,
but
but
we
should
and
they
already
have
a
order
of
precedence.
So
so,
for
instance,
instance,
iam
is
considered
more
important,
more
more
higher
higher
order
or
more
preferred
or
preferred
as
compared
to
environment
variable
based
credential
discovery.
A
B
A
A
Okay,
all
right,
okay,
so
first
I'll
I'll,
write
it
down
and
then
I'll
I'll.
Thank
you
all
first,
then,
then,
once
we're
all
in
agreement,
let's
go,
let's
go!
Thank
them
all
right!
That's
that's
it!
For
today
there
are
a
few
other
questions
that
weren't
answered,
feel
free
to
look
at
the
cap
and
and
provide
answers
to
his
questions
directly.
If
you
think
you
know,
if
you,
if
you
want
to
do
it,
if
not,
if
not
you
know,
we
will
go
the
route
that
we
were
just
talking
about.