►
From YouTube: CNCF SIG Security 2020-07-15
Description
CNCF SIG Security 2020-07-15
C
D
E
E
B
B
B
B
Actually,
you
know
injecting
security.
How
do
you
think
about
security
as
you're
building
out
large
horizontally
scaled
applications,
microservices
and
as
we
know
that
these
are
highly
ephrmel?
So
how
do
they?
How
do
they
need
to
think
about
the
security
landscape
and
how
do
they
appropriately
inject
security
throughout
the
entire
life
cycle,
right
from
build,
deploy
to
run
and
it
the
one
of
the
other
goals
is
also
to
provide
operators
with
a
blueprint
in
order
to
operationalize
security.
You
know
how
do
they
think
about
it?
What
are
the
missing
pieces?
B
B
But
how
do
you
now
inject
and
incorporate
security
right
through
the
development
and
the
deployment
phases
and
to
actually
provide
this
as
a
reference
to
the
community
for
security
for
cloud
native
workloads?
So
that's
the
objective
and
the
benefit
I
don't
have
too
many
slides
so
feel
free
to
interject.
If
you
have
any
questions
comments,
suggestions
as
we
go
through
this
may
I
throw
on.
E
E
What
would
you
say
is,
I
guess,
the
the
most
practical
or
pragmatic
element
that
gets
people
to
treat
it
as
this
is
something
we
can
integrate
as
we
go
without
really
many
pain,
points
or
loss
of
project
velocity
versus,
as
you
said,
bolted
on
at
the
end
sort
of
thing
as
an
afterthought,
because
there
isn't
time
for
it.
What
do
you
think's?
The
key
part
of
what
you're
describing
here
that
encourages
voluntary
adoption.
B
So
obviously
it's
I
mean
the
the
obviously.
The
current
problem
is
the
you
know.
We
always
talk
about
it.
Where
you
know,
security
and
devops
are
not
meeting
either
way
right
and
I
think
that's.
Firstly,
that's
that
and
just
we're
recognizing
that's
the
fundamental
problem,
and
that's
also
because
you
know
security
teams
are
so
often
brought
in
at
the
flag
end
of
projects
or
you
know
so,
once
all
the
development,
all
the
everything
is
done
and
then
security
teams
are
made
aware
of
it
and
saying
hey
now.
B
You
can
maybe
just
give
me
a
stamp
of
approval,
as
I
really
really
need
to
deploy
this
application
into
production
and
that's
obviously
the
reason
for
a
lot
of
this
friction.
And
then
there
is
this
concept
that
you
know:
security
needs
to
be
embedded,
but
then
devops
teams
don't
think
that
you
have
the
right
tools
and
the
capabilities
for
them
to
really
adopt
with
their
with
their
need
for
agility,
and
then
security
doesn't
think
that
devops
knows
how
to
get
security
right
as
as
a
developer
and
as
a
security
person
myself.
B
B
So
this
actually
fosters
meets
the
devops
and
the
developers
where
they
are
so
providing
them.
The
right
tools
and
the
visibility
and
I'll
talk
about
what
that
really
really
means
in
the
next
slide,
but
you
know
when
you're,
making
a
pull
request.
You
know
make
sure
that
your
security
debt
is
not
continuously
increasing
unit
testing
system
testing
integration
texting
is
fundamental.
B
Let's
make
security
testing
fundamental
so
putting
in
together
the
the
these
processes
and
and
showcasing
the
ideal
state
and
empowering
devops
with
the
right
tools
really
really
really
goes
a
long
way
in
ensuring
that
they
adopt
those
capabilities
and
incorporate
security
throughout
the
process.
Does
that
did
that
answer
your
question
a
little
bit
yup!
That's.
B
Sounds
good
sure
thing,
so
what
I
you
know
put
together
is
this
concept
of
the
the
life
cycle
is
so
important
when
you
talk
about
cloud
native
applications
and
deployments
right,
which
is
you
have
the
development
phase
once
your
artifacts
have
been
developed,
you
know
you
go
through
the
build
phase
these
arctic
artifacts
now
are
built
in
you
know.
For
for
our
purposes,
for
example,
the
form
factor
is
container
images.
You
go
through
building
all
the
different
layers,
pulling
all
your
dependencies.
B
You
build
your
container
image,
push
it
into
a
container
registry
and
then
go
through
a
whole
bunch
of
testing,
so
I've
I've
identified
four
distinct
phases,
which
I
think
we'll
all
agree
with,
which
is
develop,
build,
deploy
and
then
obviously
the
run
phase,
and
what
I've
tried
to
do
is
in
this
particular
view.
I
think
this
is
the
the
best
practices
view
and
then
the
next
slide
talks
about
an
operationalizing
view
to
say
that
you
know
here's
how
your
code
is
being
developed.
B
B
So,
for
example,
you
know
we've
seen
even
in
my
day-to-day
that
you
know
as
we
are
developing
so
many
new
automation,
templates
and
capabilities.
You
know
once
again,
there
are
so
many
new
services
that
we're
leveraging.
We
don't
really
really
know
all
the
the
high
value
security
controls
that
you
need
to
be
enforcing
and
applying
right.
B
So
that's
the
point
that
you
can
do
so
once
those
things
are
validated
and
if
you
let's
say,
for
example,
it
goes
through
your
validation
and
your
policies
process
in
the
developing
the
pull
request,
phase
your
code
gets
checked
into
your
source
code
management
and
then
in
the
build
phase,
is
when
you
apply
the
next
set
of
capabilities,
and
I'm
going
to
talk
about
this
more
from
an
operationalization
aspect
in
the
next
slide.
But
the
point
of
this
slide
is
say,
for
example,
in
the
build
phase,
and
I
also
want
to
highlight
the
fact.
B
Hopefully
it's
evident
by
now
the
light
blue
boxes
are
all
the
security
capabilities
right
that
you
can
enforce
at
all
the
different
phases
of
the
development
and
the
deployment
pipeline.
So
in
the
the
light
blue
is
you
know,
once
your
code
has
been
checked,
you'll
obviously
want
to
run
it
through
your
static
checkers.
You
want
to
be
able
to
perform
the
vulnerability
scans.
You
want
to
be
able
to
do
the
image
scanning
infrastructure
as
code
scanning,
as
well
as
your
kubernetes,
and
then
they
also.
B
The
notion
here
also
encompasses
that
you
know
developers
need
to
move
fast,
so
you
probably
have
a
loser
set
of
policy
security
policies
that
you
want
to
enforce
at
the
developed
phase.
But
then,
when
you
go
into
the
build
phase,
it's
maybe
it's
now
you're
going
from
the
the
dev
environment
to
your
test
environment
in
your
test
environment,
you
have
stricter
policies
that
you
want
to
apply,
so
you
have
the
capability
of
applying
a
different
set
of
stricter,
potentially
stricter
policies,
the
build
phase.
B
You
know
no
code
goes
into
production
without
going
through
significant,
well
unit
system
integration
tests,
and
the
point
theme
also
here
is
that
you
know
we
want
security
testing
to
be
a
mainstay
as
part
of
that
that
that
process
as
well
so
once
you've
done
your
application
testing.
So
if
you
have
failures,
what
happens?
Is
it
gets
pushed
back
developers
look
into
it
fix
your
bugs
fix
your
issues,
and
it
goes
back
through
the
process.
B
Similarly,
we
want
to
apply
the
same
rigor
to
security
testing,
where
you
want
to
scan
your
amis,
your
container
images,
your
manifest
and
your
infrastructure
as
code
templates
based
on
vulnerabilities
config
and
compliance
scanning
capabilities.
A
simple
example,
just
maybe
I
shouldn't
make
any
assumptions
just
to
give
you
context
as
to
what
the
compliance
scanning,
for
example,
is
right
when
we
want
to
deploy
a
a
cluster,
for
example,
in
gke,
for
example,
you
know
just
making
sure
that
your
your
kubernetes
api
server,
for
example,
is
not
exposed.
B
You
know
stuff
like
that,
if
you're
having
a
database
make
sure
that
your
database
is
encrypted,
you're,
making
sure
that
your
keys
are
secured
properly,
make
sure
that
the
database
is
not
exposed
to
the
internet.
You
know
all
those
kinds
of
checks
and
with
this
new
cloud
native
pattern
and
paradigm,
we
have
an
unprecedented
ability
to
catch
it
even
before
all
of
these
assets
are
deployed
into
the
runtime
and
that's
the
point
right
and
we
can
fix
it,
so
it
tremendously
improves
the
security
posture
of
applications
that
get
deployed
in
production.
B
If
you
would
right
so
in
the
deploy
phase,
you
have
the
ability
to
actually
apply
a
lot
of
these
security,
rigor,
testing
and
approaches
and
then
obviously,
in
the
run
phase,
which
is
either
in
your
cloud
or
your
on-prem
across
different
asset
classes.
If
you
will,
which
is
serverless
containers
host
vms,
you
need
network
security,
you
need
runtime
security.
B
So,
for
example,
the
code
commit
is
pretty
much
your
develop
phase
and
then
your
build
and
deploy
is
your
ci
cd
pipeline
and
then,
of
course,
the
run
phase
is
pretty
much
your
infrastructure,
iis
paths
and
cash
capabilities,
and
the
fact
that
you
also
want
to
have
operate
up
your
policies
across
all
these
three
or
four
different
phases
of
the
application
deployment
life
cycle
so
and
then
I'd
love
to
have
a
discussion.
I
mean
this
is
just
a
preliminary.
B
I
wanted
to
put
this
out
there,
but
I'll
talk
about
that
more
and
once
again,
if
you
have
any
questions,
please
feel
free
to
stop
me,
but
the
next
slide
that
I
wanted
to
talk
about
is
now.
How
does
how
do
operators
actually
think
about
operationalizing?
So
this
is
more
of
the
operational
view.
If
you
will
to
you,
know,
take
a
lot
of
those
components
that
we
talked
about,
but
then
how
do
you
build
and
integrate
and
incorporate
all
of
these
different
concepts
and
capabilities
and
tools
into
your
entire
development
process?
B
Now
you
have
the
ability
to
actually
have
a
commit
pre-hooks
where
you
can
actually
check,
and
we
talked
about
all
the
different
types
of
scans
that
are
possible
to
ensure
that
these
are
best
practices,
security
controls
that
now
you
can
apply
even
before
your
infrastructure
is
running,
so
you
can
catch.
All
of
these
capabilities
and
flag
it
and
make
the
appropriate
changes,
and
then
I
also
wanted
to
highlight
the
fact
that
there
are
so
many
different
capabilities
right
so,
for
example,
with
the
advent
of
open
source,
tooling,
there's
so
much
of
open
source.
B
I've
never
worked
at
a
place
where
everyone
actually
had
a
perfect
visibility
into
all
the
open
source,
tooling,
the
libraries
that
they
have
all
the
licensing
implications
there
are
for
both
the
the
the
library,
as
well
as,
ultimately,
their
own
application.
So
the
source
code,
composition,
analysis
capabilities,
play
a
very
important
role
and
then
you
actually
now
run
through
all
your
security
capabilities,
which
is
defined
and
then
with
the
development
environment
policies.
Right
as
I
talked
about
it,
so
you
do
your
static
analysis.
B
You
do
your
vulnerability
scans,
you
do
your
iac
scans
and
the
kubernetes
kubernetes
manifest
scans
and
then
so.
Security
is
a
first-class
citizen.
You
want
to
be
able.
These
are
the
best
practices
I
mean
these
are
the
best
practice
steps
that
you
need
to
execute
if
they're
evaluated,
if
any
failure,
if
it
results
in
a
failure,
you
go
back
to
the
drawing
board.
Go
back
and
then
so
those
thing
there's
a
constant
feedback
loop
for
the
developer,
they're
able
to
fix
what
issues
they
now.
B
But
once
again,
I
think
the
underlying
theme
also
is
we.
We
can't
expect
developers
and
devops
folks
to
be
security
experts,
but
now,
with
the
right
tooling
and
the
capabilities
you
have
contextualized
information
on
for
them
to
actually
take
remedial
action,
and
if
everything
is
checks
out,
it
passes,
it
gets
checked
into
your
source
code
management
system,
and
then
it
goes
into
the
your
build.
So
let's
go
ahead
and
build
all
these
different
artifacts.
It
goes
and
fetches
all
the
dependencies.
B
It
goes
through
and
builds
your
container
images
or
amis
or
serverless
images,
and
then
your
build
artifacts
are
now
checked
in,
for
example,
into
your
catalog
virtual
machine,
catalogs,
container
registries,
server
registries
and
then
the
next
step
is
now.
This
is
where,
which
is
where
I
would
love
input
from
the
folks
in
in
in
our
group
here
where
now
I
want
to
showcase
how
we
want
to
incorporate
best
practices
in
terms
of
signing
images.
We
want
to
make
sure
all
your
images
are
signed.
B
So
then,
once
those
images
are
all
signed,
then
you
go
into
your
application
testing
that
we
talked
about,
which
is
system
and
integration
tests.
There's
a
failure
go
back
to
the
drawing
board
and
then
the
next
step
is
to
perform
your
scans
with
your
test
environment
policies.
These
are
potentially
stricter
policies
right,
so
you
make
sure
that
your
images
are
always
scanned
based
on
policies,
make
sure
that
all
your
security
controls
are
being
applied
accurately.
You
know,
for
example,
the
nist
800-190.
B
You
know
this
is
an
opportunity
to
actually
bring
that
in
into
your
build
pipeline
and
validate
that
your
your,
your
kubernetes
or
your
container
orchestration
platform
is
appropriately
secured.
Your
your,
for
example,
you're
not
running
your
applications
as
a
root
user.
You
don't
you're,
not
you,
don't
have
you're
not
running
as
a
as
a
privileged
container.
B
It's
just
so
many
different
things
that
you
know
now
we
can
actually
catch
and
actually
test
for
in
your
build
pipeline
and
then
once
this
is
passed
through,
then
we
want
to
actually
now
you
know,
for
example.
This
is
where
I
want
to
bring
it
back
to
the
vision
that
I
have
in
terms
of
let's
talk
about
the
internal
project
right
where
you're
talking
about
software
supply,
chain
security.
So
this
concept
of
this
controller
and
how
it
can
actually
validate
that
your
images
have
been
signed.
B
There
has
not
been
any
kind
of
modification
or
or
changing,
of
your
binaries
and
your
images
etc.
But
you
have
the
opportunity
to
inject
these
policies
and
these
capabilities
at
different
parts
of
the
deployment
pipeline.
And
then
you
go
into
the
deployment
phase
where
there
now
you
can
actually
incorporate
these
steps
to
validate
the
image,
the
hash,
the
signatures,
etc,
enforce
certain
kinds
of
using
admission
controllers,
potentially
runtime
image
policies,
and
then
your
runtime
compliance
policies.
B
And
then
there
are
three
different
capabilities
yet
again
and
as
you
can
see,
which
is
the
configuration,
the
appropriate
security
of
the
container
orchestration
platform,
then
the
appropriate
configuration
for
your
the
the
hosts,
as
well
as
the
pods
right.
So
that's
the
kind
of
representation
that
I've
tried
to
afford
here,
and
you
want
to
make
sure
that
you
have
the
right
policies.
There
are
so
many
best
practices,
and
this
goes
back
to
now
the
platforms
that
we
work
in,
whether
it's
kubernetes
or
openshift,
or
one
of
the
cloud
vendor
managed
platforms.
B
It's
still
a
shared
responsibility
model,
so
you
have
to
they
give
you
the
capability,
so
you
have
to
make
sure
that
they
are
enforcing
the
right
capabilities.
So,
for
example,
the
nist
800-190
is
a
special
publication
that
talks
about
container
and
security
for
container
and
application
containers.
So
there
is
a
whole
bunch
of
security
controls.
So
you
need
to
make
sure
that
you
are
applying
those
best
practices
in
your
for
your
container
orchestration
platform
and
and
there's
so
many
different.
B
As
I
talked
about
give
you
examples
about
privilege,
containers,
etc
so,
and
we
need
to
make
sure
that
our
operators
are
aware
of
them
and
then
make
sure
that
they
need
to
take
steps
to
actually
enforce
that.
So
here's
how
here's
providing
an
ability
to
showcase
how
they
can
they
can
think
about
enforcing
those
kinds
of
best
practices.
B
And
then
you
talk
about
the
hosts,
make
sure
that
the
hosts
are
appropriately
secured
and
configured
based
on
your
compliance
controls.
And
then
you
also,
we
need
to
make
sure
that
those
hosts
are
appropriately
locked
down
in
terms
of
either
network
policies
or
network
security,
make
sure
that
they're
not
making
unsanctioned
access
to
malicious
domains
etc.
And
then
we
talk
about
pods
right.
So
you
have
to
think
about
container
and
securities.
E
Quick
question
vinay.
I
was
wondering
with
respect
to
I
guess
one
of
the
final
deliverables
like
if
this
was
to
be
seen
through
to
fruition.
What
do
you
see
as
the
ultimate
deliverable
like?
Is
it
a
large,
heavily
documented,
slash,
well-designed
documentation,
wiki
kind
of
like
say
the
kubernetes
documentation?
Does
it
have
specific
examples
without
necessarily
advertising
or
advocating
a
specific
implementation
like
here's,
how
you
do
future
xyz
with
git
lab
with
jenkins
or
some
other
pieces
like
that?
Is
it
meant
to
be
a
broad
documentation,
project
and
b?
E
Is
it
something
for
lack
of
a
better
term,
somewhat
democratized,
in
the
sense
that
the
request
is
that
once
it's
in
the
right
direction
and
it
has
enough
maturity,
cncf
officially
adopts
it
and
endorses
it,
for
example?
So
I
guess
what
are
the
desired
implementation
outcomes?
Rough
ballpark?
I
know
that's
always
down
the
road
and
be
what's
the
intent
in
terms
of
I
guess
audience
and
promoting
it.
B
B
Concur
yeah
so,
and
that's
the
sense
right.
So
these
are
very,
very
complex
projects,
so
we
want
to
actually
help
our
operators
and
our
users
ultimate
users
along
the
way
in
in
helping
them
understand
how
they
can
wrap
their
heads
around
it,
how
they
can
approach
it,
how
they
should
be
thinking
about
it,
how
they
can
adopt
it
right.
B
So
the
first
goal
is
to
give
them
some
kind
of
a
sense
as
to
how
they
can
what
are
all
the
different
components
that
they
need
to
be
indexing
as
they're,
putting
together
a
plan,
for
you
know,
fundamentally
their
cicd
pipelines
for
cloud
native
applications.
But
then
I
I
think
we
would
all
agree
that
we
don't
want
to
be.
Let
security
be
a
bolted
on
capability
right,
so
we
want
to
constantly
advocate
that
security
needs
to
be
built
in.
B
So
we
want
to
highlight
all
the
different
generically
speaking
the
security
capabilities
that
needs
to
be
incorporated
into
this
entire
devops
and
devops
process
right.
So
so
some
kind
of
a
consumable
document
that
gives
them
a
bird's
eye
view
in
terms
of
what
are
all
the
different
components.
And
then
how
can
you
operationalize
and
then,
if,
if,
if,
if
this
group
feels
like,
we
can
take
it
a
step
further,
which
I
think
we
could
in
one
example
of
that
is
to
actually
say
how
do
we
take
harbor?
How
do
we
take
in
total?
B
How
do
we
take
tough?
How
do
we
take?
I
don't
know
certain
other
capabilities,
binary
authorization,
all
those
different
capabilities
and
and
then
take
a
generic
framework
and
make
it
a
specific
use
case
right.
So
I
think
there's
potential
to
take
it
further
and
make
it
a
little
bit
more
specific,
but
the
initial
goal
is
to
provide
like
a
totally
generic
agnostic
platform
and
potentially
portraying
the
ideal
state.
G
G
Perhaps
from
the
outset
we
might
have-
and
I
just
want
to
say
that
I
think
it
would
be
good
for
us
to
all
like
for
you
to
to
join
those
conversations
along
with
others
that
are
interested
in
this,
because
I
think
now
that
we're
sort
of
you
know
three
times
independently,
seeing
the
need
for
the
same
thing
and
taking
what
on
the
surface,
looks
like.
It
has
some
very
mild
differences,
but
I
think
underneath
really
doesn't
you
know,
is
mostly
the
same
way
of
presenting
the
same
information.
E
G
G
I
think
we've
been
sort
of
reusing
this.
This
sig
security
chairs
and
tech
leads
channel
that
we
talk
on
sometimes
for
some
of
that
discussion,
especially
since
we've
really
only
had
one
initial
meeting.
So
maybe
this
is
maybe
this
is
something
where
we
need
to
create
a
new
channel
and
open
it,
and
let
people
come
in
and
discuss
or
open
the
open,
the
existing
tech
landscape
channel,
and
do
that.
C
So
the
white
paper
is
intended
to
be
that
think
of
it
as
the
landscape
and
the
items
that
denae
has
been
presenting
more
at
a
high
level,
c-suite
executive
overview,
a
better
understanding
for
a
technology
officer
or
assisto
to
get
a
more
get
clear
insight
into
what
cognitive
and
cognitive
security
is
and
how
that
intersects
with
their
development
life
cycle.
How
does
that
affect
their
organization's
ability
to
adopt
specific
cloud
products?
C
Where
should
they
be
focusing
some
of
their
resources?
And
some
of
the
conversations
that
we've
been
having
around
that
in
the
landscape?
Is
there
there's
overlap?
The
audiences
are
slightly
different,
but
a
lot
of
the
information
can
be
used
across
them.
So
with
the
white
paper
coming
at
it.
From
the
perspective,
we
have
all
of
these
stacks
or
ecosystems
associated
with
cognitive
practices.
C
C
Bringing
your
own
case
association,
what
does
that
stack
actually
look
like
and
then
there's
just
the
general
application
development
that
goes
into
all
of
that?
What
does
your
application
definition
look
like
and
everything
that
goes
into
it?
So
these
are
all
it's
essentially
the
culmination
of
the
problem
that
anybody
in
security
or
anybody
moving
having
and
we're
coming
at
it
from
a
bunch
of
different
angles,
either
from
the
top
down
or
from
the
bottom
up,
because
we've
realized
that
there
are
people
across
all
sections
of
the
community
that
don't
have
access
to
this
information.
I
Yeah,
I
have
a
couple
of
questions
one.
How
would
you
like
the
feedback
on
this?
Would
you
like
comments
on
the
document
or
do
you
want?
I
I
see
you
have
it
in
github.
How
would
you
prefer,
because
I
have
specific
comments
about
the
order
of
8
and
10?
I
don't
know
why
you
would
sign
if
signing
is
intended
as
a
symbol
of
immutability,
why
would
you
have
8
before
10
and
why
is
there
no
distribution
mechanism
in
place
to
maintain
integrity
of
the
supply
chain
better.
J
I
B
That's
a
great
point,
maybe
if
I
could
quickly
just
sound
out
on
that
and
I
think
some
I
just
opened
the
floor
up
and
I
know
I
just
wanted
to
have
input.
You
know.
I
think
the
value
add
for
this
group
to
be
able
to
advocate
for
one
of
these
kinds
of
reference
architecture.
Is
they
have
a
lot
of
thought,
leaders
and
subject
matter
experts
and
then
put
bringing
our
putting
our
heads
together
if
we
come
up
with
some
kind
of
an
accepted,
validated
paradigm?
That
goes
a
long
way
in
helping
operators
and
adopters.
B
You
know
have
confidence
that
they
can
adopt
this
kind
of
a
paradigm
which
which
which
which
which
could
give
some
kind
of
weight
given
from
given
the
fact
that
it's
been
coming
from
this
particular
group
right.
So
I
think
that's
the
value
I
see
in
in
collaborating
here
and
putting
something
out
from
to
answer
that
question
and
chase.
I
believe
you
wanted
to
say
something.
A
You
had
a
question
or
maybe
it's
a
comment
or
I
don't
know
funny
enough.
I
made
this
similar
diagram
just
in
the
last
few
months
for
similar
reasons.
Right
and
basically
this
is
very
difficult
to
conceptualize
and
then
without
some
kind
of
table,
conversation
piece
and
meeting
with
developers
and
other
stakeholders.
Just
within
my
organization
right,
you
just
need
a
thing
to
where
everybody
knows
that
you're
talking
about
number
seven
or
everybody
knows
you're
talking
about
number
six
and
without
having
you
know
this,
some
kind
of
infographic,
it's
virtually
impossible.
A
So
that's
my
experience,
but
then
the
and
it's
interesting.
I
think
it
was
just
news
that
there
were
kind
of
have
been
three
variants
of
recognizing
that
all
the
all
the
lego
pieces
are
dumped
on
the
table,
but
nobody's
really
laid
out
like
well.
If
you
do,
you
want
to
build
a
monster
truck
right,
it
has
wheels.
It
has
an
undercarriage
whatever
if
you
want
to
build
a
pirate
ship,
etc,
etc.
But
where
I
I'm
wondering
if
this
is
a
gap-
and
maybe
it's
an
intentional
hunter,
maybe.
K
A
A
I
think
I
put
in
the
notes
that
like
if,
if
cncf
were
a
company
right
and
and
was
trying
to
sell
all
this
stuff,
you're
really
talking
about
like
not
even
quite
a
product
roadmap
but
like
a
portfolio,
a
portfolio
view
of
like
how
all
the
components
could
fit
together
into
a
cohesive
whole.
But
whereas
this
is
is
generalized
right,
which
is
cool,
and
maybe
that's
the
thought
I
don't
know.
If
any,
I
wonder
if
any
of
the
three
variants
have
have
a
goal
of
saying
hey.
This
is
where
harbor
fits
in.
A
It
covers
some
items
of
seven.
You
know
these
points
that
cover
some
items
of.
I
don't
know
what
7
is
here.
I
can't
read
it,
but
my
point
is
just
like:
if
I'm
looking
at,
if
I
go
and
look
at
the
landscape
page
for
cncs,
all
I
see
are
150
boxes
and
they're
they're
grouped,
but
not
and
and
they're
sort
of
functionally
grouped
but
they're,
not
processed
or
workflow
oriented
in
that
way.
Right.
So
for
me
like,
if
I'm
looking
at
this,
I
want
to
use
it
as
a
translation
mechanism
for
like
half.
A
You
know.
I
need
one
thing
out
of
this
bucket
to
fit
in
here.
You
know,
but
it's
not
clear
at
least
to
me
how
the
buckets
translate
for
say.
Okay,
you
know
service
providers.
I
remember
is
a
category
on
the
landscape
pictorial,
but,
like
you
know,
where
does
that
some
of
them
are
past
providers
only
some
of
them
or
whatever?
That
would
be
an
easy
one
to
sort
of
draw
straight
lines
too.
B
I
think
just
quickly,
let's
highlight
that.
I
think
that
I
think
bullet
number
four,
so
that
was
one
of
the
potentially
the
next
steps
where
we
could
demonstrate
the
mapping
of
all
the
cncf,
not
all,
but
let's
say
as
appropriate.
You
know
based
on
industry,
where
I
like
what
you
said.
You
know,
building
this
monster
truck
or
I
don't
know
what
you
said
then
the
other
one
was
some
other,
maybe
a
spaceship
or
whatever
for
all
these
different.
B
I
think
that,
as
we
as
we
mature
through
these
things,
I
think
it
can
it's
applicable
across
all
of
them
and
to
actually
showcase
that
you
know
here
are
ways
in
which
you
can
put
these
lego
pieces
together.
To
your
point,
I
love
the
the
analogy
to
build
what
ultimately.
This
is
what
you
want
to
build,
but
here
are
the
pieces
that
you
need
and
here's
how
you
can
put
those
pieces
together
to
potentially
build
the
millennium
falcon,
for
example,.
B
Yeah,
no,
absolutely
thanks
for
that
justin.
So
I
because
when
I
I
was
on
on
a
call
where
I
think
you
and
brandon
talked
about
the
landscape
and-
and
I
think
maybe
I
got
something
a
little
different
out
of
it,
because
maybe
the
granularity
with
which
that
presentation
was
done.
I
think
I
was
trying
to
provide
a
little
bit
more
of
an
abstracted
view,
but
I
think
it
could
be
highly
complimentary
and
I'd
love
to
discuss
that
a
little
bit
more.
K
C
That
level
of
granularity
with
the
explanations
and
the
appropriate
context
for
somebody
doing
that
level
of
shopping,
where
the
white
paper
provides
that
higher
level
of
extraction
and
the
generalized
concepts
associated
with
it
so
you've
what
you've
presented
kind
of
bridges
that
a
little
bit
more
between
the
two
of
them
that
that's
something
that
the
tech
leads
and
the
chairs
discussed.
Last
week,
I
see.
E
Second,
I
just
want
to
jump
in
for
a
quick
second
to
ask
if
justin
cormack
had
a
update
or
something
he
wanted
to
present,
I
don't
see
any
specific
issues
or
pr's,
so
just
want
to
make
sure
he
has
a
window
of
opportunity.
If
there's
anything
you
need
to
bring
up.
If
not,
we
can
leave
the
remaining
15
minutes
for
today's
meeting
with
renee
and
everyone
else.
B
Yeah,
no,
I
actually
I'm
I'm.
I
just
wanted
to
conclude
with
one
last
few
comments.
You
know:
I'd
love
the
collaboration
yeah,
take
it
out
there,
so
if
we
can
collapse
all
these
into
some
other
ticket,
that
makes
more
sense
happy
to
do
that,
but
and
justin.
If
you
could
please
just
let
us
know
where
we
could
have
the
further
conversations
and
how
we
could
collapse.
These
efforts
that'll
be
great.
H
H
You
know
sort
of
approached
how
we
lead
in
line
everyone
together
has
struggled
with
now,
since
I've
been.
You
know
grinding
on
this
particular
problem
for
at
this
point
better
part
of
two
years.
You
know
I
I
want
to
level
set
a
little
bit
on.
You
know
how
we
got
here
and
and
make
sure
you
sort
of
manage
expectations
in
line
with
that.
H
So
you
know
the
founding
premise
of
you
know
the
safe
working
group
secure
access
for
everyone
that
eventually
became
security,
was,
you
know
really
to
you
know,
bring
together
the
points
of
view
around
security
that
were
underrepresented
in
the
constellation
of
projects
that
you
know
the
cloud
native
computing
foundation
brings
together
and
the
federation
of
corporate
interest
that
the
cncf
represents
for
better
for
worse.
We
start,
you
know
this
journey
with
a
lot
of
these
projects
and
they're
contributed.
H
H
H
You
know
really
really
hard,
because
we
aren't
actually
coming
from
a
point
in
time.
You
know
greenfield's
premise
we're
coming
from
you
know
this,
this
federation
of
all
these
parts
that
are
that
are
coming
together.
The
white
paper,
as
you
know,
kind
of.
Unfortunately,
you
know
it,
it's
tended,
you
know
towards
unified
theory.
You
know
kind
of
you
know
perspective
of,
of
what
this
world
is
and
and
how
it
should
work
in
security.
H
You
know,
I
think,
there's
a
great
opportunity
to
establish
robust
consensus
about
what
those
pillars
are.
You
know
just
in
sort
of
assessing
you
know
where
you
know
things
might
be
heading
in
in
this
articulation.
The
one
thing
that
I
I
can
sort
of
get
you
an
easy
no
on
is.
I
I
think
that
sig
security,
you
know,
defining
a
comprehensive
representation
of
how
this
is
all
implemented
for
all
the
use
cases
is
probably
outside
of
our
purview.
H
You
know
that
is
something
that
you
know.
I've
leaned
on
you
know
corporate
interest
in
the
past
organizations.
You
know
that
have
a
stake
in
the
game
you
know
could
align
to
all
right.
Here
are
the
pillars.
You
know
that
we
cover
and
and
how
we
implement,
that
that
is
in
my
mind,
you
know
when
we
complete
this
journey.
B
Yeah
no
totally
makes
sense,
then
I
mean
just
to
summarize.
I
think
my
my
goal
was
just
that.
I
I
see
this
and
I-
and
I
think
we
would
all
agree
to
this-
that
these
are
set
common
issues
that
we
see
on
a
day-to-day
basis
and
then,
just
to
I
thought
there
was
an
opportunity
just
to
put
out
like
a
very
very
generic
framework.
B
H
Right
and
that
journey
is
hard
and
and
it'll
take
a
lot,
and
you
know
there
are
all
kinds
of
ways
in
which
folks
kind
of
give
themselves
out.
You
know
either
they're
too
big
or
they're
too
large,
and
you
know
they'll
be
like
oh,
it
doesn't
apply
to
us
and
you
know
expressing
you
know
the
the
needs
you
know
that
need
to
be
addressed
will
help
folks
see
you
know.
Oh
okay,
that's
a
consideration.
I
haven't
addressed
and
I
can
you
know
move
on
rather
than
oh.
H
H
B
H
H
E
D
B
E
It's
tomatoes,
justin
capos,
will
be
justin.
Kapos
will
be
picking
up
on
the
alignment
of
the
or
at
least
bring
up
the
discussion
of
the
alignment
of
white
paper
and
the
communication
channels
used
for
that
and
what
vna
has
put
together
today,
as
well
as
the
landscape,
is
that
something
that
will
be
posted
in
the
security
slack
or
a
new
tickets
on
the
github
page.
G
Yeah
I'll
I'll
put
this
in
the
scmtf
in
the
slack
channel
I'll
just
put
a
link
to
this.
I
think
what
we'll
do
is
just
create
a
separate
channel,
because
we're
gonna
have
a
lot
of
conversation
in
here,
and
I
wanted
to
talk
with
brandon
first
to
figure
out.
If
we
want
to
reuse
the
existing
landscape
channel,
that
we
have
or
abandon
that
and
make
a
new
one.