►
From YouTube: Kubernetes SIG Security Assessments 20230227
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
I'll
just
put
the
note
stock
in
chat
again
for
you
Grace,
so
yeah
I'll
just
go
ahead
and
kick
things
off
so
here
we
are
everyone.
It's
been
a
long
time
coming.
I'm
super
excited
to
get
this
started
yeah.
So
if
you
want
to
put
your
name
and
pronouns
in
the
doc
in
the
note
stock,
that
would
be
great
so
that
we
can
have
a
record
of
who
is
here
and
how
they
like
to
be
addressed.
A
Awesome
awesome,
first,
point
of
business:
I
guess
we
can
just
for
the
sake
of
the
recording,
do
are
super
lightning,
quick
round
of
intros
and
pretty
sure
we
all
know
each
other
from
the
sick
security
meeting.
But
wanting
to
keep
this
open
and
welcoming
after
that
I
think
the
most
important
thing
in
the
tips
that
I
got
from
Tabby
when
I
met
with
her
was
you
know,
taking
some
time
as
part
of
this
kickoff,
to
talk
about
how
we
should
work,
how
we
want
to
work?
A
What
makes
sense
what
things
we
think
we
can
do,
synchronously
and
asynchronously,
and
just
how
generally
to
make
the
best
use
of
our
time
given
sort
of
the
core
like
tasks
that
need
to
happen
to
do
this
self-assessment
and
then,
if
time
allows
I
have
started
an
Excalibur
doc
which
I'll
just
something.
Here
again,
oh
you
don't
have
that
access
to
the
docs.
A
Editor
help
you
link.
Let
me
try
this
again.
Try
that
link
Grace.
That
should
be
better
and
yeah.
Let's
we
can
just
start
sort
of
component
mapping,
but
before
we
do
that,
actually
we
should
confirm
with
you
Shang
what
is
the
main
workflow
that
we
want
to
map
I
know
in
the
past,
when
we've
chatted
that
you've
said
you
want
to
focus
on
the
vanilla,
kubernetes,
workflow,
so
I
think
I'll
just
add
that
to
the
agenda
making
sure
scope
appropriate.
A
And
then,
after
that,
we
can
start
building
the
data
flow
diagram
together,
which
would
of
course
be
based
on
the
architecture
diagram
that
is
in
the
documentation.
So
with
that
said,
are
there
any
other
points
that
folks
think
we
should
cover
today
before
we
get
started
or
anything
of
any
other
nature.
A
Great
nailed
it
okay,
so
yeah
I
guess:
let's
do
just
a
really
quick
round
of
intros
who
would
like
to
jump
in
first.
B
I
can
go
first
hi
folks,
I
am
Grace
I'm,
currently
working
doing
software
at
Expo,
I'm,
usually
on
the
release
team
been
doing
releases
for
the
past
two
years-ish
I'm
just
dabbling
a
little
bit
into
six
security
and
just
kind
of
hopping
in
to
see
where
I
can
help
out
awesome
thanks,
Grace.
C
I
guess
I'll
go.
This
is
Robert
fakalia
I'm,
co-chair
of
the
policy
work
group
in
communities.
I've
been
active
with
the
cncf
tag
for
a
number
of
years
since
2019
and
helped
switch
car
get
that
first
self-assessment
off
the
ground
way
back
when
asking
what
was
that
a
year
ago
now
for
Cappy
but
and
yeah
in
general,
performed
a
couple
of
Assessments
for
cncf
and
then
helped
Ray
and
Rory
on
the
kubernetes
third
party
audit
with
NCC
so
glad
to
be
here.
D
Okay,
I'll
go
next
Shane
I
work
at
a
VMware
I
work
on
the
vsphere
seaside
driver
I'm,
also
a
co-chair
in
kubernetes,
six
storage,
so
I,
but
I'm
new
to
the
security
related
thing.
I,
don't
think.
I
have
joined
your
six
or
six
security
meetings,
so
yeah
so
I'm
here
to
learn
this
process.
A
Awesome
and
yeah
that
leaves
me
so
I'm
Allah
I
also
work
at
VMware
and
thank
you
to
Shang
for
making
use
of
this
service
and
and
requesting
a
self-assessment
and
making
kubernetes
more
secure
by
virtue
of
expressing
this
intent
so
yeah.
This
is.
This
is
really
great.
A
I
yeah
I'm
super
excited
to
get
this
kicked
off
and
you
know
I
feel
like
my
role
here
is
really
to
you
know
to
to
be
a
judicious.
You
know
facilitator
and
guide
here.
A
You
know,
I
I
definitely
want
to,
you
know,
be
as
active
or
as
sort
of
not
passive,
but
you
know
just
be
as
active
as
it
makes
sense,
knowing
that
we
have
a
lot
of
expertise
here
as
well
all
right.
So
with
that,
let's
move
on
to
the
next
part
of
the
agenda,
which
is
you
know,
looking
at
and
I,
can
share
my
screen.
A
If
that's
useful,
although
it
looks
like
people
are
in
the
doc,
but
let
me
know
if,
if
I
can
jump
to
that,
so
just
given
you
know
the
the
things
that
we
need
to
do,
which
is
you
know,
I
think
we
can
bang
out
sort
of
selecting
the
workflow
that
we
wanted
throughout
model
in
this
meeting,
we're
going
to
need
to
build
a
data
flow
diagram.
A
If
folks
I
can
link
to
this
as
well.
I
want
to
see
an
example
of
that
pushker
recorded
all
of
his
previous
sessions
for
Cappy.
A
We've
gotta,
basically
write
up
the
results
of
of
building
those
data
flow
diagrams
and
the
following
the
stride
model
for
doing
threat
models.
You
know
capture
sort
of
what
we
think
could
go
wrong.
That
write-up
will
need
to
go
through
a
set
of
reviews.
A
We
should
write
a
blog
post
as
part
of
that
process
to
make
sure
that
you
know
the
community
knows
about
what
we're
up
to
and
what
we've
been
doing
and
then
potentially
submitting
a
coupe
contact
at
some
point
to
outline
so
yeah,
really,
you
know
in
terms
of
you
know,
the
workflow
selection
I
think
you
know
I
think
we
can
kind
of
do
that
today.
A
I
think
that's
a
good,
a
good
thing
for
us
to
take
off,
but
really
in
terms
of
the
data
flow
diagram
building
you
know,
that's
that's,
certainly
something
that
can
be
very
interactive
and
I
think
it
worked
really
well
for
Cappy
for
it
to
be
an
interactive.
A
You
know
exercise,
but
you
know
Shanghai.
You
know
you
know
the
system
better
than
anyone
else
and
I
can
imagine
that
as
we
get
going,
you
know
if
it
makes
more
sense
for
you
to
peel
off
and
and
do
a
chunk
of
it
like
I
could
also
see
an
asynchronous
approach.
Working
and
so
I
just
really
wanted
to
sort
of
open
it
up
to
the
group
about
what
we
think
kind
of
makes
sense
in
terms
of
how
we
want
to
handle
those
those
tasks.
A
And
yeah
I
don't
know
Robert.
If
you
know
you,
like
you,
said
you've
done
several
of
these,
including
the
the
Cappy
pilot.
At
this
point,
if
you
know
you
can
share
a
little
bit
about
what
you've
seen
work
in
terms
of
different
working
Styles,
but
also
just
in
terms
of
like
different
Target
flows,
and
you
know
kind
of
what
you've
seen
work
and
maybe
not
work
as
well.
C
A
C
Everybody
has
kind
of
a
shared
view
of
what
we're
going
to
be
looking
at
and
and
some
of
those
have
had,
you
know
very
defined
documentation
and
diagrams
and
whatnot,
but
just
making
sure
that
we
lay
out
on
the
table
what
does
exist
if
it,
if
nothing
exists,
then
great
and
we
we
baseline
from
there
I
think
in
in
the
Cappy
one,
particularly
it
very
quickly
moved
from
that
high
level
description
to
the
diagramming
exercise
and
that's
where
pushka
really
played
the
Scribe
and-
and
you
know
we
did
a
couple
of
interactive
sessions-
I
think
you've
seen
the
recordings
of
all
that
you
know
as
pushkar
would
call
out
various
lines
and
boxes
and
arrows
and
and
the
developers
would
would
correct
or
add
or
or
clarify
and
so
I.
C
You
know,
I
think
that
was
very
helpful
for
everybody
to
kind
of
really
move
from
the
you
know,
text
description
of
something
to
kind
of
more
of
a
dynamic
understanding
of
how
things
are
getting
in
and
out
of
the
interfaces
I
think
from
there.
It
was
more
the
developers
kind
of
thinking
through
finalizing
that
so
you
know
we
kind
of
came
away
with
a
straw.
C
Man
rough
rough
version
of
that,
if
you
will
boundary
and
data
flow
View
and
then
the
developers
I
think
tweaked
it
and
added
to
it,
but
I
I
couldn't
it
was
hard
to
see
what
was
happening
asynchronously
and
who
was
doing
what
I'm
sure
it's
captured
in
some
history
log
somewhere,
but
it
could
have
been
that
you
know
pushkar
and
the
developers
were
exchanging
notes
on
slack
and
then
pushcard
might
be
updating
the
diagram
or
he
may
have
just
handed
over
the
diagrams
the
developers
and
they
added
a
lot
of
detail.
C
But
I
do
recall
there
was
you
know
some
many
weeks
of
kind
of
asynchronous
work
to
clarify
all
that
and
then,
as
I
recall,
we
had
you
know
kind
of
a
final
session
just
to
make
sure
we
all
kind
of
walk
through
it.
Again.
We
all
understood
and
agreed
with
the
the
flows
and
the
threats
and
whatnot
so
I
guess
I
skipped
over
the
front
part.
The
threat
flat,
bottling
I,
don't
recall,
being
very
interactive.
C
I
think
that
was
more
going
through
the
diagrams
and
then
everybody
kind
of
asynchronously
adding
in
their
Definition
of
threats,
at
least
if,
if
it
wasn't
active,
it
wasn't
very
impactful
because
I'm
not
remembering
it.
C
That
was
kind
of
captured,
ad
hoc
during
the
diagramming
session
and
then
kind
of
footnoted
somewhere,
and
then
we
kind
of
broke
it
into
a
more
formal
threat
model.
After
that
and
it's
a
fiber
call
I
send
some
notes
to
pushkar
and
the
developers
and
the
pushkar
kind
of
Consolidated,
the
the
final
threat
model
into
I
think
a
matrix
or
maybe
it
was
an
outline.
I
can't
remember
it,
but
something
like
that
and
again
and
then
even
other
cncf
projects.
You
know
whether
it
was
oppa
or
Cloud
custodian
or
others.
C
It
kind
of
followed
a
similar
process.
We
did
that.
You
know
we
did
the
diagrams.
We
talked
through
the
the
flows
and
configurations
that
impact
the
the
data,
and
then
we
kind
of
all
ruminated
on
the
flat
model
and
added
that
to
the
Google
Docs
and
then
summarize
that
in
some
sort
of
sort
of
table-
and
then
someone
volunteered
usually
to
put
that
in
some
graphical
thought,
modeling
notation,
I,
I,
can't
remember
which
one
it
was.
C
C
Which,
if,
if
the
folks
here
or
others
supporting
this
are
amenable
to
I,
would
recommend
we
do
that
as
well,
especially
for
something
so
core.
As
this
driver,
you
know,
having
having
fuzzing
provided
by
cncf
I
think
would
be
a
phenomenal
support
and
we
did
find
several.
You
know
real
issues
in
doing
that
for
copy,
so
I
think
the
developers
found
that
to
be
high
value.
A
Yeah
and
I
think
that
that
that's
a
good
compliment
also
because
you
know
you
can
really
scope
a
fuzzing
effort
very
precisely
by
virtue
of
like
doing
this.
Pretty
detailed
diagramming
data
flow
exercise
as
well.
I
recall
from
the
Cappy
retro
that
they
listed
that
as
being
really
beneficial.
D
Hey
sorry,
since
I
security
turn,
so
what
does
the
Aussie
effort
do.
A
I
was
gonna
say
so.
Fuzzing
is
sort
of
like
it's
a
bit
like
penetration
testing.
Basically,
is
you
know
you
basically
hire
an
outside
firm
to
you
know,
basically
go
after
a
really
specific
part
of
the
application
and
see
what
they
can
exploit
and
it
can
be
really
time
consuming
because
you
know
getting
in
an
environment
set
up,
that's
accessible
to
that
team
and
getting
them
to
you
know
getting
them
to
be
familiar
enough
with
the
application
or
the
service
or
whatever
you
want
them
to
go.
A
After
that
you
know
they
can
actually
sort
of
do
like
meaningful
trickery,
so
to
speak,
but
yeah
Robert
I,
don't.
C
Yeah
and
I
typically
I
think
you
can
do
it
with
a
minimal
I
think
they
can
do
it
basically
like
a
unit
test
harness
so
essentially
the
fuzzer
will
instrument
the
source
code
and
we'll
you
know,
at
a
very
low
level,
try
to
find
boundary
conditions
in
the
code.
So
you
know
by
definition,
the
fuzzing
tool
chain
is
language
specific.
C
So
you
have
sea
fuzzers
and
you
have,
you
know,
go
fuzzers
and
you
have
you
know
in
other
languages.
You
know
python,
composers
and
things
so
so
they
understand
the
the
parse
tree
of
a
particular
language
and
and
then
some
of
them
work.
C
You
know,
probably
at
the
symbolic
level
you
know
in
the
compiled
code,
but
the
the
open
source
ones
probably
will
work
at
the
source
code
level
specifically
and
then
instrument
up
and
kind
of
annotate
the
code,
kind
of
kind
of
do
a
pseudo
compilation
and
then
generate
unit
tests
that
send
very
you
know,
Corner
case
values
to
any
kind
of
input
variable
to
the
function
right.
So
it's
very
much
a
white
box
testing
methodology.
It
will
call,
you
know,
function
by
function,
input
by
input
to
those
routines
and
then
pass
in.
C
A
C
Is
it's
trying
to
catch
some
sort
of
exception,
state
or
some
sort
of
fault
state
in
the
code?
That
would,
you
know,
cause
some
worst
case
with
you
know
some
sort
of
exploitable
or
data
leak
condition
right.
So
it's
just
kind
of
algorithmically,
we'll
just
brute
force,
all
the
input
variables
to
different
functions
with
some
heuristics
and
and
patterns
to
try
to
exploit
those
inputs
to
a
function,
but.
B
C
D
And
the
tests
are
pretty
much
automatic,
so
basically,
it's
that
there's
a
tool.
I
will
write
those
generated
those
unit
tests.
C
Okay,
yes,
I
think
the
the
effort
all
is
correct
that
the
effort
comes
in
and
kind
of
knowing
all
the
bells
and
whistles
the
winter
and
kind
of
giving
it
The.
Annotation,
hints
and
massaging
the
different
options.
I
mean
if
you've
ever
had
to
do
c,
compiler,
Flags
right,
it's
kind
of
a
similar
process.
There
are
all
sorts
of
bells
and
whistles
that
the
linters
can
can
use
to
try.
C
And
you
know,
and
in
its
simplest
case
of
course,
it's
just
going
to
crash
everything
and
the
the
art
versus
the
algorithm
is
trying
to
figure
out
what
type
of
Crash
is
exploitable
versus
something
that
would
just
terminate
the
program
right.
So
I
think
that's
where
the
the
the
outside
firm
that
cncf
has
contracted
with
they've
got
the
pattern,
recognition
the
knowledge
base
and,
in
their
expertise,
to
understand
the
types
of
The
Faults
that
the
the
pleasure
will
generate.
That
could
be
exploitable
and
then
work
with
the
development.
A
A
But
yeah
like
Robert
was
saying
yeah.
It's
definitely
as
as
part
of
this
effort.
We
can
totally
you
know,
reach
out
to
the
firm
whose
Name
Escapes
me
and
and
the
CNC
app
to
see,
if
there's
budget,
to
do
that,
as
as
part
of
this
exercise
and
yeah
I
know
that
the
Cappy
team
found
it
really
beneficial
and,
like
Robert
said
they
they
found
some.
A
You
know
they
saw.
They
found
some
pretty
meaningful
flaws
that
they
were
able
to
take
action
on.
So
just
something
for
us
to
consider
Ada
Logistics.
Yes,
thank
you
Grace
for
putting
out
the
notes,
alrighty,
okay,
so
yeah.
Just
given
that
you
know
it
seems
like
at
least
taking
the
interactive
approach
to
building
you
know
the
component
and
data
flow
diagram
map
I
think
we
can
probably
just
say
that
you
know
we'll
do
as
much
of
that
synchronously
as
possible.
I
know
for
Cappy.
A
It
definitely
seems
like
it
was
a
really
beneficial
information
Exchange
and
after
the
first
couple
of
sessions
of
Cappy,
you
know
they
started.
You
know.
Obviously
the
sessions
are
recorded
and
they
started
just
bulleting
out
sort
of
descriptions
of
you
know
when
a
user
does
this
or
you
know
bootstraps,
like
you,
know,
a
workload
cluster,
you
know
this.
You
know
this
service
or
this
component
is
instantiated
and
it
talks
to
this
other
component
and
it's
encrypted
or
it's
not
encrypted,
and
it
goes
through
this
port
and
the
suddenly
other
thing.
A
Yeah
so
I
think-
and
you
know
of
course,
like
any
approach
that
we
take
like
this-
is
it's
about
what
works
for
this
group.
So
if
we
find
that
hey,
you
know,
we
can
probably
bang
something
out
asynchronously,
but
we've
been
tackling
it
in
meeting
synchronously
like
that's
totally
fine
for
it
to
change
so
yeah
it's
about
whatever
works.
A
A
So
I
guess
so
Shang
would
you
and
it's
it's
totally
fine?
We
can.
We
can
do
this
another
time,
but
would
you
be
willing
to
just
kind
of
walk
through
a
high
level
of
the
documentation
and
just
describe
the
service
then
and
what
it
does.
D
B
B
B
D
D
Yes,
this
diagram
is
really
very
high
level,
but
maybe
let
me
explain
this
one
then
so
this
really
just
shows
this.
You
know
that
does
not
really
show
the
internals
of
the
of
the
plugins
actually
just
shows
us
the
plugin
here
this
top
one
vsphere
container
storage
plugin.
D
D
So
at
a
high
level.
That's
what
that
does,
but
this
one
just
unfortunately,
it
doesn't
really
show
the
diagram
of
this
particular
plugin
shows.
You
know
this:
the
vsphere
basically
Iranian
vsphere.
This
is
your
recenter.
This
shows
a
few
more
components.
Is
that
I'm
not
sure
when
we
do
this
analysis?
Do
we
also
go
lower
or
is
any
like
stays
at
this
level?
D
So
this
one
basically
says:
okay,
this
plugin
will
be
communicating
with
vsphere
through
vcenter
apis,
but
everything
you
see
everything
in
there
are
some
components
that
is
part
of
the
vsphere
right.
So
it's
just
showing
here
right
so
here
it
shows
the
this
is
a
Cloud
native
storage
control
plane,
but
this
is
part
of
a
vsphere.
D
Most
of
the
most
of
the
vco
course
from
the
VCS
is
a
driver
is
through
the
CNS
layer.
So
it's
so
it's
this
list
layer.
This
C
is
a
driver,
layer,
costs
CNS
apis,
basically
and
then
so
this
one
basically
the
FCD.
This
is
the
the
kind
of
the
block
of
volume
that
we
support
is
called
the
first
class
disk.
So
that's
what
this
one
is
in
this
spbm.
This
is
the
story
policy.
D
So
this
is
a
just
like
a
policy
engine.
The
services
shows
this
is
the
file
file
volumes,
so
we
support
FCD
or
blog
volumes
and
we
send
FS
that's
the
fireworks.
This
is
just
a
two
different
type
of
audience.
We
support
and
then
the
zombies
that
just
shows
the
compute
right.
So
the
the
those
are
the
ESX
and
then
here
this
shows
you
could
have
different
data
stores.
Different
data
stores
can
be,
you
know,
can
be
this
vmfs
FS,
vivos
or
vsan.
D
Those
are
those
can
be
blocked,
and
then
you
see
that
it
shows
block
volume,
one
two,
three,
four,
those
are
so
those
are
four
type.
All
four
type
of
of
data
stores
can
be
used
for
Block
volumes,
but
for
five
volumes
we
only
support
this
vsan
FS.
So
that's
why
this
one
is
it
just?
Unfortunately,
this
one
doesn't
have
more
details
about
like
how
different
components
in
kubernetes
communicate
with
this
I
can't
talk
about
that
I'm.
Just
thinking
do
I,
otherwise,
I'll
have
to
find
a
diagram.
A
To
answer
your
earlier
question
in
terms
of
like
what
we
want
to
cover
and
kind
of
like
how
would
how
deep
into
v-sphere
do
we
want
to
or
need
to
go?
You
know
in
terms
of
scoping
this
I,
you
know
it's
definitely
focusing
on.
You
know
on
the
driver
itself
and
I
think
we
can
document.
As
part
of
this,
you
know
what
are
the
you
know
calls
in
and
out
of
the
driver
to
and
from
vsphere
or
the
the
the
vcenter
apis
that
you
call
so
I
think
documenting.
A
That
is
totally
in
scope,
but
I,
don't
I,
don't
think
we
need
to
get
into
the
weeds
of
vsphere
under
the
hood
for
sure,
because
that
would
be
yeah.
C
Yeah
I
would
only
I
would
only
add
in
that,
so
I
would
agree
that
the
primary
boundaries,
the
API
okay,
I,
would
say
if
there's
I
think
we
should
probably
enumerate
you
know
any
critical
life
cycle
of
this
like.
How
does
it
get
loaded?
How
is
it,
how
might
it
be
unloaded,
you
know?
Are
there
other?
You
know,
type
of
you
know
scale
up
scale
to
any
anything.
That's
like
kind
of
a
life
cycle
of
the
module
itself.
C
You
know
what
policy
or
configuration
can
be
applied
that
may
impact
how
the
apis
work
or
don't,
and
you
know,
and
things
like
communicating
that
the
API
itself
is
there,
you
know,
is
there
TLS?
Is
there
encryption?
C
Is
there
authentication
right,
I
mean
things
I
mean,
probably
not
if
it's
you
know
just
being
called
by
the
API
server,
but
generally
speaking,
if
there's
any
kind
of
Integrity
checks
or
other
kind
of
configuration
that
needs
to
be
done
or
a
policy
that
needs
to
be
applied,
since
you
mentioned
policy,
so
I
think
those
peripheral
concerns
you.
D
Let
me
see
I,
don't
even
know,
there's
any
yeah.
Those
are
like
details
if
you're
talking
about
deployment
or
those
are
kind
of
like
the
details,
let's
see
I,
don't
know
if
this
sign,
maybe
too
much
yeah
too
much
details
on
this
is
there
a
deployment
diagram.
Is
that
that's
actually
better
right,
I,
don't
know
if
I
have
a
good
diagram
for
this?
Unfortunately,
I
was
didn't
really
yeah.
A
That's
okay
and
yeah,
it's
like
we
can.
You
know
if,
if
that
doesn't
exist,
like
that's
totally
within
scope,
you
know,
as
part
of
like
mapping
out,
you
know
the
data
flows
for,
like
you
know
how
do
you?
How
do
you
get
started
with
you
know
with
the
CSI
driver,
like
you
know,
you
have
a
user
like
what
do
they
do
like
what
you
know
and
just
mapping
out
that
whole
flow
for,
like
you
know,
basically,
bootstrapping
it
is,
is
totally
within
scope.
So
it's
okay.
If
you
haven't.
D
Yeah,
let
me
actually
I
actually
have
something:
okay,
yeah,
let's
see
this
one,
if
I
have
something
that
is
already
okay,
I
think
this
one
might
answer,
might
work
okay,
so
this
one
at
least
some
kubernetes
components.
So
let
me
stop
sharing
this
and
this
other
thing.
D
Okay,
so
oh
yeah,
this
one
at
least,
has
some
components.
You
can
see:
okay,
so
yeah.
So
here
right,
so
we
just
show
there's
a
kubernetes.
This
is
a
old
diagrams.
It's
a
kubernetes
control
plane
we
have
a
so
VCS
is
a
driver,
has
a
controller.
So
here
we
show
this
one
there's
a
controller
pod
running
on
those
control
planes.
D
Now,
in
this
part,
there
is
a
VCS.
Is
a
driver.
This
you
see,
the
driver
will
be
running
with
some
side
cars.
So
those
side,
cars
are
actually
those
are
from
kubernetes
Upstream.
This
is
a
kubernetes
storage
projects
like
those
sidecars
external
Provisions
external,
attach
all
of
those
so
and
then
so.
The
main
flow
is
when,
let's
say,
for
example,
if
a
user
want
to
provision
a
volume,
so
users
say
I
want
give
me
a
PVC
position.
D
Volume
claim,
and
that
requires
basically
first
will
be
processed
by
there-
is
an
entry
in
kubernetes
entry
in
queue.
Control,
imaginary,
is
a
PV
controller
that
will
do
some
processing
and
then
and
then
you
realize
that
this
actually
will
be
handled
by
a
Auto
3
CSI
driver,
so
this
actually
will
be
next.
Will
be
handled
by
the
external
provisioner,
this
is
a
sidecar.
D
This
one
will
be,
will
be
the
one
who
is
actually
calling
visual
CSI
driver
through
a
grpc
call,
so
there
was
a
there
is
I'm,
pretty
sure
show,
and
it
was
actually
another
diagram.
Let
me
go
through
this
one.
First,
you
want
to
know
you
know
further
how
this
sidecar
communication,
but
this
is
maybe
maybe
similar
in
other
kubernetes
projects
as
well.
This
is
the
grpc
call
and
so
and
then,
and
then,
when
CSI
driver
gets
this
great
warning
call
the
cset
driver
will
be
calling
the
the
Cs
control
plane.
D
That
I
was
talking
about
earlier.
That
you
know
that's.
This
is
a
part
of
vsphere,
so
I
know
this
is
this
line
is
actually
meaning
from
here
to
here,
yeah
yeah.
So
that's
how
the
how
a
creative
volume
call,
because
this
is
a
control
plane,
that's
how
this
one
works
at
high
level
and
then,
of
course
there
are.
You
know
many
other
other
operations
when
there's
a
creative
and
there's
a
attach
detach,
there's
a
mount
amount.
D
So
if
it's
attached
detached
there's
this
there's
a
attached
detached
controller
in
Cube
controller
manager,
so
that's
again:
first
it
goes
here
and
then
it
goes
to
this
external
attacher
side,
car
and
then
the
the
attached
external
attaches
side
card
will
be
calling
CSI
driver
for
attach
and
if
it's
a
month
I
say
your
pod
want
to
use
the
volume
Ray
it
it
first
attach
and
then
it
also
needs
to
mount
it.
So
that
will
be
this.
D
You
know
there
is
this
null
node
part
so
other
than
the
controller
partner
is
also
a
notepad.
This
notepad
there's
a
CSI
driver
component
and
there's
also
other
there's
also
other
side,
because
the
sidecar
is
this
gel
red
structurally,
because
this
is
a
CSI
Sita
driver
and
then
this
is
the
travel
registrar
site
car
that
is
running
together.
D
So
this
will
be
going
through.
The
you
know,
the
cubelet
will
be
will
be
will
be
calling
the
CSI
function
actually
in
this
case,
so
this
one
yeah
I
know
it's
not
clear
in
this
Diagon.
Actually
we
should.
We
have
another.
Upstream
has
a
diagram
that
shows
how
this
amount
happens.
This
is
actually
the
cubelet
we'll
be
calling
those
the
CSI
node
functions,
node,
node
stage,
node
node
publish
course
so
yeah.
So
that's
at
a
high
level.
It
works
like
this.
B
A
So
I
I,
don't
know
how
other
folks
feel
about
this,
but
I
feel,
like
you
know,
sort
of
the
crud
operations,
like
you
know,
create
a
volume
you
know
read,
update,
delete
or,
like
you
said,
mountain
and
remove.
That
seems
like
a
really
good
that
that
seems
like
it
would
be
something
that's
beneficial
to
do.
You
know
a
more
kind
of
like
flow-based
diagram
of.
C
D
We
should
oh
no
I'll
find
out,
yet
we
should
have
some
sequence
diagram,
I'll
check
out
and
see
yeah
I'll
I'll
need
to
find
those
right.
We
should
have
those.
So
if
you
want
to
go
through
those
secret
diagram,
that's
where
we'll
be
more
clear
right
from
those
two
years
and
the
others
or
the
all,
the
sequence
will
be
shown
there
or
more
clear
than
this
block
diagram.
Yeah.
A
Yeah,
although
this
is
really
helpful,
like
I,
could
see
this
as
like
an
input
in
the
final
DOC
for
like
here's,
the
whole
system,
you
know,
here's
kind
of
like
is
that
a
block
diagram
and
then
we
can
follow
it
with,
like
you
said
those
sequence
diagrams
with
you
know
we
can,
we
can
so
show
the
flows
for
like
when
you,
you
know,
instantiate
a
volume.
So
to
speak.
Like
here's,
you
know,
here's.
A
Here's
sort
of
the
like
you
said
here
is
the
chain
of
services
that
talk
to
each
other
and
call
each
other
and
here's.
You
know
the
type
of
data
they
share
and
here's
what's
encrypted
and
not
encrypted,
and
they
talk
to
each
other
on
these
ports
and
that
sort
of
thing
so.
D
D
I'm
thinking
so
probably
right,
so
all
the
CSI
apis
that
we
have
implemented
in
the
driver.
So
probably
we'll
just
look
at
all
of
those
yeah.
A
Pen
ran
out
of
ink,
but
yeah,
like
you,
said
yeah
just
looking
at,
like
you
said
all
the
apis
that
are
involved
in
those
workflows.
B
B
A
All
right
so
yeah
I
know
so
we
have
about
20
minutes
left
just
keeping
an
eye
on
time
in
terms
of
action
items
you
know,
I
don't
want
to
rush
us
into
anything
before
we've
had
you
know
just
more
time
to
sort
of
gather
some
information,
so
Shing
I,
guess
if
you
want
to
get
some
of
the
the
sequence
diagrams
like
you
said
together
and
then
you
know,
if
you
could
just
share
them
in
the
stock
channel,
we
could
take
time
to
review
them,
and
then
you
know
the
next
time
we
meet.
A
We
could
you
know
we
could
basically
build
the
data
flow
diagram
for
one
of
those
workflows.
D
Yeah
sure
so,
where
do
you
now,
you
want
me
to
put
those
in
some
Google
docs.
So
how
do
you
want
me
to
share
those
right
now,
it's
probably
scattered
on
our
internal
conference,
page
somewhere.
So
just
let's
how?
What
is
the
best
way
for
me
to
share
those?
Maybe
I
can
I
can
put
them.
A
Yeah
yeah
anyway
I'll
but
yeah
I.
Think
sharing
them
in
GitHub
makes
a
ton
of
sense,
which
is
great,
and
that
reminds
me.
Yeah
I
should
make
a
new
folder
for
the
vsphere
CSI
driver
in
our
GitHub.
A
So
we
can,
you
know
in
in
the
meantime,
if
you
just
want
to
drop
links
in
slack,
that's
fine,
but
we
can
make
sure
it
gets
into
GitHub
for
proper
process.
Sanitation.
B
A
Great
okay,
so
action
item
for
me
is
to
create
a
GitHub
folder
for
us
in
the
self-assessment
subfolder
of
six
security,
yeah
Shing.
A
If
you
want
to
share
those
sequence
diagrams
and
select
for
the
time
being-
and
we
have
kind
of,
we
will
of
course
put
them
in
GitHub
once
that
is
up
and
running,
and
then
we
can
asynchronously
decide
in
slack
just
once
we
have
the
sequence
diagrams
like
which
one
we
want
to
Target
for
our
next
meeting,
probably
like
setting
up
a
new
volume,
you
know
create,
read,
update,
delete
we'll
just
do
the
first
thing
create.
D
Yeah
I
may
not
get
everything
ready
in
my
shot,
because
I
was
thinking
even
the
create
one.
I
know
there
are
some
but
I
wonder
if
those
are
not
for
vanilla
classes
at
the
cluster
flavor.
So
but
it's
fine
just
if
you
can
tell
me
like
what,
when
will
be,
our
next
meeting
I
will
make
sure
I
got
those
get
those
ready,
yeah.
A
You
know,
probably
not
for
the
next
few
weeks,
so
not
like
or
anything
but
yeah
once
you
know,
I'll
definitely
want
to
take
a
look
at
the
sequence
diagrams
and
and
digest
them
to
make
sure
that
I
can
come
prepared
to
the
meeting,
and
you
know
then
we'll
just
I
don't
know
if
anyone
else
has
had
a
chance.
A
I'll
post
it
in
in
the
slack
Channel
too,
but
even
just
watching,
like
10
minutes
of
the
Cappy
videos
with
pushkar
and
the
way
he
drew
everything
out
and
the
way
that
him
and
nadir
were
talking
is
was
super.
Useful
I
actually
watched
three
of
them
about
three
hours
of
video.
So
far,
so
you
can
just
see
sort
of
what
the
process
is.
I
I
watched
it
at
like
one
and
a
half
speeds.
A
I
learned
a
lot
about
Kathy,
which
was
great,
but
even
just
a
few
minutes
to
see
kind
of
like
how
pushkar
kind
of
like
talked
through
everything
was
was
really
was
really
great.
So.
D
Yeah,
and
also
the
is
that
already
there,
the
the
cat,
you
said,
the
they're
meeting,
recording
that's
already.
Oh.
A
Yes,
so
the
meeting
recordings
I'll
put
I'll
put
it
in
the
slack
Channel
too.
It's
a
series.
B
A
Yeah
so
it's
like
you
know,
I
imagine,
Happy
meetings.
B
A
We
go
so
I
just
watched
it,
but
yeah.
If
you
I,
remember,
I
recommend,
starting
with
really
it's
the
first
or
second
one
just
watch
you
know
pick.
It
doesn't
really
even
matter
where
you
start
like
just
watch
like
a
10
minute
segment
and
you'll
see
just
how
they
kind
of
walk
through
everything
and
build
the
data
flow
diagram
together.
So.
B
A
Alrighty,
let
me
keep
myself
honest
and
look
at
the
agenda.
Oh
and
then
I
also
I
put
this
in
slack
too
I,
scrubbed
out
and
I
linked
to
and
scrubbed
out
the
template
for
the
final
write-up
that
pushed
her
and
and
the
team
did
and
I
also
linked
to
it
in
that
doc.
A
So
I'll
I
should
pin
those
pin
those
links
to
make
sure
we
have
them
on
hand
for
reference,
but
yeah.
So
you
can
just
kind
of
see
like
what
they
where
they
landed
and
what
they
did.
A
A
A
A
Very
good,
all
right
folks,
well
I
think
that
was
really
productive.
Thank
you.
Everyone!
So
much
for
your
time
and
yeah
Shang,
sorry
for
for
putting
you
on
the
spot
and
surprising
you
a
little
bit
but
yeah.
A
Getting
getting
our
information
together
and
just
deciding
kind
of
how
we
want
to
work.
I
think
is
a
productive
first
meeting,
so
awesome
awesome,
yeah
any
Grace,
Robert
anything
anything
else,
top
of
mind
that
that
you
want
to
share.
C
Well,
I
just
signed
myself
up
as
an
action
item.
I'll
go
back
and
review
I,
don't
think
anything.
Csi
really
came
up
in
our
most
recent
NCC
audit,
but
I'll
go
back
and
review
both
that
one
in
the
2021
report
and
there
were
some
Associated
threat
models,
I'll
just
kind
of
brief,
briefly
review.
If
there
are
anything
CSI
specific.
A
Oh,
that
would
be
awesome,
yeah
good
for
us
to
have
on
our
radar.
If
there's
anything,
awesome
well,
yeah
thanks
everyone
for
your
time,
yeah
excited
to
to
do
this.
Like
Robert,
like
you
said,
this
is
like
a
super
important
part
of
kubernetes
and
kubernetes
on
top
of
vsphere,
so
yay
making
kubernetes
paper
together
all
right
cool.
Well,
thanks
folks
and
yeah
I'll
share
a
doodle
Poll
for
us
to
to
gather
again
in
the
next
few
weeks.