►
From YouTube: Secrets Store CSI Community Meeting - 2022-03-03
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,
yeah
welcome
to
the
secrets,
store,
csi
driver,
bi-weekly
meeting
reminder
this
call
falls
under
the
cncf
code
of
conduct
and
the
video
is
recording
and
will
be
published
after
the
meeting
here.
Let
me
try
to
share.
A
Yes,
okay,
sorry
about
that
yeah!
So
we've
got
our
agenda
here
and
first
announcement
is
the
driver.
1.1.0
was
released
a
little
over
a
week
ago.
I
think
that
was
a
niche
press.
The
button
on
that
one.
A
Oh,
I
guess
I
can't
quickly
share
another
tab,
but
there
should
be
release,
notes
linked
there.
I
think
for
discussion
items
we
just
had
the
a
key
list.
Driver
and
worry
yeah
is
that
right,
yeah
I'll
switch
over.
A
Okay,
yeah,
so
a
new
new
provider,
a
keyless
yeah,
do
we
have
any
well?
Should
we
yeah,
I
think
good
times
yeah.
Do
you
want
to
give
an
introduction
to
just
the
driver
and
kind
of
the
goals
that
you're
hoping
to
have
and
then
we'll
we'll
go
over
kind
of
some,
some
of
the
more
details
on
how
to
get
it?
Actually,
the
pr
approved
yeah.
B
Sure,
absolutely
first
of
all,
maybe
a
few
words
about
ourselves
is
a
startup
company
and
we're
dealing
with
the
secret
management,
key
management
and
security,
a
sas
platform
running
on
multiple
regions
and
multiple
cloud
providers
competing
with
vendors
like
hashicorp,
vault
and
and
others.
B
What
we're
trying
to
to
do
is
to
provide
a
similar
functionality
to
the
existing
ones
of
other
secret
management
stores
that
would
allow
users
to
use
the
csi
driver
in
order
to
fetch
secrets
at
runtime
by
application
clouds
and
mount
them
as
static
files
on
or
virtual
files
on
the
pods.
B
B
The
main
gap
that
we've
encountered
is
that
we're
unable
to
to
test
it
prior
to
getting
the
pr
approved.
So
we
wrote
the
tests,
but
we
need
your
confirmation
in
order
to
run
it
and
basically
merge
it
in
line.
B
A
Yeah
cool,
let's
see,
was
there.
A
I
think
when
I
looked
at
this
one
of
just
the
cons.
Was
it
this
one.
A
A
So
I
think
either
anesthetical
like
do.
A
We
wanna
go
over
kind
of
how
the
end-to-end
tests
actually
run,
because
it
can
be
a
little
bit
weird
when
interacting
with,
like,
like,
I,
I
maintain
the
gcp
one,
so
our
e2e
tests
have
to
talk
to
actual
gcp
and
we
have
the
azure
ones
that
talk
to
actual
azure
vault
is
one
of
the
ones
that's
unique
in
that
it
can
run
the
vault
pod
in
the
e2e
test,
and
I
think
it
would
help
us
review
if
we
had
a
little
bit
of
an
overview
of
kind
of
what
the
test
was
installing
and
yeah
those
kind
of
things.
C
C
No,
I
think,
there's
a
lag.
Sorry.
B
I
was
just
about
to
notify
the
visibility
to
that.
I
was
about
to
say
that
the
fact
that
we're
a
sas
platform
doesn't
mean
that
we
are
business
only
so
we
have
a
free
tier,
free
community
tier
that
allow
you
to
sign
up
and
register
basically
to
anyone
with
limited
scale,
but
it's
more
than
enough
for
the.
B
A
I
yeah-
I
was
just
gonna
talk
a
little
bit
about
the
right,
the
gcp,
azure
and
aws
right
now
all
end
up
talking
to
different
sas
apis.
A
I
think
the
way
we've
gone
with
that
is
that
just
each
company
has
owned
the
testing
accounts
that,
like
these
tests,
will
interact
with
and
then
yeah
the
off
story.
There
can
be
kind
of
confusing
because
the
the
tests
run
in
a
it's
in
a
prowl
cluster
on
a
gcp
infrastructure
that
is
owned
by
the
cncf
and
then
those
test
cases
start
up
a
kind
kubernetes
cluster
within
the
prow
job,
and
then
that
kind
cluster
is
the
one
that
the
driver
and
provider
are
installed
to.
A
So
there's
a
bit
of
a
complicated
step
of
getting
credentials
into
that
pro
cluster,
either
as
like
static
credentials
or
using
like
the
gcp,
has
a
workload
identity
type
feature.
So
I
think
that's
probably
something
we
would
want
to
go
over
together
to
make
sure
we
get
either
the
credentials
added
to
the
right
spot
or
yeah
get
the
correct
identity
for
you
for
like
providing
accols
on
your
sas
api.
B
It
makes
perfect
sense
and
we
also
support
gcp
authentication
method,
so
you
can
use
your
identity
to
authenticate
without
the
need
to
have
an
initial
secret
or
a
secret
zoom
in
all.
We
need
is
basically
to
add
your
account
to
our
auth
method.
C
Yeah
so
when
we
started
off
like
we
added
quite
a
few
tests
to
the
each
provider
right
like
each
provider
that
we
support,
we
basically
try
to
have
like
an
extensive
test
suite.
But
then
about
six
or
seven
months
back
millet
worked
on
adding
an
e3
provider,
so
our
focus
has
been
to
enhance
the
test
suite
there
and
then
the
provided
test.
What
we
are
expecting
is
a
minimum
set
of
tests
that
basically
validate
the
existing
contract
between
the
driver
and
the
provider,
just
to
make
sure
that
the
driver.
A
C
Breaking
anything,
and
then
these
tests
also
signal
to
users
that
hey
look.
This
works
with
our
driver
currently,
so
it
is
one
of
the
reasons
we
call
it
supported
providers
and
in
terms
of
how
it
works
on
a
very
high
level,
basically-
and
I
think,
you're
running
into
an
issue
locally,
where
you're
not
installing
the
driver.
So
there
is
a
make
file
target
which
just
says
make
install
release
and
that
will
install
the
driver.
And
then
you
would
just
run
the
badge
test
suite
with
your
particular
set
of
tests
right.
C
But
I
think
that
and
then
did
you
also
get
a
chance
to
look
at
our
provides
onboarding
new
provider
dock,
which
has
some
criteria
in
terms
of
the
code
review
that
the
csr
driver
community
will
do
in
some
of
those.
C
And
I
mean
you,
don't
have
to
add
the
provider
right.
So
basically,
the
driver
already
exists
in
the
batch
file,
you're
installing
your
provider
and
running
the
test.
So
the
once
the
pr
actually
turns
green.
We
know
that
this
provider
works
and
then
we
will
see
the
test
that
you're,
adding
if
they're
sufficient
enough
or
if
we
need
some
more
tests
to
make
sure
that
there's
the
contract.
A
So
I
think
inish
though
we
need
to
approve
the
tests
before
they
can
see
whether
or
not
it
works
well
in.
C
Yeah
so
in
test
infra,
we
can
do
that.
I
think
previously,
what
we've
done
is
we've
just
made
it
as
optional
test,
so
we
don't
want
to
block
on
the
test
yet
and
then
with
that,
you
can
actually
try
to
run
it
on
your
pr
and
validate
it,
and
then
we
will
go
through
the
process
of
adding
you
as
a
new
provider
and
if
everything
goes
through
after
a
couple
of
months,
what
we
do
is
we
make
these
optional
tests
required,
which
means
we'll
start
blocking
pis.
If
the
provider
tests
are
actually
failing.
C
Yeah,
but
there
was
the
dog
that
I
was
mentioning
so
like
we
have
a
process
where
we
do
some
code
review
to
make
sure
that
it's
in
conformance
with
what
we
support
today
and
then
like
if
there
are
any
recommendations,
so
we
recently
went
through
this
with
the
aws
provider.
So
what
we
did
was
they
open
source,
their
provider,
repo
and
the
maintainers
and
all
the
contributors?
C
What
we
did
we
did
a
code
audit,
so
we
looked
at
the
code
that
suggested
some
changes
on
some
of
the
best
practices
that
we
follow
across
different
providers
and
then
once
that
is
complete,
and
then
we
have
the
e
to
e
test
with
a
passing
rate.
Then
we
would
add
that
provider
to
our
documentation
to
say
like
hey
look,
this
is
a
supported
provider.
D
Yeah,
no,
that's
fine.
I
mean
I
just
wanted
to
add
like
couple
points
so
the
the
dog
that
is
mentioning
right
now
right.
We
have
just
marked
that
in
the
issue
discussion,
so
it
might
be
easier
for
you
to
find
out.
The
other
thing
I
am
sort
of
thinking
is
right.
The
the
prof
might
be
like
a
chicken
and
exit
question
that
will
have
to
probably
either
merge
or
get
their
a
specific
job
in
or
maybe
they'll
have
to
just
use
one
of
our
job
to
run
their
test.
D
I'm
not
sure
how
we
should
do
this,
but
then
there
is
one
more
thing
I
have
seen
in
the
pr
which
sort
of
caught
my
eye
like.
I
saw
some
kind
of
a
key
in
there.
I'm
not
sure
if
it's
a
secret
or
something
like
that,
but
as
tommy
was
mentioning
earlier
yeah,
I
saw
it
somewhere.
I
don't
remember
very
excited
yes,.
B
You
saw
it
correctly,
it's
a
dummy
account
that
we've
established
just
for
the
purpose
of
testing,
and
I
would
much
prefer
to
use
the
gcp
authentication
even
for
appearance,
because
it
it
catches
the
eye
and
maybe
a
normally
entropy
test
will
find
some
keys
there.
So
I
would
very
much
like
to
replace
it
with
the
gcp
authentication.
D
Right
or
sure
and
or
probably
what.
B
C
C
So
that
would
be
an
ideal
way
if
you
also
want
to
support
like
access
keys
like
that's
the
one.
I
think
that
was
there
in
your
yaml
file,
but
these
are
the
kind
of
things
that
we
would
try
to
catch
in
code
audit
and
then
suggest
that,
like
this
would
be
something
that
can
be
implemented
in
a
different
way.
B
That
the
authentication
method
should
be
decoupled
from
the
business
logic,
because
we
have
internal
testing
for
that,
and
I
think
that
would
it
would
be
sufficient
to
use
the
gcp
workload
identity
in
order
to
verify
our
business
logic.
And
then
we
will
avoid
testing
the
keys
in
this
concept
because
of
the
visibility.
A
Yeah,
so
I
think
there
is
a
way
one
to
get
the
identity
I'll
try
to
look
that
up
the
identity
that
our
pod
runs
as
like
our
integration
test,
so
like
workload,
identity
in
the
client
custom
cluster,
I
believe,
is
the
like
identity
of
one
of
the
pods
or
like
of
the
pod,
that
it's
running
us
in
the
prop
cluster.
But
there
is
also
a
way
in
the
proud
cluster
to
add
like
static
secrets
as
kubernetes
secrets
and
then
to
have
that
mounted
into
the
test
case.
A
B
Would
have
to
be
done
by
you,
I
imagine
right,
so
we
don't
have
access
to
the
to
the
testing
environment.
So
we
we
cannot
just
inject
the
secrets
there
right.
C
This
is
something
that
we
can
actually
work
with
the
kubernetes
pro
community
right,
so
there's
actually
a
working
group
there's
on
slack
communities
like
the
sick
testing
and
then
prof,
and
then
I
this
piece
is
something
that
we
can
help
you
with
and
then
like
familiarize
you
with,
so
that
we
can
jointly
work
with
the
community,
because
if
there
are
any
issues
in
the
future
in
terms
of
rotating
threads
and
all
those,
it
would
be
great.
If
you
can
do
that.
C
C
You
can
actually
just
set
it
up
in
such
a
way
that
you
go
update
it
in
like
a
google
secret
manager,
and
then
it
will
automatically
pick
up
whatever
experiences
need
to
get
updated
in
the
cluster,
but
we
can
help
you
with
the
process
on
what
needs
to
be
added.
We
can
connect
you
with
the
right
set
of
folks
to
get
that
going.
C
A
Tests,
I
believe
like
yes,
because
we
had
expired
creds
repeatedly
and
that
led
to
failing
tests
for
the
gcp
provider,
and
I
believe
I
have
them
now
on
workload.
Identity
I'd
have
to
verify,
but
I
can
add
a
link
to
that
and
then
right
initially,
you
said
like
we
would
try
to
get
the
test
to
pass
in
the
pr
and
then
add
it
as
optional
test.
C
C
It
needs
to
be
explicitly
run
with
slash,
pull
the
whole
thing
and
we
can
do
that
until
the
pr
passes
and
then
once
the
peer
passes
we
can
say
required
is
true,
but
optional
is
also
true
and
then
once
the
test
pass
over
a
couple
of
weeks,
then
we
can
say
optional
is
false,
but
we
can
share
a
sample
config
for
the
file.
So
then
you
can
just
use
that
file
and
then
just
modify
it
for
your
provider.
B
A
Sure
yeah
and
then
also
just
make
sure
we
share
the
community.
Oh
yeah,
the
meeting
agenda
should
have
the
slack
channel
at
the
top
too.
In
case
I
have
it
yeah
and
then
yeah
great.
A
B
We
have,
I
know
it's
probably,
by
different
maintainers,
but
we
have
lots
of
other
integrations.
I'm
talking
about
the
eso
project
that
we've
contributed
to
a
few
months
ago
and
external
kms
that
we've
implemented
and
then
a
few
other
integrations
that
we've
done
already
so
we'll
be
happy
to
to
extend
it
to
csi
driver
as
well
and
more
integrations
as
we
go.
D
And
then
rory,
I'm
I'm
just
curious.
Like
do,
can
you
just
point
to
any
of
the
resources
of
your
company
or
this
particular
product?
You
know
just
to
get
a
glance
of
what
it
is.
Absolutely
if
you
can
raise
the
country.
B
This
is
the
marketing
website,
and-
and
this
was
this
is
the
documentation
side
and-
and
you
can
register
to
the
application
in
this
one.
C
Yeah
and
then,
like
I
said
we
did
this
process,
maybe
a
year
one
year
back,
so
if
we
do
run
into
issues,
this
will
also
be
like
a
great
way
for
us
to
improve
our
own
voting
process.
So
we
can
update
the
docs
and
everything,
so
I'm
really
excited
to
be
working
with
you
and
your
team.
C
A
I
just
wanted
to
make
sure
that
what
we
covered
was
the
question
actually
asked
on
the
meeting
agenda
of
how
to
add
the
new
csi
provider
and
get
the
test
cases
to
pass
right.
Like
other
other
questions
you
have
there,
I
think
also
over
the
next
few,
like
between
meetings.
The
the
slack
channel
is
probably
the
best
way
to
to
communicate
for
us,
but
yeah
are
there
any
other
questions.
A
I
think
that's
all
of
the
discussion
items
we
had
are
there
any
other
agenda.
C
I
don't
know
I
want
to
go
ahead,
not
agenda
but
yeah,
so
we
had
the
announcement
that
1.1.0
is
really
and
then
we
have
a
bug
fixed
for
the
json
log
which
has
been
cherry
picked.
So
I
think
we
need
to
decide
when
we
want
to
do
1.1.1.
C
We
haven't
had
a
lot
of
reports
for
that,
but
yet
so
I
think
we
can
wait
till
next
week
and
then
the
next
thing
is.
We
also
need
to
plan
for
1.2.0.
D
One
just
slight
addition
to
that:
I
have
probably
a
dependency
on
that
json
thing
as
well.
I
mean
if
it's,
it
should
be
okay,
if
you're
doing
it
like
in
next
week,
but
probably
for
the
ark
stuff.
I
think
we'll
need
it
to
sort
of
push
the
lock.
So
just.
A
Yeah,
let's
see,
I
should
have
some
time
monday
morning
to
help
with
that
yeah.
A
Cool
finish:
did
you
want
to
go
over
bugs
now,
or
should
we
just
you
know,
put
out
a
call
for
like
if
you
want
something
in
1.2.0
post
it
on
the
bug
kind
of
thing.
A
Yeah
here
sorry
I'll
try
to
share
again.
A
Yeah
right
now,
what
we
have
is
one
the
provider.
The
pathway
providers
are
supposed
to
create
the
unix
socket.
There's
the
effort
to
transition
it
from
under
at
cd,
slash
kubernetes
to
var
slash,
run.
A
And
we,
the
1.1.0,
will
now
check
in
both
locations
for
the
providers,
and
I
think
we
need
to
wait
like
a
release
or
two.
I
think
1.2.0
we'll
change
the
default
and
then
in
1.3
plus
we
will
start
to
stop,
stop
checking
and
in
etc
and
to
let
the
providers
migrate
over.
A
And
then
there
is
the
requires
republish,
which
has
been
a
long-running
effort
to
have
the
the
csi
driver
interface
added
in
a
way
to
inject
the
an
auth
token
for
the
pod.
That
is
being
scheduled
into
the
mount
to
request.
A
We
have
that
now
for
like
supported
for
the
both
initial
amounts
and
initial
1.0
or
1.1.0
added
support
for
it
and
requires
republish.
A
I
think
both
of
those
require
a
bit
of
additional
configuration
to
get
it
working,
but
we're
trying
to
move
to
that,
because
it
removes
some
of
the
permissions
that
are
needed
by
the
driver
and
gives
a
consistent
interface
to
providers
to
always
expect
an
auth
token
for
the
pod
that
is
being
scheduled,
which
helps
with
things
like
using
the
pods
identity
for
authenticating
to
the
external
secret
managers.
A
So
yeah,
I
think,
there's
just
some
work
to
make
that
maybe
the
default
in
1.2.
C
All
right
roll
up,
I
think
you
had
it
in
one
of
your
comments.
Sorry.
A
I
think
it's
1.22,
I
think
I
posted
on
the
gcp
provider
more
details
on
the
the
timeline
there.
A
Yeah,
I
think
we
can't
assume
it
until
1.22,
okay,
which
is
july.
It's
when
1.21
of
life,
but.
C
Yeah,
so
we
can
support
that
against.
If
we
don't
give
us
like
a
test,
run
to
see
if
it's
working
as
expected
or
if
we
need
to
modify
anything
to
keep
the
behavior,
then
we
can
just
keep
it
as
an
experimental
feature
and
then
once
122
and
once
121
at
the
end
of
life,
we
can
basically
say
like
hey:
look:
we've
had
these
many
months
of
run
with
request
republic.
A
Yeah
and
then
just
for
context
for
the
the
a
keyless
folks
is
that
the
rotation
feature
specifically
of
the
csi
driver
is
still
in
kind
of
a.
A
Preview
state,
which.
A
Sorry,
we
have
yeah
the
things
that
are
stable
or
the
secret
provider
class
custom
resource
definition.
The
initial.
A
What's
it
called
like
loading
of
secrets
into
the
pod
but
rotation
and
then
syncing
the
secrets?
Like
writing
the
secrets
from
the
secret
provider
class
to
kubernetes
secrets?
Is
this
one?
That
is,
these
two
are
not
as
mature
features
in
the
driver.
B
We
have
done
something
similar,
but
first
of
all,
we
support
different
kinds
of
secrets,
obviously
static
secrets,
but
dynamic
and
rotated
secrets
as
well.
We've
implemented
something
like
that
using
our
secret
injection
functionality,
using
a
sidecar
container
that
we
injected
with
imitating
webhook.
B
A
C
A
Okay
yeah:
let's
do
that
asynchronously,
I
think
and
we'll
try
to
try
to
yeah
add
the
1.2.0
label
to
different
things
and
if
anyone
has
ones
they
would
like
to
raise,
I
think
slack
are
just
commenting
on
the
issue.
A
I
think
that
brings
us
to
the
end
of
the
agenda.
Is
there
anything
else.
B
I
think
we
have
next
steps.
We
made
the
implementation
public,
so
you
can
review
it.
I
would
be
happy
to
get
your
approval
on
the
testing
we'll
continue
to
work
on
the
credentials
and
how
to
the
test
credentials,
I
mean,
and
how
to
integrate
with
the
test
environment,
and
I
will
just
sign
up
to
the
structure
and
we
continue
the
conversation
over
there.
Okay.