►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 18 November 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)
B
A
Yeah,
well,
you
don't
have
a
solution
yet
before
one
of
the
problems
I'm
hoping
ben
will
join
so
today,
what
I
thought
we'll
do
something
a
little
differently
good
morning,
sir:
hey
hey
good
morning
so
shing.
So
in
order
to
reach
consensus,
I'm
thinking
I
think,
it'll
help.
If
we
visually
can
look
at
what
the
structures
are
going
to
look
like.
B
A
Yeah
yeah,
no,
no,
that's
totally
understandable!
Okay!
So
let's,
let's
try
that
today.
Can
you
give
me
those
permissions.
C
I'm
sorry
post
permissions.
Can
you
give
me
hosts.
A
B
D
A
Okay,
so
let's
talk
about,
let's
actually
live,
do
this,
I
want
to
see
how
we're
going
to
represent
the
different
fields
and
clear
up
the
issues
we've
been
seeing
with
with
workflow
identity.
So,
let's
start
with
what
we've
got
so
far
for
access,
key
and
secret
key
and
then
we'll
go
into
workload
entity.
A
Okay,
so,
okay,
can
you
help
me
get
started
so?
Are
you
saying
that
okay.
E
A
Sure
sure,
that's
that's
fine
by
me.
We
can
start
with
the
bucket
request.
Actually
bucket
class
really
doesn't
have
much
information
other
than
provisioner,
and
then
it
has.
Let
me
try
and
remember
this
parameters.
A
A
And
retention
policy
deletion
policy
so
again
the
pro
yeah.
We
moved
the
protocol
back
here.
This
one's,
not
updated
deletion
policy.
A
Bucket
request
currently
simply
just
says,
bucket
class.
A
And
right
now
it
doesn't
say
anything
else,
it
doesn't
say
it
wants
workload,
identity
or
access
key
security.
Nothing
like
that.
A
A
Name,
we
had
something
like
that.
Let
me
see
what
would
that
do
it
would
let
you
know
it's
it's
for
denoting
the
name
of
the
request
claim:
yeah
credential
secret
name,
bucket
access,
name,
bucket
name.
D
A
C
F
A
B
F
Right
but
I
mean
I
way
way
way
back
at
the
beginning,
the
the
plan
was
like
the
pod
would
refer
directly
to
the
bucket
access
and
there'd
be
some
csi
driver.
That
would
know
when
the
bucket
access
was
provisioned
and
be
able
to
extract
the
actual
secret
name
and
do
all
the
plumbing
that
was.
That
was
the
plan
back.
We
moved
yeah,
okay,
so
so
so
the
plan
now
is,
there
is
no
magic.
You
just
have
to
handle
the
secret
yourself
yeah,
but
then
who?
A
Cozy,
so
so
they
they
decide
where
they
want
the
secret
to
show
up
in
the
part.
Cozy
can't
decide
that
for
them.
F
F
A
Yeah
so
yeah,
so
that's
how
we've
been
doing
it
all
right.
So
now,
let's
get
into
bucket
access
class,
I
just
copied
all
the
fields
doesn't
have
these
fields.
Let
me
see
what
what's
there
right
now?
Oh
just
parameters
all
right.
A
So
we
can
specify
what
kind
of
yeah,
let's
let's
start
with
what
you're
going
to
specify
here.
So
far
only
parameters
was
needed
because
we
just
assumed
it's
always
access
pc
quickly,
not
anymore,
though
so
now
we
have
two
authentication
styles.
A
F
F
A
Isn't
that's
the
kind
of
reason
we're
going
to
pick
because,
okay.
F
A
F
Okay,
so
then
I
mean
I
where
we
left
the
last
meeting
was
we
were
stuck
on
this
question
of
who
gets
to
specify
what
the
what
the
authentication
type
is
going
to
be
and
how
how
the
user
face,
how
the
kubernetes
facing
api
deals
with.
You
know
if
there's
multiple
users
in
the
name
space.
How
do
you
know
which
one,
if
you
don't
care
about
the
user,
then
like?
What's
the
point
of
that
field
and
all
of
those
questions
yeah.
F
A
A
I
mean,
isn't
it
better
to
specify
it
here,
but
have
the
admin?
Do
it
and
then
say
say
the
admin
wants
this
and,
and
they
say
I
am
style.
F
A
Well,
that's
the
admin
problem
right
because
you
can.
You
could
do
that
with
any
any
driver
and
any
any.
You
know
any
feature
in
kubernetes
like
I
could
set
up
a
csi
driver
that
that
has
you
know
that
that's
expecting
a
feature.
That's
not
provided
by
by
the
driver
like
I
could
set
up
a
storage,
yeah.
F
F
A
It's
reasonable.
So,
let's
just
say
we
go
with
this.
You
know
what
we
can
actually
reuse,
credential
secret
name
regardless,
because
what
ends
up
going
into
the
pod
with
workload
identity
is,
you
know
as
a
token
what?
If
what,
if
we
set
the
token
to
be
in
in
the
credential
secret
name,
so
so
with
access
key
secret
key
again,
it
goes
into
credential
security
name,
that's
pretty
straightforward,
but
with
iam
style
access,
there's
a
token
provided
to
the
pod
and
then
that
token
is
associated
with
a
workload
identity
in
the
back
end.
A
So
far
we
were
providing
the
token
using
service
account,
so
it
goes
into
a
standard
spot.
What
if
we
said
it
will
go
through
the
credential
secret.
E
C
F
A
F
A
F
A
You
associate
one
service
account
with
multiple
authentication
credentials
like
can
I
plumb
one
service
account
to
be
associated
with
the
workload
identity
and
also
associated
with
a
bunch
of
cluster
roles.
That's
possible
right,
so
I
I
don't
really
ever
need
more
than
one
service
account
right.
So.
F
Given
you.
I
don't
know
the
details
of
that,
though,
but
my
my
presumption
had
been
that
we
would
be
piggybacking
on
the
actual
service
account
token
when
using
iam,
and
we
would
not
be
plumbing
anything
into
the
pot
at
all.
You'd
just
be
saying
or
well.
You
know
we
would
plumb
in
something
that
said
you're
using,
I
am
go,
go
find
your
service
account
token
and
but
like
no
actual
secret
data
would
come
in.
It
would
just
be
a
you
know,
a
bucket.json
that
gave
you
your
regular
bucket
information
and
then
directed
you
to
go.
A
F
A
That
works,
it
was
just
a
suggestion,
but
yeah
that
works.
So
so,
let's
say
we
go
service
account
tokens
here,
as
the
other
service
account
name,
and
this
gets
plumbed
into
the
pod.
So
we
don't
have
so
what
we're
saying
right
now
is
we
don't
have
this
risk
of
occupying
a
service
account
token
and
the
part
not
being
able
to
utilize
a
different
one?
F
F
No,
no
I'm
saying
like
the
pod
has
a
service
account
field.
It's
going
to
have
a
value
like
it.
It's
going
to
be
up
to
you
to
ensure
that
the
value
that's
specified
in
the
pod
matches
the
value
that's
set
on
the
ba,
because
if
they
don't
yes,
we're
not
going
to
know,
and
it's
just
going
to
break
right,
and
that
I
mean
I
don't
know
how
I
feel
about
that.
It
kind
of
feels
bad,
isn't.
F
F
F
That's
the
right.
I
refer
to
the
secret
that
was
specified
by
the
bucket
access
like
there
is
no
way
for
us
to
notice
that
bob
and
alice
are
not
the
same
and
we'll
just
allow
the
pod
to
start
up
we'll
plumb,
the
secret
in
they'll,
try
to
access
the
bucket
and
it'll
fail
because
it'll
be
wrong
wrong
service
account
right
and
and
nowhere
along
that
path.
Do
we
have
an
opportunity
to
catch
it
and
and
say
this
is
an
error
we
just
have.
F
F
B
A
F
A
D
F
F
Yeah
yeah,
I'm
saying
it
is
a
user
error,
but
but
the
problem
is
it's
a
user
error
that
no
one
catches
until
the
workload
just
fails
like
there's,
no
controller,
that
will
notice
that
and
say
this
is
an
error
you
need
to
fix
it.
It'll
just
go
all
the
way
to
the
point
where
you'll
fire
up
your
pod
and
you'll
get
a
weird
authentication,
error
and
you'll
see.
That's
that's
strange.
F
F
A
So
we
could
make
the
field
look
like
it's
either
service
account
name
or
credential
secret
name.
A
C
F
F
And
everything,
and
so
so
that's
going
to
be
something-
that's
always
present.
100
of
the
time,
no
matter
what
you're
doing
you're
going
to
have
one
of
those
secrets
it's
going
to
get
plumbed
in
it's
going
to
have
a
format
that
you
can
rely
on
and
in
some
cases,
it'll
contain
an
access
key
secret
and
in
other
cases
it
won't
and
it'll
tell
you,
hey,
go
use
your
go!
Use
your
token
and,
and
hopefully
you
picked
the
right
token,
which
which
makes
me
nervous.
Okay,.
A
Let's,
let's
write
this
out
also.
A
So
here
we
have
just
some
metadata.
I
don't
think
if
this
is
needed,
just
bucket
name,
endpoint.
F
Well,
I
I
would
have
liked
a
different
file,
but
again
that
was
all
based
on
the
assumption
that
we
had
like
some
csi
driver
that
got
to
configure
this
stuff
for
you.
If
it's,
if
it's
literally
just
a
pre-made
secret
that
we're
plumbing
in,
we
don't
have
any
opportunity
to
invoke
anything
special
and
we
kind
of
are
forced
to
just
embed
things.
Yeah.
B
F
B
F
You
haven't
put
anything
for
bucket,
yet
endpoint
and
and
the
bucket
access,
so
so
you've
specified
the
the
spec
for
the
bucket
access,
but
we
had
said
that
there's
a
bunch
of
important
stuff
in
the
status
of
the
bucket
access.
F
If,
if
we're
not
having
ba
and
bar.
A
F
G
C
A
So
this
looks
good
so
last
week.
What
was
that?
What
was
the?
What
was
the
argument
about,
so
we
were
trying
to
decide.
E
So
if
I
remember
correctly,
the
issue
was
like:
where
do
you
want
to
put
the
service
account
name
and
the
portability
issue?
So
if
you
specify,
like
the
application,
part
first
choose
to
use
a
secret
name
access
key
and
when
it
moves
to
a
different
cluster,
it
it
plan
to
use
the
service
like
identity
manager,
account
authentication
how
we
handle
those
scenarios.
A
Okay:
okay:
let's
talk
about
portability
and
yeah,
let's
start
with
portability,
so
I
let's
say
we
move
provisionals
here.
A
Let's
say
we
move
so
portability
in
the
sense
using
the
same
bucket,
access
and
bucket
request,
but
changing
the
provisional
not
really
putting
the
bucket
itself
like
not
putting
an
existing
button
right,
yeah
we'll
get
into
that
a
second
okay.
So.
F
But
but
yeah
the
the
portability
problem
is
is
if,
if
the
bac
said
authentication
is
key,
then
it
didn't
matter
what
you
put
in
the
service
account
name,
but
if,
and
so,
if
you
put
garbage
in
the
service
account
name,
it's
going
to
work
on
the
one
that
uses
the
authentic,
the
key
authentication
and
it's
not
going
to
work
on
the.
I
am.
A
F
F
Right
and
and
at
that
point,
if
you
specify
the
wrong
server's
account,
name
access
might
be
granted
to
the
wrong
person
and
then,
when
your
pod
starts
up,
you'll
have
a
token,
but
it
won't
be
the
right
token
and
you'll
you'll
lose
x.
You
won't
have
access
so
so
the
problem
is,
is
that
service
account
name
matters
in
some
cases
and
doesn't
matter
in
other
cases,
and
how
do
you
make
sure
that
people
use
it
correctly.
A
I
don't
think
we
need
to
do
any
more
than
this.
It's
it's
understood
with
with
any
web
client.
Actually,
if
access
is
denied,
then
there's
something
wrong
with
the
credentials
and
and
all
clients
are
have
the
facilities
to
handle
with
it.
Well,
I
think
all
we
would
expect
you
know
if
they
just
throw
logs
saying,
hey,
look.
They
expected
a
service
account
that
has
access
to
this
bucket,
but
it
doesn't.
F
A
F
A
A
There
is
no
way
for
me
to
know
until
I
actually
open
up
the
application.
Try
to
use
that
feature.
F
A
Is
that
wrong?
Yeah?
If
you
got
the
storage
class
right,
so
storage
class
can
specify
file
system
type.
So
so,
let's
say
I'm
expecting
xfs
because
let's
say
I'm
using
copy
on
write
for
vm
management.
Okay
and
that's
what
I
expect
to
be
in
my
storage
class
but
then,
but
then
I
forget
to
put
the
storage
class
in
or
I
put
it
wrong
and
I
end
up
getting.
I
end
up
getting
a
different
file
system
that
doesn't
have
copy
on
right.
So
I
end
up
getting
very
slower.
F
B
A
No,
but
but
all
applications
are
actually
well,
you
know
they
all
know
to
check
if
access
is
granted
or
not
like
every
application
knows.
B
A
F
A
F
A
I
mean
I
it's
good
to
it's
good
to
I
like
that,
we're
trying
to
improve
the
ui.
I
I
really
do
I
I
don't
see
a
simple
solution.
That's
why
I
think
I.
F
B
E
Driver
have
smooth
or
like
whether
now
it's
how
why
the
decision
was
made
like
initially
like
we
had
some
control
on
the
application
right,
at
least
of
course
here,
but
we
have
no
no
control
on
the
place
at
the
moment,
like
I'm
just
considering
for
the
future.
Maybe
some
other
features
require
some
control
on
the
application
board
right.
A
Csi
driver
initially
we
brought
it
in
because
it
was
a
you
know.
It
was
one
of
the
approaches
to
keep
the
ball
from
starting.
If,
if
you
know,
if
bucket
wasn't
provisioned
yet.
F
Well-
and
there
was,
there
was
another
reason
that
I
remember,
which
was
we
were
hoping
that
this
would
eventually
become
like
an
entry
feature.
Part
of
cubelet,
where
you
could
just
specify
buckets
as
part
of
your
pod,
spec
and
cubelet
would
just
do
the
right
thing,
but
because
we
didn't
want
to
have
to
fight
the
battle
of
getting
through
a
proper
injury,
kubernetes
feature.
F
A
F
C
F
Yeah,
but
but
the
critical
difference
is
that
like
when,
in
a
world
where
this
is
in
kubler
in
a
world
where
this
is
in
a
csi
plug-in
that
has
access
to
the
same
kind
of
information
that
cuba
has,
we
can
do
way
smarter
things
like
we
don't
have
to.
You,
don't
have
to
tell
us
the
secret
name
like
we
can
auto-generate
the
secret
and
put
it
in
a
special
place
and
retrieve
it.
B
B
F
F
F
A
B
D
B
F
F
F
A
But
a
better
use
of
our
time
is
to
get
this
through
and
then
work
on
the
cubelet
one
rather
than
getting
a
cs
editing,
perhaps
yeah
yeah
yeah.
So
let's
do
that.
So
I
think
this
looks
good.
I
think,
overall,
this
looks
good.
It
addresses
portability
of
one
kind.
Let's
try
the
other
two
kinds,
so
one
more
portability
is
or
just
the
other
time
which
is
moving
the
bucket
itself.
A
So
moving
the
bucket
itself
doesn't
change
from
where
we
how
we
had
it
before,
let's
say
we're,
moving
the
bucket
itself
from
one
cluster
to
another,
so
cross
cluster
portability.
The
way
we
were
saying
it
before
is
you
have
the
bucket
copied
over
and
then
you
have
the
bucket
access
actually
nothing
else.
F
Or
you
could
just
you,
don't
even
need
a
bucket
access.
You
could
just
copy
the
contents
of
the
secret
from
the
first
cluster
and
use
the
secret
directly
on
another
cluster
yeah
well
and
in
that
world
you
don't
even
need
the
bucket
either
right,
if
you
just
provision
a
bucket
and
a
bucket
access
on
one
cluster
and
then
take
the
contents
of
that
secret
and
the
pod
to
another
cluster.
F
Yes,
yes,
if
it's
imbe,
it's
authentication,
you
need
a
new
ba,
which
means
you
need
a
copy
of
the
b
and
the
br
on
the
on
the
other
cluster.
And
then
you
need
a
second
ba
to
be
created
so
that
you
can
grant
access
to
the
token
there
sure,
okay.
D
A
All
right,
so
that
addresses,
I
think
I
think
portability
is-
is
reasonably
manageable
here.
What
are
the
other
concerns?
Let's
go
over
them.
G
Sid,
will
you
make
this
document
your
drawing
available
so
that,
like
this
thing,
storage
cozy,
so
we
can
look
at
it?
Make
comments.
A
Yeah
right
now
I
don't
see
a
screen.
A
A
A
Oh
yeah,
you
know
having
a
difference
between
developer
related
things
or
what
developers
get
to
do
versus
what
or
self-service.
I
would
say.
That's
the
word
so
self-service.
Nothing!
Changes
on
that
front
right.
A
I
don't
see
anything
changing
developers
still
just
says:
hey
here's,
the
kind
of
access
I
want
by
specifying
a
service
account
name
or
leaving
it
empty
and.
E
A
A
Yeah
we
can
yeah,
that's
just
marshalling
yeah.
We
we
can
even
make
the
key
go
away.
F
E
D
A
A
I'm
not
hearing
any,
you
know
any
any
arguments
against
it,
so
I'm
gonna
assume
it
looks
good.
F
A
A
A
A
Okay,
we
can,
if,
if
this
is
all
it
is,
I
think
I
think
we're
in
consensus
we're
in
agreement.
We
can
go
update
the
cap
and
we
can.
We
can
reconvene
next
week
as
usual
and
we
can
actually
get
started
on.
B
A
Yeah
yeah
I'm
going
to
do
that,
so
it's
going
to
quickly!
Actually,
I'm
just
going
to
quickly
actually
update
the
cap
and
start
start
bringing
people.
A
B
A
Thanks
jing
all
right,
so
that's
all
from
me.
If
anyone
has
any
objections
or
any
thoughts
about
this
or
improvements,
just
put
it
on
slack,
we
will
continue
the
discussion
there.
Yeah
that's
about
it
thanks
everyone.
We
can
end
early
today.