►
From YouTube: Secrets Store CSI Community Meeting - 2021-04-29
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
the
april
29th.
This
call
falls
under
the
cncf
code
of
conduct
and
it's
being
recorded
as
well
for
all
the
attendees.
Please
go
ahead
and
add
your
name
to
the
attendees
list
on
the
dock,
and
I
think
we
have
quite
a
few
new
folks
joining
the
call
today.
So
we
all
want
to
introduce
yourself
to
the
community.
C
Hey
guys,
this
is
milk
from
microsoft,
hey.
A
Okay,
so
jumping
into
the
agenda.
We
actually
only
have
one
item
today,
so
it's
pretty
short.
So
the
first
item
on
the
list
is
from
joe
and
chris.
Basically
the
code
audit
for
csi
acceptance
for
the
aws
provider.
B
It
sure
what
you're
you're
looking
for
for
me
before
we
jump
into
that
there
was
one
other
thing
I
wanted
to
bring
up
and
we
could
probably
talk
about
it
at
the
end.
But
there
were
some
comments
on
the
agenda
the
last
meeting,
and
I
was
wondering
if
I
could
bring
that
up
after
we're
done
with
this
too
yeah
sure.
B
Okay,
what
would
you?
What
would
you
like
to
hear
about
the
code
or
about
what
we're
doing.
A
No,
I
think
so
chris
had
reached
out
to
me
and
now
aws
yes
has
open
source
the
provider,
and
so
there
are
a
couple
of
criterias
that
we
have
added
in
the
documentation
for
adding
a
new
provider.
So
I
think
the
first
one
is
basically
the
the
maintainers
and
reviewers
from
the
csi
secret
store
community
being
able
to
do
a
small
audit
on
the
provider
code
to
make
sure
that
it
satisfies
all
the
requirements.
A
A
So
I
think
this
is
for
the
first
step
and
what
do
the
folks
in
the
community
think
about
helping
the
aws
provider
with
the
audit
for
the
code.
C
Yeah,
I
can
take
a
look
through
it
and
then
I
think
for
the
integration
test,
though
there's
maybe
this
is
what
joe's
gonna
bring
up
the
like,
whether
or
not
it
should
be
the
bats
or
the
ginkgo
kind
of
tests.
I
presume
yeah
or
it
might
be
easier
to
do
the
bats
style.
D
C
C
I
think
a
niche
might
have
the
most
reviews
or
on
that,
but
it
was
whether
or
not
like
yeah
like,
what's
probably
the
the
easiest
way
to
get
it
in
quickly,
I
think
is
probably
continuing
with
the
bats.
A
Yeah
yeah
yeah,
I
agree
with
tommy
because
we
are
eventually
switching
to
gingko.
So
I
have
started
an
initial
doc
proposal,
doc
for
the
ginkgo
test
framework
and
then
I've
shared
it
with
chen
for
now,
because
we
both
have
been
looking
at
it,
but
eventually
we
will
also
want
to
share
that
to
the
wider
community
and
also
when
we
open
the
pr
for
reference.
A
But
a
good
starting
point
would
be
to
start
off
with
the
bad
test
suite
at
least
with
some
of
the
few
basic
tests
that
work
with
the
provider
so
that
we
know
the
driver
provider.
Communication
works
well
and
then,
in
terms
of
it
and
then
we'll
also
help
out
with
the
audit
for
the
review.
So
tell
me
a
look
at
it.
I'll
also
go
look
at
it
and
then,
if
we
find
anything,
we'll
open,
github
issues
with
the
provider,
so
that'll
be
useful.
A
But
I
think
starting
off
with
bats
is
a
probably
a
good
first
step
and
then,
when
we
have
the
ginkgo
framework,
the
plan
is
to
have
the
initial
test
framework
that
could
be
consumed
by
all
the
providers.
A
So
from
the
provider
perspective,
the
implementation
should
be
minimal,
so
it's
around
having
a
secret
store
already
set
up
and
maybe
a
single
object
that
is
there
in
the
external
secret
store
and
the
driver
would
just
call
the
provider
to
get
the
provider's
custom,
secret
provider
class
and
typically,
this
is
all
we
want
from
the
provider
and
not
a
complete
test
suite
from
the
provider,
so
that
should
be
handled
on
the
driver
side.
So
that
is
what
we
are
working
towards.
B
Are
you
looking
for
the
test
suite
in
the
audit
as
well,
because
we
haven't
committed
our
edd
tests
and
our
git
repository
yet.
A
So
for
the
provider
audit,
we
are
not
looking
for
the
test
suite,
but
eventually,
when
the
provider
needs
to
be
onboarded
to
the
driver,
we
would.
It
would
be
good
to
have
the
e2e
test
in
the
driver
for
the
provider.
B
No,
there
was
a
comment
in
the
agenda
notes
from
the
last
call
that
said.
Currently
no
provider
is
optimized
to
not
set
secrets
if
they
haven't
changed
and
we
have
actually
implemented
that
optimization
when
the
rotation
reconciler
runs.
B
So
we
we,
we
have
two
different
sort
of
secret
stores
in
aws,
there's
a
parameter
store
and
secrets
manager,
and
we
support
both
of
them.
In
the
secrets
manager
case
we
have
a
described
call,
we
can
run,
which
is
way
lighter
weight.
It
doesn't
do
a
decrypt.
It
just
returns
some
metadata,
which
saves
customers
on
the
backend.
It
reduces
api,
calls
to
other
services
and
can
reduce
charges
in.
B
Like
the
you
know,
the
high
volume
cases
what
we
do
there
is
we
we
look
at
the
the
list
of
existing
versions
that
gets
passed
in
in
the
reconciler
case,
and
we
do
describe
calls
on
some
of
the
secrets
and
if
they
haven't
changed,
we
don't
rewrite
the
secrets.
We
don't
fetch
them
again
and
write
them
out.
B
I'm
not
sure
how
that
impacts.
What
you
guys
were
discussing
last
time.
B
So,
in
this
case,
we
have
a
higher
api
call
threshold.
So
I
was
talking
about
the
parameter,
staircase
they're,
they're,
sort
of
what
you
may
call
constrained
in
terms
of
number
api
calls.
So
what
we
do
there
is
we
we
use
batch
calls.
We
fetch
every
time
in
the
secrets
manager
case.
B
The
assumption
is
that
that
these
secrets
are
not
going
to
rotate
frequently,
you
know,
maybe
once
a
day
or
30
days.
There
are
some
customers
who
want
to
do
it
more
often,
but
it
doesn't
add
a
lot
so
doing
a
single
described
call
most
of
the
time
is
going
to
be
the
same
as
doing
a
fetch
call,
but
again
because
the
described
call
is
lighter
weight.
It
actually
reduces
the
number
of
api
calls
downstream
to
other
services
that
they
may
also
be
billed
for.
A
Got
it
so
does
the
describe
call,
do
it
for
the
list
of
secrets,
or
is
it
for
each
individual
secret
that
the
user
defines.
A
A
So
we
have
the
version
as
well
as
the
content,
so
it
translates
to
one
get
call
and
then
I
think
the
optimization
could
be
around
the
fact
that
if
the
versions
match
so
what
the
current
version
is
running
and
the
version
that
we
got
matches,
we
could
skip
writing
to
the
file
system.
So
that
is
the
optimization
that
we
had
thought
about
initially,
but
in
terms
of
skipping
the
api
call,
I
think
we
couldn't
find
an
option
for
that.
One.
B
Well,
that's
that's
exactly
what
we're
doing
we're
comparing
the
version,
but
we're
fetching
down
the
current
version
in
the
described
call.
C
So
yeah
the
the
changed
like
that
this
affects
is
that
we
were
moving
from
the
providers.
Writing
the
files
to
the
file
system
to
the
drivers,
writing
to
just
the
driver.
Writing,
because
we've
had
problems
like
turns
out.
Writing
a
file
to
a
file
system
can
be
difficult,
and
so
we
wanted
to
consolidate
that
logic.
C
So
we
added
as
part
of
the
response
on
the
mount
calls
the
basically
a
view
of
the
file
system
in
the
grpc
protos,
where
it's
just
the
list
of
file
they're
like
relative
path
and
the
contents,
and
then
we're
trying
to
use
the
same
library
that
kubernetes
uses
for
writing
secrets
and
config
maps
to
the
the
temporary
file
system,
and
that
needs
the
full
contents
like
yeah.
C
The
way
that
that
interface
is
written
requires
the
full
thing,
so
it
can
do
the
the
diffs
on
the
files
and
do
the
sim
links.
B
A
Area
that
we're
trying
to
address
with
the
tommy's
proposal
is
today
also
the
providers.
I
really
don't
update
anything
in
the
file
system,
apart
from
just
updating
the
content
right.
So
if
the
secret
provider
class
started
off
with
four
secrets,
we
write
four
of
them
to
the
file
system
and
then
during
rotation.
Let's
say
the
user
updated
the
secret
provider
class
to
only
have
two
secrets,
so
they
wanted
the
other
two
secrets
to
go
away.
A
But
at
that
point
the
providers
today
actually
don't
go,
delete
the
existing
two
secrets,
but
they
only
update
the
two
out
of
the
four
so
which
means
the
users,
the
part
still
has
access
to
all
the
four
sequence.
So
one
thing
we're
trying
to
address
is
how
the
driver
can
handle
these
cases.
So
every
time
that
the
driver
writes
to
the
file
system,
it
will
be
more
like
a
it
will
write
to
a
different
directory
and
then
send
link
to
that.
C
I
I
think
it's
not
really
reflected
in
the
notes
from
last
time,
but
that
an
issue-
you
kind
of
like
discovered
this
as
whether
or
not
the
interface
between
the
provider
and
the
driver
should
support
like
patch
versus
put,
and
I
think,
one
of
the
mitigations
for
like
load
and
cost
on
the
secret
managers
that
we
had
discussed.
That
isn't
here
was
tuning
the
like
polling
frequency
and
making
that
more.
C
The
right
now
it's
just
configured
at
the
daemon
set
of
like
poll
every
two
minutes.
I
think
it's
the
default
and
we
had
discussed
some
there.
A
Yeah
yeah,
I
think,
probably
another
call
before
so
we
are
exploring
the
option
of
using
the
requires
republish
in
the
csi
spec.
A
The
rotation,
so
mika
already
opened
the
pr
such
work
in
progress,
so
hopefully
we'll
be
working
with
him
on
it,
but
once
we
add
support
for
required
republish,
which
is
going
ga
122,
we
are
exploring
an
option
to
give
back
on
that
for
the
rotation
as
well,
and
then,
if
we
do
do
that,
there
might
be
an
option
where
we
could
make
the
rotation
configurable
our
poor
interval
configurable
for
certain
workloads.
A
C
One
more
question
for
joe
on
this:
how
often
would
like
just
a
subset
of
of
the
files
change
or
be
updated.
B
Well,
it's
going
to
vary
by
customer,
but
we
would
expect
it
would
typically
be
one
out
of.
However
many
they
have.
You
know
every
you
know
day
or
30
days
or
something
like
that
so
be.
It
should
be
fairly
static
most
of
the
time,
but
there
are
going
to
be
customers
who
want
to
do
like
high
frequency
rotations
and
things
like
that.
C
Yeah,
I
think
one
of
the
the
easiest
way
that
I'm
thinking
through
now
of
like
still
using
the
the
kubernetes
file
writer
is,
you
know,
a
response
from
the
provider
saying
just
no
change
right
to
anything,
but
that
if
there
is
a
change,
it
would
still
need
like
to
fetch
all
of
the
secrets
in
the
mount.
B
Well,
we're
kind
of
driven
by
the
the
current
list
that's
sent
in.
B
A
B
C
Well,
but
I
think
it's
the
provider
is
the
one
that
knows
so.
So
what
I'm
saying
is,
if
you
know
we're
pulling
the
providers
every
two
minutes
and.
C
Changing
but
like
once
a
day
you
know
the
provider
can
like
see
that
do
the
get
calls
notice
that
there's
no
difference
and
then
just
say,
there's
no
difference.
But
if
there's
any
difference
in
the
amount
of
like
one,
then
we
would
need
the
providers
to
refetch
like
the
entire
mount
amount.
B
Yeah,
I
understand
what
you're
saying
and
that's
a
possibility
too.
B
It
sort
of
changes
the
contract
a
little
bit
on
that.
That
list
is
passed
in
I
I
guess
we
would
have
to
wait
and
see
what
the
final
proposal
is
and
then
we
could
implement
it,
but
we'll
have
to
do
something.
I
guess
one
way
or
another.
A
Yeah
yeah,
I
think
the
reason
for
not
doing
the
patch
is
we
don't
know
whether
how
to
delete
the
files
like
if
we
keep
consistent
with
today
like
what
we
do
today
with
each
provider
like
not
cleaning
up
the
files,
then
it
could
be
as
simple
as
the
provider
just
fetching
the
delta
and
then
sending
it
back,
and
then
the
driver
just
replacing
that
delta.
B
So
yeah
I
mean
we
could
so
right
now
we're
taking
the
list
passed
in
and
updating
that
and
returning
the
whole
list.
We
could
just
return
a
partial
list
as
long
as
the
driver
is
maintaining
all
the
state
of
what's
there
before,
and
everything.
C
So
those
lists
are
just
about
the
secrets:
they
don't
incorporate
things
to
which
files.
So
that's
where
the
the
driver
doesn't
know
how
that
list,
maps
to
to
the
files.
A
A
C
This
yeah,
so
I
think
the
the
key
is
that
it
seems
like
there
are
customers
that
would
want
that
kind
of
more
optimizations
on
when
a
secret
is
accessed.
Based
on
on
the
metadata
about
the
secrets
that
currently
exists
right.
A
Yeah,
I
think,
from
the
provider
perspective
that'll
be
a
good
to
have,
but
it's
not
possible
that
all
providers
could
implement
it.
I
mean
if
they
don't
have
any
caching,
then
they
will
probably
still
have
to
make
the
external
api
call,
but
I
think,
from
the
driver
perspective
it'll
be
good
to
give
the
provider
the
option.
For
that
so
basically
say:
if
you
don't
want
to
go
refresh
everything,
then
we
support
that
at
least
just
give
me
what
the
delta
is
like
that.
A
But
I
think
if
we
talk
about
the
delta,
then
it
becomes
a
little
difficult
for
us
on
the
rotation
path.
B
Yeah
but
like
I
said,
if
it's
just
a
matter
of
forcing
a
refresh
occasionally
if
we,
if,
if
we're
passed
in
an
empty
list,
we'll
refresh
everything.
C
C
Yeah,
because
we
don't
know
that
anything
has
changed
to
say,
hey
if
I
address
everything
I'm
going
to
this
was
the
original
proposal
back
consideration
I'll,
add
a
section
to
it
about
this,
and
I,
I
think,
tuning
the
the
refresh
rate
and
making
sure
that
there's
an
easy
way
for
the
providers
to
say
they're
like
don't
change
anything
basically
committing
the
file
returned.
C
It's
just
yeah:
if
anything
does
change,
then
the
the
writing
interface
needs
all
files
it
can't
take
just
like
just
one
of
you
know:
seven
has
changed.
C
A
So
we
were
trying
to
gauge
interest
from
the
community
to
see
if
folks
wanted
that
particular
scenario
right,
but
we
didn't
get
a
lot
of
plus
ones
from
it,
but
the
issue
is
still
open,
but
I
think
the
idea
is
the
rotation.
Reconciler
helps
to
fetch
the
new
contents
and
then
republish
it,
but
also,
on
the
other
hand,
it
handles
in
place
updates
of
secret
provider
class.
A
A
A
A
Thanks
bob,
thank
you,
so
oh
yeah
me
and
tommy
will
take
a
look
at
the
code
and
other
folks
in
the
community
are
also
welcome
to
help
take
a
look
at
the
aws
provider
and
provide
any
feedback
as
they
get.