►
From YouTube: Secrets Store CSI Community Meeting - 2022-01-20
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
and
welcome
to
this
session
of
the
csi
secret
store
meeting.
It
is
january,
20th
2022..
A
As
a
reminder,
this
call
falls
under
the
cncf
code
of
conduct
and,
if
you
wanna
familiarize
yourself
with
that,
please
visit
the
repo
and
read
the
call
the
conduct
markdown
file
and
with
that
we'll
go
ahead
and
kick
it
off
looks
like
we
got
a
pretty
short
agenda
from
what
I'm
seeing
no
announcements.
But
I
know
this
has
been
brought
up
in
several
last
meetings,
so
we're
definitely
going
to
get
a
poly
out
to
do
a
survey
on
when
we
would
like
this
meeting
to
occur.
A
If,
if
this
time
is
good
or
if
it's
not
so,
let's
just
go
ahead
and
get
a
vote
out
there
and
see
where
that
lands.
B
Yeah,
so
actually
it's
an
old
issue.
I
think
if
we
can
open
it,
you
can
see,
but
then
this
is
the
particular
issue
actually
tom
had
opened.
This
is
about
running
the
providers.
Non-Root
I
mean
as
an
on
root
user,
and
actually
we
got
like
a
similar
issue
like
I
think
it
was
in
this
way
where
one
of
the
user
was
looking
for
if
we
can
run
the
driver
as
a
non-producer
as
well.
B
So
I
just
wanted
to
sort
of
bubble
this
up,
I'm
not
sure
if
we
had
like,
I
I'm
certain
like
there.
It
might
be
some
discussion
in
our
community
meeting,
but
I
just
wanted
to
sort
of
bubble
this
up
again
and
see
what
everybody
thinks
or
you
know
what
was
our
thought
process
behind
this
or
you
know
what
we
discussed
things
like
that.
C
Yeah,
I
think
the
same
user
also
opened
the
issue
on
gcp
provider,
and
then
I
was
discussing
this
with
tommy
right,
so
maybe
for
the
pro
so
for
the
provider.
Today,
the
root
privileges
are
only
required
because
we
need
to
create
and
bind
the
socket.
So
if
we
can
find
a
way
not
where
we
don't
need
to
be
root
user.
For
that,
I
think
we
can
do
that
because,
right
now,
all
the
providers
return
the
files
to
the
driver.
C
They
don't
write
to
the
file
system
anymore,
so
they
don't
need
any
root
privileges
in
that
way.
So
it's
only
for
the
socket
purposes,
but
in
case
of
driver
we
still
need
to
be
rude
because
we
need
to
perform
the
mount
operations
and
then
write
to
the
file
system,
and
I
think
there
are
two
aspects
to
this
right:
one
is
there:
are
certain
scanners
like
image
scanners,
which
scan
just
the
content,
the
vanilla
container
image?
C
So
if
you
don't
set
the
user
directive
in
the
docker
file,
then
those
scanners
are
basically
flagged
the
image
saying
there
is
no
user
directive.
This
is
running
in
the
root
right.
One
way
to
circumvent
that
that
we
have
been
doing
in
some
of
the
projects
is
setting
the
user
explicitly
to
some
other
user.
Like
some
sixty
four
thousand
sixty
three
thousand
something,
and
then
in
the
yaml
file,
you
can
actually
set
it
to
run
as
a
root,
so
we
can
see
if
that
works.
C
So
that
is
one
thing
where
it
will
supplement
the
issue
where
image
is
just
the
when
the
images
are
scanned
and
they
are
flagged,
but
the
second
point
coming
down
to
running
as
root
that
is
still
required
for
this
driver,
at
least
just
because
it
needs
to
do
the
mount
operation
and
that's
what
I
think.
B
So
for
the
first
option
that
you
mentioned
right,
I
think
if
we
scroll
down
this
issue
right,
I
have
sort
of
linked
those
two
issues
together
in
that
new
issue.
The
user
had
exactly
the
same
problem
like
I
think
their
image
was
flagged
because
some
scans,
so
what
you
mentioned
right,
should
we
just
have
it
as
default?
I
guess
like
this
kind
of
thing
or
meaning
like
in
our
driver
image,
we
can
do
that.
B
I
mean
we
can
set
it
explicitly
and
then
we
will
update
our
yaml
and
then
charts,
probably
because
that
is
that
an
option
basically.
C
Yeah,
I
think
that
that
will
be
good,
like
I
think
in
general.
Right
now
also,
the
recommendation
is
to
have
the
user
specified
in
the
docker
file,
so
that
will
definitely
like
help
with
this
issue.
Right,
but
again,
we
just
have
to
make
sure
users
know
that
it's
still
running
as
root
so
like
we
can
still
document
it
and
say:
hey
look,
even
though
we
set
the
user
there.
D
I
would
I'd
rather
not
add
complexity
to
make
the
lenters
happy
or
I
think,
kind
of
adding
a
non-root
to
the
docker
file,
but
then
running
it
as
root
is
kind
of
like.
D
I
think
that
adds
cognitive
overhead
when
like.
If
the
result
is
it's
running
as
root
in
the
cluster,
I
I
think
it's
better
to
be
kind
of
just
like
up
front
on
that,
but
there
may
be
ways
where
we
can
have
like
other
specific
capabilities
or
yeah.
I'm
not
sure
if
there's
a
way
to
have
kind
of
a
non-root
user
that
is
able
to
manage
mounts
volume
mounts
right.
D
Like
that's
the
that's
the
main
thing,
I
think
I
think
the
the
unix
sockets
we
could
probably
get
around
by
having
you
know
user
group
world
like
readable
writable
on
like
the
folder
or
something
so
I
I
just
haven't,
looked
into
it
to
see.
If
there's
a
way
to
get
that
permission
but
yeah,
I
don't
think
it's
worth
it
to.
A
Right,
I
guess
I'll
come
from
a
different
angle.
What
is
the
what's?
What's
the
exposure
or
the
risk
here?
I've
I've
not
read
through
the
issue,
but
I
guess
if
we
can
concentrate
on
kind
of
why
we
would
not
want
this
to
run
as
root
and
see
what
type
of
exposure
see
if
we
can
kind
of
just
mitigate
that
part.
If
that
makes.
B
Sense,
yep
yep,
so
actually
I
was
going
to
ask
this
exact
same
question
so
in
this
particular
issue,
what
we
are
looking
at
is
right
user
is,
I
mean
asking
is
like
you
know,
hey.
If
we
are
running
this
as
a
route,
then
what
possible
security
issues
we
can
get
into
so
I
mean
I
am
okay
with
either
idea
with
what
anish
and
tommy
suggested
but
like.
B
If
we
decided
to
not
do
any
changes,
then
maybe
we
should
at
least
add
some
kind
of
a
documentation
or
some
note
by
saying
our
dogs
were
saying
that
hey,
we
have
to
run
as
a
root
for
these
these
reasons,
and
this
might
be
the
potential
issue.
And
honestly,
if
you
look
at
that
issue,
I
mean
I
answered
it
like
in
a
generic
way,
because
I'm
not
sure
or
I
have
not
came
across
any
particular
issue
because
of
the
root.
So
I
just
told
them
like
hey.
B
D
This
does
remind
me,
like
we
were
gonna,
get
a
security
review
or
like
an
external
audit
thing
like
a
while
ago,
I
forgot
to
follow
up
bird.
Like
did
that
happen,
because
I.
C
Think
that's
still
going
on
the
whole,
I
think
they're
still
almost
close
to
completion.
Like
I
checked
with
them
yesterday,
they
still
haven't
shared
the
results
and
all
that,
but
it's
still
an
ongoing
process
cool
because.
D
That
might
be
where
we
can
get.
You
know
like
good
feedback
on
that,
where.
D
Especially
on
alternatives
of
like
you
know,
if
we
are
over
privileged
just
as
a
root,
but
that
there's
a
way
to
make
it
an
honor
user
have
the
the
permissions.
We
need.
I'm
just
not
familiar
enough
with
the
like
unix
kind
of
heard
of
the
linux
specific.
C
C
But
yeah,
at
least
in
the
azure
provider.
Today
we
recommend
them
they
deploy
it
in
cube
system.
So
if
they're
using
their
csi
driver
and
provider,
we
just
tell
them
that
like
hey
look,
these
are
all
high,
privileged
parts
and
run
it
in
cube
system.
Because
that's
where
you
have
all
your
system,
critical,
pods
running,
which
have
high
privileges
and
then
you
can
lock
down
that
particular
name
space.
So
we
have
that
directive
there.
C
But
I
think
having
a
parallel
comment
here
in
our
documentation,
just
to
say
why
we
need
root
and
then,
like
nellic,
suggested
what
potential
issues
that
we
are
aware
of
and
then
also,
I
think
we
all
already
recommend
running
it
in
cube
system
so
that
we've
already
covered
that
base
here.
So
we
just
need
probably
additional
documentation.
B
C
Yeah
and
then,
if
in
the
audit,
if
they
have
spent
quite
amount
of
time
on
driver
and
all
the
components
that
were
listed,
then
the
results
will
also
be
public.
So
we
can
always
reference
that
too
and
say
like
hey
look.
All
this
was
reported,
we
fixed
it
and
then
like
users,
can
also
be
aware
that
in
the
older
versions,
what
could
be
the
issue
perfect.
B
A
C
B
Sorry,
no,
I
just
wanted
to
sort
of
just
bring
the
thing
like
in
azure
provider.
We
recently
implemented
the
file
permissions
logic,
basically
so
like
if
user
mentioned
like
they
want
to
mount
secrets
with
a
particular
file
permissions,
we
sort
of
implemented
that
logic,
I'm
not
sure
like.
If
other
providers
has
that
kind
of
request
or
not,
but
I
just
wanted
to
sort
of
load
this
did
you
say
that
you've.
B
Does
that
I
mean
we
have
not
cut
the
radius,
yet
we
just
like
watched
it
yesterday,
but
following
release
of
azure
provider
will
have
that
flexibility.
I
guess.
D
Great
yeah
I
had
looked
into
that
on
a
gpc
one,
but
have
not
merged
anything.
For
that,
I
think
great
we
had
talking.
D
One
one
or
two
meetings
ago
and
I
think,
like
yeah,
it's
it's
possible
right
now
on
profile,
but
there
was
something
of
like.
If
we
want
the
secret
provider
class
to
specify
a
default,
then
we
might
want
to
change
the
driver.
B
Yeah,
I
think
so
right
now,
like
the
implementation,
is
pretty
simple.
Like
we
added
like
in
the
objects
array,
we
added
like
another
field,
called
file
permission
so
like.
If
it's
mentioned,
then
the
provider
will
try
to
return
that
file
permission.
What
basically
user
has
given
and
if
not
then
just
return
the
default
file,
permission
which
driver
passes
to
provider
and
basically
the
current
flow
so
like
no
changes
to
driver,
or
rather
the
schema
of
rcrd.
C
I
think,
like
a
starting
point
is
I
think,
users
want
control
for
each
individual
object
right
rather
than
the
whole
secret
provider
class.
So
this
approach
will
be
nice
and
then,
if
there
is
an
ever
request
where
they
say
like,
I
just
want
to
define
it
on
the
secret
provider
class
level,
then
we
can
think
about
the
schema
changes
and
maybe
providing
it
to
the
director.
B
One
more
thing
actually
I
was
discussing
with
nh-
is
like
this
potentially
gives
like
a
full
control
to
the
user,
and
you
know
they
can
set
pretty
much
any
permission
that
they
want,
which
includes
like
full,
read,
write
execute
permissions,
so
it
would
be
kind
of
nice
to
see
user
feedback
on
this
and
see
you
know
if
there
are
any
potential
issues
with
that
or
are
they
good
with
it?
So
that's
it.
B
Sorry,
honey
yeah,
that's
it!
I
was
just
wanted
to.
C
Oh
yeah,
the
other
one
was,
I
think
we
talked
about
this
the
last
time
right.
So
the
there's,
a
user
who
has
a
pr
open
for
the
socket
path
so
like
today
we're
using
the
slack
hc
folder
and
then
here's
a
pi
to
move
it
to
wire
run,
and
then
I
think,
on
the
last
call.
We
discussed
that
we
want
to
support
it
in
a
backward
compatible
way,
so
we
will
search
both
the
volumes.
So
I
think
we
should
include
that
in
the
1.1
release.
C
Phil,
if
you
go
to
issues
yes,
this
one.
C
Yeah
we
discussed
about
including
this
in
1.1
release
and
then
I
think
tommy
had
suggested.
We
should
just
ensure
we
do
it
in
a
backward
compatible
way.
Rather
than
saying
it's
a
breaking
change,
and
now
users
all
have
to
go
and
update
both
driver
and
providers.
C
So
we
can
do
this
in
a
backward
compatible
way
and
then
add
this
to
the
change
log.
And
then
we
can
tell
users
that
going
forward,
we
will
be
supporting
only
liquid
run
as
a
default
instead
of
etsy.
C
B
We
can
just
put
out
a
notice
for
that
right
now
right,
because
when
we
did
v1,
it's
like
pretty
much
exact
same
copy
right.
We
didn't
do
any
changes.
So
if
you
are
not
anticipating
sorry,
I
mean
that's
what
I'm
saying
so
like.
If
we
are
pretty
much
sure
that
we
are
not
going
to
break
this,
maybe
we
can
start
the
deprecation
process,
maybe.
C
Yeah,
I
think
I
think
we
need
to
see
what
the
kubernetes
api
depletion
process
is
too
right.
So
basically
we
just
have
to
follow
that
right
now,
we're
serving
both
of
it,
because
it
was
only
in
this
release
that
we
added
it
and
then
we
just
have
to
come
up
with
a
release
number
where
we
say
we
no
longer
serve
it.
So
then,
if
a
user
tries
to
create
even
alpha
one,
it
will
start
erroring
out
and
saying:
hey
just
use
v1.
C
B
Yeah
and
that's
what
I
was
mentioning
so
like
maybe
from
this
release
or
the
release
note
of
this
1.1,
we
can
mention,
or
we
can
just
see
what
that
we
can
start
the
application
process.
Basically
by
telling
them.
A
Good
stuff,
all
right,
so
we'll
wrap
it
up
thanks
everyone
for
joining
our
next
call
will
be,
I
believe,
it's
february
3rd
again,
we'll
try
to
get
a
poly
out
this
this
week
to
take
a
survey
on
the
change
of
this
meeting.
The
timing
of
this
meeting
and
with
that
we'll
go
ahead
and
end
the
call
thanks
everyone
and
we'll
see
you
in
a
couple
weeks.
Thank
you.