►
From YouTube: IAM on Hybrid Cloud: Next Generation Security Model to Create an Interoperable Cloud [I]
Description
IAM on Hybrid Cloud: Next Generation Security Model to Create an Interoperable Cloud [I] - Jeyappragash JJ & Kamil Pawlowski, padme.io
Those developing and operating modern software infrastructure face a myriad of complexity when trying to secure it. While environments like amazon have vastly simplified the supply chain associated with brining up new physical and virtual infrastructure or services, complexity around managing access to and between these services has grown, and continues to expand. The proliferation of configurations, management tools, and management schemes that exists in the modern datacenter has exploded when dealing with multi-cloud, hybrid (cloud + dc), or legacy systems.
Complexity is the enemy of security. This heterogeneity is its embodiment. Having many different ways to configure access policies on different cloud providers or with different vendors, makes it impossible to understand whom has access to what in any given infrastructure. Without this visibility it is impossible to have intelligibility, and hence security.
Worse, today developers and operators must exist in and support a highly dynamic service environment. That is to say existing services must evolve to support new functionality, and new services must be rapidly brought on line to support features in a highly competitive business environment. The miasma of different configuration schemes creates a great deal of friction against this, and impedes security because it is difficult to holistically understand the impact of changes (let alone make them rapidly). Security must be able to accommodate this temporality.
In this talk we introduce PADME as an architecture for policy admission aimed at solving these problems in a distributed environment. PADME operates by normalizing access policy information across underlying clouds and system. It allows policies to be operated up as known fixed building blocks in order to establish end to end security. Finally, it attacks the problem of policy distribution in a distributed environment so that assertions can be made about the security of a system over time, and in the face of CAP theorem issues.
About Jeyappragash JJ
Jeyappragash previously built the team and lead the technical roadmap for Twitter's Cloud Infrastructure Management Platform. This platform helps developers manage their services and provides detailed visibility to the infrastructure and the services that use the infrastructures. Prior to this he was a Distinguished Engineer at Motorola (then Google Company), leading efforts to build their Notification Infrastructure, their Software Upgrade services and a Prospective Search based Content Delivery Service and built a true hybrid infrastructure while migrating these services to Google cloud. Jeyappragash graduated from IIT Madras with a Masters in EE. He holds 5 patents in cloud infrastructure and distributed systems space.
About Kamil Pawlowski
Kamil Pawlowski (Software Engineer) has worked on everything from mobile to high scale/availability systems, network protocols to web stacks. His experience includes early stage startups, large companies, and stages in between. He is presently building services infrastructure for the medical field.
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
So
I
am
jayjay
and
the
guy
who's
supposed
to
be
presenting
his
camp
Oblonsky.
He
works
on
this
project
and
he
did
all
the
preparation
and
everything.
So
he
has
all
the
context.
I
wanted
to
hear.
I
want
you
to
hear
from
him.
If,
for
some
technical
reason
it
doesn't
work
out,
then
I
think
you
get.
You
get
to
hear
my
version
of
the
story.
B
B
Web
server
that
you're
using
an
older
one
if
you've
got
network
infrastructure
of
any
kind
chances
are
with
the
stuff
that
you're
dealing
with
this
all
configured
differently
and
forget
about,
like
all
your
switches,
configure
the
same
ways
or
router,
and
all
this
other
wonderful
stuff
like
these
things
are
all
everybody
has
their
own
proprietary
way
of
configuring
all
this
stuff.
Why
is
this
important
in
a
security
context?
Well,
because
all
of
this
stuff
is
difficult
to
configure
and
it's
all
configured
differently,
it's
difficult
to
understand.
B
What's
going
on
at
any
given
point
in
time,
and
it's
really
hard
to
roll
out
a
policy
across
this
myriad
of
different
things.
This
is
the
heterogeneity
problem
and
everybody
basically
has
it.
You
know.
Oh
you've
got
something
going
on
Google
Cloud,
all
that
slightly
different
than
what's
going
on
on
Amazon
and
I'll
Amazon
I
mean
you
know,
you
started
to
figure
something.
B
My
experience
has
been
it's
basically,
you
know
kind
of
three
minutes
with
with
the
code
and
then
three
hours
to
three
days
with
I
am
or
messing
around
with
various
other
things
you
try
to
figure
out
which,
from
you
need
to
make
everything
work
together.
So
this
still,
you
know
a
problem.
You
in
that
context.
That's
the
heterogeneity
problem.
The
other
problem
people
are
starting
slowly
become
aware
of.
It
is
the
temporality
problem.
The
temporality
problem
has
existed,
but
we
haven't
really
thought
much
about
doing
anything
with
it.
B
Consider,
for
example,
a
case
from
I
guess
what
we
might
call
the
old
economy
and
I'd
use
that
not
in
any
case,
in
a
pejorative
way,
if
you
have
a
company
that
has
a
batch
processing
job,
that,
let's
say,
does
billing
reports
and
runs
at
midnight
means
at
2:00
a.m.
it
probably
needs
a
bunch
of
permissions.
Those
permissions
will
probably
configured
once
and
now.
The
permissions
are
open
the
whole
time.
The
rest
of
the
time
that
there's
the
that
the
system
is
running,
even
though
these
reports
aren't
actively
running,
fills
our
security
holes.
B
Take
a
different
example:
you
bring
that
you
spin
up
a
QA
environment
may
be
a
temporary
environment
for
testing
access.
Policies
have
to
come
and
go
for
that
environment
as
they
will.
They
should
be
configured
programmatically.
No
one
should
care,
it
should
just
happen
and
work,
and
when
the
environment
is
no
longer
needed,
they
should
be
pulled
down.
B
Now
you
could
build
all
this
on
top
of
I
am
and
I'm
something
assuming
some
of
you
probably
have
started
that
investment,
maybe
gun's
part
of
the
way,
but
you're,
not
the
only
ones
who
need
that
sort
of
infrastructure.
Everybody
should
be
able
to
leverage
that
we
should
all
be
able
to
basically
say:
ok,
I
need
this
resource
and
temporary
basis.
Oh
ok
gone
done,
and
here's
your
rhythm,
here's,
your
policy.
B
If
I'm
setting
up
a
new
service
that
I'm
releasing,
then
I
should
be
able
to
configure
the
policies
in
advance,
make
sure
everything
works
and
then
turn
them
off
until
the
service
is
ready
to
go
lie
and
then,
when
the
service
is
ready
to
go,
live,
I
should
be
able
to
bring
them
back
up.
You
know
as
I've
scheduled
it
all
for
deployment
on
Tuesday
should
just
happen.
I
shouldn't
have
to
worry
about
it.
I
have
better
things
to
do
than
babysit
my
system.
B
Those
are
the
sorts
of
things
that
we
need
to
deal
with
in
terms
of
temporality.
There's
another
part
of
temporality,
though,
that
when
stop
thinking
about
that
that
aspect
that
comes
through
and
that
is
that
to
a
large
extent,
we
don't
really
think
about
how
policy
distribution
factors
into
things
in
the
distributed
world.
It
takes
time
for
policies
to
get
from
point
A
to
point
B.
B
You
have
to
understand
how
a
policy
is
going
to
behave
if
there's
a
partition
of
the
network,
and
this
I
mean
by
this
I
mean
policy
distribution
right.
So
if
the
policy
still
active,
if
you
want
to
revoke
a
policy,
how
is
that
gonna
work?
How
long
is
it
gonna
take?
Most
of
us
don't
think
about
these
sorts
of
things
as
yet,
but
we
will,
because
when
you
can
create
policies
on
demand,
then
what
our
demand
really
means
becomes
important.
B
So
these
are
the
problems
that
we
are
trying
to
address
with
patterning
we're
aiming
to
build
a
reference
architecture
to
provide
this
kind
of
global
I.
Am
that
you
would
that
one
could
use
our
goals
in
this
context
and
I'm
just
going
to
read
this
off
here,
it's
a
lot
of
text
but
bear
with
you
provable
composable
security
simplicity,
such
ease
of
use
and
well-defined
behavior
in
a
distributed
environment.
That
last
one
based
on
what
I've
just
said
should
be
very
proximate
to
you
right.
B
We
want
to
know
when
policies
get
they
get
to
where
they're
going
other
distributing
things
in
this
nature.
We
want
that
to
understand
the
cap.
Theorem
and
we
want
to
be
able
to
reason
about
it.
Well,
that
reason
is
important
work.
The
reason
that,
for
example,
our
back
is
so
pervasive
is
because
it's
intelligible,
you
define
a
policy
ad
attributes,
it's
a
static
time
binding.
Everyone
can
look
at
that
thing
and
understand
what's
going
on
and
what
should
happen
as
a
result
of
those
policies
in
a
dynamic
world.
We
need
the
same
thing.
B
We
need
our
policies
to
be
intelligible
and
once
we've
defined
a
policy,
we
need
it
to
be
able
to
be
put
together
like
a
Lego,
brick
with
another
policy
in
a
fashion,
that's
also
intelligible.
We
need
to
be
able
to
know
how
they're
going
to
behave
together,
how
they're
going
to
be
distributed,
and
if
something
happens,
what's
what
they're
going
to
do?
We
need
to
be
able
to
test
the
effects
of
these
policies
on
our
traffic
before
we
deploy
them
all.
B
B
What's
a
call
to
talk
about
our
back
a
little
bit
to
tie
everything
back
together
together
again,
so
the
way
that
we've
chosen
to
approach
these
problems
of
of
temporality
and
hegemon
excuse
me
heterogeneity
is
that
first,
we
define
a
common
expression
syntax
so
that
we
can
work
in
an
abstract
universe,
away
from
a
lot
of
the
details
that
are
in
the
specifics.
So
how
do
you
configure
this
kubernetes
container
to
do
foo?
How
do
you
configure
nginx
to
do
bar
I'd
be
changed?
B
Syntax
is
exactly
what
oh
and
I've
got
a
hardware
firewall
here
somewhere
or
my
routers
configured
to
do
the
same
thing:
how
do
I
make
that
apply
the
same
policy
as
I've
got
here,
an
IP
chains,
common
expression,
syntax.
The
next
things
we've
already
alluded
to
is
composable
policies,
policies
that
fit
together
like
Lego
bricks
this
so
that
you
can
understand.
What's
going
on
and
reuse
a
policy,
you
know
works
right,
so
you
know
this
policy
blocks
on
port
80.
B
Great
time,
use
that
as
a
building
block
to
a
larger
pile,
see,
that
does
let's
say
port
80,
and
only
this
service
you,
you
are
off,
you
go
distributed.
Architecture
falls
right
out.
The
architecture
of
policy
deployment
and
policy
enforcement
must
be
distributed
must
be
distributed
so
that
you
can
approach
the
issues
that
happen
in
distributed
systems
in
it.
It's
very
that's
almost
tautological,
but
that's
where
we
are
right.
Last
but
not
least,
component
plug-in,
we
have
a
common
expression,
syntax.
B
We
are
obviously
not
in
and
of
ourselves,
capable
of
handling
every
piece
of
hardware
out
there.
Every
piece
of
software
out
there,
everything
that
you
possibly
can
we
may
be
able
to
handle
some
of
the
major
ones.
Look
for
this
to
fill
its
promise.
You
have
to
be
able
to
bring
your
own
and
other
vendors
have
to
be
able
to
bring
their
own,
and
you
have
to
be
able
to
proceed
from
there.
B
So
a
component
plug-in
architecture
is
required
for
this.
Now
we
understand
in
that
context,
that
our
common
expression,
syntax
may
say
one
thing,
but
if
you
botch
the
configuration
of
a
plugin,
you've
negated,
you
know
the
impact
of
that
and
that's
a
necessary
evil.
We
have
to
be
careful
with
that.
B
Our
assumption
is
that
if
the
plugins,
you
know
because
we've
built
this
distribute
in
a
distributed
distributed
system
in
order
to
or
design
this
distributed
system
in
order
to
handle
these
cases,
we
will
have
to
very
least
be
able
to
come
to
correct
will
problems
we
have
on
mass
and
assuming
that
the
underlying
implementation,
everybody's
gonna
have
this
problem
to
no
dissent
or
another
right.
Assuming
this
implementation
is
correct,
you
will
have
your
provable
security,
so
common
expression,
syntax,
should
be
intelligible,
should
deal
with
the
heterogeneity
problem.
B
Composable
policies
should
be
intelligible,
distributed,
architecture
deals
with
both
heterogeneity
and
temporality,
and
you
know
what
so-called
the
component
plug-ins
deal
with
heterogeneity
will
deal
a
little
bit
more
with
temporality
in
a
minute
when
I
talk
about
what
actually
goes
into
a
policy.
But
first,
let's
talk
about
the
component
expression
syntax
a
little
bit
in
order
to
think
about
the
expression,
syntax.
First,
we
need
a
column
model
for
where
we
apply
policies.
We
call
this
thing:
the
enforcement
surface
onion
and
how
many
layers
this
onion
has
in
its
final
implementation.
B
I,
don't
know
this
is
an
example
of
what
is
possible.
Basically,
what
this
is
telling
you
is
that
your
policy
infrastructure
has
to
be
able
to
address
any
layer
where
you
can
make
a
policy
decision.
Then
you
can
say
well.
Cam
is
the
network
physical
layer?
What
does
that
mean?
Well,
turning
off
a
port
on
a
switch
can
be
a
policy
decision.
It
definitely
has
security
implications.
B
It
is
sometimes
your
last
will
and
only
line
of
defense
should
have
you
know,
ripping
the
plug
out
of
the
wall,
which,
okay,
sometimes
I,
have
to
admit
has
happened.
But
you
know
these
are
the
sorts
of
what's
our
code.
These
are
the
sorts
of
of
things
that
you
have
to
be
able
to
handle
and
we
are,
even
though
you
may
be
interested,
particularly
in
let's
say
the
container
aspect,
or
maybe
you're
interested
in
dealing
with
all
the
network
gear
that
you
have
in
your
network
or
maybe
you're
interested
in
something
else.
B
B
If
you
want
to
define
something
that
sits
in
IP
chains,
that
would
be
the
the
layer
of
the
onion
where
you
would
you
would
be
dealing
with
if
you
wanted
to
set,
for
example,
the
physical
limits
on
the
amount
of
what's
a
cold
memory,
a
process
can
take
on
one
of
your
boxes.
Hardware,
physical
layer
decide
where
your
container
is
going
to
be
run,
probably
at
the
container
layer
want
to
disable
a
particular
endpoint,
possibly
service
that
might
fit
in
the
network
protocol,
we're
still
working
some
of
those
tells
up.
B
But,
for
example,
if
you
wanted
to
configure
which
tables
in
which
queries
are
possible
in
my
sequel,
probably
at
the
application
layer
and
it
can
kind
of
go
on
from
there,
our
intent
is
to
provide
you
know
a
very
definite
structure
of
this
layering
in
some
cases
within
a
given
layer.
So,
for
example,
in
the
networking
layer,
it's
fairly
obvious
what
the
precedence
is,
but
also
a
final
arbiter
I
think
it's
going
to
end
up
being
alphabetical
of
when
all
the
things
are
equal
for
which
policy
gets
applied.
B
First,
because
you
need
to
understand
that
you
may
not
like
it,
but
at
the
very
least
you
need
to
understand.
What's
going
on,
so
you
can
get
that
intelligibility
piece.
So
you
can
reason
about
whether
or
not
a
given
request
will
pass
through
the
system
and
what
you
know
which
policy
will
hit
in
the
grand
scheme
of
things.
B
The
way
this
will
end
up
working
is
that
you
will
define
a
you
know,
a
request
in
terms
of
our
language
passes
through
the
policies
and
then
basically
get
back
an
up-or-down
answer
as
to
whether
or
not
it
made
it
or
not
right
and
that
it
kind
of
goes
from
there.
So
this
having
been
said,
let
me
then
move
on
to
what
comprises
of
policy
in
our
universe.
B
In
our
view,
a
policy
has
a
set
of
rules
that
identify
resources
and
in
our
world
a
resource
is
something
that
it
can
be
accessed
and
because
we're
using
because
we
expect
that
these
policies
will
be
will
be
updated
programmatically
and
that
it
will
be
other
programs
making
the
requests.
It
also
identifies
who's,
making
the
request.
So
in
what
so-called
I
don't
remember
the
exact
details
of
the
the
the
terminology
here,
you
know
the
requester
basically
will
have
a
you
know,
is
a
resource
and
the
request.
B
E
is
a
resource,
and
the
request
e
will
basically
be
able
to
say,
ok
what
requesters
are
allowed
or
disallowed
and
so
forth.
Alright,
so
those
are
the
that's
the
deal
with
the
rules.
The
rules
are,
of
course,
composable.
I
should
be
able
to
say
this
IP
range
and
this
IP
range,
or
this
IP
and
TCP
and
so
forth,
right
within
a
given
layer
and
so
on.
B
Because
that's
what
allows
you
to
build,
you
know
more
complex
policies
without
necessarily
going
to
building
a
little
policy
that
does
port
80
and
another
policy
to
something
larger
and
so
forth.
It
just
gives
you
more
granularity,
but
we
will
get
to
policy
bundling
together
in
a
minute
provable
identity
wherever
possible,
the
system
uses
provable
identity,
whether
it's
something
like
spiffy
or
whether
it's
something
like
Olaf
or
whether
it's
something
like
Kerberos
or
you
know
name.
B
We
pick
your
poison,
obviously,
if
you're,
using
SSL,
certs,
Kerberos,
etc
off
to
right,
then
those
systems
are
built
around
owned,
a
model
of
a
request,
poor
connection
security
and,
if
you're
doing
something
like
amok,
sir,
you
have.
We
have
to
provide
a
way
for
you
to
be
able
to
do
pull,
request,
queries,
but
that's
a
sort
of,
but
that's
the
the
universe
we
expect
to
be
moving
into.
B
Obviously,
at
a
poor
IP
address
level
you're
not
going
to
have
provable
identity,
so
that's
you're,
no
better
you're,
no
worse
off,
then
than
you
were
today
because
we
want
to
address
temporality
head-on.
Time
must
be
a
first-class
citizen
time,
as
a
first
class
citizen
allows
you
to
turn
policies
on
and
off
at
specific
times,
but
it
also
allows
you
to
deal
in
a
same
way
with
propagation
delay.
B
B
That's
guaranteed
consistent,
well,
you're
gonna
pay
for
that,
and
then
you
can
set
the
delay
on
when
the
policy
is
going
to
be
deployed
you
or
or
the
time
in
which
the
policy
is
going
to
be
active,
much
lower,
then
someone
who
hasn't
and
let's
say
they're
gonna,
say
I'm
gonna,
that's
gonna
get
deployed
in
half
an
hour,
not
a
big
deal
right
or
it's
going
to
get
activated
in
half
an
hour.
That's
not
a
big
deal.
B
The
next
thing-
and
this
is
what's
called
something
comes
out
of
modern
needs-
is
that
location
has
to
be
a
first-class
citizen.
You
need
to
be
able
to
say
in
this
universe,
where
you
have
IP
mobility
with
containers,
which
is
I,
think
something
that
a
zero
was
talking
about
and
pretty
sure
they
do
now.
But
it's
been
a
losses.
B
I've
looked
at
it
if
the
IP
address
can
move
between
with
a
container
in
a
data
center
or
possibly,
who
knows
between
data
centers,
then
you
better
be
able
to
say
well,
I,
don't
want
that
container
to
be
moved
outside
of
Dublin
I,
don't
want
that
to
be
moved
outside
of
Germany,
etc.
Location
must
be
a
first-class
citizen.
You
cannot
get
away
with
the
mapping
that
says.
Oh
those
IP
addresses
are
only
assigned
to
that
area.
B
Obviously
the
you
know,
elephant
in
the
room
is
how
do
you
make
those
snippets
work
and
how
do
you
cut
and
paste
different
parts
of
the
policies,
but
that's
something
that
we
have
to
deal
with.
That's
better
than
that's
a
better
problem
to
have
then
the
problem
of
not
being
able
to
configure
these
things
at
all
or
not
being
able
to
distribute.
B
B
If
you
happen
to
use
the
Netflix
case,
for
example,
in
their
model,
which
we
are
base,
which
was
the
inspiration
for
this,
the
general
padme
effort
policies
live
in
RDS
and
it
takes
to
care
of
distribution
for
them
that
will
work
for
them.
That
may
not
work
for
you,
because
you
may
not
be
all
on
Netflix.
You
may
be
somewhere
else,
so
we
have
to
be
able
to
support
hybrid
models,
but
the
controller
allows
you
to
basically
distribute
policies.
The
enforcement
component
is
called
the
enforcer.
B
That's
it's
a
very
imaginative
name
in
this
context
and
the
enforcer
we
haven't
decided
yet
whether
it
should
do
push
or
pull
or
marry
a
difference,
or
you
know,
support
both
for
being
being
able
to
get
policies.
Obviously
each
model
has
its
own
implications
with
you
know
the
pull
model
where
the
enforcer
pulls
the
policies
being
a
little
bit
more
robust
about
the
controller's,
not
knowing
about
the
enforcers,
but
on
the
other
hand,
that
model
makes
it
a
little
bit
more
difficult
to
understand
where
the
policy
has
been
just.
B
You
know,
distributed
within
your
network,
so
there
are
trade-offs
to
be
made.
We
haven't.
Come
to
a
design
decision
there,
but
that
will
come.
The
enforcer
itself
can
either
make
decisions
on
behalf
of
a
component
itself
or
it
can
configure
other
components
to
go
off
and
make
those
decisions.
This
can
be
done
either
plugged
via
plugins
or
directed
so
and
in
our
context,
the
thing
that's
actually
fulfilling
the
request
is
called
a
resource.
B
So
if
you
look
on
and
the
picture
on
your
right
now,
this
will
give
you
an
idea.
So
if,
for
example,
the
enforcer
is
configuring
IP
chains,
then
in
that
case,
when
it's
configuring
that
be
chains,
it
writes
the
IP
chains,
rules
from
the
policies
it
knows
about
and
then
basically
lets
you
change
do
the
business.
This
works
for
cases
where
you
can't
handle
every
request
or,
for
example,
I
mean
you
could
imagine
this
kind
of
architecture
in
a
software-defined
network
universe.
Where,
basically,
you
know
the
switch
pins.
B
You
back
and
says
should
I
let
this
flow
go.
Well,
that's
great,
but
it
can't
make
the
the
switch
can't
make
a
you
know:
HTTP
let
wiring
level
decision
on
single
packet
because
it
doesn't
have
the
whole
request.
So,
as
a
result,
you
know
you
have
to
just
tell
it:
okay
go,
do
this
and
and
then
pass
this
traffic
and
let
something
else
handle
it
right
in
the
model
that
I'm
showing
you
on
the
right
hand,
side.
B
You
have
basically
bits
and
pieces
that
are
configured
and
can
be
configured
by
plugins,
and
you
can
have
plugins
that
handle
this.
And
then
you
have
you
know.
Nginx
can
call
us
back
and
say:
hey
should
I
let
this
request
go
through
and
the
enforcement
will
say
yes
or
no
up
or
down,
and
you
can
proceed
from
there
and
very
obviously
you
could
delegate
a
to
a
plug-in.
Oh
you
do
that
check
from
you
could
also
have
multiple
plugins
that
had
the
different
layers
depending
on
you
know
what
they're
doing
so.
B
You
could
say:
oh
well,
this
guy's
configuring
buffers
and
this
guy's
configuring
them
it's
a
cold.
Oh,
do
you
know
what
ports
you're
allowed
to
handle
right?
We
could
delegate
bits
and
pieces
of,
for
example,
we're
containers
go
to
the
guys
we're
doing
OPA
because
that's
you
know,
sort
of
in
their
in
their
core
or
few
set
of
features,
and
so
that's
essentially
how
we
expect
these
bits
and
pieces
to
interact
with
to
interact
with
one
another.
B
We
are
obviously
in
this
context
trying
to
build
a
system
that
is
fast
enough,
for
you
know
a
multi
hop
in
the
data
center
authentication,
and
so,
as
a
result,
the
checks
are
gonna
have
to
be
down.
You
know,
sort
of
in
the
sub
to
millisecond
kind
of
be
able
to
respond
to
a
request
kind
of
thing,
so
that
doesn't
eat
up
your
all
up
SLA,
and
this
is
the
what's
a
call.
This
is
the
system
architecture.
This
is
how
we
expect
enforcement
to
happen
to
one
extent
or
another.
B
Our
back
does
a
stag
time.
Config,
binding
and
attributes
are
added
to
walls
in
our
universe.
Rules
are
defined
by
the
attributes
that
you
give
them
when
you
define
a
rule
that
identifies
certain
piece
of
traffic
to
match
this
policy
you're
doing
the
inverse
operation,
the
binding
of
who
is
allowed
to
do
what
is
done
at
runtime
when
the
request
comes
in.
B
The
only
difference
between
the
two
is
when
the
binding
is
done
and
we're
striving
to
be
intelligent
as
intelligible
as
the
rback
model.
In
terms
of
what's
going
on
in
my
network,
we
feel
that
as
I
don't
know
how
many
of
you
take
in
a
CS
class
recently,
if
you're
familiar
with
this,
you
know
you
can
move
between
a
condition
variable
mutex
pair
and
a
semaphore
back
and
forth.
The
concepts
are
identical.
We
think
the
saintly.
B
We
are
aiming
to
build
a
secure
system
that
we
can
understand
and
that
will
let
us
address
these
next
generation
problems
and
to
that
end,
let
me
talk
a
little
bit
about
what
we're
actually
doing.
We
are
building
a
reference
architecture,
we
have
a
team
put
together
and
we
are
going
through
the
process
borrowed
resources
from
various
places.
Some
of
us,
like
myself
or
basically,
this
is
our
so
I'd,
give
me
a
full
time
work.
B
We've
got
our
policy
definitions
in
the
sort
of
architectural
structure
in
place,
we're
working
on
building
some
prototypes,
and
if
you
want
to
catch
up
with
what
we're
doing
and
see
where
we
are
and
so
on,
we
have
something
on
github.
You
can
find
our
documentation
there
and
you
can
find
us
at
Padme
IO
again,
I
apologize
for
not
being
there
in
person
I.
Thank
you
for
your
time.
I
hope
this
has
been
useful
and
I
hope
you've
enjoyed
it.
Thank
you
very
much.
A
All
right
so
just
to
emphasize
the
point
like
it's
a
full-on
volunteer
effort,
basically
like
when
I
started,
proposing
this
problem.
There
were
like
a
lot
of
people
that
registered
interest
in
this
problem.
So
the
reason
why
it
in,
despite
him
not
being
able
to
fly
over
the
reason
why
I
wanted
him
to
present
was
like
it
was
full
on
his
effort,
which
is
his
sidekick.
He
works
till
2:00
a.m.
if
money
to
finish
this
out.
So
the
problem
is
real.
People
are
facing
this
problem.
A
There
isn't
a
clean
clean-cut
solution
for
how
you'd
marry
our
back
to
your
existing
infrastructure.
So
you
can
actually
really
solve
this
problem
for
administrators,
not
for
infrastructure,
because
infrastructure
can
solve
by
itself
in
many
different
ways.
So
that's
the
reason
why,
despite
all
the
hiccups,
I
wanted
him
to
present
and
I'll,
be
here,
I
mean
we
don't
have
a
demo
put
together.
I
think
we're
running
out
of
time.
So
we'll
post
the
demo,
it's
it's.
Basically
a
envoy
authorization
plugin.
A
We
have
written
the
plug-in,
you
specify
your
policy
ones
and
then
it'll
get
applied
to
either
my
sequel
or
your
HTTP
restful
endpoint.
In
one
single
way,
with
common
expression-
syntax
that
we
were
talking
about
so
you
can
already
do
that-
we
are
working
on
it.
It's
still
in
a
private,
github
repo.