►
From YouTube: Secrets Store CSI Community Meeting - 2021-08-19
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
Hello:
everyone,
thanks
for
joining
our
csi
secrets,
store
community
call,
it's
august,
8th
and
just
a
reminder.
This
call
is
governed
by
the
cncf
code
of
conduct.
Please
visit
the
repo
to
look
up
what
the
code
of
conduct
is
tldr
just
be
respectful
to
each
other
and
you'll
do
well.
A
We
got
a
quick
agenda,
looks
like
it's
growing,
so
we'll
get
through
it.
I
don't
think
I
see
any
new
members
joining
the
call
so
no
need
for
intros
and
with
that,
let's
just
go
ahead
and
jump
into
the
agenda.
First
item:
we
have
a
niche.
It's
going
to
talk
about
the
moving
of
the
helm,
charts.
B
Yeah,
so
this
is
something
that
we
thought
about
when
we
were
actually
undoing
the
v0
or
2.0
release
like
today.
The
handshakes
are
in
the
master
branch,
which
means
when
we
cut
a
release.
We
merge
a
pr
to
the
cherry
pick.
We
cherry
pick
the
prv
merger
to
the
release
branch
cutter
tag
and
then
we
merge
it
to
the
master
branch
and
then
one
idea
was
maybe
moving
all
the
chart
packages
to
github
pages
so
that
the
charts
are
always
hosted
in
a
single
location
there.
B
So
we
had
this
idea
and
then
opened
a
github
issue
which
is
follow-up
and
then
last
week
I
started
looking
into
renaming
the
default
branch
from
master
to
main
right
and
then,
while
going
through
that
process,
one
thing
we
realized
was
with
the
change
to
main
the
github.
The
helm,
chats
url
will
also
need
to
be
updated,
because
today
the
hem
chat
url
has
mastered
in
the
path.
B
So
what
we
were
thinking
was
we
anyways
have
to
make
the
change,
which
is
a
breaking
change,
which
means
we
have
to
tell
users
that
the
url
is
updated,
go
use
the
new
url.
So
as
part
of
that,
we
realize
it's
best
to
make
the
move
the
github
pages
right
now
and
then
also
along
with
that,
we
can
automate
the
generation
of
hem
charts
and
publishing
using
like
github
actions
right.
B
So
what
we
did
was
we
created
a
github
pages
branch
and
then
moved
all
the
existing
packages
to
that,
and
then
we
also
updated
the
help
index
to
say
make
all
these
packages
available
on
the
new
url
and
then
we
merged
the
pr
yesterday
to
actually
add
the
github
actions
which
will
publish
the
head
charts
for
us
going
forward
when
we
cut
a
release.
So
the
old
url
is
the
raw.githubusercontent.com
the
whole
thing,
but
going
forward
it's
just
going
to
be
kubernetes
dot,
github,
dot,
io,
slash
the
repo
name,
slash
charts!
B
I
added
this
so
that
we
all
are
aware
of
it.
But
one
other
question
that
I
had
was:
we
are
going
through
the
process
to
rename
from
master
to
main.
So
I
think
now
would
be
a
good
time
for
us
to
also
update
our
documentation
with
the
new
url
for
the
charts,
so
that
users
start
using
that.
So
I
just
wanted
to
see
what
other
folks
think
on
the
call
about
it
like,
instead
of
waiting
for
an
actual
release,
I
I
I'm
thinking.
A
B
C
Hey
a
question
so
right
now,
right,
like
everyone
has
to
like
to
upgrade,
you
have
to
know
to
type
in
the
like
helm,
upgrade
commands
right
and
will
changing
the
repo.
Maybe
you
said
this
already
on
an
existing
deployment
like
do
we
know
if
there's
any
issues
like
that,
you
know
what
I
mean.
B
B
So
once
we
change
this
as
long
as
master
branch
is
still
there,
if
you
do
a
upgrade,
you
still
won't
have
any
issues,
but
once
the
master
goes
away
and
gets
renamed
as
main,
then,
when
the
user
tries
to
do
a
helm
upgrade,
then
it
will
just
say
that
this
url
is
not
found
like
something
went
wrong,
go
and
check
and
then,
when
they
come
to
our
readme
they'll
see
that
we
have
changed
the
url.
So
they
just
help
repo
update
that
url
that
they
have
and
then
when
they
do
upgrade
it.
C
Okay,
yeah-
and
I
think
I
was
also
supportive
of
doing
this
like
earlier
before
we
mark
on
1.0.
C
And
then,
during
the
release
process,
yeah
the
having
the
charts
didn't,
make
it
so
there's
like
one
or
two
extra
prs
and
commits
like
which
adds
what
about
like
40
minutes
or
so
to
the
release
process
so
yeah.
I
think
I
think
it
makes
the
get
history
more
clear
to
do
something
like
this,
but.
B
A
B
I'm
sorry
I
was
just
going
to
say
if
all
folks
think
it's
a
good
idea,
then
we'll
make
the
change
in
the
readme.
So
when
I
say
the
readme
phil,
can
you
just
go
to
our
repo
once
I
just
know
yeah
yeah
and
then
charge.
B
Scroll
all
the
way
up
charge
and
then
secret
stress
is
head
over
and
then
scroll
down
a
little
bit
there.
So
basically,
when
I
say
update
the
readme
in
the
help
repo
ad,
we
are
going
to
update
it
to
the
new
url
today
or
tomorrow,
and
once
we
do
that
we
will
add
a
note
in
the
documentation
saying
the
url
has
been
updated.
We
will
also
post
it
on
slack
and
then
maybe
also
send
it
out
to
the
mailing
list
so
that
we
tell
users
that
look.
C
Yeah,
I
think
we'll
also
want
to
update
the
like.
We
have
that
upgrade
dock
on
the
in
the
book.
I
don't
know
there
and
then
it
really
stops.
A
A
B
A
On
the
just
say,
hey
we've
updated
the
helm,
chart,
location,
etc.
I
don't
know.
B
A
E
A
Okay,
you
should
have
controls
and
I'll
go
ahead
and
stop
sharing
and
take
it
away.
Okay,
let's
see
here.
D
E
E
Yes,
okay,
I
will
try
to
make
this
quick
and
painless,
so
I
kind
of
altered
the
sinkhole
option,
because
what
I
had
last
time
would
only
allow
syncing
all
listed
secrets
within
one
opaque
secret
type.
So
I
wanted
to
accommodate
the
different
secret
types
for
kubernetes.
E
And
there
we
go
and
just
to
confirm
the
key
is
also
password,
we'll
have
a
look
at
the
ammo
and
there
we
go
so
that
one's
all
in
well,
but
then
one
of
the
trickier
parts
was
accommodating
for
secrets
always
being
unique.
Even
if
the
key
was
the
same,
I
didn't
want
to
have
any
of
the
secrets
over
writing
each
other.
So
this
example
has
username
in
like
the
the
root
directory
of
the
secret
mount.
But
then
I
have
nested
secrets
as
well,
so
we'll
go
ahead
and
apply
the
update.
E
And
if
we
get
the
secrets,
I
made
the
name
of
the
secret
based
on
the
path
where
it
was
mounted.
So
in
this
case
with
the
update,
they
were
both
mounted
within
a
nested
directory
and
then
the
secret
name,
and
then,
if
we
get
the
key
again
it
should
just
be,
it
should
still
be
password.
So
the
key
doesn't
change.
It's
just
the
name
to
keep
it
unique.
E
So
no
secrets
are
interfering
with
each
other
and
then
again
to
show
that
you
can
also
include
sync
all
with
this,
with
an
opaque
secret
object.
So
with
this
behavior,
all
of
these
secrets
would
be
included
under
as
keys
and
values
in
dv
secret,
so
go
ahead
and
quickly
apply
that
update.
E
And
we
see
db
secret
and
we'll
go
ahead
and
look
at
the
keys
so
again
to
accommodate
for
similar
naming
we
want
to.
I
went
ahead
and
made
the
keys
based
on
the
nested
structure
of
the
path
so
that
these
wouldn't
interfere
and
yeah.
That's
pretty
much
the
the
the
meat
of
the
feature.
E
I
have
a
couple
other
examples
here,
we'll
just
go
through
the
tls
example,
so
I'm
mounting
two
certificates
and
then,
if
we
just
look
at
one
of
them,
we
could
see
like
the
key
and
the
both
the
keys
have
the
required
values
for
tls,
so
tls.insert
tls.key,
the
user
would
only
have
to
refer
to
them
as
tls
secrets.
They
wouldn't
have
to
actually
worry
about
creating
these
keys
and
that
behavior
is
the
same
for
ssh
and
basic
auth.
B
B
E
There
was
that
yeah
you,
you
brought
up
that
the
driver
was
smart
enough
to
distinguish
between
the
key
and
the
certificate,
so
I
I
just
utilized
that
same
behavior,
that's
already
there.
So
I'm
pretty
sure
when
I'm
mounting
these
the
certificate
and
the
key
are
within
the
same
file.
B
Okay,
but
in
this
also,
this
example
has
served
one
answer
too
right,
so
in
the
dls
secret,
which
one
is
being
added.
D
B
E
E
B
C
E
C
Could
you
open
the
sinkhole
opaque?
I
think
that
was
your
first
secret
provider
class.
C
This
one
did
all
of
those
paths
to
the
same
secret
right.
Yes,
how
do
what
was
the
what's
controlling
that
difference?.
E
Yeah,
so
if
sync
options,
dot
sync
all
is
true,
then
it'll
sync
each
listed
secret
as
an
individual
secret.
So
it
would
just
be
one
key
value
pair.
E
C
C
E
F
F
F
F
Okay,
so
the
secret
objects
we
have
is
like
the
key
that
we
are
using
right
now
as
well.
Correct.
F
Okay,
cool,
so
that's
fine.
The
the
other
question
that
I
have
is
so
like.
If
we
have
defined
secret
objects
and
if
we
have
this
thing
called
equals
to
true,
then
we
are
going
to
create
multiple
keys
within
that
single
secret
called
db
secret,
and
in
that
case,
when
we
have
this
similar
keys
like
username,
we
are
appending
or
we
are
creating
the
keys
with
the
path
right.
So
in
that
case
it
will
be
username
and
then
hyphen.
F
How
does
the
pod
will
refer
it
like
do
or
when
I
refer
in
the
port?
Should
I
be
expected
of
this
change
or
of
this?
What
we
can
say
pattern
that
it
will
be
sync
like
this,
and
hence
my
part
should
refer
it
like
this.
Is
that
the
expectation.
E
Let
let
me
quickly
like
bring
those
particular
secrets
up
and
I
might
need
some
clarification
on
your
on
your
question,
but
maybe
I
would
help
if
I
went
into
the
pod
so
like
here,
because
we
have.
E
E
So
those
secret
names
should
all
it
was
just
a
way
to
accommodate
the
uniqueness
of
the
secret
name,
so
so
that
we
could
get
all
four
secrets
in
here.
F
F
What
I
am
was
thinking
here
is,
since
we
are
syncing
this
as
a
kubernetes
secret,
probably
user
will
be
using
that
either
as
an
environment
variable
or
directly
as
a
kubernetes
secret
right.
So
if
they
are
not
referring
the
amount
and
if
they
are
referring
either
kubernetes
secrets
or
and
or
from
the
environment
variable
then
do
they
know
that
they
have
to
be,
or
they
will
be
of
this
name
or
the
key
will
be
of
this
name
like
next
username.
E
Yeah,
I
think
so
like
down
here
as
an
environment.
Variable
I'm
referencing
it
as.
B
E
That
changed
name,
and
I
think
for
a
user
to
like
predict
that
they
would
just
have
to
understand
how
to
use
the
feature,
because
one
of
the
things
with
the
like
singing
all
of
them
is
instead
of
listing
them
out
individually.
Is
that
you
lose
the
freedom
to
choose
the
name
of
each
secret.
F
E
F
Okay,
so
I
think
yeah-
and
this
is
what
I
was
sort
of
expecting,
so
we
should
have
some
sort
of
examples
and
documentation-
probably
around
this,
because
new
user
might
not-
I
mean
unless
they
go
through
the
implementation,
they
wouldn't
know
like
what
the
name
final
name
would
be
or
what
they
can
provide
over
there
you're
right.
A
We
got
one
item
left
on
the
left.
That's
you
and
we're
looking
at
a
pr
here
right
right.
F
F
If
you
can
go,
I
mean
you
can
scroll
all
the
way
down.
If
there
is
a
comment
on
the
pr.
So
let
me
give
a
like
quick
context,
so
we
wanted
to
implement
like
a
into
in
it.
We
provide
or
the
mock
provider.
So
we
don't
have
to
run
our
test
against
each
individual
crowd
providers
provider
and
that
way
we
can
be
quick
and
more
consistent
in
our
end-to-end
testing
and
whatnot.
F
There
were
like
couple
different
options
as
to
how
to
do
it,
so
one
was
to
just
return
a
static
secret
values
or
secrets,
and
we
don't
have
to
rely
on
any
of
the
any
of
the
custom
logic
per
se.
There
was
one
there
is
an
issue
related
to
this
implementation,
which
talks
about
having
kubernetes
secret.
F
F
F
If
we
go
with
the
kubernetes
secret
route
to
implement
this
or
to
get
this
mock
secrets,
then
we
still
be
having
dependency
on
the
kubernetes
api
server
and
that
I
don't
know
like
if,
for
example
like,
if
api
server
is
down,
our
mock
or
e2e
provider
will
not
be
able
to
return
anything
so,
and
so
so
the
best
practice,
probably
or
the
best
way
to
do
that
probably
to
is
just
return.
F
The
the
the
hardcoded
value
or
the
static
value
as
a
secret,
rather
than
relying
on
in
any
kind
of
a
secret
provider.
So
just
want
to
understand
like
what
everybody
thinks
could
be.
You
know
the
good
approach
to
do
that
and
both
works
by
the
way
like
initially
I
had
it
with
the
static
values
like
I
was
not
using
any
provider
and
the
only
problem
there
was
is
like
how
to
handle
or
how
to
test
the
rotation.
F
So,
like
sort
of
brainstorming
yesterday
with
anish
and
we'll
try
to
implement
that
and
we'll
figure
it
out,
but
then
I
checked
the
issue
and
which
talked
about
this
kubernetes.
As
a
I
mean,
given
the
secrets
as
like
a
pseudo
vault
kind
of
thing,
so
I
updated
the
implementation
to
that.
F
C
C
C
Yeah
so
since
it
is
just
like
a
fake
provider,
I
don't
think
we
care
about
the
security
really
yeah
so
yeah,
I
think
even
just
like
raw
secret
values
and
secret
provider
classes-
or
you
know,
I
think,
would
be
fine.
Kubernetes
secrets,
I
think,
are
a
little
bit
different.
That
might
be
more
okay
to
to
reference
in
the
implementation,
but
it
might
also
add
more
complexity
and
yeah.
I
think
keeping
it
as
simple
as
possible.
B
F
Yeah,
I
mean
sorry
the
way
that
this
currently
implemented
is
so
like.
If
you
see
right
here
like
it
says
the
populate
world,
so
what
it
does
basically
is.
It
goes
ahead
and
create
a
bunch
of
kubernetes
secrets,
and
then
we
actually
get
the
mount
request
in
the
fake
provider.
It
will
just
do
the
kubernetes
api
calls
for
secrets
and
just
get
those
exact
cigarettes.
F
So
that's
the
additional
part
so
like
it's
just
implemented,
which
is
backed
by
the
kubernetes
secrets,
for
example.
So
if
we
have
to
cut
this
out,
we
don't
have
to
do
all
these
things
so
like
within.
Within
that
same
mount
function,
we
can
just
return
like
hardcoded
values
so
like
this
is
the
secret
and
we
have
just
returned
it
and
then
for
rotation.
We
will
we'll
figure
it
out
how
to
implement
the
rotation,
because
for
rotation
we'll
have
to
externally.
F
First
change
the
value
of
secret
and
say
that,
like
it's
rotated
and
then
our
provider
will
go
again
and
try
to
fetch
it
and
will
then
get
the
updated
value.
So
we
will
figure
that
part
out
should
not
be
that
difficult.
B
So
it's
we
just
need
to
test
the
driver
logic
and
we
need
something
on
the
other
end,
giving
us
a
grpc
response
with
files
in
it,
and
it
can
be
anything
and
with
this
it's
just
a
lot
simpler,
where
it's
a
deterministic
value
so
like
we
can
always
check
on
the
driver
that
this
is
the
value
from
the
e2e
provider
and
then
for
rotation
again,
like
I
think
we
discussed.
So
we
can
do
that.
B
C
Yeah,
a
number
of
like
test
frameworks
right
have
like
a
return
x
value
and
then
return
like
y
value,
so
like
we
could.
C
B
Yeah,
I
think
one
thing
is:
the
driver
actually
sends
the
pod
name
and
name
space
today
to
the
provider.
So
one
idea
that
we
had
was
just
have
a
map
internally
and
then
the
first
time
the
request
comes
in
add
the
pod
name,
name
space
to
the
map
and
then
return
the
first
value
x
and
then
the
next
time
when
it
comes.
If
it's
in
the
map
just
return
y,
if
it's
not
then
written
x,
then
add
them
up.
A
All
right
that
takes
us
to
the
end
of
our
agenda
today,
any
other
comments
or
any
other
topics.
Anyone
wishes
to
bring
up
before
we
end
the
call.
B
B
So
if
there
are
any
issues
that
you
think
should
be
part
of
v,
1.0
blocker
like
please
feel
free
to
open
a
github
issue
and
then
we
can
get
it
added
to
the
stable
milestone,
but
in
terms
of
us
as
a
community.
That's
what
we're
going
to
be
working
for
in
the
next
couple
of
weeks
to
get
the
1.0
release
out.
A
Yeah
thanks
for
that,
okay,
all
right
that
looks
like
that's
gonna,
be
it
for
us
today.
Next
meeting
will
be
september
september,
2nd
actually
in
next
couple
weeks,
I'll
get
the
recording
out,
asap
and
I'll,
also
post
it
to
the
slack
channel
as
well
for
the
community.