►
From YouTube: Cloud Native Application Authorization
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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
Hi
Alex
livier
here
from
serbos
today
we're
going
to
look
at
a
truly
cloud-native
way
and
approach
to
authorizing
your
application.
Your
business
logic,
using
kind
of
the
modern
technology
stack
and
making
use
of
the
vast
ecosystem
of
cncf
projects
so
quickly
service,
is
an
open
source.
D
covered
access
control
for
your
software.
A
So
a
quick
run
through
of
the
app
this
is
so
Finance,
it's
a
kind
of
an
expense
tracking
system.
I'm
sure
many
of
you
are
familiar
with.
You
know
traveling
for
work
and
having
to
file
your
expenses,
those
sort
of
things.
So
this
is
a
demo
app
node
back
in
route
front,
end
phrase,
symbol,
API
and
kind
of
what
it
exposes
is.
We
have
our
different
users
so
for
Simplicity,
it's
a
very
simple
kind
of
user
switcher
here
and
we
have
users,
they
have
different
roles
so
from
our
identity
system.
A
We
know
what
role
this
person
Sally
is
in.
We've
got
some
attitudes
about
them,
so
if
she's
in
the
sales
department
she's
in
a
mere-
and
this
is
what
the
application
kind
of
allows
so
I
can
go
into
my
expenses.
I
can
see
all
the
expenses
that
I've
submitted
as
Sally
and
they've
got
dates.
Vendors
amounts
these
sort
of
things.
A
If
I
go
into
it,
there's
the
different
actions,
so
I
can
go
and
edit
this
expense,
but
I
can't
approve
or
reject,
because
it's
my
own
expense
and
if
I
were
to
go
back
and
look
at
maybe
when
it's
already
approved
I
can't
edit
it
because
it's
not
approved
so
there's
already
some
business
logic
in
here
that
defines
who's
allowed
to
do
what
and
if
I
go
and
look
over
to
be
this
other
person.
So
now,
I'm
Ian
I'm
in
the
IT
department,
I,
am
an
admin.
So
I
can
actually
see
a
lot
more
here.
A
So
there's
suddenly
I
can
access
to
this
admin.
Section
I've
got
a
report
section
if
I
go
into
expenses.
I
can
now
see
you
know,
expenses
from
Sally
bill.
So
there's
one
from
Frank.
If
I
go
and
look
at
the
actions,
I
can
do
all
actions
because
I'm
that's
kind
of
the
super
user.
You
know
some
other
sections
that
we
pretend
will
be
implemented.
A
Now
we're
going
to
look
at
something
interesting,
so
we
have
Frank
here
so
Frank
is
in
the
finance
team.
He's
a
user
in
the
Emir
Department.
If
I
can
go
into
my
expenses
and
now
I
can
see
all
the
ones
that
have
been
submitted
so
Sally
Frank
Etc.
A
If
I
go
and
look
at
my
Frank,
one
I
can't
improve
it
because
there's
some
sort
of
business
rule
that
says
you
can't
approve
your
own
expenses
and
now,
if
I
go
and
look
at
this
particular
one
from
Global
Airlines
twelve
thousand
dollars,
even
though
I'm
in
the
finance
department,
I
can't
approve
it
and
if
I
actually
go
and
flip
over
to
go
and
be
Derek
he's.
Actually,
a
finance
manager
because
he's
in
the
finance
team
he's
also
got
the
manager
role.
A
A
So
on
our
GitHub,
so
it's
running
a
kubernetes
cluster.
We
have
our
application
layer,
it's
talking
to
an
API,
that's
running,
and
then
the
data
is
being
stored
inside
of
postgres
and
using
Prisma
as
an
orm.
A
We
have
traces
coming
both
from
our
app
and
also
from
servers,
so
we
get
kind
of
open,
Telemetry
tracing,
so
we
can
see
what's
going
on
Prometheus
metrics,
so
our
app
our
and
our
service
instance
are
exposing
Prometheus
metrics,
which
are
being
scraped
and
also
our
logs
have
been
collected
by
Loki,
so
doing
log
capture
from
our
different
containers
that
are
running
here
and
then
exposing
all
that
through
a
graphite
interface.
A
So
if
I
can
flip
over
to
our
grafana,
we
got
various
kind
of
interesting
metrics,
your
typical
sort
of
request
rate
by
path,
request,
latency,
and
we
have
some
metrics
coming
from
my
service
instance.
So
we
can
see
the
different
checks
being
done.
So
there's
like
a
a
check
resource
and
a
plan
resource.
We
can
see
a
number
of
policies
that
are
currently
in
our
cluster
and
we
can
actually
see
our
decisions
so
how
many
allows?
How
many
of
the
dies?
A
How
many
resource
plans
that
have
been
committed
to
have
been
run
and
we're
going
to
what
that
means
in
a
second
and
then
we
also
get
all
the
logs.
So
this
is
all
being
captured
by
Loki.
So
we're
actually
getting
audit
log,
so
every
action
you
see
me
doing
and
clicking
around
is
generating
a
log
which
is
being
outputted
by
serbos
in
a
standardized
format
and
being
in
this
case,
picked
up
by
Loki
and
demonstrated
here.
So
we
can
see
we
have
some
inputs
of
an
expense.
A
We
have
Derek
trying
to
look
at
this
particular
expense.
Id3.
These
attributes
trying
to
see
whether
we
can
view
the
approver
delete,
allow
and
we
can
see
the
different
responses
here.
So
the
allow
for
the
approver
allow
for
delete
deny
for
an
update,
allow
for
approve,
allow
for
a
view.
So
we
actually
get
a
nice
audit
log
and
Order
Trail
and
we
can
even
see
what
my
effective
roles
are
against
those
policies
what's
going
on
for
fluid
to
yoga,
so
we
can
go
and
see
traces
application
traces.
A
So
here,
like
there's,
API
calls
to
go
and
get
a
particular
resource.
We
can
see
the
request
coming
in
here.
We've
got
some
middleware
to
do
authentication
we're
going
to
fetch
the
data
from
the
database
and
then
we
actually
go
and
do
a
check
resource
call
out
to
the
service
instance,
and
that
brings
back
our
results
as
we
saw
kind
of
from
the
other
end.
So
we
fall
from
the
logs
service
making
decision.
This
is
the
Telemetry
tracing
showing
us
of
the
actual
request
pipeline.
A
If
you
very
quickly
go
and
look
at
the
actual
code
and
see
how
this
is
all
wired
up,
so
in
our
server
back
end,
as
I
said,
a
very
simple
kind
of
and
Express
server
in
node,
we
have
different
routes
like
to
render
the
root
page
to
go
and
get
a
particular
expense
and
the
way
this
logic
is
done.
So
we've
authenticated
the
request
already.
So
we
know
from
a
request,
header
authorization,
header
who
the
user
is
and
that's
being
passed
in.
This
request
object.
A
So
when
we
want
to
go
and
get
a
particular
expense,
we
first
go
and
fetch
that
from
the
database,
so
using
Prisma
go
and
look
up
our
ID
and
send
some
attributes.
If
we
can't
find
it
return,
a
sort
of
an
error
and
we've
set
up
some
spans,
so
we
can
get
nice
tracing
around
exactly
what's
going
on
and
then
our
business
logic
is
very
different
rules
around
who's
allowed
to
do
what-
and
you
can
imagine
you
might
end
up
having
to
car
code.
A
If
this,
then
that
or
a
key
switch
style
logic
to
work
out
that
can
this
user
in
this
case
view
a
particular
expense
or
not,
and
that
logic
will
be
kind
of
repeated
across
different
API
handlers.
How
servers
works?
Is
you
just
now
replace
that
with
this
SDK
and
we
have
the
service
SDK,
which
actually
runs
a
check
resource
call?
So
we
now
simply
package
up
the
information
about
the
principle.
So
this
is
our
user,
the
particular
resource
they're
trying
to
access.
So
we
have
the
resource
type
expense.
A
We
have
various
different
attributes
about
it
and
then
different
actions
that
we
want
to
check
permissions
for.
Can
this
person
view?
Can
this
approved
canister
lead?
Can
this
update?
Can
this
approve
that
goes
off
and
then
service
goes
and
checks
those
and
you
get
response
back
for
each
of
those
either
an
allow
or
deny
so
yeah
a
billion,
and
here
we're
just
returning
a
map
of
all
the
different
missions
and
whether
it's
allowed
or
not.
So
these
are
just
booleans.
A
Some
further
logic
to
you
know
hide
certain
Fields
based
on
further
permissions,
but
ultimately
we
will
return
back
an
object
to
the
browser
with
the
the
information
about
the
particular
expense,
if
they're
allowed
to
view
it
and
then
what
permissions
that
user
has
upon
it
and
that's
actually
what's
being
used
to
render
these
buttons.
A
So,
firstly,
to
view
the
page,
you
must
have
the
view
permission
and
then
for
each
of
these
actions,
edit
approve
reject,
delete,
Etc,
that's
being
driven
by
servos
and
that's
coming
back
from
the
response,
and
then
it's
a
similar
setup
for
the
other
action
so
to
approve.
We
look
it
up,
we
go
and
find
it.
We
then
go
and
check
servers
whether
this
user
is
allowed
to
do
the
approve
action
on
this
particular
resource.
If
it
is,
then
we
actually
trigger
it.
A
In
this
case,
it's
a
database
update
to
set
the
status
to
approve
and
set
the
idea
of
who
approved
it
to
the
person
making
the
request
and
goes
off
in
a
similar
Logic
for
those.
So
that's
going
to
actually
look
at
our
policy,
so
our
service
policies
and
we
have
a
set
of
common
roles.
So
these
are
roles.
We're
called
derived
roles
that
will
get
kind
of
added
to
the
request
or
to
the
user
base
request
time.
So,
for
example,
the
owner
you
are
given
the
owner
role
in
the
request.
A
If
the
owner
ID
attribute
of
the
resource
is
equal
to
the
ID
of
the
person
making
the
request
similar,
we
give
you
the
finance
attribute
if
you
have
finances
your
department
and
you're
a
user,
and
we
give
you
the
finance
manager
role.
If
your
department
is
finance
and
you
have
the
parent
role
of
manager,
you've
got
a
finance
manager
and
similar
sort
of
thing
for
regions.
A
Now,
if
we
go
and
look
at
an
actual
resource
policies,
this
is
the
service
expense
resource.
We
have
different
actions,
so
view
approve,
create,
update,
delete
et
cetera,
currently
talking
about,
and
through
these
yaml
definitions,
we
Define
our
business
logic.
So
to
view
it
we're
saying:
You
must
be
the
owner
of
it.
You
must
be
the
finance
team
or
you
must
be
regional
manager
to
see
who
approved
it.
We
only
want
to
show
this
to
people
who
are
either
the
owner
of
the
resource
and
it's
approved.
A
So
here
we
say
to
the
view:
approver
action
is
allowed
if
you
are
the
owner,
so
the
owner
ID
is
equal
to
the
printable
ID
and
the
condition
of
status
is
set
to
approve.
So
you
can't
see
who
approved
a
particular
expense.
Initially,
the
owner
and
it's
approved
or
there's
another
rule
here
that
says
you.
The
view
approved
fraction
is
allowed
if
you're
in
the
finance
or
the
finance
manager
roles.
So
if
you're
at
the
finance
team,
you
can
always
see
who
approved
it,
something
a
bit
more
interesting.
A
Is
these
the
actual
approved
action?
So
our
business
logic
says
a
principle
that
belongs
to
the
finance
role
is
allowed
to
perform
the
approve
action
if
the
amount
is
less
than
ten
thousand
dollars,
and
they
did
not
create
it.
So
here
our
logic
says
the
approve
is
allowed.
If
your
derived
role
is
finance
and
all
these
conditions
meet.
So
here
we're
looking
at
actually
the
attributes
about
the
resource
and
the
principle
to
make
a
decision.
So
all
of
these
must
match
the
amount
field
must
be
less
than
ten
thousand.
A
So
that's
that
less
than
ten
thousand
dollar
rule
the
nrd
must
not
equal
to
the
principal
ID.
So
you
can't
approve
your
own
expense
and
the
status
must
be
opened
now.
Additionally,
we
have
our
finance
manager
role,
it's
just
the
same
logic,
but
there's
no
cap,
there's
no
no
limit
and
what
that
looks
like
back
in
the
UI.
A
So
if
I
swap
myself
over
to
Frank
who's,
just
our
regular
Finance
person
I'm
looking
at
this
expense,
which
is
twelve
thousand
dollars,
it's
not
allowed
if
I
go
and
look
at
it
as
Derek,
the
action
is
allowed.
So
service
is
actually
based
on
the
requests
giving
you
a
dynamic
result
with
each
of
these
actions
and
that's
being
reflected
in
the
traces.
You
know
you
see
these
traces
go
through
here
we
go
the
request
for
Derek
and
the
response
is
coming
back
for
each
of
those
particular
actions.
A
So
now,
let's
say
our
business
logic,
changes
and
we've
got
a
ticket
and
we
want
to
kind
of
evolve
this
logic.
Normally,
you
would
have
to
go
back
to
your
code,
update
your
if
else
style,
statements
to
go
and
change
things
to
reflect
the
New
Logic,
but
because
there
are
application
code
and
our
authorization
Logics
decoupled
through
servers
for
these
policies
and
the
the
API
application
is
actually
doing
a
check
against
the
service
instance.
A
We
don't
need
to
touch
our
application
code
again,
because
all
the
context
about
who's
making
the
requests
and
the
resource
they're
trying
to
access
is
already
being
sent
to
servos,
and
so
in
our
policy.
Here,
let's
say
we
wanted
to
change
it
from
ten
thousand
dollars
to
fifty
thousand
dollars,
because
you
want,
you
know
your
team's
growing.
You
want
to
be
able
to
disseminate
our
responsibility
to
different
parts
of
the
organization
so
now
anyone's
got.
A
finance
role
should
be
allowed
to
prove
it
up
to
fifty
thousand
dollars.
A
So
what
this
ultimately
means
is
our
existing
Finance
user
should
now
actually
be
allowed
to
do
it.
So
I've
made
this
change,
let's
go
and
commit
it
to
our
git
repo.
So
we
want
to
make
sure
we
have
a
nice
sort
of
I
can't
type.
At
the
same
time,
we
want
to
have
a
nice
little
githubsy
style
workflow.
So
I've
now
come
into
that
change.
A
I'm
going
to
go
edit
I'm
going
to
go
again,
commit
it
really
can't
type
I'm
not
going
to
say,
allow
Finance
team
members
to
approve
up
to
50K.
A
And,
of
course,
it's
not
going
to
like
my
dollar
sign
there
we
go
so
I've
made
that
change.
The
logic
is
going
on
I'm
going
to
go
and
push
that
up
to
my
kind
of
Co
repo
and
it's
up
there.
Now
at
this
point
you
could
set
up
kind
of
a
CI
pipeline
in
say
GitHub
actions
or
gitlab,
and
have
this
service
instance
pulled
down,
but
we're
actually
going
to
use
Argo
for
this.
A
So
we
have
our
ago
instance
running
inside
of
our
cluster.
So
again,
it's
all
kind
of
locally
controlled
and
we're
going
to
submit
a
job
to
it.
I'm
going
to
go
and
just
go
into
our
infra
show
you
a
color
make
file.
So
we
have
this
Argo
job
submit
and
we're
going
to
submit
a
workflow
that
that
we
have
available
for
service
and
we're
saying,
go
and
grab
the
policies
from
this
particular
repo.
A
This
demo
app
expenses,
repo
run
that
workflow
and
I'm
going
to
do
this
and
then
I'll
talk
through
what
it
does.
It
takes
a
bit
of
time,
but
that's
now
going
to
go
and
submit
a
job
and
we
can
see
their
jobs
running
and
we
can
go
in
our
Argo
UI
again
running
inside
of
our
cluster
and
see
what's
happening
so
what's
happening
behind
the
scenes,
we
kicked
off
a
job
this
case
manually.
A
Imagine
it
being
triggered
by
a
commit
to
the
Gear
repo
it's
going
to
go
and
claim
clone
down
the
repo
into
it.
So
this
is
now
going
to
go
and
fetch
the
latest
commit
it's
going
to
go
and
fetch
the
latest
policy
change
that
one
we
made
in
that
yaml
file,
and
this
takes
a
little
while
to
run.
But
behind
the
scenes,
it's
you
know,
pulling
down
pulling
down
those
policies,
and
this
workflow
does
a
few
different
things.
A
So
with
serbos,
we
provide
a
full
sort
of
CI,
CD
style
experience,
so
there's
Tooling
in
there
and
to
actually
write
tests
and
evolve
things
over
time
and
running
your
CR
workflow.
Firstly,
validate
that
your
yaml
files
are
in
the
correct
format
against
the
schema
and
then
actually
run
tests.
So
for
serbos
for
this
expenses
resource
we've
actually
have
our
test
defined
here.
So
we
have
some
example
test
data
of
different
principles
with
different
roles.
This
actually
matches
what
you're
seeing
in
UI.
We
have
this
example
different
resources
and
we
have
some
tests.
A
So
here
we're
testing
every
combination
of
user
and
resource
and
action
to
go
and
establish
where
there
are
policies
are
doing
as
we
expect-
and
you
know
catching
on
those
edge
cases
which
undoubtedly
will
occur,
may
not
have
thought
of,
and
here
we're
saying
that,
for
you
know
Saturday
if
it's
particular
suspense,
these
actions
should
be
allowed
denied,
Etc
and
we're
doing
it
for
kind
of
different
ones.
So
we
can
be
certain
what's
going
on
here,
we're
looking
at
different
roles.
So
you
know
we
have
these
principles
of
Mark
and
Simon.
A
They
in
our
sales
managers,
different
resources,
different
actions
and
what
they
expected
results
comes
from,
and
if
we
go
and
actually
look
at
the
approve,
we
have
a
test
that
are
checking
this
approve
action
and
that's
what
Argo
is
now
running
through.
It's
actually
going
to
pull
down
his
policies.
A
Firstly,
validate
that
the
policies
are
behaving
as
they
should
and
then
actually
run
the
tests
against
them,
and
if
we
go
and
jump
back
in
here,
we
can
actually
see
what's
going
on
so
we've
cloned
the
reaper
already
and
we're
running
the
tests,
we're
validating
it.
So
this
is
good,
so
this
this
step
hasn't
failed.
So
all
our
policy
files
are
valid
against
the
specification
of
service
policies
and
then
we
have
the
test
phase.
So
this
is
where
we're
actually
running
that
change
through
the
tests.
A
This
is
now
executing,
and
so
it's
using
serverless
itself
to
actually
run
the
tests,
and
this
has
a
surprise,
surprise
failed.
If
you're
going
to
look
at
the
output,
we
can
actually
see
oh
yeah,
this
particular
expenses
test
for
Frank
for
expensive
three
has
failed.
We
got
to
deny,
but
it
was
actually
allowed,
and
this
is
because
our
our
test
data
for
Frank
and
this
particular
expense
now
breaks
the
rule.
A
A
So
let's
go
and
actually
it's
going
to
fix
that
test,
because
you
know
we've
changed
our
business
logic
and
we
want
to
allow
it.
So
it
was
approvals
for
Frank
for
expenses.
Three,
let's
check
those
right,
yeah
expense,
three
approve
for
Frank
expense.
Three,
so
slash
you
should
be
allowed
now,
because
the
limit
has
changed
so
I'm
going
to
commit
that
again,
we've
got
the
change
classic
fixed
test,
commit
commit
that
in
synchronize
the
changes
up
and
we're
going
to
go
and
just
rerun
on
that
test.
A
So
now
we're
going
to
go
and
give
the
same
process
kick
off
that
job
inside
of
Argo.
Again
it's
kind
of
inside
our
cluster.
So
it's
going
to
go
and
pull
down
the
different
resources.
It's
going
to
pull
down
our
git
repo
and
this
time
it's
going
to
run
through
all
the
tests
and
just
repeat,
I
haven't
touched,
my
application
code,
but
the
only
thing
I've
changed
now
is
our
application
policy.
A
Our
you
know
our
logs,
our
application.
You
confirm
it.
Our
containers
are
still
running,
it's
still
serving
requests.
Our
service
instance
is
still
making
decisions.
Our
index
size
doesn't
change.
A
Everything
is
behaving
kind
of
as
it
should
I
mean
our
log,
our
logs,
as
we
kind
of
Click
around,
let
it
again
Frank
still
denied
and
our
tracing
here
is
kind
of
confirming
that
we
can
see
the
request
going
off.
We
can
see
it
going
off
to
a
service
instance
and
coming
back
so
you
get
that
full
visibility
into
end
of
exactly
what's
going
on
so
now
the
CI
workflow
is
validated.
A
It's
claimed
the
tests
are
now
passed,
and
now
what
the
workflow
is
doing
is
actually
saying
to
the
serverless
instance:
that's
running
inside
the
cluster
saying
yep,
there's
new
policies,
they're
valid
they're
tested,
go
and
pull
them
down,
and
that
service
instance
is
now
going
to
go
and
fetch
the
new
policies.
Now,
if
you
actually
go
and
look
at
the
here
at
inside
of
here,
the
requests
are
kind
of
being
handled
and
we'll
actually
see
an
audit
event
occurring
telling
us
it's
going
to
downloaded
those
new
policies
which
it
has
so
it's
Reloaded.
A
So
the
policies
have
now
been
updated.
The
reload
store
method
has
been
called
so
again
because
of
the
observability
and
tracing
we
have.
We
can
see
exactly
what's
going
on
and
now,
if
I
just
go
and
refresh
my
my
data
here,
so
if
I
go
back
it
out
and
then
this
is
Frank
remember
we
changed
the
logic
this
one.
These
buttons
are
now
enabled.
So
this
action
has
now
been
validated
so
kind
of
summarize.
What's
going
on
here
and
recap,
what
we've
just
seen
through
this
architecture?
We
have
an
application.
A
It's
business
Logic
for
authorization
has
been
extracted
out
into
a
standalone
service
using
serbos
cscf
project
and
that
that
service
instance
is
pulling
down
its
policies
from
a
repo.
We
can
see
exactly
what's
going
on
thanks
to
open
symmetry,
Jager
Prometheus
Loki,
we
have
all
the
logs,
we
have
the
metrics.
A
We
can
see
how
things
performing
we
can
see
the
traces
of
a
request
coming
out
through
the
database
out
into
a
service
instance
before
actually
returning
back
thanks
to
the
eager
traces
and
then
we're
using
Argo
for
end-to-end
workflows
for
compiling
testing,
validating
the
authorization
changes
and
then
once
it's
done
telling
the
service
the
server
service
inside
of
our
cluster,
to
reload
the
policies
and
then
that
is
immediately
reflected
inside
our
application,
because
all
those
checks
are
that
are
not
hard-coded,
they're,
now
being
dynamically
resolved,
based
on
that
service
instance.
A
So
this
is
just
touching
the
tip
of
the
iceberg
in
terms
of
what
you
can
do
using
this
architecture.
But
the
cool
thing
is:
it
enables,
are
fully
very
much
Cloud
native
open
source
as
well
authorization
application
architecture,
plugging
into
all
your
existing
Tools,
around
observability
monitoring,
metrics
in
a
very
Cloud
nativey
fashion,
and
allowing
you
to
iterate
on
your
business
requirements
around
authorization
without
having
to
go
back
to
a
Dev
team
to
go
and
change
the
code
base.
You
can
just
do
it
through
the
service
policies.
A
If
you
want
to
find
out
more
about
this,
the
application
is
up
on
the
service
GitHub
book,
so
github.com
server,
slash
demo,
app
and
expenses,
and
you
can
find
out
more
about
servers
how
these
policies
are
defined,
the
different
tools
and
everything
available
at
service.dev
a
particularly
shout
out.
We
have
a
playground
where
you
can
actually
experiment
and
test
policy
themselves
and
this
example
application.