►
From YouTube: Secrets Store CSI Community Meeting - 2023-03-30
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
This
call
falls
under
the
CNC
of
code
of
conduct
and
also
this
is
recorded
and
will
be
published
to
YouTube.
Please
add
your
name
to
the
attendees
list.
If
you
already
haven't,
and
then
we
have
three
items
in
the
agenda,
I
can
help
moderate.
Does
anyone
want
to
want
volunteer
to
take
notes.
B
A
The
first
discussion
item
is
the
disconnected
scenarios,
the
caching
Xena.
Do
you
want
to
talk
about
it.
C
Yeah
I
just
wanted
to
set
aside
some
time
to
see
if
there
was
any
points
of
of
this,
that
we
wanted
to
discuss
further
on
the
call
or
yeah
I.
Think
probably
the
area
that
we're
zeroing
in
on
is
is
storage
of
secrets
and
whether
we
want
to
use
a
crd
or
or
what
I
have
some
options
highlighted
in
the
bottom
of
the
dock.
Here
yeah.
B
C
Yeah
I
think
Mo
brought
up
on
the
last
call
too
that
it
might
be
a
good
idea
to
take
this
to
an
upcoming
cigarth
meeting
and
see
what
they
have
to
say
about
it.
A
E
E
Well,
actually,
so
it
it
should.
The
drivers
right
now
needs
to
have
the
ability
to
create
kubernetes
Secrets
right,
because.
A
Yes,
it
does
so
it
the
we
don't
install
the
role
by
default
because
thinking
as
Secrets
like,
if
the
user
opts
into
the
feature,
then
they
install
those
required
roles.
But
if
they
opt
in
yes,
it
can
create
kubernetes
in
any
namespace.
E
E
A
I
mean
I
think
if
you
go
down
the
route
of
splitting
the
controller,
if
and
having
the
driver
only
do
the
mount
in
the.
In
that
scenario,
we
could
reduce
the
number
of
secrets
that
it's
allowed
access
to
so
like
we
could
basically
no
actually.
B
E
Right
so
there's
no
getting
out
of
this
situation
in
terms
of
the
level
of
access
that
the
service
account
has
like
not
really
because
we
don't
have
like
a
reference
based
authorizer
like
a
generic
one
like
if
we
had
a
generic
reference
with
authorizer
like
the
node
authorizer,
then
yeah,
we
could
come
up
with
a
strategy
for
saying
that
the
driver
can
read
or
write
secrets
and
namespaces.
E
D
We
made
it
optional
and
it's
not
like
a
ga
feature
yet
I
think.
E
Yeah
yeah
I,
don't
I,
don't
feel
like
that
is
like
expected.
Behavior
like
I
would
not
expect
that
to
happen.
That,
like
by
using
this
thing,
I
like
really
really
weaken
the
security
model
of
the
node
authorizer
and
the
node
admission
plugin
right,
because
in
most
environments
like
basically
the
important
environments
that
have
gone
through
upgrades,
kubernetes
Secrets
still
contain
service
account.
Tokens
from
older
installs,
thus
read
on
secret
is
effectively
cluster
admin
all
right
so
that
that
really
kind
of
nullifies.
E
E
C
I
would
have
to
question
if,
like
it's
worth
the
time
of
even
doing
that
with
with
ESO
out
there
like
ESO
kind
of
already
I,
don't
know,
is
it
worth
the
engineering
effort
for
us
to
like
rip
that
out
and
build
a
whole
new
controller?
Just
for
that
when,
like
that
project
already
exists,.
E
E
Whatever
this
controller
is
called,
the
potential
value
add
they
could
have
is
we
could
still
model
its
identity
in
the
same
way
that
we
model
the
identity
of
a
CSI
Secret
store?
So
when
the
Daemon
site
is
running
and
it
talks
to
Providers
and
stuff,
the
identity
of
the
workload
is
what's
used
to
fetch
data
from
the
cloud.
E
That's
not
true.
In
ESO,
when
ESO
runs
with
workload
identity,
it's
got
one
Global
identity.
That
is
the
controller.
So
there's
no
granularity
of
access.
It's
well
there.
If
there
is
granularity
of
access,
it
has
to
be
provided
by
ESO,
so
it
basically
nullifies
all
the
fancy
auth
Z
policies
you
have
in
your
cloud
and
instead
says
no,
you
got
to
make
ESO
do
all
of
those
whatever
I.
Don't
even
I,
don't
know
if
it
does
or
does
not
do
those
things.
A
Yeah
I
think
one
is
that
and
then
the
second
one
is
also
like
users
who
are
already
accustomed
to
our
like
custom
resources
and
stuff
like
they
don't
have
to
go.
Do
any
kind
of
migration
like
what
would
be
that
they
still
use
the
same
secret
provider
class
and
then
also
all
the
providers
that
we
have
don't
have
to
go,
make
any
code
changes
like
we
could
take
those
and
then
just
run
it
with
this
new
controller,
and
then
it
will
just
work
like
so
in
terms
of
the
user
migration.
E
B
A
You
define
like
a
template
to
say
what
a
secret
would
like
look
like
and
then
which
data
from
your
external
Secret
store.
Is
your
value
here
right?
So
if
we
split
it
into
two
separate
things,
if
they
use
use
the
exact
same
crd,
it
would
just
work
in
both
of
it.
So
like
the
only
the
CSI
driver
will
look
at
what
is
required
for
the
mount
part,
and
then
it
will
return
those
files
and
for
the
controller,
the
provider
will
put
still
returns
those
files.
A
E
Okay,
so,
based
on
that,
we
could
actually
do
like
like
one
of
the
questions
I
had
for
y'all
was
like
would
would
there
be
breaking
changes
if
we
went
down
this
route
that,
like
required
us
to
like,
do
like
a
V2
of
the
stuff
as
a
way
of
like
saying
that?
No,
like
we're
gonna
break
some
stuff
so
like
if
you
don't
want
to
break
stuff
stay
at
V1
until
you're
ready
to
migrate,
but
I
I
didn't
know.
If
we
could
get
the
changes
we
wanted
without
making
some
kind
of
breaking
change.
A
Yeah
I
think
we
can
do
it
without
a
breaking
change,
like
I
think
when
I
wrote,
The
Proposal,
initially
also
that
that
was
the
reason
right
like
it's
in
from
user
perspective,
it's
more
like
installing
this
separate
component.
The
behavior
is
slightly
different
because
obviously
like
today,
this
thing
secret
only
happens
when
you
go
create
a
pod
and
things
like
that,
but
going
forward.
Obviously
it's
just
like
you
create
the
custom
resource
and
it
automatically
goes
and
creates
it
for
you.
A
E
E
Okay,
yeah
I
mean
that
seems
fine.
What
have
you
all
traditionally
done
in
the
past?
Would
you
like?
Would
you
just
do
like
a
minor
like
like
a
kubernetes
style,
minor
version
bump
just
to
say
that,
like
you
know
it's
one
dot,
and
or
would
you
feel
like
something
like
this
would
warrant
a
full
2.0.
A
Like
with
minor
releases,
I
think
we've
deprecated
flags
and
all
of
those
right,
but
that
also
we
try
and
follow
like
the
kubernetes
process
of
deprecating
over
three
releases.
So,
like
the
first
leave,
you
say
it's
deprecated
and
then
like
we
remove
it
in
the
N
minus
two
releasing
like
now,
you
cannot
configure
it
and
then
that
finally
goes
away.
E
A
E
A
B
E
E
So
on
on
the
topic
of
like
you
using
custom
resources
that
are
like
encrypted
versus,
like
kubernetes
Secrets
I,
think
last
time,
I
talked
when
I
talked
with
you,
Xander
I
had
thrown
out
the
idea
that
would
it
be
the
end
of
the
world
if
the
future
controller,
when
it
needed
to
do
its
caching,
if
they
just
wrote
the
the
secrets
from
the
provider
into
its
namespace
as
a
kubernetes
secret.
Basically
do
we
need
the
indirection
between
the
custom
resource
and
the
kubernetes
Secret.
E
Would
you
need
to
be
able
to
read
kubernetes
secrets
to
get
the
encryption
key?
You
would
also
have
to
be
able
to
read
the
cash
secret
custom
resource.
You
need
both
access
rights
right
and
the
Assumption.
There
would
be
the
only
actors
in
the
environment
that
have
both
is
either
the
cluster
admin
or
the
driver
or
the
controller.
Whatever
right
to
you
know,
someone
play
Devil's
Advocate
I
was
asking
if
that
is
that
something
that
the
driver
controller
thing
should
try
to
defend
against
or.
E
Like
like,
as
a
for
example,
I,
don't
know
of
any
other
project
that
does
this.
A
A
E
E
E
D
E
And
whatever
you
want
right,
I
think
we
have
to
be
stricter
than
that,
like
I,
don't
care
if
someone
sets
their
cash
policy
to
10
years,
whatever
I.
Don't
care,
that's
that's
on
you,
but
it
should
not
have
no
capability
of
revoking
access.
A
E
E
Right,
okay,
yeah,
so
I,
guess,
yeah,
there's,
there's
two
very
similar
related
problems.
There
is
the
driver
that
needs
to
work
in
offline
mode
and
then
there's
the
controller.
That
also
needs
to
work
in
offline
mode
right
and
do
they
use
the
same
strategy
for
doing
that
by
the
way,
I
could
see
a
user
being
very
confused
if
a
the
driver
is
able
to
in
offline
mode
mount
a
secret
because
it
saw
it,
but
for
whatever
reason
the
controller
didn't
see
it
and
it
can't
create
the
same
secret.
E
That
seems
weird
and
unexpected
I'm,
not
sure.
If
there's
a
fix
to
that,
because
there's
just
separate
components
and
they
have
their
own
like
their
logic,
I
could
I
could
see
that
being
confusing,
but
yeah,
so
there
like.
So
the
the
the
thing
I
was
thinking
about
is
like
the
I
to
me.
E
E
C
C
E
A
Yeah
that
key
would
I
mean
at
least
from
the
postal.
It
stays
in
the
kubernetes
secret,
but
that
also
just
means
any
instance
of
the
driver.
Part
could
access
it
and
I
think
the
thing
with
the
cash
cash
secret
is
all
the
driver.
Parts
can
access
it
so
like
basically,
access
goes
out
of
the
node
like,
unlike
today,.
E
So
we're
saying
that
ignoring
the
sinking
of
Secrets
feature
as
I
said,
pretend
that
it
wasn't
even
there.
If
you
add
this
offline
mode
capability
to
the
driver
now,
because
the
driver
is
running
on
every
cubelet
and
the
driver
would
need
access
to
its
own
namespaces
secrets.
E
That
means
now
I
guess
every
cubelet
already
had
access
to
those
Secrets,
because
it
has
to
do
the
file
mounts
for
you,
but
now
it
like
really
really
has
access
to
them,
because
you're
sticking
them
in
NCD
in
kubernetes
secrets
so
like
you've
made
it
extra
easy
for
it
to
find
them
like
it
doesn't
even
have
to
mess
around
with
file
system
stuff,
and
as
you
mentioned,
though,
whereas
previously
each
cubelet
would
have
its
own
like
file
system
that
you
could
mess
with
now,
each
cubelet
would
be
able
to
read
all
of
the
secrets
that
have
been
synced
in
because
each
cubelet
can
run
as
the
Daemon
set
user
and
thus
read
the
secrets.
E
None
of
this
sounds
great
by
the
way.
All
of
this
sounds
like
like
further
and
further
weakening
of
the
boundaries,
and
then
what
were
you
saying
in
this
about
the
the
from
so
that's
the
weakening
from
the
cubelet
side.
What
was
the
weakening
from
the
driver's
side?
No.
A
I
mean
yeah
like
today.
We
have
no
kind
of
caching
so
like
it's
almost
always
like,
they
have
no
actual
access
right.
They
basically
just
call
out
get
it
at
the
time
time
the
part
is
created,
but
if
they
did
go
and
look
into
the
file
system
yeah,
they
had
access
to
those
secrets.
For
that
part,
but
I
think
like
in
terms
of
auth.
A
Even
though
all
the
driver
pods
have
access
to
it,
if
they
are
the
good
actors,
then
they
would
only
mount
it
for
the
parts
that
have
that
service
account
like
if
there's
some
kind
of
serious
bug.
Yes,
then,
basically,
the
driver
would
just
give
access
to
all
the
secrets
like
it
would
Mount
the
wrong
secrets
in
the
wrong
part
and
give
them
access
to
it
right.
E
So
I
guess
do
we
feel
comfortable,
saying
that
by
building
offline
support
into
the
driver,
which
I
will,
which
obviously
will
still
be
opt
in,
if
you
want
it,
we
are
comfortable
with
both
the
weakening
on
the
driver's
side,
which
you
could
argue
is
fine,
like
the
driver
is
supposed
to
be
a
trusted
agent
for
fetching
secrets
so
whatever,
but
are
we
fine
with
the
weakening
on
the
cubelet
side,
where
we
just
say
yeah
now,
every
cubelet
in
your
environment
can
read
all
of
the
secrets
from
your
cloud
that
you
can
fetch.
D
E
Right
with
the
volume
option,
because
we
would
not
be
using
a
kubernetes
rest
API,
we
would
not
give
access
to
the
driver
to
put
them
where
the
cubelet
can
kind
of
get
to
them,
like
all
cubelets
all
instances
of
all
cubelets,
it
would
instead
be
local,
though
I
I.
Suppose
you
could
argue,
though,
if
whatever
like
like
say,
we
did
it
on
based
on
volumes.
E
Yeah,
so
this
might
just
be
a
side
effect
right,
like
an
inherent
side
effect
of
how
this
has
to
work
right.
It's
like
a
mixture
of
you,
want
offline
support
and
you're
using
a
Damon
site
like
when
you
intersect
those
together.
It's
just
basically
grants
and
read
on
those
objects
to
the
cubelets.
C
I
mean
the
the
attack
surface
on
these
clusters
is
theoretically
already
smaller
by
by
the
nature
of
them
being
disconnected.
A
I
think
if
we
take
the
approach
of
saying
during
the
time
of
disconnection
You're
vulnerable,
but
once
you
come
back
online,
we
will
switch
back
to
the
default
behavior
and
like
not
have
all
these
things.
A
That
could
be
fine,
like
basically
like
we
don't
rely
on
the
cash
and
any
of
that
once
we
are
online,
so
that
that
is
the
ability
for
us
to
distinguish
between
the
offline
mode
and
like
actual
letters
right
like
at
which
point
do
we
want
to
look
at
the
cash
and
use
that
value
or
we
are
online
and
there's
an
actual
error
like
in
those
cases.
A
We
just
want
to
error
out
like
straight
up
like
how
we
do
it
today,
so
I
think
we
need
that
ability
to
distinguish
so,
like
the
provider
could
tell
us,
hey
use
the
cash
or
not,
and
so
that
means
when
we
come
out
of
the
offline
mode,
then
we
can
still
go
back
to
the
whole
Behavior.
So
we
still
as
secure
as
we
are
today.
E
The
driver
is
as
secure,
but
the
cubelet
model
isn't
as
great
oh
yeah,
right
yeah,
so
yeah,
no
I
totally
agree
with
the
driver
uses
the
cache
when
it
strongly
understands
that
it
should
use
the
cache.
It
should
not
just
use
the
cache,
because
it
has
it
right
like
as
a
for
example.
If
it
gets
like
a
401,
unauthorized
or
something
from
the
provider,
it
should
not
fall
back
to
the
cache
and
just
ignore
that
and
be
like.
No,
you
didn't
really
mean
that
right.
I
already
asked
that.
A
But
also
when
you
say
the
cubelet
one
still
exists
that
you're,
referring
to
like
cubelet
having
access
to
all
the
mounts
right.
So
basically
it
has
access
to
the
file
system.
E
No,
what
I
was
saying
is
that,
like
when
we
come
online
right,
we're
not
going
to
go
delete
our
cash.
A
E
E
Right
we
had
yeah,
so
we
yeah,
we
should
obviously
go
delete.
The
cache
from
the
TPL
expires
as
a
way
of
like
preventing
us
from
accidentally
ever
using
the
cache
when
it's
been
expired,
but
yeah,
I,
yeah
I,
think
you
foundationally
sort
of
give
all
cubelets
where
your
Damon
set
is
running
access
to
all
of
the
secrets
that
you're
gonna
sink
I.
Think
you
have
to
accept
that
I
think
that's
just
part
of
how
this
has
to
work.
E
D
D
So
like
that's,
what
I
think
it's
important
to
opt
in
in
the
future
and
I'm
not
sure
yeah?
How
much
to
weigh
that
like
way
solving
that
versus
solving
like
more
immediate
user,
things
of
like
yeah
wanting
it
in
secrets
and
wanting
it
cashed,
yeah
I,
don't
know
it
seems
Seems
hard.
A
So,
when
you
say
the
indirection,
are
you
referring
to
the
kubernetes
secret
and
the
CID,
the
customer
users
great.
A
Yeah
I
mean,
if
it's
all
in,
if
you're
doing
all
of
this
in
Cube
system,
right,
like
let's
say
like
we're,
caching
it
and
putting
in
Cube
system
like
as
a
cluster
admin,
I
can
control
access
on
who
has
access
to
which
namespaces
Secrets
image
name
space.
So,
like
a
user,
wouldn't
have
access
to
the
skill
system.
A
E
Right,
yeah:
that's
why
I
kind
of
think
of
this
as
a
secret
class
right
like
it's
just
a
it
is
a
secret.
It's
just
has
a
separate
authorization
check
to
get
access
to
the
data
inside
of
it,
I
mean
if
we
want.
Maybe
we
just
bring
this
to
the
like
the
next
take
off
meeting
and
be
like.
Does
this?
Does
this
make
sense,
or
are
we
just
making
up
like
a
concept
just
because
we
think
we
should
Xander?
Did
you
have
other
open
questions?
C
E
So
what
what
work
is
needed
there
is
is
this
something
that
we
would
have
to
go
like
make
a
small
POC
or
something
to
kind
of
play
around
with
the
code
to
get
a
sense
of
like
how
yeah
I
I
can't
immediately
conceptualize
what
the
cache
key
is
going
to
be
other
than
like
hand
waving
like
workload,
and
something
also
that
reminds
me
when
you
do
the
CSI
volume
out.
You
can
ask
for
like
multiple
tokens
right.
E
Right
different
audiences
right,
so
I
guess
as
a
just
a
like
a
gut
check
with
the
cash
key.
Just
be
that
service
account
or
would
the
cash
key
be
all
of
the
audiences
it
has
to.
A
Be
for
the
specific
audience
right
so
like
we
would
have
to
rely
on
the
provider
to
tell
us
which
audience
it
used
out
of
the
seven
are
like
audiences
that
it
used
to
cash
based
on
that,
because
the
next
time,
some
other
part
comes
with
just
one
of
the
audience.
We
don't
want
to
give
it
access
to
that.
C
I
think
part
of
that
was
my
initial,
like
one
of
the
reasons
I
was
originally
thinking
about
thinking
of
storing
the
crd
in
the
workloads,
namespace
and
the
cache
key
in
Cube
system,
because
then
you
can
rely
on
like
what's
defined
in
the
the
secret
provider
class.
To
kind
of
you
know,
since
it's
namespace
scoped,
that
kind
of
gives
you
some
some
information
on
the
key,
but
I
don't
know
if
that's
actually
a
good
idea
or
not.
E
E
Okay,
so,
but
based
on
what
you
just
said,
initial
it
to
me,
it
opens
the
question
that
I
wasn't
sure
about
which
is:
can
we
do
this
purely
at
the
driver
or
or
does
this
actually
definitely
require
provider
level
changes.
E
I
have
no
idea
what
kind
of
error
the
driver
gets
when
the
provider
is
offline
and
if
it's
like
something
that
the
driver
can
explicitly
make
sense
of
like.
Oh,
it's,
a
network
error
and
thus
I
do
fall
back
to
cash
I
that
one
I
could
think
we
might
be
able
to
do
without
provider
changes
but
I'm
less
sure
about
like.
E
If
the
provider
wants
to
inform
us
about
some
logic
that
we
need
to
do
like,
for
example,
the
whole
audience
thing.
There's
no
way
for
us
to
infer
that.
That's
it's
a
black
box
right,
but
it
does
sound,
really
kind
of
terrible.
If
we
have
like
seven
providers
that
exist
today,
so
we
gotta
go
tell
all
of
them
hey.
If
you
want
to
support
caching,
now
you
got
to
like
return
extra
data
to
us
so
that
we
know
how
to
do
the
caching
I
mean.
Maybe
it's
fine,
but
it
seems
a
little,
not
great.
A
I
think
on
the
provider
level
already,
there
are
few
required
changes,
because,
like
provider
has
to
tell
us
how
long
it
has
to
cash
and
all
of
those,
because
the
provider
is
one
that
tells
us
right
and
then
also
I.
Think
today
we
talked
about.
We
need
to
know
what
error
means,
which
error
means
we
could
use
the
cash
value
so
like.
That
is
also
something
that
the
provider
has
to
tell
us
like
as
part
of
the
failure.
A
E
So
would
we
what
was
I
going
to
ask
so
I,
don't
know
like
what
kind
of
Errors
come
over
the
RPC.
So
are
you
saying
that,
like
we
can't
tell
from
the
grpc
code
that
it
was
like
a
network
failure.
A
For
Network
failures,
I
mean
we
can.
If
the
RPC
calls
fails,
then
that's
there,
but
we
can't
tell
what
error
the
provider
had
while
talking
to
the
external
Secret
store,
like
the
provider
passes
it,
but
we
just
have
to
see
if
that
is
consistent
across.
Are
all
the
providers
right
like
in
terms
of
what
errors
like
I
mean
I,
think
unauthorized
and
stuff
like
that
like
would
be
similar
across
all
the
providers?
A
E
Yeah
I
don't
think
we
want
implicit,
the
things
that
make
us
do
security
actions
with
generally
a
Surefire
way
to
do
something
wrong.
So
Xander
correct
me:
if
I'm
wrong,
I
thought
the
caching
policy
was
defined
at
the
custom
resource
level
and
not
the
provider
level.
I
don't
have
an
opinion
really
here.
I'm,
mostly
just
asking
right
now.
F
The
canis
the
secret
object,
but
I'm
interested
I
mean
there
anyways,
not
strict
right
provider.
They
just
have
to
interpret
them.
A
Yeah
I
think
in
terms
of
caching,
we
want
to
cache
on
the
entire
secret
provider
class
right
like
I.
We
don't
need
granularity
on
the
secret
level,
but
I
think
that
it
boils
down
to.
If
we
want
the
provider
to
tell
us
the
cache
key
and
everything
like
do.
We
want
the
provider
to
tell
us.
The
TTL,
too,
are.
E
E
Imagine
us
coming
up
with
some
way
for
them
to
say
this
secret
is
super
important,
so
give
it
like
a
one
hour
TTL,
but
the
other
one's
not
so
important,
so
it
can
be
a
month
and
like
I,
don't
know
how
we
would
go
about
doing
that,
because
we
would
have
to
build
an
entire
config
layer.
There
then
yeah
I,
don't
know
if
that
really
I
mean
like
yeah.
If
you
really
want
it,
then
sure
it
makes
sense
to
do
that.
I
guess!
Maybe
the
way
I
would
think
about.
E
A
So
I
think
that's
kind
of
the
approach
that
we've
taken
today
to
like
so
rotation
and
stuff.
Like
we
configured
at
the
driver
level,
and
then
we
opened
an
issue
asking
users
if
they
want
to
like
be
granular
and
do
it
at
each
secret
provide
a
class,
but
no
one
asked
for
it.
So
like
we
ended
up
just
keeping
the
global
one.
A
A
Seems
fine,
yeah,
but
I
think
going
back
to
your
point
about
like
in
terms
of
what
we
want
to
do
next
right,
like
I,
think
a
POC
might
definitely
help
like
answer
some
of
these
questions.
E
So
for
cigarth
we
have
the
indirection
question
about
the
custom
resource
and
then
once
we
understand
the
enough
with
the
POC
to
understand
the
cache
key,
then
we
would
bring
that
there
and
be
like
hey
like
here's,
the
high
level
idea,
it's
going
to
be
opt-in.
The
reason
this
opt-in
is
because
it
weakens
the
cubelet
boundary.
Maybe
nobody
cares
or
if
or
if
anyone
wants
this
feature,
they
cannot
have
that
boundary.
E
They
have
to
give
up
the
boundary,
because
the
thing
is
that
Damon
said
there's
no
way
of
getting
around
that
or
or
you
could
schedule
the
Daemon
set
only
on
the
cubelets
that
you
want
to
be
in
your
pool,
but
there's
no
nothing
further,
that
you
can
restrict
and
then
like.
This
is
how
we're
gonna
have
the
providers
and
drivers
cache
things,
or
this
is
how
the
caching
will
work
based
on
the
changes
to
the
provider
and
the
driver.
E
Did
we
break
anything?
Basically,
okay,
I
assume.
A
Yeah
I
think
that
should
be
fine,
but
also
the
thinking
over
is
the
provider
is
the
one
that
still
tells
us.
If
you
can
use
the
cash,
so
it
still
knows
which,
if
it's
not
a
network
error
like
we
would
still
not
use
the
cache
so
like
the
users
will
still
just
not
benefit,
but
if
they
don't
want
to
remember
and
go
and
update
the
TTL
every
time,
so
they
just
set
it
to
like
an
arbitrary
long
value.
E
F
I
have
questions
that
so
let's
say
I
mean
we
are
like
disconnected
and
we
have
a
copy
of
secret
on
a
pod.
Then
we
came
back
online,
but
then
we
realized
the
secret
might
have
been
updated
in
the
keyboard
right
then
who?
F
And
what
do
we
do
and
who
will
do
to
update
that
copy
in
the
driver
like
do
we
do
our
regular
periodic
sync
and
say
that
hey
now
it's
changed
so
we're
going
and
updating
the
mount
in
the
driver
and
in
the
pod
and
what,
if
it
has
it's,
also
synced
as
an
environment
variable
in
the
current
state,
like
we
also
restart
the
Pod,
or
how
do
we
make
sure
that
updated
copy
is
updated
in
the
workload
after
coming
back
online.
F
B
E
Yeah
so,
like
I,
think
that's
a
good
point:
I'm,
not
100
sure
what
we
could
do
there.
It
does.
But
it
is
interesting
that,
if,
like
I
guess,
do
you
guys
have
a
sense
for
what
people
set
rotation
intervals
to
normally.
A
So
the
default
we
have
is
two
minutes.
Some
of
them
who
use
the
driver
only
for
like
certificates,
set
it
for
like
24
hours,
because
they
know
the
search.
Don't
change
that
often
but
I.
Think
for
people
who
constantly
keep
changing
like
in
devops
scenario
and
stuff
like
they
even
try
to
keep
it
at
10
seconds.
F
F
And
that's
why
I
asked
that
earlier
question
like
people
don't
want
stealth
secret,
apparently
so
right
now
that
they
are
doing
is
the
like
intense
polling,
I,
guess
so
that
that
thought
is
still
there,
I
guess.
So
how
is
there
a
way
we
can
address
that
in
a
disconnected
as
well
or
it's
just
gonna,
be
there
too.
E
Yeah
so
I
guess
in
disconnected
when
you
go
offline,
the
cash
policy
would
take
place,
and
so
we
would
leave
everything
as
is
so
today.
I
would
assume
that
if
you
get
a
failure
during
the
rotation
or
what
you
don't
do
anything
like
I
mean
you
might
make
a
log
or
whatever
make
an
event,
but
you
don't
do
anything
to
running
pods.
Remember
right!
E
A
Oh
you're,
saying
during
the
disconnected
period
of
our
TTL,
expires
right,
yeah
I,
don't
think
we
would
change
the
behavior
we
would
still
if
so,
this
is
still
considered
just
like
a
failure
right
like
so
first
call
is
external
Secret
store
that
fails.
Then
we
look
at
our
internal
Secret
store,
which
is
the
cache,
and
if
that
also
failed,
we
don't
go
affect
any
existing
workloads,
but
any
new
workload
that
comes
up
will
straight
up
fail,
saying,
like
I,
don't
have
anything
that
I
can
mount
with.
E
Yeah
I
mean
I'm
more
trying
to
think
about
like
what
is
expected
Behavior
here
right.
So
it's
it's
a
little
weird
that
new
pods
can't
come
up,
but
the
existing
pods
are
coasting
on
some
like
Old
State,
but
I,
guess:
I!
Guess
that
wouldn't
happen
right
because
well
no
matter
so
the
cash
could
have
expired
and
thus
been
invalidated.
So,
even
though,
technically
the
driver
has
access,
you
know,
assuming
it
didn't
literally
go
delete
its
cash.
E
A
I
mean
think
about
it.
The
driver
is
only
really
called
during
like
two
two
hooks
right
like
one
Hook
is
when
the
part
gets
created
like
Cuba
tells
us
to
mount,
and
then
the
second
Hook
is
cubelet
explicitly
tells
us
hey.
You
go
on
Mount,
so
in
between
that
mount
and
unmount
the
assumption
is,
the
CSR
is
not
doing
anything
there.
A
They
added
the
requires
republishing
CSI,
like
like
few
releases
back
where
they're
like
cubelet,
will
call
you
like
periodically,
so
you
go
and
do
whatever
you
have
to
like
it's.
The
amount
had
failed
before
go
retry
it
or
make
sure
that
it's
back
to
the
same
state.
We
expect
it
to
be
in
kind
of
things
like
that
right,
but
other
than
that.
The
expectation
is
in
between
that,
like
you,
don't
go
and
do
anything
to
the
already
existing
thing.
Unless
you're
explicitly
told
to
do
so,.
E
So
so
let
me
ask
a
question:
what
was
the
field
called
requires?
What
republished
yeah
so
that
republished
field,
like
so
say
that
set
and
the
cubelet
does
call
us
and
our
cash
is
expired?
What
do
we
do
yeah
right?
So
we
so
we
purposely
ignored
the
fact
that
the
user
configured
a
cache
TTL
and
it's
no
longer
going
to
be
honored
for
this
pod
because
it
was
running
before
then
yeah.
A
I
mean
I
think
it
depends
on
how
we
see
the
cash
as
like.
If
you
see
the
cash
is
just
something
for
like
few
to
use
and
stuff
like
that
like
that
is
a
different
thing.
But
if
we
say
like
that
is
the
current
state
of
world
and
like
we
will
use
that
like
strictly
then
yeah,
you
would
want
to
go
and
break
all
the
existing
pods.
A
E
Yeah
I
mean
I,
think
that
makes
sense,
I
I
think
what
this
would
come
down
to
is
the
documentation
for
the
TTL
field
would
very
explicitly
say.
This
applies
to
new
pods
that
existing
pods
might
not
get
updates
to
their
secrets
if
things
are
offline,
but
we
don't
like
basically
once
you
give
access
to
a
kubernetes
to
a
secret
to
a
running
workload.
A
Yeah
and
I
think
like
one
of
the
questions
that,
like
I,
saw
in
some
other
doc.
Not
this
one
is
someone
had
asked
what
happens
if
the
dash
expires,
like
I,
think
that's
a
valid
question
so
like
this
Behavior
thing
is
one,
but
also
like
I.
Think
in
that
some
other
dog
I'd
seen
someone
had
mentioned
that
maybe
just
keep
reusing
the
cash.
Even
it's
expired
and
all
of
that,
like
I,
don't
think
we
want
to
offer
that
level
of
granularity
where
we
say
what
to
do
if
cash
expires
and
stuff
like
I,
think.
E
Yeah,
so
we
would
say
if
the
cash
is
expired,
new
stuff
doesn't
work,
but
old
stuff
is
unaffected
and
if,
if
that's
a
problem
for
you,
will
you
set
a
longer
cash
detail
right
and
you
can
set
it
as
long
as
you
want,
and
thus
you
can
set
it
long
enough
that
there
effectively
cannot
be
an
impact
on
workloads
as
long
as
the
secret
was
at
least
fetched
once
somewhere.
A
A
Sorry,
okay,
but
this
is
a
big
discussion.
I
think
there's.
The
other
topic
was
going
to
be
the
controller
stuff
like
where
we
wanted
to
go
in
detail,
but
I'll
move
that
to
the
next
agenda,
but
I
think
yeah.
We
don't
have
to
wait
till
the
next
one
like
we
can
do
async
conversations
too
on
the
design
dock.
E
Okay,
now
we
we
also
probably
should
find
victim
for
the
POC.
E
It's
just
me
being
fun.
That's
that's
just
me
describing
it
funny
ways,
not
necessarily
that
it's
a
bad
question
might
be
a
fun
exercise.
I
I
might
volunteer
to
be
the
victim,
mostly
because
I
haven't
read
the
CSI
Secret
store
code
base
in
like
three
years
or
something
so
whatever
no
longer
has
any
context
in
my
head.
Oh.
A
Yeah
I
can
pair
with
you
on
it
sure.