►
From YouTube: Secrets Store CSI Community Meeting - 2022-05-26
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
Okay,
hello,
everyone.
Thank
you
for
joining
this
week's
csi
secret
store
community
call.
As
a
note
again,
this
meeting
is
governed
by
the
cncf,
so
it
abides
by
the
code
of
conduct
if
you're
not
familiar
with
all
the
rules
around
code
of
conduct.
Please
visit
the
repo
there's
actually
a
code
of
conduct.
Markdown
file
that'll
have
all
the
information
there
for
you
all
right.
So
welcome
everyone.
Last
couple
of
weeks,
we've
not
had
too
much
attendance
and
glad
to
see
a
lot
of
people
are
attending,
which
is
which
is
great.
A
What
we
tend
to
do
if
we
have
new
people
that
join
the
call.
We
just
like
to
just
do
a
quick
round
just
intro
yourself
to
the
community
and
maybe
speak
about
what
you
like
about
the
project,
or
you
know
anything
else
that
drove
you
here.
So
I'm
just
going
to
go
down
the
list
that
I
see
here,
kind
of
alphabetically,
I'm
assuming
and
I'm
going
to
start
with,
and
hopefully
I'm
pronouncing
this
right
amira.
C
A
Also,
my
new
tommy
one
of
our
maintainers
works
on
google,
so
I'm
sure
you'll
be
interested
in
how
you're
using
the
google
provider.
Thank
you
daniel.
Next
we
have
iden
all
right
and
if
you
want
to
go
ahead
and
introduce
yourself
to
the
community.
A
A
A
A
E
Cool,
so
I'm
yes,
issues
in
my
headset
anyway,
so
I'm
working,
I'm
a
product
manager
from
microsoft,
I'm
working
with
roy
amira
and
new
bio.
Here
we've
been
working
on
the
encryption
provider,
part
which
we'll
probably
gonna
cover
today
in
this
meeting
later
on
first
time
here,
so
it's
nice
to
see
everyone
happy
to
join
those
calls.
A
All
right,
thank
you
for
joining
and
last
but
not
least,
I'm
not
sure
it's
a
foreign
language
to
me.
So
I
can't
even
begin
to
announce
this.
But
if
you
want
to
go
ahead-
and
I
think
there's
just
an.
B
E
A
Icon,
or
is
that
you've
you
follow.
E
F
A
All
right,
so
I'm
assuming
there's
going
to
be
some
big
topics,
the
team's
joining
the
call
thanks
everyone.
This
is
awesome.
Seeing
this
this
call
grow
with
that,
let's
go
ahead
and
get
into
the
meeting,
no
major
announcements.
I'll
be
your
moderator.
A
I
will
try
to
attempt
to
take
notes
on
the
side
here.
No
one
else
wants
to
volunteer
for
that
and
with
that
I
think
nelleck
you
got
a
ton
of
items
lined
up.
I
think
these
are
items
that
were
pending
from
last
week
since
we
had
low
attendance.
We
just
moved
these
forward.
A
G
Yeah,
I
think
those
hyperlinks
might
have
corrupted,
I'm
not
sure
if
they're
not
working
correctly.
A
G
G
Can
this
also
be
supported
for
like
james
path,
queries
and
things
like
that,
so
I
just
wanted
to
circle
back
and
see
now
where
this
pr
is
because
we
were
discussing
those
topics
in
this
peers
in
this
pair
of
probably,
you
know
taking
or
implementing
that
as
a
separate
of
pr.
So
just
one
wanted
to
circle
back
with
everybody.
H
G
G
G
This
is
interesting,
and
I
think
I
wanted
to
talk
with
with
everybody
about
this
okay,
so
the
basic
ask
from
the
user
over
here
is:
they
want
to
have
an
ability
to
set
the
static
secrets
under
the
secret
subject.
So
I
think
a
bit
more
background
on
this
is
so
some
scenarios,
like,
I
think
what
they
have
mentioned.
There
is
like
an
argo
city
where
you
know
they
are
not
like
a
secret
secrets.
G
They
are
just
more
like
a
configuration
settings,
but
they
are
expected
to
be
created
as
a
secret
in
kubernetes
or
argo
city,
for
example,
expects
those
thing
as
a
kubernetes
secrets.
So
what
the
users
asking
over
here
is
like
is
there
a
way
a
secret
store?
Csi
driver
can
do
it
so
basically
in
secret
provider
class.
They
they
want
to
just
mention,
like
you
know,
hey
like
these
are
like
the
static,
static
keys
or
key
value
pairs,
create
them
as
a
secret.
G
So
we
have
a
functionality
in
the
driver
where
we
sync
the
mounted
secret
as
a
kubernetes
secret.
So
using
that
functionality
can
we
just
create
a
static
secret
and
or
static
key
value
pairs?
As
a
secret
as
well
so
yeah,
I
mean
I
just
wanted
to
check
like
everybody's
opinion
on
this
or
what
they
think.
Personally,
I
think
this
is
sort
of
piggybacking
on
the
functionality,
so
I
mean
I'm,
I
personally,
I
don't
think
we
should
implement
it
in
in
this
particular
manner.
What
what
is
being
proposed
here.
G
The
reason
for
that
is
again
like
the
main.
The
core
functionality
of
our
driver,
is
just
fetching
the
secret
and
mounting
it
into
the
wall.
So
that's
that's
like
the
core
essence
of
our
of
this
project.
G
G
Maybe
that
can
be
a
good
candidate
for
this
implementation
or
this
this,
what
particular
ask
what
users
have
but
yeah?
I
just
wanted
to
check
like
everybody's
opinion,
what
they
think-
or
you
know,
does
this
make
sense
to
be
included
in
the
driver
or
not.
I
Yeah,
I
I
just
took
a
look
at
this
one
and
my
rate
on
it
is
that,
if,
if
the
feature
is
needed
for
sync
secrets,
it's
probably
also
needed
for
secrets
that
are
written
to
the
like.
The
the
main
use
case
of
the
the
file
system,
secrets
and
right
now.
What
ends
up
in
the
file
system
is
entirely
determined
by
the
providers.
I
So
if,
if
the
providers
supported
like
hey
this
file
maps
to
the
secret
or
the
setup
file,
snaps
to
these
secrets,
like
the
providers
could
be
extended
to
support
like
this
file
maps
to
this
static
value,
and
then
it
would
be
implicitly
supported
by
the
driver,
because
the
secrets
object
would
would
just
be
able
to
pick
that
up.
It
doesn't
really
care
if
it's
a
secret
or
not
a
secret.
So,
like.
I
think,
there's
a
way
to
support
this
without
changing
the
driver
and
just
extending
some
functionality
to
the
providers.
H
H
They
might
not
want
to
support
static
secrets,
but
if
they
want
to
again
it's
not
something
like
the
driver
really
has
to
worry
about
like
as
long
as
the
file
exists,
the
driver
relies
on
it,
so
we
are
not
building
anything
new
in
the
driver,
so
I
like
the
so
I
think
tommy
also
commented
on
the
issue.
So
that's
good.
G
Perfect
yeah
and
I
think
they
also
have
a
associated
pr
with
it.
I
haven't
look
at
the
pr
like:
what's
their
implementation
is,
but
maybe
we
should
look
at
that
as
well
and
maybe
give
them
this
direction.
I
mean
they
are
very
much
interested
in
this
by
the
way,
so
I
think
we
and
they
they
can
always
get
the
recording
of
this,
but
I
think
we
can
also
have
the
notes
in
there.
C
Yes,
can
I
give
my
input
as
a
end
user,
because
I
open
a
feature
request
as
well:
it's
a
number
938
and
then
there's
another
request
which
is
948,
so
this
is
picking
up
interest
and
by
chance
we
both
get
blocked
by
the
or
we
saw
the
feature
request
by
the
same
reason,
which
is
to
implement
argo
cd
because,
as
so
milec
say,
you
know,
you
need
to
create
six
or
seven
non-actual
secrets
so
because
targo
city
pulled
the
secret
to
to
get
the
configuration.
C
I
don't
want
to
get
into
intermittent
implementation
detail
because
out
of
my
scope,
but
the
initial
proposal
of
setting
it
as
an
nvar
into
the
pod,
I
don't
think
it
will
work
because
at
least
argo
cd
needs
to
fetch
information
from
the
secret
and
then
rather
than
directly
setting
up
as
an
end
value.
C
I
Yeah,
so
I'm
not
sure
if
that
was
a
response
to
my
suggestion
there,
but
my
suggestion
is
that
the
provider
support
it
not
as
an
environment
variable
but
as
as
a
you
know,
this
file
maps
to
this
static
value
rather
than
this
file
maps
to
this
external
secret.
I
Yeah
so
like
under,
like
the
parameters
secrets
we
just
have
like
you
know
something
like
instead
of
resource
name
and
then
a
secret,
we
could
have
like
you
know,
static
string
and
then
a
value
and
then
file
name
and
then
the
file
name
that
it
maps
to.
So,
if
the
gcp
provider
like
adds
that
functionality,
then
no
changes
are
needed
from
the
the
driver
project.
I
You
could
map
just
like
that
file
name
to
a
parameter
in
a
secret
and
it
should
end
up
being
the
same
same
experience.
I
believe
that
is
requested
in
the
the
issue,
but
just
an
implementation
that
pushes
it
to
the
providers
instead
of
the
overall
driver,
which
I
think
would
be
preferable
from
from
the
persona
of
the
maintainers
of
the
driver.
I
C
Like
I
said,
I
don't
want
to
go
into
the
implementation
details,
so
I
don't
know,
let's
you
decide,
which
is
the
best
way
how
to
tackle
this,
because
we
need
to
open
a
feature
request
in
the
to
the
provider.
I
guess
it's
not
maintained
by
you
guys
so
many
things
to
google,
but
I
don't
know
yeah
just
reaching
out.
C
I
Yeah,
we
should
probably
find
out
also
it
sounds
like
there's
one
request
to
the
gcp
provider.
For
this,
I'm
not
sure
it
looks
like
the
nick
that
filed
the
issue
may
be
looking
at
the
aws
provider.
I
So
yeah
it's.
I
think
I
don't
know
how
what
a
good
way
to
to
get
like
more
input
if
they're
people
using
multiple
providers.
But
I
I
think
that's
something
that
I
would
be
willing
to
add
to
the
gcp
provider
and
yeah.
C
The
thing
is,
then:
I
understand
the
the
solution
will
be
tackle
on
each
provider,
not
on
the
driver.
So
just
my
point
of
view
we're
putting
the
balls
into
the
provider
both
outside
and
we
are
not
fixing
this
issue
in
one
go.
It
would
be
fixing
multiple
goals
saying
this
time
correct,
which
will,
which
I
think
will
make
things
more
difficult.
This
is
my
just
my
point
of
view.
Instead
of
pro
you
guys,
I
understand
you,
I'm
not
getting.
I'm
just
saying
my
point
of
view.
C
Then
it
makes
the
solution
much
more
complex,
because
you
know
now
it's
we
need
to
go
to
aws,
gcp,
microsoft,
volt
and
whoever
else
comes
later
on
to
use
this
csi
driver
just
my
five
cents.
I
Yeah,
the
unfortunate
thing
is
that
only
the
providers
know
the
mapping
of
files
like
to
the
contents
of
files,
so
it's
hard
to
add
the
functionality
into
the
driver
across
all
providers.
I
So
if
we
wanted
to
add
it
just
to
the
driver,
there's
probably
a
lot
more
engineering
work
on
figuring
out
how
to
kind
of
create
kind
of
like
a
knowledge
of
the
files
in
the
secret
provider
class
that
the
driver
could
be
aware
of
is
is
part
of
my
technical
explanation.
I
know
that
might
not
be
satisfying
to
and
the
end
user,
but
I
think
that's
why
it
would
be
slower
to
get
this
into
the
driver
than
to
get
it
into
the
different
providers.
G
Yeah,
I
personally
now
agree
after
listening
to
the
solution
like,
instead
of
not
supporting
it
at
all.
I
think
this
is
the
right
way.
Probably
to
do
it,
and
I
I
think
the
other
part
from
driver's
perspective,
which
is,
I
was
gonna,
add,
is
like
it's
more
like
mounting.
Whatever
provider
is
sending
them
back
so
like?
G
If
we
look
at
the
actual
structure
right,
we
literally
the
driver
literally
receives
the
the
file
path
and
the
content,
everything
from
the
provider,
so
if
provider
I
mean
so
whatever
provider
gives
essentially
is
get
is
being
mounted
on
by
the
driver.
So
this
kind
of
does
make
sense
from
that
perspective
as
well
like
let
this
functionality
be
at
the
provider
and
then
whatever
driver
it
is
anyway,
that's
gonna
mount.
A
A
I
Yeah,
I
think,
there's
a
number
of
spots
where
like
if
the
driver
was
able
to
be
more
aware
of
the
contents
of
the
responses
like
this
kind
of
comes
up
in
a
few
different
types
of
issues.
But
and
so
there
may
be
some
sort
of
like
structure,
we
could
extend
the
secret
provider
class
to
have,
like
you
know,
some
post
processing
on
what
is
returned
from
providers.
But
I
I
think,
that's
probably
a
larger
scope
than
what's
needed
to
kind
of
like
satisfy
the
request.
I
A
Discussion
here,
let's
see
next
up
the
left,
you
have
a
proposal
for
encryption
provider.
Let's
chat
about
it.
G
Yeah
right
so
I'll,
do
you
want
to
yeah
cool?
So
we
have
an
actually
issue
created
as
well,
so
I
believe
the
ratio
as
well.
So
what
the
basically
that
issue
says
is
right.
G
Today
we
are
writing
secrets
on
the
file
system
in
the
plain
text
and
we
got
ask
from
the
user.
I
guess
both
internally
and
externally,
like
can
we
or
is
there
a
way
to
encrypt
those
secrets
that
we
would
put
it
on
the
file
system?
Although
it's
a
temp
file
system,
still
it's
it's
a
plain
text
and
that
might
not
be
like
a
fully
secured
solution.
So
that's
what
the
basically
issue
is,
and
the
encryption
provider
is
probably
one
of
the
answer
that
we
want
to
propose
to
address
that.
G
What
what
the
what
the
generic
idea
behind
this
is
like.
We
will
have
a
so.
We
have
a
plugable
provider
model
that
we
use
today.
So
like
we
use,
we
fetch
the
secrets
from
the
external
keyword
using
those
providers,
so
we
just
tell
driver
that
hey.
G
These
are
the
providers
that
are
available
and
in
secret
provider
class
we
just
tell
like
hey
this
is
the
provider
you
should
use
to
fetch
the
secrets
and
rest
of
the
job
is
done
by
the
actual
provider
of
fetching
the
secrets
and
returning
the
file
back
in
the
similar
fashion.
We
wanted
to
also
implement
the
encryption
provider,
so
we
have
written
this
doc
with
the
help
of
our
internal
team
here
at
microsoft,
in
order
to
sort
of
provide
that
functionality.
G
So
the
idea
again,
the
you
can,
I
mean
actually
read
through
the
entire
documentation
and
please
comment
on
on
this
proposal,
but
the
idea
here
what
we
want
to
propose
is
like
we
like
our
existing
provider.
We
will
have
a.
We
will
have
an
encryption
provider
which
driver
will
call.
G
So
when
the
driver
boots
up
our
driver
provider
boots
up,
we
will
also
boot
up
the
encryption
provider
and
that
encryption
provider
will
get
registered
by
the
driver,
similar
to
our
secrets
provider
that
we
have
today
and
we
will
have
a
particular
interface,
so
the
interface.
What
that
what
that
interface
should
look
like
is
also
we
have
outlined
over
here,
and
if
you
can
go
back
right,
sorry,
go
down
scroll
down
a
little
bit,
maybe
at
the
flow
part.
That
might
be
like
a
really
good
way
to
explain
this
right.
G
So
what
what
essentially
the?
What?
Essentially
what
we
are
proposing
is
like?
There
is
a
slight
alteration:
there
will
be
a
slight
alteration
in
the
flow,
so,
for
example,
whenever
we
are
creating
a
workload
part
right,
if
it's
referring
the
csi
driver,
the
driver
is
going
to
call
the
secrets
provider
fetch
the
secrets,
and
once
it
has
the
secret,
we
can
check
whether
whether
the
encryption
provider
is
enabled
or
not
or
whether
user
want
to
include
those
secrets
or
not
so
instead
of
mounting.
G
If
that
encryption
provider
is
set
to
true,
we
will
call
the
encryption
provider,
or
at
least
the
encrypt
method
of
an
encryption
provider,
get
the
encrypted
content
back
and
then
mount
it
to
the
driver.
So
that's
the
that's
the
essence
of
it
or
that's.
That's
the
core
gist
of
it.
G
Couple
things
I
wanted
to
discuss,
but
before
that
I
just
wanted
to
open
floor
for
the
questions.
First,.
G
Or
do
you
think
it
will
be
a
good
idea
to
go
through
all
the
document
or
just
all
the
section
step
by
step?
What
do
you
guys
think.
E
G
Right,
yeah,
weekends,
sure
yeah,
it's
it's
that
that's
and
that's
that's
why
I
was
not
sort
of
going
through
point
by
point
because
anyways,
like
people
have
to
probably
go
through
the
document
and
comment
and
whatnot.
But
one
thing
I
will
do
I
just
wanted
to
talk
about.
There
are
some
open
questions
as
well.
They
might
they
might
be
straight
forward,
but
anyways.
I
wanted
to
just
touch
base
on
that,
so
that
whenever
you
guys
are
reviewing
this
document,
you
will
have
that
at
the
back
of
your
mind
as
well.
G
So
one
of
the
thing
is
like
whenever
we
do
this
encrypt
operation
right
so
for
okay,
first
of
all,
like
we
are
proposing
that
this
whole
thing
should
sit
behind
a
feature
flag.
So
that
way
we
can
maintain
the
backward
compatibility
as
well
and
then
the
another
problem.
The
benefit
of
this
is
like.
If
some
provider
is
out
of
the
box
providing
into
an
encryption,
then
probably
they
don't
want
to
use
this,
so
they
can
just
disable
it.
G
So
having
said
that,
so
let's
say
there
could
be
a
scenario
where
driver
got
the
secrets
from
the
provider
and
it
wants
to
encrypt.
But
then
the
encrypt
call
fails
right.
Then.
What
should
we
do
like?
Should
we
just
reject
all
the
requests,
or
should
we
sort
of
partially
fulfill
it?
So,
for
example,
I
mean
we
still
made
that
call
and
we
still
got
the
secret.
G
So
that's
that
in
it
itself
like
like
an
expensive
call,
so
we
have
the
secret,
but
just
because
encryption
provider
is
failing,
we
should
not
reject
it
and
mount
the
content
anyways.
G
So
should
we
take
that
path
or
if
we
have
to
take
the
path
should
that
be
configurable,
like
let
user
decide
what
happens
if,
if
the
encryption
provider
fails,
do
they
want
to
mount
the
secret
as
is
or
just
reject
the
request?
The
from
the
user
experience
perspective?
G
Whenever
this
thing
happens,
the
pod
is
stuck
into
container
creating
space.
So
if
they
choose
to
just
discard
the
mounting
in
this
case,
then
yeah
the
pod
will
be
stuck
at
the
container,
creating
state,
and
then
we
will
have
to
just
go
through
the
logs
from
the
drivers
and
providers
and
figure
it
out.
What's
going
on.
G
So
that's
so
that's
one.
My
one
question.
The
second
question
is
more
of
like
a
logistics
of
it
like
where
we
should
quote
it
and
had
like
a
bit
of
a
discussion
with
anish,
and
he
had
like
a
really
good
suggestion
on
that,
but
wanted
to
discuss
with
the
broader
audience
as
well.
So
I
think
what
we
are
proposing
in
the
document
right
now
is.
We
will
have
just
like
any
the
other
providers
that
we
have
right
now
correct.
G
We
will
have
a
separate
repository
created
for
for
the
encryption
provider
as
well,
and
there
can
be
like
many
encryption
products
like
microsoft,
probably
is
going
to
write
one
but
google
or
anybody
else,
or
they
can
write
their
own
product
as
well
or
so.
Okay.
So
if
this
is
the
case,
then
probably
we
can
end
up
posting
that
into
our
respective
organizations
data
repository
or
I
think
the
other
thing.
G
G
So
if
that
is
the
case
or
like,
if
we
decided
to
write
one
for
for
this
for
for
the
driver,
then
should
we
host
it
in
like
kubernetes
itself,
and
things
like
that,
so
that
that
is
the.
That
is
another
open
question
right
now.
G
I
think
what
we
are
proposing
from
the
microsoft
end
is
like,
as
I
said
like,
we,
we
have
our
internal
security
team
who
is
already
working
on
it
right,
so
we
will
probably
have
our
own
proprietary
implementation
for
now
for
the
driver,
sorry
for
the
encryption
provider.
So
probably
we
will
end
up
creating
that
into
our
of
our
organization's
repository
itself
and
we
will
have
just
a
grpc
software
to
communicate
like
we
have
for
the
other
providers
today.
That's
the
that's
the
idea,
but
yeah.
A
I
want
to
make
sure
I'm
wrapping
my
head
around
this,
so
the
solution
is
to
encrypt
the
secret
on
the
mounted
drive
correct.
That's
good!
That's
right,
but
I
guess
I'm
looking
at
from
just
a
developer
right.
B
J
H
G
G
What
that
end
user
experience
will
look
like
right
like
how
the
decrypt
will
work
essentially,
so
what
we
are
proposing
right
now
is
for
this
from
the
driver
perspective,
the
responsibility
of
this
provider
is
to
just
encrypt
and
the
decrypt
should
handle
by
the
encryption
provider
out
of
the
box
so
for,
for
example
like
if,
if
there
is
some
workload
who
who
wish
to
encrypt
the
secret
right,
it
will
install
the
driver
and
the
required
providers
with
with
those
settings
and
the
content
that
will
get
mounted
on
that
workload.
G
They
will
be
encrypted
now,
since
the
encryption
provider
knows
how
to
encrypt.
It
also
knows
how
to
decrypt
right
and
it
will
have
a
necessary
interface
in
order
to
do
that,
encryption
and
anti-correction.
So
whenever
they
want
to
decrypt
it,
they
will
directly
call
the
underline,
underline
encryption
services
in
order
to
decrypt
that
secrets
and
use
it
in
the
use
it
in
that
code.
G
So
that's
that
is
going
to
be
the
user
experience
and
still,
I
think
we
are
refining
on
it
and
I
think
probably
amira
or
other
folks
can
probably
add
add
to
here,
but
but
this
is
what
we
are
thinking
right
now
from
the
providers
implement
from
the
encryption
provider
perspective
not
for
from
the
enterprise
perspective.
So
as
far
as
the
interface
goes
or
the
driver
responsibility
goes,
it
will
encrypt
and
it
its
job
is
done.
B
B
Okay,
can
can,
I
add
few
words
yeah
and
the
suggestions.
The
suggestion
for
the
proposal
for
the
encryption
provider
is
just
for
encrypting,
the
secret.
We
are
not
giving
here
the
details
about
how
the
application
or
the
service
running
on
the
pod
will
use
it.
This
is
something
that
is
proprietary
or
internal.
It's
it's.
B
For
example,
you
can,
you
can
think
of
a
common
key
or
a
common
hardware,
key
on
the
node
itself,
and
the
encryption
provider
will
encrypt
with
this
key,
and
the
pod
itself
will
be
able
to
access
this
key
and
later
decrypt
it
when
it
needs
to
use
it.
But
this
is
only
you
know.
The
details
of
the
entire
solution
are
left
out
of
this
proposal
because
they
are
internal.
B
We
are
just
giving
here
the
interface
for
an
encryption
provider
just
for
encrypting
or
binding
this,
the
secret
to
the
to
the
node,
we're
not
telling
here
or
describing
how
the
secret
will
later
be
used,
and
it
will
not.
It
will
not
be
used
through
the
encryption
provider.
So
it's
not
part
of
the
proposal
itself.
B
B
D
This
is
only
a
generalization
of
of
the
of
actually
the
encryption
process
of
the
secret
in
order
to
get
a
really
secure
solution
accurately
to
the
environment
you're
running.
So
we
are,
we
are
going
to
implement
a
tailored
tool
to
our
environment,
but
it
might
not
apply
to
other
environment
and
you
need
you
need
a
different
solution
for
that.
So
this
is
just
an
generalization,
so
we'll
be
able
and
to
fetch
the
secret
from
the
secret
provider
and
encrypt
it
before
anyone
can
read
the
file
on
the
on
the
mountain
yeah.
I
So
I
I
think
I
left
some
comments
on
the
dock,
but
I
I
think
you
can't
just
describe
the
encryption
interface
without
describing
the
ux
of
what
the
workload
needs
to
do,
because
you
can't
evaluate,
like
the
security
of
the
interface
without
knowing
like
what
happens
on
the
decryption
side.
And
so
that's
my
yeah.
I
Without
some
description
of
what
the
workload
is
supposed
to
do
to
consume,
the
contents
of
the
encrypted
like
yeah,
and
also
like
at
that
point,
like
the
workload
could
probably
just
be
talking
to
the
secret
api
directly
like
I'm,
not
sure
why
you
would
be
using
the
file
system
for
this
to
consume
the
secrets
if
the
workload
needs
to
be
modified
to
do
decryption,
because,
if
you're
able
to
modify
the
workload
like
just
talk
to
the
seekers,
api
directly
is
generally.
I
What
we
have
told
integrators
concerned
with,
like
the
secrets
being
unencrypted
in
the
file
system,
is
a
quick
and
easy
way
to
keep
secrets
out
of
the
file
system.
So
just
talk
to
the
api
and
not
write
them
to
the
file
system,
but
yeah.
I
I
can
see
the
yeah
I
can
see
the
appeal
I
know
there's
also
like
the
other,
like
kubernetes
secrets,
has
the
same
problem
or
like
a
desire
to
bind
kind
of
or
incorporate
the
secrets
but
yeah
without
a
more
complete
flow
of
what
the
workload
does.
G
Okay,
cool
yeah.
That's
that's
actually
a
valid
question.
So
let
me
do
this.
So
I'll
probably
just
go
back
to
the
team
and
we
will
just
try
to
hash
it
out
the
user
experience
part
of
it
and
we'll
try
to
elaborate
on
on
it
here.
A
G
B
While
the
pod
is
is
running,
so
we
are
leaving
the
secret
in
plain
text
on
the
file
system,
even
though
it's
in
memory,
but
it
is
in
plain
text
and
the
main
idea
behind
adding
it
to
the
csi
driver
is
that
the
mount
itself
will
mount
an
already
encrypted
secret
so
or
something
that
if
someone
can
view
it,
it
will
not
make
any.
We
could
not
use
it.
B
So
we
need,
I
mean
we,
we
need
to
to
mount
it
already
encrypted,
or
at
least
the
value
in
the
tempest
should
be
encrypted,
and
this
is
something
that
csi
driver
today
cannot
do,
even
even
if
the
secret
is
encrypted
in
the
hcd
or
in
the
azure
keyboard,
it
is
protected
once
it
is
mounted
it's
in
plain
text.
I
I
understand
that
the
way
that
we've
addressed
this
is
like,
if
you
have
the
ability
to
change
the
application
to
perform
decryption,
we
have
recommended
people
just
not
use
the
csi
driver
to
avoid
the
file
system
entirely
and
change
the
application
to
talk
to
one
of
the
secret
apis
directly
like
ins,
instead
of
performing
a
decrypt
right,
just
make
the
api
call
to
vault
or
key
vault
or
secret
manager
directly,
and
that
are
at
least
from
my
perspective.
I
B
F
B
I
You
still
have
the
same
problem
of
making
all
of
the
pods
need
to
know
how
to
perform
the
decryption,
and
in
my
view,
then,
you
have
like
a
key
management
problem
and
an
application
update
problem
which,
which
is
more
complicated
but,
like
I
understand
the
generic
request
of
like
yeah.
If
there's
a
generic
way
that
everything
does
like
decryption
and
applications
can
leverage
that
that
it's
it's
useful.
B
It
gets
re-encrypted
through
the
provider
automatically
and
then
updated
in
the
pods
mount,
and
if,
if
the
application
itself
needs
to
be,
you
know
communicate
with
a
with
a
keyboard,
it
needs
to
be
aware
of
rotation
and
update
the
secrets.
It's
more
complicated
and
the
csi
driver
is
much
more
useful
here.
I
I
There
is
some
amount
of
modification
in
order
to
need
to
to
notice
and
react
to
new
values
too.
So
that
is
also
a
point
where,
instead
of
a
file
read,
it
could
be
an
api
call.
B
I
A
I
think
yeah
I
just
want
to
be
mindful
of
the
time
I
know
there's
a
couple
of
I'm
fine
if
we
want
to
continue
this
conversation
on
this
or
if
we
want
to
just
add
comments
to
this
doc
and
have
this
discussion
on
slack,
I
don't
know,
let
me
just
double
check.
What's
left
chat
about.
A
The
last
just
okay,
so
this
is:
let's
see
this
okay.
H
Okay,
yeah,
but
again,
just
to
add
my
quick
two
cents.
I
think
what
tommy's
saying
is
perfectly
violent
right,
like
in
terms
of
the
user
experience
on
the
decrypt
flow,
like
at
least
my
personal
opinion
is,
if
we
can
validate
this
design
with,
maybe
like
some
of
the
users
who
are
asking
for
it
like
just
to
see
what
they
think
about
making
code
changes
to
actually
do
the
decrypt,
or
would
they
rather
prefer
just
moving
away
from
csi
driver,
given
this
limitation
like
that
will
also
be
like
a
value.
G
That
makes
sense
yeah.
So,
let's
I
think,
let's
probably
let
me
work
with
the
team
and
see
what
that
user
experience
is
going
to
be
and
we'll
try
to
sort
of
put
those
in
the
in
the
dock
and
see
at
least
the
flow
of
it.
G
G
Sorry,
real
quick,
so
tommy
for
for
for
your
suggestion,
what
what
you
suggested
right
or
you
have
been
suggesting
to
user
for
doing
the
encrypt
and
decrypt
by
themselves.
So
what's
the
generic
flow
gonna
look
like
like
when
people
put
the
secrets
in
the
keyword
they
will
be
in
the
encrypted
by
default,
so
when
they
are
mounted,
they
are
always
encrypted,
and
then
they
know
how
to
decrypt
it
because
they
encrypted
it
in
the
first
place.
I
No,
what
you're,
describing
there,
I
think,
would
would
work
and
provide
encrypted
secrets
on
the
file
system,
but
without
any
driver
changes.
I
think
the
desire
here
right
is
the
unencrypted
values
to
be
in
the
external
store
and
then
to
do
some
encryption,
but
the
the
work
like
if
the
files
on
disk
are
encrypted
and
encrypted
by
the
provider,
then
we
need
to
describe
what
is
the
workflow
like?
What
is
the
workload
need
to
do
to
decrypt
those
values.
G
No
that
that
that
part
I
completely
agree.
I
was
just
trying
to
understand
your
suggestion
that
you
give
to
user
otherwise,
like
I
think
I
get
it
now,
so
I
think
probably
you
just
said,
like
don't
use
csi
driver
at
all
and
just
talk
to
secrets,
api
directly
and
fetch
the
secrets
encrypt
it
or
decrypt
it
in
the
application.
However,
we
want
is
that.
I
Yeah,
I
can
yeah,
I
can
write
it
down,
but
like
one
of
them
is
to
just
use
the
seekers
api
like
directly
with
no
encryption,
but
then
using
the
api
right.
It
never
enters
a
file
system.
It's
just
in
task
in
memory,
okay,
the
other
one
would
be.
You
know
app
like
the
user.
When
writing
a
secret
to
like
key
fault,
could
encrypt
it.
Client-Side
write
it
to
key
vault.
Csi
driver
brings
the
encrypted
value
right
to
disk
and
then,
since
they
encrypted
it
before,
they
wrote
it
to
key
vault.
I
Both
of
those
things
require
no
changes
from
the
driver
or
providers,
but
the
it
seems
like
what
this
is
looking
for
is
the
value
in
key
vault.
Is
you
know,
unencrypted
the
provider
fetches
that
and
then
does
some
sort
of
encryption
before
giving
it
to
the
workload
and
yeah
the
the
question
is,
then,
how
does
the
workload
consume
the
encrypted
value
yeah?
I
So
it
seems
like
three
approaches
this
one
talks
about
the
third,
but
just
leaves
out
the
what
the
workload
needs
to
do
and
that's
what
I
think
is
kind
of
the
important
part
to
evacuate.
H
I
think
last
year,
right
like
where
the
user
actually
stores
the
encrypted
secret
in,
like
the
external
secret
store,
and
then
our
driver
would
get
it
and
put
it
in
the
file
mount
like
and
then
the
decryption
part
was
the
only
concern
there
because,
let's
say
it's
encrypted
using
like
a
private
key
or
something
so
does
the
driver
get
the
private
key
and
store
that
in
plain
text
or
would
the
workload
just
have
to
make
one
external
api
call
to
get
that
encryption
key,
keep
it
in
memory
and
then
do
decryption
the
decryption
story.
H
A
All
right
a
lot
of
discussion
on
that
topic.
I
guess
going
forward
yeah.
This
is
the
the
doc.
So
just
add
your
comments
to
it,
and
I
guess
we'll
pick
this
up
in
a
couple
weeks.
A
H
Okay,
I
think
only
one
thing
was
I
did
see.
There
was
one
github
issue
that
got
reopened
for
matrix
in
gke,
so
I
think
they
are
saying
only
in
gk
clusters.
H
They
are
unable
to
see
the
metrics,
so
I
think
we
might
need
to
look
into
that,
like
I
think
it's
issue
number
eight
to
one.
H
A
H
Did
tag
tommy
in
it
but
like
just
so
that
we
can
try
and
repro
but
yeah.
We
can
probably
take
a
look
because
I
thought
it
was
only
one
user,
but
there
are
a
couple
of
them
who
are
saying
they're
only
having
issues
in
gke
so
and
app.
I
know
we
get
these
metrics
in
azure
and
we
haven't
had
any
issues
because
we
have
that
as
part
of
the
add-on.
H
All
right
yeah,
but
that's
all
I
have
and
then
I
think
in
terms
of
the
next
driver
release,
there's
one
pr
that
we
want
to
add.
So
I
will
open
that
up
for
review
soon,
but
we
can
plan
for
the
release
in
the
next
two
weeks.
Like
that's
what
I
was
thinking,
provided
we
get
all
the
feedback
and
getting
merged.
A
So
we
have
that
from
last
meeting.
Awesome.
Okay,
I
think
we're
at
time
thanks
everyone
good
conversations
around
the
encryption,
I'm
sure
we'll
continue
on
next
call
will
be
in
a
couple
weeks.
That's
gonna
be
june.