►
From YouTube: Secrets Store CSI Community Meeting - 2021-01-21
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,
that's
regarding
hey.
Everyone!
Welcome
to
the
secret
store,
csi
community
call
it's
jan
21
2021,
and
this
call
is
gone
by
the
cncf
code
of
conduct
and
is
also
being
recorded
I'll
be
moderating
today.
Is
anyone
willing
to
take
notes
for
the
meeting,
or
I
can
just
do
that.
A
Okay,
jumping
into
the
agenda.
The
first
thing
that
I
added
was
we
released
0.19
for
the
driver
in
terms
of
the
change
changes
that
were
introduced
in
that
it
was
mostly
changes
to
the
helm,
charts
and
I
think
one
important
change
was.
We
also
patched
the
base
os
image
for
our
vulnerabilities
that
we
found
the
long
term
plan,
for
that
is
to
update
the
base
image
to
a
newer
version
when
that's
available
and
that
was
released
yesterday.
A
So
I
have
a
pr
to
update
to
the
latest
base
image
which
fixes
all
these
vulnerabilities,
and
also
for
as
part
of
that,
I'm
working
on
adding
the
image
scanning
for
vulnerabilities
as
part
of
the
ci.
C
Hey
yeah:
that's
right!
Thanks!
Yeah!
Thanks
for
that
update
on
the
race,
it's
called
here
yeah.
So
this
was
just
something
that
came
up
on
pr
internally
and
yeah.
I
had
a
go
at
trying
to
make
the
our
provider
run
as
a
non-root
user,
but
found
that
that
wasn't
possible,
because
host
paths
are
only
writable
by
root
users
like
host
path
volumes
and
yeah.
C
I
just
thought
I
know
in
the
in
the
previous
call
tommy
was
suggesting
he
might
write
a
design
document
to
have
the
driver
write
the
secret
material
to
the
pod
instead
of
the
provider,
which
would
eliminate
one
host
path
volume
from
the
provider.
C
I
thought
I
just
kind
of
gauge
interest
in
whether
this
is
a
problem
that
we're
interested
in
solving
or
motivated
to
solve
and
any
kind
of
ideas
on
yeah
how
we
might
go
about
it
because
yeah.
It
feels
like
it's.
It's
something
that,
yes,
it's
obviously
a
best
practice
to
run
containers
as
non-root
users,
but
at
the
same
time
we
won't
be
able
to
eliminate
the
driver
being
able
to
having
to
run
as
a
root
user.
C
But
it
does
provide
a
nice
kind
of
separation
of
concerns
between
the
driver
and
the
provider
where
the
driver
is
the
cube
admin
and
does
kind
of
cube
admin
stuff
and
the
provider
handles
the
the
auth
with
the
the
secrets
provider.
So
so
yeah.
I
just
kind
of
wanted
to
throw
it
out
there
and
see
see
if
you
had
any
thoughts
on
it.
A
I
think
one
of
the
ideas
there
was
a
sidecar
approach
and
yes
yeah,
I
think
so
initially,
when
we
were
designing
this,
I
think
we
also
thought
about
doing
the
provider
as
a
side
car
to
the
driver
right,
but
I
think
some
of
the
cons
with
that
approach
was
one.
If
you
wanted
to
deploy
another
provider,
that
would
mean
you
need
to
restart
the
driver
pod
on
every
node,
because
the
driver
has
to
be
a
side
card
in
that
part
right.
A
So
that
was
one
concern,
but
even
in
terms
of
setting
the
grpc
socket
for
the
host
path,
do
we
actually
need
root
privileges
for
just
the
host
path.
C
So
because
it
creates
essentially
a
file
to
to
listen
on
the
host
path
that
that's
kind
of
considered
needing
right
privileges.
So
that's
the
that's
the
current
right.
So
if
you
try
to
run
the
provider
as
as
non-root
you
just
get
a
kind
of
failed
open,
socket
message
can't
write
to
that
volume.
A
No,
I
think
it
does.
Actually
I
thought
not
root
user
would
work
for
hostpath
and
then
the
only
thing
that
we
would
really
need
was
to
constrict
using
port
security
policies
or
other
ad,
but
other
policies
right.
So
in
psps
you
can
say
that
restrict
only
access
to
host
path
for
this
particular
part,
and
then
I
thought
only
that
would
be
enough
and
I'd
once
tommy's
changes
go
in.
We
would
not
require
root
privileges.
C
Like
yeah,
I
guess,
if
you,
if
you
configure
access
to
the
to
the
path
that
the
socket
will
be
created
in
from
the
host
side
like
from
the
node
side,
then
then
that
that
would
work.
I
I
guess
I
didn't
really.
Think
of
that
as
being
a
possibility
is,
is
that
what
you're
suggesting
with
the
pod
security
policies.
A
So,
with
the
pod
security
policies,
we
can
associate
the
service
account
that
the
provider
is
using
and
then
we
can
only
provide
privileges
for
just
host
path
and
nothing
else.
So
we
can
make
sure
that
the
pod
only
has
access
to
what
it
needs
and
nothing
more
and
once
tommy's
changes
are
there.
Then
I
think
the
pod
doesn't
even
have
a
need
right
access
or
anything
right,
because
the
driver
is
the
one
that's
going
to
get
the
payload
and
write
the
contents
to
the
pod
mount.
C
Okay,
yeah
yeah
that
actually
sounds
quite
good.
I'll
have
a
look
into
yeah,
whether
that
will
work,
because
I
was
trying
to
use
ffs
group
options
for
the
pod,
and
that
was
what
I
I
kind
of
yeah
found.
Didn't
support,
host
path
volumes,
but
yeah
I'll
see.
If
I
can
do
it
with
pod
security
policies
and
report
back.
A
Okay-
and
I
think
we
should
as
a
follow-up,
we
should
also
open
an
issue
on
github
so
that
we
can
continue
the
conversation
there
and
see.
What
is
the
final
decision
that
we
want
to
make.
B
Yeah,
I
was
also
gonna
ask
like
sounds
like
tommy
wanted
to
create,
like
a
design
doc
for
us
to
review
right
at
least
I
think
from
last
call
yeah.
That
would
be
useful
to
be
linked
within
that
particular
issue.
A
A
And
then
the
third
one
that
I
added
was
a
very
short
one.
Basically
erita
shared
this
security
audit
meeting
that
was
going
on
as
part
of
six
security
yesterday,
so
I
was
able
to
hop
on
the
call-
and
I
talked
a
little
bit
about
the
secret
store,
csi
driver
with
them,
and
then
I
requested
them
to
add
this
to
their
scope
for
ordered
this
year.
So
they
gladly
accepted
it.
And
now
it's
part
of
their
scope
for
the
rfp
for
third
party
audit.
A
So
now
with
the
team
is
actually
working
on
the
rfp
and
then
they're
going
to
choose
a
vendor
and
when
they
do
the
audit
the
secret
store.
Csi
driver
is
going
to
be
a
part
of
it,
so
we'll
be
able
to
run,
ordered
and
test
to
make
sure
that
the
solution
is
safe
and
I've
also
added
the
meeting
nodes
there.
If
anyone's
interested
in
joining
it's
a
bi-weekly
call,
they
recommended
that
I
joined
the
call
by
weekly
if
they
had
any
questions
about
the
project.
If
anyone
else
is
also
interested,
they
can
join
the.
A
Call
okay
and
I
think
one
more
thing
was:
I
opened
an
issue
yesterday
for
the
wall
provider.
I
think
the
wall
provider
released
0.0.7
with
the
grpc
changes,
so
we
also
need
to
update
the
tests,
but
I
I
just
saw
that
tom
has
appeared
for
it.
C
Yeah
yeah
yeah,
that's
right
and
I
it's
on
my
to-do
list
to
kind
of
change
the
way
that
those
tests
work
so
that
I
can
kind
of
control
yeah
control
better
when
when
the
tests
actually
get
updated,
because
the
fact
that
it
kind
of
applies
from
master
yeah
just
makes
it
a
bit
awkward
to
to
do
releases
without
breaking
the
tests,
but
yeah,
hopefully
that
pr
should
the
test
should
pass
once
it
gets.
Okayed.
C
B
Oh
wow,
I
just
couldn't
say
I
was
thinking
like
the
change
that
we
want
to
make
to
to
make
the
driver
write
the
content
inside
of
the
providers.
We
should
really
try
to
get
that
in
before
the
security
audit,
just
because
it's
a
big
change-
and
I
want
to
make
sure
whatever
gets
audit-
is
more
closer
to
what
people
end
up
running.
C
A
Not
yet
so
they
said
they're
going
to
finish
and
submit
the
rfp
and
after
that
they
have
to
choose
a
vendor.
So
I
think
it's
probably
going
to
be
another
month
before
they
actually
begin
the
audit,
so
I'm
guessing
probably
first
week
of
march
but
I'll
check
with
them
and
on
a
concrete
timeline
to
see
what
they
have.
C
Cool
yeah
sounds
like
going
quite
a
good
point
in
the
process
right.
A
I
think
that's
it
for
the
agenda
items,
we
don't
have
anything
else,
I'm
working
on
the
broad
production,
readiness
questionnaire,
so
I'll
open
a
pr
for
that
for
review
and
I'll
post
it
on
slack.
So
everyone
can
get
a
chance
to
review
it
before
we.
B
Merge
great,
do
you
have
any
updates
for
other
providers
out
there
that
you're
working
with.
A
Yeah,
actually,
someone
from
aws
reached
out
to
us
on
slack,
so
they
were
initially
in
the
design
phase
for
adding
a
new
provider
for
the
driver
and
now
they've
completed
the
design
phase
and
they've
started
the
implementation
work.
So
they've
been
going
through
a
repo
on
docs
on
how
to
add
a
new
provider
and
they've
started
working
on
that,
so
they'll
be
reaching
out
more
on
slack
when
they
have
questions,
because
all
providers
on
that
slack
it'll
be
great.
A
A
Okay,
I
think
that's
it.
If
no
one
asks
anything
else,
then
I
think
we
all
get
about
40
minutes
back.