►
From YouTube: Deep Dive: CNCF Security SIG – Justin Cappos, New York University & Zhipeng Huang, Huawei
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
Deep Dive: CNCF Security SIG – Justin Cappos, New York University & Zhipeng Huang, Huawei
CNCF Security SIG representing cross-cutting concerns including authentication, authorization, auditing, policy enforcement, privacy and compliance. This session will present the state of cloud native authentication, authorization, policy controls and verification, highlighting CNCF projects that can help reduce risks for cloud native deployments and the ecosystem of tools and services.
https://sched.co/Oscd
A
You
know
generally
has
this
opinion
or
generally
thinks
this
thing
and
will
try
to
make
it.
You
know
try
to
make
it
clear
when
we
have
our
own
opinions
or
what
else
is
going
on
in
this
case.
So,
first
of
all,
what
is
this
sig
security
group?
Well,
of
course,
the
big
focus
here
is
to
protect
cloud
native
ecosystems
and
also
to
really
help
people
understand
what
tooling
and
what
procedures
and
what
things
are
available
for
them
to
use
in
cloud
native
to
go
and
have
a
stronger,
more
secure
cloud
native
ecosystem.
A
There
are
also
things
around
tooling
for
auditing
and
other
mechanisms
like
that
that
are
under
the
purview
and
they're
some
of
the
things
that
I'm
very
quickly
going
to
talk
about
here
by
the
way,
if
you
feel
free
to
raise
your
hand
and
interrupt
at
any
point,
if
you
have
questions,
we
will
intentionally
be
going
through
things
here
and
leave
plenty
of
time
for
questions
at
the
end.
So
we've
we've
tried.
A
A
It
has
really
started
fairly
recently
and
really
damned
Shaw
Sarah,
Allen
and
JJ,
which
are
the
co-chairs
of
it,
did
a
nice
job
of
getting
this
together
and
getting
this
accepted
and
getting
this
formal
part
of
the
CNC
F
and
it
been
going
through
a
lot
of
the
bureaucracy
here.
So
you
can
just
see
this
is
I,
think
even
a
partial
list
of
people
that
have
been
participatory
here
so
and
I
know
that
some
of
these
people
in
the
room,
if
you're
one
of
the
people
who's
participated,
please
raise
your
hand
for
a
sec.
A
Okay,
well
there's
at
least
one
other.
So
thank
you
for
for
participating
and
there
are
a
lot
of
different
people
that
could
have
been
asked
to
give
this
talk,
but
I
drew
this
short
straw,
I
guess
so
anyway.
So
one
of
the
big
things
that
we're
doing
in
this
group
is
we're
trying
to
do
security
assessments
and
what
a
security
assessment
is
and
is
not
is
it's
kind
of
important
here
to
talk
about?
A
The
idea
is
to
do
a
high-level
security
review
of
a
project
not
to
try
to
look
through
the
code,
for
you
know,
like
sequel
injections
and
buffer
overflows,
and
things
like
this,
but
to
understand:
are
they
trying
you
know?
Do
they
have
goals
that
make
sense?
Are
they
trying
to
solve
a
problem
that
would
make
sense
for
users
to
want
to
adopt?
Well,
it
actually
make
security.
Better
is
the
way
that
they're
going
and
developing
their
software
the
general
framework
for
this.
Does
it
make
sense,
or
you
know,
do
they?
A
Are
they
just
like
checking
in
private
keys
into
their
repo
that
they
use
in
production,
or
things
like
that?
Accidentally,
like
you
know,
also,
is
the
project
itself
usable?
Is
it
something
that
people
can
go
and
you
pick
it
up
and
you
plug
it
in
and
the
default
way
of
plugging
it
in
is
actually
going
to
give
you
meaningful
security,
or
are
you
in
a
situation
where
there
are
so
many
kind
of
rough
edges
and
gotchas
that
you
really
have
to
worry
about
that
and
there's
a
whole
template
for
this?
A
The
list
was
tough
notaries,
spiffy
spire,
OPA
and
falco
on
the
list
and
those
were
all
security
projects,
then
the
second
priority
for
from
the
TOC
was
projects
that
heavily
influenced
the
way
you
would
have
security,
so
something
that
you
might
plug
into
your
infrastructure.
That
would
you
know
if
something
goes
wrong
from
a
security
standpoint,
have
undue
impact
in
a
negative
way,
after
that,
it's
sort
of
everything
else
and
we
have
unofficially
completed
audits
of
tough
notaries.
A
Spiffy
inspire
I
actually
did
the
worked
with
some
folks
on
the
spiffy
spire
team
to
do
in
an
audit
I,
don't
know
maybe
six
months
ago
for
them,
there's
a
bunch
of
blog
posts
and
other
documentation
available
about
this,
and
we
actually
use
this
as
the
way
to
come
up
with
the
initial
procedures
for
how
we
would
do
the
audits
inside
the
safe
working
group.
Tough
notary
has
had
a
whole
bunch
of
audits
and
a
lot
of
them
are
available
on
our
on
the
site
for
them.
A
So
you
can
actually
go
and
read
other
audits
by
Kyra,
53
and
I.
Don't
know
three
or
four
other
groups,
and
then
we
have
been
sort
of
going
through
the
assessment
process
with
a
couple
of
different
projects.
Justin
Cormac
here
was,
is
leading
the
assessment
for
the
in
toto
project,
which
is
a
project
that
is
hoping
to
join
the
CNC
F
at
the
incubating
level.
It's
a
supply
chain
security
project
and
then
OPA
I've
been
leading
that
assessment
and
working
with
the
folks
there
to
go
through
that
process.
A
We
have
other
projects
that
we've
been
had
conversations
with,
like
Falcone,
key
cloak
and
others.
If
you
are
a
contributor
to
a
project
that
might
be
interested
in
being
that
third
non-security
project,
then
please
let
us
know
we
are
looking
for
something
else
and
hopefully
by
the
next,
like
cube
con,
we'll
be
able
to
present
and
talk
about
all
the
you
know
finalize
things
like
this,
if
just
to
give
you
a
sense
of
what
it
takes
to
do,
one
of
these
is
it
open
here,
or
did
it
not
get
open
the
OPA?
A
Okay,
all
right
so
I
can
sorry
because
we
should
slap
tops.
So
it's
you
basically
write
up
a
document:
hey
Sarah,
there's
Sarah
one
of
the
co-chairs
on
the
back
who
just
walked
in
so
what
you
do.
Is
you
basically
write
up
a
document?
It
takes
something
like
maybe
20
hours,
to
write
an
initial
assessment
document
20
to
30
hours,
you
iterate
with
the
group,
that's
doing
the
the
audit
and
the
whole
process
from
your
side.
A
If
you
you
know,
have
already
done
some
background
and
have
some
security
assessment
is
expected
to
take
something
like
one
to
two
man
weeks
of
effort
from
from
your
side
to
put
this
together
and
the
resulting
documentation.
Sorry
engineer
weeks,
I
apologize!
Thank
you.
Thank
you
for
correcting
that.
A
So
is
it's
expected
to
take
not
an
undue
amount
of
time
from
you
and
then
the
auditors
themselves
go
through
and
get
a
deeper
understanding
of
what
it
is.
You're
doing,
write
up
an
assessment
and
the
documents
both
the
things
that
you
write
about
your
project
in
its
security
posture
and
the
things
that
the
Assessors
write
about.
It
are
public
documents
that
other
people
can
look
at
and
read
and
understand
what
the
security
posture
of
a
project
is
and
get
a
sense
of
that.
A
A
How
best
should
you
actually
deploy
it?
Like
you
have
this
project,
you
hear
it's
great,
you
hear
it
does
all
these
good
things
from
a
security
standpoint,
but
you
know
there
are
definitely
wrong
ways
to
deploy
pretty
much
anything.
So
you
you
want
to
understand
a
bit
about
that
and
also
it's
often
helpful
to
understand
what
other
people
have
done.
A
How
can
we
improve
security
overall?
Can
we
give
recommendations
for
ways
to
do
things?
Do
we
need
to,
you
know,
push
to
say:
hey.
There
should
be
a
cloud
native
project
that
secures
this
part,
because
there's
a
big
weakness
here
and
everybody's
workflow,
and
also
for
existing
projects
that
you
already
use.
How
can
we
do
things
like?
How
can
we
make
kubernetes
more
secure?
How
can
we
make
Prometheus
more
secure?
A
How
can
we
make
you
know
whatever
tool
thing
you
use
work
better
right
so
and
I'll
just
give
you
a
rough
rundown
of
the
ones
that
we've
been
through
I
want
to
say
that
this
is
just
a
very
rough
assessment
and
kind
of
one-liner
about
what
you
might
think
about
it.
So
if
you're
trying
to
deliver
your
software
in
your
container
securely-
which
ideally
you
know
you
don't
want
people
to
tamper
with
your
containers,
so
should
be
everyone's
goal.
A
Then
using
something
like
toughened
oak
tree
and
the
kind
of
one
in
assessment
I
have
for
this
and
I
should
say:
I
have
bias,
perhaps
because
of
this,
because
I
the
tough
creator,
but
it
does
have
some
one-time
set-up
cost.
But
after
that
is
largely
an
invisible
piece
of
security.
Your
infrastructure,
that's
basically
the
feedback
that
we
get
from
our
users
who
have
adopted
it.
It's
yeah
it
took
us
a
week
to
integrate,
but
after
that
it
was
great
and
then,
when
something
bad
happens,
it's
really
nice
to
have
it.
A
There
spiffy
inspire
handled
the
secure
introduction,
the
secure
provisioning
of
the
initial
identity
and
it's
a
cross-platform
cross
cloud
way
of
doing
this,
that's
very
simple:
to
use
and
integrate
and
fairly
seamless.
So
it
also
if
you're,
trying
to
manage
policy.
Oh
oppa
is
a
great
policy
for
is
a
great
project
for
that,
and
it
does
have
some
costs
to
kind
of
get
up
and
going
with
oppa.
But
it
lets
you
kind
of
collate
and
manage
a
lot
of
policy
centrally.
A
You
find
things
and
do
things
is
we're
currently
undergoing
creating
like
a
landscape
for
security
here,
and
there
have
been
some
proposals
about
ways
to
do.
Category
is
a
different
approach
to
do
this
and
we're
having
a
fair
amount
of
discussion
about
what
the
right
way
is
and
what
the
most
useful
way
is.
A
There
are
other
things
we're
trying
to
do
under
the
security
sig
group.
One
of
them
is
we
to
provide
expertise
out
to
different
projects.
There
are
a
fair
number
of
situations
that
come
up
quite
rarely
for
different
organizations,
but
one
of
the
things
that
at
least
in
my
role
as
a
professor
I
have
kind
of
the
leisure
to
do,
is
I,
get
to
study
a
lot
of
incidents
and
really
understand
them
and
I
know
a
lot
of
people
in
the
security
group.
A
There
are
also
things
around
documentation
and
tooling,
and
things
like
this
that
we
want
to
make
better
and
want
to
improve
in
the
ecosystem
generally
improving
security
awareness,
we're
working
on
a
security
white
paper.
That's
had
quite
a
lot
of
effort,
there's
a
lot
of
policy
documentation
which
Howard's
going
to
talk
about
in
a
moment
and
in
general.
Another
big
part
of
what
we're
trying
to
do
is
to
do
outreach
and
get
community
feedback.
So
we'd
love
you
all.
A
If
you're
on
slack,
to
join
sig
security
and
to
come
to
our
meetings,
our
meetings
are
Wednesday
at
1:00
p.m.
Eastern
time.
So
you
have
to
adjust
that,
for
whatever
your
time
zone
is
10
at
10
a.m.
Pacific.
What's
it
Justin
Cormac
in
6
p.m.
UK
7
p.m.
here,
so
your
your
time
zone
may
vary
ok
and
yeah.
For
that
there's
a
link
here
and
you
can
also,
if
you
want
to
learn
more
about
the
security
reviews
just
in
Cormac
right
here,
is
going
to
be
giving
an
in-depth
talk
about
that
at
2
o'clock
today.
A
A
B
B
Your
security
deployment
and
I
would
really
like
to
point
out
that
policy
is
very
different
from
configuration.
I
think
people
always
confuses
to
to
config
is
like
part
of
part
of
the
ways
you
actually
enforce
policy,
but
it's
not
like
policy
and
policies,
rare
species
that
you
can
say
it's
an
abstraction
on
every
level.
It's
like
an
an
abstraction.
You
can
have
very
high-level
policy
expressions,
expressions
like
OPA,
the
rego
file
provides
or
down
very
low
things
like
EBP
have,
or
you
have
policy
for
your
CPUs
GPUs
accelerators.
B
So
if
one
thing
you
can
take
away
from
this
session,
I
want
you
to
take
this
away.
So
palsy
is
now
config.
Configuration
is
one
way.
Policy
is
a
wrong
shape.
Policy
expect
result
and
provide
like
like
punishment
or
reward
for
the
result.
Okay,
it's
not
so
policy
talk.
Json
is
hardly
policy.
Okay,
a
little
bit
history
I'll
quickly
call
way.
So
we
are,
we
were
working
with
safe
and
now
security
seek
very
early
on.
This
is
a
very
old
sign.
B
Actually
and
motivation
is
actually
we
see
policy
started
with
kubernetes
start
a
scattered
all
around
place.
You
have
multi-tenancy
policies,
networking
policies
are
back
policies
and
then,
if
you
look
beyond
Cuban
80s,
you
see
issue
has
a
lot
of
policies.
Many
other,
like
OPA
spire
notre
a
many
cognitive
softwares
are
using
policies
and
what's
important
to
know
here
is
that
for
the
policy
description
itself,
the
language
we
think
it's
very
domain-specific
in
nature,
so
it
we're
very
hard
or
difficult
to
standardize
on
the
language
level.
We
come
any
questions
like
we
have
a
standard
language.
B
You
know
to
describe
policy
personally,
I,
don't
think
so.
Well,
it
might
be
in
the
future,
but
it
would
be
a
very
difficult
task,
so
we
focus
mostly
on
policy,
semantics
and
control
mechanism.
These
things
are
universal,
so,
no
matter
what
language
like
programming
languages,
no
matter,
what
you
are
using,
the
semantics
are
the
same.
You
are
expressing
like
who
to
what
under
what
circumstances
you
know
in
which
manner
for
what
reward
right.
This
is
basically
a
policy
inertia.
B
So
I
can
see
we
can
sort
of
put
the
cognitive
world
into
these
three
layers,
so
we
have
control
playing
like
the
kubernetes
is
do
and
we
have
the
data
plane
envoy
ceiling,
and
you
have
the
policy
layer
that
you
have
the
policy
engine
possibly
have
a
formal
verification
engine
to
help.
You
know,
validate
the
policy
and
also
the
compiler
here
is
not
the
usual
compiler.
We
always
refer
to
in
programming.
Language
compiler.
Here
is
something
that
help
compile
your
policy
semantics
to
what
a
cloud
control
plane
understand.
C
B
We
do
in
the
sincere
security
is
six
island
communities,
okay,
so
the
main
thing
we
are
doing
in
the
security
sig
is
now.
We
are
writing
the
white
paper.
So
there
are
some
of
the
like
papers
and
things
we
do.
One
of
the
things
we
do
for
white
paper
is
to
do
in
case
studies,
which
makes
our
meeting
quite
like
a
podcast.
It's
quite
interesting,
so
I
will
quickly
go
over
for
highlighted
case
studies.
We
did.
The
two
are
mostly
communities
related
I
will
cover
in
tomorrow's
policy
working
group
session.
B
We
are
the
power
of
a
BPF,
so
this
is
where
the
policy
is
very
important,
insulin
and
interesting
for
us
to
see
how
policy
could
help
cilium
one
of
the
takeaway
from
our
case
study
session.
Is
that
giving
EBP
HAP's
own
capability
of
extension.
We
think
sealing
my
go
beyond
the
current.
You
know
scope
and
have
more.
B
So
something
came
out.
The
case
study
is
that
we
are
looking
at
maybe
for
the
spiffy
metadata
field
that
we
could
like
as
something
like
trust
domain
or
a
policy
domain
that
actually
help
further
identify
the
workloads
like
belonging,
so
that
you
can
apply
more
dynamically
apply
policies
to
to
the
workload
instead
of
right.
Now
we
just
have
one
field
as
long
as
I
understand
so
tough
normally
came
from
Justin's
my
you
team,
very,
very
interesting
project,
so
we
were
very
glad
to
see
there
are
like
we
we
are
always
going
with.
B
There
are
more
policy
semantics.
The
support
not
only
allow
and
deny
it's
sort
of
boring
now,
so
we
see
like,
for
example,
in
total
in
total,
has
the
concept
of
artifact
rules
and
like
layers
of
rules,
and
you
can
define
actions
like
match
or
create,
which
is
quite
quite
interesting.
This
means
we
can
basically
further
extend
policy
a
semantic
issue.
B
We
have
a
really
great
talk
from
the
issue
of
security,
so
policy
is
issue
mostly
use
for
security,
so
one
of
the
things
that
they
are
planning
for
the
authorization
project
we
to
in
this
year
is
that
they
are
looking
at
also
more
complex
semantic
support
other
than
just
allow
deny
and
also
they
are
facing.
The
problem
or
policy
rate
resolution
like
how
you
could
have
a
set
of
rules
for
your
different
namespaces
and
tenant
and
how
you
you
know
prioritize.
This
denied
rule
can
prioritize
this
allow
rule
or
wanna
okay.
B
B
Okay,
there
are.
Some
very
interesting
areas
may
cover
tomorrow
meeting
so
one
if
form
of
Education
we
are.
We
did
had
a
discussion
with
the
AWS,
automated
reasoning
team,
very,
very
interesting
discussion
with
burning
cook.
We
probably
this
year
we
launched
a
sort
of
open
source
research
project
to
see
how
to
bring
for
more
verification
for
communities
policy.
Starting
with
kubernetes,
of
course,
to
see
that
one
we
can
verify
the
policy
itself
and
second,
we
can
like
ahead
of
time
or
just
in
time,
see
the
policy
execution
if
you
can
be
validated.
B
The
second
one
is
from
our
co-lead
Erica
from
Red
Hat,
the
policy
types.
So
basically,
you
can
treat
policy
as
a
type
system
for
your
cloud
native
architecture.
This
is
also
very
interesting
topic,
so
you
can
have
many
policies
actually
like
the
integers
floating
point
that
you're
using
the
programming
language
that
putting
constraints
on
your
cluster
and
unaware
in
its
container
policy
interface,
because
most
of
time
we
are
doing
web
hooks
and
maybe
their
need
for
a
rest-based.
A
B
Csi
scene
right:
okay,
we
have
weekly
meeting.
So
please
it's
is
it's
like
4:00
p.m.
on
the
west
coast,
I
think
also
we
can
ping
as
either
the
since
I
have
slack
channel
six
security,
or
you
know
kubernetes
slack
policy
yeah.
So
tomorrow,
we'll
have
another
communities,
focus
talk,
you're
more
than
welcome
to
join.
Okay.
Thank
you.
B
A
Sir
we'd,
like
to
we
intentionally
left
quite
a
bit
of
time,
because
we
want
this
to
be
a
discussion
like
what
should
the
security
group
be
doing
what
you
know?
What
would
you
like
to
do
as
part
of
a
security
group
effort?
You
know
anything
in
those
sort
of
Eanes,
just
somebody
kick
us
off
with
some
great
suggestion.
All
right.
Yes,.
A
Yes,
so
so
don't
be
careful
about
how
we
use
the
word
audit,
it's
funny,
because
during
the
intro
session,
I
had
exactly
the
same
observation
about
the
speaker
there
it's
it's
kind
of
hard
to
to
do
that
it.
It
is
an
audit,
but
it's
not
a
code
audit,
and
it
is
so.
We
called
it
assessment
to
try
to
disambiguate.
So
we'll
try
to
be
clear
about
that,
but
thank
you
for
the
catch.
Yes,
oh
sorry,
go
ahead.
A
Yes,
yes,
we
are,
we
we
have
two
of
them
that
are
not
complete,
but
we,
the
plan,
is
to
have
them
up
in
the
repo
linked
and
also
the
projects
are
very
likely
to
list
them
prominently,
or
at
least
I
know.
The
in
toto
project
will
absolutely
do
that
as
we
did
with
tough
and
I'm
sure
other
projects
will
want
to
as
well.
Yes,.
A
So
if
you
have
something,
that's
really
meant
to
be
used
in
highly
available
high
assurance
environments
that
it's
designed
to
be
a
storage
layer
for
that's
like
a
persistent
storage
layer
or
a
database
or
something
you
might.
You
might
consider
unavailability
like
denial
of
service
style
attacks
to
be
a
much
higher
problem
than
one.
That's
just
meant
to
be
like
an
ephemeral
cache
where
you're
allowed
to
have
cache
misses
and
your
system
needs
to
be
able
to
fail
and
recover,
even
though
they
both
sort
of
have
storage
and
so
on.
A
A
A
A
Okay.
Okay,
so
let
me
repeat
the
question
just
for
the
recording
here.
So
the
observation
is:
is
that
when
you
build
attack
trees
and
things
like
this
you're
going
and
then
you'd
like
to
be
able
to
tie
this
into
more
automated
assessment
and
have
tooling
around
this
and
this
work
you're
doing
you're
somewhat
leading
the
way
here
and
you'd
like
to
make
this
available
to
others.
I
think
that's
excellent
suggestion
and
we'd
absolutely
love
to
have
things
like
that.
A
C
So
our
intent
is
to
have
the
ideas
about
what
we
do.
Work
on
very
much
come
from
the
people
in
the
group,
because
we
have
a
lot
of
experts
in
the
group,
and
so
while
we
will
do
things
that
the
TOC
would
like
us
to
do
when
they
have
a
need,
we
created
a
governance
process.
So
if
you
look
in
the
governance
folder
of
this
repo
there's
a
process
that
describes
it's
pretty
simple,
you
make
a
github
issue
and
we
talk
about
it,
but
it's
written
down
exactly
what
you
would
have
to
do.
C
If
you
know
you
want
us
to
work
on
something
as
a
group-
and
so
you
know,
I
would
encourage
you
to
follow
that
process,
because
I
think
you
and
like
lots
of
people
here,
have
what
we're
seeing
is
people
in
the
field
have
these
security
issues
that
everybody
it's
all
DIY
right.
It's
all
like.
Let
me
write
some
script
to
do
this
thing
and
lots
and
lots
of
people
have
a
need,
which
is
why
this
group
exists
right.
A
And
and
become
us,
don't
don't
don't
just
create
a
PR
and
then
say
gosh
like
why
don't
the
security
group?
Why
doesn't
this
group
do
this
like
join
the
security
group
and
participate?
That's
basically
what
I
did
is
you
know
they
were
like
gosh?
We
need
an
assessment
thing
and
I'm
like
well.
I
did
an
assessment
for
spiffy,
spire
and
they're
like
well.
How
did
that?
Go
and
I
wrote
a
bunch
of
things
down
as
a
guideline
and
then
all
of
a
sudden.
A
A
A
A
A
A
great
question
that
I'll
try
to
repeat
so
you
work
in
FinTech,
you
did
things
in
the
threat,
modeling
standpoint
and
you're
also
doing
things
in
the
testing
and
verification
standpoint
and
you'd,
really
kind
of
like
someone
to
look
at
your
environment
and
your
holistic
deployment
of
how
you
did
things.
I
think
that
the
general
goal
of
what
we
want
to
achieve
should
make
what
you're
doing
there.
A
There
should
be
good
ways
to
to
provide
things
like
what
you're
doing
I
can
think
you
know
I'm
just
speaking
for
myself
here,
but
one
way
to
do
it
would
be
for
you
to.
Let
us
make
you
like
a
case
study
that
we
could
put
up
on
the
site
and
have
other
people
audit
and
look
at
it.
That
I
think
would
be
an
effective
way
to
get
that
kind
of
feedback
you
want.
Sara
has
so.
C
Yeah
actually,
before
we
pulled
you
into
activity
in
the
group,
what
we
did
a
lot
in
the
first
six
months
is
to
nine
months
that
we
were
in
existence.
Is
we
invite
we
had
on
the
different
projects
that
did
security?
Some
of
them
come
in
and
present,
as
well
as
what
we
called
use
case
presentations,
so
that
was
incredibly
helpful
in
aligning
the
group.
Basically,
we
decided
at
any
time
the
people
who
created
platforms
disagreed
on
things.
C
We
would
pause
and
ask
for
people
to
come
present
their
use
cases
and
talk
about
their
pain
points,
and
so,
like
Cloud
Foundry,
talked
about
how
they
integrated
various
things
for
identity,
and
you
know
a
number
of
different
companies
came
in
and
talked
about
exactly
this
type
of
thing,
so
I
would
love
to
have
you
talk
about
your
use
case.
This
is
the
security
things
we
used
and
then
people
can
talk
about.
People
can
get
inspired.
Oh
I'm,
not
doing
that.
I
didn't
read
that
paper
that
101
best
practice
that
you
read
or
have
recommendations.
A
A
C
Actually,
one
of
the
reasons
we
don't
yet
have
a
white
paper,
because
we
imagine
that
there
were
many
different
audiences
and
now
that
we've
basically
in
the
fall,
we
realized
what
the
audience
needs
to
be,
which
is
the
TOC
needs
to
be
able
to.
Somebody
is
new
to
cloud
and
says:
I,
don't
know
about
this
cloud
thing
or
I'm
in
cloud
and
I.
Don't
know
what
I
should
be
doing
about
security
and
here's
your
white
paper.
C
B
Policy
white
paper,
mostly
for
developers,
so
we
don't
have
a
long.
You
know
basic
concept
so
to
just
write
note:
I
have
no
self
into
the
concept.
So
the
reason
for
organizing
white
paper
is
because
policy
is
so
scattered
around.
You
know
people
saying
policy
but
means
differently.
So
we
want
there's
a
place.
You
know
people
can
discuss
and
sort
of
standardize
or
any.
A
And
any
other
questions
I
know
we're
over
time
here,
but
everybody's
been
so
nice
and
patient
has
such
smart
questions
that
feel
free
to
ask
anymore.
If
not,
then
join
the
the
security
slack
channel
ask
questions
there.
Talk
with
us
individually
meet
us
in
the
hallway,
come
to
our
meetings
on
Wednesday
at
you
know.
Whatever
time
it
is
in
your
time
zone
and
thank
you
all
for
coming.
Thanks.