►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Kubernetes Policy WG Deep Dive - Zhipeng Huang, Huawei (Intermediate Skill Level)
This session is dedicated to the technical side of policy implementation. This session will be divided into the following six lightning talks each 5 mins:b- Kubernetes Security Profile Demo (David Oppenheimer) - sig-auth/sig-arch policy discussion update (Tim Allclair) - kube-arbitrator talk (Michael Elder) - open policy agent update (Torin Sandall) - Istio policy talk (Etai Lev-Ran) - SPIFEE policy talk (Andrew Jessup)
About Zhipeng
Zhipeng Huang currently serve as open source operation manager for Huawei. Zhipeng have been involved with various major open source communities and is now the PTL of OpenStack Cyborg project, co-chair of OpenStack Public Cloud WG, and co-lead of the Kubernetes Policy WG.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
Some
of
these
things
are
cluster
level.
Some
of
them
are
namespace
level.
Some
are
bound
to
users.
Some
are
bound
to
service
accounts.
Some
are
bound
to
namespaces
they're
all
specified
through
different
schemas
that
don't
have
a
lot
of
consistency
between
them.
Some
are
fail
open.
Some
are,
you
know,
closed
by
default
and
you
open
them
up
and
vice
versa,
and
so
this
is
something
that
we
want
to
improve
in
the
future
I
linked
at
the
bottom
here
to
the
github
issue.
Discussing
this.
B
Question
like
what
policies
we
should
even
be
talking
about
in
the
first
place,
we're
going
to
talk
about
OPA
a
little
later
in
this
deep
dive,
but
kind
of
one
of
the
questions
we
have
is
which
of
these
policies?
Should
we
actually
be
like
building
into
kubernetes
and
which
of
them?
Should
we
be
delegating
to
other
tools
that
specialize
in
policy
management
like
I?
B
Don't
want
us
to
end
up
re-implementing
oppa
in
yeah
mall
in
kubernetes,
CR
DS
in
order
to
you
know,
support
all
of
the
possible
combinations
of
policies,
and
so
I
think
this
is
maybe
the
most
important
question
that
we
have
in
the
working
group
and
sig
off
in
the
community.
Kubernetes
community
is
to
kind
of
get
at
this
and
then
once
we've
decided
what
the
policies
we
actually
want
to
support
are.
How
can
we
make
them
behave
more
consistently
and
fix
some
of
the
stuff
that
I
was
just
complaining
about
in
the
previous
slide?
B
So,
along
the
lines
of
you
know,
consistent
behavior,
I,
put
three
questions
or
on
the
left
that
are
I.
Think
some
of
the
biggest
questions
for
how
to
make
those
behave
consistently.
Should
they
be
namespace
scoped
or
cluster
scoped,
or
both
how
those
policies
get
bound
to
someone
or
something
should
be
at
least
somewhat
consistent,
and
you
know,
if
you're,
depending
on
what
types
of
objects
you're
dealing
with
and
and
what
your
enforcement
mechanisms
look
like.
There's
gonna
be
some
variation
here.
I,
don't
expect
us
to
have
one.
B
You
know
policy
template
that
fits
every
every
possible
combination,
but
I
think
we
should
come
up
with
more
like
guidelines
of
when
you're,
adding
a
new
policy.
This
is
sort
of
how
you
how
you
think
about
it
and
then
also
how
those
compose
one
of
the
big
problems
with
a
few
of
our
policies.
Right
now
is,
if
you
have
you
know,
maybe
your
cluster
administrator
and
your
security
group
and
your
namespace
administrator,
and
they
all
want
to
set
some
different
parts
of
the
policy.
B
A
C
Thank
you.
Thank
you.
Okay,
everyone,
I'm,
Michael,
older,
so
coop
arbiter,
who's
familiar
with
coop
arbitrator.
Today,
great
then
these
are
the
slides
for
you.
Okay,
so
coop
arbitrator
is
really
a
combination
of
kubernetes
and
high-performance
computing.
So
what
we're
doing
is
we're
trying
to
figure
out
how
do
I
get
a
laser?
Oh,
they
did
not
give
you
laser
powers.
Is
that
Alright.
A
D
C
I'll
need
more
technical
training.
All
right,
kubernetes
is
about
long
running
workloads.
High-Performance
computing
is
typically
about
batch
processing
where
I
have
a
specific
problem
that
I'm
trying
to
solve
and
I'm
running
it
through
lots
of
parallel
computation.
So
if
I
look
at
the
use
cases,
batch
processing,
I'm
looking
at
use
cases
where
I'm
submitting
jobs
I
need
to
balance
how
resources
are
assigned
to
those
jobs,
so
I'm
scheduling
them
with
certain
topologies
or
constraints,
they're
layered.
C
On
top
of
that,
and
then
I
need
to
have
a
good
way
to
sign
up,
say:
okay,
I'm,
going
to
give
you
a
particular
queue
job.
This
is
one
of
the
resource
types
that
comes
along
with
one
of
the
components
of
coop
arbitrator,
and
this
allows
me
to
say
this
particular
bit
of
work.
Has
the
sort
of
priority
requires
this
kind
of
resource,
etcetera
and
then
I
need
something
to
sort
of
play
referee
so
that
all
of
these
jobs
are
coming
on
to
the
field
can
be
allocated.
C
The
right
amount
of
resource
and
I
can
prioritize
how
much
compute
capacity
or
resources
are
assigned
to
them
as
they
so
coup
batch
D
is
one
of
the
components.
That's
part
of
Kubb
arbitrator
today.
This
is
the
piece
that
actually
defines
sort
of
the
working
model
for
Q
job,
as
well
as
the
Q's
themselves.
We'll
talk
about
what
that
looks
like
in
a
moment.
C
This
basically
runs,
though,
as
a
deployment
on
top
of
kubernetes
and
allows
it
to
interact
with
the
broader
system
and
sort
of
put
a
layer
on
top
of
coop
scheduler,
we'll
see
what
that
looks
like
in
just
a
moment.
So
when
we're
looking
at
qu
batch
D,
what
we're
really
seeing
is
here's
a
way
to
define
queues,
which
is
where
I
file
work
to
be
completed
and
that
I'm
submitting
a
set
of
Q
jobs
into
those
queues
that
each
have
these
sort
of
relative
weightings
and
priorities
and
requests
for
resources.
C
C
So
in
this
case,
so
what
it's
really
doing
is
it's
putting
another
layer
of
scheduling
on
top
of
the
coop
scheduler
work
that
is
really
optimized
for
sort
of
long-running
workloads
and
allowing
it
to
to
put
this
additional
model
of
scheduling
on
top
right
queues,
which
then
are
submitted
into
into
those
queues
or
queue
jobs
with
this
kind
of
prioritization,
and
so
by
default.
The
Kubb
arbiter
is
pluggable
and
there's
something
called
dominant
resource
fairness,
which
is
the
balancing
algorithm.
C
So,
when
we
think
about
policies
here,
the
ability
for
a
pod
to
say,
here's
when
I'm
capable
of
being
disrupted
because
we're
going
to
allocate
as
much
capacity
or
balance
capacity
between
long-running
workloads
and
batch
processing
as
we
can.
But
when
significant
new
workload
comes
on
board,
we
need
to
know
who
can
we
take
out
of
the
pool?
Who
can
we
preempt
and
therefore
give
that
capacity
to
something?
C
That's
it's
higher
precedence
and
you'll,
see
the
introduction
and
things
like
priority
classes,
so
I
think
there's
a
lot
of
capability
here
in
coop
arbitrator
that
needs
more
attention
in
terms
of
how
it
defines
policy,
and
now
we
integrate
that
with
the
rest
of
the
plot
for
dynamic
quota
allocation
is
the
second
use
case
here.
We're
looking
at
really
what
are
some
of
the
specific
workload
scheduling
algorithms
I
can
kind
of
plug
into
the
batch
to
you,
processor
and
so
cube
quota
alec
is
the
default
one
that's
available
today.
This
implements
this
domain.
C
Excuse
me
dominant
resource
fairness,
and,
if
you
don't
know
what
that
is,
I
didn't
know,
either
until
I
put
this
together,
but
here's
a
quote:
it
kind
of
summarizes
it.
It's
basically
from
a
set
of
high
performance
literature
that
allows
you
to
balance
so
that
users
are
not
exploiting
the
system
in
order
to
get
access
to
more
resource
and
they're
loud
right.
C
So
the
key
thing
there
is
that
this
means
that,
as
I
submit
lots
of
different
research
projects
or
different
works,
that
I
want
to
complete
I'm
allocating
resource
to
each
of
those
as
as
optimally
as
I,
possibly
can
without
allowing
any
one
of
those
to
game
the
system
and
get
more
than
they're
really
supposed
to
have.
Access
to.
C
This
is
a
little
bit
about
how
it
works,
and
so
there's
already
a
proposal
that
we're
discussing
in
the
workgroup
around
improvements
to
the
scheduling,
policy
and
I
think
a
lot
of
those
improvements
today
are
somewhat
security-related
placement
issues
or
preventing
certain
workloads
from
kind
of
taking
over
certain
segments
of
the
cluster.
That
they're
not
supposed
to
this
I
think,
is
a
slightly
different
problem,
which
is
really
about
optimization
and
optimization
of
the
capacity
on
the
cluster.
So
I
think
one
of
the
areas
that
we'll
do
more
of
is
looking
at.
C
Most
of
this
I
think
I've
just
said,
and
there's
one
slide:
that's
not
in
this
version,
so
apparently
my
last,
if
they
didn't
take
but
I,
do
want
to
give
a
shout
out
to
Klaus
MA
and
DA
ma
who's,
one
of
the
maintainer
x'
on
this
project
who
most
of
this
actually
came
from,
so
he
would
have
been
here,
presenting
it
otherwise
was
unable
to
travel.
So
thanks
to
Klaus
and
others
who
contributed
there,
all
right,
I
think
since
I
see
David.
C
E
E
Thanks
yeah,
so
thanks
I'm
gonna
talk
about
a
security
profile
which
is
a
open
source
project.
We
are
working
on
at
Google
and
the
idea
is
to
create
a
small
menu
of
versioned
community
curated
policy
profiles
to
enable
a
turnkey
cluster
creation
with
desired
security
and
tenant
isolation.
Actually,
I
think
there
was
a
slight
I
guess
there
wasn't
a
slide
before
this,
but
right.
So.
The
problem
that
we're
trying
to
solve
is
that
today
it's
pretty
hard
for
administrators
to
figure
out
what
policies
they
need
for
their
use
case.
E
So
that
might
be
another
published
security
profile
and
then
you
would
be
able
to
upgrade
your
cluster
or
upgrade
the
security
profile
either
one
to
a
new
version,
and
it
would
just
work
across
upgrades.
So
that's
kind
of
the
basic
idea
of
the
security
profile.
The
way
it
works
under
the
covers
is
that
there
are
three
constituents
of
it.
One
is
what
we
call
bootstrapping
rules,
so
these
are
command
line.
E
Flags
like
for
the
API
server
for
the
cubelet
cluster
scope
policy,
objects
like
pod
security
policy
and
then
namespace
scope
policy,
objects
like
network
policy,
and
then
these
policies
get
kind
of
unwrapped
from
the
security
profile,
which
is
an
object
that
aggregates
all
of
them.
They
get
unwrapped
and
applied
to
the
cluster
by
different
enforcers
that
that
you
can
choose
from
that
are
kind
of
pre-existing
pieces
of
the
system
today.
E
Yeah,
it's
tough,
okay,
thanks!
Okay
right,
so
the
part
we
missed
was
bringing
up
the
was
running
queue
bottom,
and
so
this
is
a
demo
of
integration
with
queue
bottom,
and
so
it
was
doing
queue
bottom.
No,
no!
It's
fine!
It's
fine!
I!
Don't
want
to
take
too
long,
so
it
was
kind
of
applying
the
policies
when
it
brought
up
the
cluster
and
then,
by
the
way
this
demo
was
put
together
by
one
of
my
colleagues
Lee
who
who
is
actually
the
person
who
implemented
this
system.
E
E
E
E
So
the
security
profile
is
a
CR
D
and
when
we
brought
up
the
cluster
it
installed
these
three
security
profiles.
None
of
them
are
activated
yet,
but
the
definitions
are
represented
as
custom
resources
and
then
there's
this
concept
of
a
security
profile
selector
which
lets
you
choose
which
of
the
loaded
security
profiles.
You
want
to
activate
in
the
cluster.
E
So
in
this
case
the
one
that
was
chosen,
I
guess,
was
the
lob
with
default
1.0.0,
and
now
that
we
set
the
security
profile
selector
to
choose
the
default
1.0
0
profile,
it
should
take
effect,
and
one
of
the
things
that
it'll
do
is
to
ensure
that
when
that
the
network
policy
that's
defined
in
that
security
profile
gets
populated
into
the
existing
namespaces
and
then
not
only
will
it
get
populated
into
the
existing
namespaces,
but
also
when
we
create
a
new
namespace.
The
network
policy
from
that
profile
will
automatically
get
populated
into
the
new
namespace.
E
So
we
will
check
what's
inside
the
namespace
and
hopefully
it
should
have
the
so
this
new
namespace
we
created
was
demo
one
and
hopefully
it
will
have
the
network
policy.
I
didn't
actually
watch
the
video
before
the
demo,
so
when
I
say
hopefully,
I'm
not
just
like
feigning
surprise,
whether
this
works
or
not
I'm,
just
trusting
that
it
does
so
yeah.
E
So
you
can
see
that
there
was
the
default
Network
policy
installed
in
the
new
namespace
and
also
part
of
the
profile
was
role
bindings
that
automatically
got
populated
into
namespace,
and
so
you
can
see
the
contents
of
the
network
policy
that
went
into
it.
So
I
think
that's
the
end.
Well,
maybe
not
all
right
now
we're
going
to
look
at
what
the
role
binding
was,
but
the
point
was
mostly
just
as
they
got
populated
into
the
namespace,
not
the
actual
contents,
but
the
contents
are,
you
know
what
you
would
expect
for
the
scenario.
E
So
the
scenario
here
was
like
default,
which
means
like
a
secure
by
default
cluster
but,
like
I
said
there
could
be
profiles
for
other
typical
use
cases
for
secure
for
security
and
isolation.
Okay,
that's
probably
enough
of
the
demo
demo.
It's
I
mean
it's
just
showing
here
that
it
also
installs
cluster
level.
Security
policies
like
pod
security
profile,
was
installed
as
part
of
the
security
profile
when
we
brought
up
the
cluster
using
cube,
Adam
and
past
in
the
name
of
the
security
profile,
when
we
did
that,
okay.
E
A
A
F
Right,
hi,
everybody,
my
name
is
turin
and
I'm
one
of
the
contributors
to
the
open
policy
agent
project
and,
if
you've
seen
the
project
before
our
logo
is
a
viking.
So
I
think
I'm
going
to
change
it
to
these
cats
cuz
they
look
pretty
cool.
So
what
I
thought
I
would
do
today
is
talk
a
little
bit
about
how
you
can
use
OPA
and
kubernetes
and
but
before
I.
Do
that
I
just
want
to
set
this
up
for
people
that
aren't
familiar
with
the
project.
F
So
OPA
is
a
general
purpose
policy
engine
and
what
that
means
is
you
can
kind
of
just
use
it
anywhere
in
your
system
at
any
layer
of
the
stack
and
the
core
thing
that
it
gives?
You
is
the
ability
to
offload
policy
decisions
from
your
services.
So,
if
you
think
of
in
kubernetes
in
the
API
server
every
time
a
resource
gets
created,
that
operation
has
to
be
authorized,
it
has
to
pass
through
a
series
of
admission
controllers.
F
So
every
time
you
wanted
to
like
tune
the
admission
controllers,
you
would
have
to
like
recompile
the
API
server,
but
all
of
this
has
gotten
a
lot
better,
as
of
1/8
I
believe
was
when
it
really
got
better
and
then
1/9
and
1/10
of
sort
of
made
it
it's
in
beta
now,
and
it's
really
well
supported.
So
this
notion
of
admission
control
is
really
important,
because
every
time
you
run
Coop's
etl
against
your
API
server
and
you
supply
a
manifest
with
a
bunch
of
data
in
it.
F
There's
all
kinds
of
fields
in
there
that
are
interesting
from
a
policy
perspective,
so
you
might
want
to
be
able
to
enforce.
You
know
that
all
objects
have
a
contact
email
on
them
or
that
you
know
if
the
application
is
a
critical
application,
that
the
replicas
are
set
to
some
minimum
value
or
they
follow
a
naming
convention
or
that
images
are
pulled
from
some
kind
of
common
repository
and
so
OPA
lets.
You
actually
write
these
kinds
of
policies.
I'm
not
gonna,
go
into
any
detail
on
how
you
write
them
right
now.
F
F
F
Opa
has
also
been
applied
in
a
bunch
of
other
places
in
kubernetes,
but
I
will
say
that
emission
control
is
by
far
the
most
common.
So
one
of
the
initial
integrations
we
did
was
actually
at
the
scheduler
layer,
so
we
built
a
custom
scheduler
that
allowed
you
to
write
the
scheduling
just
to
make
the
scheduling
decisions
with
an
OPA
policy,
and
that
was
more
of
like
a
proof
of
concept.
F
It
allowed
us
to
test
out
the
policy
language
like
two
years
ago
and
it
worked,
but
what
we
found
was
that
it's
really
not
a
good
fit
for
the
second
step
of
scheduling,
which
is
about
waiting
and
spreading
the
load
across
your
cluster.
So
it's
really
good
at
filtering
out
like
nodes
or
clusters
that
you
shouldn't
deploy
to,
but
you
don't
want
to
use
it
for
trying
to
spread
or
optimize
resource
utilization.
F
So
that's
not
something
you
want
to
use,
though,
before,
however,
for
filtering
or
for
authorization
and
admission
control,
it's
great
and
it's
also
integrated
into
Federation
today.
So
I
don't
know
if
anybody
here
is
using
Federation,
but
if
you
want
to,
if
you're,
using
Federation-
and
you
want
to
be
able
to
pick
which
clusters
a
workload
gets
deployed
to
based
on
fine-grained
attributes
of
the
resources
or
based
on
context,
then
you
can
use
OPA
to
do
that.
F
Okay.
So
what
I
thought
I
would
also
mention
is
that
we
have
new
support
in
b08,
which
is
kind
of
exciting
one
of
the
things
obviously
like
as
you're.
Looking
at
these.
These
use
cases
there
are
a
number
of
different
enforcement
points
that
we're
working
with,
and
so
now
you
have
all
these
oppa's
running
around
in
your
system
and
you
need
some
way
to
get
policies
to
them.
You
need
some
way
to
test
that
the
policies
are
making
the
right
decisions.
F
We've
also
added
status
reporting.
So
it's
really
useful
when
you
have
a
mini
opus
running
to
know
that
the
bundle
you
gave
it
is
actually
active
and
that
it
didn't
encounter
an
error
when
it
parsed
and
compiled
the
policies
and
so
on,
and
so
it'll
tell
you
that,
like
the
revision
of
the
bundle
that
it's
running
and
whether
there
were
any
errors
and
then
the
last
thing
is
actually
really
important.
F
So
this
there's
a
notion
of
decision
logging
and
open
now,
where
every
time
it
makes
a
decision
like
every
time
it
admits
a
pod
or
allows
an
API
request
or
denies
an
API
request.
It
will
record
that
decision,
as
well
as
the
input
that
you
gave
OPA,
as
well
as
the
bundle
revision
that
that
is
active
right
now
and
then
it'll
buffer,
those
up
in
memory
and
periodically
upload
those
batches
to
a
remote,
HTTP,
endpoint,
and
so
then,
using
that
you
can
actually
do
like
audit.
So
you
can
know
what
API
operations
have
been
performed.
F
You
can
use
it
for
offline
debugging.
If
you
want
to
understand
why
a
particular
decision
was
made
at
a
particular
point
in
time-
and
you
can
also
use
it
for
like
back
testing
so,
for
example,
if
you
have
a
lot
set
of
policies
and
you
are
making
a
change
to
them-
you
might
not
be
100
percent,
confident
that
you
can
just
deploy
that
immediately.
F
And
so
what
you
want
to
do
is
like
gain
confidence
in
that,
and
you
can
do
that
by
looking
at
these
decision
logs
and
running
them
through
the
new
policy
and
seeing,
if
there's
a
delta
between
the
old
decision
and
the
new
decisions,
and
if
there
is,
then
maybe
you
need
to
investigate
that
further.
So
this
is
just
like
an
overview
of
the
new
functionality
that
we
added
sort
of
in
response
to
seeing
open
deployed
in
many
different
places,
we'd
like
to
improve
this
going
forward,
but
it's
a
good
starting
point.
I
think
so.
B
G
So
basically
we
really
like
policies.
I
did
a
count
award
count
yesterday,
and
we
mentioned
the
word
policy
or
policies
almost
700
times
on
our
website
and
almost
400
times
in
the
code,
and
basically,
if
there
is
a
function
that
the
service
mesh
does
for
you,
that
least
year
does
for
you
and
you
want
to
be
able
to
control
it.
Then
we
have
a
policy
for
you.
There
are
policies
around
security
like
authentication
policies,
authorization
policies,
mutual
TLS
policies.
G
So
basically,
the
way
steel
works
is
when
a
request
comes
in,
and
this
is
going
to
be
the
same
for
all
of
our
policy
engines.
Request
comes
in
the
data.
Plane
is
going
to
extract
a
bunch
of
attributes
like
what
service
is
calling
the
service
being
called
the
API
user
methods,
etc.
All
those
attributes
are
going
to
be
sent
over
to
one
of
our
components
called
a
mixer
where
there's
an
adapter.
The
role
of
an
adapter
is
to
take
those
attributes.
G
Take
some
data
from
a
back-end
system
like
maybe
where
the
policies
are
being
stored
and
then
make
an
allow
or
deny
decision
based
on
the
request,
attributes
and
based
on
the
policies
that
are
configured
and
the
same
is
going
to
be
applied
to
any
kind
of
system
that
we
have
now.
This
shows
the
backend
system
sending
information
over
to
the
adapter,
which
is
like
a
policy
store,
maybe
and
then
we're
pulling
information
from
there
about
the
policies,
but
the
error
can
be
reversed.
G
We
have
two
built-in
adapters
there's
an
hour
back
adapter,
which
basically
is
very
much
like
the
kubernetes
one,
possibly
with
a
little
bit
of
extension,
but
it
does
what
you
expected
rolls
roll
binding
permissions,
etc
it's
pretty
standard
and
it
will
probably
work
for
most
of
the
simple
use
cases.
We
also
have
an
OPA
adapter,
where
you
can
exploit
all
of
the
capabilities
in
OPA.
G
Ok,
so
it's
a
matter
of
writing
an
adapter
that
can
take
the
attributes,
convert
the
format
and
call
back.
This
doesn't
have
to
happen
on
every
call.
We
do
have
cash
in
place
for
better
performance.
So
when
we
get
back
a
reply,
it's
going
to
say-
and
you
can
cash
this
for
so
many
operations
or
so
many
minutes
and
based
on
these
keys.
So
next
time
you
see
a
request
with
the
same
attributes.
You
can
continue
to
use.
G
Some
of
the
open
questions
or
things,
questions
that
we're
getting
from
customers
and
I.
Think
Tim
refer
to
those
as
well
is
how
do
we
do
policy
composition
and
control
as
soon
as
you
have
multiple
people
defining
policies
at
different
times,
different
groups?
How
do
you
measure
those
things
together
and
that's
that's
difficult,
I,
don't
think
we
have
an
answer
yet,
but
that
it's
something
that
we're
looking
at
and
I
think
that
we're
cooperating.
We
sing-off
from
that
as
well.
G
One
of
the
things
we
notice
is:
it's
not
doesn't
really
match
with
the
kubernetes
model
very
cleanly,
because
if
we
take
a
look
at
something
like
priorities,
it's
not
going
to
be
part
of
your
are
back
model.
It's
having
policies
that
take
into
account
the
attributes
of
another
policy
like
I,
won't
have
a
policy
that
says
only
people
who
belong
to
that
group
can
set
a
policy
that
has
a
priority
that
is
higher
than
mine,
not
sure
that
would
fit
well
with
the
kubernetes
model
right
now.
G
Another
thing
or
two
things
that
we're
looking
at
as
we
are
expanding
the
service
mesh
to
include
more
and
more
services,
is
how
do
we
handle
multiple
protocols
right
now?
He
still
does
a
good
job
on
HTTP
and
GRP,
see
what
happens
if
we
extend
this
to
databases
to
message
queues.
Do
we
have
the
same
kind
of
policies
or
do
we
even
need
to
change
our
policy
model,
our
attributes
that
are
still
work
together?
G
Another
question
is:
how
do
you
basically
expose,
or
should
you
even
expose
a
single
management
pane
to
customers
to
specify
policies
right
now?
If
somebody
wants
to
set
policies
or
network
access
like
I
described
before
they
have
to
go
into
the
East
EO,
to
set
those
application
level
policies,
they
need
to
go
into
calico
or
any
other
kind
of
CNI
or
kubernetes
to
set
Network
policies
and
they
have
to
go
into
their
cloud
provider
or
or
another
system
to
set
host
level
policies.
G
As
an
example
and
the
question
is,
can
we
take
the
information
from
the
developers
mind
and
somehow
extract
it
and
use
that
application
level
policy
to
automatically
derive
Network
policy
so
that
we
can
enforce
the
policies
at
the
right
location
right?
So
these
are
some
of
the
things
that
we're
looking
at
and
thinking
about
for
the
future.
I'd
be
happy
to
take
questions
afterwards
in
the
back.
D
Cool
kind
of
cool
that
I'm
last
here
spiffy
is
kind
of
ties.
A
lot
of
this
together,
I'm
sorry,
Blackman
work
for
site,
L
I'm,
our
developer
programs,
engineer
so
I'm
sort
of
the
open
source
community
guy,
if
that
makes
sense
a
little
bit
of
a
really
really
high-level
introduction
to
into
spiffy
what
it
is
and
how
service
identity
really
ties
in
to
all
these
previous
discussions,
why
do
we
care
about
servers
identity?
D
In
this
example?
Here
you
know
we
have
a
user's
application,
calling
to
a
payment
application
and
in
any
sort
of
secure
system
that
payments
application
is
this.
It
goes
through
the
sort
of
work
through
off
trying
to
figure
out
who's.
Calling
me
is
this
service
or
user
authorized
to
call
me,
and
those
policies
can
potentially
change
over
time,
and
so
spiffy
really
is
sort
of
a
level
set
of
creating
trusted
identities.
If
you
will,
and
if
you
can
create
trusted
identities,
you
can
create
and
enforce
effective
policies
in
this
case
like
access,
quotas,
etc.
D
So
many
cloud
providers
and
other
platforms
have
their
own
constructs
for
service
identity.
Ews
has
service
accounts.
You
know
it
ties
in
a
I
am
Cloud
Foundry
has
this
notion
of
services?
Kubernetes
has
namespaces
services
et
cetera,
and
they
all
really
use
these
different
constructs
to
control
different
aspects
of
policy
around
their
services,
whether
it's
access
or
billing.
D
Some
infrastructure
providers
use
these
labels
and
things
like
that
to
control
load,
balancing
and
egress
points,
so
you
can
use
it
for
network
policy
and
secrets,
et
cetera,
and
so
those
constructs
work
really
well
if
you're
constrained
to
one
particular
ecosystem,
and
so,
if
you're,
using
kubernetes
inside
of
AWS,
you
have
you
know
a
number
of
constructs.
You
can
rely
on
to
prove
identity
to
any
particular
service,
but
that's
not
really
reality
for
a
lot
of
organizations
right.
D
So
if
you
have
multiple
different
providers,
multiple
different
kubernetes
distributions,
maybe
you're
not
using
kubernetes
at
all
for
some
new
services.
How
do
you
really
tie
this
notion
of
identity
together
and
so
spiffy?
You
know
we
really
do
believe
in
this
idea
that
service
identity
should
be
independent
of
the
underlying
infrastructure
and
access
management
rules
that
can
be
derived
from
that
sort
of
stuff
should
also
be
drivable
outside
of
the
underlying
the
underlying
application
infrastructure,
and
so
these
sorts
of
rule
sets
around
access
weather.
You
know,
network
should
traffic
to
be
able
to.
D
D
This
is
a
pretty
you
know,
high
level
overview.
Spiffy
really
is
a
set
of
standards.
Spire
is
our
implementation
of
those
standards.
Spiffy
is
really
three
things:
ID
an
ID
document
and
an
API
inspire.
He
said
as
the
our
implementation
of
that
system
and
you'll
see
how
that
works
a
little
bit,
and
so
first
it
really
is
this
local
API
that
services
can
use
or
communicate
to
to
receive
identity
and
that
s
vid
or
that
spiffy
identity
really
is
a
certificate,
and
so,
if
you're
familiar
with
PKI,
this
you
know
sounds
pretty
familiar.
D
D
D
D
They
can
revoked
we're
working
on
that,
but
you
can
kind
of
imagine
scenarios
where
there
may
be.
You
know
security
incident
where
you
may
need
to
revoke
certificates
for
a
particular
application.
You
can
do
that.
Programmatically,
we're
also
working
on
specifically
with
kubernetes
being
able
to
register
services
as
couplets
come
up
and
so
having
those
couplets
and
those
applications
being
essentially
pre
verified
through
some
service
of
those
certificates
already
exists
and
then
I
put
load.
Balancer
configuration
changes,
you
know
potentially
being
able
to
present
these
certificates
to
your
load.
Balancer.
D
D
You
can
use
these
IDs
to
present
these
IDs
to
rule
system
or
policy
agents
like
OPA
for
instance,
and
so
you
can
use
these
IDs
to
automate
network
policy
or
to
enforce
quotas,
and
you
know
when
we're
working
on
some
projects
to
embed
those
into
debug,
logs
and
and
tracing
systems
like
open
trace
and
so
really
once
you
can
establish
your
identity
and
the
metadata
around
that
you
can
imagine
what
kind
of
decisions
you
can
make
around
that
where
we
going
next.
This
is
just
a
little
bit
of
a
high-level
roadmap.
D
You
see
a
jot
is
sort
of
in
the
in
the
near
term,
roadmap
for
US
Federation
right
now.
The
spire
servers
that
are
actually
issuing
the
certs
they're,
essentially
their
own
domain
right
now,
and
so
we're
looking
at
being
able
to
connect
different
spire
servers
to
create
federated
services,
so
they
both
trust
each
other
high
availability
right
now.
Spire
servers
are
a
single
point
of
failure.
You
don't
like
that.
This
is
a
pretty.
You
know
important
aspect
of
your
service
infrastructure.
D
You
don't
want
that
to
be
a
single
point
of
failure
and
then
delete
and
revoke.
As
I
was
saying
before,
we
want
to
be
able
to
programmatically
for
be
able
to
delete
and
revoke
certs,
which
enables
some
pretty
cool
security
features
and
scenarios
go
over
this
really
really
quickly.
There's
a
lot
of
work
to
do
still
pretty
early
project
and
the
SIG's
are
pretty
active.
I
would
definitely
invite
everyone
to
get
involved
in
those
there
are
bugs.
D
You
know,
as
your
support
would
be
great
or
GCP.
Support
would
be
great
if
you
are
using
some
really
weird.
You
know
I
as
out
there
that
can
potentially
be
leveraged
to
provide
provide
metadata.
We
could
definitely
use
plugins
for
that
sort
of
thing
and
slack
we
have
a
sock
channel,
that's
pretty
cool,
yeah
I
think
that's
it.