►
From YouTube: Kubernetes WG IoT Edge 20190410
Description
April 4 2019 meeting of the Kubernetes IoT Edge Working Group -discussion of draft of an edge security white paper
A
Record
hope:
that's
okay
with
everyone,
so
I
I
must
start
by
saying
that
I'm
I'm
thrilled
that
we
have
a
good
turnout
turnout
in
the
apec
time
this
time.
For
the
first
time
I
think
so.
I
was
starting
to
lose
hope
that
we
will
get
things
going
in
this
term,
but
this
is
good
so
for
today
on
the
agenda,
we
have
only
going
to
the
security
white
paper
that
kilton
altered.
C
D
A
Yes,
so
it's
not!
This
is
not
a
sick.
This
is
a
working
group
which,
like
spans,
multiple
topics,
while
the
the
seek
is
more
related
to
the
single
single
purpose
topic
for
the
kubernetes
yeah
and-
and
this
is
like
a
working
group
trying
to
cover
all
the
areas
related
to
iot
and
edge
computing
in
the
context
of
of
kubernetes
so
trying
to
together
resources.
Use
cases,
provide
some
white
papers,
best
practices
just
share
the
knowledge
and
and
try
try
to
see
where
we
can
improve
the
whole
experience.
D
Okay,
okay,
thank
you
and
the
the
things
why
I'm
enjoying
this
and
interesting.
It
is
because
we
are
working
for
us.
We
are
looking
for
a
solution
and
I'm
not
sure
whether
the
lth
will
be
a
solution
for
us.
The
scenario
we
want
to
have
is
we
have
we
implement
a
solution
and
we
have
a
client
and
we
have
server.
D
The
client
has
been
installed
in
the
indifferent
of
the
device
and
we
we
are
hoping
to
have
a
mechanism
to
check
whether
the
clients,
where
deploy
a
new
version
and
other
clients
can
be
updated
automatically.
So
I'm
not
sure
whether
this
is
one
of
the
company's
iot
age
can
support
him.
For
this
kind
of
scenario,.
A
E
F
E
Us
not
just
new
people
should
introduce
ourselves,
because
there
aren't
that
many
and
that
way
the
the
new
people
know.
Who
else
is
here?
So
I
I
guess
I'll
go.
I'm
steve
wong,
an
engineer
with
vmware,
based
in
los
angeles
and
vmware,
has
some
things
going
on
in
the
edge
in
iot
space
and
a
lot
of
things
going
on
in
kubernetes,
and
I'm
just
interested
in
keeping
up
with.
What's
going
on
in
this
space.
F
Themselves,
well,
this
is
brand
speaking,
I'm
also
from
hp,
and
I
want
to
learn
more
from
you
guys
in
this
group,
and
I
want
to
also
I'm
passionate
on
the
iot
and
and
edge
computing
and
also
thank
you
steven.
I
just
had
a
talk
with
cindy
and
she
mentioned
that
on
the
proposal
of
how
to
update
the
software
from
from
from
kubernetes
from
edge
computing
and
cinemation,
the
cube
age
might
help.
Thank
you.
C
G
H
Yeah
then
I'll
introduce
myself.
My
name
is
bernhard,
I'm
particular
working
as
a
data
engineer
on
teradata,
but
this
is
purely
from
a
private
initiative
from
my
site,
so
I
joined
this
community
particular
that
I'm
coming
from
the
cloud
perspective
and
I'm
now
focusing
more
or
less
on
my
roots
back
again,
because
when
I
started
or
well
finished
my
school,
I
was
more
or
less
a
electrical
engineer,
so
I'm
quite
delighted
how
this
cloud-ish
and
iot-ish
things
work
together
and
in
particular
my
interest
in
this.
H
A
So
yeah
great,
if,
if
no
one
else
we'll
do
so
for
everybody
who's
new,
I
would
just
encourage
people
to
to
if,
if
you
want
to
get
up
to
speed
where
we
are
at
the
moment,
I
think
starting
with
the
original
white
paper
is
a
good
good
starting
point.
Unfortunately,
it's
it's
it's
in
kind
of
work
in
progress
state
forever,
but
I
think
there
were
a
couple
of
things
that
that
succeeded
that
that
white
paper
and
that's
the
did-
I
say
deep
dive
session.
A
B
B
Cool,
so
you
want
me
yes
till
I
dive
in
or
I
think
so
yeah
I
think
that'd
be
good.
Okay,
great,
so
I'll
actually
share
my
screen
for
those
who
have
video
up
and
we
can.
We
can
look
at
the
paper
as
we
go
and
there
have
been
some
really
good
comment
contributions
that
we
that
we're
not
going
to
walk
through
all
of
those
comments,
but
I'm
also
not
going
to
read
through
the
whole
paper
either.
B
The
etiquette
is
that
if
you
do
have
the
ability
to
to
make
changes
to
this
document
start
them
as
as
comments
and
and
then
we're
going
to
kind
of
work
through
and
see
how
to
take
all
of
the
inputs
and
and
make
this
document
even
better.
So
the
goal
is
well.
Actually,
let's
go
to
the
section
called
goals.
B
The
the
point
of
this
document
is
not
to
solve
anything,
yet
it
was
to
identify
the
security
challenges
that
we're
facing,
and
perhaps
if
it's
complete,
identify
why
those
challenges
are
different
than
the
ones
that
we
already
know
so
that
we
can
start
to
get
our
heads
around
how
to
approach
them.
What
we're
not
trying
to
do
with
this
document
is
we're
not
trying
to
make
any
you
know
recommending
particular
course
of
action
and
definitively
definitively
solving
we're,
definitely
trying
not
trying
to
limit
the
scope
of
security
discussions
outside
of
this
paper.
B
B
Sorry
I
put
this
together
with
the
hopes
that
we'd
start
to
add
more
and
more
items
and
I'm
starting
to
see
some
of
that
come
through,
which
is
great
and
the
edge
is
kind
of
a
funny
place.
It's
it's.
It
has
some
security
challenges
that
are
very
different
than
what
we're
used
to
and
some
of
the
the
security
challenges
are
based
on
just
a
simple
change
of
situation.
B
When
you're
in
a
cloud
and
data
center
environments,
you
don't
really
have
to
contend
with
the
notion
that
somebody
will
physically
access
your
compute
hardware
and
largely
because,
if
they
can
they're,
probably
someone
on
the
inside
and
no
one
from
the
the
you
know,
public
from
the
street
can
just
walk
in
and
plug
in
a
keyboard.
A
usb
drive
into
your
your
cloud
server
at
least
I
should
hope
not,
but
at
the
edge
that
that
assumption
falls
apart.
So
we
start
to
get
some
new
challenges.
B
B
And
so
obviously,
you
know
if
you
spend
time
in
the
space
where
you
deal
with
hardware,
security
or
hardware
root
of
trust.
Some
of
the
first
things
that
come
to
mind
are
like
tpm,
you
know
tpm2
and
so
on.
It
doesn't
matter
how
you
do
it,
even
if
it's
a
you
know,
a
separate
hardware,
module
that
you
that
you
attach
to
your
your
iot
gateway,
for
example,
in
the
usb
port.
However,
it
is
that
you
want
to
bring
root
of
trust.
B
Everything
starts
at
some
level
where
you
can
say
for
sure
that
the
the
same
device
is
running
your
software.
That
was
the
one
you
intended
and
it
still
looks
the
same
way
you
did.
But
then,
after
it's
running,
you've
got
this
notion
of
okay,
it's
the
right
hardware,
but
what's
its
condition,
and
there
are
some
conditions
that
actually
change
what
you
would
want
to
do
with
ed
software,
maybe
even
changing
what
you'd
be
willing
to
run.
B
So
an
example
that
I
give
here
in
the
paper
is:
if
some
of
the
the
condition
of
hardware
is,
you
know,
battery
level
or
gps
coordinates.
You
might
not
want
to
run
some
sensitive
software
on
a
device
where
the
gps
coordinates
are
outside
of
a
given
range,
and
that
might
just
be
that
there's
the
iot
gateway
is
on
a
campus
and
if
you're
running
software
on
that
campus,
that
is,
you
know,
behind
a
it's,
a
gated,
gated,
campus
and
so
on.
B
So
another
interesting
one
is
what's
attached,
so
this
is
actually
like
a
personal
favorite
of
mine
when
it
comes
to
locking
down
or
knowing
the
condition
of
hardware.
So
if
I
have
an
iot
gateway
and
it's
you
know
operating
an
oil
pump,
that's
in
a
remote
oil
field
where
basically,
nobody
is
present
in
the
desert
or
wherever
and
all
of
a
sudden,
an
unexpected
device
is
attached
to
the
the
universal
stereo
bus.
B
And
it's
you
know,
flash
storage
device
that
that's
the
sort
of
thing
that
I
would
want
to
not
only
know,
but
I
would
want
to,
if
possible,
take
some
action
immediately.
That's
of
course
getting
in
the
area
of
like
what
would
I
do
about
it
or
or
how
would
I
you
know,
recommend
some
kind
of
a
fix,
so
I'm
not
going
to
get
too
far
into
that,
but
because
we're
trying
to
avoid
that.
But
just
think
about
this
is
you
know
if
a
human
interface
device
attaches
to
a
completely
unattended,
iot
gateway?
B
That
seems
to
me,
like
the
sort
of
incident
that
you
would
want
to
to
flag
as
a
security
concern.
So
sometimes
there's
indications
of
compromise.
There's
a
lot
of
products
out
there
that
have
like
case
intrusion
and
things
that
you
can
use
when
devices
are
out
in
the
field
and
often
all
too
often,
though,
these
indications
of
compromise
don't
go
anywhere
other
than
the
hardware
monitoring
tools
that
came
with
the
the
kit
that
the
vendor
gave
you.
B
So
if
I
have
some
kind
of
a
web
dashboard
that
tells
me
the
the
condition
of
my
hardware,
but
it's
not
integrated
into
the
software
management
system
that
that
to
me
doesn't
really
sound.
Like
security
challenges
have
been
resolved,
just
that
there's
some
pieces
in
place
that
we
might
want
to
use
and
then,
of
course,
in
the
end,
after
all
of
the
hardware,
is
you
know,
put
into
a
condition
where
you
feel
like
it's
well
integrated,
and
there
are
some
some
security
challenges
of
being
handled.
B
You
still
have
to
come
down
to
the
the
notion
of
when
it
was
manufactured.
Was
it
manufactured
in
a
way
that
you
can
actually
trust
the
hardware?
It
might
have
the
you
know
the
tpn
module
and
so
on?
But
what
if
the
hardware
is
actually
manufactured
in
a
way
where
it
contains
devices
that
were
never
authorized
and
perhaps
are
listening
to
what's
happening
in
the
room?
And
you
know
you
weren't,
you
weren't
aware
that
your
hardware
had
these
these
devices
placed
on
it
and
so
on.
B
So
just
it
comes
down
to
you
know,
supply
chain
management
and
things
are
a
part
of
pictures.
I
guess
what
I
was
trying
to
say
here,
and
I
think
in
a
way
you
know
talking
about
supply
chain
here
is
a
good
is
a
good
way
to
expand
this
topic
other
than
just
saying
authenticity
of
hardware.
This
this
section
was
added
the
man
in
the
middle,
and
so
I
haven't
taken
time
to
review
this
too
much.
B
You
know
attached
to
its
circuitry
inside
the
the
gateway,
then
that's
that's
one.
You
know
inflexible
gateway.
Most
of
the
time
gateways
are
collecting
from
a
variety
of
devices
out
on
a
wet
a
network
or
a
low
power.
Wireless
network
such
as
lorawan
and
so
on,
and
what
we
get
into
here
is
that
you're,
probably
not
going
to
be
able
to
make
modifications
to
every
single
device
all
the
way
through
your
system
chain.
B
How
on
earth
do
you
know
that
the
devices
you're
taking
data
from
are
in
fact
the
devices
that
you're
supposed
to
be
taking
data
from
and
falsifying
one
or
two
readings
from
like
a
temperature
sensor
and
so
on?
It's
usually
not
you
know,
you're
not
usually
capable
of
doing
much
damage
or
getting
very
far
into
a
system
with
that.
But
do
you
think
about
some
of
the
automated
actions
that
get
taken,
especially
with
systems
like
closed
loop
systems
in
advanced
manufacturing?
B
A
bay
door
is
any
anything
that
you
might
do
in
response
to
indicators
that
come
from
sensors
and
if
somebody's
able
to
falsify
the
the
data,
then
they
can
actually
cause
actions
to
happen,
including
perhaps
you
know,
opening
a
backdoor
or
event
or
you
know
these
types
of
things
and
then
once
you
get
the
data,
let's
say
that
you
get
it
from
sensors
that
you
trust,
and
you
feel
that
the
quality
of
the
data
is
good.
Then
how
do
you
protect
it
as
it
moves
onward
in
the
stream?
You
know.
B
B
How
can
you
make
sure
that
that
data
is
actually
in
good
form
and
hasn't
been
tampered
with,
and
so
you
know
a
lot
of
people
say
well,
if
you
can
protect
it
right
from
the
device
encrypt
it
right
from
the
device,
then
you
know
it
should
be
okay
and
yeah
that
that
might
be
true.
The
question
is,
is
how
do
you
encrypt
it
right
from
the
device
and
know
that
the
encrypted
data
is
coming
from?
B
You
know
a
verifiable
device
and
all
of
these
things,
but
I
again
leave
the
solutions
to
some
some
other
papers
yet
to
come,
but
just
consider
that
the
data
goes
to
a
lot
of
different
different,
stop
points
or
touch
points
as
it
goes.
So
this
is
interesting
here
this
notion
of
the
denial
of
thing
attacks
or
denial
of
device
attacks
and,
in
some
cases,
you're
relying
on
devices
to
provide
data
so
that
you
can
make
decisions
or
in
essence,
so
your
whole
iot
system
functions
and
it's
a
nasty
thing
to
do.
B
B
And
so
then
you
know,
device
management
is
opens
a
lot
of
security
challenges
here
too,
because,
although
you
might
be
receiving
information
from
a
device
about
its
condition
and
something
like
a
digital
twin
here,
right
is
what's
the
battery
level
and
is
the
device
you
know
currently
identifying.
You
know
that
it's
a
sensor
is
connected
and
well
calibrated,
or
what
do
I
want
to
learn
about
this
device?
B
All
of
these
information
systems
are,
you
know,
potentially
taken
for
granted,
in
that
it
might
be
a
great
attack
point
for
somebody
to
say
yeah
they're,
going
to
take
actions
based
on
the
device
management
information,
and
sometimes
these
things
are
really
just
totally
open.
Apis
you're
able
to
drop
in
device
status.
Information,
however
you'd
like
and
then
it's
the
digital
twin
representation.
B
So
then,
above
the
hardware
and
the
device
is
connected
and
the
data
flowing
is,
you
know
we
get
to
the
operating
systems
and
we
all
know
that
securing
the
operating
system
is
a
very
difficult
task.
So
you
know
I
think
here
I
expect
to
see
a
lot
of
extra
information
being
added
in.
I
did
my
best
to
drive
to
drop
in
some
stuff.
B
That
was
right
on
the
top
of
my
mind,
and
I've
got
a
few
other
items
that
I'll
put
in
too,
but
all
the
way
down
above
the
hardware
root
of
trust
right
is,
you
know:
we've
got
to
bootstrap
this
thing
somehow,
and
you
know
the
first
step
is
bios
and
there's
a
lot
of
ways
to
secure
the
bios.
I
think
on
on.
You
know,
trusted
hardware
modules.
You
know
this
shouldn't
be
too
much
of
a
problem,
but
the
handoff
happens
where
secure
boot
usually
takes.
B
You
takes
you
through
the
point
of
where
some
you
know
trusted.
Drivers
are
loaded
and
we're
getting
close
to
the
point
where
we
hand
over
to
user
space,
and
when
we
get
around
here,
we
start
to
get
into
an
area
where
we're
wondering
what's
gonna
happen
next,
and
so,
if
you
get
secure
boot
in
place
and
everything,
then
that
after
they
hand
off
you,
you
have
to
make
sure
that
you're,
not
you,
don't
start
running
anything
that
wasn't
expected
to
so
more
and
more.
B
But
if,
in
addition
to
the
let's
say,
you
know,
docker,
daemon
or
container
d
and
you
know
cubelet,
you
also
have
some
other
binaries
running
that
you're
not
familiar
with,
and
you
know
they
just
get
to
do
whatever
they
want.
That's
even
post
secure
boot
if
they're
running
this
is
not
a
very
secure
scenario
and
so
in
some
way
you've
got
to
know
what's
running
there
and
be
able
to.
You
know,
fingerprint
it
in
some
sort
of
way
and
say:
hey:
these
are
the
ones
we
expect
these
ones.
B
We
don't
expect
so
they
should.
We
should
take
some
action.
I'm
going
to
spend
a
little
bit
more
time
on
on
4.3
here,
because
I'd
really
love
to
see
this
flushed
out
more.
If
you
take
a
private
key
and
you
bake
it
into
the
edge
hardware,
so
in
other
words
a
fixed
private
key
that
is
meant
to
to
be
used
to
identify
the
edge
node
to
the
the
up
strains
upstream
systems,
and
you
know
to
your
cloud
back
end
and
whatnot.
B
This
is
this
is
a
fine
start,
but
this
is
essentially
taking
a
really
really
privileged
piece
of
information
and
putting
it
on
hardware
that
somebody
might
get
their
hands
on.
So
if
you
don't
have
a
way
to
protect
all
of
the
the
things
around
it,
that
private
key
can
end
up
becoming
a
false
sense
of
trust,
and
that's
what
I'm
really
worried
about.
B
I'm
not
in
any
way
opposed
to
using
you
know,
keys
on
edge
devices
for
identities,
and
so
this
is
all
good
stuff,
but
if
the
key
should
be
used,
you
know
by
somebody
to
impersonate
that
device.
Can
you
tell
and
that's
kind
of
the
question
I
want
to
ask-
and
this
is
a
you
know-
a
topic-
that's
real
close
to
my
heart,
because
it's
actually
one
that
I've
had
to
deal
with.
B
Some
things
happened
where
private
keys
were
were
trusted
beyond
the
point
where
they
should
for
distributed
hardware,
and
that
was
just
we're
entering
into
an
era
where
people
are
becoming
aware
that,
for
example,
on
a
city
bus,
there
might
be
some
hardware
that
you
could
use
to
get
access
to
the
back
end
systems.
If
you
know
what
you're
looking
looking
for
so
so
I'd
love
to
see
more
information
here,
I'd
also
love
to
evaluate
kind
of
the
different
ways
that
people
are
trying
to
protect.
B
So
in
this
scenario,
where
I
feel
grossly
under
qualified
to
to
be
listing
stuff,
so
I
I
took
a
first
stab
at
it
and
I'm
I'm
hoping
that
people
add
in
a
lot,
but
you
know
we
get
into
some
situations
at
the
edge
that
are
also
very
different
than
cloud
and
data
center
that
that
need
to
be
discussed.
I
think,
if
you're
on
a
land,
that's
you
know
protected,
and
it's
private
to
your
data
center.
Then
you
know
open
ports
are
not
in
any
way
a
problem.
B
In
fact,
that's
the
way
that
you're
probably
going
to
be
able
to
you
know
access
mysql
database
on
3306
and
whatnot.
It's
it's
all
fine,
but
think
about
an
edge
environment
in
which
you
know
the
devices
have
open
ports
but
they're
on
wi-fi
they're
on
wi-fi
in
you
know
a
retail
location
or
a
warehouse
or
a
factory
or
something
like
that.
Open
ports
are
a
you
know,
a
point
of
attack
and
it's
pretty
easy
to
scan
for
them.
It's
pretty
easy
to
start
poking
around.
If
there's
those
exposed
ports.
B
So
then
you
know
you
their
vlans
are
an
option
and
there's
different
ways
to
try
to
you
know,
keep
traffic
separated,
but
in
the
end
I
just
want
to
ask
the
question:
is
you
know,
do
we
need
open
ports
at
the
edge,
the
same
way
that
we've
become
accustomed
to
using
them?
And
maybe
the
answer
is
yes
and
that's
fine
if
we
have
ways
to
protect
them,
but
one
to
bring
it
up
and
I'm
also
just
like
fixed,
fixed,
private
keys
and
stuff.
B
If
somebody
gets
access
to
the
iot
gateway
in
that
truck
and
they
get
the
vpn
information
from
it,
then
essentially,
the
truck
is
like
an
extended
attack
surface
for
my
warehouse,
and
I
treat
vpns
very
carefully,
especially
you
know
ones
that
are
are
used
in
a
kind
of
a
permanent
fashion,
because
they
that
means
you
know
you
get
access
to
the
warehouse.
You
get
access
to
the
data
center,
you
get
access
to
warehouse,
you
get
access
to
the
trucks
and
so
on
and
so
forth.
B
Something
to
watch
out
for
and
up
until
now,
we've
largely
considered
that
if
you're
on
the
network
you're
part
way
to
actually
getting
access
to
the
data,
and
that
really
goes
back
to
kind
of
this
open
port
thing
and
so
on.
It's
just
if
you're
there
and
able
to
physically
communicate
with
the
the
the
nodes
that
are
on
the
network,
and
so
you
know
taking,
for
example,
the
land
in
the
factory
right.
B
If
you're
on
that
land,
then
you're
kind
of
part
way
there
to
to
maybe
doing
some
damage
or
getting
access
to
data
that
you
shouldn't
get
access
to.
So
I
just
want
to
ask
the
question:
is:
does
everything
need
to
be
not
worked
out
the
same
way
that
it
used
to
be
at
the
edge?
Maybe
the
answer
is
no,
especially
for
devices
that
are
like
outside
of
physical
walls
right
things,
hanging
on
the
side
of
a
building
or
up
on
a
light
pole
owned
by
a
city.
B
Do
those
need
to
be
on
the
same
type
of
network
that
they
they
used
to
be
author,
unauthorized
outbound?
It's
been
mentioned
to
me
a
few
times
like
you
know,
hey.
I
put
an
iot
gateway
out
there,
and
then
we
noticed
at
one
point
that
a
microservice
that
we
were
using
on
that
gateway
was
sending
traffic.
You
know
kind
of
phoning
home
and
sending
traffic
back
to
the
author
of
the
microservice
and
it's
data
that
we
never
thought
that
they'd
be
collecting
from
our
iot
gateway.
And
how
do
we?
B
You
know,
prevent
this
stuff,
and
my
answer
is
well.
You
know
if
you're
running
microservices,
that
you
haven't
tested
and
so
on.
Well,
that's
one
thing
right:
there
right
is:
you
can't
just
grab
third
party
microservices,
you
shouldn't
do
it
in
the
cloud
you
shouldn't,
do
it
at
the
edge,
but
on
things
that
haven't
been
vetted,
but
you
know,
with
with
edge
nodes
you're,
not
really
around
to
see
the
traffic
the
same
way
as
you
are
in
you
know:
cloud
environments
in
cloud
environments.
Sometimes
you've
got.
B
You
know,
active
monitors,
watching
network
traffic
and
trying
to
pull
out
stuff
and
look
for
anomalies
and
things
and
at
the
edge
it's
not
really
feasible.
To
have
that
much
software
actively
monitoring
traffic
when
the
edge
node
might
literally
have
only
one
line
coming
off
of
it.
That
goes
back
to
some
data
center,
possibly
over
a
vpn
or
whatever.
Are
you
really
going
to
put
active
network
monitoring
at
every
single
edge
node?
Maybe
we
need
a
different
approach
here?
It's
like
you
know.
B
What
do
we
do
about
unauthorized,
outbound
traffic
and
it's
kind
of
the
same
as
off
unauthorized
inbound,
and
so,
if
the
control
plane
is,
I
is
doing
identity,
verification
of
the
edge
nodes.
Why
are
the
edge
nodes
not
doing
identity,
verification
of
the
control
plane,
and
that's
that
point
kind
of
speaks
for
itself
right
there?
In
summary,
then
we
get
to
the
edge
micro
services
and
some
of
my
thoughts
around
here.
Are
you
just
got
to
treat
the
software
the
same
way
that
you
would
treat
it
for?
B
You
know
deploying
any
third-party
stuff
where
you
you
want.
You
know
security
on
your
environment,
so
do
a
you
know,
do
an
integrity
check
of
the
the
microservice
images
and
that's
just
kind
of
a
straightforward
situation.
But
then
a
little
bit
different
than
your
normal
environment
is.
I
might
not
want
to
give
those
edge
micro
services
access
to
privileged
privileged
information
until
I
know
for
sure
that
the
rest
of
the
stack
is
looking
secure.
B
For
example,
if
I
have
an
api
key
to
drop
things
into
my
s3
buckets
in
my
aws
environment,
I
don't
really
want
that
api
key
baked
in
the
microservice
and
then
that
image
is.
You
know,
an
image
that
I
I'd
be
very
worried
about
people
instantiating
without
my
authorization,
but
if
I'm
gonna
pass
it
in
some
kind
of
configuration
or
you
know
secrets
at
runtime
just
knowing
that
the
rest
of
the
stack
is
good
before
this
microservice
gets.
B
Its
sensitive
information
is
kind
of
the
challenge
here
and
wanted
to
call
that
out.
Are
we
running
any
microservices
at
the
edge
that
are
not
authorized,
and
how
would
we
know
and
can
we
whitelist
and
some
other
good
stuff
microservices
run
well,
some
of
the
edge
nodes
have
resources
that
are
are
pretty
important.
B
These
are
things
that
you,
you
don't
want
microservices
just
tapping
into
them
willy-nilly,
because
you
can
actually
execute
commands
on
legacy
equipment
far
more
easily,
I
think
than
than
people
coming
from
a
cloud
background
realize
there's
a
lot
of
equipment
out
there
that
if
you
can
open
the
back
panel,
which
usually
requires
just
like
a
screwdriver,
if
you
can
open
the
back
panel
and
connect
to
the
the
ethernet
port,
there
then
pretty
much.
You
can
start
issuing
commands
and
that's
a
lot
of
legacy
equipment.
Is
that
way,
especially
in
industrial
settings.
B
So
if
I
want
some
edge
nodes
to
change
the
software,
I
want
to
also
know
that
it
was
executed
that
that
request
for
change.
So
that's
out
there
checking
you
know
employee
id
badges
of
your
near-field
communication.
Recording
who
is
you
know,
passing
what
work:
checkpoints
in
the
warehouse
or
factory
or
on
an
oil
rig.
That's
pretty
important
information,
and
if
I
decide
that
that
iot
gateway
is
going
down
for
servicing,
it's
going
to
get
swapped
out.
I
don't
want
those
microservices
to
remain
on
there.
B
B
How
do
you
know,
and
how
do
you
know
without
sending
a
person
out
there
right
because
part
of
the
challenge
of
the
edges,
the
expense
of
going
out
and
physically
fixing
things,
is
so
high
that
you
can't
just
fix
it
by
by
sending
somebody
to
go
check
it
out?
It's
not
just
you
know
a
couple
halls
down
in
a
data
center
where
somebody's
doing
maintenance
anyway
on
a
routine
basis.
B
It's
in
the
iot
world,
it's
called
the
truck
roll
and
in
fact
it's
not
just
the
iot
world
in
the
mtm
world
m2m
world,
and
before
that
just
plain
old
in
the
industrial
world,
it's
called
our
truck
roll
and
they're
really
expensive
out
in
oil
fields.
There
are
specialized
electricians
that
are
able
to
handle
the
hazardous
situations
and
the
high
voltages
stuff.
B
These
people
are,
you
know,
sometimes
400
us
dollars
per
hour
and
you
might
even
need
to
pay
higher
amounts
if
you
want
them
to
be
deployed
immediately
to
solve
a
problem.
In
some
cases
they
have
to
land
by
helicopter
to
get
there
in
any
kind
of
efficient
amount
of
time
and
or
you
know,
over
some
dangerous
terrain.
These
are
not
things
that
you
take
lightly,
so
once
you
put
edge
hardware
out
there,
you
need
some
kind
of
guarantees
over
remote
control
and
remote
versioning
and
this
type
of
stuff.
Otherwise
it
gets
really
expensive.
B
So
anyway,
that's
the
notion
behind
these
guarantees-
and
the
last
thing
that
I
have
listed
here
is:
it
doesn't
make
a
lot
of
sense
to
protect
edge
micro
services
and
also
protect
edge
hardware.
If
you
don't
have
a
guarantee
over
matching
them
up,
I
for
one
would
not
want
you
know
any
employee
id
information
running
on
an
edge
compute
node.
That's
that's
sitting
on
the
outside
walls
of
my
of
my
factory.
It's
it's
not
a
place
where
I
want
sensitive
information
to
be
stored
or
even
flowing
through.
B
B
Some
of
the
things
we're
doing
at
the
eclipse
foundation
with
eclipse
io
fog
is,
if
I
know
that
the
gps
coordinates
of
the
edge
compute
node
are
outside
of
the
range
that
is
appropriate
for
this
particular
pod.
Then
it's
not
able
to
to
be
scheduled
on
those
edge
nodes,
even
though
they
have
the
capacity
and
all
of
the
right
matching
hardware
attributes.
B
So
just
adding
some
edge
awareness
to
the
to
the
orchestration
layers
is
stuff
that
I
foresee
becoming
more
and
more
important,
and
I
would
love
to
know
more
and
more
attributes
that
people
are
interested
in
using
to
validate
is
the
right
software
running
on
the
right
hardware
at
the
right
time.
I
would
also
add
so
that's
a
whole
run
through
me
running
my
mouth
for
a
while.
B
B
You
know,
containers
being
you
know
main
one
of
them,
but
all
of
the
stuff
that
people
want
to
talk
about
regarding
security
in
in
relation
to
kubernetes
in
general
and
then
like
what
of
it
is
particularly
challenging
at
the
edge
would
make.
I
think,
a
great
way
to
to
get
this
document
into
a
position
where
it's
we
wanted
to
inform
people
in
the
kubernetes
community
of
the
challenges
at
the
edge,
but
in
particular
I
think,
you're
right.
B
The
challenge
is
at
the
edge
as
it
relates
to
the
you
know,
the
stuff
that
they're
working
with
ie,
kubernetes
and
and
all
of
the
surrounding
projects,
so
yeah
good,
good
call,
I'm
not
sure
how
to
do
it.
You
know
I
think
comments
are
going
to
come
in
probably
steering
things
a
little
bit
more
in
that
direction
already,
but
maybe
even
like
something
like
an
actual
review
to
rename
the
sections
right
toward
kubernetes
related
topics
or
something
I'm
not
really
sure
open
to
ideas.
A
H
Yeah
cool,
I
have
a
question.
Can
you
grant
me
please
access
to
the
document,
because
I
have
plenty
of
comments,
but
I'm
just
sadly,
I
just
found
the
document
by
the
end
of
last
day
and
I'm
currently
at
section.
I
think
three.
So
I
have
plenty
of
comments
there
and
I
would
like
to
add
them
in
the
document.
Unfortunately,
I
don't
have
access
to
it.
H
A
E
A
E
B
Yeah,
no,
I
imagine
I
imagine
it
will
get
out
of
hand.
So
I'm
no!
I'm
with
I
like
your
suggestions
to
you.
I
I
would.
I
would
like
to
do
it
by
the
group
I
at
first
at
first
I
don't
mind
doing
it.
You
know
one
by
one
just
until
it
gets
out
of
hand
sure
I
can
do
it
a
little
here
and
there,
but
definitely
as
soon
as
we
can
move
over
to
having
people
get
their
permissions
by
joining
the
the
working
group.
That
would
be
ideal.
E
E
E
A
Yeah
I
mean
until
we
fix
this,
I
mean
if,
if,
if
someone
you
know
wants
to
start
working
on
it,
just
giving
it
you
know,
suggesting
privileges
would
be,
you
know
would
be
a
good
first
step
and
then
we
can
lock
it
up.
This
is
what
we
did
with
the
with
the
original
white
paper.
So
first
it
was
public,
but
it
was.
A
A
B
Okay,
cool
well
I'll
stop
by
sharing
my
screen,
and
this
is
not
the
end
of
the
discussion,
but
rather
the
from
my
point
of
view,
the
beginning
of
a
deeper
discussion,
I'm
on
the
the
slack
channel
for
this
working
group
fairly
regularly,
meaning
like
if
you
call
out
my
name,
I
will
probably
respond
within
you-
know:
24
hours,
some
days
are
busier
than
others.
If
you
don't
call
out
my
name,
it
might
be
several
days
before
I
have
a
chance
to
read
messages
and
so
on,
particularly
this
working
group.
B
B
I
am,
I
am,
I'm
torn
because
I've
been
invited
to
through
the
eclipse
foundation,
of
course,
to
be
there
showing
io
fog,
eclipse,
io
fog
with
with
kubernetes
integration
and
and
I
don't
think,
giving
a
talk
during
kubecon,
but
but
definitely
there
to
show
people
at
the
eclipse
foundation
booth.
I
don't
know
if
I'll
be
able
to
make
it,
and
so
I'm
gonna
try,
I
hope
to,
and
if
so
will
I
see
you
there.
A
Yeah
yeah,
so
we
have
a
session
there.
That's
why
I
asked
so
steve
and
cindy
and
me
there
will
be
a
session
on
the
working
group
and
a
couple
of
sessions
of
the
cube
edge.
I
was
thinking
yeah.
I
was
thinking
if
you're
getting
there
some
of
these
material.
We
can.
We
can
present
there
as
well.
Like
you
know,
you
know,
but
let's,
let's
talk
about
it:
offline,
yeah,
yeah,.
B
E
A
So
is
this
time
work
for
everybody,
so
for
the
next
meeting
for
the
for
the
regular
time
zone
in
two
weeks,
we
will
switch
for
for
the
one
hour
earlier
to
you
know
as
we
discussed
to
to
to
align
with
with
the
daylight
savings
times
and
everything.
So
what
about
this
time?
Slot?
Is
everybody,
okay
to
move
this
one
hour
early
as
well.
A
F
A
E
E
I
would
favor
it
simply
because
not
permanently,
but
only
during
the
daylight
savings
transition.
So
if
there
are
parts
of
the
world
that
don't
transit
with
the
us,
then
they
they,
it
might
not
be
at
the
same
time
throughout
the
whole
year.
But
normal
expectation
for
people
in
the
u.s
on
the
kubernetes
project
is
that
the
meetings
shift
with
the
daylight
savings
time
now,
given
that
this
slot
we're
on
right
now
is
for
apec.
E
E
A
E
And
I
think
we
do
have
to
whatever
is
resolved
part
of
the
problem
with
people
showing
up
at
the
wrong
time.
There
was
one
who
showed
up
early
today
and
I
went
on
and
told
him
to
try
again
in
an
hour,
but
we
didn't
have
the
agenda
doc
actually
listing
the
time,
and
we
maybe
need
to
be
better
about
that.
So
yeah.
F
A
E
A
So
I
added
I
added
those
descriptive
time
times
in
the
in
the
agenda:
doc,
there's
a
two.
You
know:
google
two
calendar
links
one
for
google
one
for
ics
and
what
I'm
planning
to
do
now
is
every
monday
when
there's
a
week
going
for
the
you
know,
when
we
have
a
meeting,
just
publish
both
on
the
mailing
list
and
and
just
like
you
know,
yeah
and
all.
G
A
B
F
B
For
people
that
that
don't
necessarily
you
know
want
to
just
dive
in
and
read
and
figure
out
what
on
earth
this
thing
is
they
can
watch
the
video
so
I'd
like
to
keep
it
open.
For
you
know,
I
would
say,
maybe
you
know
a
30
a
30
day
cycle,
but
with
checking
in
on
the
next.
You
know
working
group
meetings,
but
what
I'll
be
doing
is
I'll
be
starting
to
work
through
some
of
the
suggestions
and
maybe
make
some
edits.
B
You
know
posted
the
black
channel
stuff
to
to
actively
engage
some
discussion.
I
kind
of
want
to
know
what
the
working
group
wants
to
do
with
it
once
it's.
You
know
polished
a
bit
more
and
you
know
that,
of
course,
is
like
you
know,
I
I
was
happy
to
bring
it
in,
but
I'm
not
sure
where
it
should
go
or
what
should
be
done
with
it.
B
So
maybe
listening
suggestions
of
like
you
know
how
would
she
get
finalized
and
where
it
should
go
after
that,
but
you
know
I
don't
want
to
open
for
you
know
six
months,
I
don't
even
want
to
be
open.
I
think
for
three
months,
where
we're
kind
of
not
sure
what
we're
going
to
do
I'd
say
about
30
days
from
now.
We
probably
should
have
it
in
a
pretty
final
state.
If,
if
I
can
stay
on
managing
it,
that
should
be
achievable.
A
Perfect,
perfect
yeah
yeah.
It's
always
the
same
question
for
me
for
for
the
original
first
white
paper
for
julie.
I
never
find
time
to
to
you
know
just
go
ahead
and
finish
it
up,
but
you
know.
Maybe
you
know
once
you
you
have
your
your
or
this
one
in
shape.
Maybe
we
can
coordinate
and
you
know,
publish
both
of
them.