►
From YouTube: Secrets Store CSI Community Meeting - 2021-06-10
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
All
right,
hello,
everyone
thanks
for
joining
this
session
of
the
csi
secrets,
store
community
call
it's
june
10th
and
just
to
let
everyone
know,
this
meeting
falls
under
the
code
of
conduct
under
the
cncf.
So
just
please
be
respectful.
A
A
I
think
you
know,
I
don't
see
anyone
new,
so
I
don't
think
there's
any
need
to
do
any
introductions
to
the
community
with
that.
Let's
go
ahead,
let's
start
off
with
the
announcement,
so
thanks
for
updating
so
yeah,
the
aws
provider
is
now
listed
under
the
supported
providers.
A
So
thanks
to
the
team
at
aws
and
getting
that
on,
that's
awesome
achievement,
and
I
don't
know
if
there's
any
other
ad
hoc
announcements
anyone
wants
to
chat
about
if
not
we'll,
we'll
go
and
run
through
the
agenda
here
see
I'll
be
moderating
this.
If
he
can
back
me
up
on
those
yeah,
okay,
awesome,
okay!
A
So
let's
jump
into
it
dane
we
got
one
from
you,
we're
talking
about
getting
all
the
kb
pairs
value
pairs
from
the
end
point
and
so
I'll
go
ahead
and
share
out
the
link
on
the
issue
and
the
floor
is
yours
to
discuss.
B
Yeah
so
yeah,
I
was
just
scrolling
through
the
issues
and
came
across
this
issue
here.
The
proposal
is
that
that
we
should
be
able
to
specify
a
single
path
to
get
all
secrets
on
that
path
on
that
relative
path
rather
than
having
to
list
the
object
name,
should
that
secret
be
on
the
same
path.
B
So
if
we
scroll
down
just
a
little
bit
it
kind
of
takes
on
the
to
the
yaml
file
below
there,
we
go
yeah
just
there
like,
rather
than
having
just
the
objects
we
can
declare
where
we
want
the
objects
from
and
then
just
specify
the
one
path
and
get
all
the
secrets
and
then
tommy.
I
saw
that
in
the
discussion
below
you
mentioned
that,
like
the
parameters
are
specific
to
the
providers,
but
the
secret
objects,
which
I
think
deals
with
syncing
secrets
to
the
with
kubernetes,
is
related
to
the
csi
driver.
B
C
So
I
think
the
part
with
the
secret
objects
kind
of
raises
is
something
that
would
need
to
be
done
just
like
for
the
driver
to
support
of
kind
of
like
wild
cards
on
the
sinking.
C
C
So
I
think
those
would
be
pretty
provider
specific,
but
that
there's,
I
think,
more
room
for
the
driver
to
know
the
kind
of
like
more
of
the
structure
from
that
parameters
and
like
to
at
least
like
know
more
of
the
expected
file
system,
output
and
then
mapping
that
to
the
like
mapped
secrets.
C
D
D
We
don't
have
an
api
that
supports
something
like
that
where
we
can
actually
list
everything,
so
it
would
still
translate
to
an
individual
get
that
we
do
today.
D
I
think
in
this
example,
they
said
data
from
object
list,
but
in
terms
of
the
key
value
pairs,
if
they
want
to
define
a
different
key
value
pair,
how
does
it
work
and
those
different
scenarios,
because
the
whole
section
that
we
read
from
the
mount?
All
that
is
provider
specific
like
that,
is
not
something
that
the
driver
understands
at
all.
The
driver
just
reads
from
the
mount
and
gets
the
data
from
there.
So
I
think,
like
understanding
the
mapping
on
how
it's
defined
for
the
providers
how
it
could
affect
the
driver
is
very
critical.
B
Okay,
could
you
could
you
say
that
that
part
again
with
the
with
the
secret
objects,
you're
saying
that
it's
getting
that
information
directly
from
the
mount.
D
E
D
Key
is
basically
what
the
key
is
going
to
be
in
the
data
field
of
the
kubernetes
secret,
and
then
the
value
is
what
they
we
get
from
the
object
name.
So
from
the
object
name.
We
basically
go
to
the
target
path,
and
then
we
read
that
file
from
the
target
path,
for
that
particular
object,
name
and
then
like
provide
a
support,
object,
name,
alias
and
all
those,
but
the
object
name
field
that
the
user
defines
is
basically
a
file
that
has
to
exist
in
the
target
path.
B
B
And
then
you
said
that
each
secret,
within,
like
a
secret
store,
has
to
be
received
by
an
individual
get
there's
no
like
batch
kit.
D
I
think
that
depends
on
the
how
the
external
secret
store
api
is
implemented,
at
least
for
azure
keyword.
I
know
we
have
a
list
api
where
we
can
get
what
secrets
exist
today,
but
we
can't
actually
get
the
contents
with
it.
So
after
we
do
a
list,
if
the
user
defines
a
regex,
then
we
basically
have
to
match
the
secrets
from
those
lists
and
then
do
a
selective
get
for
the
ones
that
match
so
from
the
user
perspective.
D
Yeah
I
mean,
I
think,
when
this
feature
request
was
asked
in
the
provider.
I
mean
it
was
something
that
was
still
feasible
without
a
lot
of
changes,
but
I
think
the
same
request
for
secret
objects
on
the
driver
side.
It
requires
a
little
bit
more
on
how
we
can
design
this,
because
the
driver
is
totally
agnostic
to
provide
a
field.
Son.
C
Yeah
yeah,
so
I
think,
like
a
scoped
down
thing
could
be
like.
If
the
provider
supported
wild
cards
or
filtering
or
regexes
and
whatnot,
then
you
know
expanding
the
secret
objects,
part
of
the
secret
provider
class
to
have
some
more
automated
way
of,
like
you
know,
because
the
secret
objects
maps
like
files
to
the
keys
and
values.
C
But
kind
of
the
whole
feature
I
think,
is
split
and
then
like.
I
think
there
would
be
a
lot
of
benefits
if
we
could
have
the
secret
provider
class
more
aware
of
more
of
the
structure
of
the
expected,
like
the
expected
secrets
and
the
expected
mapping
of
secrets
to
files,
but
like
I
just
don't
think
we're
there
yet
in
terms
of
knowing
whether
or
not
there
is
like
a
an
abstraction
that
works
with
all
of
the
various
apis
and
whether
that
abstraction
is
more
helpful
or
well,
but
yeah.
C
I
think
that
would
help
us
with
some
other
requests
of
like
templating
files
or
maybe
some
rotation,
stuff
yeah.
I
don't
know.
B
Do
you
think
that
it
would
be
best
to
try
to
resolve
the
communication
between,
like
the
different
properties
there
in
secret
provider
class
first,
or
you
also
said,
like
this
functionality
would
be
split?
Would
it
be
like
possible
to
just
start
with,
like
the
secret
objects
and
trying
to
configure
a
way
to
reference,
an
object
list
first
and
then
move
on
to
the
specific
parameters
of
the
providers,
or
do
you
would
you
feel
like
this
entire
feature
has
to
collectively
work
all
together?
If
that
makes
sense,.
C
I
think
it
is
easier
to
scope,
something
that,
like
will
be
successfully
implemented
just
looking
at
the
secret
objects
and
in
ways
to
like
conveniences
kind
of
around
declaring
the
secret
objects.
C
B
C
There,
oh
and
and
then
I
think
also
it
could
be
like
immediately
useful.
I
don't
know
if
any
of
the
providers
have
implemented
like
wild
cards
like
but
like
if
they
did,
then
this
would
complement
that.
F
A
All
right
so
looks
like
there
could
be
a
need
to
kind
of
expose
more
the
driver
parameters
up
to
the
providers
that
the
consensus
or.
C
Yeah,
I
think,
okay,
and
then
my
one
thought
on
that
is
in
terms
of
like
versioning,
I
think
post
1.0
is
is
where
I
would
kind
of
put
that
in
terms
of
the
roadmap
like
I'd
like
to,
I
think,
prioritize,
getting
the
1.0
out
currently
more
than
new
features
right
now.
Just
I
think
we
get
a
lot
of
kind
of
questions
about
like
the
supports
and
stuff
so.
C
D
Yeah,
I
think
the
way
I
see
it,
it
adds
a
new
field
in
the
crd
spec
like
one
way,
the
way
it
is
proposed.
It
could
be
that
way.
But
again
it's
not
a
mandatory
field
right,
it's
totally
optional.
So
if
the
user
wants
to
use
the
same
secret
provider,
class
post
1.0
with
this
change,
that
would
still
work.
But
if
they
want
to
make
it
easier,
then
they
could
just
use
this
new
field
and
maybe
just
say
get
it
from
a
list.
D
G
Right
can
we
also
maybe
see
a
detailed
design
of
this
proposal
at
some
point,
preferably
before
1.0,
so
we
can
make
sure
it
doesn't
impact.
You
know
the
design
of
the
project.
A
D
I
think
dane
was
interested
so
dane
designed
this
one.
So
would
it
be
possible,
then,
if
you
want
to
look
at
this
one,
we
can
help
you
out
with
it.
If
you
have
any
questions.
B
Yeah,
I
I
I
was
kind
of
drawn
to
it,
because
I
think
it
would
be
a
nice
feature.
It
would
make
just
configuring
a
lot
easier,
but
I
would
for
sure,
like
need
to
spend
a
good
amount
of
time
getting
a
better
understanding
of
some
of
the
working
parts
and
the
driver
that
are
already
there,
and
you
know,
experiment
a
little
to
see
if
I
can
come
up
with
something
just
check
in
and
ask
questions
when
they
come
up.
D
Yeah
so
I
mean,
as
you
try
it
out.
Let
us
know
if
you
have
any
questions
and
then
I
think
a
good
action
item
after
this,
like
what
rita
said
right,
like
I
think,
if
you
have
a
design
proposal,
then
it'll
be
easier
for
folks
to
chime
in
and
then
comment
on
it.
And
then
we
can
decide
that
if
you
want
to
make
this
blocking
for
one
daughter.
G
Yeah,
like
I
have
this,
like
one
question
I
want
to
ask,
is
like
how
does
validation
for
the
object
work
with
this?
Since
you
know
the
list
can
change
over
time.
So
how
we
determine
failure
when,
when
we
can't
find
an
object,
is
interesting
like
when
the
when
the
list
changes
right
and
how
that
impacts.
D
G
D
G
Right
and
how
and
that
information
once
we
get
that
back
in
the
driver,
how
does
the
driver
deal
with
that
information?
It
is
my
question
because,
right
now
today,
we
just
assume
like
the
list
is
in
the
yaml
right.
It's
pretty
clear
when,
when
we
see
like
oh
object,
a
should
be
there,
but
it's
not
okay.
So
that
means
that
something's
wrong
right.
E
G
But
now
that
your
this
list
can
be
updated
outside
of
the
knowledge
of
the
driver
or
the
provider
right,
how
do
you
determine.
G
B
G
B
G
A
G
A
Yeah
we'll
think
about
as
you
as
you
create
that
proposal.
You
know
we
can
get
some
feedback
on
it.
Okay,
I
think
we
had
a
really
good
conversation
about
this.
I
don't
know
if
there's
any
other
comments,
if,
if
not,
we
can
move
on,
but
I
think
some
next
steps,
I
guess,
dane
you'll,
look
at
kind
of
creating
a
design
proposal.
A
Okay,
awesome:
okay,
all
right,
let's
see
what
we
got
next
is
anish
we're
gonna
talk
about
the
v.o.a
release.
D
Yes,
so
we're
planning
for
the
release
today
and
then
the
last
release
was
about
20
to
23
days
before
so,
basically,
we
are
going
to
hop
on
the
the
release
cadence
that
we
proposed,
so
that
is
aligning
our
release
process
with
the
patch
tuesdays.
So
the
past
tuesday
was
this
week
and
then
we're
going
to
cut
a
release
for
the
driver
this
week
with
all
the
changes
that
have
gone
in
and
then
basically
two
things
that
I
wanted
to
call
out.
D
The
first
one
is:
we
are
disabling
sync
secret
by
default,
which
is
a
breaking
change,
so
we'll
be
adding
this
to
the
release.
Notes.
D
Also,
users
who
are
using
this
for
syncing
is
kubernetes
secret
when
they
upgrade
their
driver
version
or
when
they
install
it.
They
have
to
explicitly
set
sync
secret
dot
enable
to
true,
otherwise
it
will
fail
going
with
this
release
and
then
the
second
thing
is
when
I
was
testing
yesterday.
One
thing
I
realized
was
the
sync
secret:
had
the
outback
permissions
which
were
required
for
rotation
as
well,
so
like
get
list
and
watch
so
if
you're
using
node
publish
secret
reference,
then
these
permissions
are
required.
D
So
we
basically
added
another
rbac
role
and
role
binding
file
specifically
for
rotation,
and
this
is
also
disabled
by
default.
If
the
user
does
enable
secret
rotation
to
true,
then
these
permissions
get
installed.
So
basically,
we
have
broken
down
some
of
the
permissions.
That's
required.
The
default
permissions
that's
required
on
secret
provider,
class
and
pod
status
will
be
installed
by
default
because
that's
required
for
mount,
but
the
rotation
are
back
roles
and
the
sync
secret
outback
roles
have
been
separated,
and
only
if
the
user
wants
to
use
those
features,
then
they'll
explicitly
get
added.
F
So
when
we
say
they
will
get
added,
like
do,
users
have
to
manually
install
it,
because
I
think
today
we
installed
all
the
rbx
manually
right
as
install
process.
D
F
D
A
All
right-
and
then
we
have
one
more
here,
so
the
sinking
is
coming
these
secrets
without
them
out.
D
Yeah,
I
I
added
that
to
see
what
other
maintenance
and
everyone
thinks
about
this
like
this
is
a
widely
requested
feature
like
I
saw
they
have
like
15
thumbs
up
on
this,
so
the
general
idea
is,
the
request
is
to
split
the
sync
kubernetes
secret
from
the
mount
so
that
users
only
want
to
use.
Sync
is
community
secret
without
the
mark
and
there's
been
a
lot
of
good
discussion
on
it
like
the
idea.
Is
they
never
use
the
mounted
files?
D
So
I
just
wanted
to
bring
this
up
and
then
see
if
anyone
had
any
thoughts
around
it
should
we
support
it,
because
if
we
do
plan
to
support
it,
it's
going
away
from
the
primary
functionality
of
the
project,
like
it's
no
longer
rightly
called
csi
driver,
because
we're
not
relying
on
that
behavior.
C
Using
the
mount,
but
then
and
not
writing
it
to
disk
right
so
like
we
can
use
the
mount
definition
for
the
the
csi
driver
to
call
the
providers
right.
The
csi
driver
gets
the
responses
back
and
the
driver
could
choose
to
just
not
write
the
files.
C
So
if
the
concern
is,
I
want
to
sync
to
secrets,
but
I
actually
don't
want
or
need
it
to
be.
You
know
in
the
file
system
of
the
amount
that's
created
like
that,
can
kind
of
be
done,
but
then
that
doesn't,
I
think,
solve
the
case
of
like
I
want
to
sing
to
a
secret.
But
I
don't
want
a
job
created
like
you.
Don't
want
to
create
like
a
it's
an
empty
job,
just
for
secrets
and
there.
C
But
you
know
or
like
a
common
crd
kind
of
thing,
that
the
projects
understand,
but
that
I
think
my
preference
would
be
to
remain
more
focused
on
this
project.
Just
being
the
csi.
G
Driver
I
have
a
proposal:
how
about
we
bring
this
issue
as
a
topic
to
the
next
exoth
call.
G
I
do
want
to
get
more
opinions
on
this,
especially
given
how
this
is
pretty
sensitive
and
also,
I,
I
think,
there's
a
lot
of
opinionated
people
in
sick
off
who
may
have
more
to
say
here
but
yeah.
I
think
maybe
we
should
go
into
that
meeting
with
like
some
pros
and
cons
of
this
right.
G
If
you
know,
should
this
be
two
different
projects,
should
it
be
just
two
different
functionalities
within
the
same
project
right
like
what
kind
of
impact
it
could
have
on
on
the
user
who's
consuming
it
exactly
to
your
point
like
they
could,
you
know,
use
the
external
secret
project
as
well
right.
So
what's
the
difference
essentially.
G
D
Yeah,
I
think
adding
it
to
cigar
agenda
would
be
a
good
first
step
like
just
to
see
what
cigar
thinks
about
this
supporting
this
in
general,
but
yeah
I
mean
within
the
same
project
having
the
two
functionalities,
I
think.
Fundamentally,
it
can
be
confusing,
but
also
in
terms
of
the
deployment
model.
It's
very
different
right
like
if
we
decide
to
support
only
sync
as
kubernetes
secret.
We
don't
really
need
to
have
a
daemon
set
running
on
every
single
node,
which
is
just
a
lot
of
overhead
for
the
user.
D
So
I
think
that
that
brings
about
confusion
on
how
to
install
it
and
then
like
even
in
terms
of
debugging.
It
can
make
it
very
difficult
for
us
in
just
one
single
project
so
like
the
tempting
thing
is
to
have
two
different
projects
like
if
we
really
have
to
support
it.
But
again
the
csi
driver
was
created
with
the
idea
that
mount
is
more
secure
than
actually
syncing
his
kubernetes
secret.
E
One
thing
one
other
thing
worth
pointing
out
is
that
it
would
give
a
very
different
permissions
model.
Currently,
we
rely
on
pod
identity,
to
kind
of
fragment
permission
to
fetch
certain
secrets
between
a
set
of
identities,
and
this
would
kind
of
necessarily
require
one.
One
service
account
having
the
keys
to
the
kingdom
so
to
speak.
C
Yeah,
like
one
of
the
the
reasons
like
when
we
at
google,
were
looking
at
different
ways
of
doing
this,
and
you
know
kind
of
hopped
onto
the
csi
project
was
the
the
ability
to
use
the
upload
identity
directly,
yeah
so
kind
of
seconding.
Some
of
that.
G
Cool
when.
G
It's
nice
that
we
have
two
weeks
and
the
reason
for
that
is.
I
think
we
should
go
in
with
like
a
doc
that
outlines
the
pros
and
cons
of
you
know
this
approach
versus
completely
syncing
everything,
because
I
think
we
get
a
lot
of
questions
on
this
anyway,
so
that
you
know
out
of
that
talks.
G
Hopefully
it
will
be
good
documentation
that
we
can
put
up
here
for
here's,
why
we
don't
think
you
should
be
thinking
secrets
and
if
you
really
want
to
here's,
how
to
do
it,
but
also
it
would
hopefully
help
drive
the
conversation
as
far
as
like
since
people
want
to
think
their
secrets.
What's
the
right
way
to
do
it
and
could
that
result
in
another
project
right.
A
D
Now,
I
think,
in
terms
of
prs,
it's
the
ones
that
are
active.
Basically,
the
release
management
dock
that'll
be
great.
If
you
can
get
more
eyes
on
it,
me
and
tommy
have
looked
at
it
and
added
some
comments
on
it,
but
the
initial
implementation
of
token
request.
We
moved
it
to
the
next
milestone,
because
the
pr
still
needs
few
more
changes
and
then
there's.
It's
also
a,
I
think,
a
a
longer
effort.
D
This
one
basically
adds
the
plumbing
for
passing.
The
service
account
tokens
to
the
applica
to
the
providers,
but
also
on
top
of
that,
we
have
to
handle
rotation
scenarios
like
how
can
rotation
pass
this
token
to
the
provider.
So
I've
opened
an
issue
for
us
to
basically
do
the
investigation
and
I
think,
based
on
discussion,
we
want
to
make
that
blocking
for
1.0.
D
We
want
to
decide
if
we
want
to
use
the
native
requires
republish
feature
in
the
csi
driver
for
rotation
going
forward.
I
think
that
reduces
the
overhead
like.
It
will
also
reduce
the
memory
consumption
because
all
the
overhead
falls
and
cubelet
to
give
us
everything,
and
we
already
have
the
item
put
in
way
to
call
providers
today
so
that'll
just
work
but
yeah.
I
think
me
tommy
and
ellick.
D
We
met
the
last
week
and
we
basically
put
some
dates
on
the
milestones,
so
we
have
added
a
v0.1.0
milestone
and
then
we've
also
put
a
date
on
the
stable
milestone
that
we
think
is
possible.
It
could
go
a
little
bit
further
if
some
of
the
features
have
to
take
time
for
implementation.
But
this
is
the
current
set
of
dates
that
we
have
and
now
that
the
o23
milestone
is
going
to
be
complete.
D
I
think
we
will
probably
meet
tomorrow
or
on
monday
for
just
going
over
the
1.0
milestone
and
then
basically
having
assignees
for
all
the
issues
that
are
there,
so
that
we
are
tracking
them
actively
to
make
sure
that
nothing
falls
out
of
the.
C
Milestone
yeah,
the
the
only
remaining
issue
in
the
23
was
the
providers
supporting
the
grpc
responses,
and
it
looks
like
all
of
them
have
now
had
our
lace,
except
for
the
aws
one
being
new
hasn't
hasn't
implemented
that
yet
I
think
we're
probably
good
to
try
to
do
the
release
on
schedule
or
just
close
schedule.
A
Okay,
thanks
for
the
update,
all
right
that
takes
us
to
the
end.
D
A
Awesome,
okay,
I
think
that's
it
lots
of
good
stuff
happening
so
sum
it
up
dan
you'll
kind
of
start
on
a
draft
for
that
proposal,
and
then
it
looks
like
we're
going
to
go
to
the
sigoth
meeting
and
discuss
the
that
issue.
I
think
it's
298.
A
Okay,
great
okay,
so
that's
it
for
this
meeting
next
meeting
is
in
two
weeks:
that'll
fall
on
june
24th.
So
again,
if
you
got
anything
and
then
the
items
please
go
ahead
and
fill
that
out,
one
quick
thing:
anish:
where
are
we
at
with
the
the
the
issue
oleg
had
brought?
D
So
I
think
they
are
looking
at
the
timeline,
so
the
the
team
is
going
to
decide
how
they
want
to
contribute.
I
think
but
yeah
I
think,
like
and
there's
any
communication
will
probably
be
on
the
github
issue
that
they
have
open.