Skip to content

Security Operator

The Security Operator manages OpenFGA stores, authorization models, and tuples. It is responsible for setting up the authorization infrastructure that other operators and the webhook use.

Overview

The Security Operator handles three main responsibilities:

  1. Store Management - Creates and maintains OpenFGA stores
  2. Authorization Models - Writes authorization model DSL to stores
  3. Tuple Management - Writes and deletes tuples based on resource specs

Note

Account relationship tuples (creator → owner role, parent relations) are managed by the Account Operator, not the Security Operator.

Configuration

Field Description Example
config.fga-target OpenFGA server address <openfga-target>
Store.metadata.name Store name (from logical cluster) <store-name>
Store.status.storeId Resolved store ID <store-id>
Store.status.authorizationModelId Current authorization model ID <authorization-model-id>
Store.spec.coreModule Core authorization module <core-module>
Store.spec.tuples[] Tuple definitions object/relation/user
AuthorizationModel.metadata.name Model resource name <resource-plural>-<org-name>
AuthorizationModel.spec.storeRef Reference to target store name, cluster
AuthorizationModel.spec.model Authorization model DSL <model-dsl>
AuthorizationModel.spec.tuples[] Model-specific tuples object/relation/user

Defaults

  • Tuple finalizer: core.platform-mesh.io/fga-tuples
  • Store finalizer: core.platform-mesh.io/fga-store
  • Authorization model schema version: 1.2

Store and Model Resolution

Store ID Resolution

Store IDs are resolved through the following process:

  1. List stores by name
  2. Create a store if missing
  3. Update the name if it drifts

Source: internal/subroutine/store.go

Authorization Model ID Resolution

Authorization model IDs are:

  1. Written with WriteAuthorizationModel
  2. Stored on the Store status

Source: internal/subroutine/authorization_model.go

AuthorizationModel from APIBindings

AuthorizationModel resources created from APIBindings set:

  • spec.storeRef.name → org name
  • spec.storeRef.cluster → org origin cluster

Source: internal/subroutine/authorization_model_generation.go

Tuple Management

Written on Reconcile

Tuples are written from the current spec.tuples list for either Store or AuthorizationModel resources. The tuple writer uses the Store status IDs; for AuthorizationModels, it resolves the Store via spec.storeRef.

Source: internal/subroutine/tuples.go

Example tuples (when allow-member-tuples-enabled is true):

# User Relation Object
1 user:* assignee role:authenticated
2 role:authenticated#assignee member core_platform-mesh_io_account:<account-origin-cluster-id>/<account-name>

Source: internal/subroutine/workspace_initializer.go

Deleted on Reconcile or Removal

  • During reconcile: Any managed tuple that no longer appears in spec.tuples is deleted
  • During finalization: All managed tuples are deleted

Deletions use the same storeId and authorizationModelId sources as writes (no origin/generated ID split in this operator).

Source: internal/subroutine/tuples.go

Org vs Non-Org Store Behavior

Store Type Behavior
orgs Authorization model generator skips discovery of additional core and privileged modules
Non-org Discovers APIs in the org workspace and appends those module files before writing the model

Source: internal/subroutine/authorization_model.go