►
From YouTube: Secrets Store CSI Community Meeting - 2021-07-08
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
All
right,
hello,
everyone,
thank
you
for
joining
this
week's
csi
secrets.
Community
call
it's
july
8th,
and
this
meeting
is
under
the
cncf
code
of
conduct
guidelines,
so
please
be
respectful
when
having
conversations
with
others
with
that
looks,
like
we've
got
a
pretty
pretty
light
agenda
here.
In
fact,.
A
No
items
as
of
yet,
but
I
know
micah
had
mentioned
that
he
has
a
demo
that
he
would
like
to
show
to
the
community.
A
He's
ready,
okay!
So
with
that,
I
won't
even
bother
to
share
the
our
dock
here.
So
let
me
go
ahead
and
bump
you
up
micah
to
make
you
a
presenter
here.
A
And
I
guess,
before
you
jump
into
that
micah
is
there
any
other
items
that
anyone
wishes
to
to
chat
about
or
discuss
either
from
last
meeting
any
any
follow-ups
or
anything.
C
Next
week,
I
think
is
when
we're
scheduled
to
do
another
release
of
the
the
driver.
I
think
it's,
I
think
it's
next
week,
but
yeah
another
release
should
be
coming
pretty
shortly.
I
think,
before
the
next
meeting,
so.
A
Okay,
all
right
thanks
for
that
update,
tommy!
Okay.
So
with
that
hey
the
floor,
joe's
micah
show
us
what
you
got.
B
All
right,
you
can
see
my
screen,
yes
great,
so
basically,
this
is
kind
of
based
on
the
the
pr
that
I've
had
out,
and
I
saw
that
there's
been
some
comments
on
it,
so
I
will
get
to
those
shortly,
but
the
basic
idea
where's
my
here
it
is-
is
so
this
is
leveraging
the
token
request
functionality
in
csi.
B
B
Basically,
it
enables
the
a
csi
sidecar
to
not
need
its
own
identity
to
do
stuff
for
pods
right,
like
you're
passing
the
token
that
is,
that
the
cubelet
acquired
from
the
api
server
for
that
specific
pod
and
the
great
thing
about
that
is
cubelet-
is
by
nature
of
of
the
node,
authorizer
and
and
node
admission
controller.
B
The
node
can
only
request
tokens
for
pods
that
belong
to
it.
The
public
can
only
request
tokens
for
pods
assigned
to
that
node.
So
I
can't
get
a
token,
for
you
know,
say
maybe
some
administrative
pod
on
some
other
node.
So
I
get
these
great
authorization
boundaries
built
in
to
built
into
token
request.
So
when
cubelet
passes
on
this
token
request
like
token
well
this
this,
I
just
kind
of
diagrammed
for
myself
just
to
get
my
head
around
the
flow.
B
Basically
yeah
cuba
requested
token
from
the
api
server
and
that's
the
again
scopes
down
so
that
it's
only
for
that
pod
api
server
is
making
sure
it's
not
for
a
pod
on
another
node
cubelet
is
requesting
in
in
this
sense
to
this,
I'm
calling
this
irsa
agent,
but
that's
basically
secret
store
provider
right
and
in
this
model
you
can
sort
of
think
is
this
I,
what
I've
modeled
as
this
irsa
agent
and
the
the
secret
store
plug
like
plug-in
provider,
that
I
wrote
as
the
same
component
just
because
they
effectively
have
the
same
boundary
here.
B
So
the
plug-in
then
requests
from
from
what
I
showed
before
there
was
a
just
just
a
cs5
sidecar.
Now,
what
I
have
is
basically
a
small
server
that
can
run
somewhere
else
in
the
cluster,
so
the
csi
sidecar
can
now
or
the
the
provider
for
the
the
secret
store
provider
can
request
from
a
local
server,
say
hey,
I
need
something
in
exchange.
For
this
token
now.
This
server
that
I
have
running
has
mappings
of
aws
iam
roles
to
service
accounts.
B
So
when
a
specific
token
for
a
specific
service
account
is
given
this
server
then
can
validate
that
token
can
call
token
request
against
keep
api
server.
It
could
do
it
all
in
memory
and,
do
you
know
oi
oidc
validation
on
the
server
itself,
but
for
now
I'm
just
calling
kubernetes
token
request,
because
that
tells
me
is
it
valid.
Is
it
signed
by
the
api
server
and
everything
else
there?
B
Then?
What
I
have
happening
is
this:
this
server
is
calling
aws
sts,
assume
role,
so
that's
basically
a
way
to
use
its
own
identity
that
the
server
has
to
get
credentials
for
some
other
role,
and
it
knows
this
based
on
the
mapping.
That's
given
to
this
server
so
right
now
I
just
am
supplying
the
the
mapping
of
service
account
to.
B
I
am
roll
via
a
simple
config
file
that
could
easily
be
changed
to
a
crd
or
other
stuff
later,
so
it
gets
back
these
role
credentials
and
then
it
can
can
pass
those
role
credentials
on
back
to
the
the
the
secret
store
plug-in
provider
and
which
gets
passed
back
to
secret
store
and
gets
mounted
and
gets
into
the
pod
right
and
in
the
end
of
the
day,
that
gets
mounted
as
an
aws
config
file
into
the
pod
right.
B
So
that's
great,
like
we
get
credentials
down
in
the
pod,
and
I
demoed
this
largely
last
time
without
the
server
side.
So
it's
just
the
the
agent
kind
of
doing
everything
where
the
agent
was
talking
to
sts.
The
advantage
that
I
have
here
with
this
server
that's
kind
of
cool
is
that
aws
sts
has
an
a
a
feature
where
you
can
assume.
When
you
call
assume
role,
you
can
provide
what
are
called
session
tags.
B
These
are
key
value
context,
pairs
that
get
injected
into
the
aws
session
token.
So
what
I'll
show
really
quick
is
when
I
have
so
I
have
a
just.
This
is
my
again.
I
have
this
running
in
a
cluster
but
I'll
just
demo,
it
locally.
B
So
I
have
a
little
server
running
that
that's
essentially
this
request
server.
It
has
its
own
im
credentials
that
can
assume
another
role,
and
this
I
have
a
little
client
here
that
is
I'll,
see
where's
the
client
okay.
So
this
client
has
a
token
I
can
actually
let
me
get
the
token.
B
This
is
basically
mimicking
cubelet,
getting
a
token
for
a
pot
right,
and
so
I'm
just
picking
core
dns.
In
this
case,
it's
making
a
token
request
request,
just
like
the
cubelet
would
and
getting
back
to
token
for
in
this
case,
accordion
spot.
B
So
if
I
call
get
hack
token
get
token,
I
should
oh
wrong
hold
on
I'm
in
the
wrong.
B
Place,
I
have
my
contacts
all
next
time.
Okay,
so
I
have
a
token
there's
my
pod
uuid
and
now
what
I'm
going
to
do
is
write.
Use
that
token
to
write
credentials.
B
Basically,
I
have
a
small
client,
that's
basically
again
acting
like
that
that,
like,
like
the
secret
store
plug-in
and
I'm
going
to
write
the
those
credentials
to
a
file
okay.
So
if
I
assume
config.
B
Oh
I'm
against
the
wrong
api.
Actually,
yes!
Well!
I
can
actually
show
this
really
quick.
So
if
I
okay
get
pod
all
names,
facebook,
oh
wide,
all
name
spaces.
Okay,
so
I
have
a
cox
cluster
and
it
has
has
all
the
components
here
running
what
I've
got
is
so
here's
an
example.
Really
quick
is
I've,
got
the
cert,
well,
okay,
the
server
running,
and
when
I
call
assume
role,
I
do
these
tags,
so
I
say:
namespace
cube
system
service
account
uid,
pod
uid.
B
So
all
these
key
values
are
stored
in
the
session
token.
For
this
for
this
aws
session,
when
I
have
those
credentials,
I
can
do
things
like
hold
on.
B
Nope,
oh,
I
just
cleared
it
out.
Okay!
Well,
either
way.
I
can
show
you
what
I
ran
before.
Basically,
what
happens
is,
and
these
credentials
are
no
longer
valid,
so
they're
fine
to
record
in
their
recording.
When
I
call
when
I
what
I
did
is
on
the
the
role
that
I
have.
B
That
I
assumed
and
gave
down
to
in
this
case
my
simulated
pod
and
what
this
whole
csi
driver
does
it
has
this
following.
This?
Is
the
cloud
database
confirmation,
templated
iam
policy,
what
this
policy
says-
and
this
is
based
off
the
docs
here-
is
that
someone
with
this
permission
in
this
case
this
role,
can
only
do
things
where
the
session
context
of
that
role
matches
the
tags
in
the
request.
B
B
Obviously,
according
this
is
not
really
talk-
data
secret
manager,
but
what
you
can
do
is
you
can
imagine
this
for
any
other
pod
when
a
pod
gets
the
set
of
aws
credentials,
that
pod
can
talk
to
secret
manager,
but
all
the
requests
when
it
talks,
the
secret
manager
must
have
the
aws
tag,
key
pairs
where
that
key
pod
uid,
that
that
string,
pod
uid,
where
the
value
matches
the
actual
pods
uid
and
the
key
namespace
equals
the
value
of
that
pod's
namespace
in
this
case
cubesystem.
B
So
when
the
pod
gets
an
aws
credential,
if
it
tries
to
say
in
this
case
I
have
the
secret
manager
policy.
If
I
try
to
call-
and
this
this
is
kind
of
small
I'll
increase,
this
font
size
when
the
pod
tries
to
create
a
secret.
So
this
is
an
aws
clock
and
fig
fall
call
using
those
credentials
using
a
secret.
You
know
name,
the
key
secret
name
is
kate's
namespace
secret
dash
cordiness
with
a
description.
The
secret
value
is
quote
super
secret.
B
But
when
I
do
the
here
again,
key
namespace
equals
value
cube
system.
I
also
get
an
access
to
nine
because
I
don't
have
that
second
condition.
B
When
I
ran
it
again
and
I
set
here
the
tags
to
namespace
cube
system
and
pod
uid
to
that
actual
pod
sessions
uid,
I
can
actually
so
these
cards
are
actually
valid.
No
that's
the
token
just
kidding
that
pod
id
I
actually
can
create
a
secret.
B
So
basically,
what
this
effectively
does
is
I'm
leveraging
secret
manager
to
distribute
aws
credits
around,
but
because
I
have
this
intermediate
server
where
I
can
set
these
session
tags,
I
can
do
cool
things
like.
Oh,
I
know
based
on
this
token,
that
is
being
passed
through
secret
manager.
I
know
all
these
things
about
where
this
token
is
coming
from,
and
I
can
add
that,
to
my
aws
case,
my
aws
session
context
and
then
do
cool
things
like
okay.
B
If
I
want
to
list
secrets
with
that
session
or
with
for
for
that
pod,
then
I
can,
you
know,
maybe
only
list
secret.
B
I
can
list
all
secrets,
but
I
might
be
able
to
only
get
and
describe
secrets
that
are,
in
my
same
name
space,
but
I
can
only
create
secrets
with
my
pod
uid,
so
I
couldn't
maybe
delete
secrets
for
some
other
podu
id,
but
I
could
maybe
read
them
so
this
gives
you
like
really
strong,
like
you,
can
imagine
really
strong
boundaries
around
the
identities
that
you
distribute
to
your
pods
in
in
this
in
this
system,
and
it's
all
leveraging,
like
this
token
request
feature
in
in
csi.
B
The
secret
store
driver,
so
that's
my
demo,
it's
kind
of
basic,
but
it's
and
it's
not
totally
complete.
I
don't
have
it
totally
running
in
cluster
yet,
but
I
just
just
got
this
working
late
yesterday,
so
I
thought
it
would
be
cool
to
show.
A
Yeah
yeah,
that
was
oh
actually,
it
was
pretty
cool.
I
I
got
a
couple
questions
yeah
this
the
session.
What's
the
ttl
on
the
session
is
that
coming
from?
B
B
Mapping
I
can
share
my
screen
again,
so
if
I
again,
this
is
like
a
very
prototype
work
in
progress,
but.
B
B
Right
the
I
could,
I
could
add,
other
things
here,
like
basically
anything
that
I
can
put
into
the
assume
roll
call
like
a
policy
to
scope
down
that
session
to
a
specific
subset
of
permissions
or
something
but
yeah.
A
And
and
that
that
component,
you
referenced
as
what's
like
an
rsa
yeah,
all
right,
okay,
so
that
that's
just
an
end
point
right
that
doesn't
necessarily
have
to
be.
B
In
the
cluster,
so
it
doesn't
have
to
be
in
the
cluster
exactly
right
it
could
be.
You
could
have
a
one
for
multiple
clusters
right
now.
I've
really
written
it
just
to
be
like
one
per
cluster,
but
I
could
use
like
easily
add.
You
know
multiple
clusters
that
it
could
map
to,
so
that
you
know
this
cluster
is
associated
with
this
endpoint
and
so
yeah
all
right,
cool,
yep.
C
The
idea
here
is
not
necessarily
rule
for
extending,
like
the
aws
plug-in,
to
have
a
way
to
do
like
arbitrary
pod
identities,
or
is
that.
B
Yeah,
I
understand
that
yeah.
The
idea
is
just
that.
The
idea
for
this
that's
demo,
like
in
this
project
that
I'm
like
playing
with,
is,
is
that
you
could
get
you
can
inject
session
like
key
value
pairs
based
on
what
like
what
you
want
in
this
case,
I'm
doing
it
all
based
on
the
token
that's
coming
in,
but
I
could
do
other
things
like
like
add
I
mean
labels
are
obviously
can
come
and
go
on
a
pod,
but
I
could
add
label
metadata
in
there
too.
B
So
that
say
your
you
know
your
pods,
like
the
requests
your
pods
make
to
say
manage.
I
don't
know
something
like
secrets,
manager
or
anything
else.
Right
like
in
aws,
need
to
have
the
same
key
value
pairs
that
are
in
your
session,
whether
that's
the
label
or
the
service
account
name
or
the
pod
name,
what
it
or
whatever
it
is
cool.
C
And
then
yeah,
I
think
I
was
one
of
the
last
reviewers
on
the
pr.
So
you
know
feel
free
to.
Thank
me
on
slack
because
I
think
we're
also
pretty
interested
in
getting
that
in
because
it
like
you
mentioned
it,
helps
with
kind
of
like
node
isolation,
yep.
B
C
A
All
right
thanks,
micah,
okay,
I
think
that's
all
we
have
on
the
agenda.
Is
there
any
issues
or
pr's
that
we
want
to
take
a
look
at?
I
can
go
ahead
and
share
out
of
the
list
here
and
let's
see,
if
there's
anything,
interesting
to
chat.
B
B
B
A
All
right,
thanks
again,
I'm
assuming
you
guys
can
see
my
screen.
Is
there
any
any
issues
we
want
to
talk
about
that?
That's
out
here
that
may
be
lingering
or
need
some
clarity.
C
I
was
just
starting
this
morning
to
look
at
the
top
two,
but
so
notice,
I
think,
there's
maybe
timeouts
on
the
windows
tests
that
are
creating
failures.
I
was
going
to
look
in
that
more
today.
I
think
this
aws
one
was
more
of
a
documentation
issue.
In
that
we
have
some.
C
We
have
features
that
are
optional.
Do
that
like
need
to
be
documented,
that
you
need
to
explicitly
have
them.
C
A
All
right,
so
that
is
it
super
quick
call
this
a
week
say
anything.
I
guess
we
can
go
ahead
and
wrap
it
up.
We
don't
have
to
hang
out
before
we
do.
That.
Is
there
any
other
comments
or
anything
anyone
wishes
to.
A
C
Okay,
I'm
just
gonna,
we'll
finish
up
a
little
note
here
on
micah's
demo.
It's
just
like
if
it
looks
right
her,
it
doesn't
look
if
my
summary
doesn't
look
right.
Let
me
know:
okay.
A
A
All
right,
okay,
we'll
go
ahead
and
wrap
things
up.
Our
next
meeting
that'll
be
scheduled
two
weeks
from
now
so
that'll
be
july.
21St
I
will
be
out
of
the
office,
but
I'm
sure
someone
can
pick
up
the
moderator
and
note
taking
at
that
time.
A
Yeah
with
that
we'll
go
ahead
and
in
the
meeting
thanks
for
that
demo
mike.
That
was
actually
pretty
cool.
So
okay,
we'll
go
ahead,
and
hopefully
the
recording
will
be
out
here
the
next
couple
of
days
and
we
will
meet
again
back
on
the
21st
in
a
couple
of
weeks.