►
From YouTube: CNCF SIG-Security Meeting - 2019-07-31
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
B
A
So
I've
been
traveling,
so
no
real
updates
from
me,
Sarah
Allen,
normally
facilitating
this
meeting.
Thank
you
that
one
of
the
co-chairs
of
the
word
school
group
and
thanks
Justin
for
helping
out
okay.
B
Great
so
I'm
Justin,
capos,
I,
I
guess
something
moderately
exciting
is
that
are
obtained,
which
is
the
automotive
version
of
tough
project?
Is
we've
now
finalized
all
the
legal
parts
and
we're
now
part
of
the
Linux
Foundation,
whose
joint
development
project-
and
we
also
did
some
other
things
with
officially
officially
officially
having
the
I
Triple
E
isto
standard
for
the
current
version
of
what
is
going
on
out
so
yeah?
That's
that's
been
one
of
the
major
things.
I've
done
all
right.
Why
don't?
We
have
sorry.
B
There's
something
called
the
joint
development
foundation
that
was
recently
as
maybe
a
month
or
so
ago
was
a
separate
effort,
but
kind
of
was
absorbed
into
the
Linux
Foundation.
In
some
way
there
was
I
think
maybe
the
the
question
that
isn't
being
asked:
here's:
why
isn't
it
part
of
a
GL
but
there's
AGL's,
not
home
for
specs
and
obtain
as
a
spec
with
the
reference
implementation,
that's
party
in
a
GL
called
actualize
ur.
B
So
as
a
result,
the
JTF
was
a
very
natural,
perfect
home
for
us
and
has
a
path
to
like
ISO,
standardization
and
other
things.
I
think
that
tough
and
other
projects
like
this
will
retain
their
current
homes,
but
may
also
benefit
from
some
resources
that
the
JTF
provides
like
ISO
standardization
in
the
future
and
I'm
happy
to
talk
more
about
that.
If
that
become
that's
of
interest
in
else,
but
maybe
we
can
either
do
that
after
the
check-in
or
take
it
off
on
either
one.
D
So
Brandon
hi
I'm
Brandon
from
IBM,
so
I've
been
working
on
the
emission
Krypton
stuff
because
of
the
recent
acquisition
for
it,
and
now
we
are
moving
to
open
ships,
so
we're
moving
a
lot
of
the
SAC
to
the
railhead
related
technologies.
So
we
have
implementations
of
the
encryptor
container
images
as
well
and
every
head.
Second,
then
we
are
going
to
collaborate
with
them
to
to
kind
of
push
it
upstream
as
well.
So
if
all
goes
well,
hopefully
we
will
see
this
in
both
maintainer.
D
B
F
G
Good
to
see
you
here,
yeah,
hey
so
I'm
Dan
Guido
from
trilobites
I
brought
Stephanie
Edwards.
Along
with
me.
We
just
wanted
to
drop
in,
introduce
ourselves
share
a
little
bit
about
what
happened
during
the
kubernetes
security
review
and
offer
to
help
with
other
projects
and
problems
that
you're
trying
to
solve.
I
J
Finally,
making
some
progress
on
issue
165
the
platform
implementer
persona
I,
try
to
chase
down
somebody
Google
that
apparently
wrote
use
cases
for
that
persona,
but
those
use
cases
weren't
quite
usable,
so
yeah
I'm,
making
some
progress
on
that
and
and
I
have
another
lead
here
at
Google.
That
I
want
to
query
some
of
our
own
corporate
people
that
basically
try
to
make
Google's
cloud
platform
work
for
our
corporate
needs,
so
that
is
pretty
similar,
Wow,
so
I'm,
hopefully
making
progress
on
that
till
next
week.
J
K
G
B
L
M
N
My
name
is
Stefan
Edwards
I
worked
with
Craig
on
the
on
the
kubernetes
working
group
for
actually
auditing,
both
the
technical
side,
as
well
as
the
the
threat
side
and
then
obviously
I
work
with
Dan
at
Trello
bits
where
I
am
a
principal
consultant.
I
do
a
lot
of
our
threat,
modeling,
some
VC
so
and
and
other
things
here
so
I'll
be
giving
some
talk.
N
A
G
G
N
I'll,
do
you
one
better
dan
I
will
share
only
the
slides
that
I
intended
to
yeah
I.
Just
I
really
wanted
to
walk
through
this.
We
don't
need
to
do
an
introduction
to
us,
since
we
did
the
the
roundtable,
but
I
wanted
to
walk
through
how
we
ran
the
threat
model,
because
I
think
threat,
modeling,
open
source
software,
especially
of
the
size
of
kubernetes
and
then
other
similar
components,
can
be
very
difficult.
N
We
had
people
from
companies
that
are
technically
competitors
working
with
us
and
trying
to
represent
everyone's
understanding
of
kubernetes
and
everyone's
different
viewpoints
and
from
component
teams
from
competitors.
Those
sorts
of
things
was
an
interesting
challenge
here.
Just
one
thing:
I
want
to
note
beforehand.
Technically
some
of
this
information
that
we
are
discussing
hasn't
been
released
publicly.
N
Yet
Craig
and
I
are
working
to
get
this
all
ramp
down,
but
some
folks
on
this
call
have
already
seen
the
report
I
just
wanted
to
scroll
through
some
sections,
but
they're
technically
could
be
things
in
here
that
are
unpatched
vulnerabilities
to
kubernetes
at
a
design
level.
So
I
just
ask
that
you
please
don't
share
this
too
widely.
Obviously
this
is
a
recorded
call,
there's
people
from
the
community
on
here.
So
just
just
don't
crow
any
of
the
things
that
you've
seen
here,
but
there
will
be
some
vulnerabilities
that
are
not
public.
G
N
Yes,
exactly
so
methodology
was
was
very
interesting,
I
think,
as
most
people
have
seen
with
kubernetes,
it's
a
very
networked.
Very
you
know
very
intricate
system.
There
are
many
different
state
machines.
There
are
many
different
things
such
as
there
are
multiple
public
key
infrastructures
within
kubernetes
itself,
so
having
a
dataflow
for
the
restricted
set
of
components
that
we
were
interested
in
was
fairly
interesting.
I'll
talk
about
what
components
we
had
when
I
switch
over
to
the
report
itself,
but
there
was
actually
having
something
that
is
a
documented
from
from
kubernetes
from
the
linux
foundation's
viewpoint.
N
As
a
more
canonical
data
flow
was
the
first
step
here.
So
during
the
technical
assessment
and
talking
with
Craig
and
other
folks
on
the
team,
we
came
up
with
what
was
a
rough
data
flow
model
for
this
I
actually
used
PI
TM.
If
people
are
familiar
with
that,
it
is
a
pythonic
threat,
modeling
framework
to
get
the
initial
pass
out
so
that
we
could
iterate
programmatically
on
that.
Instead
of
having
to
redraw,
slides
and
redraw
things
there
so
from
there,
we
went
to
go
on
and
understand
the
connections
between
components
at
a
logical
level.
N
Understanding
trust
zones,
the
threat
actors
there
and
and
what
concern
points
we
had
between
those.
So,
for
example,
we
wanted
to
understand
what
a
external
user
meant,
what
an
internal
user
meant,
what
a
malicious
internal
administrator
meant
and
what
components
and
what
items
they
could
touch
within
kubernetes,
both
from
a
technical
component
side,
as
well
as
a
trust
zone
side.
So
we
undertook
that
analysis.
I
will
show
you
some
of
that
shortly
and
then
we
situated
the
each
control
family
within
the
the
larger
kubernetes
system
itself
and
when
I
say
control.
N
Families
I
mean
this
in
sort
of
a
like
NIST
800
series
style
of
control.
Like
are
we
talking
about
audit
family?
Are
we
talking
about
multi-tenancy
those
sorts
of
things
so
going
through
and
I
will
show
you
how
I
address
this
going
through
each
of
the
components
and
understanding
what
controls
they
implemented,
how
strong
they
were
implemented,
what
they
were
attempting
to
protect
against
and
where
those
were
implemented.
N
We
we
then
went
through
and
situated
those
as
best
as
possible
to
pre-game
for
all
of
the
meetings
that
we
held
with
sig's
Craig
sat
in
on
some
of
these
meetings.
Jbo
one
of
our
counterparts
on
the
working
group
Aaron
from
Google.
We
all
sat
in
on
meetings
with
the
SIG's
and
I,
went
through
and
asked
people
from.
You
know:
sig
API
machinery.
How
do
you
handle
multi-tenancy?
How
do
you
handle
you
know
various
other
things
like
authentication
authorization?
What
do
you
do
for
this?
What
control
failures?
N
Do
we
see
and
I
documented
that
entire
process,
we
captured
the
output
of
those
meetings
in
what
are
called
rapid
risk
assessment
documents
I
specifically
designed
some
rapid
risk
assessment
documents
for
this
assessment.
I'll
show
you
one
in
just
a
few
moments
and
then
I
collected
the
output
from
those
all
of
the
findings.
All
of
the
really
great
notes,
all
of
the.
N
Here
the
audit
working
group
asked
us
to
focus
on
roughly
six
control
families.
Now
this
doesn't
mean
that
we
weren't
interested
in
something
say:
logging
right.
There
were
several
times
where
we
talked
about
logging.
We
talked
about
non-repudiation,
we
talked
about
other
control
families,
but
the
main
focus
of
our
assessment
was
these:
six
control,
families,
we're
interested
in
authorization,
authentication,
cryptography,
etc.
So,
for
each
of
the
SIG's
I
came
up
with
a
series
of
questions.
N
I
worked
with
Craig
and
others
to
review
those,
and
then
we
sent
those
out
to
members
of
the
open
source
community
and
pulled
them
for
answers.
So
if
you
go
back
through
the
the
archives
of
some
of
the,
the
SIG's
you'll
actually
see
me
Craig
and
other
folks
reaching
out
to
men.
Many
people
of
the
open-source
community
and
literally
asking
them
for
for
time
to
just
sit
on
a
meeting
and
discuss
some
of
these
things
or
to
look
over
the
the
the
questions
that
I
was
asking
and
provide
any
feedback.
N
So
we
we
received
some
from
from
the
community
directly
itself.
Folks
had
some
Corrections,
they
had
some
comments
and
things
like
that,
and
then
we
also
went
to
some
of
our
constituent
organizations
and
asked
members
of
the
community
who
worked
at
those
companies
to
sit
in
on
meetings
with
us
and
to
actually
review
each
of
these
control
families.
Now
we
did
rapid
risk
assessments
if
you're
not
familiar
with
this.
This
is
a
process
that
Mozilla
actually
came
up
with.
Rapid
risk
assessments
are
a
very
quick
way
of
understanding
your
CIA
triad
for
a
threat
model.
N
So
if
you
want
to,
if
you
have
a
data
flow-
and
you
want
to
understand
what
the
impact
of
a
certain
set
of
risks
are
and
come
up
with
recommendations
quickly,
Mozilla
has
worked
on
this
process.
Now,
it's
it's
interesting
when
you're
doing
this
for
normal
threat
modeling,
but
it's
not
necessarily
the
most
useful
for
what
we
wanted
to
do.
We
were
doing
control
focused.
We
are
interested
in
a
specific
set
of
components,
so
I
actually
modified
this
process
and
I
can
switch
to
that
right
now.
One
second
lost
I,
find
it
hang
on.
N
Perfect,
so
we
actually
came
up
with
these
RRA
documents.
If
you
look
for
Mozilla
rapid
risk
assessment,
you
will
see
their
document.
They
have
a
very
nice
Google
Doc
that
you
can
use,
but
it
was
not
as
useful
for
us
within
the
working
group
we
had
this.
We
had
to
work
with
many
people
from
the
community.
We
had
to.
N
We
coordinated
many
of
our
activities
via
get
and
github,
so
we
wanted
a
very
simple
markdown
document,
so,
basically
for
each
one
of
the
RAS
and
each
one
of
the
the
SIG's
we
went
through
and
asked
them
the
normal
threat,
modeling
questions
that
you
would
ask,
such
as
how
does
the
service
work?
What
sort
of
data
does
this
operate
on?
N
What
like,
why
do
I
care
as
an
attacker
and
as
a
threat
modeler
as
to
this
component,
like
what
am
I
looking
for
in
this
thing
and
then
each
one
of
those
answers
I
collected
so
for,
as
everyone
knows,
for
example,
there
are
sub
components
that
exist
within
the
same
host
but
are
technically
within
different
trust
boundaries.
So
a
cubelet
it
would
be
on
a
worker
node,
but
then
there
also
may
be
pods
or
other
things
on
that
worker
node
that
the
transit
trust
boundaries
there.
N
N
You
may
be
able
to
build
off
the
the
data
flow
diagrams
and
other
things
that
we
already
created
to
help
speed
up
your
threat,
modeling
processes
and
whatnot.
So
a
number
of
notes
were
collected.
We
went
through
and
analyzed
all
of
the
control
families.
We
did
talk
through
some
threat
scenarios.
We
did
talk
through
findings
etc,
but
all
in
all,
we
captured
a
large
number
of
notes
across
the
entirety
of
the
system.
N
N
Versus
the
components
sure
so,
kubernetes
actually
has
quite
a
few
quite
a
few
components
that
we
did
not
look
at
itself.
So,
for
example,
when
kubernetes
talks
about
networking,
there
are
a
number
of
components
within
the
system
that
handle
networking
so
for
you'd,
see
something
like
cube
proxy
and
cubelet,
and
other
items
actually
interact
with
the
Linux
routing
table
or
other
commands
at
the
network
level.
So
we
would
focus
on
cube
proxy
and
cube
lip,
but
say
we
wouldn't
necessarily
look
into
the
various
CN
eyes
that
are
out
there.
N
A
I
guess
the
question
is
in
a
norm
like
I
know,
there
are
a
lot
of
components
that
are
optional
right,
that
you
don't
need,
but,
like
with
this
assessment,
I
would
like
I'm
trying
to
figure
out
like
what
do
you?
What
what
did
what
we
supposed
to
take
away
from
it?
Does
it
mean
that
I
could
use
kubernetes
with
only
these
components
and
my
own
code,
and
then
I
would
know
something
about
this?
Then
this
audit
would
be
meaningful,
or
this
is
a
baseline
which
by
itself
doesn't
really
tell
you
anything
about
the
system.
So.
N
It
tells
you
about
the
most
critical
components
within
the
system,
so
we
were
interested
in
those
components
that
kubernetes
itself
controls.
So
like
cube,
schedulers
there
is
there
an
issue
there.
Is
there
an
issue
with
any
of
the
controller
managers,
but
where
we
did
not
dive
into
it,
say
something
such
as
docker,
so
we
were
interested
in
how
kubernetes
interacts
with
docker
or
how
kubernetes,
inter
with
calico
and
flannel,
for
networking,
but
we
were
not
reviewing
docker
and
we
were
not
reviewing
calico
and
flannel
themselves.
N
So,
in
order
to
answer
your
question,
it's
really
more
that
we
had
a
baseline
pulse
of
design
concerns
within
kubernetes
itself,
but
there
are
other
wider
concerns
based
on
your
choices
there.
So
there
may
be
issues
that
we've
seen
with
calico
that
don't
exist
in
flannel
and
vice
versa,
that
you
still
have
to
if
you're,
using
these
components
in
your
organization,
you
still
have
to
understand
risks
that
are
there
on
top
of
kubernetes
risks
themselves.
Does
that
distinction
make
sense?
Yes,.
A
N
A
N
It's
a
foundation
for
kubernetes
and
the
CNC
F
to
review
some
design
decisions
that
they've
made
within
kubernetes
and
then
it's
also
absolutely
a
a
company
could
go
in
and
look
at
these
sorts
of
things
and
see
these
sorts
of
design
concerns
and
then
design
around
them.
One
of
the
mandates
that
we
had
from
the
audit
team
was
to
not
use
previously
existent
vulnerabilities
so
like
we
weren't
dinging
them
for
things
that
were
known
issues
within
kubernetes
itself,.
G
Yeah
I
do
want
to
jump
in,
for
a
second
to
a
lot
of.
The
mandate
was
also
to
provide
kind
of
a
foundational
set
of
information
that
we
could
use
to
drive
further
security
review
inside
kubernetes,
since
even
in
the
vast
amount
of
time
that
we
had
on
like
a
subjective
basis
compared
the
size
of
the
rest
of
our
projects.
The
level
of
complexity,
number
of
components
and
just
sheer
amount
of
code
involved
in
kubernetes
is
you're
not
going
to
get
to
the
whole
thing
in
that
timeframe.
G
So
we
really
wanted
to
make
sure
that
we're
lifting
all
boats
in
the
community
and
helping
them
understand
where
else
they
should
search
next
and
what
a
good
prioritized
outcome,
oriented
list
of
tasks
to
work
on
would
be,
and
this
threat
model
document
that
Stefan's
got
up
now
represents
about
one
third
of
the
deliverables
that
we
made
for
this
project.
I
think
the
threat
model
is
particularly
interesting
to
this
SIG,
but
we
also
have
a
list
of
specific
security
issues
that
we
found
about
30
or
40
of
them,
as
well
as
a
white
paper
document.
G
K
K
N
N
But
the
interesting
thing
about
KCM
and
CCM
is
they
actually
violate
the
principle
of
least
Authority
in
some
ways,
so
there
are
components
within
KCM
and
CCM
that
are
more
privileged
than
others,
and
the
only
thing
that's
really
stopping
a
component
from
calling
another
sub
component
is
trust.
Currently.
N
So
there
was
very
interesting
discussions
that
we
had,
and
this
is
the
sort
of
thing
that
I
mentioned.
Please
don't
like
tweet
about
this
just
just
yet,
but
there
are
very
rusting
discussions
going
on
within
the
SIG's
as
to
how
to
design
around
some
of
the
concerns
that
we
came
up
with
during
our
discussions.
To
be
honest,
the
as
much
as
I'm
very
happy
with
the
work
that
I
did
on
the
threat
model
and
there's
a
bunch
of
cool
tables
and
I
I
did
all
sorts
of
really
neat
stuff.
I.
N
Think
the
most
interesting
output
from
this
was
actually
having
folks
from
the
community
sit
down
on
a
call
similar
to
this
one
and
talk
about
well.
What
does
KCM
and
cesium
do
for
authorization,
and
that
was
extremely
interesting,
because
different
folks
had
different
perspectives
on
the
various
components
and
getting
them
to
talk
about
it
in
one
single
space
was
extremely
enlightening.
N
Just
flipping
back
to
where
we
were
as
we're
as
we're
all
aware,
kubernetes
is,
is
quite
quite
large
and
the
number
of
components
so
I
had
the
situate
components
themselves,
the
ones
that
we
were
tasked
with
reviewing
within
planes
and
then
situate
those
planes
within
trust
zones.
So
if
you've
done
threat
models
before
you've
seen
trust
zones
like
there's
a
database
layer
system,
administrators
may
have
access
to
that.
What
components
sit
within
those?
What
you
know,
what
planes
are
they
in
those
sorts
of
things?
So
those
sorts
of
analyses
are
are
here
and
going
forward.
N
You
may
want
to
lift
some
of
these
trust
zones,
because
they've
been
vetted
by
the
community
they've
been
vetted
by
the
working
group
on
the
coronary
side.
There
may
be
some
interesting
things
that
you
can
build
off
of
from
these
trust
zones
as
well,
in
your
in
your
threat
model
as
well,
and
then
there's
obviously
a
connection
analysis.
This
was
actually
fairly
interesting.
We
did
find
a
number
of
locations
that
had
weak
connections,
so
they
may
use
HTTP
by
default.
N
They
may
have
the
option
of
using
authenticated
TLS
connections,
but
do
not
those
sort
of
things
and
then
support
of
sussing
out
all
of
those
connection,
types
and
sussing
out
all
of
the
all
of
the
various
zones
and
how
an
attacker
can
transit.
Those
zones
was
extremely
fascinating
whilst
talking
with
the
the
very
cigs
themselves,
and
then
we
have
fret
actors.
Obviously
this
then
drove
all
of
our
findings.
N
So
if
you
go
through
the
findings
once
this
is
released
when
I
talk
about
who
can
undertake
this
I
use
just
these
users
themselves,
there
are
no
other
users
use
throughout,
so
that
you
have
a
standard
set
of
folks
that
you're
actually
attacking
a
system,
and
then
I
wanted
to
talk
about,
obviously
where
they
come
from
and
where
do
they?
They
want
to
attack
throughout
the
system
and
then
I
talk
through
the
controls,
which
ones
we
focused
on
which
other
ones
we
had
and
then
did
an
actual
analysis
of
these.
N
So
if
you
go
through
each
one
of
the
components,
you'll
see
that
they
it
has
a
control
family.
It
has
a
subjective
strength.
Category
that
talks
about
is
the
satisfactory.
What
is
satisfactory
means
is
defined
up
above
and
then
gives
you
a
description
of
each
area
there.
So
there's
there's
quite
a
bit
of
data
in
in
the
threat
model
that
you
may
want
to
to
look
for
either
in
your
own.
N
What
I
actually
did
was
broke
down
findings
by
component
so
rather
than
just
have
a
giant
list
of
components
of
giant
list
of
findings,
I
should
say
each
finding
is
situated
within
the
within
the
component
section
that
is
there
and
then
there's
a
general
architectural
summary
of
of
the
component
and
of
the
findings
that
we
have
there.
So
there's,
there's
quite
a
bit
of
data
in
here,
I
think,
there's
56
pages,
currently
there's
a
few
other
changes
that
we've
made
so
roughly
60
pages
worth
of
information
here
and
capture.
N
The
other
thing
that
we
will
be
doing
is
once
once
we
released
this
report.
We
will
almost
certainly
release
the
the
raw
data,
so
all
the
Ras,
all
the
PI
threat
model
files.
Those
sorts
of
things
will
also
be
released,
so
you
can
build
off
of
those
either
for
for
your
threat
models
internally
or
for
the
the
CNC
F
threat,
modeling
activities
that
you
may
be
undertaking
yourselves.
So
that
was
a
lot
of
information
for
everyone.
N
B
Yeah
I'd
like
to
to
ask
a
question
and
make
a
mention.
So,
first
of
all,
when
we
do
reviews
of
our
own
in
in
the
security
it
in
the
sig
they're
open
for
anyone
to
participate,
we'd
love
to
have
you
know
folks
from
your
group,
go
and
take
a
look
at
this
after
we
do
about
three
or
four
more
of
these,
then
we're
gonna
take
a
step
back
and
try
to
look
at
how
we
change
our
process.
B
I'm
sure,
a
lot
of
your
invaluable
experience
with
doing
this
will
be
well
and
valuable
in
helping
us
adjust
that
process
and
then
with
that
comment.
I
also
in
I
also
wanted
to
ask
a
question:
a
more
focused
question
sure,
which
is
so
when
doing
security
assessments
for
like
spiffy
inspire
and
the
projects
like
that.
B
You
know
like
one
component,
could
often
then
use
that
too
fairly
easily
take
access
like
take
control
or
gain
access
to
other
components
in
the
system
and
I'm
wondering
if
the
way
in
which
you
did
things
with
kubernetes
modeled,
that
in
a
straightforward
way,
whether
that
was
difficult
to
do,
whether
that
was
out
of
scope
or
or
what
your
thoughts
are.
So.
N
N
Their
access
is
actually
able
to
parlay
that
access
to
wider
cluster
access,
so
we
have
a
technical
finding
for
that
sort
of
thing
in
terms
of
what
we
were
looking
for
when,
when
discussing
the
authorization
and
authentication
components,
I
was
always
really
interested
in
hearing
the
SIG's
thoughts
on
who
should
be
accessing
this
and
what
they
should
be
doing.
So,
for
example,
when
talking
about
you,
know
the
API
server
right.
This
is
the
real
heart,
besides
cubelet
of
the
of
the
kubernetes
system.
N
So
when
talking
about
it,
there
could
be
a
large
number
of
people
who
have
to
interact
with
this.
There
could
be
developers
that
have
to
have
access
to
this.
There
could
be
administrators
that
need
to
have
access
to
this.
So
when
we're
trying
to
understand
who
can
do
what?
To
this
thing,
there's
the
the
coercion
aspect,
there's
the
the
malicious
aspect,
those
sorts
of
things.
So
yes,
absolutely
we
did.
We
did
talk
about
who
can
do
what
from
where,
but
we
also
have
the
technical
side
behind
us,
because
there
is
a
whole
other
report.
N
With
about
forty
findings
in
it
we
were
able
to
leverage
the
two.
So
when
we
had
when
we
had
technical
findings
that
became
larger
design
issues,
we
we
made
them
into
architectural
findings
and
then
went
as
we
saw
things
on
the
threat
model
that
that
looked
a
little
interesting
that
looked
maybe
like
they
could
be
a
technical
vulnerability
as
well.
We
fed
that
process
there
if
you're
familiar
with
like
Myst
800,
115
Myst
837
those
sorts
of
things,
we
really
followed
those
sorts
of
like
oo
da
loops
like
we
see
something
in
the
threat
model.
N
We
see
something
in
the
technical
side.
We
kicked
that
back
up
as
a
discovery
item
and
then
feed
it
into
the
other
process.
So
everything
was
feeding
everything
else
so
that
we
could
look
at
who
can
who
can
parlay
their
access,
and
then
we
also
looked
to
see
if
there
were
technical
or
design
issues
from
each
of
the
other
two
assessments
so
very
long-winded
way
of
saying
yes,
we
did.
N
B
N
Absolutely
dan
has
heard
me
and
Craig
has
heard
me:
do
this.
I
will
I
will
very
frequently
sit
on
phone
calls
with
clients
because
of
my
government
background
and
say
things
like:
oh,
you
do
missed
812,
which
leads
to
missed
830,
37,
60,
61,
115,
53,
171,
etc.
But,
yes,
I
can
I
can
certainly
post
all
of
those
to
folks.
That's
not
a
problem
and.
A
A
N
The
industry
absolutely
there's
actually
a
great
paper
from
the
Swedish
police
authority.
Academy
I
can
find
that
reference.
We
reference
it
in
this
document,
but
they
actually
talked
about
how
they
used
kubernetes
in
a
highly
policy-driven,
highly
regulated
environment,
and
what
the
implications
to
doing
that
were.
That's
a
super,
fascinating
paper,
but
I
will
get
that
reference
for
everyone.
N
Well,
thank
you
very
much
for
having
Dan
and
I
I
do
think.
We
will
continue
on
with
this
I
think
it's
very
interesting,
especially
for
me,
because
I
work
to
crag
on
these
sorts
of
things
from
the
the
kubernetes
side,
I
think
we'd
be
happy
to
continue
on
working
on
these
sorts
of
things.
I
will
get
you
the
the
references
that
I
made
during
this
talk,
but
if
there's
anything
else,
please
feel
free
to
reach
out
to
dan
and
I
via
email
we'd,
be
happy
to
to
pick
it
up.
N
We're
also
on
the
kubernetes
slack
if
you're
there.
So
you
can
reach
out
to
us
and
say
hello:
I
will
include
our
handles
in
a
email
after
this
with
the
references
and
then
we
will
also
be
joining
a
CNCs
slack
as
well,
but
if
no
one
else
has
any
other
questions,
I'd
be
happy
to
turn
it
back
to
the
moderators
yeah.
B
Yeah
we
have
the
in
toto
assessment
already
up
and
we
have
a
an
assessment
for
Opa
Opa.
That
is
basically
we're
just
kind
of
waiting
for
a
tiny
bit
of
discussion
with
that
community,
which
has
been
a
little
off
and
on
and
then
we're
ready
to
push
that
one
over
the
finish
line.
So
you
I
think
reopening
the
in
toto
one.
Maybe
isn't
the
right
thing
to
do,
but
helping
us,
you
know,
there's
minor
changes
to
what
we've
done
with
OPA
that'd,
be
great
or
more
substantial.
Little
tweaks
to
things
for
upcoming
assessments.
A
I
think
that'd
be
fabulous
and
just
I
don't
know
if
we
mentioned
it,
but
our
plan
is
to
do
five
of
them
and
then
really
do
a
retrospective
on
the
process.
So
having
you
know
kind
of
like
look
at
what
we've
done
and
also
forward-looking,
and
we
have
an
issue
you
chime
in
on
or
you
know,
email
or
whatever
is
good
for
you.
We
just
really
welcome
your
participation,
Thanks
yeah.
A
E
A
B
A
Think
it
was
it
just
basically
like
if
you
could
give
a
little
update
since
I
didn't
write
down
exactly,
but
if
you
could
give
a
little
update
on
what
it
I
think.
Justin
just
talked
about
OPA,
but
of
the
next
ones
that
are
coming
up.
What
are
the
what
is
coming
up,
and
you
know
kind
of
like
status
and
on
things
yeah.
D
You're
right
so
this
is
that
difficult
to
read:
I,
don't
know
how
to
make
this
nicer.
Oh
there
we
go
yeah,
so
it's
a
robber
put
together
this
thing,
which
shows
kind
of
like
the
NYX
reviews
coming
up
people
who
signed
up.
Basically
that
commented
on
the
issue,
so
pokey
colloquy,
we
have
piled
all
of
volunteers
already,
so
it
seems
like
we
have
a
group
or
people
will
be
contacting
the
the
folks
again
next
week
they
were
all
on
vacation.
Our
way
this
past
month.
A
A
B
C
A
D
B
Yeah
I
think
we
don't
have
to
look
too
far
ahead
since
we
are
I
mean
we
don't
want
to
do
these
too
too
much
in
parallel
anyway,
but
Keith's
cloak
seems
ready.
We
should
get
someone
on
the
TOC
to
give
us
a
nod
and
say
yes,
just
so
that
later
on,
when
we
get
a
message
from
oh
I,
don't
know
some
random
person,
I'll
call
him
mr.
Q
about.
Why
would
we
pick
that,
then
we
can
say
well,
Liz
told
us
her
Michelle
told
us
or
whoever
told
us
all.
A
A
D
K
D
J
O
I've
been
in
brief
contact
on
slack
with
Ed
and
Frederic,
basically,
just
answering
some
questions
about
the
process
and
premium
to
the
docs
in
the
leaf
o
here,
so
they
can
get
familiar
with
it.
I
don't
know
if
anyone
from
that
team
is
on
the
call,
but
my
general
impression
is
that
they're
in
the
getting
familiar
stage-
and
it's
not
really
yet
ready
to
engage.
B
A
Maybe
we
can
make
a
column
in
this
for,
like
notes
where
we
can
say
like
waiting
on
project
or
whatever
or
in
queue,
and
so
the
I'll
just
comment
on
strings.
That
was.
It
came
up
at
a
TOC
meeting
where
they
gave
a
presentation,
and
at
that
time
we
were
still
at
least
I
was
under
the
impression
that
we
were
getting
guidance
from
the
TOC
to
do
assessments
for
projects
that
had
not
that
when
they
weren't
considering
bringing
them
into
the
TOC
and
into
the
s
santiana
projects
and
now
we're
getting.
A
A
But
we
do
want
one
of
our
first
5s
to
be
a
project
that
isn't
specifically
designed
to
deliver
a
security
outcome,
and
this
was
kind
of
an
interesting
thing
because
it
sort
of
it
allowed
you
to
do.
I
can't
remember
exactly
what
it
does,
but
it
does
something
where
it's
like
a
pattern
for
how
you
deploy
on
kubernetes
for
this
particular
type
of
software.
So
so,
like
I
thought
it
might
have
some
like
sort
of
security
conventions
that
it's
establishing
for
category
of
projects.
A
D
A
Okay,
Falco
and
then
we
want
a
fifth
that
is
a
ideally
a
CNC
F
project
that
we
think
is
you
know
worth
our
time
in
terms
of
you
know
of
all
the
CNCs
projects
that
don't
aren't
on
our
list
of
security
projects
like
what's
one
where
it
would
be
valuable
to
the
community
for
us
to
assess
the
security
of
it.
So.
H
I
H
I
A
I
think
also
another
way
to
say
that
Justin
is
that
so
Prometheus
has
already
been
through
an
audit
and
we
were
going
to
deprioritize
things
that
have
been
audited
and
we
actually
looked
at
Prometheus.
As
an
example
of
you
know,
when
some
of
us
read
the
audit,
we
had
different
opinions
about
the
way
it
was
handled,
and
so
we
were
going
to
go
through
the
thought
experiment,
potentially
with
the
Prometheus
team
or
some
people
from
who
were
participating
in
that
to
talk
about
how
we
would
handle
it
if
different.
A
A
We
are,
you
know,
sort
of
reporting
to
the
TOC
into
the
community
what
our
findings
are
as
people
who
are
knowledgeable
in
this
area
and
as
we
go
through
all
these
projects
having
a
disability
across
the
number
of
projects.
So
we
we
don't,
because
it's
already
been
through
that
audit.
We
don't
want
to
prioritize
the
assessment
of
it,
but
we
should
prioritize
that
to
queue
up
that
discussion
at
some
point.
A
D
A
H
G
H
C
There
people
seem
to
have
some
confusion
about
what
encryption
of
rest
means
in
a
cloud
context.
Often
people
seem
to
think
the
encryption
at
rest
is
when
something's
switched
off,
which
an
s3
bucket
is
never
switched
off.
It's
always
effectively
online
and
the
kind
of
people's
people
have
some
confusion
about
I
mean
even
at
rest.
Well,.
M
A
I
mean
this
is
actually
an
interesting
topic
because
it's
sort
of
like
cloud
versus
not
cloud
like
if
you
have
a
desktop
application
right
that
needs
to
be
encrypted
at
rest.
You
know
and
you're
keeping
data
in
memory,
and
you
don't
have
any
network
interfaces
like
it's
a
different
world.
Then
you've
got
a
cloud
native
application
and
things
are
you
well.