►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 05 August 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
And
similar
to
that
another
requirement
that
you
know
so
they
don't
want
to
use
access,
keys
and
secret
keys
whatsoever
for
for
talking
to
a
service.
They
only
want
to
use
sds
style
access.
A
I
know
we
briefly
touched
upon
this
last
week,
but
yeah
it's
been
on
my
mind
throughout
this
week.
I
think
I
think,
might
be
worth
bringing
it
up
today,
just
a
little
bit
before
that
before
we
get
into
that.
A
I
want
to
give
a
quick
update
on
the
camp,
so
we
we've
had
a
good
amount
of
feedback
on
the
cap
from
from
you
know,
cozy
members
itself,
and
you
know
I
think
it
I
think
it's
in
pretty
good
shape
after
the
review
and
what,
if
or
whatever
updates
we
made
to
it
and
and
I'm
I'm
gonna
start
bringing
tim
given
the
shape
it
is
in.
I
think
it's
it's
time
to
do
that.
A
If
anyone
wants
to
take
a
last
look
at
it
just
to
make
sure
everything
looks
good.
That
would
be
really
helpful
and
if
guy
is
here
on
the
call
he's
not
here
yet
he
left
one
comment
that
I
still
haven't
made
an
update
for
and-
and
the
comment
was
about
using
selectors
for
loud
name
spaces
rather
than
just
a
list
of
strings.
A
I
personally
prefer
the
selector
approach,
because
it's
more
in
line
with
how
things
are
done
in
kubernetes
and
also
just
seems
more
intuitive
and
more
flexible,
but
I
can't
fully
remember
what
we
decided
on
for
loud
namespaces
did
we
did
we
decided
to
just
have
a
list
of
namespaces
that
we
put
into
this
list
of
allowed
namespaces
and,
and-
and
you
know,
if
those
namespace
exists,
then
then
we
allow
buckets
to
be
mounted
into
them
or
mounted
as
a
wrong
word
attached
into
those
pods
from
those
name
spaces,
or
did
we
say
we'll
use
a
selector
and
whatever
namespaces
that
selector
selected
would
have
access
to
the
buckets
which,
which
one
did
we
finally
decide
on.
B
Can
you
hear
me
now
yeah
yeah,
okay,
stupid
headset,
I'm
having
issues
I
thought
we
tried
to
do
both
because
yeah
there
was
that
use
case
that
people
kind
of
agreed
was
good,
but
my
stance
was
like
we
want
to
make
the
easy
case
easy
and
if,
if
it's
only
selectors,
then
like
a
simple
list
of
a
few
names
because
harder
than
needs
to
be,
but
if,
if
there's
a
way
to
sort
of
allow
either
the
same,
you
know
same
time,
then.
A
Oh,
it's
like
it's
like
it's
like.
No,
it's
equal
into
this
concept
of
node,
name
and
part,
and
also
node
selector,
both
exist
and
then
now
we
also
have
affinity.
But
I.
A
Multiple
ways
to
do
one
thing
is
a
terrible
idea,
but
in
this
case
I
mean.
B
B
A
Yeah,
what
if
we
said?
Well,
you
know
you,
you
could
you
could
it
is
it?
Is
it
a
lot
to
ask
if
we
said
they
have
to
label
the
namespaces
and
then
select
those
namespaces
in
there
in
their
bucket
class
or
or
is
it
okay
and
and
also
for
the
simplest
use
case
which
is
there
is
there
is
no
restriction
on
namespaces?
What.
B
A
I
see
I
see
so
so
you're
saying
if
an
admin
has
forgotten
to
label
the
namespace,
the
user
wants
to
use
it
or
you
know
the
admins
has
added.
Let's
say:
let's
say:
admin
has
added
the
right
selectors,
but
he
hasn't
gone
and
updated
the
select.
You
know
the
labels
in
a
particular
name
space.
The
users
can
do
nothing
about
it
because
they.
B
Can't
go
with
that
right
right!
That's
what
I'm
thinking
so
I
mean
I
haven't
thought
through
all
the
use
cases
to
know,
if
that's
a
practical
problem,
but
that's
how
I
look
at
it
is
you
don't
want
to
create
a
situation
where
all
of
a
sudden,
you
need
an
admin
to
do
something
where
previously,
you
didn't.
A
Okay,
so
I
see
what
you
mean,
even
in
that
scenario,
it
seems
to
me
like
selectors
would
be
more
flexible
because,
yes,
you
know,
if
you
have
a
selector,
then
then
new
name
spaces
added
to
that
selector
by
default,
get
get
added
to
the
list
of
allowed
namespaces,
rather
than
even
having
to
manually,
go
and
put
in
namespace
lists
there.
Wouldn't
wouldn't
this
actually
be
more,
you
know
empowering
and
less
likely
to
require
admin
potentially.
A
Would
have
to
sell
it
themselves,
I
don't
think
users
can
go
and
do
it,
because
namespace
is
a
cluster
level
resource
right.
B
A
But
well,
it's
like
in
a
pod
spec.
If
you
don't
put
a
note
selector,
it
can
go
on
any
node.
If
you
don't
put
an
entry
selector,
I
think-
and
you
know
I
think
it's
it's
a
lot
from
all
namespaces
that
that
that
empty
you
know
the
the
default
cases,
but.
B
Pretty
straightforward,
but
the
difference
is
with
the
node
selector,
like
that's
just
a
scheduling.
Concern
like
there's:
no
security
implications
to
what
node
it
ends
up
on.
If,
if
my
buckets
are
automatically
shared
with
everyone-
and
I
don't
want
them
to
be-
that
has
huge
security
implications
right
by
default,
my
bucket
shouldn't
be
accessible
to
anyone
with
me.
D
B
Right
if
you
can
create
a
host
path,
volume
to
slash
etsy
and
you
can
read
etsy
shadow
and
start
cracking
the
password
database
like
now.
The
crazy
admin
has
a
problem
so
like
they
don't
allow
that
it's
just
prevented.
And
then,
if
you
have
a
pod
security
policy
that
says
you
can
create
host
path
volumes,
then
you
can,
but
the
default
should
be
secure
and
then
you
opt
into
sharing
or
granting
access
or
whatever
through
some
mechanism.
A
Okay,
so
okay,
coming
back
to
nodes
and
and
yeah,
I
I
see
what
you're
saying
so
so
you're
saying
it's
just
a
scheduling,
concern
and
you're
saying,
with
nos
there's,
no
there's
no
security
issue
like
this.
I
see.
B
C
B
With
buckets
like
by
by
default,
all
the
buckets
I
create
are
only
readable
by
me,
because
anything
else
would
be
insecure
and
then,
if
I
get
together
with
alice
and
say,
I
want
to
share
this
bucket
with
her
I'm
going
to
give
her
the
name
I'm
going
to
grant
her
the
access.
Somehow
I
mean
we
still
don't
know
how
you
actually
mutate
this
field,
because
it's
on
a
non-namespace
object,
but
I
should
just
be
able
to
say
just
me
and
alice:
that's
all,
and
then
that
should
be
able
to
go
into
effect.
A
A
You're
right,
but,
but
I
can
see,
I
can
see
a
scenario
where
I'm
even
wondering:
if
something
like
a
taint
and
toleration
type
of
mechanism
would
apply
here
would
make
more
sense
here
or
or
something
like
a
port
security
policy
style
mechanism,
like
maybe
port
security
policy,
should
should
allow
you
know
pods
to
access
a
bucket
just
like
host
path
volumes.
Maybe.
B
B
A
Yeah
yeah
right
so
so
part
security
policy
also
helps
you.
You
know
set
up
or
work
with,
say,
sc
linux
rules
and,
and
you
can
so,
for
instance,
you
can
an
fsfs
group.
So
you
you,
you
can
allow
a
host
path
volume,
but
you
can
only
allow
it
from
certain
directories,
for
instance,
so
the
the
reason
I
bring
it
up
that
way
is.
B
The
whole
the
whole
principle
behind
pod
security
policies
is
like
no
one
should
need
to
have
host
path
volumes
for
most
of
the
kubernetes
use
cases
every
now,
and
then
you
have
like
infrastructure
type
pods
that
are
performing
some
role
on
the
node
and
like
they
need
host
path
volumes,
and
so
you,
you
vet
those
specific,
pods
and
say
yeah.
I
trust
that
the
guy
producing
these
images
is
not
trying
to
hack
my
cluster.
Therefore,
I'm
gonna
allow
these
pods
to
run
with
a
different
pod
security
policy
that
gives
them
a
little
more.
A
B
A
So
you're
saying
psp
is
more
of
a
particular
box.
Psp
is
more
of
a
gating
mechanism
rather
than
kind
of
a
selecting
mechanism.
You
don't
use
psp
to
say
these
are
all
the
positive
allowed
uses,
but
it's
more
like
a
way
to
say
no
pods
that
belong
to
this
default
psp
should
be
able
to
access
this
right
right.
A
You
definitely
don't
want
to
put
selectors
there
you're
right,
okay,
so,
okay,
maybe
not
part
security
policy.
What
about
something
like
teams
and
tolerations?
So
if
a
bucket
is
tainted,
nobody
can
use
it
unless
they
can
tolerate
it.
But
what's
the
what's
the
security
mechanism
behind
it?
Can
anyone
tolerate
a
thing.
B
I
was
going
to
say
yeah,
like
the
the
taints
and
tolerations.
First
of
all
is
a
fairly
complicated
system
for
mortals
to
understand,
like
when
people
come
to
kubernetes,
and
you
explain
to
them
taints
and
tolerations
their
eyes
glaze
over,
like
what
the
heck
are
you
talking
about
and
and
they
aren't
about
security
at
all,
they're
really
about
you
know
controlling
behavior,
so
like
the
the
most
common
taint,
is
the
not
ready
taint
right
like
your
node
node
goes
down
for
some
reason.
B
The
the
node
life
cycle
manager
controller
marks
it
not
ready
with
the
taint
and
by
default
every
pod
tolerates
that
taint
for
exactly
300
seconds.
So
pods
will
self-evict
after
five
minutes
of
the
node
they're
on
not
being
ready
and
that's
a
good
default,
but
you
can
override
it.
You
can
say
I
want
to
self-evict
after
zero
seconds,
so
the
instant,
it's
not
ready,
I'm
out
when
you
can
have
other
pods.
B
That
say
you
know
what
I'm
going
to
wait
an
hour
for
the
pod
for
the
node
to
come
back
because
you
know
restarting,
my
pot
is
really
expensive
and
it
just
lets.
You
tune
your
behavior
on
a,
but
it's
not
about
security.
It's
just
about.
You
know
that
there's
a
default
and
you
can
you
can
change
the
time
up
or
down
to
get
faster
or
slower
responsiveness
to
things
happening
in
the
cluster
that
that's
really
what
tolerations
are
about.
In
my
mind,.
A
Okay,
so
even
that
wouldn't
work,
then
I
see
where
you're
coming
from
okay,
so
coming
back
to
allow
namespaces
selectors
is
just
a
list
of
allowed
namespaces.
I
feel
like
with
either
of
these
approaches.
It's
not
really
a
security
policy.
A
I
I'm
just
looking
for
a
way
to
be
more
specific
or
be
sure
that
you
know
no
unintended
users
can
use
this
bucket,
because
this
was
one
of
the
feedback
that
we
got
during
the
previous
kept
review
which,
which
you
know
where,
where
it
was
said
allowed
names,
was
really
using
the
security
mechanism.
It's
kind
of
a
convenience
mechanism
to
to
make
you
know
kind
of
say
that
people
won't
use
it
the
wrong
way.
B
B
I
mean
I,
I
think,
the
reason
that
the
kepler
viewers
honed
in
on
those
the
first
time
around
is
because
it
had
you
know
which
way
we
go.
Has
such
dramatic
impact
on,
like
the
api
design
like
whether
you
need
not
namespaced
objects
or
non-namespaced
objects
depends
greatly
on
what
exactly
you
want
to
do
here.
B
You
know
we
went
through
the
iteration
where
we
talked
about
the
concept
of
like
a
clustered
bucket
as
a
another
kind
of
bucket.
That
was
non-namespace,
that
everyone
could
see
or
a
clustered
bucket
request
or
what
I
don't
forget,
what
we
were
calling
it
but
yeah.
We.
B
B
We
wanted
to
stick
with
our
original
design
of
having
a
namespace
request
and
a
non-namespace
sort
of
thing
that
it
binds
to
right.
A
B
It's
a
one-time
upfront
thing
to
create
the
classes
and
then,
from
that
point
on,
you
can
turn
the
crank
as
many
times
as
you
want
to
get
buckets
out
right
and
it's
yeah
and,
and
the
question
is
just
you
know
if
if
alice
is
cranking
out
buckets
and
she
wants
to
share
them
with
bob,
what
is
how
does
she
do
that.
A
So
if
we
had
some
kind
of
you
know,
if
can
we
rely
on
the
outback
infrastructure?
Somehow
can
we
say
something
like
people
from
this
namespace
or
users
from
this
nation
can
only
use
these
bucket
classes?
Is
there
a
way
to
do
that
other
than
making
bucket
class
namespace.
B
Oh,
how
does
that
work?
I'm
not
too
familiar
with
that.
Can
you
can
you
understand
a
little
bit
more?
I'm
trying
to
remember,
because
I
I
am
not
familiar
with
the
quota
system
myself,
but
I
I
thought
that
you
could
specify
a
quota
per
storage
class
with
the
pvc
so
like
I
know
that
you
know
pvcs.
You
can
set
a
number
of
pvcs
that
you're
allowed
to
have
a
total
gb
of
the
pvcs
you're
allowed
to
have,
and
I
thought
that
it
also
extended
to
her
storage
class.
You
could
have
separate
limits.
B
I
I
wish
I
had
spent
more
time
looking
at
the
quota
system
to
familiarize
myself
with
it,
but
but
but
short
of
the
quota
system.
I
don't
think
there
is
a
way
to
sort
of
say
that
you
know
alice
can't
use
the
storage
class,
you
know
if
it's.
If
it's
there,
everyone
can
see
it
and
everyone
can
can
point
to
it,
because
it's
just
a
name.
B
A
B
A
Could
be
you
know,
final
solution
that
that
we'll
probably
end
up
with
after
we
won
or
something
but
using
bucket
outback,
we
can
kind
of
get
the
functionality.
I
think
that
we're
talking
about.
B
Can
when
another
controller
looks
at
it
the
fact
that
bsward's
created
it
is
nowhere
to
be
found
right,
because
it's
just
an
object
in
the
server
now
and
it
has
to
make
a
different
decision
about
you
know.
Can
I
bind
to
this?
B
Can
I
bind
this
bar
to
this
b
and
and
the
fact
that
ben
created
the
bars
is,
is
not
accessible
to
that
other
controller,
because
it's
just
saying
because
it
got
created
and
now
it's
in
the
database
and
kubernetes
doesn't
remember
who
did
what
okay,
so
people
can
still
guess
the
name
and
kind
of
just.
B
A
I
see
I
see
why
I
see
why
namespace
selector
is
probably
our
namespace
level.
Access
control
is
probably
the
best
way
here,
but
because
then
you
can
control
it
at
the
name,
space
level,
or
you
know
at
that
resource
level,
because
there
you
know
you're
actually
controlling
rather
than
who,
rather
than
based
on
who
made
the
request
is
more
based
on
where's
the
request
coming
from.
So
it
doesn't
matter
who
create
the
request
to
to
bind
a
bucket
access
request
to
a
bucket
if
it's
coming
from
the
right
name.
A
Okay,
I
think
I
think
that
makes
sense.
Let's
see
guy,
I
didn't
get
a
chance
to
read
everything
you
said:
can
you
explain
it.
D
Hey,
I'm
not
sure
if
you
can
hear.
D
C
Hey
so
I
I
just
went
to
check,
I
remembered
that
there
was
a
storage
class,
but
I
forgot
how
so,
basically,
you
can
specify
per
either
globally
for
all
storage
classes,
the
limit
of
how
much
storage
or
the
limit
of
how
many
claims
for
pvs
and
the
same
thing
you
can
do
in
in
in
a
per
storage
class
limit
in
the
quota.
So
you
can
specify,
like
ben
said,
gold
per
dot
and
then
there's
like
this
storage
class,
dot,
storage,
k,
k,
a
guess.
C
A
C
You
can
do
that.
You
can
certainly
do
that,
because
what
we,
what
you
do
then,
is
you
create
your
quota
limits
in
a
way
that
selects
which
you
know
you
have
selectors
there
as
well,
and
then
you
select
which
to
which
you
know,
I
think
to
which
pods
eventually
this
I
think
it
selects
pods
or
am
I
no?
C
It's
probably
spv's
pvcs
then,
but
there
is
some
selector
here:
scope,
selector,
it's
called
and
things
like
that
where
you
match
things
in
your
in
your
pods
as
far
as
I
can
see,
and
but
yeah
you
know
in
the
pod
case,
it's
it's
meant
to
to
be
quota
for
cpu
and
memory
right.
So
it's
like
the
different
case,
I'm
not
too
sure
if,
if
the
same
applies
in
storage,
but
I
I
think
so
I
see
and.
E
A
B
The
difference
is
that
admins
set
up
quotas
right.
We
don't
want
admins
to
be
doing
this
operation
next
election.
Do
you
mean
right
like
like
quota,
is
about
the
the
admin
putting
a
limit
on
an
end
user
users
have
no
reason
to
adjust
quotas
themselves,
but
we
we
keep.
I
I
I
have
the
belief
that
users
should
be
able
to
share
buckets
by
themselves.
A
Yeah
yep,
I
see
they're
coming
from
so
actually
you
know
based
on
all
this
discussion
it.
It
seems
to
me
like,
unless
there's
a
stronger
security
model
like
unless
there's
a
there's,
a
stronger
way
to
say
you
know,
you
know,
only
only
these
resources
can
use
it
and
and
on
that
resource
level,
there's
a
way
to
say
you
know
like,
for
instance,
if
I
could
say
only
pods
with
these
labels
can
use
it,
and-
and
you
know,
users
cannot
just
add
that
label
if
they
wanted
to.
A
Either
allowed
namespaces
or
namespace
selector
again,
I'm
leaning
towards
namespace
selector,
but
maybe
we
could
we
could
you
know
unless
it
does?
Anyone
have
an
objection
to
that
or
you
know,
doesn't
even
have
other
ideas
about
how
we
should
do
this.
B
To
go,
someone
is
working
on
a
storage
transfer
cap
to
transfer
volumes
and
transfer
snapshots
from
one
namespace
to
another.
For
a
variety
of
reasons.
I
think
it's
been
down
scoped
to
just
transferring
snapshots
and
not
volumes,
but
it's.
B
C
Right
I
saw
this
as
well,
but
so
you
mean
that
in
our
case
it
will
be
transferring
a
bug
bucket
access
request.
You
mean
like
if
I.
B
C
Right
but,
and
does
rely
on
on
these
users-
sorry,
knowing
each
other
in
the
sense
that
they
identify
each
other
by
a
namespace
or
something
like
that.
B
Yeah
yeah
they
have
to
have
some
some
external
communication
channel,
because
what
you
don't
want
is
for
alice
to
be
able
to
create
pvcs
and
just
send
them
to
bob
when
bob
didn't
didn't
want
them
right.
Right,
bob
has
to
both
want
it,
and
alice
has
to
be
willing
to
give
it
up
for
the
transfer
to
occur.
C
Right
basically,
so
I
if
I
would
just
frame
it
in
what
we're
doing.
Let's
say
that
I
have
a
bucket
access
request,
which
you
know
it's
already
already.
Has
it's
like
already
fulfilled
and
there's
already
a
bucket
access
object
underneath
and
then
I
I
you
know,
somebody
else
wants
to
get
that
from
me
and
I
tell
him:
okay
get
ready
for
it,
so
he
creates
his
bucket
access
requests
in
a
way
that
you
know
makes
it
ready
for
transfer.
B
Yeah
yeah,
so
I
kind
of
I
kind
of
like
that
model,
because
that
is
very
different
than
what
we've
been
talking
about
so
far,
that
that
would
be
then
no
one
would
ever
have
to
change
the
non-namespace
object.
You
wouldn't
need
a
policy
on
it.
You
would
just
need
every
time
you
every
time
someone
wanted
to
gain
access
to
the
bucket
that
that
an
object
would
be
two
objects,
would
get
created,
one
in
each
namespace.
B
That
would
end
up
referring
to
each
other
somehow
to
affect
the
the
grant,
and
then
I
guess
the
issue
with
the
only
issue
I
see
with
that
that
makes
it
weaker
is
that,
after
after
alice
gives,
gives
a
bucket
access
to
bob
there's
nothing
to
stop
bob
from
giving
it
to
charlie,
even
if
alice
doesn't
want
charlie
to
have
access
like
once
she's
given
it
to
bob
bob
can
give
it
to
whoever
he
wants.
So
she
loses
control
of
it
at
that
point,
but
presumably
not.
C
But,
but
also
not
necessarily,
I
mean
the
transfer
can
be,
can
be
user
driven,
but
it
doesn't
mean
that
the
bucket
access
that
I
created
necessarily
has
you
know
can
can
then
be
used
for
anything
like
maybe.
B
C
B
I
mean
yeah,
I
guess
we
could
come
up
with
more
rules,
but
like
the
simplest
flavor
of
this,
I
kind
of
like
is,
is
that
the
originator
of
the
bucket
has
to
create
something
that
that
refers
to
the
the
the
sharer
has
to
create
something
that
refers
to
the
share
e
and
and
then
and
then
a
transfer
can
occur
and
then
no
one
ever
needs
to
mutate.
The
non-namespace
object.
B
B
Anyone
who
wants
to
to
do
this
can
do
this.
The
admin
is
completely
out
of
the
way
and
the
only
burden
is
that
alice
has
to
be
around
to
grant
new
access
to
anyone
who
wants
to
use
it.
So,
every
time
a
new
user
shows
up
that
needs
to
get
access
to
the
bucket.
Someone
has
to
do
something
alice's
namespace,
to
make
that
happen.
B
C
Just
like
select
anything
no
labels
or
something
here.
B
Then
then
I
could
see
that
being
reasonable
and
and
and
if,
if
we
had
that
scheme,
then
we
could
completely
get
rid
of
the
allowed
namespaces,
because
no
one
would
ever
have
to
check
that
all
you'd
have
to
check
would
be
the
existence
of
these
other
objects.
D
B
The
except
buckets
don't
have
an
allowed
name
space
on
it
when,
when,
when
alice,
creates
a
bucket
request
and
gets
a
bucket
and
then
she
creates
a
bucket
access
request
and
she
has
access
to
her
bucket,
she
can
use
it
exactly
like
like
it
is
now
when
she
wants
to
share
with
bob
what
she
does
is
she
creates
a
new
bar
in
her
own
name,
space
that
she's
going
to
give
to
bob,
and
so
she
creates
it
in
such
a
way
that,
like
it,
is
it's
initially
created
in
her
name
space
and
only
usable
by
her.
B
But
it
has
some
some
extra
piece
of
data
on
it.
That
says,
like
I'm,
willing
to
give
this
to
bob,
and
then
bob
also
creates
a
bar
in
his
name
space
that
points
back
to
the
one
alice
just
created,
and
they
have
to
exchange
some
information
out
of
band,
like
maybe
the
name
of
the
the
ba
that
that
it
got
bound
to
or
something
and
then
as
long
as
both
of
these
objects
exist,
one
in
bob's
name,
space
pointing
to
alice's
one
in
alice's
namespace
pointing
to
bob's.
B
The
controller
will
just
switch
the
axis
over
so
that
so
that
bob
now
has
the
ba
that
alice
used
to
have
basically
take
the
ba
and
rebind
it
to
the
one
in
the
other
name
space
and
then
alice
can
get
rid
of
her
bar
because
it
because
bob
now
has
it.
Bob
now
has
his
own
bar
that
points
to
the
old
ba
and
now
bob
can
just
access
the
bucket,
as
you
know,
directly
through
the
ba
that
alice
created
and
then
transferred
to
him.
A
I
don't
think
it
solves
the
problem,
though,
because
because
how
many
bas,
so
so?
Okay,
maybe
maybe
it
is
possible,
but
let's
say
the
the
bar
that
that
alice
creates
to
share
the
bucket.
Can
it
can
it
be
bound
to
any
namespace
or
is
it
for
a
specific
other
namespace,
I'm
just
starting.
B
So
so
it
would
when
she
creates
it
initially,
it's
only
going
to
be
in
her
name
space,
because
if
no
one
in
any
other
name
space
claims
it
it's
not
going
to
go
anywhere.
It's
just
going
to
sit
there
right.
You
don't
want
to
create.
You
don't
want
to
give
alice
the
power
to
push
objects
into
other
people's
names
faces.
So
all
she
can
do
is
create
the
bar
for
herself
but
flag
it
for
transfer
to
a
specific
place.
C
Yeah,
so
can
I
can
I
play.
Can
I
play
it
out
a
little
bit
like
a
little
bit
out
of
the
box
here?
So
what
if
this
bar?
That
else
creates
so
one
way
that
you
just
presented
like
then
right
now
means
I
want
to
hand
off
this
access
to
someone
in
particular
bob
right,
I'm
referencing,
specifically
it's
going
to
be
bob
in
this
namespace
and
you
know
like
something
very
strict.
C
Perhaps
the
the
other
method
might
be.
This
is
a
bar
that
I
hand
off
to
others,
to
bob
and,
and
you
know,
and
and
others
right
so
bob
two
bob
three
and
then
and
then,
and
whenever
a
bucket
access
gets
transferred.
C
This
bar
sticks
there
in
alice's
namespace
and
allocates
a
new
one
ready
to
be
transferred
as
well
right.
Something
like
like
in
the
sense
of
this
is
a
this
is
a
resource.
This
is
a
request
for
bucket
access
that
I
can
transfer
to
these,
and
this.
C
So
it
can
be
one
to
one
saying
like
a
transfer
request
like
that
was,
I
think,
for
snapshots,
and
then
the
other
option
means
it's
just
you
know
a
tombstone
here
saying
I
I
I
will
keep
on
keep
on
transferring
it
to
anybody
who
I
allow.
C
Basically,
if
I
say
this
is
allowed
to
this
this
and
that
selectors
from
a
user
perspective
right,
not
an
ad
perspective
like
I
can
select
other
namespaces
by
a
name
or
selector
like
that
and
say
each
one
of
these
can
get
bucket
access
from
me,
and
I
just
allocate
a
new
one
or
something
like
that.
B
The
the
the
reason
I
like
the
one
to
one
is
that,
like
it,
gives
alice
fine
grain
control
over
exactly
what
level
of
access
she's,
creating
and
giving
to
bob
and
then,
if
she
wants
to
give
charlie
a
different
level
of
access,
she
can
create
a
different
bar
with
a
different
bac
right
and
then
transfer
that
one
to
charlie
and
and
so
she
she
gets
she's
in
the
driver's
seat.
Every
time
one
of
these
transfers
happens,
she
knows
who
got
it
and
what
level
of
access
was
given.
C
I
I'm
sure
that
we
can
always
fall
back
to
the
one-to-one
if,
even
if
we
support
more
than
one
but
the
option
of
more
one
just
means
that
you
know
alex
is
not
needed
every
time
there.
It's
like
a
policy
that
alice
publishes
saying
this
is
what
I
want
to
provide
to
the
to
my
peer
users
here,
and
you
know,
whenever
they
they
are
ready.
I
am
ready
to
provide
it.
B
B
They
both
and
alice's,
gets
bound
to
a
specific
ba
before
the
transfer
happens,
and
then
the
question
is:
do
we
actually
take
that
ba
and
rebind
it
to
the
other
person's
bar,
so
that
alice
loses
it
or
do
we
copy
it
so
so
that
they
get?
Because
the
difference
is
every
time
you
create
a
ba,
you
have
to
go
all
the
way
down
to
the
driver
and
call
grant
access,
get
a
new
access,
key,
get
a
new
secret
and
put
it
on
the
va
object
right.
So
I
I
was
imagining.
C
B
I
don't
know
just
it
feels
different.
It
could
work.
I
don't
see
any
obvious
problems,
but
I
I
like
the
idea
that
alice
causes
it
to
occur
through
her
actions
and
then
she
hands
it
off
to
other
users
to
cause
the
sharing
to
occur.
Before
we
get
to
the
end
of
the
meeting
sid,
you
would
want
to
talk
about
sts
style
access
and
I,
as
you
know,
I'm
against
it.
I
want
to
hear
the
case
again
well,.
A
I
can't
take
the
name,
but
just
say
that
it's
a
it's
a
large
bank
and
they
have
these
these
security
control
mechanisms
that
are
site-wide
an
example
of
that
is,
you
know,
you're
not
allowed
to
mount
any
non-standard
environment
variables
and
and
so
that
you
so
that
no
other
process
can
just
you
know,
sniff
out,
environment
variables
and-
and
you
know,
read
credentials
or
some
other
sensitive
information
similar
to
that.
They
also
have
this.
A
This
other
requirement
that
nowhere
in
your
system
should
you
use
access,
keys
and
secret
keys.
Some
other
form
of
authentication
needs
to
be
used
and,
and
the
this
customer
of
ours
uses
sts.
A
B
All
know
you
know
corporate
security
teams
sending
down
edicts
of
this
flavor
for
various
reasons,
and
we
know
why
they
do
it.
I
mean
so
it
doesn't
surprise.
I
I
guess
what
my
question
would
be
is
like.
Is
this
the
kind
of
user
that
actually
needs
cozy,
or
are
they
happy
doing
what
they're
already
doing
like.
A
A
I
o
right
like
how
do
I,
how
do
I
mount
min
io
into
a
pod
automatically
and
you
know,
then
we
go
over
the
whole
thing
about
how
object
storage
is
not
supposed
to
be
consumed
over
posix
and-
and
you
know
it's
better
to
use
the
api
directly
and
all
that
and
then
that's
how
we
you
know
we
can
kind
of
touch
upon
cozy
and
everything
at
that
point.
But
but
the
reason.
A
This
up
is,
I,
I
would
think
someone
like,
I
mean
I
think
it's
too
early
to
architect
for
it,
but
since
we're
talking
about
you
know,
since
we're
just
designing
the
system
now,
I
think
I
think
it's
good
to
keep
in
mind
that
that
such
a
requirement
might
come
up
in
the
future
where,
where
access
mechanisms,
because
there's
two
pieces
of
information
we
share
with
the
part
one
is
the
end
point
itself,
and
you
know
what
you're
accessing
another
is,
how
you
know
the
credentials
to
access
it
and,
and
this
credential
mechanism
wise
it
is.
A
B
If
the
concern
is
that
like
using
access,
keys
and
secret
keys
is
is
dangerous
because
of
you
know,
someone
can
read
something
somewhere.
You
have
to
think
about.
You
know
in
the
context
of
cozy
who
can
who
can
see
those
things
and
and
if,
if
you
were
to
use
sts
or
some
other
form
of
of
authentication
like
have
you
have
you
shrunk,
the
circle
of
who
can
see
the
the
sensitive
information?
B
My
my
suspicion
is.
The
answer
is
no
that
whether
you
use
access
keys
and
secret
keys
with
cozy
plumbed
through
by
cozy
and
everything
or
use
sts,
the
class
of
attacks
that
will
allow
you
to
actually
compromise.
Something
are
the
same
in
both
cases,
and
so
I
I'm
not
convinced
that.
There's
a
practical
gain:
there
are
obviously
bad
ways
to
use
access,
keys
and
secret
keys.
That
would
expose
your
data
to
to
compromise.
A
B
Right
right,
I'm
saying
that,
like
that
the
kind
of
users
who
can
steal
your
information
with
the
security
scheme,
we've
proposed,
can
also
steal
your
sts
tokens
and
everything
that
comes
out
of
those.
So
it's
like
you
haven't
prevented
anything
by
upgrading
your
security,
so
I
I
just
I
want
to
be
really.
I
really
want
to
understand
like
what
are
they
actually
worried
about?
No.
B
A
B
I
I
think
that
the
way
that
we've
proposed
using
access,
keys
and
secret
keys
and
storing
them
in
kubernetes
secrets
and
plumbing
them
into
the
pod
means
that
they're
pretty
safe
like
unless,
unless
someone
either
compromises
the
lcd
behind
kubernetes
or
compromises,
a
node
on
which
one
of
these
workloads
is
running
like
they're
not
going
to
be
able
to
get
these
keys
and
if
they
do
either
of
those
two
things
the
sts
scheme
isn't
going
to
help
you.
A
B
A
It's
like
it's
not
very
different
from
oauth,
but
generally
they
they
integrate
with
active
directory
or
ldap
instead
of
instead
of
so
you
know,
they
already
have
some
kind
of
user
credential
mechanism
whatever
that
is
so
you
know
a
user
would
be
able
to
so
so
say
they
have.
They
have
cube
flow
running
and
and
and
kubeflow
accesses
object,
storage.
A
So
whoever
starts
the
workload
on
the
cube
flow
side,
their
access
and
and
secret
would
be,
would
be
tied
to
or
their
active
directory.
Username
and
password
would
be
tied
to
an
iem
role
in
the
object,
storage
backing
and
and
if
that
user
has
access
to
regular
bucket,
they
get
access
to
the
bucket.
But
the
way
cube
flow
gets.
You
know,
takes
the
active
directory
credentials
and
and
gets
a
you
know.
Access
to
s3
is
using
the
scs
token.
A
So
so
it
talks
to
the
s3
back
end
and-
and
you
know,
provides
these
well,
it
talks
to
the
active
directory
back
and
and
and
gets
a
token
back
from
there
saying
hey.
This
is
an
authenticated
user.
Here's
the
token
for
that
user
and
then
that
token
is
given
to
the
s3
backend,
and
that
gives
back
your
sts
token
that
can
be
used
back
and
forth.
It's
it's
exactly
like
the
oauth
mechanism,
but
with
you
know
it
can
be
done
with
oauth
too.
It's
actually.
B
Point
of
cozy
is
that
the
guy
who
created
the
bucket
sets
the
policy
on
who
gets
to
access
it
right
like
it's
the
whole
policy.
The
whole
idea
is
the
admin
isn't
involved
that
the
user
decides
it's
my
bucket.
I
can
share
it
with
alex
with
with
bob,
if
I
want
to
or
or
not,
and
and
no
one
no
one
gets
to
come
in
above
me
and
and
tell
me
who
my
bucket
is
shared
with
or
not
shared
with
it.
It
feels
like
they.
They
want
something
other
than
cozy.
It
feels
like
they.
A
We
have
a
solution
that
helps
their
markets,
so
so
the
thing
is,
we
have
a
solution
for
them.
I'm
bringing
this
up
from
the
context
of
would
it
was
that
something
we'll
ever
need
to
support
it's
more
of
a
question
rather
than
a
requirement,
so
so
they're
happy
that
you
know
we
they're
not
using
cozy
now
and-
and
you
know,
they're
able
to
work
around
with
with
all
this.
But
the
question
is:
is
that
is
that
use
case,
something
that
is
even
relevant
to
us?.
B
B
When
you
know,
when
you
ask
the
question
of
who's
allowed
to
to
access
the
bucket,
but
that
that's
that's
the
model
we've
gone
with
so
far
is
the
cozy
is
the
decider
cozy
is
the
source
of
truth
on
all
of
these
questions,
if
you
want
to
add
in
external
sources
of
truth,
like
you
need
a
different
api
than
more
than
the
one
we've
designed
right,
I
don't
know
I
I
I.
I
hope
that
people,
you
know
the
hope
that
cozy
gets
gets.
Shippable
and
people
start
using
it
and
think.
B
A
Yeah
I
mean
if
we
don't,
we
learn
from
it
and
fix
it.
So,
okay,
so
okay,
so
I
think
I
think,
that's
convincing.
I
think
that's
a
good
enough
answer,
yeah.
Actually
it
doesn't
even
make
sense
because,
because
you
know
we're
not
we're
not
getting
into
that
whole
life
cycle
whatsoever,
yeah
we're
not
getting
into
this
life
cycle
of
you
know
someone
manually
setting
these
access
policies
we're
working
at
the
name,
space
level.
B
And-
and
I
think
we
should
emphasize
it
like-
our
goal-
is
not
to
take
over
all
bucket
or
object
storage
forever
in
all
time
right,
it's
it's
it's
a
very
specific
way
of
managing
buckets
and
using
them
in
kubernetes.
That
should
be
useful,
but,
like
the
other
ways
of
doing
it
will
remain
valid
after
cozy
exists.
Just
like
the
same
is
true
for
volumes
right,
there's
plenty
of
ways
to
consume
storage
that
have
nothing
to
do
with
kubernetes,
and
you
can.
B
You
can
take
volumes
created
in
kubernetes
and
use
them
outside
of
kubernetes
and
vice
versa.
The
same
will
end
up
end
up
being
true
of
these
buckets,
but
but
within
within
our
world
of
cozy
and
the
buckets
that
we
create
and
we
control,
we
should
have
ultimate
control
over
what
happens
to
those
buckets.
C
But
one
thing
one
thing
that
sts
brings
to
the
table
is:
is
the
ability
to
separate
between
you
know
the
long
term
credentials
and
the
the
the
kind
of
short
term
like
coverage
and
all
regardless
of
the
policy
of
like
access
control?
Who
who
can
access?
What
I'm
not
sure,
what's
more
valuable
in
the
use
case
that
you
mentioned
sid,
but
both
of
them
are
there
in
some
way
before
another.
B
A
The
main
reason
is,
we
can't
enforce
the
client
to
to
rotate
it.
The
client
has
to
initiate
the
rotation
we
can.
We
can
give
the
infrastructure
for
it,
but
we
can't.
We
can't
force
the
client
to
rotate.
B
A
Yeah,
okay,
so
one
last
thing
I'll
go
update
the
cap,
then
I'm
gonna,
I'm
gonna
change
from
allowed
names
just
being
a
list
to
a
selector.
I
prefer
that
I
think
I
think,
based
on
today's
discussion,
we're
kind
of
like
both
work
and
we
have
an
alternate
solution
which
might.
B
A
How
about
this?
How
about
we
sit
on
it
for
a
week?
Okay,
yeah,
let's
discuss
again
on
next
thursday
and
and
yeah
we'll
go
from
there,
hey,
there's
another
thing
that
I
was
thinking
about,
bringing
up,
I
completely
forgot
actually
but
yeah.
If
I
remember
it
we'll
bring
it
back
up
next
next
week,
it's
important
enough
we'll
come
back
all
right,
so
so
we'll
continue
this
discussion
next
thursday.
A
Please
take
a
second
to
review
the
cap.
I
think
it's
in
good
shape
and-
and
you
know,
I'm
gonna
start
bringing
time
about
this.
I
if
someone
wants
to
take
a
look
and
make
sure
everything
looks
good.
I
would
really
appreciate
that.