►
From YouTube: Kubernetes SIG Security 20230309
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
A
Let's
officially
call
it
started
hello,
thank
you
all
for
coming
to
another
kubernetes
Sig
security,
I'm
Tabitha
I'm,
one
of
the
co-chairs
she
or
they
and
I-
am
really
proud
to
be
able
to
help
us
make
this
space
so
that
we
can
improve
kubernetes
security
together.
A
Anybody
else
want
to
jump
in
and
give
a
brief
introduction.
C
I'll
go:
my
name
is
Ray
I
work
for
Susa,
professionally
I'm,
the
sub-project
leader
owner
for
the
third
party,
security
audits
and
I'm
also
involved
in
several
other
six.
So
you
might
see
me
around
I'm.
Also,
the
co-chair
for
sick
docs
as
well
also
participate
in
Sig
release.
D
Intel
and
a
cloud
native
security
architect
yep,
that's
about
it.
D
E
Hey
folks,
my
name
is
Grace
I.
F
E
Go
to
school
in
Waterloo
I'm,
usually
in
sick
release.
Currently,
release
manager
associate
no
associate
signal
shadow
currently
also
helping
out
with
the
security
self-assessment
and
always
happy
to
join
the
sixth
security
meeting.
G
Hi,
my
name
is
Bill
Bernson
I
work
over
in
GK
security.
As
a
security
engineer,
yeah
I
was
happy
to
pop
in
and
ask
people
about
to
use
that.
B
B
A
C
Sure
so
the
third
party
security
audits
and
so
the
statuses
that
we're
targeting
for
the
press,
release
and
publication
by
keepcon
EU
the
there's
communication
involved
with
the
SRC
cncf
and
the
vendor
as
well.
So
we're
getting
red
we're
getting
ready
for
publication
shortly.
A
A
Well,
then,
I
will
read
out
from
docs
unless
there
is
someone
here
who
would
rather
talk
about.
What's
been
going
on
with
Docs.
A
Right,
the
first
update
from
docs
is
a
a
work
in
progress
to
on
the
page
describing
setcomp,
SE,
Linux
and
app
armor.
There
is
a
link
to
a
Google
doc
in
the
meeting
notes,
and
so,
if
those
are
topics
that
have
been
interesting
to
you
or
you
are
looking
for
a
place
where
you
can
make
a
contribution
by
reading
through
some
documentation
and
and
sharing
how
well
it
works
for
you,
then
please
hit
that
link
and
help
out
the
folks
who
are
driving
that
effort.
A
Other
update
from
docs
is
at
the
last
docs
meeting
folks,
went
together
through
new
contributor
opportunities,
so
documentation
updates
that
folks
would
love
to
see
made
and
that
feel
like
they
are
good
places
to
get
started
so
that
information
can
be
found
in
the
meeting
notes
from
the
Sig
security
docs
meeting,
which
is
linked
at
the
top
of
the
main
Sig
meeting
notes
and
I
will
prioritize
getting
that
video
uploaded
toward
the
end
of
the
toward
the
end
of
the
notes.
A
Okay,
next,
actually,
before
we
move
on
any
questions
about
what's
going
on
in
Docs,.
A
H
Yes,
yes,
yes,
so
last
week
we're
trying
to
merge
the
pr
on
the
new
Json,
the
specification
thing
and
it
finally
merged.
H
So
it's
done,
which
is
nice
but
like
it,
didn't
break
the
main
websites,
but
in
the
end
it
broke
some
some
people's
Fork,
because
because
the
the
website
is
relying
on
an
external
source
which
is
like
the
SD
bucket,
people
were
having
like
their
poke
like
Fork
Lottery,
based
on
Main
on
the
new
format
and
it
just
break.
They
are
completely
unrelated
PR,
which
is
unfortunate,
but
I.
Think
it's
okay.
So
so
this
thing
is
merged
and
I.
H
Think
the
next
step
is
the
emergency
RFS
speed
thing:
I
just
need
to
take
some
feedback
into
kind
of
like
I.
Just
need
to
finish
this
film
and
I
think
it
will
be
able
to
merge
before
before
the
cut
freeze
and
so
that
we
can
reduce
the
blog
and
everything
for
the
release.
So
yeah
that
that's
that's,
it
I
think
the
rest
I
don't
really
know
because
I
did
not
didn't
attend
the
class
meeting
where
they
did
like
a
presentation
about
what
I
think
by
David
David.
H
C
H
B
F
F
A
E
I
can
read
what
Ella
loved
here,
so
we
had
a
great
kickoff
meeting
for
the
piece
here.
Csi
driver
and
the
slack
Channel
thread
is
linked.
There
we're
still
scheduling
the
next
meeting,
there's
a
judo
out.
If
anyone
also
wants
to
participate,
it's
in
our
slack
Channel
and
we
currently
have
two
meetings
running
in
parallel.
One
is
for
self-assessment
by
weekly.
The
other
one
is
specifically
for
VCR
CSI
driver
assessment,
and
we
may
repurpose
it
the
general
meeting
to
do
vsphere
CSI
activities.
A
Yeah
I
think
that's
I,
think
that's
a
great
way
to
be
be
flexible
with
that,
like
the
purpose
of
a
meeting
is
to
do
things
together
and
so
use
use
everybody's
time
or
you
know,
make
space
for
everybody
to
use
their
time
actively
any
questions,
thoughts
or
further
comments
about
what
is
going
on
either
with
self-assessments
sub-project,
generally
or
vsphere
CSI
driver
in
specific.
A
All
right:
well,
then,
we
are
into
the
the
new
topics.
I
have
one
that
I
have
put
here,
which
is
a
couple
of
caps
that
folks
might
be
interested
in
or
want
to
have.
A
look
at
one
is
Cap
3857,
which
is
hardening
the
hardening
the
use
of
read-only
host
path
mounts
it's.
A
You
know
it's
an
it's
an
improvement.
There
is
a
link
to
the
there's,
a
link
to
the
cap
issue
there
and
I
think
it
I
think
it
looks
really
interesting,
but
I've
only
myself
had
a
chance
to
skim
it
so
far,
and
so
I
wanted
to
also
call
it
to
the
attention
of
the
rest
of
the
group
in
case.
That
is
something
that
folks
feel
away
about
or
want
to
be
able
to
contribute
to.
A
The
other
one
that
I
have
called
out
here
kind
of
kind
of
kind
of
putting
your
toes
into
this
one.
How
is
it
going
with
removing
security
context?
Deny.
H
H
We
don't
want
to
add
warnings
for
people
creating
posts
under
like
an
API
server
that
is
running
this
specific
plugin,
because
the
targets
like
targeting
the
user
would
not
be
like
appropriate.
So
these
things
cleared,
but
they
want
to
like
on
next
version
in
order
for
people
to
actually
get
like
to
know
that
this
thing
is
going
to
be
deprecated
because
they
are
not
going
to
read
the
logs.
We
want
to
put
that
like
behind
the
future
gate,
because
this
thing
is
in
Alpha.
H
It
was
created
before
feature
Gates,
but
we
can
just
put
it
in
like
behind
the
future
gate
right
now
for
the
next
version,
so
that
people
actually
realize
it's
been
disabled
by
default.
If,
if
somebody
is
using
this
thing,
so
I
I
need
to
write
this
thing
like
I.
Never
never
did
that,
but
I
never
tried
to
write
something
like
that,
but
I
guess
it
might
not
be
that
complicated.
So.
A
I
hope
that
it
I
hope
that
it
won't
be
to
to
make
sure
that
I
understand
the
status
of
this.
The
plan
that
that
you
and
Sig
off
came
up
with
together
is
to
take
the
feature
and
hide
it
behind
a
feature
gate
and
in
the
next
release.
Have
that
feature
gate
be
on
by
default,
so
that
the
behavior
is
unchanged
and.
H
I
think
your
ID
was
much
more
like
nice
to
people,
maybe
but
I
think
it's
what
they
said
like.
Let
me
we
should
add
an
alpha
feature:
gate
removed.
H
Yeah
I
think
that's
what
they
means
are
they
didn't
write
it
down
so
well,
I
think
we'll
see
when
I
write
the
code
for
the
future
again
yeah.
A
There
will
be
plenty
of
time
there
will
be
plenty
of
time
to
criticize
the
implementation
after
after
some
of
the
code
is
written,
that
that
makes
sense
well,
thank
you.
So
much
for
your
continued
follow-up
with
that,
and
you
know,
I
I
look
forward
to
seeing
it
go
away
in
whatever
method
is
determined
by
the
community
to
be
the
best.
H
A
Administrative
note,
the
next
thing
is,
is
also
something
that
I
put
on
here.
Just
an
administrative
note.
A
There
is
a
backlog
of
uploading,
the
meeting
recordings,
and
that
is
a
thing
of
which
I
am
aware
and
I
will
be
prioritizing
the
the
most
recent
docs
meeting
and
the
most
recent
tooling
meetings
that
have
been
the
learning
sessions
and
then,
after
after
those
then
plowing
through
the
remaining
recordings
in
order
in
order
to
get
caught
up.
If
there
is
any
particular
meeting
that
is
of
interest
to
anyone,
DM
me
on
slack,
so
that
I
can
at
least
have
a
chance
to
take
those
preferences
into
account.
A
We
have
now
reached
the
end
of
what
is
written
on
the
agenda,
and
so
this
is
the
place
where
I
remind
all
of
us
that
this
is
a
space
that
we
make
for
ourselves
in
time.
In
order
to
do
the
things
that
we
do
together
to
improve
kubernetes
security.
So
does
anyone
have
any
new
topics
that
they
wish
to
discuss
with
the
group.
H
D
So
Tabitha
I
wanted
to
the
whole
group
I
wanted
to
share
with
you
all
a
little
bit
about
confidential
containers,
the
flavors
of
them
and
then
some
thoughts
I
had
that
we
could
translate
or
mutate
or
whatever
word
we
like
to
the
rest
of
kubernetes
just
to
get
people
thinking
about
it.
So
I
have
like
three
slides
on
that.
Whenever
there's
time.
A
H
Yeah
she
wants
to
be
quick.
I
just
wanted
to
I
saw
these
tweets
by
cncf
tech
security,
and
since
we
talked
about
like
the
the
security
that
they
want
to
do,
a
next
group
call
I
think
at
the
moment
they
are
searching
from
committee
members
and
cfp
reviewers
for
like
the
organization.
So
if
you
want
to
participate
to
this
thing,
just
wanted
to
to
share
it
with
you
or
if
you
want
to
submit
something
for
the
next
event.
That's
it.
A
Thank
you
for
bringing
that
to
to
folks's
attention,
given
given
your
desire
to
allow
other
folks
the
floor
before
you
show
us
what
you've
brought
molini
I'll
ask
anyone
else.
Would
you
like
to
go
before.
G
A
quick
reminder:
if
you
have
a
chance
check
out
the
cvso
stock
leave
comments,
have
a
read:
I
didn't
get
a
chance
to
do
some
updates
on
the
worked
examples
of
the
different
proposals,
but
yeah
always
still
looking
for
more
feedback.
So
thanks,
everyone.
A
D
D
D
So
what
are
the
flavors
of
confidential
compute?
Okay
I
mean
confidential
computers
about
protecting
data
in
use.
We've
always
had
protecting
data.
You
know
at
rest,
that's
the
self-encrypted
drives
encrypted
data
on
this
etc,
etc.
Then
you
know
we
it's
a
ubiquitous
if
we
use
https
and
TLS
these
days,
but
when
we're
like
protecting
data
and
use
what
it
means
is,
as
it
enters
the
hardware
platform
on
the
processor
it's
secure.
So
that's
part
of
your
trusted
compute
base,
but
outside
of
that
any
other
process
like
a
root
process.
Another
neighbor
process.
D
They
can't
peek
into
your
code.
They
can't
peek
into
your
data
for
all
practical
purposes
is
encrypted,
but
this
is
provided
through
Hardware,
okay,
so
one
of
the
modes
of
using
this
for
kubernetes
level
is
a
cluster
of
confidential
VM
nodes
and
today
I'm
just
talking
about
confidential
VMS
and
we
have
AMD
having
their
SUV
and
SUV
es.
Suv
SNMP
Etc
arm
is
bringing
something
out
called
CCA.
Then
there
is
a
risk.
5,
bringing
something
out
and
Intel
has
its
TDX
trusted
execution
environments.
D
So
one
way
is
we
could
make
a
kubernetes
cluster
with
all
confidential
VMS
so
that
any
other
user
of
the
infrastructure
the
same
bare
metal
node.
If
there
are
other
workloads
running
on
it
other
clusters
on
it,
they
can't
peek
into
your
cluster,
so
the
boundary
for
security
is
your
whole
cluster
made
of
your
kubernetes
nodes,
which
are
each
of
them
a
confidential,
VM
node.
So
in
this
space,
there's
a
startup
called
edgeless
and
their
solution
is
called
constellation.
D
In
this
scenario,
your
API
server
hcd
demon,
sets
they're
all
part
of
your
trusted
compute
base.
So
it's
just
this.
As
far
as
you're
concerned,
it's
a
kubernetes
cluster.
You
use
it
no
different
from
any
other
kubernetes
cluster
of
yours,
but
under
the
covers,
it's
protected
you
from
other
users
of
this.
You
know
infrastructure
the
bare
metal
another
way
of
going
about.
This
is
a
cluster
of
bare
metal
nodes
where
each
of
them
is
a
hardware
te.
Now
this
is
a
little
expensive
whenever
we
think
of
kubernetes
and
even
ask
people
to
train
on
kubernetes.
D
We
offer
them
a
kubernetes
cluster,
so
giving
folks
a
cluster
of
bare
metal
nodes
is
just
super
expensive,
not
feasible,
but
that's
one
approach
and
in
this
approach,
what
you
do
is
you
can
use
an
existing
project
called
Kata.
It's
been
there
for
more
than
six
years.
What
it
does
is
it
launches
on
the
Fly
of
VM.
In
the
past
it
used
to
be
a
classic
VM
around
your
thought,
and
why
do
they
do
that?
D
D
Now
a
little
more
forward
we
have
Coco
Coco
is
This
Confidential
containers
open
source
project,
that's
built
on
top
of
Kata.
What
it
does
is.
It
still
requires
you
to
have
bare
metal
nodes.
Hardware
te
notes
the
difference
now
is
it
says:
okay
I'm
going
to
launch
for
you
a
on
the
Fly
confidential
VM
drop
your
pod
inside
it
and
then
lo
and
behold
you
have
your
confidential
pod,
but
there's
a
little
more
difference.
D
It
hardens
things
a
little
further
how
the
image
for
your
pod
is
downloaded
inside
that
Enclave
inside
that
trusted
execution
environment
that
confidential
VM
of
yours.
So
there's
some
pros
and
cons
of
that
and
before
you
even
do
all
this,
you
essentially
can
add
test
that
confidential
VM.
It's
like
an
empty
vessel.
At
that
point,
you
say:
hey!
Are
you
clean?
Are
you
good?
Are
you
you
know
whatever
and
after
that
one
you
say:
okay,
I
have
vetted
this.
This
is
measured
to
be
what
I
expect.
D
This
is
this
good
little
buddy
of
mine
that
can
now
download
my
image
and
do
the
rest
of
the
stuff?
Okay,
but
there's
still
a
problem
here,
because
we're
talking
about
bare
metal
hardware,
te
nodes,
it's
still
very
expensive,
same
problem
as
before,
but
it's
a
little
more
secure
because
the
kubernetes
pieces
are
outside
the
trust
boundary,
especially
once
you
measure
it.
D
You
know
part
this
is
built
on
top
of
Coco,
so
it's
still
confidential
and
then
the
idea
is
it's
like
a
pure
part,
even
though
your
cluster
is
made
of
VM
nodes,
you're,
not
creating
a
VM
inside
a
VM,
because
most
of
these
te
environments
do
not
support
nested
virtualization,
so
you
basically
put
it
on
the
side
of
you
or
somewhere
in
in
your
ether
of
bare
metal
nodes.
It's
like
a
cluster
API
kind
of
concept.
D
Okay,
so
now
this
is
how
today,
at
a
very
high
level,
the
cocoa
project
architecture
looks
like
it's
supporting,
though
I
just
spoke
about
confidential
VMS.
It
supports
two
pads.
You
can
have
process
based
isolation
or
you
can
go
this
VM
path
and
I
don't
want
to
go
about
the
process
based
isolation,
but
what
I
want
to
point
out
is
typically,
you
have
your
API
server.
It
contacts
the
cubelet
cubelet
contacts
container
D
talks
to
an
image
provider
for
you.
D
You
know
over
here.
It's
your
confidential
VM
allows
This
Confidential
VM
to
be
measured.
That's
this
whole
bit
about
attestation
key
broker
service.
Everything
says
good
to
go.
It's
a
some
expected
signature
value
and
then
inside
this
is
this
image.
Management
Service,
not
using
an
external
one,
and
at
this
point
what
happens
is
it
says?
Okay,
everything
good
to
go?
What
is
the
secret
key?
You
want
so
in
Coco
they
even
encrypt
these
images
and
then
now
you
get
the
key
decrypted
launch
it,
okay,
but
we
don't
really
stop
there.
D
Apart
from
doing
this
attestation
of
this
VM
here,
you
know
downloading
the
image
itself
here.
After
checking
for
this,
it
also
aims
to
do
a
few
more
things.
Once
you
go
through
this
path,
it
locks
down
the
cube,
cuddle
admin,
access.
Okay,
you
can't
exec
into
your
container.
You
can't
look
at
logs
in
that
container.
D
You
can't
look
at
you
know,
get
in
there
and
do
any
debug,
so
it
keeps
that
cluster
admin
out
of
your
trusted
compute
base,
and
we
already
have
from
the
hardware
capabilities
protection
from
other
processes
from
other
users
of
your
infrastructure.
Another
piece
that
it
aims
to
do
is
why
should
I
one
sec
trusted
this
API
service?
Actually
sending
me
the
things
that
I
specified
I
mean,
maybe
I
said,
use
database
food.
It
goes
to
database
bar
instead
because
those
may
be
a
parameters
that
you're
sending
in
so
do.
D
I
trust
this
do
I
trust
in
the
communication
from
the
cubelet
to
contain.
Nt,
do
I
trust
the
image
itself,
and
that
was
where
all
this
downloaded.
The
image
here
happened-
and
there
is
a
consequence
to
your
downloading
the
image
inside
This
Confidential
VM
separate
from
other
users,
You've
Lost,
Your,
sharing
efficiency,
okay
and
it
stops
at
one
bit
today
and
what
is
that
bit
that
it
measured
only
that
empty
vessel
before
you
put
in
your
pod,
a
higher
level
of
identity
would
be
to
measure
the
actual
pod
itself.
Okay
and
that's
a
little
complex.
D
D
Okay,
so
from
this
discussion,
what
can
we
take
away
to
regular
kubernetes?
Why
is
all
this
sort
of
hardening
that
we
talked
about?
Yes,
it
came
up
in
the
confidential
context,
but
is
there
something
we
might
want
to
bring
up
to
the
rest
of
kubernetes?
One
is
that
cluster
setup
we
have
VM
nodes,
nothing
there.
That
says
that
we
should
only
measure
the
VM
nodes
for
confidential
VMS.
D
We
could
measure
it
for
all
VM
nodes
so
that,
as
a
prop
announces
the
software
supply
chain
as
a
infrastructure
supply
chain,
we
can
say:
hey
these
VM
nodes,
that
your
kubernetes
cluster
were
made
from
kubernetes
1.24,
and
it
had
Ubuntu
image
this
that
so,
like
a
software
supply
chain
security,
we
have.
We
have
now
infrastructure
with
its
software
full
supply
chain
for
your
execution.
D
D
We
measure
this
input
Arguments
for
this
or
whether
it's
you
know
the
docker
compose
file
or
the
helm
chart
that
we
should
measure
to
inside
our
actual
VM
image
body
image
some
measurement
there,
and
we
should
also
have
some
audit
log
saying
what
would
those
incoming
parameters
and
I
think
this
is
generic
that
we
can
use
for
all
of
kubernetes
and
then
the
image
handling?
Right
now
we
say
we
do
image
handling
at
the
cluster
level.
D
This
isn't
regular
kubernetes
inside
This,
Confidential
one
they
went
over
paranoid
said.
Let
me
do
it
inside
that
Enclave
that
I'm
going
to
actually
be
using
for
my
own
work,
but
what
if
we
could
just
have
the
image
service
in
its
own
Enclave?
So
if
you
had
something
confidential,
there
I
mean
encrypted
confidential
in
that
sense
that
it
stays
inside
things
and
nobody
else
can
peek
in,
except
maybe
somebody
who
has
access
to
the
key
and
brings
in
that
key.
D
But
another
thing
that
tees
give:
you
is
integrity
protection,
so
nobody
can
go
behind
the
scenes
and
change
some
bits
in
your
actual
image
and
we
can
still
have
some
sharing
then,
but
this
is
a
image
service
running
in
a
tee,
and
by
that
token,
why
stop
it
image
handling?
We
can
protect
the
Integrity
of
your
hcd
of
your
API
server
Etc,
so
I'm
thinking
tees
will
serve
a
purpose
even
for
the
infrastructure
aspects
of
your
kubernetes
cluster,
protect
you
from
those
end
users
type
of
thing,
then
the
Pod
measurement
that
I
mentioned.
D
This
is
still
like
a
very
open
space.
How
do
we
want
to
measure
it
and
there'll
be
the
pause
part?
The
the
init
part
then,
maybe
due
to
some
kind
of
timing.
If
your
part
has
multiple
containers,
body
I
mean
containing
container
B,
you
can't
really
hash
them,
because
the
measurements
will
then
change
because
of
some
timing
thing.
If
container
a
got,
you
know
initiated
first
and
then
B
type
of
thing.
D
So
maybe
we
want
to
keep
each
of
those
container
measurements
separate
so
I'm,
just
thinking
in
my
head,
something
like
vtpms
but
a
linked
list
of
vtpms,
and
then
each
of
these
individual
entities
in
this
linked
list
are
the
measurements
for
that
individual
container,
its
launch
parameters
and
the
actual
measurement
of
the
image
type
of
stuff.
So
that's
where
I'm
thinking
in
this
space,
and
where
else
will
this
service,
it
will
give
us
a
stronger
identity
as
we're
talking
about
spiffy
and
Spire.
D
If
these
measurements
can
be
part
like
a
spiral
extension
and
where
I'm
thinking
in
this
space
is
you
have
this
awesome
data
financial
data
that
you
want
to
Crunch
or
this
Healthcare
data
of
you
know
heart
disease
or
cancer
or
whatever
it's
valuable?
It's
personal
information.
It's
collected
over
years
across
millions
of
people
before
you
hand
it
over
to
somebody
to
use
whether
to
build
a
machine
learning
model
or
to
analyze
it
and
say
so.
Many
people
have
heart
attacks:
hey.
We
should
invest
in
more
research
in
this
space.
D
You
want
to
establish
three
things:
who
is
it?
Is
it
malni,
this
researcher
or
malni,
the
Rogue
researcher,
so
that
sort
of
identity,
where's
malni
executing
this?
Is
she
doing
it
in
a
Enclave,
or
is
she
doing
it
in
some
public
coffee
shop
with
somebody?
You
know,
look
over
her
shoulder
and
copy
all
this
important
data.
And
last
but
not
least,
how
is
she
processing
and
is
she
doing
it
at
the
tensorflow?
D
You
know
learning
something
something
or
is
she
doing
it
like
rope,
tensorflow
learning
where
the
First
Act
I
do
is
like
take
that
data
and
then
make
a
copy
in
some
private
repo
database,
so
I
can
sell
it
later
type
of
thing.
So
this
sort
of
thing
about
the
container
image
is
like
how
am
I
processing
then
the
who
is
me,
maybe
some
identity
with
my
keyword,
password
whatever
two
Factor
authentication
and
the
where
is
like
in
an
enclave.
D
A
Thank
you
for
sharing
I,
think
that
I
think
there's
a
lot
of
I.
Think
there's
a
lot
of
complexity
in
there.
I
think
there's
a
lot
of
of
careful
thought
that
various
folks
have
put
into
the
designs
of
these
different
kinds
of
solutions
and
yeah.
I
hope
that
I
hope
that
folks
will
find
that
to
be
interesting
and
inspiring
for
places
where
we
may
be
able
to
do
more
in
ordinary
kubernetes.
D
Yeah,
like
that
ability
to
lock
down
exact
debug
I
mean
in
production.
Yes,
why
not-
and
maybe
I
have
some
key
another
thought
I
had
in
that
space
is.
If
I
am
the
launcher
of
this
workload.
I
have
my
private
public
key
pair
I
have
my
certificate
if
I
send
that
in
and
then
maybe
return
a
password
access
to
this
even
download
my
SSH
key
into
this
container
only
I
can
then
exec
into
it.
A
That's
it,
then,
we
have
accomplished
what
we
set
out
to
accomplish
together
this
time.
Thank
you
all
so
much
for
coming,
look
forward
to
seeing
folks
again
soon
and
reminder
that
until
then
the
Channel
6
Security
on
kubernetes
slack
is
open,
24
7
and
is
also
a
great
place
to
bring
things
to
the
attention
of
the
community
and
find
folks
to
work
on
things
together.
Well
goodbye
everyone
thank.