feat: Authz

[markphelps]

This adds authz to Flipt using Open Policy Agent for both the 'language' used to define the authz policies as well as the enforcement library.

I think that using OPA in this way continues with Flipt's ethos of:

1. Being self-contained/not requiring external services to function (ie not requiring our users to run an authorization service like Authz/SpiceDB, Topaz, etc)
2. Being extremely configurable/composable. (described below)

What/How

This will allow users to enable authz and configure their own policies/data in order to use existing authentication data to enforce authz.

Each API request to Flipt that is to be authorized (management API only) is annotated with a namespace, resource, subject and action similar to our already existing audit events.

The authz policies configured by operators enforce what requests are allowed given:

1. request data (described above)
2. authentication data (described in our docs PR)

Our existing audit events were changed to use these new request types as well, since they map 1-1 to audit events that we already publish.

Configurability

The goal is to allow operators to define their own policy rules via Rego as well as provide optional 'data' that can be used in these policies (think static mapping of user emails to roles, groups, or departments).

Currently, policies and data can only be read from the local filesystem, however, in the near future we aim to include support for:

• git
• oci
• objectstores
• k8s config maps?

Mapping Authn to Authz

A key aspect of this functionality is the mapping of authentication to authorization.
Most OIDC providers have the notion of roles and allow enriching the tokens they create with custom attributes such as roles.

OIDC Providers:

• ✅ Keycloak: (roles) (mapping)
• ✅ Azure (roles)
• ❌ Google: doesn't look like its possible without us writing some code to integrate with their API
• ✅ Auth0: (mapping)
• ✅ Okta: seems like you can have custom roles added to their tokens

In our docs PR, I have written a guide demonstrating how to map a user to a role using Keycloak, that can then be enforced by a policy in Flipt using OPA.

We will likely need more documentation and examples on writing policies in the future.

We have also chosen to make this functionality 'experimental' until we add extensive integration tests and have had the ability to get it in user's hands and garner feedback.

cc @piclemx @erka @GeorgeMac

[GeorgeMac]

I'll just add that; while there are limitations with OIDC providers r.e. doing the role management on the IdP itself, you can always express role mappings in the Rego data. Ultimately this is an email to permissions mapping directly in the data payload. Doesn't necessarily need to include roles, but roles and mappings in the data can be expressed for readability and DRYing up the definitions.

The Rego/OPA Playground demonstrates this if you choose the RBAC scenario.
They have user_roles and role_grants sections in their data like so:

{
    "user_roles": {
        "alice": [
            "admin"
        ],
        "bob": [
            "employee",
            "billing"
        ],
        "eve": [
            "customer"
        ]
    },
    "role_grants": {
        "customer": [
            {
                "action": "read",
                "type": "dog"
            },
            {
                "action": "read",
                "type": "cat"
            },
            {
                "action": "adopt",
                "type": "dog"
            },
            {
                "action": "adopt",
                "type": "cat"
            }
        ],
        "employee": [
            {
                "action": "read",
                "type": "dog"
            },
            {
                "action": "read",
                "type": "cat"
            },
            {
                "action": "update",
                "type": "dog"
            },
            {
                "action": "update",
                "type": "cat"
            }
        ],
        "billing": [
            {
                "action": "read",
                "type": "finance"
            },
            {
                "action": "update",
                "type": "finance"
            }
        ]
    }
}

Then the policy itself knows to perform the mapping from auth email to granted permissions.
It just means in the datasource you will need to manage the user role mappings there, instead of in e.g. Google.
If e.g. these were in Git, that might be a familiar experience for those managing e.g. k8s role mappings in Git via something like Argo / Flux.

[markphelps]

cc @smittysmee

[GeorgeMac]

Awesome. There is one bit of go fmting left I think. Otherwise, good to go.