►
From YouTube: Cloud Native Live: Modernizing Authorization
Description
From Basic Roles to Decoupled ABAC
A
Hello,
everyone
Welcome
to
Cloud
native,
live
where
we
dive
deep
into
the
code
behind
Cloud
native
I'm,
Annie,
talabaster
and
I
am
a
cncf
Ambassador
as
well
as
I
lead
marketing
at
vision
and
I
will
be
your
host
tonight.
So
every
week
we
bring
a
newsletter
presenters
to
Showcase
how
to
work
with
Cloud
native
Technologies.
A
They
will
build
things,
they
will
break
things
and
they
will
answer
all
of
your
questions,
so
you
can
join
us
every
Wednesday
to
watch
live
so
this
week
we
have
Alex
here
with
us
to
talk
about
modernizing
authorization
very
excited
for
this,
and
as
always,
this
is
an
official
live
stream
of
the
cncf
and
as
such
it
is
subject
to
the
cncf
code
of
conduct.
So
please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
B
Great
thanks,
Eddie
hi,
everyone
very
happy
to
be
here
today,
speaking
about
authorization
and
service,
which
is
an
open
source
project
that
helps
you
decouple
authorization
out
of
your
application
code
and
into
something
that's
a
bit
more
manageable
and
scalable.
So
just
to
kick
it
off
make
sure
we're
all
on
the
same
page.
B
Today
we're
going
to
be
talking
about
authorization
and
not
authentication,
which
are
two
terms
that
sound
very
similar
and
we
all
kind
of
shorten
them,
as
we
do
as
software
developers
to
things
like
auth,
n
and
auth
Z,
but
they
are
two
kind
of
very
different
different
concepts.
So
authentication
is
about
really
identifying
who
the
user
is.
You
know
they
provide
some
credential.
You
get
back
some
sort
of
signed
token
or
something
you
know,
JWT
that
certifies
to
that
person
is
who
they
say
they
are,
and
then
authorization
is
about.
B
Okay,
now
you
know
who
the
person
is,
what
are
they
actually
allowed
to
do
inside
of
your
system?
So
you
know
this
being
cncf
I'm
sure
many
of
you
are
familiar
with
kubernetes
and
things
like
are
back
inside
of
the
kubernetes
system
and
our
back
being
role
based
access
control.
That
is
one
type
of
authorization
and
then-
and
today
we're
going
to
be
talking
about
application
layer
authorization.
So,
once
you've
got
an
application,
you
have
your
end
users.
Those
users
might
have
different
roles.
B
How
do
you
actually
manage
what
those
users
can
do
inside
of
your
app
education
in
a
way?
That's
kind
of
manageable,
scalable,
very
Cloud
native,
in
the
way,
it's
kind
of
deployed
and
managed
very
kubernetes
friendly
Etc,
and
to
do
this,
we're
going
to
go
actually
go
through
a
journey
of
actually
implementing
a
very
simple
application,
with
no
permissions
and
kind
of
go
through
the
growing
pains
as
aware
of
information
authorization
and
then
demonstrate
how
you
can
use
the
open
source
project
servers
to
do
this.
B
If
you
want
to
dive
straight
into
server,
so
you
can
find
it
up
in
GitHub,
github.com,
surboss,
I
think
we'll
put
the
link
in
the
chat
shortly
there
we
go.
If
you
want
to
go
dive
straight
in
or
service.dev
is
the
website,
so
let's
go
kick
it
off.
I
have
a
very
simple
node
Express
server
here
and
we
are
going
to
basically
go
through
and
Implement
a
correct,
create,
read,
update,
delete
as
well
as
some
kind
of
application
specific
permissions.
B
Now
it's
quickly
run
you
through
how
this
application
works.
It's
going
to
be
a
simple
service,
it's
in
sort
of
node
typescript,
that's
just
because
what
I'm
most
familiar
with
and
because
we're
going
to
talk
about
authorization
and
not
authentication,
and
we
we're
doing
some
basic,
authentic,
fake
authentication,
where
we're
passing
through
a
header
in
the
request
of
a
user's
name
and
then
behind
the
scenes.
We
have
a
database
of
these
users,
so
this
would
be
usually
coming
from
your
identity
provider
or
your
own
application
authentication
system.
Maybe
it's
a
no
auth
exchange.
B
Maybe
you've
got
a
JWT
token,
but
each
user
has
an
ID.
We
have
some
rules,
so
these
could
be
like
claims.
Inside
of
your
token,
even
so,
in
this
case
we
have
users,
we
have
admins,
we
have
managers,
and
then
each
user
has
some
attributes.
In
this
case
we
have
a
couple
of
attributes
around
what
department
they
belong
to
and
what
region
they
belong
to,
and
these
you
can
imagine
in
like
a
sort
of
typical,
maybe
like
SAS
type
application.
B
These
would
be
your
users
in
your
database
in
terms
of
what
the
application
does
is
for
managing
expenses,
so
we're
Andy
and
I
were
just
talking.
We
were
at
cubecon
a
couple
of
weeks
ago
and
we
have
like
expenses
that
we
need
to
go
and
claim
back.
So
we
want
to
submit
these
into
our
system
and
an
expense
resource
inside
of
our
system.
Has
this
shape,
so
it
has
an
ID.
B
So
our
basic
API
here
has
a
few
routes,
one
for
getting
an
expense
one
for
seeing
who
approving
expense.
We've
got
one
here
and
for
actually
doing
the
approval.
So
the
person
that
maybe
in
you've
got
a
web
UI
you've
got
mobile
app,
that's
hidden
this
API,
if
you're,
actually
doing
the
approval,
updating,
delete
you
typical
crowd
of
things.
B
So
this
API
is
up
and
running
and
I'm
using
kind
of
Postman
here,
just
to
kind
of
show
you
some
requests,
so
we
have
a
request
coming
into
a
particular
expense,
I'm
going
to
tend
to
be
different
users
by
setting
a
different
header,
and
in
this
case
all
users
can
do
all
actions,
because
there's
currently
no
permissions
in
place.
But
from
like
a
business
process,
point
of
view,
I've
actually
implemented
the
main
actions,
and
you
know
we
can
pretend
this
is
updating
a
database
and
those
kind
of
things
behind
the
scenes.
B
If
the
person
is
an
admin,
then
they
should
be
able
to
do
all
actions,
so
they
should
be
able
to
do
those
create
read,
update,
delete
type
permissions
if
they're
in
the
finance
team
and
the
finance
team
is
defined
by
someone
having
the
role
of
user
and
in
the
Department
of
Finance,
then
they
should
be
able
to
view
all
the
expenses.
If
you
had
approved
all
the
expenses
and
then
they
should
be
able
to
do
the
approve
action
only
under
certain
conditions
and
these
conditions.
B
Sorry,
my
camera's
gone
very
blurry
and,
under
these
conditions,
is
where
we
start
coming
into
the
difference
between
our
back
and
ABAC.
So
our
back
or
roles
based
access
control
is
the
way
of
do
permissions,
where
you
simply
check
whether
a
user
has
a
particular
role
or
not
so,
for
this
admin
use
case,
it's
pretty
simple.
We
want
to
go
and
check
whether
the
user
is
an
admin.
B
So,
for
this
view
route
we
basically
want
to
go
and
write
a
big
if
statement.
So
if
the
user
dot
rolls
dot
includes
admin,
then
you
know
we
go
and
like
do
the
action
and
then
in
this
case
we're
just
returning
the
the
response,
and
if
you
don't
match
that
case,
then
we
actually
want
to
go
and
return
back
to
that.
Api
I
got
403
saying
you
know,
error.
B
Actually,
not
permissive,
and
you
know
here,
we've
just
done
the
very
first
check
where
we
work
out
whether
you're
an
admin,
that's
a
pretty
simple
one,
but
now
if
we
go
and
look
at
okay,
the
next
case,
so
the
finance
team,
your
rollers
user,
your
department
is
finance
and
you
should
be
able
to
view
all
the
expenses
okay.
So
we
go
like
if
user
rolls
dot
include
user
and
we
go
and
actually
look
at
an
attribute
of
the
user.
If
user
attribute
dot
Department
equals.
A
B
For
that
view
command
and
now
you
could,
you
know,
sit
here
and
start
iterating
through
all
those
different
setups
and
you're
going
to
have
to
go
and
do
this
for
each
of
these
and
I'm
going
to
flip
over
to
an
example
rather
than
coding,
this
all
live,
but
you
can
see
here,
we've
implemented
all
that
logic.
So
here's
that
the
view
rule
we've
done
with
the
with
the
checks
on
the
attributes
if
you
go
and
look
at
the
approve
status.
B
So
if
we're
going
to
look
here,
so
admin
can
do
all
the
finance
team
can
approve.
If
it's
open
and
they
didn't
create
it,
so
we're
going
to
look
here
where
now
we
said
admin
can
do
it.
In
this
case,
we
just
like
we're
turning
some
Vera
returning
the
approved
message.
So
for
the
case
where
you
have
to
be
the
owner,
we're
checking
if
you're
a
user,
your
Finance
team,
the
status
of
the
expense
is
open
and
that
you
only
did
not
create
it
other
person
making
the
request
did
not
create
it.
B
So
you
can't
approve
your
own
expenses
and
make
sure
they're
not
equal.
Then
we
return
the
actual
expense,
if
not
return,
sort
of
error,
and
we
can
go
and
keep
evolving
this
and
adding
and
adding
more
logic-
and
this
is
great-
you
know
getting
started
something
quick
off.
You
go
implements
that
that
if
else
statement
and
the
keys
are
very
simple,
but
now,
if
you
imagine
all
applications-
kind
of
evolving,
Are,
We
Now
moving
to
microservices,
because
we've
got
an
as
kubernetes
cluster,
we've
got
teams,
Building,
Services
and
JavaScript.
B
We've
got
teams,
Building
Services
and
go
we've.
Got
teams
burn
services
in
Java
when
the
requirements
change,
which
they
undoubtedly
will
anytime.
You
have
to
go
and
implements
logic.
You're
gonna
have
to
take
essentially
that
business
logic
so
that
that
ticket
we've
got
and
take
this
and
kind
of
map
it
into
JavaScript
and
map
it
into
go
and
map
it
into
Java
and
map
it
into
XYZ.
B
Other
weird,
wonderful
language
that
has
come
along
this
week
into
your
system,
and
this
is
where
things
start
falling
down,
because
you're
now
going
to
have
to
go
and
touch
all
your
application
code
when
the
requirements,
change
and
you're
going
to
have
to
go
and
rewrite
and
re-implement
that
logic
each
time
re-release
your
application
having.
Hopefully
all
the
tests
are
passed
and
kind
of
hope
that
the
logic
is
implemented
correctly
because
you've
had
to
do
it
in
multiple
languages.
B
So
what's
the
alternative
for
this,
and
this
is
to
move
to
a
policy
or
a
configuration
based
workflow
rather
than
hard
coding
that
logic
in
there-
and
this
is
where
surboss
is
the
project
that
we're
going
to
be
talking
about
today.
That
helps
you
kind
of
implement
this
business
logic
as
configuration
policy
rather
than
code.
B
So
this
is
a
a
playground.
Instance.
We
have
created
I've
in
order
for
us
to
actually
get
some
real-time
feedback
or
based
on
whether
the
logic
is
implemented
correctly.
I've
set
up
some
example
users,
so
these
users
are
the
same
one.
We
just
saw
in
the
application,
so
they
have
an
ID.
They
have
a
role,
they
have
some
attributes
and
then
the
resource
they're
trying
to
access
here
are
some
example,
resources
of
different
amounts
and
it's
the
same
kind
of
object.
We
saw
so
we're
working
with
the
same
kind
of
test
data
here.
B
So
if
we
go
to
go
and
Implement
a
policy
for
our
resources,
so
expense
is
our
first
resource
we're
going
to
create
this
expense
resource,
we're
going
to
give
the
name
of
the
resource
and
expense
and
there's
some
example.
Actions
in
here
which
we're
going
to
go
modify
so
our
first
rule
again
was
admins.
B
Can
do
all
actions
so
we're
going
to
create
a
wildcard
rule,
and
this
is
essentially
all
the
different
rules,
all
the
different
actions
that
users
can
do
upon
an
expense
resource
and
we're
going
to
say
that
for
all
actions,
the
effect
of
this
should
be
allow.
So
a
in
the
case
where
this
matches
you
should
be
allowed
and
we're
going
to
say
that
for
this
rule
says
for
all
actions.
If
you
match
the
role
of
admin,
the
effect
is
allowed.
So
this
policy
and
these
roles
are
looking
at
the
request
or
looking
at
the
user.
B
B
View
so
how
who
you
can
go
and
view
a
resource
so
going
back
to
our
business
rules,
we're
saying
to
view
so
admins
we've
already
covered,
because
this
wildcard
will
match
it
for
the
finance
team.
You're
allowed
to
view
it.
If
your
role
is
a
user
and
your
department
is
finance
or
you
have
to
view
it
if
you
created
it
now
in
this
case,
I
could
go
and
write
a
lot
of
repeating
Logic
for
the
cases
of
both
the
finance
team
and
the
owner
in
this
case,
for
a
a
gear
resource.
B
So
the
way
I
could
do.
This
is
go
and
set
up
and
hardcode
and
like
write
that
logic
as
an
expression
in
here,
but
what
I'm
actually
going
to
do
is
create
something
called
a
derive
rule,
so
derive
rules
allows
us
to
essentially
at
request
time
based
on
the
inputs
of
who
the
user
is,
and
what
the
resource
they're
trying
to
access
and
set
up
and
and
derive
further
rules
for
that
user.
For
the
scope
of
that
request,
and
the
most
common
example
for
this
is
a
an
owner
role.
B
These
conditions
here
are
using
cell
common
expression,
language,
which
some
of
you
might
be
familiar
with:
it's
an
open
source,
Google
project
and
where
you
can
get
quite
well
very
expressive
with
your
business
logic
and,
and
it
gives
us
basic
ability
to
write,
binary
type
type
logic
or
look
and
logic
based
on
inputs,
and
the
inputs
in
this
case
are
the
person
making
the
request
and
the
resource
they're
trying
to
access
going
back
to
our
use
case
a
case
again.
So
this
Finance
team
member
is
actually
another
kind
of
derived
role.
B
So
this
person
is
a
user,
but
they
also
have
to
be
in
the
Department
of
Finance,
so
rather
than
typing
it
out
I'm
just
going
to
go
and
copy
this
over.
So
now
we
have
this
another
derive
role
that
says
you
you
get
or
you're
granted
the
finance
role.
If
you
are
a
user
and
your
department
is
finance
and
that
matches
this,
this
stays
at
Point
here.
B
B
So
now,
hopefully,
you've
seen
as
I've
been
typing
down
here
in
the
bottom
right,
we've
been
getting
some
sort
of
live
feedback
as
we
kind
of
experiment
and
work
in
these
different
policies,
so
I'm,
currently
being
someone
that's
in
like
the
IT
department,
so
I
have
the
admin
role.
So
I
did
a
permission
to
view
this
particular
expense
and
if
I
go
and
look
at
different
expenses,
they're
going
to
be
allowed
aloud
and
this
one's
owned
by
Sally.
B
So
if
I
go
and
look
at
one,
that's
owned
by
someone
else,
so
here
we
have
the
owner
Frank.
If
I
go
and
look
at
this
as
someone
that
hasn't
got
the
admin
role,
in
this
case,
a
user
in
this
case
Sally
she
gets
access
denied.
So
cannot
do
the
view
permission
or
cannot.
Do
the
view
action
upon
the
upon
that
particular
resources
making
request.
B
So
going
back
to
our
business
logic.
Again,
we
have
all
this
logic
around.
Who
can
approve
so
we're
saying
it
must
be
opened.
The
status
must
be
opened
and
if
they
mustn't
have
created
it,
it's
the
only
and
you
must
be
in
the
finance
team
to
go
and
do
the
approval.
So
what
does
that
look
like
I
am
going
to
go
and
grab
a
snippet
again
and
just
to
say
typing
out
and
we'll
talk
you
through
it.
So
we're
gonna.
B
We
have
another
action
in
here,
which
is
a
proof
and
would
say
for
the
approve
action
it
should
be
allowed.
If
you
again,
you
have
that
derived
role
of
Finance,
so
you're
in
the
finance
team,
and
this
time
we
have
a
couple
of
conditions
in
place
so
as
well
as
checking
that
you're
in
that
team
by
looking
at
that
department
attribute
we're
also
now
checking
for
these
two
conditions
of
if
it's
open
and
they
didn't
create
it.
B
B
And
now,
if
we
go
and
look
at
here,
we're
getting
that
feedback
as
we
sort
of
go
and
look
at
different
resources
who
can
be
allowed
to
do
what?
If
you're
going
to
look
at
someone,
that's
in
the
finance
team
here,
they're
allowed
to
do
the
approve
on
this
particular
resource
because
it
is
status
said
to
open
and
the
owner.
B
So
let
me
jump
back
to
another.
There.
We
go
I'm
going
to
jump
over
to
this
example,
which
is
our
exact
same
API,
but
here
we've
actually
implemented
the
code
of
servers.
So
the
way
service
runs
is
is
a
container
that
you
run
alongside
your
application.
You
know
in
the
kubernetes
world
we
always
recommend
writing
this
as
like
a
sidecar,
and
we
have
Helm
charts
as
well
for
any
other
services
Etc.
B
They
have
this
role
they're
in
this
department,
they're
in
this
team,
open
for
you
to
Define
they're
trying
to
access
this
particular
resource.
So
you
pass
through
the
resource.
It's
an
expense.
Has
this
ID
it's
in
it.
Has
this
amount
it
has
this
status
Etc
and
what
action
the
user
is
trying
to
do.
I'm,
trying
to
create,
read,
update,
delete
view,
approve
and
open-ended
based
on
you
to
Define
inside
of
your
policies,
so.
A
B
Service
instance
is,
in
this
case,
I'm
just
running
it
locally,
so
we've
imported
the
serverless
SDK,
there's
sdks
for
most
of
the
language
out
there
now
find
it
all
on
GitHub
we
connect
from
the
service
to
that
service
instance,
in
this
case
I'm
just
talking
to
localhost.
That's
why
I'm
running
it.
If
this
is
inside
your
cluster,
it
might
be
the
cycle
path
or
might
be
like
service.
B
Stop
server,
stop
service.cluster
local
or
it
depends
how
you
want
to
deploy
it
in
this
case,
we're
actually
using
grpc
as
well
and
again,
it's
very
focused
on
performance.
Authorization
is
in
the
critical
part
of
every
request,
so
you
don't
want
to
be
going
out
over
the
Internet,
especially
to
make
authorization
checks.
B
So
it's
designed
to
be
all
local
can
be
completely
air
gapped,
there's
no
external
dependencies,
and
this
service
instance
is
you
talk
to
it
from
your
application,
then
going
down
to
the
actual
request
handlers
where,
before
we
had
these
big,
if
else
wrong
one,
we
had
these
big.
If
else
case
switch
style
blocks
in
the
service
version,
we
simply
make
a
call
to
that
service
instance.
B
So
we've
set
up
service
SDK,
we've
got
our
expense
and
we
pass
into
it
the
principal
so
in
this
case
the
user
that
made
the
request
the
resource
so
we're
telling
it
what
kind
of
resource
and
we're
passing
in
that
full
object
or
about
the
resource
that
that
user
is
trying
to
access
and
what
action
they're
trying
to
do
in
this
case,
View
and
further
down,
we
have
like
the
approve
action,
and
here
we
have
the
update,
delete
Etc.
Then
what
comes
back
from
serbos
is
for
each
action,
a
very
simple
Boolean.
Is
this
allowed?
B
Yes
or
no?
So
what's
going
on
here
behind
the
scenes?
Request
comes
in
from
your
end,
users,
from
to
your
service,
your
services
grabbing
that
user's
identity
and
from
your
IDP
or
the
token
it's
grabbing
the
resource.
That
user
is
trying
to
access
from
your
own
application
database.
So
you
might
be
doing
a
SQL
query.
You
might
be
going
to
hit
some
other
API,
it
might
record
another
service
and
then,
rather
than
in
the
application
code,
doing
that
big.
B
If
else
k
switch
style
statement,
we
pass
that
context
from
Europe
from
inside
your
app
to
that
service
instance
running
right
alongside
it
saying
I've
got
this
principle
trying
to
do
this
action
on
this
resource
and
it
was
should
it
be
allowed
on
denied
inside
a
servers.
Servers
has
taken
that
input
of
principal
resource
and
action,
evaluating
your
policies
and
then
simply
returning
back
and
allow
a
design
decision,
which
means
you
only
have
a
single.
B
What
what
should
happen
so
at
this
point,
we've
just
gone
and
messy
replicated
what
we
had
hard-coded
and
here
I
actually
have
the
policies
similar
to
the
ones
we
had
in
the
playground,
with
all
that
business
logic
defined,
Etc
and
I'm,
going
to
go
and
start
up
a
service
instance,
so
I'm
going
to
start
serbos.
This
is
now
running
locally
in
my
machine.
B
Our
API
is
now
up
and
running
and
I'm,
going
to
use
Postman
to
go
and
hit
it,
and
here
we're
getting
kind
of
back
decisions
and
there
we
go
I
got
a
action
denied
response
for
trying
to
get
this
particular
expense,
expense,
four,
which
I
just
know
from
implementation.
Is
that
not
one
that
this
user?
In
this
case
Sally
is
allowed
to
access?
And
we
actually
go
and
look
in
the
service
logs?
And
we
can
confirm
that
that
request
has
been
denied
servers
itself,
creates
full
audit
logs.
B
B
What
happens
if
the
requirements
change,
so
we
have
another
ticket
or
another
issue
here
from
said
Annoying
product
manager
me
and
we're
saying:
we've
had
some
client
requests
and
we
want
to
have
a
different
option
and
a
different
permissioning
type
role
inside
of
the
system
and
the
business
Logic.
For
this
particular
example,
is
we
no
longer
want
to
have
a
single
Finance
kind
of
role?
B
B
And
if
you
imagine,
we
had
this
all
hard
coded
before
we'd
have
to
go
and
update
all
that,
if
else
case
switch
style
logic
in
not
just
this
service,
but
every
other
service
that
relies
on
the
kind
of
those
permissions
to
handle
this,
and
that
logic
is
going
to
be
spread
because
across
potentially
many
request,
handlers
across
many
services
and
many
numbers
of
languages.
Because
we've
done
this
decoupling,
there's
now
one
place
and
one
source
of
Truth
or
what
our
permission
logic
is.
B
So
let's
go
and
look
at
our
policies
as
before,
we're
actually
going
to
go
and
create
a
derived
role
here,
just
to
kind
of
simplify
some
of
the
logic.
So
we
now
have
that
Finance
derive
role
which
we
had
earlier,
which
just
checks,
if
you're
a
user
and
in
the
finance
team,
whilst
our
finance
manager
derive
role
here-
is
a
parent
role
of
manager.
B
So
that's
coming
through
from
your
IDP,
so
we're
checking
whether
that
exists
and
your
department
is
finance
so
now
we're
creating
this
derived
rule
at
request
time
for
every
request
that
comes
in
and
in
our
resource
policy.
We
want
to
go
and
look
at
the
approval
logic.
So
here
we
have
our
approval
logic
as
before,
but
now
for
our
regular
Finance
team
members,
we
have
a
new
condition
which
says
that
it
must
be
less
than
50
000
the
amount
field.
B
So
the
amount
attribute
of
the
expense
that
this
user
is
trying
to
approve
must
be
less
than
50
000.
in
this
case,
and
if
you
try
and
approve
it
and
you're,
just
a
regular
Finance
user
and
it's
over
that
amount,
this
will
fail
and
you'll
get
a
permission
denied
as
you
kind
of
expect,
based
on
our
business
rule.
B
B
And
in
this
case,
we're
going
to
have
essentially
the
same
conditions
as
before,
but
we're
going
to
take
away
that
50
000
sort
of
limit.
So
just
to
recap:
we've
added
a
new
derived
role
of
finance
manager
where
the
user
has
the
parent
role
of
manager
and
they're
in
the
finance
team.
We've
added
a
new
rule
here
that
says
the
action
should
be
approved,
excuse
my
typo.
B
The
action
here
will
be
allowed
and
the
approval
should
be
allowed
if
you
have
that
finance
manager
derived
role
regardless
of
the
amount
and
we've
added
the
condition
here,
which
says
to
do
the
approve
action
and
you've
in
the
regular
Finance
team.
The
amount
must
be
less
than
fifty
thousand
so
because
we're
big
fans
of
the
GitHub
style
workflow
here
at
serboss
and
being
kind
of
a
player
in
the
cloud
native
ecosystem.
Everyone
loves
githubs
and
we
have.
B
We
can
actually
go
and
write
full
unit
tests
against
it,
which
I
won't
dive
into
here.
But
we'll
we'll
point
I'll
point
you
to
the
documentation
for
this,
but
we've
written
some
examples
of
conditions
that
we
met,
and
example
inputs
of
resources
and
actions
to
check
that
your
policies
pass.
I
can
go
and
run
these
tests
locally.
So
we
have
CLI,
tooling,
say
look
so
it's
telling
me
I've
got
a
typo
in
my
policy
which
I
do
you
somewhere
there
we
go
derived
roles
run.
This
test
again
still
got
another
roll.
B
B
And
so,
if
we
go
back
to
our
application
and
all
things
being
right,
we
have
our
new
user
if
we
go
and
get
expense
number
four.
Sorry
expense
number,
three,
sorry
as
Frank.
This
is
an
expense.
That's
at
80,
000
Frank
here
is
our
regular
Finance
team
user.
So
if
we
go
and
see
whether
he
can
go
and
do
the
approve
action
on
it,
action
or
permitted,
if
I
swap
to
a
user
that
we
up
that
we
set
on
our
database
as
the
finance.
B
B
I
have
not
changed.
This
lookup
serbos
is
is
receiving
the
the
principle.
The
resource
in
action
from
the
application
service
is
then
evaluating
whether
a
permission
should
be
allowed
or
not,
based
on
the
current
policies
that
are
live
and
returning
back
is
the
same.
Allow
or
that
I
decision
back
to
my
application
code
and
I,
don't
need
to
make
any
changes
here
in
terms
of
how
that's
handled
it's
simply
seconding
is
the
approve
action
allowed.
B
B
If
this
says
set
any
light
bulbs
off
or
or
answers,
maybe
a
pain
you've
had
in
the
past,
where
you
kept
getting
requirements
changing
for
authorization,
do
go
and
check
us.
The
service
project
out
github.com
service
play.service.dev
is
the
playground
that
we've
been
be
showing
you
today
and
then
service.dev
is
the
website,
which
is
a
lot
more
about
this
everything's
open
source
apache2
license
you're
free
to
go
and
use
it
as
you
wish,
and
we've
got
users
both
big
and
small
Now.
B
A
Perfect
so
time
for
the
Q
a
then
so
now
is
the
perfect
time
to
send
in
your
questions.
If
you
have
any,
obviously
you
can
chat
with
Alex,
as
he
kind
of
said
there
in
the
future
as
well.
We
have
all
the
different
means
that
he
set
there,
but
if
you
have
any
questions
now
you
can
type
them
into
the
chat
and
we'll
get
them
answered.
A
A
B
Yeah,
absolutely
so
service
will
be
really
focusing
on
the
developer
experience.
So
I
mentioned
quite
a
few
times
that
the
tool
in
the
CI
sort
of
pipeline
you
can
set
server
servers,
we're
constantly
iterating
and
evolving
on
that
to
make
sure
that
you
have
not
only
a
a
kind
of
smooth
pipeline
for
getting
policy
changes
out,
but
even
up
front
in
terms
of
making
sure
that
the
IDE
and
the
workflow
for
actually
writing
policies
in
the
first
place
is
slick.
B
Question
there
we
go
ask
this
quite
a
lot,
so
this
is
a
Hot
Topic
right
now,
and
particularly
also
the
service
mesh
side
of
things
as
well.
So
where
server
sits
is
in
the
application
layer.
Your
top
level
kind
of
API,
Gateway
or
type
access
is
possible
to
write
kind
of
extension
and
and
have
your
gateway
call
to
serbos,
based
on
Purely
the
request
parameters.
So
in
next
case
the
only
context
you'll
have
about
the
user
and
the
resource
is
maybe
the
authentication
token
or
JWT,
and
what
route
they're
trying
to
request.
B
We
know
all
the
information
about
the
actual
resource
they're
trying
to
access,
so
you
can
go
and
fetch
that
from
your
own
database,
you
have
full
access
to
all
the
attributes
about
that
particular
resource,
and
this
is
where
that
our
back
ABAC
kind
of
story
comes
in
because
in
most
cases
the
permissioning,
as
we
saw
the
examples
here,
is
actually
more
about
the
specific
attributes.
If
we
take
the
example
of
the
action
should
only
be
allowed
if
the
amount
is
less
than
fifty
thousand
dollars.
B
If
all
you
have,
is
the
URL
you're
not
going
to
be
able
to
kind
of
derive
that
so
inside
of
your
application?
Level
kind
of
permissions
and
request
Handler
is
when
you
have
access
to
all
that
state
and
that's
generally,
where
you
would
Implement
service
and
to
do
those
permission
checks,
because
you
can
pass
through
all
the
states
in
from
the
request,
plus
your
own
kind
of
application
state
to
servers
and
use
it
as
inputs
to
make
decisions
upon
inside
of
your
policies.
A
Perfect
now,
if
anyone
has
any
more
questions,
send
them
in
and
I
would
have
now
a
question
from
a
bit
of
a
different
Direction
kind
of
I
love
talking
about
people
with
this
sort
of
what
did
we
say
since
we've
not
been
talking
about
authorization
and
artwork
and
whatnot?
Do
you
have
any
guesstimation
or
any
hopes
for
how
this
field
will
evolve
in
the
future?
How
do
what
would
you
like
to
see
coming
up.
B
Yeah
great
so
when
I
kind
of
look
at
at
this
space
and
kind
of
where
civil
sits,
you
know
we're
in
an
environment
that
isn't
in
isolation.
You
know
we
have
the
authentication
piece
and
we're
now
in
a
world
where
there's
really
kind
of
good
standards,
around
authentication,
You've,
Got,
oauth,
2,
you've
got
jdbts,
there's
a
kind
of
token
exchange.
That's
kind
of
a
very
kind
of
standardized
place.
Authorization
today
is
not
quite
there.
B
B
There's
lots
of
interesting
approaches
or
different
access
models,
and
we
think
service
is
a
good
fit
for
kind
of
your
typical
SAS
B2B
applications
or
internal
services
and
that's
kind
of
the
use
case
we've
built
upon
and
but
there's
also
a
third
bit,
which
is
the
audit
story
or
the
accounting
story,
so
authentication
authorization
and
accounting
and
generally,
what
that
looks
like
is
the
audit
logs.
So
now,
you've
authenticated
someone
you've
authorized.
A
B
How
can
you
actually
keep
track
of
what
they've
done
or
what
they're
doing,
and
that's
why
the
audit
kind
of
story
was
built
into
server
wasn't
day.
One
is
really
capturing
that
output
at
this
time.
This
principal
showed
this
session.
The
resource
and
I
think
there's
a
whole
interesting
ecosystem
in
future
around.
A
Sounds
good
I
love
the
answer,
and
then
we
had
Shuma
asking
about
the
recording
and
don't
worry.
The
recording
will
be
immediately
essentially
available
in,
for
example,
CNC
of
YouTube.
So
you
can
check
that
out
from
there
I
think
it's
under
the
live
streams
tab
there.
So
cncf
YouTube
is
the
place
to
go
for
that
and
then
Alexander
also
had
a
question.
Is
it
possible
to
do
a
partial
check
as
oppa
you
ask
server
service
which
resources
the
user
has
access
to
and
it
returns
a
list,
and
so
the
service
consumes.
B
So
serbos,
we
have
something
called
a
query
plan
where
you
say
to
serbos.
I
got
this
principle
trying
to
do
this
action
on
this
type
of
resource
and
what
service
gives
you
back
and
I'll?
Give
you
a
live
example.
Here
is
a
query
plan.
So
career
plan
from
serbos
is
a
abstract
syntax
Tree
in
AST
of
conditions
which
are
computed,
live
based
on
the
policies
that
are
currently
implemented,
and
this
condition
tree
can
then
be
mapped
into
something
like
a
SQL
where
Clause
it
can
be
mapped
into
a
filter.
It
can
be
mapped
into.
B
You
know
some
filter
on
an
API
call
somewhere,
because
it's
agnostic
to
any
particular
data
storage
technology
and
my
background's
from
like
high
throughput,
the
latency
systems,
where
we
store
data
in
very
specific
databases,
for
very
specific
reasons
for
mainly
for
brand
performance.
So
our
data
wasn't
all
in
one
big.
You
know
postgres
database.
It
was
split
between
you
know,
hbase
and
redis,
and
you
know
some
SQL
servers,
so
we
haven't
coupled
their
service
query
plan
to
any
particular
storage
technology,
is
abstract
and
and
a
very
predictable
and
well
snapshot.
A
B
If
you
found
this
interesting
or
if
you
feel
like
this
is
something
that
is
a
pain
you've
had
you've
had
to
go
and
deal
with
in
the
past,
please
go
and
check
us
out.
Service.Dev
is
the
website
github.com
Service
as
well,
for
the
figure
repo
as
I
said:
everything's
open
source
go
and
use
it.
We
have
users
ranging
from
small
startups
to
multinational
Enterprise
companies.
At
this
point,
we're
here
to
help
we
have
a
slack
Community.
If
you
want
to
jump
in
there,
we
can
ask
questions,
we're
a
globally
distributed
team.