►
From YouTube: Secrets Store CSI Community Meeting - 2022-08-04
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
Hey
everyone
welcome
to
the
csi
secret
store
community
call
today
is
august
4th
this
call
is
recorded
and
will
be
published
to
youtube
and
falls
under
the
cnc
code
of
conduct.
A
C
A
We
have
a
pretty
small
agenda.
I
think
the
first
one
is
follow
up
today's
pr
and
then
the
second
one
I
just
had
it.
D
So
I
can
share
my
screen
and
kind
of
talk
a
little
bit
about
the
changes
in
the
code
based
on
just
kind
of
what
we
talked
about
last
meeting.
C
D
Okay,
which
screen,
can
you
see,
can
you
see
vs
code,
yep,
okay,
yeah,
so.
D
Yeah
so
like
my
in
my
original
implementation
for
for
trying
to
help
and
syncing
multiple
secrets
based
on
a
file
being
mounted
as
a
adjacent
object.
I
I
added
this
sync
options:
field
to
the
secret
provider
class,
where
the
behavior
was
to
tell
the
driver
what
it
should
expect
that
mount,
what
format
that
mount
should
be
in
and
then
which
path
on
the
json
object
to
target
and
then
sync
all
those
secrets.
D
And
then,
in
our
discussion
last
week,
based
on
tommy's
feedback,
we
mentioned
that
it
might
be
better
to
actually
just
transform
the
the
mount
or
do
some
transformation
before
the
mount.
So
the
driver
receives
a
json
object
and
then
we
could
tell
the
driver.
D
D
So
with
this
object
here
we
should
expect
the
full
volt
json
response
and
then
the
driver
targets
the
data.datapath
in
that
json
response
and
then
mounts
each
key
value
pair
as
its
own
file
and
like
we
could
see
that
here
with
the
within
the
secret
objects.
I'm
I'm
using
the
db
creds
object,
name
and
then
the
name
of
the
file
is
the
name
of
the
key
in
the
json
object
on
that
path.
D
So
just
for
the
sake
of
being
verbose
and
demonstrating
the
concept,
I've
targeted,
the
individual,
username
and
password
keys,
like
we
normally
would
with
the
driver
now,
in
addition
to
targeting
the
full
json
object
and
I've
mounted
those
secrets,
as
plain
tech
secrets
so
like
in
the
terminal
at
the
bottom,
I'm
in
the
container
now,
and
if
I
I
run
that
ls
we
could
see,
we
have
two
directories.
There's
the
database
directory
and
the
db
creds
directory.
D
So
if
I
ls
into
the
database
and
I
ls
into
the
db
creds,
we
see
the
same
information,
the
only
difference
being
that
for
db
creds.
We
didn't
actually
have
to
make
the
effort
to
specify
each
key
that
we
wanted
to
get
from
the
vault
secret
and
also
we
didn't
have
to
specifically
name
the
the
object
name
like
based
on
the
full
path,
including
the
name
of
the
file.
The
name
of
the
file
is
based
on
the
key.
That's
found
in
the
json
object.
D
And
all
of
this
is
done
right
after
the
client
mount
call
to
the
provider.
So
if,
if
files
are
detected
in
the
response,
then
the
driver
will
loop
through
those
files
and
check
to
see
if
there's
any,
that
have
a
json
format
and
then
from
there
it'll
create
new
files,
a
new
files
list
with
those
in
with
those
those
key
value
pairs
found
in
the
json
objects
created
as
their
own
files.
E
I
have
one
question
here:
I'm
still
confused
on
the
part
where
how
are
we
determining
the
json
structure,
because
that
is
highly
dependent
on
what
provider
is
going
to
send
back
right?
So
so,
like
the
dot
data
dot
data
that
you
have
mentioned
in
the
spc
right?
That
is
specific
to
probably
what
not
sure
about
aws.
E
E
How
will
it
know
like
the
first
object
or
the
first,
what
we
can
say
the
first
layer
of
that
json
will
always
be
key.
What
if
it's
a
complex
json
object?
I'm
not
sure
if
that's
even
going
to
be
the
case,
but
still.
D
Right
so
I
I
want
to
make
sure
I
grab
that
first
part
of
your
question,
you're
you're
mentioning
or
you
were
asking.
How
does
the
driver
like
know
which
which
path
to
target
or
because
could
you
repeat
the
first
question
again
yeah.
E
E
Some
kind
of
an
assumption
that
we
are
making
here
while
parsing
the
json
content
or
what's
the
logic
behind
that.
D
So,
like
I
know
this
isn't
true,
but
just
for
the
example's
sake
like
if
aws
returned
a
json
object
and
its
key
value
pairs.
Let's
say
they
were
just
top
level.
They
weren't
nested
like
in
the
vault
response
like.data.data,
then
you
could
just
like
in
the
json
path,
specify
you
want
the
top
level
just
that
dot
or
we
could
even
just
take
it
out
altogether.
The
default
could
be
look
at
the
top
level.
E
Sure
so
so
the
entry
point
is
fine,
maybe
maybe
I
think
it
will
help
do
you
have
like
a
json
response
from
the
wall
or
something
like
that.
C
E
C
E
C
E
I
don't
know
so,
for
example,
and
that's
that's
what
probably
I'm
not
sure
whether
so
I
was
mostly.
I
was
mostly
curious
about
if
there
will
be
a
complex
json
like
within
that
data,
dot
data,
or
will
there
be?
Will
there
be
a
case,
but
I'm
not
sure
if
that's
a
valid
question,
to
be
honest,
I
mean,
if
you're
not
expecting,
then
it.
I
think
it's
pretty
much
straight
forward
then
like
we
just
give
the
entry
point
and
that
should
work.
A
E
E
Correct
but
then,
oh
so
like
if
there
are
any
other
so
like.
Let's
say
there
is
any
other
like
dot
data,
dot
data
dot.
Let's
say
I
don't
know
db1
grid
and
then
again
key
value
pair.
So
you
mention
like
dot
data
dot
data
db
data,
dot
data
db
grade
one
like
these
two
separate
as
an
array,
and
then
it
will
check.
D
C
D
You're
talking
like
the
case
where,
like
both
of
these,
are
their
own
individual
json
objects
that
have
different
shapes,
yeah
yeah.
In
that
case,
I
don't
think
this
has
the
flexibility
to
allow
you
to
like
or
actually
now.
D
E
Got
it
okay,
cool
yeah?
That's
that
should
work
yeah
I
mean
I
was
what
I
was
trying
to
get
at.
It
is
basically
like
to
certain
extent-
and
at
this
point
in
the
driver,
we
are
expecting
provider
response
to
be
in
a
certain
type,
like
that's
the
assumption,
probably
that
we
are
making
like
it
will
always
be
data.data
and
then
something
or
whatever
the
the
response
is
from
the
provider.
E
So
I
was
curious,
like
should
provider
return,
something
for
us
to
for
driver
to
sort
of
know
what
exactly
the
json
format
is,
rather
than
asking
user
or
something
like
that,
but
I
think
that's
going
to
be
unnecessarily
complex.
This
would
just
work
fine.
D
I
I
think,
like
so
you're
saying,
like
a
key
value
pair
as
a
secret
and
vault,
where
the
value
is
adjacent,
object.
A
All
right
so
like,
instead
of
just
having
the
data
and
then
vault
returning
data.username.password,
let's
say
under
data
there's
another
nesting
which
says
data.
something
so
then
inside
something
you
have
username
password,
so
you
have
data.something.username
data.something.password.
Does
vault
provider
actually
handle
that
today.
D
A
Yeah
I
mean
as
a
user,
it's
possible
I
just
come
in
and
then
I
already
have
a
json
blob.
I
just
put
that
into
like
the
external
secret
store
right
like
this
is
like
an
added
value,
but
it
doesn't
necessarily
have
to
be
supported,
like
I
think,
that's
what
I'm
getting
at
like.
I
think
we
are
already
left
providing
them
like
one
level
of
extraction
like
maybe
we
can
start
with
that
and
say
like
hey.
A
We
can't
do
complex
expressions
that
will
go
into
your
data
and
like
strip
each
and
everything
like
under
understand
it
and
do
it
like
we
can
do
that.
One
approach.
So
that's
why
I
was
asking.
Have
you
gotten
any
of
these
questions
involved?
Like
has
some
vault
user
come
and
said?
Like
hey,
I
have
a
json
as
a
secret
wait.
Can
you
extract
it?
For
me,
like
has
a
feature
request
ever
come
up.
E
And
I
think
my
question
was
exactly
on
the
similar
account.
Like,
ideally,
I
mean
the
way
where
we
have
sort
of
written
driver
is
like
whatever
provider
gives
it's
going
to
just
you
know,
write
on
the
file
system
on
the
similar
thought
process
provider
should
also
give
the
expected
json
struct
to
driver
so
that
it
can
pass
without
having
any
assumption.
E
But
I
guess,
as
a
nist
was
saying,
like
probably
to
begin
with,
we
can
have
this
non-complex
scenario
implemented
and
then
we
can
figure
it
out
user.
Ask
then,
then
we
can
have
like
another
round
of
discussion
like
how
do
we
want
to
know
json
structure
beforehand,
for
example
in
terms
of
driver.
D
So
and
then
like,
how
do
you
guys
feel
about
the
keys?
Just
being
the
name
of
the
file?
I
mean
the
user
doesn't
get
to
name
it
exactly
what
they
want,
but
for
some
I
feel
like
that
wouldn't
actually
be
an
issue.
E
A
No
I'm
saying
providers
can
support
like
it
is,
azure
does
support
it,
but
that
also
means
so
technically
they
still
don't
lose
out
on
it.
So
if,
let's
say
like
they
have
a
json,
they
provide
object,
alias
so
in
the
object,
alias,
they
still
have
the
json,
but
they
just
can't.
They
don't
have
the
flexibility
to
provide
an
alias
for
for
the
extracted
keys.
A
So
if
they
say
like
hey,
I
have
the
secret,
which
is
a
json
in
keyword
and
then
they
say
object,
alias
is
foo.
Then
foo
would
still
have
that,
which
is
the
same
behavior
as
today.
Who
will
contain
that
json
thing,
but
they
just
won't,
have
the
flexibility
to
define
what
the
extracted
file
names
will
be.
E
D
Right
and
at
the
end
of
the
day,
like
my
biggest
goal
with
it,
was
so
that
we
could
just
have
a
scenario
where,
like
we
don't
have
any
of
these
extra
listings
and
the
secret
provider
class
becomes
easier
to
work
with.
So
we
don't
have
to
specify
an
object
name
for
every
secret,
and
I
think
this
puts
it
on
track
and
I
think
the
transform
options
made
it.
It
made
the
code
actually
a
lot
easier
to
work
with.
So
I
think
that
was
a
better
route
as
well.
A
Cool
yeah,
I
haven't
had
a
chance
to
look
at
the
pr.
Yet
it's
just
been
like
the
whole
code,
freeze
and
everything,
but
hopefully
in
the
coming
weeks,
we'll
take
a
look
and
then
add
our
reviews.
D
To
it
sure
I
do
have
to
still
push
this
up.
I
just
wanted
to
run
it
by
you
first
and
then,
if
this
looks
all
good
and
on
track
I'll
start,
adding
all
the
the
testing
all
that.
A
Okay,
so
the
next
thing
that
I
wanted
to
discuss
was
I
added
this
issue,
because
I
think
there
have
been
few
other
folks
on
slack
and
like
like
other
communication
channels
that
have
been
asking
about
this.
So
today
we,
the
file
system
permission
is
configured
by
the
driver
automatically
so
like
it's.
It
requires
you
to
run
as
a
route.
If
you
want
to
be
able
to
access
it,
and
then
I
think
this
feature
request
was
specifically
user,
saying
like
hey.
A
If
I
define
like
file
system
permissions
and
all
of
those
would
you
be
able
to
like
use
that
in
the
security
context
and
say:
okay,
fine,
like
I
will
I
love
a
different
permission
for
this
particular
amount.
A
I
think
it's
a
valid
ask.
I
was
thinking.
Maybe
we
can
start
with
a
proposal
just
run
it
by
cigarette
and
see
like
hey.
Is
this
a
reasonable
idea?
Because
the
permissions
that
we
have
today
are
was
set
when
we
moved
the
project
to
cigar
to
the
sub
project
like
it
was
done
as
part
of
code
review
so
like?
That
is
where,
like
storage
and
auth
said
like
hey
make,
this
read
only
don't
allow
write
access
and
then
like
set
these
permissions
and
all
of
that.
A
So
if
we
want
to
support
it
through
the
security
context,
where
we
look
at
fs
group
and
say
like
okay,
now
we
can
override
it.
We
can
just
write
like
a
one,
pager
and
then
just
say,
okay
cigar.
This
is
something
we
want
to
do
like.
A
Do
you
think
we're
doing
anything
wrong,
and
I
think
if
we
get
an
approval,
we
should
probably
just
go
ahead
and
do
it
because
it
opens
up
like
us
more
scenarios
for
users,
so
they
don't
have
to
keep
running
the
processor
root
just
because
they
need
to
access
the
volume
and
all
of
those.
C
E
C
A
Okay,
we
can
respond
to
that
then
this
issue
I
created
because
kubernetes
already
moved
to
go
119
and
we
are
still
on
118
so
like
that
can
cause
like
lint
failures
and
all
of
those.
So
right
now
I've
pinned
the
e2e
image
to
the
124,
which
is
using
118,
but
now
that
119
is
out,
we
can
update
the
driver
and
then
also
you
update.
All
of
that.
A
This
one,
I
think,
is
an
interesting
one.
So
today
in
the
driver
we
own
for
kubernetes
secret,
we
only
I
love
tls
key
and
tls
cert,
and
then
this
particular
user
wants
to
also
do
ca.cert
in
it.
A
It
should
not
be
difficult
for
us
to
add
support
for
this,
but
it's
just
I've
been
digging
through
the
kubernetes
code
to
see
like
what
are
the
supported
keys
and
if
you
need
to
add
any
additional
logic
for
extracting
the
values.
A
Yeah,
so
today
we
separated
so
this
error
is
coming
from
us
saying,
like
hey,
we
only
support
tls
certain
tls
key,
but
we
need
to
look
if
they
have
like
a
ca,
cert
key
like
over
here
like
if
kubernetes
supports
it,
then
we
can
just
add
support
for
it.
A
C
Make
sense:
okay,
we
can
look
at
this
one.
I
think.
A
B
So
with
I'm
gonna
post
an
issue
in
the
chat
here
number
948,
I
was
pulled
into
a
conversation
on
twitter
about
a
similar
thing
where
there
were
like
folks
that
were
talking
about
being
able
to
have
the
driver
create
kubernetes
secrets
without
involving
a
volume
mount
yeah,
and
I
was
just
wondering
because
I
haven't
looked
into
this
in
the
past.
I
I
did
just
find
this
issue
too.
So
it
looks
like
it's.
Maybe
something
that's
been
talked
about
before.
I
was
just
curious.
E
I
think
static
secret
is
something
I
think
we
concluded
that
we
are
not
going
to
support
it
right.
That
is
so
static.
Secret
is
something
like
we
driver.
I
mean
provider,
just
send
a
bunch
of
key
value.
Pairs
and
driver
is
going
to
just
write
it.
A
No,
the
static
secret,
I
think
gcp
is
doing,
but
I
think
this
is
the
one
that
zander
is
referring
to.
So
basically,
users
want
so
today
we
mount
and
then
after
we
mount
what
we
do
is
we
also
sync
that
as
kubernetes
secret,
which
means
mount
is
mandatory
so
like?
If
you
need
to
sync
something,
you
still
need
to
do
these
additional
mounts
which
in
some
cases
you
don't
want
to
so
this
was
an
issue
created.
It
has
received
a
lot
of
plus
ones.
A
The
only
thing
is
the
csi
driver
is
primarily
for
mounting
right
and
then
the
sync
secret
was
added
as
an
optional
thing.
On
top
of
it,
we've
been
discussing
this
on
and
off.
A
If
we
need
to
support
syncing
as
community
secret
without
the
mount,
then
it
would
mean
we
either
have
to
split
the
project
and
say
like
hey,
like
sync:
secret
is
its
own
thing,
which
is
we
are
just
going
to
do
it
as
a
spin-off
project.
A
The
only
advantage
of
doing
that
is,
we
will
still
support
secret
provider
class.
So
if
you're
already
using
a
secret
provider
class
cid
with
the
csi
driver
today,
if
we
spin
it
off
as
a
separate
project,
you
will
be
able
to
use
the
same
crd,
but
that
controller
will
only
sync
the
community
secret
and
you
don't
have
to
do
the
mount.
A
So
that
was
one
approach
that
we
thought
about.
So
I
actually
had
a
google
doc
that
I
presented
to
cigar
it's
just.
We
didn't
go
back
to
it,
because
if
there
was
like
a
time
when
not
a
lot
of
users
were
asking
about
it,
but
if
it's
coming
up
again,
then
we
can
see
like
so
two
options.
A
Right,
one
is
that's
splitting
each
project
like
we
just
need
to
see
like
if
that's
a
feasible
design
and
then
how
far
we
can
go
with
it
or
the
second
option
is,
I
think,
there's
also
like
some
integration
points
with
the
projects
that
that
we
can
explore,
which
only
sync
is
like
kubernetes
secret,
but
I
will
share
that
word
talk
with
you
and
then
like.
Maybe
we
can
start
seeing
what
we
want
to
do
with
it.
E
Oh,
no,
that's
that's
the
thing
I
mainly.
I
think
I
just
wanted
to
say
that
at
the
static
record-
and
these
two
are
like
different
things-
probably
and
yeah,
we
have
been
discussing
this
for
a
while
now,
but
I
think,
as
you
mentioned,
the
integration
point
with
other
project
also,
I
think
it's
it
has
merits.
B
A
B
A
Yeah
I
mean
we've
been
thinking
about
this
one,
a
lot.
It's
just
that
I
mean
so
even
with
the
driver
today,
like
a
very
dirty
way
to
support.
It
is
like
we
built
some
kind
of
like
a
mutating
webhook
which
will
look
at
the
cid
getting
created,
call
the
provider
for
the
mount,
not
the
mount
like
call
the
provider
to
say,
like
hey,
go,
get
all
of
these
secrets
for
me
and
once
it
gets
it,
it
will
just
create
it
as
a
kubernetes
secret
and
that's
it
so
like.
A
That
is
one
way
to
do
it,
but,
like
the
tricky
thing
is,
does
that
have
to
be
deployed
with
the
entire
driver
or
if
it
has
to
run
stand
alone,
then
we
have
to
make
sure
that
providers
are
running
on
those
nodes
because
we
communicate
using
grpc
unix
domain
sockets.
B
Well,
that
was
one
of
the
things
I
was
wondering
with,
like
I
think
one
of
the
first
things
you
brought
up
like
yeah.
The
project
is
like
a
csi
driver
and
therefore,
like
you
know,
for
you
know,
working
with
the
storage
interface
like
and
and
mounting.
So
I
think
I
think,
if
it
is
something
we
were
to
pursue,
like
an
actual
like
a
separate
controller
that
can
rely
on
the
same
crd
is,
is
probably
the
most
like
sensible
thing
that,
like
stays
truest
to
the
intent
of
the
project.
A
A
A
A
Yeah
yeah
I'll
share
it
I'll
share
it
on
this,
live
stream.
A
But
yeah
thanks
for
bringing
that
up,
we
can
look
at
it
again.
A
Okay,
then,
I
think,
apart
from
that,
all
the
issues
have
been
responded
to.
I
think
we
need
to
set
a
milestone
for
the
1.3.
A
We
don't
have
to
do
it
on
this
call
like
we
can
also
like
discuss
on
slack,
so
I
was
thinking
maybe
like
a
month
from
now
or
45
days
from
now
like
we
can
set
it.
So
we
just
have
enough
time
to
work
on
all
the
items.