►
From YouTube: Secrets Store CSI Community Meeting - 2022-02-03
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Okay,
so
we
can
take
a
look
at
the
agenda.
I
think
the
first
one
was
something
that
I
added
right
now.
A
So
basically,
we've
merged
this
pr,
which
adds
a
new
token
client
in
the
driver
that
will
actually
generate
the
service
account
tokens
which
I
think
today
the
providers
are
doing
that
for
workload,
identity
or
like
the
federation
scenarios
right.
So
I
think
walt
is
doing
it
and
gcp
is
doing
it
and
then
we're
going
to
be
adding
it
to
azure.
So
I
thought,
let's
just
do
this
in
a
backward
compatible
way
in
the
driver.
A
So
what
this
change
does
is
anything
121
above
basically,
it
will
generate
the
token
and
then
it
will
add
it
in
the
same
format
that
cubed
adds
the
service
account
tokens
and
then
it
also
reuses.
The
api
field
that
is
available
in
the
csi
driver,
so
csi
driver
has
this
token
request
where
you
can
specify
the
audience
and
the
expiration
seconds.
A
So
we're
just
reusing
that
if
cubelet
doesn't
give
it
as
part
of
the
mount
request,
we
will
generate
it
in
the
driver
and
then
send
it
to
the
providers
and
then
now
we
are
also
doing
this
for
rotation
as
well,
so
which
means
we've
covered
the
token
scenarios
and
everything
in
the
driver
and
then
providers
can
stop
generating
the
token
on
their
own
and
one
good
thing
is:
we
were
able
to
reuse
the
cubelet
token
generation
package
which
takes
care
of
caching,
so
we
are
actually
not
generating
a
token
every
10
minutes
or
like
periodically,
rather
we're
just
looking
up
cash.
A
If
it's
expired,
then
we
reach
and
create
it,
and
then
we
also
clean
it
up
from
cash
when
the
part
goes
away.
So
I
think
one
way
providers
can
leverage
this
like
if
they're
already
generating
tokens
check.
If
the
annotation
it
exists,
the
ca
token
sa
tokens
annotation
in
the
attribute,
if
it
does
not,
then
basically
generate
it.
So
that,
like
you,
are
also
backward
compatible.
But
if
the
tokens
already
exist
in
the
attributes
you're
getting,
then
you
can
just.
A
A
D
What
are
the,
what
the
scenarios
in
which
there'd
be
multiple,
the
the
plural,
makes
me
think
it
might?
Is
it
an
array
of
tokens
potentially.
A
Yeah
I
mean
if,
for
some
reason,
the
provider
wants
tokens
with
multiple
audiences
like
targeted
one
forward
and
then
like
for
gcp,
like
let's
say,
you're
running
two
providers.
Then
it's
just
an
array
here,
so
they
give
audience
gcp
and
then
they
also
give
audience
board
and
then
the
tokens
will
have
both
of
it.
When
you
unmarshal
it,
you
will
just
have
a
map
for
each
audience.
C
A
Right
so
yeah
in
terms
of
permissions,
there
are
two
additional
permissions
right.
One
is
because
we're
following
the
same
cubelet
path:
one
is
we
want
to
get
the
csi
driver
and
see
what
all
audiences
are
configured
in
it.
So
this
is
enabled
by
default,
because
it's
not
very
high
level
permissions.
It's
only
get
list
and
watch
and
then
also
we
are
only
doing
it
for
our
driver
name,
nothing
more,
but
the
second
permission
is
basically
the
service
account
create
a
service,
account
token
create
and
delete
the
create.
So
this
at
least
for
help.
A
We
are
putting
it
behind
the
check
where,
if
the
user
configures
token
request
only
then
we
take
that
permission
and
then,
if
they're
going
to
install
with
the
deploy.aml,
then
again
we're
just
going
to
tell
them
that
hey,
if
you're,
using
the
driver
for
token
generation,
then
install
this
role,
but
if
you're
not
then
just
skip
it
so
we're
following
the
same
format
that
we've
been
doing
today,
first
in
secrets
or
rotation
and
all
those.
So
it's
all
separate
animals,
and
only
if
they
want
to
install
it.
C
And
then
I
think
the
the
thing
we
discussed
in
the
pr
was
that,
like
in
the
future,
we
can
actually
remove
that
permission
once
required
to
republish
is,
is
supported
in
all
supported
versions,
right
right.
A
Yeah
so
like
right
now
for
1.1,
it's
this
and
then
I
think
the
plan
for
1.2
is.
We
switch
to
requires
republish
for
rotation,
because
120
is
going
to
be
end
of
life
soon
and
request.
Republish
is
a
feature
where
cubelet
will
periodically
review
by
the
mount
file
and
basically
give
us
the
token
in
every
call,
which
means
we
don't
have
to
do
all
this
customer
rotation
logic
and
all
that
in
our
code.
A
So
we
were
thinking
in
1.2.
We
can
introduce
it,
and
I
think
that
aligns
with
the
timeline
when
120
goes
end
of
life.
So
we
can
say
1.2
works
well
with
121,
plus
kubernetes
version,
because
that
that
would
be
that's
already
default
right
now
and
if
things
go
well
and
if
you
get
good
feedback
from
users
or
no
issues,
then
we
can
actually
graduate
rotation
to
ga
in
1.3
release
like
as
a
feature.
A
B
And
one
more
thing
is
like
we
have
done
this
change
with
backward
compatibility
mine
in
mind,
and
so
we
are
going
to
keep
that,
as
is
right
when
we
are
not
going
to
remove
it.
Correct.
A
Yeah
the
token
claim
we
don't
have
to
remove
it,
so
you
can
keep
it
for
a
while,
like
it
will
generate
the
token
for
older
versions
where
it's
not
there,
but
with
the
required
republish.
If,
if
we
say
the
driver
only
works
with
121
like
if
we
have,
I
mean
we
have
to
say
that
right,
because
if
rotation
has
to
work,
we
have
to
tell
that
it
works
at
a
certain
version.
A
So
at
that
point
we
don't
need
any
of
this.
Like
big
changes
like
everything.
B
Right,
actually,
my
point
was
like
I
mean
we
are
we
probably
not
going
to
cut?
Let's
say
2.0
right
so
for
the
semantic
aspect
of
it,
we
should
always
maintain
this
backward
compatibility.
Right
I
mean
we
are
not
going
to
deprecate
this
down.
The
line
I
mean
this
backward
compatibility
is
what
I'm
going
to
say.
A
At
some
point,
if
we
switch
to
request
republish,
we
have
to
say
which
minimum
kubernetes
supports.
Like
I
mean
we
are
not
changing
anything
in
the
user
facing
api,
but
the
minimum
version
required
to
run
this
particular
will
be
dependent
on
the
feature
and
then
only
in
121.
It's
enabled
by
default
right.
A
B
C
I
heard
like
that.
The
rotation
feature
of
the
csi
driver
isn't
part
of
our
like
ga
feature
set,
that's
still
either
alpha
or
beta,
and
so
that's
why.
I
think
there
can
be
some
changes
to
implementation
here
and
we
can
add
the
harder
requirement
for
requires
republish
kind
of
just
before
we
mark
the
rotation
feature
as
sga.
B
A
Okay,
the
next
one
was
removing
hold
the
helm
package,
so
we
have
an
approval
on
this,
but
I
just
wanted
to
bring
it
up
here,
so
we've
renamed
our
branch
from
master
to
main
and
then,
as
part
of
that,
we
also
moved
all
our
charts
to
github
pages,
so
we've
changed
our
helm,
url
and
then
we
have
put
out
a
note
which
was
there,
I
think
for
like
five
months
now.
So
I
think
it's
finally
time
to
clean
up
all
the
old
packages
that
we
have
in
the
main
branch.
A
So
I
open
this
pr.
So
we're
deleting
that
also
when
we
moved
everything
to
github
pages,
we
moved
all
the
old
packages
there
as
well.
So
if
someone
is
still
using
a
really
old
version
and
if
it's
still
available
there-
but
I
just
wanted
to
bring
it
up
here
so
everyone's
okay
with
it.
A
Cool
next
one
is
file
system
permissions.
Tommy,
do
you
want
to
talk
about
it.
C
Yeah
we
may
have
talked
about
this
last
time,
but
there's,
I
think
at
least
two
issues
currently
that
we
were
targeting
for
1.,
1
or
1.2
about
supporting
just
different
file
system
permissions,
and
I
wanted
to
bring
it
to
the
attention
that
I
think
the
azure
provider
has
gone
like.
I
did
some
testing
on
the
gcp
provider.
I
haven't
merged
a
pr,
but
it
works
with
just.
C
If
you
set
file
permissions
on
the
response
to
the
driver,
things
work
as
expected.
So
since
the
providers
have
the
map
of
like
files
from
the
secret
provider
class,
I
think
the
azure
provider
has
extended
their
specific
camel
to
support
inputting
file
permissions
so
like
these
are
bugs
in
the
driver.
C
It
is
possible
to
solve
them
in
the
providers
exclusively,
and
so
I
think
our
kind
of
implicit
decision
was
gap.
Providers
can
return
the
permissions
of
the
files
that
they
want
written
and
so
providers
should,
you
know
like
if
they
want
to
support
non-default
permissions.
It's
right
now,
gonna
be
a
up
to
providers
kind
of
to
to
extend
their
their
game
all
to
support
that.
If
that
makes
sense
because
yeah
I
was
gonna
close
out
these
issues
with
that
information,
but
wanted
to
kind
of
bring
it
up
in
this
form.
First.
B
One
thing
just
kind
of
suggestion,
or
I'm
just
putting
it
out
here
like
maybe
so
like
the
way
that
you're
doing
your
product
right
now
is
just
in
a
secret
product
class.
It's
just
a
map
right
so
or
sorry.
I
guess
so.
I
just
map
so
we're
just
adding
a
a
different
key.
So,
for
example,
we
have
like
a
key
name
file
permission
and
we
just
gave
it
so
I'm
just
thinking
like
maybe
we
all
provider
can
keep
that
key
name
same
I'm.
B
Just
I
mean
we
don't
have
to
I'm
not
sure.
If
there
is
there
are
any
implementation
implication
of
this,
but
just
kind
of
suggestion,
if
it's
possible
so
that
way,
maybe
we
can
put
a
note
in
the
driver
as
well
like
the
provider
have
implemented
this
particular
key,
or
maybe
we
can
just
redirect
to
particular
providers
implementation
or
something
like
that.
C
I
don't
I'll
take
a
look
at
that,
like
the
at
least
on
the
gcp
one.
We
use
just
a
list
of
maps
for
files
where
we
use
the
like
key
path
for
like
where
the
file
should
go,
where
I
think
in
the
azure
one.
It's
like
a
object
name
so,
like
I
think,
there's
already
some
differences.
C
Yeah,
I
think
the
the
future
issue
that
may
came
up
that
may
come
up
is
like
a
way
to
override
the
default
for
all
files,
but
I
think
we'll
close
out
the
existing
issues
and.
A
A
D
You
have
do
you
have
an
example
of
like
what
the
current
what
the
current
config
looks
like
for
file
permission,
because
I
feel
like
there
is.
I
I
I'm
a
bit
foggy
because
yeah
as,
as
you
say,
the
the
vault
provider,
just
it
receives
like
a
permission
image
in
the
grpc
request
and
then
just
returns
the
same
thing
back
in
the
response.
Basically,
but
I
can't
remember
how
that
permission
from
the
driver
actually
gets
set.
Is
it
actually
configurable
from
the
driver
at
all,
or
is
it
just?
C
A
constant
right
now,
just
hardcoded
into
the
driver,
so
there's
not
a
flag
and
it's
not
taken
from
the
secret
provider
class.
So
that's
that'll,
probably
be
the
like
a
follow-on
issue
of
like
it
cannot
be
configurable,
but
in
terms
of
just
supporting
file
permissions,
it
is
possible
for
providers
to
do
that
like
if
you
return
a
permission,
it
will
be
honored.
B
A
A
A
Have
it
as
an
option,
but
we
can
start
at
the
driver
level
like
that's
that's
why
I
think
what
tommy
said
like
we
make
it
configurable
first
at
the
driver
with
the
flag
and
then,
if
we
get
request
that
they
want
to
do
it
per
secret
provider
class
and
not
do
it
for
each
individual
object,
then
we
just
introduce
another
tree,
makes
sense.
Yeah.
C
Cool
yeah,
sorry,
yeah
and
then
the
next
one
is
just
there's
a
bug
about
like
where
providers
listen,
where
the
unix
socket
that
they
listen
in
the
file
system
is
where
currently
it's
under
hc
kubernetes
and
the
issue
was
that
var
run.
Something
is
a
more
semantically
correct
place
for
it.
So
there's
one
vr
to
that.
Just
changes
it,
but
I
have
a
prn
draft
to
do
it
in
a
backwards
compatible
way
where
the
driver
will
check
multiple
locations,
and
so
I'm
hoping
to
get
that
done
soon.
C
So
I
would
yeah
rather,
I
think
those
like
two
meetings
ago.
We
talked
about
this
issue
and
talked
about
doing
it
in
a
backwards
compatible
way,
instead
of
doing
like
a
hard
cut
over
from
like
one
five,
two
to
one.3
or
something
so
started
on
that,
but
haven't
finished
it
yet.
A
Okay,
I
think
that's
all
we
have
in
the
agenda.
I
think
yeah
tom
had
mentioned
about,
like
the
other
changes
that
were
there
right.
I
think
the
last
one
which
was
the
migration
was
the
driver
right
secrets,
one.
I
think
all
the
most
of
the
providers
now
have
defaulted
to
that,
like
I
think
I
saw
vault
also
published
for
1.0
and
then
that's
awesome
and
then
gcp
also
has
a
1.0
and
then
azure
also
has
1.0,
where
all
of
us
are
doing
right
driver
is
writing
the
secret.
A
A
But
yeah,
maybe
we
can
see
if,
when
they
plan
to
do
it
like,
I
think
we
can
open
a
github
issue
and
see
if,
when
they
plan
to
do
it,
and
then
we
can
close
out
this
one.
C
I
think
maybe
something
we
should
also
do
is
re-look
like.
C
I
think
we
want
to
get
out
the
1.1
out
soon,
but
after
that
we
look
at
our
provider
implementation
documentation
since,
like
in
this
meeting,
we
talked
about
a
few
things
of
like
moving
from
you
know
the
var
run.
C
File
system
permissions
we
could,
we
could
probably
this
could
probably
use
an
update,
yeah.
A
Okay,
anything
else
that
anyone
on
the
call
wants
to
talk
about.
A
So
yeah,
I
think,
for
the
1.1
like
we
were
thinking,
we'll
cut
an
rc
image
first
and
then
like
after
day
or
two
just
start
test
it
and
then
make
sure
it
looks
good
and
then
publish
the
1.1.
So
is
that
okay.
C
Yeah,
oh,
wait
I'll.
Add
another
action
item
I
don't
know.
Should
we
send
out
like
a
doodle
poll
like
we've
talked
about
changing
the
time.
A
D
I'm
easy,
I
I
don't
mind
catching
up
on
recordings.
I
don't
want
it
to
be
all
scheduled
around
me.
I
think
I
actually
have
like
a
meeting
clash
like
if
it
went
over
an
hour
forward,
but
yeah,
like
I
say,
don't
don't
schedule
it
just
around
me.
B
So
here
is
an
interesting
point,
I
mean
we'll,
I
think,
probably
start
daylight
saving
in
march
again
and
we
are
like
almost
mid
february,
so
I
mean
one
of
the
motivation
behind
that
is
since
daylight,
having
ended
in
november.
Maybe
should
we
rethink,
but
I'm
not
sure
if
we
just
take
out
this
timing
and
then
go
into
daylight
saving,
I
guess
but
yeah,
okay.
A
Okay,
I
will
send
out
the
doodle
like
I'll,
send
it
out
this
afternoon,
let's
see
what
the
consensus,
if
it's
late,
I
think
that
that's
fine
too,
but
we
can
see
like
what
time
breast
works
for
all
of
us.