required
field to true
on the authorization
configuration object.
config.yaml
required
, the API will ensure valid credentials are present on all management API requests.
Once authorization has been set to
required: true
all management API routes will require a valid authentication session as well.The UI will require a session-compatible authentication method (e.g. OIDC) to be enabled.Backends
Flipt uses Open Policy Agent (OPA) to enforce authorization policies. OPA is a general-purpose policy engine that can be used to enforce policies across the stack. Flipt supports sourcing policies and external data from various backends. Currently, Flipt supports the following backends:Local
Flipt supports loading policy and external data from the local filesystem.Policies
For configuring policies, the files must be valid Rego files. You can specify the path to the policy file in thepolicy
object in the authorization
configuration object.
policy.rego
Flipt v2 uses
package flipt.authz.v2
instead of v1โs package flipt.authz.v1
. This is a breaking change that reflects the enhanced
authorization model.Polling Interval
Flipt will poll the policy file for changes at a regular interval. By default, Flipt will poll the policy file every 5 minutes. You can adjust this interval by setting thepoll_interval
field in the policy
object.
External Data
In addition to policies that can be used to enforce authorization rules, Flipt also provides a way to pass external data to the policy evaluation from the local filesystem. These data objects must be valid JSON objects. This can be done by setting thedata
object in the authorization
configuration object.
Polling Interval
Like policies, Flipt will poll data files for changes at a regular interval. By default, Flipt will poll the data file every 30 seconds. You can adjust this interval by setting thepoll_interval
field in the data
object.
Key Differences from v1
Flipt v2 authorization introduces several important changes:1. Environment-Aware Authorization
Unlike v1, which operates at the namespace level, v2 introduces a hierarchical model with environments:- Global scope: Full access to all environments and namespaces
- Environment scope: Manage namespaces within specific environments
- Namespace scope: Manage resources (flags, segments, etc.) within specific namespaces
2. Optional Policy Queries for UI Filtering
v2 policies can optionally implement two special queries to enable UI filtering. When implemented, these queries allow the Flipt UI to show only the environments and namespaces that users have access to:These queries are optional. If not implemented, the UI will show all
environments and namespaces, but authorization will still be enforced when
users attempt to access them.Implementing these queries improves the user
experience by filtering out inaccessible resources in the UI.
3. Simplified Request Structure
v2 uses a simplified request structure withscope
field:
Example Policies
Basic RBAC Policy
Hereโs a complete example of a v2 RBAC policy:policy.rego
Example Data Structure
The accompanyingdata.json
file defines role bindings:
data.json
- Global admins: Full access to everything
- Platform team: Manage all namespaces in production, read/update in staging
- Developers: Full access to specific namespaces in development, read-only in staging
Migration from v1
When migrating from v1 to v2:- Update package declaration from
flipt.authz.v1
toflipt.authz.v2
- Add environment context to your role bindings
- Optionally implement the UI filtering queries:
viewable_environments
andviewable_namespaces(env)
for better UX - Update request handling to use the new
scope
field instead ofresource
/subject
- Remove bundle configurations as theyโre not supported in v2 (yet)
Existing v1 policies will not work without modification. Plan your migration
carefully and test thoroughly before deploying to production.