►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 01 April 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
A
About
how
to
mutate
credentials
once
they're,
provisioned
and
actually
yesterday,
a
new
doubt
kind
of
came
up
in
my
mind
if
this
time
I'll
I'll
bring
that
up
as
well
and-
and
this
was
about-
you
know-
allowed
namespaces.
Actually
so
really,
the
question
is:
do
we
want
to
say
what
kind
of
access
allowed
per
name
space
rather
than
just
these?
Are
the
namespaces
where
you
can
access
this
bucket?
You
also
want
to
say
these
are
the
namespaces
you
can
access
bucket
in
these
specific
ways?
B
C
A
Yeah
because,
because
I
think
it's
it's
just
a
question
at
this
point,
I
think
we
should
discuss
and
see
see
how
it
goes.
I
I
want
to
understand
better
what
what
you
know,
how
important
that
is
and
what
that
might
look
like
another
question
that
was
brought
up
in
the
cap
review.
Also
it
was
interesting
anyway.
So
so,
let's
see
it's
ten
of
four:
let's
wait
one
more
minute
and
you
know
we'll
get
started.
A
D
A
A
A
So,
for
instance,
if
a
workload
has
been
deployed
with
a
bucket
and
a
bucket
access
has
been
created
for
it
and
the
credentials
have
been
mounted
into
the
part
and
it's
running
now,
as
this
is
happening,
the
admin
decides
for
whatever
reason
that
that
set
of
credentials
is
too
restrictive
or
too
constrictive
or
too
too.
You
know
too
expansive,
I
would
say,
and,
and
they
want
to
either
restrict
the
access
or,
or
you
know,
extend
it.
A
So
first
question
that
I
had
was:
is
this
a
use
case
that
that
needs
to
be
addressed
just
based
on
your
experiences
so
far,
and
now?
If
so,
can
we
address
it
by
simply
saying
the
admin
just
has
to
delete
the
workload
redeploy
it
with?
You
know
with
the
different
ba
with
the
different
bar
that
asks
for
different
credentials.
A
A
So
so,
let's
try
and
answer
this
question
of
does
any
so
we're
all
here,
because
you
know
we're
interested
in
object,
storage
or
we
work
with
a
part
of
a
vendor
that
that
builds
it
that
you
know
that
offers
objects.
There
is
as
a
solution.
So
in
your
experience
so
far
in
whatever
capacity
do
you
see
that
being
an
important
use
case?
Where,
for
a
working
workload
for
for
a
running
workload,
you
change
the
type
of
access
that
it
has.
A
E
So
I
guess
you
can
break
it
down
into
two
pieces.
One
is
whether
it
requires
a
new
bucket
access,
and
the
second
is
whether
it
requires
a
restart
of
the
workload
I
think
for
alpha.
A
restart
of
the
workload
is
not
a
bad
place
to
start
but
being
able
to
rotate
or
change
within
this
using
the
same
bucket
access
object,
I
think,
would
be
more
important.
A
A
So
so
we're
saying
this
is
a.
This
is
an
important
use
case
where
we
want
to
be
able
to
change
the
type
of
access
the
workload
has
as
it's
running
now.
The
second
question
is:
do
we
have
to
do
it?
You
know
without
restarting
the
workload
and
and
and
we're
saying
yes,
because
you
know
for
rotation
cases.
We
need
that
so
so,
yeah,
like
you
said
there
are
two
pieces
to
it.
A
So
I'm
thinking
this
through
if
we
were
to
implement
it,
just
the
way
secrets
implemented,
like
the
secrets,
are
monitored
into
parts
today
we
can
dynamically
update
them
the
the
problem
with
that,
though,
is
there's
no
guarantee
that
the
application,
that's
using.
The
credentials
is
going
to
is
going
to
use
the
is
the
new
set
of
credentials.
A
E
I
think
that's
the
same.
The
same
problem
that
exists
with
secrets
today,
secrets
allow
themselves
to
be
updated
when
they're
mounted
as
a
volume.
It's
not
necessarily
true
that
the
application
will
pick
it
up
right
and
that's
just
a
you
know,
that's
something
that
the
developer
needs
to
figure
out.
F
A
A
Right
right,
so
I
just
want
to
clarify
about
sts
first,
though
so
so
about
the
problem
of
rotation.
Saad
also
just
brought
it
up,
you
know
there
is,
you
know,
there's
always
an
expiry.
That's
set
up
front
while
requesting
the
credentials
right
now
we
we
ask
for
credentials
with
no
expiry
on
them
and
all
the
cloud
providers
support
it,
but
but
I
would
think
post
alpha.
That
is
right
after
we
reach
alpha.
A
I
think
I
think
this
is
something
we
should
address
where,
where
you
know
the
expiry
on
the
credentials
is
set,
you
know,
through
the
bucket
access
class,
probably
and
cozy,
automatically
rotates
the
credentials
for
you
and
either
invalidates
the
existing
credentials,
so
that
you,
you
know,
even
if
the
application
doesn't
pick
up
the
new
one.
You
know
it
starts
failing
it
starts.
Failing
to,
you
know,
have
access
to
object,
storage,
and
you
know
we
can
either
advise
the
applications
like
you
know.
A
We're
gonna
provide
sdks,
so
our
sdks
could
either
automatically
reload
or
we
could
we
could.
You
know
give
that
as
an
instruction
to
application
writers
saying
when
you
know
when
the
expiry
does
happen,
you
you'll
have
to
go,
and
you
know
start
using
the
new
credentials
and
the
third
mechanism
is
we
just
restart.
We
just
restart
the
pod
and
whenever
the
part
restarts
you
know,
it
ends
up
getting
new
credentials.
A
E
F
A
F
F
E
F
A
new
one,
so
at
some
point
in
time
a
book
of
texas
has
like
two
secrets,
even
though
the
first
one
is
the
eldest
is
about
to
be
invalidated
somehow
or
will
invalidate
automatically,
but
there
seems
to
be
no
way
to
store
this
and
and
if
the
secret
invalid,
the
first
secret
invalidation
fails.
Well,
then
we
would
need
to
retry
later
and
that
kind
of
stuff.
A
I
see
what
you
mean,
I
mean
we
can
still
make
do
with
one
secret
call
it.
You
know
it's
like
a
it's
like
an
alternating
secret.
Let's
say
it
has
two
fields,
something
like
blue
and
green,
and
you
start
with
blue,
and
you
know
you
have
a
field
saying
blue
is
the
current
active
one
and
then,
when
you
rotate
you,
you
know
you
change
it
to
green
and
every
time
the
secret
changes
we
or
every
time
we
go
and
update
the
secret
we
trigger.
F
A
Oh,
I
see
I
see
so
so
I
mean
we.
Could
I
see
the
problem
you're
saying
so
you're
saying
if
the
existing
secret
is
invalidated.
First,
then,
you
know
there
is
a
possibility
that
there's
an
extended
period
of
time
where
the
new
secrets
are
not
validated
yet,
and
you
know
the
workload
could
go
without
access
for
a
long
time
if
it's
invalidated.
Second,
if
the
existing
sequence
environment.
A
F
Yes
sure
I
just
I
think
my
it
was
a
bit
simpler,
but
just
today
I
see
a
one-on-one
mapping
of
a
secret
as
known
from
the
object
storage
system
to
a
bucket
access
and
we'll
need
to
move
beyond
that
and
the
agreement
you
mentioned
you
you
you
explained
before
could
indeed
be
a
solution,
but
right
now
we
don't
have
any.
We
don't
have
the
concept
of
one
bucket
access
maps
to
multiple
object,
storage
secrets,
so
you
want
at
the
same
time.
A
G
A
Right
right,
right,
yeah,
so
generally
like
the
way
we
do,
it
is
say
you
know
you
get,
you
get
credentials
say
at
8
a.m
one
morning
and
you
get
it
for
either
like
something
like
25
hours
until
24,
the
idea
being
well
that
that's
more
meant
for,
like
actual
like
real
users,
like
you
know,
people
tokens
the
idea
being.
You
know
you
come
to
office
again
at
8
a.m
in
the
morning
and
you
don't
want
it
to
have
expired
already.
A
You
want
to
have
that
one
hour
interval
where,
when
you,
when
you
log
in
it
it
refreshes
or
it
rotates
so
that's
kind
of
how
you
know
we
do
it.
So
in
this
case
too,
what
we'll
have
to
do?
Is
you
know?
We
don't
need
that
that
plus
one
r
thing,
but
let's
say
we
we
set
the
you
know
we
should
allow
the
users
to
set
how
the
duration
of
the
expiry.
G
A
A
Okay,
so
I'm
gonna
take
that
as
this
sounds
good
so
far.
Hey.
Can
someone
remind
me
of
what
we
talked
about
last
week
or
on
monday,
because
one
of
the
decisions
we
came
to
and
one
of
the
key
pieces
that
we
had
to
do
in
order
to
make
this
happen
was
was
the
idea
of
taking
you
know,
putting
the
actual
policies
from
the
bucket
access
class
or
taking
it
away
from
from
from
the
conflict
map
which
we
have
today.
A
So
currently,
the
bucket
access
class
has
a
pointer
to
a
config
map
and
that
contract
map
is
supposed
to
call
the
actual
policy,
but
we
said
in
order
to
solve
the
problem
that
we
were
solving,
and
I
think
I
remember
it
now
that
that
policy
actions,
conflict
map
cannot
work
and
instead
we
should
have
the
policy
actions
inside
of
the
bucket
access
class
itself
and
jeff.
I
believe
we
had
a
discussion
about
it
after
the
call
also
right.
A
C
Yeah,
I
mean
one
of
the
questions
that
was
asked,
I
believe,
was
if
someone
changes
the
config
map,
because
they
are
immutable
and
they
change
an
access
policy.
What
the?
What
if
anything,
does
cozy
do
about
it?
You
know
we're
not
doing
a
watch
on
config
maps
right
now,
so
cozy
wouldn't
know
about
it,
but
but
should
we
and
if
we
did
detect
a
change
in
a
config
map
that
was
tied
to
a
bucket
access
class?
What
would
we
do,
and
so
it
was
an
area
we
hadn't.
C
C
A
Yeah,
it
doesn't
matter
to
me
as
long
as
you
can
get
the
original
data
back.
That's
what
you're
talking
about
right
encoding!
That's
what
you
said
right
right,
okay,
so
going
back
to
so
going
back
to
what
you
were
talking
about.
So
it
seems
like
there
are.
There
are
two
reasons
why
the
credentials
will
change.
A
One
is
a
regular
part
of
its
operations
where
you
need
to
rotate
the
sequence
or
rotate
the
credentials,
and
two
is
you
know,
a
manual
intervention
by
an
admin
saying
the
type
of
access
here
should
change.
So
let's
say
we
have.
I
mean,
based
on
our
discussion.
So
far,
it
seems
like
there
is.
There
is
a
pretty
clear
path
to
a
love
rotations,
just
technically
speaking
in
terms
of
plan
we
will
get
that
later.
A
C
C
Well,
this
has
come
up
recently
in
a
cap
review
by
sebastian
is
there
is
no
co,
the
user
has
no
say
in
any
of
this
in
cozy
today
there
yeah,
br,
doesn't
say
anything
and
the
bar
doesn't
say
anything:
they
they
both
reference
a
class
resource
and
the
class
which
is
admin
controlled.
It
defines
access,
it
defines
bucket
properties
and
so
on.
The
user
doesn't
do
anything.
Today,
it's
not
very
different
from
pvcs
and
pvs
right.
E
A
C
It
seems
so
to
me
it's
it's
consistent
with
the
cap
unless
we
want
to
start
discussions
about
some
balance
between
the
control
of
a
user
and
an
admin.
Today,
it's
like,
I
said
it's
all
100
admin,
and
so
with
that
in
mind
it,
what
you
just
asked
makes
sense
that
it
would
be
admin
only
because
we're
not
letting
the
user
do
anything.
B
E
E
C
A
Doesn't
this
apply
to
all
you
know
in
general
itself,
for
instance,
so
sad
you're
saying
that
if
a
user,
if
a
user
is
the
one
that
choose
what
kind
of
access
needed
and
if
we
go
behind
the
user's
back
and
without
even
informing
them,
we
go
and
update
the
type
of
access.
The
workload
has
that's
weird:
that's
what
you're
saying
right.
E
I
guess
what
I'm
saying
is:
if
you
know
rotation
needs
to
happen,
and
it
requires
admin
to
do
something
and
kind
of
the
user
user.
Can
provision
access
themselves
but
then
becomes
dependent
on
admin,
input
or
rotation.
That
seems
like
it's
kind
of
switching
right.
It's
going
from
the
user
can
mint
access
themselves,
but
then
they
are
dependent
on
the
cluster
admin
to
to
do
their
rotation.
At
a
later
point,.
A
C
B
A
So
let's
say
you
know,
the
admin
has
decided,
or
you
know
the
all
the
different
policies
they
have
do
not
allow
deletion
of
objects.
So
so
let's
say
there
are
five
policies.
One
is
read,
write.
One
is
right
only
and
and
three
more
so
so,
let's
say
the
user
starts
with
right,
only
but
then
later
on,
realizes
that
they
need
rewrite.
A
So
the
user
should
just
be
able
to
go
to
the
bucket
access
request
and
update
the
bucket
access
class
to
point
to
a
different
class
that
has
a
read,
write,
access
and,
and
that
should
that
should
start
a
cascade
of
changes
that
ends
up
creating
either
new
credentials
or
updating
access
for
the
existing
credentials.
That's
already
in
in
the
in
the
pod.
G
D
A
G
D
Things
are
not
allowing
to
change
the
car
for
being
instantiated,
and
so,
if,
if
what
we
said
that
the
update
would
be
to
you
know
the
top
level
field
of
the
access
request,
saying
I
wouldn't
want
read
only
right,
that's
one
thing,
but
what
we're
saying
is:
let's
update
the
class,
I
think
this
is
kind
of
well.
I
just
don't
know
of
any
pattern
like
that
today.
Right
most
of
these
things
do
not
update
the
crack
after,
but
we're.
D
E
A
D
Right
so
I'm
trying
to
follow
the
example
you
gave
right,
which
is
the
the
user
in
our
case,
would
like
to
signal
cozy
that
it
wants
to
live
right,
which
is,
I
want
to
change
from,
read,
write
to
read
only
and
it's
it's
an
easy
decision
in
that
case,
not
an
admin
to
update
the
workload.
That's
right,
and
in
that
case
we're
asking
how
do
how
does
the
user
manage
that
right?
D
Right
so
yeah
yeah
makes
sense.
Do
we
have
do
we
have
any
just
to
making
sure
does?
Does
it
allow
that
default
templates
will
allow
updating
the
bucket
access
request
reference?
So
if
I
have
existing
photos
within
a
deployment
and
then
update
the
deployment,
however,
to
have
a
different
backup
access
request.
A
D
D
A
A
G
D
D
E
D
But
then
what
we're
saying
is
that,
if,
if
that's
the
desire
of
the
admin
to
provide
such
a
policy
right,
then
there
it
is
to
update
the
bucket
itself
with
green
blue.
Whatever
we
said
what
we
started
with
in
this
section
of
the
discussion,
I
think,
was
what
does
the
user
trigger
that
requires
refresh
of
the
access.
D
You
know
rotating
keys,
making
updates
to
bucket
access,
not
that
every
night
like
you're
suggesting
right
and
then
all
the
cozy
applications
will
reread
from
from
the
updated
secrets,
the
updated
volume.
That's
that's
possible
and
nothing
to
change
that.
I
think
that's
what
should
work,
but
the
question
is:
do
do
we
need
any
similar
capability
for
the
user
to
make
such
an
update
to
the
bucket
access.
D
I
think
the
point
is
this
change
in
the
bucket
access
request.
If
it
it's
going
to
change
a
reference
to
the
class
here,
the
the
the
entire
you
know,
immutability
and
model
of
having
an
instance
from
a
class
and
knowing
what
that
is,
it's
it's
a
different
model
from
most
of
the
other
objects.
We
are
resources.
We
we
know
from
from
kubernetes.
A
A
D
So
if
we
really
want
the
bucket
request
to
have
a
top
level
capability
for
your
users
to
make
changes
like
read
only
versus
it,
it
does
make
sense
right
so
that
the
user
can
make
updates
to
that
top-level
request
field
and
get
you
know,
approval
or
you
know,
rejected,
or
for
the
request-
change
that
that
makes
updating
the
class
to
make.
That
change,
then
relying
on
an
admin
to
provide
a
different
class
so
that
I
can
toggle
between.
D
D
D
A
A
Does
it
make
sense?
So
that's,
that's
the
that's
the
first
part,
that's
that's
where
no
no
user
or
admin
intervention
is
needed
automatically.
We
refresh
the
tokens
as
they
expire,
that's
kind
of
how
you
know
pretty
much.
Every
kind
of
token
based
access
works
like
even
with
oauth
you
you
go
and
request
a
token.
You
get
it
through
that
multi-step
oauth
process
and
it's
only
valid
for
a
certain
amount
of
time
and
before
that
time
expires.
A
A
A
The
other
way
is
to
restart
the
pod.
If
we
forcibly
restart
the
part
when
it
comes
back
up,
it'll
come
back
up
with
the
new
tokens
alone,
and
you
know
when
the
new
tokens
are
loaded.
It
will
just
start
you'll
just
have
the
new
token.
I
don't
like
that
approach,
because
then
every
expiry
period,
your
you
know,
part,
will
restart.
F
There's
a
problem
with
both
using
that
sdk
at
the
previous
solution,
as
the
in
so
far
that
the
same
token
will
be
shared
by
multiple
pods
right,
yeah
yeah.
All
the
pods
will
will
update
the
tokens
and
wait
the
talk
well,
okay,
which
means
that
a
bunch
of
replicas
of
the
same
pod
say
under
a
deployment
controller
may
crash
and
stop
themselves
to
be
restarted.
A
A
F
A
H
H
H
F
A
A
Yeah
yeah,
so
so
the
question
still
remains
so
actually
based
on
what
guy
was
saying
about
blue
and
green.
I
think
it's
he's
right
in
that
we
don't
invalidate.
Let's
say
we
start
with
blue
and
then
we
upgrade
to
green
or
we
change
the
you
know
we
refresh
to
green.
There
should
be
a
point
in
time
where
both
are
active
right,
which
are
valid.
Yes,
we
if
we
do
it
that
way,
then
we
avoid
this
part
crashing
scenario.
H
F
Yes,
but
we
would
still
need
to
make
sure
that
the
various
pods
that
consume
the
ba
don't
decide
to
restart
themselves
at
roughly
the
same
point
in
time.
No
we're
saying
there
won't
be
that
kind
of
restart.
Due
to
error.
You
mean
due
to
permission
error.
No,
if
you
have
an
application
which
is
unable
to
reload
the
authentication
credentials,
it
reads
them
at
startup.
H
D
F
Well,
so
the
problem
now
is
that
either
and
we
have
multiple
instances
of
this
of
this
pulled
running
and
they're
all.
Using
the
same
token,
then,
if,
if
a
token
expires,
I
mean,
if
we
wait
for
it,
if
sorry,
we
recreate
a
new
token
behind
the
scenes
and
we
remap
that
new
token
into
the
file
system,
as
observed
by
the
pod
somehow,
but
the
application
doesn't
see
that
new
token,
then
at
some
point
in
time
the
the
old
token
is
invalid
and
all
instances
of
that
application
now
error
out
and
need
to
be
restarted.
A
F
A
A
I
I
think,
no,
that
I
think
that's
that
see
sometimes
adding
that
intelligence.
You
know,
turns
out
to
be
counterproductive
because
one
we're
not
solving
all
use
cases
and
two.
They
regardless
have
to
update
the
application
by
adding
this
complexity,
we're
actually
just
shooting
ourselves
in
the
foot,
because
what
why
do
they
need
to
update
the
application
in
order
to
in
order
to
work
with?
You
know,
refreshing
credentials.
H
I
have
a
suggestion,
maybe
when,
when
our,
when
we
specify
for
a
pod
right
the
volume
that
it
mounts
the
cozy
volume
for
credentials,
perhaps
we
can
we
we
can.
You
know
mark
that
volume
when
it
mounts
it,
whether
that
pod
will,
you
know,
need
to
be
recreated
when
the
volume
so
say.
Maybe
the
mount
is
read
only
maybe
something
like
that
right.
Just
saying,
if
I,
if
I
mount
this
as
read
only,
I
expect
to
be
restarted
when
the
change
happens,
because
I
cannot
expect
anything
else.
A
I
don't
I
don't
think
see,
so
we
should
not
be
solving
problems
at
that
level.
Yet
so
so
so,
if
you
know,
because
if
we
get
into
that
business
of
staggering
restarts
based
on
based
on
you
know
for
refresh
tokens,
it
actually
doesn't
guarantee
that
things
will
work.
Fine.
You
know
just
because
you
restart
at
different
points
in
time.
A
I
think
for
refreshing
we
shouldn't
even
be
restarting
the
pods,
for
instance,
like
the
workloads
using
the
bucket
may
not
even
be
ones
that
that
are
that
work
well
for
restarts
and
we're
making
the
assumption
that
all
the
state
is
in
object.
Storage.
Nothing
is
local
for
this
restart
methodology
to
even
work
yeah,
so
this
is
an
actual.
A
So
this
is
an
actual
problem
that
you
know
we
when
I
was
at
rancho
labs,
we
solved
for
coinbase
coinbase
was
using
a
particular
linux
source
that
every
time
there
was
there
was
a
there
was
an
upgrade
to
there's
an
automated
upgrade.
You
know
every
few
days
and
coinbase
couldn't
even
prevent
things
from
restarting.
A
F
A
That's
what
we're
saying
exactly
so
so,
if
you,
if
you
don't
want
to
have
automated
restarts,
I
mean
in
the
sense
as
much
as
possible.
We
should
we
should.
We
should
completely
avoid
automated
restarts
and
and
if
you
don't
want
to
have
them
for
your
current
applications,
don't
ask
for
credentials
that
have
they
have
this
refresh
tokens.
A
All
right
without
time,
I
have
a
meeting
at
11,
but
I
think
we
should
continue
this
discussion.
I
don't
think
we've
we've
come
to
a
conclusion
yet,
but
that's
okay!
So
next
week
what
I'll
do
on
monday
we're
going
to
have
our
office
hours
again,
so
I'm
going
to
be
doing
a
demo
at
that
point
and
before
that,
though
I'll
bring
up
this
topic
I'll
I'll
have
some
diagrams
drawn
up
for
this.
So
so
it's
a
little
easier
to
follow
and
understand
and
then
we'll
go
from
there.