►
From YouTube: Kubernetes SIG Windows 20200804
Description
Kubernetes SIG Windows 20200804
A
A
A
This
windows,
server,
containers,
vulnerability
or
they've
talked
about
it.
So
I
can
give
a
quick
update
here
and
then
I'm
you
know
happy
to
talk
more
about
this.
So
basically,
this
article
talks
about
what
have
been
extensively
published
already,
that
the
process,
isolated
containers
in
windows
should
not
be
considered
a
security
boundary.
If
it's
an
os
isolation
boundary
it
is
a
silo,
but
it
is
not
considered.
We
do
not
consider
it
a
security
boundary,
it's
pretty
similar
to
what
linux
does.
A
Although
you
know
in
the
implementation,
things
are
a
little
bit
different.
So
in
terms
of
that,
this
is
a
known
issue.
However,
there
was
an
additional
issue
which
was
causing
the
container
escape.
The
issue
was
basically
it
talks
about
the
global
sibling.
So,
basically,
when
when
in
windows,
we
create
a
container
name
space,
we
create
some
what
we
call
a
global
sim
link.
A
We
we
may
create
those
so
that
the
host
could
talk
to
the
container
name
space,
these
global
name.
These
global
sim
links,
basically,
which
are
symbolic
links
they
could
cause
escape
if
you
are
within
the
container.
So
because,
since
we
know
those
global
sim
links
should
only
be
used
by
host
to
create
the
medium
space
and
talk
to
the
container
we
are
going
to
we,
we
we
block
the
access
from
the
other
way
around.
A
But
besides
that
again
the
instance
stays
the
same.
The
argon
is
not
are
not
considered.
Sorry,
the
process
containers
are
not
considered
the
security
boundary.
If
you
want
a
secure
container.
Hyper-V
is
the
route
to
go
and
with
container
d
work
that
we've
been
doing
hyper
v,
we're
hoping
will
soon
become
a
reality.
C
A
No,
so
what
19
is?
Basically,
we
went
beta
with
container
d,
but
the
two
things
that
are
not
that
are
known
and
not
to
be
working
with
119,
even
we
went
with
beta,
are
hyper-v
containers
and
gmsa.
So
those
are
the
two
things
we
want
to
get
in
120
for
it
to
go.
Ga,
so
that's
how
at
least
michael
michael
and
I
are
looking
at
it.
James
craig
feel
free
to
to
chime
in.
A
But
peter
to
your
point,
the
the
the
the
hyper-v
isolation
is
like
basically
from
a
continuity
perspective
is
the
next
major
milestone.
The
gmsa
issue
is
known,
is
being
backported
from
an
os
layer,
so
the
hyper-v
work
is
the
only
work
that
needs
to
be
done
on
a
container
inside
and
if
there
is
any
work
needed
on
the
on
the
kubernetes
side,.
B
From
from
the
testing
side,
I
just
dropped
in
the
links
for
the
hyper-v
that
we
have
running.
We
recently
made
a
change
to
the
previous
package
that
made
a
lot
of
the
tests
pass.
I
think
the
though
there
was
a
issue
with
the
way
that
folders
were
being
mounted
that's
been
added.
The
windows
volume
mount
check
is
a
issue
in
container
d
for
hyperview,
currently
right
now,
what
it
does
is.
B
It
has
a
there's,
two
pods
that
get
launched
in
this
one,
and
the
second
pod
should
have
different
permissions
in
the
first
one,
but
the
hyper-v
container
d
code
is
reading
the
permissions
from
the
first
pod,
and
so
we
should
have
a
package
fixed
for
that
pretty
soon
and
then
the
other
one
is
the
gmsa,
which
is
a
is
a
known
bug
that
I
think,
needs
to
be
fixed
in
the
platform.
As
far
as
I
know
where
there
must.
A
A
A
Correct
yeah,
that's
a
very
good
point.
That's
the
same
yeah!
That's
exactly
the
same
as
linux
and
yeah
the
process.
Lid
containers
are,
as
the
name
says
right
it's
just
the
process
is
isolated
and-
and
there
are
many
ways
that
you
know
they
will
continue
to
come
up
where
escapes
are
possible
for
both
linux
and
windows.
D
E
B
The
aks
side
of
things
we
have
docs
that
say
you
should
not
run
hostile
workloads
in
in
aks,
because
the
process
isolated
is
not
I'm
not
as
familiar
with
eks
but
yeah,
and
I
I
know,
there's
there's
actually
some
pretty
big
conversations
around
hostile
workloads
in
linux.
I
think
jess
frazelle
had
a
really
good
article
a
year
ago
about
why
why
you
shouldn't
run
multi-tenanted
workloads
on
kubernetes,
and
so
I
mean
if
you
want,
I
can
maybe
see
if
I
can
dig
up
a
couple
of
those
links.
A
E
Nothing
much
there's
been
pretty
good
progress
on
the
csi
proxy
side.
One
of
kalia's
major
enhancements
that
brings
in
go
bindings
into
the
csi
proxy
layer
is
now
merged,
and
so
that,
I
think,
is
a
pretty
neat
milestone
for
beta.
So
this
allows
the
proxy
to
not
always
have
to
go
through
powershell
commandlets,
but
straight
up
call
win32i
optionals
directly.
D
A
Awesome.
Okay,
I
guess
let
me
just
put
the
for
untrusted
code.
G5000
gcp
should
be
used.
Okay,
so
thank
you
for
that.
I'm
just
gonna
put
it
right
here.
Links
and
one
last
update
is,
I
think
we
talked
about
it
last
time
about
the
backlog
of
planning
the
backlog
review
meeting
bi-weekly
that
we,
the
group,
decided
on
the
community,
decided
and
voted
on,
and
the
time
I
believe
is
thursday.
I
believe
it's
thursday
9
30
to
10.
A
A
I
wanted
to
like
use
that
time
to
kind
of
feel
more
systematic
for
planning
the
planning,
the
120
release
so
kind
of
start
with
when,
during
the
backlog
meeting,
we
want
to
go
through
the
big
items
that
are
any
enhancement
like
we
talked
about
hyper-v.
Is
there
any
other
thing?
We
want
to
focus
on
as
a
community
and
then
what
are
the
small
items
that
accrue
to
those
and
kind
of
put
them
in
the
backlog
clean
it
up
a
little
bit.
A
A
Yeah
I'm
looking
forward
to
it
as
well,
so
deep
or
ireland
or
all
the
other
full
speaker
jing.
We
are
basically
looking
at,
of
course,
making
continuity
to
the
you
know.
Taking
the
next
level
so
testing
the
gmsa
hyper-v.
Is
there
anything
on
top
of
your
mind
for
120
that
you
wanna
you,
you
can
think
of
right
now.
D
Yeah
nothing
off
the
top
of
my
head.
Our
main
focus
is
going
to
be
getting
on
to
container
continuity,
got
it
we're
hoping
just
like
how
we
have
windows,
machines
or
windows,
vm
or
windows,
images
with
with
the
docker
runtime
pre-installed
on
most
of
these
clouds,
we're
hoping
like
there
will
be
continuity
releases
also.