r

    Rounak Datta

    1 month ago
    Hello, consider a SaaS ecosystem where you have the following hierarchy: tenant->team->project. Now let's say someone is viewer for a tenant, that person should be by default viewer for every project under every team in that tenant. How do we achieve this using scoped policies?
    As a follow up, if the owner of the tenant decides to make that person administrator for one particular project (say
    android
    ), how does one achieve that as well?
    To reference the following, I'm slightly confused how does the policy YAML look like https://cerboscommunity.slack.com/archives/C028A53GAJE/p1655726043248899?thread_ts=1655263347.936209&cid=C028A53GAJE
    Charith (Cerbos)

    Charith (Cerbos)

    1 month ago
    So, scoped policies are how you can define tenant-specific overrides. I think what you're asking is how to manage permissions for individual users. One way to do that is by using the hierarchy functions. Essentially, you can write your policy rules to inspect the hierarchy the principal belongs to and the hierarchy the resource belongs to ( which are sent as attributes in the Cerbos request).
    - actions: ['*']
        effect: EFFECT_ALLOW
        roles: ["admin"]
        condition:
          match:
            expr: "hierarchy(request.principal.attr.projectScope).ancestorOf(hierarchy(request.resource.attr.projectScope))"
    If your user has the
    admin
    role and a
    projectScope
    attribute of
    project.x
    , and if the resource has a
    projectScope
    attribute of project.x.component.athen access would be granted. But if the resource has a
    projectScope
    of
    project.a.component.c
    it won't be allowed.
    r

    Rounak Datta

    1 month ago
    Damn, this is quite cool!
    v

    Viet Au

    1 month ago
    @Charith (Cerbos) your hierarchy rule above looks interesting, I have one question. Will this be against a resource or principal policy? But if you have a resource or principal then you already know the scope. Or can you define an arbitrary rule?
    Charith (Cerbos)

    Charith (Cerbos)

    1 month ago
    So, the
    projectScope
    I used in my example is not related to
    scope
    in scoped policies. It's just bad naming on my part. Sorry about the confusion. The example is demonstrating how you can store relationships between particular users and resources in your system and write Cerbos policies to make access decisions based on those.