►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Design Meeting - 11 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
Oh,
thank
you
shing
yeah,
do
you
mean
what
I
mean
is
so
I
am
not
an
expert
in,
like
the
I
don't
know
using
this,
this
the
service
account
token
to
like
authenticate
to
other
services
and
exactly
how
that
might
work
in
practice.
I
just
I
don't
tend
to
work
in
environments
where
that's
the
thing
that
you
do.
I
can.
A
Yeah,
I've
got
something,
so
I
don't
know
if
I
have
the
demo
with
me
right
now.
I
mean
prepared
right
now.
I
did
have
it
last
week,
though.
Let
me
see
what
I
can
find.
A
At
least,
to
start
with:
let's,
let's
go
over
what
the
google
cloud
api
says.
A
Oh
perfect,
hi,
michelle
hi,
I
saw
someone
else
trying
to
hi
aaron.
A
All
right,
so,
let's,
let's
get
started
okay,
so
so,
to
give
you
a
quick
background
on
how
workload
identity
works
in
google
cloud.
amazon
cloud
follows
the
same
principle.
Essentially
they
they
have
something
called
as
a
metadata
service,
and
this
is
a
this
is
a
link
local
web
server
that
runs
kind
of
kind
of
in
every
every
host
and
whenever
you
query
this
web
server,
it
gives
you
information
about
yourself.
So
it's
called
metadata
server
and
if
it's,
if
it's
coming
from
a
container,
it
will
get
information
about
the
container
itself.
A
If
it's
coming,
it's
like
a
reflection
api
and
if,
if
the
request
is
coming
from
from
a
host,
you
get
information
about
the
host
itself,
so
one
of
the
apis
it
provides.
Is
a
service
account
token
you
can.
You
can
just
even
call
that
api
and.
B
Oh
so
so
I
mean
I,
I
understand
the
concept
of
a
metadata
service,
so
I
just
want
to
understand
this.
So
in
kubernetes,
like
you
have
when
you
have
a
pod
running
the
service
account
for
that
pod,
the
token
tends
to
be
mounted
into
the
file
system
of
the
pod,
unless
you
specifically
turn
that
off,
like
you
have
that
in
your
file
system.
But
what
you're
saying
is
there's
a
different
token
or
or
what
I
want
to
understand
is.
Is
it
a
different
token
or
is
it
the
same
token
just
exposed.
B
A
A
Capable
of
working
with
it,
all
we
need
to
do
is
can't
make
the
appropriate
cloud
calls
the
api
calls
to
to
allow
that
service
account
token
for
that
part
to
access
a
bucket.
A
So
in
terms
of
orchestration,
like
really
there's
nothing
that
needs
to
the
very
little
that
needs
to
be
done
like
we're,
not
we're
not
bringing
any
tokens
and
putting
it
into
the
pod,
we
won't
even
be
touching
the
pod
api
spec.
A
B
There
yeah
so
so
so
what
I
so
so,
but
the
question
that
this
raises,
in
my
mind,
is
so
that
the
the
s3
sdk
or
the
object
storage
sdk
that
you're
going
to
use
knows
how
to
talk
to
the
metadata
service.
It's
going
to
make
an
http
call,
presumably
to
some
url.
A
I
mean
not
across
a
you
know,
protocols,
so
s3
metadata
server
won't
look
the
same
as
google
clouds,
but
the
metadata
api
itself
is
standardized
version
and
all
of
those
good
things.
So.
B
Where
I'm
going
with
this
is
like
we
could,
in
principle
not
tell
the
sdk
like
just
use
the
service
account
token.
We
could
tell
the
sdk
like.
I
know
the
url
of
the
place
where
you
need
to
get
your
token,
and
this
is
what
it
is
and
and
if,
if,
if
we
knew
that
it
was,
for
example,
one
of
these
cloud
services
where
the
the
metadata
service
was
available,
we
could
just
provide
the
link
to
that
metadata
service,
but
you
could,
in
principle,
provide
any
other
url
that
could
also
perform
the
same
function.
B
A
The
last
week
or
two
weeks
ago,
when
you
were
here
one
of
the
things
we
discussed
was
we
allow
or
we
leave
it
to
the
application
to
go
over
its
its
the
set
of
credential
mechanisms
that
it
supports
and
and
just
work
with,
whatever
is
available
right.
So
one
of
the
things
we
said
was
we're
just
going
to
enable
all
the
things
that
we
can
and
and
sdks
are
expected
to
try
different
mechanisms,
for
you
know,
authentication,
but.
B
The
problem
I
have
with
that
is,
if,
if
we
tell
them
use
all
of
them
and
the
the
priority
order
is
not
defined
anywhere
like
it
could
be
the
case
that
there
are
two
credentials
available,
but
only
one
of
them
has
been
given
access
and
if
the,
if
the
sdk
picks
the
wrong
one,
because
it
has
a
precedence
order
that
we
didn't
expect,
it
could
attempt
to
connect
using
something
that
isn't
going
to
work
fair
enough.
I
think.
A
B
B
But
it
makes
me
nervous
because
if
you
know,
if
someone
writes
a
new
sdk,
that
has
a
different
precedence
order
and
it
picks
up
on
some
credential
that
we
never
expected
to
be
there
and
it's
not
given
access
they
will
break
and
so
by
leaving
it
undefined
we're,
creating
a
possibility
for
people
to
make
wrong
decisions.
A
B
I
guess
in
particular
I'm
worried
about
the
case
where
you
have
both
the
access
key
secret
and
a
service
account
token
and
the
the
administrator
of
the
kubernetes
cluster
wanted
people
to
use
access
key
secret
for
whatever
reason,
but
this
the
service
account
token
is
still
available,
and
so
the
workload,
if
not
properly
controlled,
to
prefer
access
key
secret
over
a
service
account
token
might
just
use
the
service
account
token
and
fail
to
access
the
bucket
and
then
not
know.
Why?
B
A
I
mean
I
don't
so
so
that
communication
has
to
come
in
through
the
api,
but
but
I
do
I
do
see
the
bigger
issue
that
you
brought
in,
which
is
I
mean,
I
think
it's
better
to
be
specific
about
what
authentication
mechanism
will
be
passing
down.
A
We
can
do
it
through
the
api.
It
doesn't
have
to
be
some
mechanism
to
where
the
application
itself
on
auto
discovers.
You
know
what
kind
of
authentication
is
separate
provided
here.
What,
if
we
just
showed
it
through
the
api
like
when
the
application
is
deployed,
the
developer?
A
Whoever
is
deploying
the
application
gets
to
know
that
this
is
the
kind
of
authentication
this
one's
going
to
get,
because
it
is
really
an
infrastructure
concern.
It's
not
an
application
concern.
B
But
it's
a
portability:
it's
a
portability
concern
so
two
weeks
ago
we
spent
a
lot
of
time
going
around
on
like
who,
who
has
to
be
flexible
and
who
gets
to
make
decisions,
and
we,
I
thought
we
agreed
that,
like
the
applications
have
to
be
flexible
and
the
admin
gets
to
make
the
decision,
so
an
application
can't
dictate
like
I
want
access
key
secret
or
I
want.
I
want
to
use
my
cloud
service
account
token.
B
It
just
has
to
work
with
whatever
cozy
decides
to
give
it
and
the
admin
gets
to
just
make
that
you
know.
If
more
than
one
thing
could
be
supported,
then
the
admin
gets
to
pick
which
one
there
is
in
a
lot
of
cases.
We
expect
there
will
only
be
one
option
and
that's
what
you'll
get,
but
the
the
workload
is
sort
of
at
the
mercy
of
cozy
and
and
so
cozy
owes
it.
A
signal
of
you
know:
well
we're
using
access
key
we're
using
access
key
secret
key
on
this.
B
On
this
platform,
we're
using
cloud
service
account
tokens
on
this
platform
and
then
the
workload
can
ignore
that
at
its
own
peril,
but
it's
available
for
people
that
want
to
write
portable
applications
that
always
work
that
that's
sort
of
my
inclination
is
to
say.
Applications
have
to
be
flexible,
but
we're
going
to
give
them
a
signal
so
that
they
they
can
do
the
right
thing.
A
B
I
think
I
think
we
need
to
so
I
I
I
see
what
you're
saying
and
it
has
to
be
part
of
the
dow.
It
has
to
be
part
of
the
downward
api
that
the
workload
can
directly
observe.
It
can't
be
something
at
the
kubernetes
api
level,
because
no
one
writes
automation
at
that
level.
Right.
You
just
have
your
yaml
for
your
pod
and
your
image
for
your
application.
You
want
to
be
able
to
deploy
it
on
this
cloud
in
that
cloud.
A
B
A
Yeah
as
long
as
we
can
make
it
ignorable,
I
still
feel
like
this
is
like
a
step,
two
kind
of
thing:
don't
you
think,
or
do
you
think
we
need
to
make
it
into
the
api
now.
B
I
I
think
that
this
is
what
the
downward
api
is.
It
is
exactly
this,
it
is
which
authentication
mechanism
is
being
used
and
where
is
the
stuff
that
you
should
pull
from
and
we
can
try,
try
our
darndest
to
just
pick
file
names
and
path,
names
and
environment
variables
and
whatever
that
that
would
just
work
most
of
the
places
without
needing
any
magic.
But
we
still
need
to
have
like
a
very
explicit
pointer
to
say:
hey,
use
this
environment
variable
or
pull
from
this
url
or
read
this
file
name
yeah.
A
Have
that
mechanism
ben
the
question
is
what
we're
going
to
show
in
there.
I
guess
the
bucket
in
photo.
A
Yeah,
I
know
what
you
mean.
I
think
I
think
yeah
I
I
do.
I
see
what
you're
saying
in
the
downwards
like
there
needs
to
be
a
top
level
switch
that
says.
B
Like
this
is
the
authentication
mechanism
like
you
should
use
http,
and
here
is
the
url
or
you
should
read
from
a
file
and
here's
the
file
or
you
should
read
an
environment
variable
and
here's
the
environment
variable.
You
know
some
very
clear,
unambiguous
signal
about
which
mechanism
is
being
used.
What
is
where
to
find
it
and
what?
B
What
format
it's
in,
so
that
someone
who
wants
to
be
compatible
with
absolutely
everything
could
could
do
that
and-
and
that
is
the
essence
of
of
the
the
cozy
downward
api-
and
I
don't
see
any
way
to
punt
on
that.
Like.
A
Okay,
I
see
what
you
mean,
so
no,
I
was
so
I'm
also
thinking
of
it
from
the
api
side
from
from
the
user
api
side.
So
I
think
we
talked
about
so
this
seems
to
go
against
what
we
talked
about
two
weeks
ago
with
you
ben,
which
is
we
we
kind
of
said.
These
are
all
the
different
authentication
mechanisms
this
one
or
a
particular
bucket
access
class
is
going
to
support.
B
I
mean
there
will
be
implementations
where
there
is
no
choice
right,
it's
always
access
key
secret
or
it's
always.
You
know
cloud
service
account
token
and
no
one
gets
to
make
a
choice.
It's
just
it
is
what
it
is,
but
in
situations
where
there
is
a
choice,
the
guy
who
gets
to
choose
is
the
admin,
but
that
was
what
I
was
pushing
for,
and
I
thought
we
agreed
to
two
weeks
ago.
A
No,
I
see
what
you
mean
yeah,
no,
that's
what
you're
pushing
for
that
would
also
apply
okay.
So
so
what
would
the
apis
look
like
so
downward.
B
B
We
already
have,
I
want
to
see
it
like.
That
is
the
most
important
thing
from
my
perspective,
every
nothing
else
matters
if
we
don't
get
that
right.
So
so
that's
why
I
wanted
to
get
into
detail
on
like
if,
if
there's
a
url,
that's
like
points
to
you
know.
B
169.254.169.254
like
and
that's
the
canonical
way
of
getting
your
your
link,
local
credentials
from
a
cloud
provider
like
we
could
just
provide
that
url
and
then,
but
make
it
possible
for
the
cozy
driver
to
point
it
at
a
different
url,
and
then
you
would
have
another
degree
of
flexibility
where
you
could
basically
be
telling
the
sdk
like
pull
your
credentials
from
here,
and
it
doesn't
have
to
be
a
link
local
address.
It
could
be
more
flexible.
B
I
don't
know
that.
That's
a
good
idea
or
not,
but
like
you
know,
if
we,
if
we're
explicit
about
the
url
instead
of
just
saying,
go
talk
to
the
metadata
service,
it
gives
cozy
drivers
another
degree
of
power
to
say
oh
well,
maybe
I'll
put
my
credentials
over
here
and
then
people
will
have
to
pull
them
or
maybe
I'll
define
a
special
metadata
service
with
a
different
url.
B
I
I
don't
know
much
about
how
metadata
services
are
actually
built
into
working
clouds
because
it
has
to
be
part
of
the
infrastructure.
Typically,
yes,.
A
Yeah
so
I
mean
I,
I
don't
I
don't
that's
the
part
that
I
meant
was
like
day
two.
So
why
do
we
need
it.
B
B
I
I
mean
it's
just
I
don't
like
things
being
too
implicit
like.
If,
if
we
did
say
look,
it
only
works
with
the
link.
C
B
Metadata
service,
we
need
to
write
that
down
and
say,
like
very
explicitly
if
you
get
the
signal
that
says,
you
need
to
use
the
link
local
metadata
service,
then
this
is
exactly
what
you
should
do:
remove
this
url
and
get
this
thing
so
that
no
one
comes
to
us
later
and
says.
Well,
my
link
local
metadata
service
is
different
and
I
want
you
to
support
it
right.
We
want
to
cut
off
that
potential
complaint.
B
A
Okay,
so
so
I
what
we're
trying
to
do
is
exactly
that.
We're
trying
to
implement
our
own
or
that's
what
it
seems
like
see
as
far
as
cloud
environments
are
concerned
and
all
the
sdks,
the
wrong
cloud
environments
are
concerned,
it's
pretty
straightforward,
it's
always
a
the
cloud
defined
url.
Now
when
it
comes
to
vendors,
you
know
they
have
the
freedom
to
do
whatever
they
want,
but
as
step
one
I
mean
the
way
we
design
the
api.
It
doesn't
have
to
limit
us
to
just
the
cloud
type
of
authentication
mechanism.
A
So
let's
say
we
call
it
workload
id
right.
I
mean
we
can
call
it
anything.
Just
just
for
the
sake
of
this
exercise,
and-
and
let's
say
I
say
you
know,
the
provider
is
gke
or
the
provider
is
aws,
and
then
you
know
at
that
point.
It's
it's
already
pretty.
You
know
it's
it's
it's
implicit
with
these
two
providers
we
could
we
could
have
or
we
could
do
it
like
this.
A
You
know
say
gke
and
we
could
have
fields
that
go
in
there
and,
and
you
know,
as
we
need
to
expand,
we
can.
We
can
add
more
things
like
like
a
specific
url
if
needed.
I
think
I
think
you'll
realize
once
once
we
get
into
this
more
you,
you
don't
need
a
custom
url
as
such
for
these
official
providers,
maybe
for
vendors.
It
makes
sense.
A
But
again
it's
pretty
straightforward
at
this
point.
You
you
in
this
in
this
bucket
info
json,
which
already
is
needed
for
things
like
you
know.
What's
the
bucket,
you
are
what's
the
bucket
name
and
where
are
the
certificates
located,
and
things
like
that?
You
mean
this.
This.
This
is
a
great
way
to
this
can
be
the
great
way
to
deliver
the
authentication
information.
A
So
there's
a
bucket
info.json,
which
we
passed
down
to
the
part
that
goes
into
every
part.
That's
using
a
cozy
bucket.
You
are,
you
should
like
we've
talked
about
this
many
times.
B
The
supported
ones
I
mean.
A
To
mention
if
it's
just
aws,
nothing
to
mention,
but
just
in
you
know,
for
the
sake
of
expansion,
we
you
know,
we
make
it
a
structure
right
now.
It's
empty.
B
Right
but
but
then,
if
if
a
new
one
comes
along
tomorrow,
what
do
we
do?
Do
we
expand
our
downward
api
to
support.
E
A
B
What
we
owe
to
our
users
is
here
is
the
api,
and
it's
never
going
to
change.
If
we're
going
to
ask
them
to
support
it
completely
right,
what
what
I
was
hoping
we
could
get
to
was
like
an
api
that
covers
now
and
forever
all
the
things
that
that
we
would
need
like
barring
some
brand
new
technology,
that
no
one
ever
imagined.
I
like.
E
Complicating
it
it,
it
gets
even
more
it's
worse
than
that,
because
then
any
new
vendor
has
to
wait
for
you
to
accept
them
before
they
can
start
making
use
of
the
api.
B
B
A
No,
the
problem
is
different
here.
The
the
the
difference
between
this
and
pretty
much
other
infrastructures,
we've
standardized
and
kubernetes-
is
that
there's
a
very
limited
set
of
vendors
or
very
limited
set
of
protocols
when
it
comes
to
object,
storage.
A
This
is
just
gcs.
There
is
amazon's
s3
and.
B
B
A
So
so,
let's
talk
about
it
from
the
perspective
of
a
sdk,
s3
sdk
or
a
gcs
sdk.
They
only
work
with
one
specific
style.
So
a
protocol,
specific
sdk
works
only
with
one
specific
style
of
metadata
or
you
know,
authentication
you
can't
it's
it.
I
I
just
don't
see
an
s3
sdk
like
if
you
want
portability.
The
portability
very
much
depends
on
the
application
layer
and
and
as
of
now
talk
talk
me
through
the
s3
sdk
and
whatever.
B
A
Specifically,
oh
okay,
I
can
just
show
you
it.
It
only
works
with
the
s3
style,
metadata
credentials,
so
aws.
A
B
B
Service,
it's
just
the
metadata
service,
then
anyone
who's
compliant
with
that
it
just
works
and
that's
the
end
of
and
then
and
then
there's
no
and
then.
If
someone
new
comes
along
in
the
future
that
supports
the
metadata
service,
they
don't
have
to
do
anything.
The
api
doesn't
have
to
change.
They
just
implement
the
existing
api.
That's
where
we
have
to
be
that.
A
You
had
a
the.
B
A
I
was
I
was
putting
that
in
there
ben,
because
you
know
we
were
going
down
this
path
of
having
a
you
know,
url
specified
for
metadata,
and
I
wasn't
sure
why
that
was
needed.
Oh,
why.
B
I
was
just
I
was
thinking
it's
even
one
level
more
flexible
than
saying
like
use
the
standard
metadata
url
right,
because
if
it's
the
same
all
the
time,
we
could
just
provide
it
and
then
reserve
the
right
to
change
it
in
the
future
and
just
say
like
we're,
gonna
give
you
the
url
go,
read
it
and
you'll
be
fine,
and
then
we
for
the
first
version.
We
could
always
give
you
the
same
url,
but
it
would
free
us
up
to
in
the
second
version,
give
you
a
different
url.
C
B
Like
that's
not
important
right,
if
this
is
the
way
it's
done,
we
can
do
it
that
way.
The
main
thing
is
with
the
api
when
it
reaches
ga,
we
should
have
zero
plans
to
ever
change
it,
because
this
is
our
compatibility.
This
is
our
backwards
compatibility
layer.
This
is
you
write
a
workload,
that's
cozy
compatible
and
it's
gonna
work
this
year.
It's
gonna
work
next
year
and
it's
going
to
work
the
year
after
and
you
know,
as
more
people
have
more
more
drivers
and
more
people
have
more
stuff.
It
should
just
continue
to
work.
Yep.
A
I
mean
we
can
even
go
a
step
further.
How
much
time
do
we
have?
Okay,
it's
been
half
an
hour
already,
but
we
can
even
go
a
step
further
and
just
say
how
what
do
they
call
it
here?
They
call
it:
credential
provider
endpoint
credentials
easy
to
roll.
Let's
see
and.
D
Yeah,
sorry,
no,
I
think
I
just
wanted
to
just
comment
and
from
a
generic
standpoint
about
like
the
way
that
we
do
apis
but
but
generally
like.
Unless
we
have
like,
we
need
to
have
specific
use
cases
where
we
know
that
the
api
is
gonna.
Work
it'll
be
pretty
hard
to
come
up
with
an
api
where
we
guess
what
the
future
might
be.
I
think
that's
the
only
generic
comment.
I
have.
C
D
B
B
D
B
Yeah,
I
I
I
would
like
to
get
at
least
the
downward
api
comprehensive
to
the
point
where
someone
could
code.
You
know
once
we
reached
ga,
someone
could
go
to
workload
and
expect
it
to
just
continue
working
for
years
and
years
and
never
to
break,
because
we
decided
to
add
a
feature
to
cozy
that
they
didn't
know
about
like
that,
and.
D
B
So
so
so
that
in
yes,
yes,
I
totally
agree
with
that.
But
when
it
comes
to
like
the
authentication
mechanism,
what
we've
said
is
we're
only
going
to
give
you
one
and
we're
going
to
force
you
to
support
the
list
of
possible
ones
that
could
exist
and
then
it's
not
fair
to
both.
Do
that
and
say,
oh
when
we
reserve
the
right
to
add
more
that
we're
not
telling
you
about.
B
B
D
C
D
Do
you
need
the
like
endpoint
url
of
the
bucket.
A
E
C
A
Focusing
on
the
on
the
credentials,
part
of
it
so
I'll,
just
put
a
dot
dot
for
the
rest
of
the
things.
A
Yeah
you
do
need
an
endpoint
url,
especially
for
non-standard
buckets
non-standard
providers
like
aws
gov
cloud
or
aws
china,
or
just
vendor
specific
implementations.
D
So
if,
if
say
the
provider
is
access
key,
then
is
there
another
like
struct
with
the
actual
key
information
in
here.
A
And
that
would
also
apply
to
other
other
ones
right,
as
in
as
in
you
know,
metadata
service,
maybe
metadata
service
doesn't
have
anything,
but
a
third
one
that
we
add
in
the
future
might
might
might
have
fields
too.
So.
A
B
B
This
uses
a
memory
map
file
right,
yeah
yeah,
it's
all
memory
maps
stuff,
but
the
point
is
there
could
be
other
components
that
are
responsible
for
pulling
the
secret
out
of
some
key
store,
decrypting
it
and
then
dumping
it
into
a
temp
fest
into
a
file
of
their
choosing,
and
all
we
can
do
is
just
point
at
that:
secret.
Okay,.
B
B
Yeah
we
should
just
we
should
decide
on
something,
but
the
specif
that
is,
that
is
specific,
but
it
doesn't
matter
what
what
it
is
until
we
decide
it,
yeah
it's
a
file
or
it's
either
embedded
or
it's
the
path
to
a
the
place
where
you
read
it.
A
Yeah
so
file
our
values;
okay,
let's
just
call
it
this.
B
B
A
Yep,
no,
that's
a
good
point
all
right,
so
just
that
I
buy
the
argument
that
you
know
it's
better
to.
Let
know
the
csi
secret
magic
do
it.
I
just
like
this
just
because
we
can
end
it
at
that
right
or
do
you
still
want
the
access
key
somewhere.
B
Yeah,
I
don't
know
I
haven't
again:
I'd
want
to
see
like
an
example
of
this
working
in
practice
and
then
say
like
yeah,
this
seems
usable
and
then
we
can
just
intuitively
like.
I
think
the
access
key
is
not
sensitive
and
you
could
safely
embed
it
in
the
file
and
I
think
the
secret
is
sensitive
and
should
be
a
file
name
that
points
elsewhere,
that
that
feels
like
the
safest
thing
to
do.
But
maybe
people
do
put
their
access
keys
in
the
same
secret
file
as
secret
keys,
and
you
have
to
do
some
well.
B
A
A
So
I
mean
I
don't
mind:
putting
an
access
key
here,
embedded
access
key,
but
the
secret
is
there
access
key
goes
here
and
then
secret
key
file.
We
can
call
it
and
it's
just
the
raw
secret
key.
A
Yeah
to
me
it
doesn't
matter
because
you
know
I
I
actually
want
to
see
the
specific
protocol,
specific
access,
key
files
that
already
exist
and-
and
you
know,
come
up
with
a
scheme-
that's
similar
to
that.
But
since
I
don't
have
it
handy
in
front
of
me,
I'm
just
this.
This
makes
so
this
makes.
A
A
You
know
access
secret,
key
or
metadata
service
yeah,
some
of
that
and
then,
if
it
is
access
secret
key,
then
you
get
that
sub
field.
If
it's
metadata
service,
you
get
nothing.
A
B
A
A
path
yeah:
this
is
the
argument
we're
just
having
so
so.
Ben
had
a
good
point
where
there
are.
There
are
special
mechanisms
that
that
different
secret
providers
have
like
walt
and
and
kubernetes
works
with
it
well
to
securely
put
the
secret
into
the
part
where
it
can't
be
stolen
easily.
So
we
want
to
rely
on
that,
if,
if
possible,
by
by
making
it
a
actual
string,
we
lose
that
ability.
A
But
if
we,
if
we
were
to
make
it
a
part,
then
then
we
can
rely
on
the
existing
infrastructure.
So
then
you're
requiring.
B
Which
is,
it
makes
sense
from
a
kubernetes
point
of
view.
Now,
maybe
sdks
don't
behave
well
with
that,
and
we
need
to
do
something
else
to
be
sdk
compatible,
in
which
case
I'm
willing
to
change
it.
But
like
again,
I
would
I
want
to
see
concrete
examples
that
that
are
actually
working
and
then
we
can
evaluate
whether
they
feel
gross
or
whether
they
have
problems.
A
So
so
the
question
is:
yeah,
there's
extra
work
that
needs
to
be
done
from
the
sdk
site
to
to
pass
this
process
file.
But,
but
you
know
we're
doing
this
in
in
the
you
know,
the.
B
B
Well,
it
could
be,
it
could
be
handed
off
as
they
handle
to
a
secret
that
some
that
is
encrypted
in
vault
and
that
we
never
have
to
touch
it.
As
long
as
we
have
the
handle
to
it.
We
can
say
we
can
instruct
the
csi
secrets
driver
to
plummet
into
the
pod
and
then
provide
a
pointer
to
where
it's
going
to
be
plumbed
in
and
on
our.
A
B
B
B
B
A
E
A
E
A
B
A
I
I
don't
mind
file
pattern
for
everyone.
To
be
honest:
if
everyone's
gonna
do
file,
that's
fine
and
we
can,
we
can
standardize
it
to
whichever
file
format
they
they
prefer,
like
aws,
has
its
own
way
of
specifying
access,
key
and
secret
keynote
file.
Gcs
does
the
same,
and
azure
has
its
own
too.
So
why
not
just
call
it
access
secret
key
file,
and
we
we
really
don't
have
to
mess
with
anything.
We
just
kind
of
take
the
secret
from
somewhere
and
put
it
put
it
in
the
excuse.
E
E
A
I
I
want.
I
want
to
quickly
also
define
the
other
side
of
the
api,
the
user
side
of
it.
I
don't
know
where
we
ended
up,
but
I
just
want
to
make
sure
we
have
we.
You
know
we're
all
on
the
same
page
about
that
when
you
say
the
user
side,
which.
B
B
A
A
And
let's
also
have
one
for
kubernetes
admin
all
right,
so
the
kubernetes
user
is
going
to
be
creating
a
bucket
access
objects
where
so
bucket
access
is
namespace.
Now.
A
All
right
so,
okay,
so
then
we
have
so
currently
what
they
ask
for
is
they
ask
for
they
ask
for
access
to
a
specific
bucket.
A
Let's
again
call
it
abc,
and
so
they
don't
they
don't
say
what
protocol
they
want.
A
So
so
so
my
question
here
is
in
this
model:
they
don't
get
to
specify
protocol
and
they
don't
get
to
specify
authentication
mechanism
too,
which
is
in
line
with
what
you
were
saying.
Ben
and
I
agree
with
that,
which
is
the
admin
gets
to
say
what
authentication
mechanism
has
to
be
used
in
this
environment,
and
the
application
should
just
support
it
right.
A
F
F
Okay,
so
till
now
the
protocol
was
part
of
the
bucket
class
right,
not
the
part
of
bucket
access
class.
A
Sure
yeah
yeah
yeah,
it
was
a
part
of
the
bucket
class,
so
fair,
so
the
bucket
class
is
is
the
set
of
properties
for
provisioning
a
bucket,
and
the
bucket
access
class
is
for
properties
about
the
kind
of
credentials
you're
getting
for
that
bucket.
So.
A
So,
let's
also
call
this
abc-
and
here
you
say:
credential
provider
again.
A
A
B
B
Sorry,
the
service
account
associated
with
the
user,
so
yeah
there'd
have
to
be
a.
We
have
to
figure
that
out
at
the
grpc
layer.
How
does
the
cozy
controller
communicate
with
the
driver
to
establish
those
secrets,
but
the
format
of
the
secret
is
the
drivers
choosing
and
the
controller's
responsible
for
giving
it?
B
Whatever
information
is
necessary
to
grant
the
access
so
like
for
an
access
key
secret
key
the
the
controller
owes
nothing
to
the
driver,
the
driver
just
create
you
know:
mints
an
access
key
and
a
secret
key
and
hands
it
back
and
says
here
it
is
for
a
for
a
service
account.
You
have
to
sort
of
pass
down
which
service
account.
It
is
so
that
the
driver
can
go
grant
the
access
to
the
specific
service
account
in
question,
and
so
that's
going
to
be
a
grpc
concern.
B
I
I
just
I
don't
see:
what's
for
the,
for
the
the
configuration
should
be
done
in
the
driver,
and
the
driver
should
just
tell
the
controller
what
it's
what
it's
using
and
then
the
controller
doesn't
need
any
configuration,
because
you
can
always
find
out
from
the
driver
what
what
acc,
what
security
mechanism
is
being
used,
and
that
makes
it
really
easy
to
write
a
driver.
That
only
supports
one
security
mechanism,
which
is
what
I
imagine
most
of
them
will
be.
How.
A
Right
yeah,
my
question
is:
do
we
need
something
like
you
know,
csi
has
the
csi
driver
object
the
api?
We
don't.
We
don't
need
that
right,
like
a
cozy
driver.
I.
A
Cool
okay,
so
this
would
work.
B
Like
that,
I
don't
no,
I
don't
think
so.
I
think
that
it's
it's
meant
to
piggyback
on
the
service
account
that
your
pod
would
already
be
using
it's
like
when,
when
you
create
a
when
a
specific
kubernetes
user
creates
a
bucket
access
and
the
controller
reacts
to
that
by
going
and
minting
the
credential,
it
needs
to
know
the
service
account
associated
with
the
namespace
that
created
that
bucket
access,
so
that
they
can
grant
access
and
it'll
get
messy.
B
A
A
You
know
part
whatever
it
can
be
whatever,
and
so
they
call
it
ksa
kubernetes
service
account
and
in
google
cloud
you
create
a
iam
policy
binding
that
binds
a
google
service
account
to
a
particular
role.
A
A
B
B
B
A
A
B
A
B
Well,
I
don't
know
the
the
the
reason
it
feels
weird
is
because
if
if
what
the
admin
has
chosen
or
what
the
driver
has
implemented
is
just
access
to
secret
key,
then
which
service
account
you
specify
will
end
up
getting
ignored
right
because
we
don't
care
access.
Key
secret
key
is
going
to
work
for
all
of
your
service
accounts,
so
you
could
specify
alice's
service
account
and
then
bob
could
create
a
pod
and
it
will
still
work.
And
then
that
will
seem
strange
because
it's
like
wait.
I
only
wanted
to
grant
access
to
alice.
B
A
I'm
just
confused
about
what
changed
like
this
is
we
we
agreed
on
this,
and
so
it
doesn't
mean
just
because
you
agree
on
it
doesn't
mean
it's
always
right,
but
more
along
the
lines
of.
How
is
this
not
a
problem
before
I?
I
think
we
hand-waved
past
it
before
I
see
okay,
so
so
what
you're
saying
is
what
you're
saying
is
we
currently
yeah?
A
So
we
just
removed
it,
for
you
know
for
the
last
last
revision,
because
we
wanted
to
make
it
simple
and
specifically
say
that
we
want
those
service
accounts
that
was
kind
of
our
stance,
but
that
was
just
the
last
revision,
but
all
along
until
then,
we
were
saying
that
we're
also
going
to
have
a
service
account
field
in
here
and
and
sorry
repeat,
your
concern
again.
B
My
concern
is
that
we,
you
must
specify
it
in
order
for
this
service
account
based
authentication
to
work
right,
because
if
there's
more
than
one,
we
don't
know
which
one
to
grant
access
to.
So
if
you
leave
it
blank
like,
we
won't
know
what
to
do.
We
can't
grant
access
to
anyone
right,
but
if
you're
using
access
key
secret
key,
then
they
could
put
a
service
account
in
there,
but
we're
going
to
ignore
it,
and
then
it
creates
a
strange
situation
where
you
can
intend
to
grant
access
to
alice.
But
then,
when
bob.