►
From YouTube: CNCF SIG Security Meeting 2021-02-24
Description
CNCF SIG Security Meeting 2021-02-24
B
C
C
C
F
E
All
right,
let's
get
started
with
with
our
housekeeping
items.
I'm
gonna
go
through
and
first
thing
is.
I
see
a
lot
of
members
on
the
call
today,
but
if
you
haven't
already
added
your
names,
please
do
so
and
if
you'd
like
to
bring
up
any
items
that
you'd
like
to
talk
about,
please
make
sure
to
include
that
next
to
your
name.
So
we
can
make
sure
we
discuss
that.
E
E
E
He
leads
the
serverless
working
group
and
has
been
you
know,
working
very,
very
hard,
and
I
was
privy
to
a
lot
of
the
early
discussions
with
the
the
cloud
events
work.
That's
being
done,
I
don't
want
to
take
doug's
thunder,
but
doug
very
happy
to
have
you
here
present
to
us
about
the
status
of
the
serverless
working
group,
and
you
know,
as
we
start
off
today.
I
just
thought.
Maybe
I'll
just
give
provide
one
particular
input.
E
I
think
there's
been
a
lot
of
debate
on
what
exactly
serverless
is
and
what
constitutes
serverless.
So
would
be
great
if
you
could
also
you
know
sound
out
on
that
and
give
your
perspective
as
to
what
exactly
is
severeness.
I
have
my
thoughts
with
that.
Please
take
it
away
doug
and
thank
you
for
being
here
today.
Carol.
G
Thanks
for
having
me
so
when,
when
sarah
approached
me
to
talk
to
you
guys,
she
gave
me
some
guidance
in
terms
of
what
you
wanted
me
to
talk
about,
but
not
a
whole
lot,
so
I
wasn't
sure
what
to
to
put
together
in
terms
of
preparation
for
this.
So
please
do
not
hesitate
to
stop
me
and
ask
me
some
questions
or
to
go
in
a
different
direction,
because
I
was
guessing
in
terms
of
what
you
got
in
this
presentation.
Okay,
so
just
don't
hesitate
to
depend
on
down
a
different
track.
G
If
that's,
if
that's
the
way,
you
guys
want
to
go
okay,
so
one
of
the
things
she's
mentioned
is
something
you
were
just
asking
about.
You
know
what
is
serverless
and
I
think
from
this
serverless
working
groups
perspective.
The
best
way
to
think
of
it
is
to
first
start
out
with
what
is
a
function,
and
typically
those
are
operations
that
are
or
they're
they're
processes.
You
know
like
workloads
or
applications.
What
do
you
want
to
call?
You
know
something?
G
A
function
doesn't
even
deal
with
the
http
or
transport
aspects
of
things
right.
So,
if
you
look
at
this
little
this
little
sample
right
here.
This
thing
talks
about
you
know
how
to
take
in
parameters,
how
to
process
the
parameters
and
then
return
something
it
doesn't
deal
with
the
http
or
or
transport
aspect
of
things.
That's
supposed
to
be
sort
of
managed
by
the
infrastructure,
that's
hosting
your
function.
Now,
that's
the
way
most
people
tend
to
look
at
it.
G
However,
there
are
some
environments,
take
for
example,
k
native
where
the
user
is
responsible
for
managing
the
http
aspect
of
things
right,
so
they
have
to
inject
an
hp
server
into
their
little
javascript
code
here,
just
to
get
things
up
and
running
or
let
the
javascript
framework
do
a
forum,
but
either
way
they
have
to
sort
of
set
that
up
themselves.
Now.
G
Okay,
so,
obviously,
when
you
look
at
this
from
a
an
event-driven
process,
thing
right,
you
have
your
function,
executing
someplace,
you're
gonna,
have
an
event
producer
or
event
source
generating
events
that
gets
sent
over
to
your
function.
To
do
some
work
and,
as
I
said
typically,
these
functions
are
meant
to
be
stateless,
so
they
have
to
talk
to
some
backend
service,
often
to
store
their
persistence
or
to
get
access
to
a
database
or
something
like
that
right.
G
But
what
that
allows
is
for
these
functions
to
not
only
just
be
stateless
but
then
to
be
also
scalable
right.
That
way
they
can
come
and
go
as
they
need
to
based
upon
the
workload,
but
all
the
real
data
stored
back
here
in
the
back
end,
so
that
allows
them
to
be
stateless,
okay,
any
questions
so
far.
G
Okay,
hopefully
none
of
this
is
actually
new.
So
what
is
serverless
then
relative
to
functions?
Well,
the
way
I
tend
to
look
at
it
is
serverless
takes
function
to
service
one
step
further:
okay,
because
function
by
itself,
as
I
said,
if
it's
just
a
small
little
unit
of
work
notice,
what
I
didn't
talk
about,
something
that
is
very
popular
with
serverless
environments,
things
like
auto
scaling
of
the
function
based
on
demand
even
down
to
zero
right.
G
So
to
me,
the
difference
between
functions
and
serverless
is
that
serverless
adds
a
bit
more
of
the
orchestration
and
management
layer
around
it.
Right
function
is
just
small
little
micro
micro
service,
serverless,
says:
okay.
Now,
let's
do
auto
scaling
based
upon
load
or
cpu
or
some
other
metric,
including
to
get
down
to
zero
because
one
of
the
popular
aspects
of
serverless?
Well,
it's
not
that's
true
for
all
of
them.
It
is
very
popular.
G
Okay,
so
overall
you
can
think
of
serverless
as
not
needing
to
worry
about
the
managing
the
infrastructure,
but
then
serverless
is
meant
to
actually
invoke
functions
under
the
covers
now.
I
will
point
out,
though,
that
there
are
a
lot
of
people
who
use
the
term
serverless
outside
of
functions
in
the
sense
that
they
don't
think
of
what
they're
hosting
as
a
function.
So,
for
example,
if
you
look
at
something
like
cloud
foundry,
no
one's
going
to
say
that's
a
function
as
a
service
environment.
G
Those
are
typically
web,
apps,
maybe
microservices,
but
they
also
could
be
rather
large
things
now.
One
thing
that
that
cloud
foundry
is
missing
is
the
scale
down
to
zero
part,
but
it
will
do
auto
scaling
up
from
one
right,
but
it's
so
if
you
could
add
the
scale
to
zero
to
me
cloud
foundry
could
be
a
serverless
environment
from
that
definition
of
it's
just
there
to
manage
the
infrastructure
for
you,
you
give
it
the
source
code,
you
give
it
your
deployment
artifact
whatever
it
is,
and
it
manages
the
rest
for
you.
G
Okay,
that's
to
me
what
serverless
is
all
about.
It's
just
the
most
popular
use
of
it
is
for
functions,
okay,
so
with
all
that,
and
as
a
background,
let's
talk
about
the
serverless
working
group,
so
the
service
working
group
in
the
cncf
was
started.
I
think
around
june
2017,
mainly
because
the
toc
wanted
to
understand
what
to
do
with
serverless,
if
anything
at
all.
At
that
point,
in
time,
serverless
was
still
a
relatively
new
thing
from
a
community
perspective.
G
Obviously
things
like
landed
had
been
out
there
for
a
while,
but
it
really
hadn't
taken
off
in
terms
of
a
broad
open
source,
community
kind
of
a
thing,
and
so
they
want
to
know.
Okay,
what
do
we
do
with
it
and
in
order
to
make
that
kind
of
recommendation
or
analysis,
we
first
had
to
do
what
I
would
call
sort
of
background
work
right
figure
out
what
is
serverless,
and
it's
kind
of
you
know
what
I
just
what
I
just
talked
about
in
the
first
four
slides
right.
What
is
serverless?
G
But
the
other
thing
we
created
was
a
landscape,
and
I,
if
you
go
to
the
serverless
working
group
pages
or
get
a
repo
you'll,
find
a
link
to,
I
think
it's
a
google
spreadsheet
that
tries
to
list
out
all
the
popular
serverless
frameworks
out
there.
What
each
one
does
the
languages
they
support,
what
kind
of
back-end
services
they
have
stuff
like
that?
It's
not
necessarily
the
completely
up-to-date,
but
at
least
it
gives
you
an
idea
of
sort
of
the
general
shape
of
what
the
community
has
out
there
today.
G
Okay,
now
in
terms
of
recommendations,
we
did
come
up
with
some
interesting
things
and
I
remember
correctly
a
lot
of
them
were
things
like
look
for
other
or
look
for
serverless
frameworks
in
the
open
source
community
that
we
can
encourage
to
join
the
cncf
to
start
building
up
an
ecosystem
within
the
cncf
around
serverless,
also
trying
to
look
for
education
opportunities
and
explaining
what
is
serverless.
Why
it's
so
great
and
stuff
like
that?
G
But
one
of
the
biggest
things
is
we
want
to
look
at
where
we
could
help
out
the
community
relative
to
adoption
or
interoperability,
because
while
there
were
some
or
while
there
were
and
still
are
a
whole
bunch
of
different
serverless
frameworks
out
there,
there
really
wasn't
much
of
interability
between
them.
So,
for
example,
there
are
some
that
run
on
kubernetes
and
that's
great.
They
all
run
on
kubernetes,
but
the
way
you
interact
with
them
was
completely
different
right.
They
had
their
own
set
of
apis
and
stuff
like
that.
G
G
One
of
the
things
we
realize,
though,
is
because
we
have
lots
of
different
ideas
of
things
we'd
like
to
be
able
to
do
because
we're
all
developers-
and
we
love-
you-
know,
ability
and
standards
and
all
that
other
stuff,
but
we
realized
it.
It's
going
to
get
really
really
political
right,
because
there
are
existing
things
out
there
and
asking
anybody
to
change
their
their
implementations
or
their
apis
is
is
just
asking
for
trouble.
Okay.
G
So
what
we
did
is
we
identified
something
that's
sort
of
off
to
the
side
and
we've
realized
when
you
think
about
functions
in
serverless.
As
I
said,
a
lot
of
them
are
event
driven,
so
we
said:
okay,
well,
is
there
something
we
can
do
in
the
event
space,
and
we
realize
that
one
of
the
pain
points
that
people
experience
with
events
is
not
so
much
processing
of
the
events
but
routing
of
the
events,
meaning
how
does
an
event
get
from
the
producer
to
the
consumer
now
today?
G
The
way
that
usually
works
is
especially
if
it's
going
through
a
piece
of
middleware
is
that
middleware
has
to
understand
the
event
coming
through
it
in
some
way,
even
at
a
meta
level,
just
to
understand
how
to
send
it
to
the
next
destination.
It
has
to
know
what
their
station
is.
So
maybe
it
has
to
read
somebody
better
or
something
like
that
or
whatever.
G
Even
at
that
level,
it
has
to
look
at
the
message
in
some
way.
However,
most
of
those
intermediaries
need
to
do
more
than
just
simplistic
proxy
type
stuff.
A
lot
of
them
actually
want
to
do
routing
based
upon
the
event
itself,
so,
for
example,
maybe
it
wants
to
do
routing
based
upon
where
the
event
is
coming
from.
Maybe
wants
to
do
routing
based
upon
the
type
of
the
event
right,
maybe
creates
go
to
one
destination
while
deletes
go
to
a
different
destination
that
kind
of
stuff.
Okay.
G
Well,
in
order
to
make
that
kind
of
determination
that
middleware
has
to
now
understand
the
event
flowing
through
it,
and
I
don't
mean
necessarily
has
to
understand
all
the
business
logic,
but
at
least
has
to
understand
things
like
how
to
parse
it
to
know
what
field
to
look
at
to
do
that
routing?
Okay,
so
we
decided
well
what
if
we
try
to
help
in
this
space
and
that's
how
we
came
up
with
cloud
events.
G
Okay,
what
cloud
events
is
meant
to
do
is
to
help
in
their
routing
from
from
the
source
to
the
destination,
by
defining
common
metadata
attributes
and
I'll
give
an
example
in
a
minute.
Well,
actually,
let
me
go
ahead
and
jump
there
right
now,
it's
easier
to
talk
about
that.
Okay,
so
let
me
look
at.
Let
me
show
you
this
example
right
here.
G
So
if
you
look
at
this,
this
http
post
and
you
ignore
these
four
attributes,
the
rest
of
it
is
just
what
you
might
see
from
an
event
flowing
through
or
flowing
over
hcp
right.
You
have
the
in
essence.
So,
basically,
the
url
is
being
sent
to,
along
with
the
host
name,
the
type
of
data
and
then
the
data
itself.
Okay.
Now,
in
order
for
some
sort
of
piece
of
middleware
to
route,
this
message
appropriately,
based
upon
the
fact
that
it
knows
it's
a
new
item,
type
of
action
or
event.
G
It
would
have
to
understand
that
this
is
json
how
to
parse
this,
to
look
for
a
field
called
action
and
then
take
some
some
behavior
based
upon
that
value.
Okay,
well,
what
cloud
events
does
it
says?
Well,
wait
a
minute!
What,
if
you
just
add
a
couple
of
extra
http
headers
to
this
message,
ignore
this
for
a
minute,
because
that
just
tells
you
what
cloud
and
specific
spec
version
we're
talking
about,
and
this
is
just
a
unique
id
for
the
event.
G
G
It
can
look
at
this
metadata
and
make
some
very
basic
determination
in
terms
of
what
it
wants
to
do
with
it
relative
to
routing
okay,
this
isn't
rocket
science.
You
may
even
look
at
that
and
say:
oh
my
gosh.
What
what
the
heck
can
you
do
it
that
is
so
simplistic
and
to
some
extent
that
is
true:
it's
not
sexy,
it's
not
glamorous,
but
believe
it
or
not.
This
actually
saws
a
significant
pain
point
for
many
people
right
this
little
bit
of
extra
metadata
being
outside
of
the
event
itself.
G
Whoops
actually
has
been
a
real
life
saver
to
a
whole
bunch
of
people.
I've
had
many
customers
come
up
to
me
and
say
thank
you
for
creating
this,
because
we
did
exactly
what
I
just
mentioned.
We
had
to
create
middleware
and
every
single
time
there
was
a
new
event
with
a
new
schema.
All
the
middleware
had
to
change
to
understand
how
to
parse
it
and
know
what
to
do
with
it.
This
makes
the
life
so
much
easier.
G
Okay
and
to
be
honest,
if
there
are
other
properties
that
people
don't
or
don't
see
today
that
they
want
to
add
to
it.
They
can
extend
this
themselves,
but
the
point
is
much
like
http
headers
in
general,
we're
providing
a
well-defined
location
for
where
this
extra
bit
of
metadata
is
supposed
to
live
so
that
you
can
use
it
for
whatever
purpose
you
want
much
in
the
same
way,
http
server
itself
doesn't
understand.
G
What's
in
the
body
most
of
the
time,
it
routes
it
to
the
proper
web,
app
based
upon
an
http
header,
okay,
same
concept:
now,
that's
what
we
call
the
binary
format.
The
structured
is
the
exact
same
thing
except
people.
Come
came
to
us
and
said
you
know
this
is
all
great,
but
what,
if
I
don't
even
have
an
event,
that's
currently
being
sent
and
creating
something
brand
new?
G
Can
you
guys
give
us
an
event
wrapper
that
we
can
just
use
and
we,
and
so
we
did
and
that's
what
we
call
the
structured
side
of
things
right
so
basically
just
said:
okay,
let's
create
it
in
json,
and
you
can
see
it's
the
exact
same
data
except
instead
of
http
headers,
it's
inside
the
body
and
the
data
is
the
exact
same.
So
this
serves
two
purposes.
One
give
somebody
a
well-defined
wrapper
if
they
don't
already
have
one,
because
we
do
not
want
to
create
yet
another
common
event,
format.
G
That
was
not
our
purpose,
but
if
they
don't
have
one
and
they
want
one
recommended
we'll
give
it
to
them.
But
then
there
are
also
other
cases
where
people
say.
You
know
this
is
great,
but
I
don't
want
the
dhcp
headers.
I
want
it
in
the
body
because
I
want
to
just
to
be
able
to
take
this
entire
chunk
of
json.
Stick
it
into
a
database
and
then
let
the
next
step
in
the
process
deal
with
it.
G
And
if
it's
in,
if
that
information
is
as
http
headers,
that
I
need
to
extract
http
headers
and
create
some
sort
of
global
wrapper
myself
to
have
all
the
information
there,
so
it
serves
multiple
purposes
to
have
the
structured
side
of
things
and
that's
what
we
did.
Okay
so
anyway,
that's
what
the
service
working
group
decided
to
work
on
first
was
to
attack
that
particular
problem.
Okay.
G
Now,
while
we're
working
on
that,
we
did
think
about
other
possible
things
in
terms
of
next
steps
to
work
on
and
one
of
the
things
that
came
up
was
serverless
workflow
and
I'm
gonna.
I'm
not
gonna
talk
a
whole
lot
about
that,
but
you
can
kind
of
imagine
what
it
is
right.
It's
orchestration
of
functions
right,
so
events
coming
into
the
system.
G
You
react
to
those
events,
you
do
some
processing
and
maybe
it's
a
multi-step
process
and
each
step
can
only
process
or
can
only
get
kicked
off
after
a
previous
step
is
already
done,
who's
going
to
manage
that
orchestration
who's
going
to
realize
or
to
manage
that
one
event.
It
needs
to
get
sent
to
five
different
processes,
and
then
they
come
back
together
at
the
end
kind
of
a
fan
and
fan
kind
of
thing.
That's
what
serverless
workflow's
supposed
to
do
for
you
and
that's
a
that
itself
is
a
sandbox
project
in
the
cncf.
G
G
We
have
at
one
point
in
time:
we've
had
pretty
much.
I
think
every
major
vendor
out
there
in
in
in
the
cloud
native
world
show
up
at
our
meeting
at
one
point
or
another,
even
aws,
which
I
think
is
a
big
win
for
us,
because
aws,
while
they
do
do
a
little
bit
of
open
source
stuff,
they
don't
do
a
whole
lot
right,
so
they
were
there
for
a
while.
G
But
the
most
the
most
interesting
thing
from
the
latest
status
perspective
is,
if
you
think
about
cloud
events,
it's
great
for
helping.
You
get
the
event
from
point
a
to
point
b,
but
there's
lots
of
other
things
involved
with
just
managing
the
event
life
cycle
itself.
In
particular,
how
do
you
discover
who
says
who
sends
a
particular
type
of
events
or
what
type
of
events
they
actually
do
send?
G
So
you
know
what
you
want
to
subscribe
to:
okay,
we
decided
we're
going
to
start
looking
at
a
discovery,
api
spec,
so
that
a
consumer
can
go
to
one
or
multiple
discovery,
endpoints
and
find
out
who
generates
what?
Okay,
obviously,
once
you
figure
out,
who
generates
the
thing
you're
interested
in
you
may
want
to
then
subscribe
to
it
so
we're
going
to
create
a
subscription
api
spec
that
will
try
to
standardize
at
least
for
the
protocols
that
don't
already
have
a
standardized
way
like,
for
example,
http.
How
do
you
actually
do
a
subscription
right?
G
How
do
you
tell
it
what
events
you
want?
What
filters
you
want
where
to
send
the
event
stuff
like
that
now
there
are
many
eventing
protocols
that
already
have
this
defined,
and
it
is
not
our
goal
to
reinvent
the
wheel
for
those
go
use
what's
already
defined,
but
for
things
like
http
for
web
hooks
and
stuff,
like
that,
every
producer
has
their
own
way
of
doing
it.
So
we're
trying
to
see
if
we
can
get
some
interability
around
that
and
finally
we're
also
looking
at
a
schema
registry.
G
This
was
created
because
one
of
the
properties
inside
cloud
events
is
a
pointer
to
the
schema
of
the
event
itself.
It's
an
optional
attribute
people
can
include
if
they
really
want
to.
But
what's
missing
is
the
definition
of
how
to
talk
to
schema
registries
right
because
normally,
when
you
get
when
you're,
given
the
url
to
a
schema,
your
natural
inclination
is
to
say:
okay,
how
do
I
do
it?
You
know
I'm
going
to
do
http
get
to
that.
G
Url
and
you'll
get
the
information
back
in
some
format,
but
there
really
isn't
a
standard
way
of
actually
talking
or
managing
schema
in
a
schema
registry
itself.
So
you
get
some
interability
not
just
on
the
reading
side,
but
on
the
creation
or
update
side
and
that's
what
the
schema
registry
is
looking
to
do.
Okay
in
terms
of
priorities,
I
would
say
probably
discovery
and
subscription
are
coming
first
and
schema
registry
lasts.
Just
because
I
think
more
interest
lies
in
these
two
as
of
today
and
that's
pretty
much
all.
G
D
Doug,
I
want
to
give
you
a
compliment
and
get
the
cloud
events
like
by
the
way
it's
a
great
presentation,
something
with
falco,
for
instance
with
cloud
events,
the
the
group
that
one
of
the
contributors
scott
nichols,
came
in
and
really
explained
it
and
the
way
that
it
could
be
used.
It's
super
super
for
useful
for
eventing
and,
like
you
can
trigger
things
like
he
built
a
cloud
events,
integration
for
falco
sidekick
that
will
trigger
like
based
on
a
rules
violation
to
multi
multi-cloud.
I
mean
it's,
it's
it's
really
really
cool.
D
G
E
If
there
is
one
there
yeah,
but
you
know
what
are
the
examples
of
fizz
without
the
context
of
serverless
right,
because
you
know
when
you
talk
about
aws,
lambda
or
azure
functions,
or
I
don't
know
cloud
run,
you
know
they
you
you,
what
are
the
apple
I
mean
it
seems
like
you
can't
have
one
without
the
other
for
any
kind
of
a
realistic
application.
Is
that
a
fair
assessment
or
incorrect?
Well.
G
G
I
think
if
you
try
to
step
back
and
look
at
it
from
a
purely
abstract
or
puristic
perspective,
and
I
think
that's
what
I
tried
to
lay
out
here
on
this
chart,
which
is
technically
a
function,
I
think,
to
a
lot
of
people.
If
you,
if
you
actually
try
to
draw
a
separation,
a
function
is
just
a
smaller
microservice
right,
that's
really
all
it
is,
and
so,
if
you,
if
all
you
have,
is
a
small
micro
service
well,
that
could
be
something
that
never
scales,
but
it's
still
a
function
right.
G
It's
only
when
you
add
in
at
least
to
me
some
of
the
management
around
it,
the
auto
scaling
the
scale
to
zero
zero
cost.
When
it's
not
running
that
to
me
is:
let's
make
it
serverless,
because
it's
about
not
managing
the
infrastructure
or
anything
else
that
goes
around
it,
because
so
so
go
back.
For
a
minute
to
the
function
side
right,
I
can
have
a
function
but
still
be
forced
to
manage
the
entire
bit
of
infrastructure
myself.
G
So
I
can
do
functions
on
kubernetes
today
and
that
works
just
fine
and
I
could
I
could
and
all
in
all
honesty
and
all
purity
say.
Yes,
that
is
a
function,
but
I
still
managing
all
the
infrastructure.
Myself
and
kubernetes
is
not
easy
to
use
for
a
novice
right.
So
no
one
in
the
right
mind
would
say:
kubernetes
is
serverless,
but
does
the
support
functions
sure
it's
just
an
application?
It's
just
a
part.
So.
E
Actually,
that
might
also
be
helpful
for
this
group
I
think,
is-
and
maybe
it's
a
good
tier
for
arana,
to
talk
about
the
serverless
work
is,
but
when
you
talk
about
a
function
in
the
context
of
kubernetes,
but
you
still
have
something
that
it
needs
to
run
in
and
the
context
is
a
container
so
you're
you,
you
are,
how
do
you
say
abstracting
away
the
delivery
transport?
Is
that
fair?
E
Is
that
the
word
to
use
because
you
still
have
a
function
and
a
function
is
always
a
function,
but
it
has
to
run
in
some
context
and
in
the
context
of
kubernetes
it's
a
container,
but
in
the
context
of
lambdas
it
is
whatever
lambda
is.
I
mean,
however,
they
actually
facilitated.
Maybe
containers
in
the
back
end
is
that
the
right
way
of
looking
at
it?
So
you
are
not
you
don't
think
about
the
the
running
environment,
but
when
you
talk
about
functions.
E
G
The
reason
I'm
struggling
is
because
I
I
think
the
answer
depends
on
your
perspective.
I
think
I
think
some
people
would
agree
with
you
that
even
in
a
functioning
environment
you
should
probably
you
should
not
have
to
think
about
the
hosting
side
of
it
right
for
me
personally,
I
I'm
not
sure
I
would
agree
right.
I
I
would
still
say
it
is
perfectly
legal
for
someone
to
claim
that
they
are
a
faz
but
still
require
you
to
understand
the
infrastructure
in
some
way.
G
I
could
be
wrong
right.
It's
just
my
perspective,
but
I
think
I
think
it
depends
on
how
you're
looking
at
it,
because
I
think,
if
you're
going
to
claim
that
a
function
is
going
to
hide
the
the
infrastructure
from
you,
then
I
think
you're,
probably
in
the
mindset
that
says
functions
and
serverless
are
almost
one
in
the
same,
and
I
think
it's
a
valid
way
to
approach
it.
G
G
G
You
almost
have
to
assume
that
they're
stateless
at
the
end
of
the
day.
Now
that
doesn't
mean
they
couldn't
persist,
something
because
you're
going
to
reuse
the
container.
So,
therefore
you
don't
have
to
reload
the
cache
every
time
and
stuff
like
that,
but
I
think
in
the
most
puristic
form,
I
think
serverless
is
supposed
to
be
stateless
as
well
right
without.
G
Well,
there's
two
different
ways
to
kind
of
perceive
your
question:
one
is
you're
you're,
making
a
distinction
between
functions
and
serverless
relative
to
the
code
itself
inside
the
application,
and
I'm
not
sure
you
should
make
it.
You
draw
a
distinction
there
right.
So,
if
something's
going
to
be
stateless
in
functions,
that
same
bit
of
code
is
probably
going
to
be
stateless
and
serverless,
and
vice
versa
right,
so
I
don't
think
the
difference
between
faz
versus
serverless
changes
the
deployment
artifact
itself.
G
Okay,
now
relative
to
state,
though
I
I
my
mind,
is
still
stuck
in
this
mode
of
yes,
you
may
need
to
persist
things
between
invocation
of
either
your
function
or
your
serverless
function,
but
that's
not
typically
saved
inside
the
the
running
artifact
itself.
Those
are
typically
saved
in
some
remote
system,
some
sort
of
database
or
even
just
a
disk.
G
That's
on
a
shared
volume,
or
something
like
that
right,
because
you
want
to
be
able
to
scale
down
and
still
persist
that
information
and,
more
importantly,
you
also
want
to
be
able
to
scale
up
so
that
multiple
instances
can
share
that
data
right.
So
I
I
really
think
that
that
the
the
the
faz
versus
serverless
aspect-
I
don't
think
plays
into
the
stateful
versus
stateless
thing.
I
think
that's
a
separate
side,
discussion,
okay,.
I
G
I
said
I
don't
think
that
doesn't
mean
you
can't
do
optimizations
right.
So,
for
example,
there
are
some
environments
where
they
scale
or
the
function
when
it's
not
being
used
scales
down
within
milliseconds
persistent
and
that
you
know
that
that
that's
valid,
but
some
sort
of
persistence
stored
there
inside
the
container
doesn't
make
a
whole
lot
of
sense.
G
But
if
your
runtime
environment
or
your
your
container
lives
on
for
maybe
a
minute
before
it
gets
scaled
down,
then
maybe
it
makes
sense
to
have
a
little
bit
of
persistent
store
between
invocations
or
between
incoming
events.
Because
that
way,
as
I
said,
you
don't
want
to
initially
repopulate
your
cache
or
maybe
you
can
do
some
optimizations
and
and
you
don't
have
to
go
back
to
the
database
every
time,
because,
maybe
that's
expensive
right,
you
can
do
some
optimizations
there,
but
that's
strictly
or
that's
usually
just
for
optimization
purposes.
C
C
So
kind
of
I
have
two
kind
of
security
perspective
questions.
One
is
related
to
cloud
events,
the
other
ones.
We
did
to
kind
of
generically
the
programming
model,
but
it
seems,
like
you
know
now
that
you're,
you
kind
of
when
I
see
this.
It
reminds
me
a
bit
of
like
you
know,
or
what's
top
10
in
the
series
of
things
there
right,
it
seems
like
there
are
certain
considerations
that
also
need
to
kind
of
have
best
practices
off
with
regards
to
you
know.
C
The
metadata
they're,
including
over
here,
is
that
is
that
something
that
you
think
needs
exploration,
for
example
over
here.
Is
there
any
restrictions
from
the
sauce?
The
id
are
these
confidential
pieces
of
information,
and
things
like
that?
Do
you
think
it
is
an
area
that
needs
to
be
exploded
a
little
bit
more.
G
So
the
the
the
cloud
events
working
group
very
purposely
avoided
anything
having
to
do
with
security.
Two
reasons:
one
is
it's
a
very,
very
a
complicated
topic.
There
are
many
different
ways
to
get
it
done.
There
are
already
existing
standards
out
there
that
tell
you.
How
do
you?
You
can
secure
messages
already
and
we
didn't
want
to
reinvent
the
wheel,
and
nor
did
we
want
to
necessarily
pick
a
winner
right,
so
we
figured
okay,
you
can
layer
on
security
and
signing
and
encryption
and
all
the
other
stuff.
G
You
know
yourself
and
but
the
other
really
really
big
reason
we
decided
not
to
touch.
It
is
because
we
realized
that
the
minute
we
touched
it
we'd,
never
ship
a
spec
it
would.
We
would
get
bogged
down
in
trying
to
make
those
those
answer,
those
questions
that
that
we
would
we
would
be
there
for
years,
trying
to
settle
it,
and
we
wanted
to
avoid
some
of
this.
G
People
can
layer
it
on
themselves
later
and
we
can
always
look
at
it
again
later
and
in
fact,
just
recently,
somebody
in
our
working
group
proposed
a
an
extension
mechanism
to
sign
the
cloud
events
right
and
so
we
are
going
to
be.
You
know
it's
a
valid,
it's
a
valid
proposal,
so
we're
going
to
be
looking
at
it.
We
may
very
well
adopt
it
or
we
may
reject
it
and
say
no
sorry
we're
still
not
going
to
touch
security.
We
don't
know,
but
it
is
definitely
something
that
people
will
want
us
to
explore.
C
G
We're
already
an
incubator
status,
so
there's
you
know,
there's
sandbox
incubator
and
then
what
is
what's
the
final
one,
graduation
graduated?
Thank
you
graduate
yeah,
yeah
yeah,
so
we're
an
incubator
stage
and
I
got
honest
with
you.
I
haven't
gone
back
in
a
while
to
check
and
see
what
graduated
status
means
in
terms
of
what
the
criteria
is.
Maybe
we
should
be
going
for
graduated
status.
I
just
I
can't
remember
what
the
criteria
is
yet,
but
to
be
honest,
the
status
doesn't
mean
a
whole
lot
to
us.
C
G
C
So
so
the
other
thought
that
I
had
was
like
moving
towards
serverless.
A
lot
of
the
traditional
security
controls
can
be
done
in
the
way
that
people
are
used
to
do
you
see
kind
of.
Is
that
being
asked
for
certain
I
mean
exposing
certain
inner
workings
of
it
or
creating
different
abstractions
so
that
people
can
control.
G
Yeah
just
make
sure
I
understand
the
question.
This
is
more
generic
question
about
serverless
and
not
about
cloud
events
in
particular
right,
yeah,
okay,
yeah,
okay,
so
I
think
in
general,
there
probably
is
a
desire
for
some
level
of
internal
ability
in
the
serverless
runtime
itself,
whether
it's
the
security
aspects
that
you're
talking
about
or
whether
it's
something
as
simple
as
hey.
Can
we
at
least
standardize
on
what
your
function
signatures?
G
Look
like
right,
there's
always
good
people
that
want
that,
and
we've
had
lots
of
conversations
about
getting
into
those
types
of
topics,
but
we
we've
kind
of
shied
away
from
that
for
the
same
reason
that
we
landed
on
cloud
events,
the
minute
you
do
that
it's
going
to
get
very,
very
political,
because
people
have
existing
things
and
asking
them
to
change
it.
It's
going
to
be
a
real
nightmare,
so
I
think
the
best
way
to
answer
your
question
is
we
may
eventually
get
there,
but
I
think
it's
going
to
take
some
time.
G
In
particular,
I
think
we
need
to
wait
until
the
serverless
working
group
and
the
cncf
has
had
more
success
stories.
Put
it
that
way
to
show
that
we're
not
just
creating
things
out
of
the
blue.
We
are
not
just
trying
to
take
one
one
vendor
solution
or
ram
it
down
everybody's
throat,
but
we
actually
have
a
success
path
or
success
story.
F
G
Short
answer
is
no.
I
haven't
heard
that
topic
come
up
as
a
possible
work
item.
Yet
if
you
could
actually,
if
you
think,
that's
an
area
of
interest,
if
you
can
send
me
a
note
or
something
just
give
me
a
little
more
description
in
terms
of
what
that
area
is,
I
can
definitely
stick
it
into
the
backlog
of
potential
things
to
look
at
in
the
future.
You
know
we're
always
looking
for
new
ideas.
F
Sure,
because
I'm
both
both
in
the
build
and
run
phase-
and
I
think
there
there
are
visibility
and
controls
that
are
needed,
especially
in
regulatory
environments.
Imagine
you're
updating,
stock
prices
or
something
using
functions.
There
is
auditability
requirements
that
financial
organizations
have
to
meet,
so
we're
just
wondering
from
that
perspective.
F
G
G
G
Someone
says:
hey,
you
know
what
I'm
going
to
create
the
one
event
to
rule
them
all,
and
it's
going
to
have
all
the
metadata
you
could
possibly
want,
and
it's
all
going
to
be
a
standardized
format
and
that's
all
wonderful
and
we've
had
a
gazillion
of
those
right
and
so
the
idea
of
trying
to
force
one
particular
schema
on
everybody.
Even
if
it's
in
one
domain
is
a
challenge
right.
Let
that
domain,
let
those
domain
experts
be
the
ones
to
do
that
right.
G
So
if
it's,
if
it's
about
one
particular
type
of
government,
compliance
or
regulation
kind
of
thing,
let
those
folks
who
are
experts
in
that
go
off
and
do
that
if
they
want
from
the
from
our
perspective
as
of
today,
anyway,
we
we
tend
to
focus
more
on
the
the
abstract
solutions.
You
know
just
how
do
you
get
that
specific
payload,
whether
it's
standardized
or
not,
from
point
a
to
point
b
right?
So
well,
I'm
not
saying
it's
not
possible
for
us
to
one
day
say:
hey
look.
This
is
just
a
big
problem.
G
F
B
B
D
B
B
G
Yeah,
so
if
I
understand
what
you're
saying
there
correctly,
what
I
think
you're
describing
is
more
like
some
sort
of
hook
mechanism,
whether
it's
an
inbound
or
outbound,
hook,
thingy
on
a
particular
implementation
of
a
serverless
framework
or
whatever
framework
you're
using
to
host
your
application,
and
I
can
definitely
see
value
in
that.
The
only
reason
I'm
hesitating
is
because,
up
until
now,
the
serverless
working
group
has,
for
the
most
part,
been
focused
on
writing.
G
Specs,
not
implementations
right,
so
we
obviously
have
sdks,
but
those
are
sdks
around
the
specs
themselves
and
they
help
to
prove
the
spec
out
and
stuff
like
that.
But
so
far
the
working
group
has
not
necessarily
said
we're
going
to
go
off
and
create
a
new
project
whose
sole
purpose
in
life
is
to
write
code
right
and
that's
why
I'm
a
little
hesitant
to
say
yeah,
hey.
G
B
J
G
None
better
than
brought
up
is
part
of
the
working
group
itself.
No
because,
as
I
said
for
the
most
part,
we
kind
of
stay
out
of
the
implementation
of
these
things.
Okay,
and
if
there
were
issues
as
part
of
the
sdk
development,
I'm
personally
not
aware
of
them.
I
would
like
to
be
honest.
I
I'm
not
too
heavily
involved
in
the
sdk
side
of
the
house.
J
E
Actually,
I'm
not
sure
if
maybe
I
lost
an
extended
extension
of
that
question
to
magnus
is,
I
think,
where
I
look
at
a
security
implication
as
of
course
it's
still
code.
You
have
a
lot
of
open
source
packages
that
you're
building
on
top
of
and
obviously
there
is
a
need
to
have
visibility
into
the
vulnerability
posture
and
then
those
go
back
into
compliance
kind
of
regulations
and
having
visibility
to
make
sure
those
are
being
addressed
as
well.
E
E
Great
well
doug,
thank
you
so
much.
This
was
a
fabulous
presentation.
I
think
you
know
it
really
clarified
some
of
the
nuances
for
us,
as
we
think
about.
I
know
that
and
just
for
the
broader
team
you
know,
arana
is
leading
an
effort
to
talk
about.
You
know
the
security
in
the
context
of
serverless,
so
this
is
incredibly
helpful
and
hopefully
we
can
lean
on
you
for
your
expertise
as
we
progress
through
that
project
as
well
sure,
and
thanks
for
having
me,
I
really
appreciate
it.
Thank
you.