►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Review Meeting - 08 April 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
B
A
Of
where
it
came
to
to
be
a
part
of
the
credential
information,
I
was
going
to
mention
that.
C
Specifically
so,
yes,
the
the
the
part
that
leads
the
credential,
the
workload
that
reads
the
credential
pretty
much.
I
know
this
about
the
aws
s3
clients.
They
have
a
concept
of
expiry.
So
if
we
were
to
present,
you
know
an
expiry
time,
the
the
workload
can
be
ready
for
the
expiry
to
happen
in
in
general,
though
aws
clients
do
the
refresh
themselves
now,
in
our
case,
we'll
be
asking,
you
know,
we'll
be
doing
it
for
it.
C
Well,
well
I
mean
what
I'm
trying
to
say
is
okay,
so
I
need
to
look
this
up
so
so,
whoever
has
the
credentials
basically
is
authenticated
as
that
user
and
they
by
default,
have
permissions
to
refresh
it
with.
C
A
Depending
if
it's
an
iam
api,
for
example,
they
won't
have
access.
Yes
right,
I
mean
we
can
include
an
an
iam
api,
but
then
it's
kind
of
out
of
the
scope
of
what
we're
trying
to
achieve
here
in
terms
of
providing
rest
apis
for
that
right.
But
I
I.
C
No
we're
saying
it's
a
bad
idea,
so
so
yeah
yeah
we're
coming
up
with
you
know.
We
were
just
talking
about
how
clients
themselves,
whoever
is
accessing
the
data,
can
actually
go
ahead
and
you
know
refresh
the
tokens
that
they
have,
but
but
in
order
to
make
that
happen,
they'll
need
access
to
the
iam
api
to
the
backend
iam
api,
and
you
know
short
of
that.
What
we
can
do
is
we
can
provide
an
iem
api
that
they
can
call.
C
But
if
you
were
to
go
down
that
road
you're
actually
providing
things
that
you
shouldn't,
be
it
yeah,
it
will
become
technical
that
very
soon
if
you
go
down
that
road.
So
that's
what
we
were
talking
about.
Yeah.
A
And
I
think
we
do
have
you
know
credential
minting
in
that
like
in
cozy,
it's
it's
already
there
right
and
the
the
missing
piece
or
the
missing
link
here
is
the
is
the
refresh
and
I
think,
each
component,
because
we
have
like
these
components,
stacked
together.
Each
component
knows
exactly
how
to
refresh
from
from
the
one
that
provided
to
him
right.
So
so
the
pod
will
just
need
to
refresh
from
the
file.
A
A
It
needs
to
understand
that
it
needs
to
wake
up
at
some
point
in
time,
which
is
the
expiry
time
and
from
that
point
to
you
know,
attempt
to
refresh
and
same
thing
for
the
node
adapter
and
same
thing
for
the
controller,
which
will
you
know,
set
the
ba
set
set
this
in
in
the
ba
and
will
ask
from
the
sidecar
this
information
and
same
for
the
sidecar.
A
Maybe
so
it
can
be
really
something
that
if
it's
part
of
the
information,
it's
pretty
easy
to
to
understand
and
then
the
last
question
or
the
first
question
I
asked
was:
how
much
are
we
you
know
assuming
how
much
can
we
assume
that
you
know
an
expiry
time,
which
is
like
a
wall
clock
right
with
something
you
cannot
use
a
duration
because
duration
is
doesn't
mean
anything
for
expiry.
A
You
have
to
put
some
wall
wall
clock
there,
so
the
question
is:
can
can
this
work
in
in
kubernetes
environments
and
I'm
not
too
knowledgeable
about
how
much
is
kubernetes,
assuming
at
least
you
know
that
it's
not
completely
off
sync
right.
D
Why
can't
you
just
set
the
duration?
What's
the
rationale
for
that.
A
Because
if
you
so,
let's
assume
you
put
a
duration
on
it,
then
what
does
it
mean
for
somebody
reading
the
credentials
when
this?
When,
when
to
refresh
you
can
say
that
the
duration
is
the
refresh
duration,
but
then
like
say
say
that
I
I've
put
a
year
for
just
just
for
the
sake
of
the
example,
then
what
does
it
mean?
I
need
to
refresh
once
a
year.
Is
that
the
the
the
the.
C
Let's
say
it's
60
minutes
or
one
hour,
then
let's
say
the
controller
goes
down
and
comes
back
up.
The
controller
could
have
come
back
up.
You
know
after
60
minutes
before
60
minutes
you
wouldn't
know,
but
when
it
goes
and
reads
the
file
or
when
it
goes
and
reads
the
resource,
it's
still
going
to
see
60
minutes.
C
So
so
duration
is
not.
You
know,
there's
no
way
to
make
that
happen
like
like
understand
what
it
is.
The
expiry
time
is
so.
D
Just
just
for
information
most
of
the
apis
today
to
specify
expiration
is
the
duration.
C
C
Should
we
make
it
a
spec
field
where
we
say
this
ba
has
to
be,
you
know,
has
to
have
a
refresh
duration
of
so.
A
C
Know
this
for
the
so
let
me
let
me
pull
up
some
code.
I
know
that
you
know
time
based
things
are
done
in
kubernetes,
especially
in
checking
how
you
know
checking
how
if
a
node
went
down
or
not
so
let's
see,
I
remember
in
the
note
controller
we
had
this,
so
so
what
it
does
is
it
waits
for
you
know,
node.
You
know
reslink
period.
C
I
think
it's
like
30
seconds
or
something
or
maybe
one
minute,
and
if
three,
if
three
times
the
recent
period
amount
of
time,
there's
no
there's
no
updates
from
the
node,
then
we
assume
that
the
node
has
gone
down.
So
you
know
we.
I
want
to
look
into
how
they
take
care
of
time
there.
So
node
life
cycle,
not
life
signal
controller.
A
There
it
is
okay.
Is
this
a
controller?
Is
this
like
running
as
a
single
controller?
Yes,
the
part
of
the
core
controller
manager
right,
but
then
so
just
to,
I
think,
there's
maybe
an
easy
way
in
this
case,
because
if
it's
a
single
controller,
it's
less
likely
to
it's,
you
know
to
pass
this
time
around
between
nodes
right
can.
A
Do
you
see
what
I'm
saying
yeah,
I
see
what
you're
saying?
Yes,
yes,
so
I'm
not
saying
it!
It
necessarily
makes
the
the
argument.
You
know
not
not
enough
for,
for
you
know,
claiming
yeah.
C
I
see
so
I'll.
Tell
you
what
I'm
looking
for
here.
I'm
I'm
looking
for
assumptions
that
they've
made
in
this
code.
Basically,
what
I'm
looking
for
is
they
check
the
last
updated
timestamp
on
the
node
object
and
then
they
check
that
with
the
current
time
I
see
okay.
So
that's
what
I'm
looking
for
so
so,
if
they've
made
that
assumption,
if
there
is
assumptions
like
that
already
in
kubernetes,
assuming
that
the
clocks
are
reasonably
in
sync,
maybe
you
know,
I
think
the
allowed
amount
of
drift
is
one.
C
I
don't
know
two
seconds
I
don't
know
for
for
tls.
So
so
so
you
know
if
there
is
an
assumption
here
that
the
clocks
are
in
sync,
then
we
should
be
okay.
We.
A
Should
make
the
lessons
and
our
like
our
use
case-
is
not
about
having
very,
very
strict
timing
right,
it's
mainly
about
just
having
rotation
aware,
or
you
know,
refresh
aware
times.
D
Right,
what
about
you
know
not
managing
time
at
all
and
just
refreshing
when
something
so,
for
instance,
yeah,
there
is
a
credential
error
and
we
first
refresh
so
basically,
we
force
minting
your
new
token.
A
D
A
So
so
we
did
discuss
that
that
restarting
pods
would
make
sense
for
revoking
access,
something
which
doesn't
fit
into
the
you
know,
rotation
use
case
because
the
rotation
which
is
more
of
a
planned
activity,
at
least
in
terms
of
design,
not
not
in
terms
of
reality.
So,
like
you
say
it
might
be,
that
to
begin
with,
many
of
the
applications
do
not
support
this.
A
To
you
know
to
even
reload
whatever
we
do
on
top
will
not
help
right,
but
but
on
the
other
hand,
if,
if
we
are
trying
to
even
provide
a
rotation
mechanism,
then
restarting
pods
on
every
rotation
event
was
was
discouraged
a
little
bit
within
the
at
least
in
previous
discussions.
C
Okay,
so
here's
one
more
thing,
so
what
what
note
controller
does
is
not
it
doesn't
check
for
current
time
versus
last
observed
time.
C
It
rather
has
a
you
know,
an
an
in
process,
data
structure
of
the
current
list
of
nodes
and
it
refreshes
this
every
node
monitor
period
and
and
then
it
checks
if
it
wasn't
able
to
reach
it,
for
you
know
three
different
periods
in
in
succession,
so
maybe
we
can
do
something
like
this
too,
where
we
have
a
you
know,
access
monitor
period
or
something
and
and
we
periodically
check,
we
can
even
call
the
driver
to
periodically
check
hey.
Is
this
still
valid
and
we
don't
have
to
do
any
timing
things.
A
C
D
Yeah
going
back
to
the
do,
you
know,
what's
the
use
case
for
for
cozy
and
what
are
the
apps
which
are
going
to
use
cozy
I
mean:
do
you
have
an
idea.
D
Yeah
but
it
will
be,
I
don't
know
people
doing.
A
D
C
A
C
Yeah
yeah,
I'm
just
using
like
a
platform
kind
of
thing,
but
I'll
tell
you
what
are
the
most
common
use
cases
for
for
lunaio
customers?
Many
of
them
are,
or
you
know
the
majority
of
it
is.
You
know,
big
data
workloads
and
these
these
workloads.
The
way
they
look
like
is
for
each
work.
C
They
have
a
central,
large
data
store,
say
s3
or
mini
or
whatever,
and
each
team
does
one
part
of
the
data
management
life
cycle
either
bringing
in
data
transforming
it
or
you
know,
querying
it
or
whatever,
and
each
team
gets
their
own
access
to
the
data
or
portions
of
the
data,
so
like
say,
specific
buckets,
so
so
you,
you
could
reasonably
say
for
for
every
micro
service
that
one
team
runs
and
things
are
moving
to
a
micro
service
architecture.
D
D
No,
no,
no,
I'm
saying
the
opposite.
Okay!
So
generally
so
the
people
in
charge
of
securities.
You
know
they
don't
like
karma
and
control
right
like
they
don't
like
giving
you
a
key
forever
and
in
worst
case
they
will
delete
the
key.
So,
for
instance,
if
they
see
a
key
sticking
around
for,
like
oh
yeah,.
D
They
will
delete
it,
so
the
goal
is
to
to
provide
the
mechanism
to
pre-order.
Primitively
say
it's.
Okay,
you
specify
you
need
the
key
for
one
month,
so
you
get
the
key
for
one
month
or
one
day
or
two
days.
I
don't
think
it's
it's
supposed
to
be.
I
mean,
I
don't
think
it's
practical.
If
you
ask
a
key
for
I
see
one
minute.
C
Oh
no,
so
so
yeah
I
see
what
you
mean
so
yeah.
I
see
what
you
mean,
you're
saying
it's,
it's
kind
of
ridiculous
to
constantly
check
if
the
key
is
active
or
not
right
kind
of
yeah,
I
see
what
you
mean,
yeah,
no,
that's
fair!
That's
totally
fair!
I
think
we
were
also
saying
the
same
thing.
That's
one
reason,
because
you
know
it's
very
unlikely
that
you
know
you
need
to
constantly
check
if
it's
valid
or
not-
and
it's
probably
very
expensive.
C
Also,
that's
the
part
we
were
getting
to
tell
me:
yeah
yeah,
no
okay,
yeah.
D
So
we
should
ideally
it's
a
work
session.
The
work
is,
I
think,
it's
one
day
so.
D
But,
typically
for
big
data
workloads
when
you
start
a
project,
it's
one
month.
C
C
We
we
could
say
you
know
tokens,
they
don't
come
with
credential
rotation
and-
and
you
know
there
is
other
risks
associated
with
using
actual
tokens,
and
we
could
say
you
know
they
should
only
use
iam
if
they
want
more
security,
because,
if
you're
using
iam,
where
a
service
account
associated
with
the
pod,
you
know
it
has
has,
is
given
access
to
object,
storage
in
that
case,
you
know,
there's
no
token,
so
nothing
can
be
leaked
and
you
know
we
don't
have
like
like
we.
C
We
can.
We
can
enforce
rotation
much
more
easily.
You
know
that
might
be,
and
you
you
don't
really
need
rotation
at
that
point.
D
A
D
D
C
Well,
st
is
also
yeah
sts.
St
is
a
little
more
restrictive.
Sts
stands
for
single
or
simple
token
service
in
amazon.
What
it
gives
you
is
a
single
token
that
you
can
use
with
very
specific
types
of
credentials.
Yeah.
D
So
but
but
that's
that
that's
the
point
of
the
driver,
so,
for
instance,
I
I
can
totally
return
you
an
sts
token,
so
triplet
access,
key
secret
ksts
bound
to
a
row,
so
there
is
no
actual
identity
behind
it's
just
a
tempo
standpoint
access
and
that
that's
actually
what
I
want
to
do,
because
I
don't
want
to
give
you
full
access.
You
know.
So.
The
first
point
is
the
trend
of
giving
full
access
like
static
keys
is
disappearing
in
the
industry.
D
Yes,
if
you're
maintaining
dynamic
credentials.
Basically
it's
a
program,
automated
program,
delivering
a
credentials
to
another
program.
Then
it
has
to
be
temporary
right.
It
can
be
agreed
yeah.
So
in
the
ba
in
the
back
for
sure
the
driver,
the
driver
provider,
they
will
probably
deliver
temporary
credentials
anyways
right.
C
You
this
is
it
possible
to
I
I
I'm
not
sure
about
this.
Is
it
possible
to
create
tokens
that
is
access
screen
secret
key
with
an
expiry.
D
No
so
so,
for
instance,
in
our
driver
we
are
going
to
mint
temporary
current
source,
so
we
will
return
a
triplet
access,
key
circuit,
key
sts,
part
of
the
credentials
blob,
which
should
be
mounted
in
the
pod
and
the
pod.
I
took
us
to
basically
read
the
triplet
and.
C
But
let
me
ask
you
just
more
generically
without
cozy
in
mind:
let's
take
amazon,
can
you
create
access
key
and
secret
key
in
amazon
for
a
particular
identity
such
that
the
access
key
and
secret
key
have
an
expiry
on
them?.
C
Only
way
yeah
understood,
okay,
so
that's
a
really
good
point.
You've
brought
up
then
that
changes
a
lot
of
things.
So
I.
D
So
so
the
thing
is,
pods
will
fail,
the
culture
will
be
expired
and
and
will
and
will
crash
and
the
application
will
stop.
That's
that's.
That
will
happen
yeah.
So
we
simply
find
a
way
to.
I
don't
know
to
refresh.
C
I
still
think
you
know,
okay,
so
I'll
tell
you
why
I
said
a
lot
of
things
changes
because
it
brings
me
back
to
this
whole
idea
of
we
shouldn't
be
doing
any
credential
rotation
for
access
key
secret,
key
style
of
access,
because,
just
like
you
said
there
are
multiple
problems
associated
with
it.
One
is,
let's
say
we
make
new
tokens.
C
You
know
we
come
up
with
this
concept
of
expiry
where
we
go
and
manually
delete
them.
You
know,
with
the
automated
controller
we
go
and
delete
the
keys
after
the
expiry
the
the
problem
there
is,
you
know
you
have
to
coordinate
the
deletion
and
the
creation
of
new
keys
to
run
together.
Now,
let's
say
you
create
the
new
keys
first
and
then
delete
them.
In
that
case,
you
end
up
creating
the
new
keys
and
there
is
a
possibility
that
you
know
the
controller
goes
down
right
after
you
create
them.
B
E
B
F
B
C
Deal
with
that,
I
see
all
right.
So,
let's,
let's
do
this.
I
think
I
think
one
of
the
things
that
I'm
missing
is
what
are
the
different
styles
of
access
for.
Just
take
the
major
object,
storage,
vendors,
let's
take
microsoft,
google
and
amazon
s3
and
we'll
do
some
background
research
and
understand
how
they
do
expiry
and
rotation
and
let's
continue
the
conversation
on
monday,
because
when
vyani
just
brought
this
up
it
it.
C
D
B
B
You
know
around
that
time
did
the
credential
change
and
then,
if
it
did,
there's
got
to
be
some
way
to
obtain
the
new
one
and
you
know
somehow
propagated
to
the
consumers
of
it,
so
that
if
a
pod
outlives,
the
actual
expiration
date
of
you
know,
so
you
imagine
you
have
a
token
good
for
30
days
at
around
20
days.
It's
time
to
refresh
it.
B
So
at
some
point
you
want
to
yeah,
give
them
give
them
the
new
credential,
but
but
like
a
driver
could
say
you
know
what
I
my
credentials
good,
forever
or
or
or
every
time
you
do
a
refresh.
It
could
just
give
you
back
the
same.
The
same
key
and
say:
nope
didn't
change
nope.
It
didn't
change.
C
B
B
B
Date,
you
go
do
the
refresh
and
then
once
the
refresh
is
done,
you
update
another
timestamp
saying
I
did
the
refresh
and
then,
if,
if
anything
goes
wrong
in
the
middle
you
just
next
time,
the
controller
comes
up.
It'll
start
work
at
the
top
of
its
queue
and
get
back
to
that
one,
because
it's
not
marked
as
being
done
yet.
D
Now
the
whole
the
whole
point
of
using
tokens
with
expiration
is
that
you
don't
care
if
you,
if
you
leak
tokens
because
they
will
expire.
D
B
Yeah
and-
and
I
I
like
I
like
the
idea
of
not
trying
to
implement
anything,
fancy
and
cozy
and
say,
look
cozy,
doesn't
know
what's
going
on
below
because
he's
just
gonna,
you
know,
ask
the
driver
to
give
it
the
most
up-to-date
value
for
a
given
access
token
and
with
the
understanding
that
it
will.
It
might
change
over
time.
D
D
The
driver
will
expire
the
key
in
one
month
and
you
can
work
and
after
one
month,
if
somebody
tries
to
run
the
job
or
whatever
to
do
whatever
to
run
the
project,
it
will
fail,
because
the
cleanup
should
be
expired
and
that's
fine,
because
in
the
initial
specification
of
the
project
it
was
supposed
to
to
last
one
month
and
then
what
you
do.
Is
you
change?
D
So
you
restart
the
whole
deployment
you
you
ask
another
key,
you
know,
but
so
that's
that
for
sure
that's
most
of
the
use
cases,
but
there
will
be
also
some
use
cases
where,
for
some
reason
you
don't
want
to
crash
the
whole
thing
for,
for
some
reason
you
want
to
extend
the
duration
of
the
project.
D
Project
is
supposed
to
be
one
month
and
you
have
all
the
data
in
place
and
all
and
you
need
to
have
one
more
month
to
finish
so
in
this
case,
it
would
be
interesting
to
to
refresh
the
token
the
existing
kind
of
shots.
B
D
Need
it
yeah,
it
might
be
interesting
to
automatically
refresh
tattoo.
If
somebody
wants
to
refresh
the
credentials,
then
they
are
propagated
back
to
the
pod
without
any
disruption
like
without
any.
F
E
C
We're
out
of
time,
let's
continue
on
monday,
it's
it's
getting
more
interesting.
This
is
good
in
the
meantime,
what
what
I'll
do
or
if,
if
you
also
can
do
some
research
on
this
will
be
good,
we'll
go
look
into
the
major
cloud
providers
and
and
your
own
object
storage
systems
to
see
what
kind
of
access
mechanisms
you
have
and
what
kind
of
expiry
mechanisms
you
have.
B
B
C
He's
still
involved
he's
just
he
just
changed
jobs,
so
he's
been
a
little
busy
lately,
but
yes,
so
ben
I'm
happy
to
join
as
well.
But
if
not
yeah
I'll
I'll
I'll
talk
to
you
I'll,
let
you
know
whatever
you
need
to
give
it
is
that
on
thursdays,
or
is
that
you
do
you
mind.
C
Every
other
thursday,
right
before
this
meeting,
okay,
all
right,
okay,
yeah!
If
I
can't
make
it
I'll
I'll,
let
you
know
and
if
not,
if
not
you
know,
I
might
as
well
come
and
give
an
update,
that's
cool
all
right.
Thanks
for
letting
us
know,
ben.