►
From YouTube: Secrets Store CSI Community Meeting - 2023-04-13
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
A
If
you
haven't
already
added
your
name
to
that
in
these
list,
please
go
ahead
and
do
so
I
can
help
moderate
the
call.
Does
anyone
want
volunteers
to
take
notes.
A
Okay,
so
in
terms
of
agenda
items,
I
think
there
were
few
from
last
time
that
we
couldn't
get
to
so
the
Milestone
one
and
the
splitting
secret,
so
I
moved
them
over
and
for
the
disconnected
discussion
we
had
I
think
we
spent
the
last
one
hour
in
the
community
called
discussing
about
what
you
want
to
do
and
then
I
added
that
here
just
so
that
we
can
close
out
on
what
we
want
to
do
in
terms
of
our
next
steps.
A
So
the
first
one
was
the
disconnected
discussion
based
on
the
last
community
meeting,
the
I
think
we
decided
that
we
will
start
with
a
POC,
because
there
were
few
lingering
questions
about
the
cache
key,
but
I
think
we
said
we'll
start
with
the
POC
and
then
see
if
we
can
make
a
decision
after
we
start
the
implementation
I
just
wanted
to
bring
that
up
here
and
see
if
anyone
else
had
any
other
thoughts
or
anything
else
that
they
wanted
to
discuss
on
this.
One
specifically.
C
I
had
a
quick
question
about
I:
guess
like:
is
there
any
dependency
or
interoperability
between
both
of
these
proposals
like
how
does
the
proposal
to
separate
the
controller
out?
How
does
that
impact
this
offline
proposal,
or
not
at
all.
A
I
should
not
impact,
because
I
think
with
this
proposal,
specifically
I,
think
we're
talking
about
supporting
this
candidates
scenarios
in
the
mount
path.
So
basically,
this
enables
caching
at
the
driver
level
so
that
when
any
new
part
as
part
of
the
deployment,
so
it
scales
up
says
like
hey
I,
want
to
mount
the
volume
with
the
same
secret
provider
class.
Then
we
would
look
up
the
cache
and
then
based
on
the
policy
defined
by
the
user.
A
If
it's
already
in
the
cache,
then
we
would
Mount
that
and
then
the
part
would
start
up
by
splitting.
The
controller
is
specifically
only
doing
sync,
this
kubernetes
secret,
so
I
think
for
that,
in
terms
of
caching,
the
cache
would
be
just
be
the
kubernetes
secret,
like
I,
think
we
were
discussing
about.
Should
we
delete
the
secret
after
a
defined
TDL
by
the
user,
and
all
of
that
like
there
are
still
questions.
That's
that
we
need
to
answer,
but
that's
the
distinction.
Basically.
C
A
A
But
I
think
internal
next
step,
I
think
more
you're
volunteered
do
you
want
to
look
at
it,
but
we
can
pair
on
this
and
then
I
think
the
first
step
would
be
the
POC,
and
then
we
can
finalize
this
our
design,
Dock
and
then
the
step
out
after
that
would
be.
We
take
it
to
cigarth
and
see
if
we
have
consensus
there
as
well.
A
Okay,
if
there
are
no
questions
on
this
one,
if,
if
you
all
have
any
comments
like,
please
feel
free
to
add
to
it,
you
can
also
sync
up
on
Slack,
okay.
A
B
Yeah
that
one
I
think
I
put
down
less
energy,
but
let's
talk
about.
If
we
wanted
to
look,
oh
my
God,
it
is
wanting
to
be
in
bed.
B
If
we
wanted
to
use
the
time
like,
maybe
at
the
next
meeting,
to
do
like
a
high
level,
Milestone
planning,
we
just
kind
of
did
that
with
keeper
too,
like
I,
don't
know,
would
that
be?
Would
that
be
helpful
if
you
want
to
get
some
Milestones
added
to
the
the
repo
and
and
such.
A
Yeah
yeah
for
sure
I
think
there
are
like
a
couple
of
items
that
we
are
working
on,
so
right
definitely
add
a
milestone
and
then
also
maybe
set
a
deadline
and
when
you
want
to
cut
the
release
so
that
we
can
share
that
with
the
users
and
I
think
they're
like
a
few
of
these
discussions
that
we're
talking
about
so
maybe
we
can
add
more
data
to
those
as
well
and
then
like
add
it
to
our
roadmap.
B
Yeah
that
sounds
good
yeah,
given
that
we
have
the
discussion
on
splitting
the
controller
and
stuff
too
this
week.
Maybe
let's
set
aside
the
next
next
meeting
time
to
do
a
milestone
planning
like
we
can
book
an
ad
hoc
time
too,
but
I
figure.
Everyone
probably
just
wants
to
use
the
existing
set
aside
time.
D
Right
right,
no
I
was
more
saying
that,
like
if
it's
a
meeting
that
like,
for
example,
a
bunch
of
us,
can't
attend
or
something
it
might
not
be.
A
very
good
planning
meeting
make.
A
Okay,
the
last
topic
was
no
one
I,
think
that
we
wanted
to
discuss
so
for
the
splitting.
The
sync
secret
controller
from
the
CSI
driver
right
and
then
I
think
so.
This
was
an
old
proposal
that
we
talked
about
during
the
cigar
meeting,
maybe
in
2021
and
then
the
general
consensus
was
yes,
we
can
do
this
and
then
the
idea
was
to
remove
the
same
controller
from
the
CSI
driver.
That
way,
we
remove
the
dependency
on
the
part
requiring
the
mount
and
the
benefits
are.
A
We
could
reuse
the
existing
providers,
like
the
providers,
don't
have
to
make
any
changes.
The
only
few
changes
would
be
that
we
don't
use
Unix
domains,
okay,
because
this
would
just
be
like
a
single
controller
that
would
have
all
the
different
providers
running
as
just
different
containers
within
a
pod.
So
that's
one
thing
and
then
the
second
thing
is
we
could
just
use
the
secret
provider
class,
as
is
because
the
providers
already
understand
that
and
then
the
controller
could
pass
it
on
to
the
provider
to
go
and
fetch
the
secrets.
A
The
one
piece
that
was
being
discussed
was:
how
would
we
do
auth
with
it
and
one
of
the
ideas
that
we
had
then
was.
We
could
basically
try
to
use
the
service
account
with
the
custom
resource
and
consider
the
custom
Resource
as
a
workload.
So
we
could
still
use
workload
entity
with
different
providers,
but
here
it's
sort
of
a
part
being
a
workload.
The
custom
resource
would
just
be
the
workload,
so
that
was
the
idea.
A
I
think
that
we
had
and
then,
as
we've
been
discussing
more
about
it
now,
we've
been
looking
at
other
options
that
have
been
available
out
there
and
the
eso
being
the
popular
option.
That's
used
with
I
think
one
thing
that
we
came
across
in
their
documentation
was:
they
also
consider
custom
Resource
as
a
workload,
and
so
they
use
workload
identity
by
binding
a
service
account
with
the
custom
resource
and
initially
they
used
to
have
the
all
the
permissions
assigned
to
the
eso
controller.
A
But-
and
now
it
can
be
just
given
to
individual
customer
resources.
So
they
also
have
that
level
of
granularity.
A
A
A
So
those
are
the
existing
benefits
that
we
see
and
I
think
we
need
to
make
a
decision
that,
given
all
of
this
is
this
something
that
we
want
to
split
going
forward
and
support
as
a
separate
project.
D
Quick
question
I
think
you
mentioned
something
about
the
UDS
earlier.
When
you
were
doing,
we
would
still
have
the
UDS,
though
right
it's
it's
just
that,
instead
of
the
UDS
being
used
at
inside
the
cubelet,
it
would
just
be
inside
the
container
right.
D
A
Yeah
I
think
in
terms
of
How
It's
packaged
and
all
of
that
maybe
this
controller
project
that
just
needs
to
package
all
the
parts
in
all
of
the
containers
together
like
today,
we
the
driver
only
as
a
driver
and
providers
have
their
own
install
steps.
Saying
like
hey.
You
want
to
do
this
like
install
it
through
hell,
install
the
drivers,
have
really
on
all
of
that,
but
yeah
like
it
would
just
be
one
megapod.
D
Yeah
I
mean
that
one
has
a
little
bit
of
the
king
maker
issue
that
was
originally
discussed
like
when
this
was
first
talked
about
in
Sega,
because
we
didn't
want
to
play
that
role
in
the
community.
We
wanted
to
let
anyone
use
whatever
they
wanted.
Maybe
this
is
okay,
because
we're
still
not
we're
not
editing.
Your
yaml
isn't
like
a
high
barrier
like
you
could
change
it
to
whatever
you
wanted.
If
that's
what
you
needed.
A
Right
and
then
even
if
we
have
to
do
it
and
if
it's
there
in
like
this
controller
repo,
like
maybe
just
Helm
chat,
is
fine,
because
that
way
the
user
can
choose
which
providers
they
want
to
install
so
like.
Basically,
we
can
have,
if
classes
around
the
containers
and
then
install
only
the
providers
that
the
user
wants
not
have
everything
added
by
default.
Maybe.
D
Yeah
I
mean
I
think
we
would
do
that
I'm
still
a
little
bit,
hesitant
to
say
that
we
get
to
decide
what
the
complete
possible
set
is
that
kind
of
goes
against
a
little
bit
of
the
spirit
of
the
project,
but
you
know
maybe
we
would
just
say
that,
like
people
can
add
their
stuff
as
long
as
like
it's
reasonably
functional
or
something
right
now,.
A
E
And
I
think
it
is
safe
to
assume
that
you're
gonna
support
rotation
and
other
stuff
as
well
right
here
right,
oh
one,
more
thing
I
was
thinking
like
should.
F
D
D
But
that
means
you
expose
your
your
your
Vault
secrets
into
the
kubernetes
secrets
space
purely
because
of
like
how
it's
consumed
in
the
Pod
and
not
because
you
actually
needed
a
kubernetes
secret
at
all
right.
So
it's
it!
It's
not
the
Ingress
use
case
where
you
reference
a
kubernetes
secret
or
some
other
place
where
you
have
to
reference
the
kubernetes
secret.
D
So
that's
kind
of
painful
I,
don't
I,
don't
feel
I,
don't
I,
don't
think
we
want
to
encourage
that
as
a
sort
of
like
as
a
weird
workaround
to
the
fact
that
some
people
don't
want
to
use
file
based
Secrets.
They
want
to
use
environment
variables
based
Seekers.
D
So
if
there
was
something
we
could
do
at
the
driver
level
to
support
that
either
through
changes
in
kubernetes
upstream
or
changes
in
the
driver
or
whatever
that
to
me,
sounds
like
a
good
like
a
good
thing
to
invest
time
in,
especially
if
we
plan
on
removing
the
secret
SYNC
feature
right.
So
that
way,
the
parts
that
are
sort
of
compatible
with,
like
the
spirit
of
the
project,
are
retained
and
the
parts
that
we
consider
orthogonal
to
the
project
move
where
they
need
to
go.
D
By
controller
you
mean
the
secret
sync
controller:
well,
so
what
I
wanted
to
have
like?
Certainly
if
you
have
the
secret
sync
controller,
you
don't
need
anything
special
to
use
environment
areas.
Kubernetes
just
supports
that,
for
you,
I
I
more
mean
that
at
the
driver
level,
where
we're
not
syncing
kubernetes
secrets,
we
should
have
a
story
for
consuming
the
secrets
as
environment
variables,
instead
of
files
on
disk
without
the
kubernetes
secrets
and
direction
right
like.
F
D
A
E
I
think
that
would
depend
how
we
want
to
approach
it
right.
I
think.
If
we
want
to
drive
it
like
in
KK,
then
probably
the
driver
might
be
the
right
place,
I
guess
and
then,
if
not
KK,
then
maybe
we
can
see
with
this
new
controller.
If
we
can
support
it.
D
D
If
we
came
up
with
a
solution
that
made
like
conceptual
sense
to
be
in
the
driver,
otherwise
it
doesn't
necessarily
belong
in
either
one
of
the
places
and
it's
sort
of
like
a
a
separate
thing,
maybe
to
help
like
like
if,
for
example,
if
it's
like
an
admission
web
hook
that
injects
stuff
into
your
pod,
for
you
I'm
sure
it's
just
a
separate
thing
like
it
might
live
in
the
same
repo
and
it
might
be
in
the
same
Helm
chart.
But
it
doesn't
it's
not
logically.
The
same
component
does.
A
It
does
yeah
I
think
because
I
was
thinking
that,
like
the
driver,
is
mostly
only
used
for
the
CSI
Concepts
right
and
then,
if
the
environment
variable
changes,
actually
don't
really
relate
to
the
csi's
spec,
and
all
of
that
like
we
don't
need
to
have
a
Daemon
set
or
like
a
driver,
part
running
on
every
single
node.
Just
start
thinking
is
just
for
the
environment
variable
part.
So,
but
it
makes
sense.
C
C
C
E
C
F
C
So
for
the
environment,
variable
thing
may
I
request
that
we
postpone
on
that
and
and
wait
for
the
solid
mutating
emission.
C
Essentially
like
a
mutating
process,
but
if
it's
easy
enough
potentially
all
we
need
to
do
is
integrate
with,
like
the
the
mutating,
like
the
new
kind
right,
then
kind
of
like
the
validating
a
mission
policy.
So
we
will
just
interface
with
like
a
Native
kubernetes
API,
so
we'll
create
those
like
the
controller
might
create
that
right
as
opposed
to
us
writing
a
a
mutating
webhook
I,
don't
want
to
work
on
something
that
is
actually
coming
in
natively.
It
is
my
point
if
we
could
wait.
D
C
D
D
Because
so
then
it
would
kind
of
be
like
it
could
be
like
you
know,
instead
of
secret
CSI
store,
it
could
be
like
Secrets,
environment
store,
yeah,
but
I.
Don't
know,
I,
don't
know
enough
about
like
container
runtimes
and
stuff
to
know.
If
that's
like
a
reasonable
ask.
C
Yeah
I
don't
know,
especially
with
like
how
environment
variable
like
how
you
can
isolate
it,
because
you
don't
want
to
like
have
to
muck
with,
like
the
node
like
exposing
it
at
the
note
level,
I
guess
anyway,
off
tangent
for
too
much
for
this
particular
proposal,
though,
is
it
possible
to
create
a
proposal
specifically
for
how
we're
going
to
separate
out
the
controller,
because
this
stock?
Because
it's
meant
for
how
things
work
today?
It's
I,
don't
think
we
want
to
discuss
it
in
this
doc.
Right,
yeah.
A
D
But
I
I
think
the
larger
question
still
remains
in
my
head.
Right
is
like:
should
we
do
the
split
at
all,
or
should
we
just
remove
the
secret
SYNC
feature
and
say
please
use
ESO
and
and
we'll
and
then
we'll
focus
our
efforts
on
the
the
offline
support
and
secret
CSI
store
and
the
environment
variable
support
in
secret
CSI
store?
If
we
have
both
of
those
things,
we
can
just
say
that
the
project
is
effectively
featured
complete.
You
know
hand
waving
that
more
stuff
might
come
along
whatever.
B
This
is
maybe
just
hand
wavy
and
not
actually
helpful
in
reaching
a
decision,
but
like
I
get
what
you're
saying
like
it
does
feel
like
in
a
sense,
we're
just
duplicating
the
functionality
of
an
existing
project
that
is
now
like
cncf
incubating
and
like
all
of
that
and
yeah,
it's
really
I
do
think.
It's
a
compelling
argument
that,
like
existing
users,
don't
want
to
migrate
and
want
to
reuse
the
existing
secret
provider
class,
but
effectively
we
would
be
duplicating
the
projects
just
for
that
purpose
and.
C
B
Right,
that's
conversation
is
still
open
and
we
actually
they
wanted
to
chat
at
kubecon
next
week.
So
that's
still
a
route.
We
can
go.
Yeah
I
think.
B
A
Yeah
I
think
in
terms
of
long
term,
for
it
right,
like
like
the
conversation
that
we
had
had
with
them,
was
suggesting
that
we
could
build
this
translation
layer
where,
like
if
a
user
deploys
you
to
a
broader
class,
it
would
convert
to
an
ESO
customer
resource,
and
then
they
would
understand
how
to
do
it.
Right,
like
the
question
there
would
be.
Is
there
some?
Is
that
something
that
we
want
to
do
long
term,
because,
yes,
that
helps
users
migrate,
eventually
to
ESO
custom
resources?
A
But
we
don't
want
to
keep
supporting
it
because
that
means
ESO
has
to
like.
If
we
make
any
crd
changes
and
like
the
spec
changes,
the
schema
changes
like
ESO
has
to
constantly
keep
supporting
all
of
these
different
versions
that
we
produce
like
one
thing,
is
that,
and
if
that
is
the
route
that
we
really
want
to
go,
and
if
it's
just
about
helping
users
migrate,
we
could
just
build
our
tool
that
will
do
a
one-time
operation
right
like
like,
as
the
authors
of
the
driver
and
like
the
eso
like.
A
We
know
the
custom
resources
like
how
they
need
to
translate.
So
we
could
just
build
a
simple
tool
that
says
like
hey
feed
in
your
secret
provider:
class
it'll,
convert
it
to
a
ESO
custom
resource,
and
then
you
can
go
and
start
using
it.
But
the
question
there
would
be
is
that
what
users
want
like?
Do
they
want
something
that
comes
from
like
the
Secret
store,
like
the
CXC,
the
cigar
community,
or
they
want
to
go
and
install
another
project
that
they
want
to
maintain
like
I.
A
D
I
think
the
other
open
question
is
even
if
you
do
all
this
right,
you're
still
asking
someone
to
run
a
new
component
and
I
think
that's
like
the
real
hurdle.
It's
not
really
the
custom
resources,
because
we
can
help
you
migrate
either,
one
time
or
with
a
controller
or
whatever.
But
if
I
ask
you
to
run
a
brand
new
thing,
configure
it
and
make
sure
it's
got
the
same
sort
of
setup
and
availability
as
your
driver.
D
D
So
yeah,
like,
like
my
gut,
says
that
like
even
though
this
feature,
the
the
secret
Sync
features
the
most
requested
feature
right.
It's
is,
and
always
has
been
like
orthogonal
to
the
project
right
and
that's
why
we're
kind
of
stuck
now
is
right
like
we
have
it,
people
are
reliant
on
it,
and
so
now
we're
trying
to
figure
out
if
we're
supposed
to
continue
investing
into
it
or
not.
D
E
C
A
We
do
have
one
issue
from
a
year
or
two
back
like
that-
does
have
a
lot
of
thumbs
up
because
they
were
like
yeah
we
want
to
have.
This
is
a
separate
thing.
D
Was
a
couple
years,
thank
you,
I
I
guess,
I
would
say.
I
would
be
curious
if
the
people
that
previously
thumbed
it
up
was
long
enough
ago
that
ESO
wasn't
mature
enough.
Then
because
I
think
ESO
came
after
secret,
CSI
store
right
or,
if
maybe
it
didn't,
I
don't
know.
But
a
couple
of
years
ago,
I
read
a
lot
of
things.
Change
right
so
like
it
might
have
been
that
there
was
some
good
reasons
that
they
didn't
want
to
run.
Eso.
C
One
thing
I
just
want
to
be
careful
of
like
like
I,
think
we
should
say
like
hey,
there's
this
ESL
project,
you
know
what
do
you
think
and
if
you
don't
want
to
use
it,
why
not
right,
as
opposed
to
I,
don't
want
the
especially
people
who's
already
using
this
feature?
I
don't
want
them
to
feel
like.
Oh
we're,
abandoning
you
and
there's.
F
C
Other
project
that
use
it
don't
use
it
like
I.
Definitely
don't
want
people
to
feel
that
way.
So
it's
more!
The
question
is
more
like
I'm
curious,
have
you
looked
at
it
and
if
so,
why
doesn't?
Why
does
it
not
feed
your
your
scenario
right,
because
I
think
it
could
be
pretty
daunting
if
you
are
using
this
feature
in
production
and
you
feel
from
the
maintainers
you
see
like
oh
you're,
telling
me
to
use
something
else.
That's
very
could
be
very,
very
nerve-wracking.
D
Yeah
I
agree,
yeah
I
think
the
at
the
sort
of
like
the
highest
level.
I
think
what
we
were
thinking
about
is
if
we
did
do
a
deprecation
and
removal,
it
would
occur
across
like
a
major
version
boundary
and
we
would
retain
the
old
version
for
some
amount
of
time,
maybe
longer
than
we
traditionally
do
explicitly
give
people
more
time.
A
Yeah,
but
in
terms
of
next
steps,
yes,
I
can
go
comment
on
that
issue
that
we
have
to
based
on
what
we
discussed
today
and
also
write
up
a
doc
on
how
we
want
to
do
this
in
terms
of
the
actual
design
and
then
the
steps
they're
going
to
do.
And
then
maybe
we
can
use
these
two
to
discuss
this
further
and
make
a
decision.
If
you
want
to
do
it.
F
A
So
I
think
that
is
all
the
discussion
items.
We
had
anything
else
that
anyone
wants
to
discuss.
That's
not
on
the
agenda.
C
I
and
I
think
Xander.
You
said
you'll
you'll
be
talking
to
ESL
Folks
at
kubecon.
B
C
B
C
F
F
D
B
D
A
I
think
there's
a
question
on
chat:
do
we
have
time
to
go
over
the
encryption,
key
indirection
flow
or
open
questions,
so
yeah
I
think
from
the
discussion
last
time
we
had
discussion
around
like
how
we
want
to
do
it
like
with
service
accounts
and
multiple
audiences.
If
now
we
also
have
to
use
the
audience,
is
the
cache
key
and
then
I
think
the
final
outcome
was.
A
Maybe
we
should
start
building
the
POC,
so
then
we
can
see
if
we
are
missing
out
any
of
the
scenarios
like
I
think
once
we
have
the
POC
it's
easier
to
build
on
top
of
time
and
then
also
add
that
to
the
design
doc.
So
that
is
what
it
came
down
to
last
time
to
answer
the
question
on
the
channel.
A
Because
I
think
we
need
to
just
make
a
decision
whether
the
provider
gives
the
driver,
the
cash
key
or
the
driver
comes
up
with
it,
but
so
far
it
does
look
like
the
provider.
We
need
to
do
it
just
because
the
service
account
could
have
different
audience,
but
the
driver
also
has
that
information,
so
I
think
we
just
need
to
see
which
one
we
need
to
use.
A
I'll
just
add
your
name
to
the
agenda
for
the
demo
next
week.
More
so.
D
A
Thanks
for
doing
that,
yeah
I
think
reader.
To
answer
your
question.
We
have
issue
for
disconnected
scenarios,
but
as
we
do,
the
Milestone
planning
or
maybe
before
we
all
open
another
issue
and
then
add
this
design
dog
to
it
and
then
document
what
we
are
trying
to
do.
A
Anything
else
that
we
want
to
discuss.
F
A
D
Was
just
thinking
about
like
I
was
thinking
if
the
driver
could
have
the
capability
of
like
making
calls
to
the
provider
like
if
that
would
help
us
in
any
way
like
if
we
could
ask
to
provider
certain
questions,
maybe
that
could
help
us
build
like
a
cache
I'm,
just
really
thinking
out
loud
right
now,
I'm,
not
really
sure
if
that
makes
sense,
but.
D
F
E
A
Yeah
but
I
was
also
saying
I,
think
in
terms
of
debugging
locally
and
all
of
that,
like
milk,
had
added
a
few
Dev
container
stuff,
I
think
so
debugging
but
I
just
realized
more
doesn't
use
vs
codes.
D
F
A
I
mean
we
have
an
e2e
provider.
If
you
want
to
run
that,
if
not,
if
you
want
to
deploy
Azure
provider
too,
you
would
just
like
to
use
like
service
principles
for
art,
but
yeah.
If
you
have
any
questions,
I
can
help.