►
From YouTube: Secrets Store CSI Community Meeting - 2021-07-22
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
csi
secret
store
community
call.
Today
is
july,
22
2021..
This
call
falls
under
the
cnc
of
code
of
conduct
and
is
also
being
recorded.
Please
add
your
names
to
the
attendee
list.
A
A
But
when
we
were
seeing
all
these
test
flakes
and
like
a
couple
of
other
flakes
like
we
thought
it
might
be
better
that
we
spend
one
more
release
just
to
harden
all
the
tests
and
then
make
sure
that
we
have
consistent
test
results
and
then
also
see
what
feedback
we
get
on
the
vo
0.1.0
release,
because
there
are
a
couple
of
features
that
we
are
enabling
by
default
and
also
making
like
helm
changes.
A
So
this
is
basically
to
see
what
others
think
about
having
one
more
release
cycle
after
this
release
and
then
based
on
that
going
for
a
wee
1.0.
So
that
will
probably
be
in
september.
B
I
am
supportive
of
an
additional
release,
yeah
just
also
to
give
us
like
practice
on
the
release,
branches
and
stuff,
since
we
haven't
done
that
this
will
be
our
first
first
time
on
that.
D
A
Okay
sounds
good,
so
that
means
we
will
go
ahead
and
change
the
stable
milestone
date
to
sometime
in
september,
so
that
we
can
spend
some
time
on
the
next
to
these
and
make
sure
we
have
all
the
pieces
covered.
A
The
second
one
is
also
pretty
small,
so
we
are
planning
to
cut
the
v0.1.0
release
today.
So
a
couple
of
changes
from
how
we
do
it
before
is
we're
going
to
start
with
the
release
branch
today.
So
this
is
the
first
time
we're
going
to
try
that
out.
Hopefully
it
all
goes
through
well,
so
we're
going
to
have
a
release
branch
and
then
we
have
made
changes
in
test
infrared
pro
to
run
e2e
tests
on
release
branches
and
also
be
able
to
build
from
the
release
branches.
A
B
Yeah
and
then
I
just
wanted
to
call
out
like
I
think
we
were
scheduled
like
last
week
to
do
it,
but
it
just
hasn't
happened
yet
so,
just
just
to
call
that
out
in
case
anyone
was
expecting.
It.
D
And
just
as
a
reminder
for
me,
is
this
going
to
be
the
release
at
which
we
want
providers
to
set
using
grpc
as
the
default
right.
B
I
think
this
was
the
release
where
we
wanted
them
all
shoot.
I
need
to
look
it
up.
I
think
the
goal
here
was
this
release
was
for
all
of
them
to
support
it.
Let
me
pull
this
down.
A
Yeah,
I
think,
in
the
previous
release,
we
wanted
all
the
providers
to
have
it,
at
least
behind
the
feature
flag
now
where
they
can
return
the
response
return,
the
files
that
be
a
part
of
gsbc
response
and
with
o
1.0
like
the
directive,
is
to
start
using
it
by
default,
and
then
at
least
for
azure
provider.
That's
what
we
are
doing
like
we've
enabled
the
feature
flag
by
default
and
that's
what
we're
going
to
go
with
for
this
driver
release.
D
A
A
A
E
So
yeah
that
was
the
same
issue
I
was
working
on
before
so
last
time.
I
had
to
change
it
because
I
was
parsing
the
parameters
field
and
those
are
providers
specific.
So,
in
the
new
proposal
I
made
it.
E
I
added
a
field
for
the
crd
for
in
secret
objects
to
have
a
sync
all
which
would
just
read
the
secrets
from
disc
and
sync,
all
the
mounted
secrets
from
the
mount
and
sync
them
to
kubernetes,
and
I
know
one
of
rita's
concerns
was
being
able
to
specify
the
type,
and
so
this
would
allow
the
user
to
specify
the
type
and
not
have
to
list
out
every
single
secret
in
the
parameters,
and
then
tommy
mentioned
how
this
works,
for
this
could
work
for
now
with
the
way
things
are
implemented,
but
we
would
have
to
be
considerate
of
this
change
if
there
was
going
to
be
a
migration
to
how
we
do
secret
sinking-
and
I
saw.
E
An
open
issue
or
tommy
sent
me
an
open
issue
that
I
linked
at
the
bottom.
Initially,
I
think
you
mentioned
that
we
might
be
able
to
use
like
the
requires.
We
publish
feature
to
kind
of
manage
the
rotation
aspect
of
things
so
overall,
like
the
way
I've
implemented
it,
it
works
for
now,
but
it
seems
like
there
would
have
to
be
like
like
if
there's
any
changes
in
the
future,
we
would
just
have
to
be
considerate
of
this
feature
and
migrating
it
over
to
a
new
implementation.
A
So,
in
addition
to
having
sync
called
true,
can
they
still
override
it
by
saying
what
the
name
the
key
can
be
like,
so
I
think
for
opaque
secret.
It
works
well
right,
like
basically,
you
just
pass
through
the
whole
directory
and
then
the
file
name
translates
as
the
key
name,
the
secret
data,
and
then
the
the
value
is
just
what
is
there
in
the
file
but
in
case
of
kubernetes
dot,
io,
slash
tls,
like
let's
say
they
want
a
tls
certificate,
but
there
are
only
like
tl
assert
and
key
in
the
file
system.
E
Yeah
well,
like
my
thinking
with
the
type.
The
way
this
is
implemented
is
that
the
user
would
have
to
understand
that
they
could
only
specify
one
type,
so
they
should
only
put
secrets
of
one
type
in
the
directory.
So
if
they
wanted
their
tls
secrets,
every
secret
in
that
directory
would
have
to
be
tls
type.
A
Let's
say
they
want.
They
start
using
the
sync
call
feature
with
that:
exact
format
that
they
have
today.
So
at
that
point,
would
the
driver
need
to
say:
okay,
there's
only
one
file,
I'm
going
to
try
and
pass
the
certificate
and
key
from
this
file,
or
does
it
expect
separate
files?
If
the
user
says
sync
call
with
dls
secret.
B
Got
it
my
expectation
is
that
if
you're
using
the
sinkhole,
then
your
secret
files
need
to
match
the
kubernetes
keys
and
values
expectations
yeah
like
like,
I
think
I
think
kubernetes
has
the
oh
wait.
Where
is
it.
B
Like
I
I'm
thinking
it
would
just
be
the
reverse
of
the
existing
like
defaults
in
kubernetes,
I'm
trying
to
find
the
link
here,
but
anyway,
sorry
dan.
If
you
want
to.
E
Talk
about
anish,
could
you
re-explain
your
concern?
Actually,
I'm
not
sure
I'm
entirely
understanding.
A
C
A
Way
they
get
it
in
the
mount.
Is
they
define
a
type
secret
because
that's
how
azure
keyword
stores
it
in
the
backend
and
then
when
they
define
the
type
secret?
We
basically
get
the
certificate
if
it's
a
chain
or
a
service
or
just
servicer,
and
then
also
the
private
key,
and
then
all
of
that
is
written
to
a
single
file
like
we
don't
split
it
today,
because
we
are
following
the
conventions
as
that
api
right.
E
A
So
like
it's
basically
just
a
certificate
and
a
key,
but
it's
all
within
one
file:
okay,
right
and
then
when
they
want
to
actually
sync
this
kubernetes
secret
in
the
the
type
is
tls
and
then
for
the
key.
They
say:
tls.cert
read
the
same
file
and
parse
it
and
then
tls.keys
read
the
same
file
and
pass
the
private
key
out
of
it.
And
then
the
driver
is
smart
enough
to
go
past
it
and
then
pick
out
the
snippets
that
are
within
the
headers
like
begin
private
key
or
begin
certificate.
A
And
then
it's
able
to
convert
a
base64
encoded
and
then
put
that
in
a
kubernetes
secret.
But
with
sync
call
there
is
still
just
that
one
file
and
then
would
the
driver
need
to
say.
If
there's
one
file,
I'm
going
to
pass
through
that
or
do
we
need
a
specific
format
where
we
like?
I
think
what
tommy
was
saying
right
like
does
it
have
to
be
the
tls.tls.key
everything
in
individual
files
so
that
the
driver
can
just
parse
the
individual
components
and
base64
encoder.
E
B
Yeah
yeah
I
was,
I
was
going
to
bring
up
that.
I'm
not
sure
that
the
like
current
behavior
of
the
driver
is
actually
like.
Maybe
what
we
want
we're
like
there's.
I
think
this
is
the
only
secret
type
that
the
driver
knows
about.
Is
the
the
tia
certificate
one
right,
and
it
knows
that
like
okay,
sometimes
there
can
be
one
file
that
splits
into
you
know
a
kubernetes
type
and
like
I
guess
I
just
don't
know
that
like.
B
Would
we
do
that
for
all
of
the
other
like
kubernetes
secret
types
like
or
is
you
know
because,
like
I
think
in
like
vaults
right,
you
can
get
the
cert
and
key
as
separate
files
or
still
like.
B
I
know,
for
that.
Behavior
probably
helps
the
gcp
one
and
the
azure
one,
but
I
don't
know
that
it's
generically
useful.
D
D
Oh
sorry,
yeah,
I
was
just
gonna
chairman
and
say
I
I
don't
know
if
I'm
understanding
this
correctly
but
yeah,
it
seems
like
maybe
something
that,
where
the
logic
kind
of
makes
the
most
sense
in
the
provider
to
kind
of
for
the
provider
to
be
splitting
that
fire
up
and
then
yeah,
I
don't
know,
I
guess
it's
it's
as
I've
yeah,
as
I've
said
before
the
kind
of
unit
of
work
that
I
see
the
driver,
kind
of
working
best
at
is
is
with
individual
files,
and
so
it
should
just
kind
of
pass
along
whatever,
whatever
files
it's
given
without
without
too
much
processing
as
possible.
D
But
that's
just
my
take.
I
might
have
misunderstood
some
of
the
surrounding
stuff
as
well.
C
This
yeah,
this
actually
kind
of
makes
sense
to
me
as
well
like
this
seems
to
be
like
a
driver
specific.
So
probably
we
can
let
the
driver
handle
and
probably
standardize
the
interface
on
the
driver
provider
right
and
then
standardize
the
interface
on
the
driver
side
to
which
you
should
receive
search
in
this
case.
E
A
Yeah,
I
think,
like
the
sing
call,
is
usually
for
all
the
users
who
are
using
it
today
for
environment
variable
site,
like
I
think
it
benefits
them
the
most,
because
they
have
like
a
lot
of
key
value
pairs
and
they
want
to
sync
all
of
that
as
environment
variables
and
today,
they're
forced
to
have
to
do
it
for
each
individual
type.
E
A
E
A
So
the
last
item
on
the
agenda
was
this
proposal
that
I
initially
wrote.
So
this
all
started
with
the
github
issue
that
we
have
on
the
driver
right
requesting
for
sync
is
community
secret
without
relying
on
the
volume
mod.
So
basically
it's
trying
to
separate
these
two
features
and
we
wrote
this
one
pager
and
then
I
presented
this
in
the
cigar
community
and
the
idea
is
separate
out
the
sync
controller
from
the
csi
driver
and
then
maybe
have
that
as
a
separate
sub
project
within
cigar.
A
So
then
users
can
decide
if
they
want
to
do
the
mount
or
if
they
just
want
to
sync
like
so
that
it's
two
different
features
and
then
like
it
gives
them
the
option
to
just
do
one
or
the
other,
rather
than
having
to
do
everything
just
to
get
the
last
part,
which
is
just
environment
variables,
because
now
they
have
to
worry
about
all
these
things
that
could
fail,
which
they
don't
even
have
to
write,
and
we
had
a
follow-up
with
the
c
got
community
yesterday
and
then
there
was
good
feedback.
A
They
are
interested
in
this.
So
the
next
steps
for
this
is
basically
writing.
A
proposal,
and
maybe
a
design
talk
on
how
we
plan
to
approach
this,
this
single
controller
that
would
sync
his
community
secret
and,
like
I
think,
the
key
part
there
is
handling
odd
scenarios.
So
today,
with
csi
driver,
we
are
able
to
assign
the
permissions
to
the
part
that
needs
the
secret
and
then
we're
just
able
to
leverage
that
for
the
auth
with
the
external
secret
store.
A
So
we
need
to
write
a
odd
story
for
just
the
sync
as
kubernetes
secret
controller
and
then
like
the
plan,
is
to
have
that
proposal
that
we
can
present
to
cigars
in
the
next
community
call,
and
once
we
get
a
go
ahead
from
them,
then
we
would
be
able
to
extract
the
bits
from
at
least
as
a
starter.
We
could
just
have
the
sub
project,
which
would
do
the
sync
and
then
I
think,
over
time,
based
on
how
it
gets
adopted
and
like
how
users
feel
about
it.
A
A
And
the
advantage
is,
we
will
use
everything
that
we
are
doing
using
today
with
the
csi
driver,
so
we
would
use
grpc.
So
basically,
the
driver
calls
the
sync
controller
provider
our
jrpc,
and
then
the
provider
would
just
return
the
data
as
part
of
the
grpc
response,
and
then
the
driver
would
just
sync
that,
as
kubernetes.
B
Would
we
use
the
same
secret
provider
class
right
like
I
guess
this
is
like
just
kind
of
duplicating
the
portion
of
the
current
project
running
them
in
parallel
for
a
while
and
then
seeing
whether
or
not.
A
Yeah
we
can
use
the
same
secret
provider
class
like
I
think
that
is
one
of
the
advantages
like
if
they
have
that
they
can
use
it
the
controller
and
it
will
still
work
and
then
over
time
we
can
evaluate
if
certain
things
are
required
for
the
controller
project.
I
mean
like
for
a
controller
object,
but
at
least
to
like
start
off.
They
can
still
continue
to
use
the
same
for
both
the
projects
and
it
will
still
work.
B
So
I
think
to
dean's
question
on
the
last
one:
it's
something
to
be
aware
about,
but
not
like
a
blocker
for
his
his
effort
or
does
that
sound
right?
Does
that
sound
like
the
right
question,
then.
A
E
Is
there
a
goal
for
like
when
this
would
be
released?
This
change.
A
I
mean
so
we
still
in
the
initial
discussions
with
cigar
so
like
once
we
have
the
proposal,
it's
going
to
be
a
couple
of
reviews
before
it
gets
approved,
and
then
we
have
the
implementation
and
then,
after
that,
also
that
we're
going
to
have
api
reviews
and
code
reviews
before
it
actually
becomes
a
cigar
sub
project.
So
it
could
take
a
while.
Like
I
mean
there
is
no
timeline
right
now,.
A
Right
so
like,
basically,
we
want
to
extract
out
the
pieces
from
here,
but
we
we
need
to
support
it
in
the
driver,
because
there
are
users
using
it
right.
So
essentially,
we
want
to
extract
out
the
bits
that
we
use
for
syncing
today
and
then
it
will
be
a
separate
controller.
So
it
will
just
be
like
a
standalone
deployment
rather
than
having
a
daemon
set
running
on
every
single
node
on
your
cluster
and
then
it
will
just
be
able
to
sync
and
yeah.
D
Awesome,
what
kind
of
compatibility
would
we
be
targeting
for
the
providers,
because
I
guess
the
the
secret
provider
class
staying
the
same
would
help
a
lot
with
that,
but
yeah.
If
someone
someone
just
wanted
to
use
the
sync
syncer,
I
guess
the
yeah.
There
is
some
kind
of
pod
identity,
specific
stuff
in
the
vault
provider.
Right
now,
I'm
just
thinking
through
yeah.
What
would
it
be
a
big
lift
to
get
the
providers
to
support
this,
or
will
you
be
aiming
for
kind
of
just
like
default
compatibility.
B
Makes
sense
yeah
my
initial
thoughts
is
that
we
should
give
the
pro
like
what
the
requires
republish
right,
we'll
be
giving
the
providers
a
token
for
a
pod
or
like
for
a
service
account
in
kubernetes,
and
I
think
that
would
be
a
good
interface
for
at
least
the
providers
to
be
to
like
work
against
to
at
least
be
able
to
presume
that,
like
the
driver
or
the
syncing
controller
will
give
them
some.
B
You
know
token
for
a
kubernetes
service
account,
ideally
ideally
scoped
to,
like
you,
know
the
ponder
but
yeah.
Well,
I
think
yeah,
that's
my
preference
in
terms
of
compatibility
and
then
like
which
token
or
service
account
it
is,
I
think,
is
kind
of
to
be
determined.