►
From YouTube: CNCF SIG-Security Meeting - 2018-06-15
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
ABAC
B
A
A
A
B
C
A
Here's
the
minutes
talk
if
we
can
get
a
couple
of
long
tears.
We
have
a
use
case
today,
then
we're
going
to
have
good
discussion
from
the
entry
team,
discussing
actions
based
control
in
the
enterprise
news
case,
so
in
a
bit
of
a
back
person,
are
back
debate
and
so
really
wanted
to
make
sure
we
capture
minutes
today.
Couple
folks.
C
C
A
A
D
A
A
C
C
On
this
side,
the
misc
risk
management
framework
is
out
for
public
comment
until
Monday
and
if
anybody's
interested
in
you
know,
chiming
in
and
trying
to
twist
them
in
a
different
direction
like
something
less
organizational
hint
hint,
you
know
be
my
guest,
that's
open
to
the
public
and
I
know
from
being
on
this
side.
They
read
all
the
comments:
they're
required
sort
of
bailar
by
edict
inside
of
NIST
to
respond
to
them.
C
The
NIST
frame
risk
management
framework
is
pretty
important
because
this
version
of
it
tries
to
do
a
crosswalk
to
853
and
covers
the
lifecycle
issues
with
SDLC
and
deal
with
some
of
the
newer
technology.
So
if
it
falls
short,
its
kind
of
on
us
to
not
office,
it's
on
us
to
not
help
them
get
there
in
some
response.
In
some
guidance-
or
rather,
let's
see
another
thing,
I
wanted
to
bring
up.
Is
anybody
on
this
group
use
cucumber?
D
A
C
That's
the
domain-specific
language
that
it
uses
that's
kind
of
a
preference,
for
you
know
an
automated
DevOps
friendly,
more
security
and
risk
aware
framework,
because
it
incorporates
the
domain
aspect
of
things
in
a
systematic
way
that
other
ones
do
not
so
I'm,
not
sure
what
I'm
gonna
do
with
it.
I'm
gonna
bring
this
to
the
standards
groups
that
I'm
in
and
say,
hey.
Let's
take
a
look
at
this.
We
need
a
way
to
address
where
to
put
our
natural
language,
annotations
and
artifacts
for
the
automation
process.
So
anyway,
that's
that's.
C
C
A
C
From
that
to
something
that's
in
the
code,
that's
traceable.
That
explains
why
you,
you
know
answer
the.
Are
you
sure
question
with
an
explanation
or
you
decide
not
to
or
you
decide
not
to
even
ask:
are
you
sure,
and
as
a
whole,
you
know
panoply
of
problems
around
connecting
up
the
natural
language
things
to
that
so
cucumber
and
that
parallel
DSL
tries
to
address
that
and
make
that
make
it
natural
language
friendly,
have
a
better
continuity
between
code
and
the
requirements
process
and
the
the
test
harness
and
the
rationale
for
the
test
harness.
C
So
it's
it's
a
little
peripheral
for
CN,
CF
and
kubernetes,
but
you
know
you
got
to
be
able
to
orchestrate
these
artifacts
and
figure
out
where
to
put
them-
and
you
know
for
at
least
for
revision
control.
You
need
automation
to
do
that,
so
it
seems
appropriate
to
me
at
this
juncture
anyway.
It
it
may
turn
out
to
be
a
yet
another
dead,
end
and
a
whole
pile
of
dead
end
solutions
that
have
been
trying
to
deal
with
this
since
the
60s.
C
D
C
But
you
know
it's
a
spreadsheet
driven
kind
of
thing
with
one
of
the
cells,
maybe
being
your
natural
language
annotation
from
a
meeting
and
how
you
do
that
in
your
requirements,
you
know,
might
differ
if
you
have
doors
or
one
of
these
other
legacy
products
to
do
it,
but
in
the
agile
world,
and
when
we're
orchestrating
this
intersection
of
operations
and
code,
it's
not
clear
how
to
do
that
in
a
systematic
way
that
has
traceability
that
works
for
forensics
and
scalability.
So
whether
cucumber
is
the
answer
or
not.
C
So
the
last
thing
this
is
short,
my
company
is
doing
a
proof
of
concept
with
stack
rocks.
This
is
a
obviously
commercial
provider.
That's
doing
security
for
containers,
so
it's
kind
of
peripherally
related,
but
DHS
is
a
partial
sponsor
of
this
work
as
well
as
my
company,
so
I'm.
You
know
I'm
open
to
suggestions
from
CN
CF
community
in
this
group
as
to
what
we
might
want
to
ask
them.
You
know
what
tires
to
kick
in
the
proof
of
concept
with
them.
C
It's
gonna
be
hosted
in
their
cloud
with
them
doing
most
of
the
setup,
but
their
initial
concept
for
how
to
do
the
POC
was
to
put
Metasploit
in
there
and
try
to
kick
the
tires
that
way
and
I
was
hoping
for
something
more
systematic
than
that.
So
just
sharing
that
in
case
there's
a
connection
and
that's
all
the
time.
I'm
gonna
monopolize.
A
B
You
know
what
we
I'll
just
kind
of
give
them
some
high-level
framing
and
hand
things
off
to
Mike
has
kind
of
the
the
salient
details
on
things,
but
what
we
were
trying
to
accomplish
was
that
we
were
building
essentially
a
fairly
kind
of
you
know:
indeterminant,
you
know
kind
of
runtime
right
into
the
HR
domains.
What
that
means
is
that
different
organizations
excuse
me
different
development
groups
would
have
different
needs
around
creating
essentially
eligibility
on
the
access
rights,
functional
kind
of
functional
execution
rights.
B
You
know
what
can
they
do
and
not
do
and
applying
that
in
different
organizational
hierarchies
right?
So
there's
going
to
be
a
number
of
different
type
of
attributes
or
criteria,
criteria
which
says:
do
I
have
access
to
this
particular
object
right
or
or
function
do
I
have
the
ability
to
approve
a
given
request
right
kind
of
one
of
the
two
scenarios?
Maybe
something
where
there
is
leave
approval
that
is
going
through
the
system
who
can
actually
say
improve
that
when
maybe
you
a
direct
line
manager
is,
is
stay
on
vacation
as
well
right.
B
So
those
are
kind
of
the
different
scenarios
that
we
were
covering
all
the
way
down,
to
kind
of
much
more
need
for
much
more
secure
conditions
where
say
access
to
Social,
Security
numbers
or
the
abilities
actually
change
someone's
pay
in
the
system.
You
know,
depending
on
even
the
amount
that
you
want
to
give
them
in
terms
of
pay
raise
you
may
not.
Your
access
rights
may
no
longer
be
valid
right.
Given
me
the
inputs
that
you're
driving
through
right,
so
it
fairly
kind
of
complex
use
cases
with
a
lot
of
kind
of
variables.
B
Well,
what's
that
Mike?
No,
nothing
I
just
put
my
microphone
just
make
sure
you
guys
can
hear
me
oh
great
yeah,
so
so,
for
that
being
being
a
Solutions
Architect
over
there
essentially
means
you
know:
you're
a
technical
product
owner
and
you're
architecting
a
lot
of
the
kind
of
solutions
that
you
pushing
forward.
So
with
that
like
to
introduce
Mike
and
take
things
a
little
bit
further.
B
E
You
Jason
hi
everyone,
so
Jason
already
did
the
introduction.
My
name
is
Mike
Irrawaddy
I'm,
the
principal
solution
architect
here,
one
of
the
principal
social
architect
here
at
Leafeon
by
ADP.
So,
as
Jason
mentioned,
my
themes
is
actually
working
on
building
the
access
control
layer
for
live
young.
So
let
me
share
my
screen
and
see.
If
you
guys
can
see
me
see
this
okay,
let
me
know
if
you
can
see
the
PowerPoint.
D
E
Can
see
great
so
I
created
this
deck
essentially
to
highlight
you
know
what
attribute
based
access
control
is.
How
is
it
different
than
row
based
and
towards
the
end?
I
have
several
slides
that
show
how
we
actually
modified
to
work
along
the
lines
that
Jason
mentioned
earlier,
which
is
to
take
on
more
complex
use
cases
that
we
see
on
the
HR
domain
and
you
know
essentially
introducing
what
we
call
criterias
into
into
the
access
control
layer.
E
So
this
is
high-level.
This
is
the
agenda.
We
don't
really
have
to
stick
to
this.
I
just
did
this
to
a
structure
of
my
deck
a
bit
and
if
you
guys
have
any
questions
along
the
way
feel
free
to
ask
you
know,
and
we
can
go
over
that
so
at
a
very
high
level,
in
a
typical
access
control
environment,
at
least
the
one
that
I've
seen
in
most
of
the
enterprises,
they
are
still
role
based
at
the
you
know,
at
the
basic
authorization
policy
or
access
control
rule.
E
Essentially,
you
know
a
subject
needs
to
or
can
operate
on,
an
object
and
the
object.
In
this
case
it's
also
called
resources.
Typically,
it
could
be
anything
from
data
to
you
know
individual
say
like
servers
or
even
like
devices
it,
so
it's
really
fairly
wide
open.
So
the
combination
of
this
subject-
action
and
object-
is
what
we
typically
call
a
rule
or
a
policy.
E
So
what
is
role
based
access
control
right?
So
it's
a
fairly
manual
process
where
you
create
a
role
or
a
security
group,
and
then
typically,
these
policies
that
have
been
implemented
by
the
developers
are
assigned
and
the
users
are
manually
assigned
to
it
as
well.
So
I
give
an
example
here
where
you
know
it's
system,
admins
can
log
into
production,
notes
and
execute
scripts.
Obviously
somebody
needs
to
create
the
role
system
admin
manually.
E
They
they
need
to
assign
the
access
control
rule
to
login
and
to
execute
scripts
also
manually
to
the
role
itself
and
even
the
user.
Sometimes
they
could
sometimes
they're
part
of
a
group
and
the
entire
group
is
assigned
to
the
role
or
individual
users
are
assigned
to
the
role.
Obviously,
there
are
a
lot
of
limitations
here.
If
you
imagine
that
you
know
somebody
then
come
along
and
say:
oh
I
need
like
a
more
granular
type
of
policy
assignment.
E
Then
there
really
isn't
any
other
choice
other
than
to
create
a
new
role
or
a
new
group,
and
obviously
that
cause
a
proliferation
of
roles.
Typically
in
the
system
and
as
more
and
more
of
these
edge
cases
come
in
it's
going
to
be
more
and
more
of
these
roles.
It's
gonna
be
heading
to
manage
and
at
some
point
somebody
will
not
really
sure
how
somebody
or
a
group
gets
assigned
to
a
role.
So
I've
seen
this
happen
before
in
the
past.
E
Okay,
so
how
does
attribute
based
access
control
help
in
this
scenario?
So
this
is
actually
a
quote
from
the
NISD
project
overview
of
access
based
attribute
based
access
control
in
its
most
basic
form.
We
basically
relies
upon
the
evaluation
of
attributes.
The
attributes
itself
can
be
of
the
subject
or
of
the
object
or
even
on
the
environment.
So,
for
example,
like
a
device
type
could
be
an
attribute
or
IP
addresses.
E
So
in
the
previous
example,
if
somebody
then
comes
along
and
say
well,
this
is
still
for
the
system.
Admin
group-
and
this
is
still
for
managing
access,
so
they
can
also
only
them
can
login
to
the
production
notes.
However,
I
want
to
add
this
little
quirk
here
that
says
in
their
office
region
right
with
role
based
access
control
system.
Typically,
what
they'll
need
to
do
is
to
create
an
group
and
then
assign
the
proper
person,
or
you
know,
groups
to
it.
E
So
it's
not
just
looking
at
this.
The
higher
level
policy
which
ace
which
says
can
login
to
production,
notes
we're
also
saying:
well,
you
can
log
into
production
notes,
but
we
also
need
to
check
where
the
production
note
is
located
and
where
you
are
located
and
see.
If
you
we
can
allow
you
access
to
that,
does
it
make
sense
so
far.
E
E
Typically,
it
is
done
at
the
product
level
and
what
I
mean
by
that
is,
if
you're
building
a
more
generic
access
control
like
the
way
we
do
here,
depending
on
which
product
somebody
is
allowed
to
do
something
means
different
things
right,
it
could
mean
they
could
see
somebody's
timesheets
or
it
could
mean
they
could
modify
somebody's
compensation,
but
the
data
that
we
operate
on
is
different.
The
action
that
they
can
operate
on
is
different.
E
So
typically,
the
enforcement
point
is
something
that
we
expose,
maybe
as
an
API
or
as
a
as
a
as
a
module
for
the
products
themselves
to
consume
within
their
code,
and
then
you
have
the
decision
point,
so
this
is
kind
of
like
the
brain
of
the
system.
This
is
where
you
know.
Every
time
a
request
comes
in,
they
look
at
the
assignment
store
where
the
policy
assignments
are
being
stored
and
once
they
have
the
assignment
they
actually
branch
out
to
the
to
this
at
the
third
component.
E
Here
the
policy
information
point
which
typically
have
one
or
more
data
sources
where
they
can
retrieve
the
attributes
for
both
the
subject
for
both
the
objects
and
maybe
even
for
the
policy
itself,
and
they
they
basically
pass
that
back
to
the
decision
point-
and
the
second
point
is
the
ones
that
make
the
final
allow
or
deny
decision,
potentially
with
additional
information
and
return
that
back
to
the
enforcement
points.
So
each
of
the
product
can
do
what
it
is
that
they
need
to
do
so.
E
These
are
essentially
the
standard
components,
standard
names
that
are
that
is
being
used
industry-wide.
There
is
no
real
guidelines
on
how
they
implemented,
whether
it's
a
service
as
a
monolith.
It
could
really
be
anything
as
long
as
it
meets
the
enterprise's
needs
now.
That
is
the
theory
right.
However,
I
have
I've
been
part
of
the
team
that
built
this
in
a
couple
of
companies
other
than
ADP.
So
what
we
found
is
obviously
there
are
other
stakeholders
that
they're
not
really
have
been
taking
into
account
in
the
standard
implementation.
E
Obviously,
the
developers
will
need
to
be
able
to
implement
these
policies
and
apply
them
to
whatever
objects
that
they're
working
on
and
whatever
subjects
or
actor,
that
they're
interested
in
the
security
admins
themselves
right
there's
they
still
need
to
configure
roles,
as
we
call
them
still
the
policies
as
well
that
are
assigned
to
the
roles,
but
in
addition
to
that,
not
necessarily
assigning
users
manually,
but
they
need
to
configure
the
attribute
assignments
and
they
add
the
the
assignment
rules
for
those
attributes.
They
also
need
to
do
other
things
like
running
audit
reports
for
their.
E
You
know
for
their
leadership
and
then
obviously
the
end
user.
They
just
want
to
log
in
and
performs
operations
they
don't
it's
they
don't
want
to
deal
with.
You
know.
I
can't
really
do
this
because
there's
something
wrong
with
the
system,
so
the
system
just
has
to
work.
So
when,
in
thinking
about
this,
there
are
actually
a
couple
more
components
that
I
feel
like
we
need
to
introduce.
E
E
So
what
does
that
means?
So
the
red
areas
here
are
the
ones
that
we
just
added.
So
if
you
look
at
the
flow
essentially
on
how
somebody
needs
to
set
this
up,
if
I'm
a
developer,
then
I
have
to
use
this
development
took
it
during
my
implementation,
so
I
can
properly
define
my
authorization
policies
right
and
that
typically
involves
what
I
want
the
subject
to
be
able
to
do
to
the
component
or
the
object
that
I'm
working
on
once.
That's
done,
then
I
store
it
in
this
policy
store
and
then
at
configuration
time.
E
So
I
found
that
this
company's
two
components
are
essentially
just
basically
a
must-have
for
for
an
access
control
to
work.
Now
we're
getting
to
the
interesting
part.
Once
we
have
all
these
things
set
up,
and
especially
at
ADP,
we
realize
that,
in
order
for
us
to
be
able
to
serve
our
users
properly,
we
really
need
to
make
this
as
real-time
as
possible
right.
So
that's
where
this
idea
of
dynamic
assignment
comes
in
we're
leveraging
an
event-driven
reactor
pattern.
E
So
what
we
realize
is
that
a
lot
of
these
attributes
for
both
the
subject
and
the
object
are
actually
coming
from,
maybe
just
one
or
two
more
data
sources.
So
what
we
do
is
we.
We
basically
make
the
attribute
repository
linked
to
the
policy
information
point
maura
and
they
like
a
pub/sub
mechanism.
So
it's
going
through
a
data
pipe,
you
know
something
like
could
be
like
a
messaging
queue
like
a
Kafka
or
Canisius,
or
something
like
that,
and
then
the
policy
information
point
itself
could
be
an
event-driven
service
that
acts
as
a
reactor.
E
So
any
changes
that
happens
in
any
of
the
web
web
app
or
any
other
app
that
affects
the
attributes.
In
the
repository
we
essentially
get
that
change
events
in
almost
real-time
and
we
can
adjust
the
policy
assignments
properly.
The
other
thing
that
needs
to
change
here
is
that,
because
we
are
evaluating
the
attributes
at
runtime,
sorry
in
real
time,
the
store
that
we
have
is
not
really
a
policy
assignment
store
anymore.
E
A
D
E
This
is
the
one
use
case
that
is,
you
know
fairly
Jeanette
general
in
the
HR
space
is
if
somebody
gets
terminated
right
so
typically
when
somebody
gets
terminated
for
let's
say
for
a
gross
violation
of
misconduct
or
something
we
literally
want
to
get
them
out
the
door
as
soon
as
possible,
because
our
access
control
is
based
on
its
attribute
based.
We
can
basically
say
in
all
of
our
policies
that
we
assign
to
that
employee.
E
We
have
to
part
of
the
attribute
that
we
need
to
look
at
is
if
this,
if
this
employee
record
is
an
active
employee
right
or
if
the
if
the
active
date
is
still
in,
is
still
in
the
future
or
sorry
it's.
How
do
I
say
this?
If
there
is
no
termination
date
in
in
his
or
her
record?
I
guess
I
should
say
so.
If
we
make
that
part
of
the
attribute
assignment
in
the
in
the
access
control
policy
itself,
the
minute
somebody
has
their
termination
date
updated
with
today's
date.
E
C
A
C
So
one
of
the
examples
of
that
is
I
just
had
in
my
head:
it's
when
you
have
a
rule
that
says
nobody's
allowed
into
this
building
without
a
badge
and
the
badge
reader
is
located.
You
know
I
and
I
hide,
but
you
might
have
some
employees
that
are
in
protected
classes.
They
are
in
wheelchairs
or
whatever,
so
you
can
have
rules
that
consult
these
protected
classes
and
have
secondary
policies
that
can
be
invoked
based
on
this
kind
of
information
and
typically
the
policy
creators.
Don't
think
through.
All
of
these
highly
domain
specific
details
right
and.
E
Another
thing
that
I
have
seen
this
use
in
the
past
is
to
actually
temporarily
restrict
access.
So,
for
example,
because
we're
using
attributes
there
is
one
more
sort
of
a
concept
that
is
standard
which
is
the
environment
attributes
and
typically,
what
that
is
is
are
things
like
IP
ranges
or
device
types.
E
So,
let's
say
you
know
an
enterprise
is
located
all
over
the
world,
but
they're
still
in
data
centers,
so
we
have
s/m
as
an
enterprise
as
a
software
provider
for
the
enterprise
we
know
where
the
requests
are
coming
from
and
let's
say
they
tell
us
one
day
that
hey
we're
getting.
We
have
a
breach
in
some
of
our
data
centers.
Please
restrict
access
from
these
IP
ranges.
We
can
literally
plug
those
IP
ranges
in
into
our
attribute
repository,
and
our
policy
assignments
will
react
immediately
right.
E
Cool
so
moving
on
and
again
this
is
getting
more
interesting.
We
are.
We
looked
at
the
type
of
data
that
we
store,
especially
in
ADP
in
the
HR
domain,
and
we
figure
out
that
most
of
them
are
really
hierarchical
right.
So,
for
example,
the
use
cases
that
we'll
deal
with
are
things
like.
Only
a
manager
can
only
approve,
say
time
offs
for
their
employees
right
for
their
own
reports.
E
So
Jason
feel
free
to
keep
me
honest
or
chime
in
if
you,
if
you,
if
you
want
to
hear
well
there,
so
we
introduced
a
graph
database
in
our
system
and
wherever
we
can,
we
try
to
essentially
create
a
replicate
source
of
truth
from
our
real
source
of
truth
in
a
graph
format.
Right
so
with
graph,
you
have
the
ability
to
you
know
to
represent
entities
or
fields
within
entities
as
as
notes
and
the
relationship
between
those
fields.
E
E
E
Sort
of
like
legal
cost
center
is
another
one
right.
So,
for
example,
if
you're
an
enterprise
company-
and
you
have
five
different
cost-
centers
that
are
for
five
different
location
and
it's
cut
across
all
the
different
Harmons.
Your
say,
like
your
compensation
product
or
your
budgeting
product,
may
need
to
look
at
the
score
center
to
decide
who
can
act
on
which
departments
budget
who
can
approve
them?
Who
can
reject
them?
Who
can
manage
them
that
type
of
stuff?
E
Now?
What
does
that?
What
that
means
for
the
actual
system
itself
is
we
actually
put
an
extra
layer
in
the
middle
here
before
we
evaluate
the
attributes
for
access
control?
What
we
do
here
is
that
the
attribute
repository
still
pushes
change
events
out
to
the
data
pipe,
but
we
have
an
additional
subsystem,
basically
in
the
middle,
which
is
the
graph
reactor
which
takes
the
same
change
events
and
wherever
relevant,
maintains
the
graph,
so
it
updates
the
graph
it
creates.
New
notes,
creates
new
edges
and
then
it
the
graph
itself
emits
its
own
change
events.
E
The
access
control
system
now
listens
to
the
graph
change
events,
wherever
it's
relevant
and
depending
on
what
changes
it
will
process
and
update
the
runtime
assignment.
So
this
is
basically
how
the
system
works
at
the
moment,
and
this
is
like
sort
of
like
the
whole
picture,
I'm
just
going
to
gloss
off
of
this.
This
is
this
is
basically
what
we've
been
discussing
so
far.
What
I
do
want
you
to
go
to
look
at?
E
Is
this,
though,
so,
once
we
have
once
we
started
going
down
this
path,
and
you
know
we
were
defining
the
products
and
the
benefits
of
using
the
graph
two
things
that
come
up
is
it.
We
can
use
it
as
a
source
of
data
for
attributes
like
what
I
just
went
through.
You
know,
as
far
as
hierarchical
scoping,
what
we
call
it
or
data
entitlement.
However,
what
makes
it
really
powerful
in
our
opinion
is
that
we
can
use
the
graph
itself
to
represent
the
policy
definition.
E
For
example,
if
we
go
back
to
the
sort
of
like
the
access
control
statement
in
the
beginning,
where
you
have
your
subject
that
can
operate
on
an
object
and
when
you
think
about
roles
and
security
groups,
we
can
represent
them
as
nodes
in
the
graph
right
and
then
the
graph
edges
essentially
represent
the
relationship
between
them.
So
a
subject
belongs
to
role
and
policies
are
assigned
to
the
role
and
therefore
the
subject
is
authorized
to
do
those
policies.
E
Thinking
about
graph
and
traversals
within
the
graph.
We
can
do
so
much
more
with
the
kind
of
traversal
queries
that
we
cannot
do
with
a
flat
or
relational
data
structure,
data
stores.
So,
for
example,
if
if
there
is
a
role
called
a
junior
manager-
and
there
is
a
policy
that
says
manager
can
see
their
team
members
compensation
and
a
manager
can
see
they
can
update
their
team
members
compensation,
we
can
actually
create
this
more
granular
level
of
access
control
and
allows
for
policy
inheritance.
E
So
what
I
mean
by
that
is
a
senior
manager
is
at
the
level
higher
than
a
junior
manager.
If
there
is
a
role
between
sorry,
if
there
is
a
relationship
between
senior
manager
and
junior
manager
in
the
graph,
we
can
assign
the
C
their
team
members
compensation
policy
to
the
junior
manager
role,
therefore
allowing
them
to
have
it.
But
then,
because
the
senior
manager
is
a
level
above,
we
don't
really
need
to
reassign
that
policy
again,
just
because
they're
a
senior
manager
they
encapsulate.
E
Capsule
eights
everything
that's
below
them,
and
in
that
case
we
only
need
to
add
the
update,
their
team
members
compensation
policy
at
the
senior
manager
role
note
and
adjust
in
time
access
control
changes.
This
is
basically
what
we
discussed
earlier,
because
everything
is
sort
of
like
event-driven.
We
we
are
actually
able
to
modify
our
run
time
assignment
and
since
we're
treating
it
more
as
a
cache
than
of
anything
else,
the
decision-making
process
is
literally
changing
just
in
time
as
the
attribute
changes
the
make
sense
to
anyone.
Any
questions
on
this
yeah.
B
Mike
just
around
non
hierarchical
structures
and
the
ability
to
address
kind
of
similar
thing
ready,
a
scenario
there
would
be.
Maybe
you
know
number
of
employees
are
on
the
same
project
at
a
company
or
they're
part
of
the
same
group,
but
these
are
not
structures
that
fall
into
the
typical
HR
hierarchies
right.
B
E
So,
in
addition
to
de
Graaff
sort
of
graph
attributes
that
we
use,
we
are
still
maintaining
the
ability
to
essentially
for
somebody
to
create
something
like
almost
like
a
sequel
query
right.
If
the
source
of
truth
is
flat
or
relational,
then
we
can
still
query
the
attributes
from
the
table
that
were
interested
in
and
via
the
same
event-driven
mechanism.
E
E
Figured
all
right,
so,
let's
get
into
the
criteria
stuff
I,
don't
actually
have
a
slide
for
it,
but
basically
what
that
means
is
when
we
find
out
when
we're
talking
to
a
lot
of
our
clients
and
anything
clients,
the
ability
to
define
these
attributes
are
really
client
specific
and
even
in
some
clients,
the
large
enough
client
is
almost
department
specific
right.
So
what
that
means
is
as
a
developer
on
the
the
development
side,
there's
only
so
much
that
we
can
do
to
predefine
all
these
policies.
E
We
need
to
build
a
mechanism
for
the
end-user
to
define
these
attributes
themselves
and
apply
them
to
policies
and
at
execution
time
at
runtime.
So
what
we
come
up
with
is
a
way
for
them
to
almost
literally
define
their
sequel.
Query
upfront
we,
as
I
mentioned
before
and
as
Jason
alluded
to.
We
actually
still
have
two
different
types
of
attribute
resolution.
One
is
this
graph
based
one
and
the
second
one
is
still
the
relational
database.
E
You
know
the
flat
data
structure
one,
so
we
are
building
what
we
call
a
criteria
based
system
where
we
will
have
a
Web,
API
front-end
for
say,
like
a
security
admin
or
even
an
HR
admin
to
go
in
and
define
the
data
entitlement
role.
So,
for
example,
if
an
HR
manager
says
only
a
certain
level
of
managers
can,
you
know,
can
actually
approve
promotions
for
their
department
or
their
division,
except
for
the
people
that
are
in
another
office
location.
E
That
is
not
something
that
we
can
define
on
the
development
side
of
things
just
because
it's
so
granular
and
it's
so
specific.
So
that's
that's
why
we
need
to
do
this.
The
criteria
based
right
now
is
turning
into
more
or
less
like
an
eligibility
engine.
So
essentially,
this
is
just
another
type
of
attributes
that
we
need
to
resolve
and
store
in
our
cache
so
that
when
the
user
actually
tries
to
perform
an
operation
on
our
system,
we
check
against
this.
This
attribute
as
well.
E
So,
okay,
so
the
last
slide
I
have
here
is
really
not
about
anything
that
we've
done
before
and
there's
a
reason
for
it.
So
there
is
a
an
effort
by
this
oasis
consortium
to
create
a
an
access
control
policy.
Language
is
called
sac
mo.
It
stands
for
extensible
access,
control,
markup
language,
I
think
they
started
this
effort
in
the
early
2000.
They
released
their
3.0
version
of
the
3.0
syntax
of
the
language.
A
few
years
back
in
one
of
my
previous
job,
I
actually
tried
to
use
this.
E
It's
very
verbose
and
in
most
cases
in
my
mind,
it's
a
little
bit
of
an
overkill
even
for
enterprise
systems,
but
it
is
very
proposed.
I
put
some
links
in
there
as
references.
If
you
guys
are
interested
the
wiki
page,
Oh,
believe
it
or
not,
actually
has
a
great
summary
on
it,
and
it
has
all
the
external
links
in
there
a
minute.
That's
really
all
I
have
so
you
know
open
for
questions.
If
anybody
has
anything.
Hopefully
this
has
been
helpful.
D
C
Yes,
we
have
questions.
Thank
thank
you
so
much.
This
is
a
very
interesting
and
it's
great
to
see
somebody
doing
this
I
talk
about
it,
a
lot
not
doing
it
very
much
when
you
implemented.
This
thing
was
very
concerned
that,
given
the
sometimes
fragility
of
you
know,
highly
scaled
assets
like
Active
Directory,
that
the
access
control
thing
that
you
built,
which
is
called
a
thing,
is
too
fragile
to
to
scale
properly.
E
If
a
user
tries
to
go
to
say
like
an
HBO
website
and
whether
or
not
they
actually
purchase
HBO
and
we
actually
use
Zack
Mel
there,
so
it
the
policy
itself
is
pretty
verbose
and
we
haven't
really
seen
any
issues
with
scalability.
The
one
thing
I
would
say,
though,
what
on
what
we
are
doing
now
we
do
take
some
precautions
around
the
the
event-driven
system
right
at
the
back
end
that
essentially
updates
this
policies.
E
Real-Time,
because
that's
one
of
the
areas
where
you
know
it's
asynchronous,
there's
always
like
some
precautions,
so
we
need
to
make
there.
So
we
do
have
other
services,
some
sort
of
like
a
recon
service,
essentially
that
monitors
discrepancies
and
tries
to
report
on
it
and
tries
to
fix
it
in
real-time,
but
I
haven't
really
seen
any
scalability
issues
per
se.
It
also
I
think
it's
a
part
of
the
the
good
thing
about
access.
Sorry,
attribute-based
access
control
is
that
there
is
no
really
just
one
way
to
build
this
and
that's
why
they
break
it.
E
Apart
into
those
components,
you
can
scale
each
of
the
components
up
or
down
depending
on
your
needs.
So
if
you
see
a
lot
of
attributes
coming
in,
then
maybe
you
want
to
scale
your
information
point
and
your
decision
points,
but
you
know
you
can
keep
your
enforcement
point
in,
however
mechanism
you
already
have,
or
vice
versa,
I.
C
What's
the
best
way
to
say
this,
I
think
their
challenge
is
real,
that
the
intersection
of
the
number
of
people,
the
number
of
changes
being
made
to
policies
number
of
groups
that
have
to
handle
the
crosswalk
to
all
the
resources
that
active,
Active,
Directory
and
LD
after
manage,
is
a
challenge
by
itself
and
if
you
try
to
put
an
overlay
of
attributes
on
top
of
that,
because
really
that's
that
implementation,
really,
if
you
think
about
it,
is
its
primitive.
In
many
senses,
right
I
was.
E
Just
going
to
say
so,
I
have
you
I.
We
have
overlaid
this
type
of
system
on
on
an
LDAP
before,
but
honestly,
at
that
point,
the
aldub
is
becoming
more
no
more
than
just
sorta
like
groupings
of
users
right
we
we
don't
actually
use
sort
of
like
their
access
control
ability.
We
just
basically
use
it
as
a
user
store.
C
A
C
The
attributes
is
tied
to
their
domain
model,
understanding
of
their
application-
yes,
they're,
obviously
not
too
well
educated
about
in
the
first
place,
even
in
the
role
world,
they're
not
too
well
educated
and
the
decision
about
what
attributes
need
to
be
pushed
out
is
one
that
they
have
to
tackle
for
logging
and
auditing,
as
well
as
alerting
so
I
wonder
how
that
got
surface
when
you
struggle
with
that.
So.
E
I'll,
give
you
two
examples:
I
guess
in
at
Comcast.
Our
attribute
list
isn't
anywhere
near
as
big
as
in
a
DBS
right,
because
at
the
end
of
the
day,
it's
like
cable,
cable,
channel,
maybe
device
type,
maybe
browser
time,
maybe
IP
addresses
and
those
are
yes,
those
are
domain
specific,
but
the
the
engineers
they're
more
or
less
know
their
domain.
Now.
What
we're
doing
here
at
ADP
is
a
completely
different
animal.
E
We
are
actually
building
a
platform
right,
so
even
the
engineers
on
the
platform
side,
they
don't
know
what
the
business
logic
is
on
the
application
that
they
that
other
people
are
building
and
other
teams
are
building.
So
we
we
actually
built
a
Jeanette.
So
there
are
other
generic
platform
functionalities
that
we
are
building
that
allows
us
to
essentially
hook
into
their
source
of
truth
right.
E
So,
if
I'm,
an
application,
developer
and
I'm
using
the
Leafeon
platform
to
build
an
application,
I
have
a
way
already
to
figure
out
to
basically
define
that
schema
by
table
to
basically
define
my
sequel
queries
and
as
a
part
of
that,
we
do
on
the
authorization
side,
we
do
have
access
to
the
fields.
On
the
tables
that
people
will
that
people
can
use
as
attributes
so
we're
dealing
with
like
a
meta
data
on
our
site,
essentially,
and
therefore
we
left
the
domain
knowledge
of
the
attribute
more
at
the
business
domain
level.
E
So,
if
I'm
working
on
like
a
like
a
payroll
application,
I
know
what
all
my
payroll
fields
are
and
what
they
mean
and
what
kind
of
policies
we'll
need
to
put
around
it
right.
So,
especially
in
the
HR
world
and
the
payroll
world,
we
deal
a
lot
with.
You
know:
PII
and
SPI,
extensive
different
personal
information
and
personally
identify
sorry
and
identifiable
information
right.
So
we
do
need
to
put
some
precautions
around
it,
but
we
do
realize
that
it's
not
possible
for
an
engineer
who
is
building
this
to
understand
all
those
attributes.
E
E
C
Promise
to
shut
up
but
I
have
to
jump
in
again
with
some
of
the
use
cases
you
gave
us
were
what
we
think
of,
as
in
the
security
space
cross-disciplinary
right
like
yes,
I'm
gonna
do
with
firewalls
and
infrastructure
stuff
right,
absolutely
yeah.
So
that's
that's
in
a
security
domain.
If
you
want
to
think
of
it
that
way
in
a
simplistic
sense,
so
so
that
part
is
sort
of
hard-coded.
Is
that
how
you
deal
with
it?.
E
No,
not
necessarily
I
mean
we
haven't
really
used
this,
or
at
least
I
haven't
in
sort
of
like
an
infrastructure
type
of
policies,
but
the
the
example
that
I
give
you
around
like
let's
say:
well,
it's
it's
kind
of
like
crossing
both
domains.
So
let's
say
a
a:
what
do
you
call
it?
A
a
partner
of
Comcast,
let's
say
HBO
right,
HBO
doesn't
want
people
to
access
their
their
website
or
their
online
streaming,
video
app
if
they
live
in
a
certain
region
or
if
they
come
in
through,
like
a
certain
IP
ranges
on
their
site.
E
D
I
want
to
just
interrupt
because
we've
just
got
a
minute
left.
Thank
you
so
much
Mike
for
the
presentation.
I
think
it
sparked
a
lot
of
discussion.
Oh
and
Mark.
Thanks
for
all
your
questions,
I
want
to
point
out
that
we
had
a
prior
presentation
from
OPA
that
talked
about
their
regular,
be
to
policy
language
which
is
I,
think
an
evolution
of
what
exact
one
was
trying
to
do.
So.
D
D
Great
and
then
Mike,
if
you
do,
you
have
a
link
to
the
slides
and
the
github
issue,
or
would
you
mind
sharing
those
I
will.