DOCSEARCHbyAlgolia
Submit Docs

OpenFeature Operator (OFO)

repository·main·Indexed 43 days ago

https://github.com/open-feature/open-feature-operator

A Kubernetes-native operator that manages the delivery of feature flags to applications by injecting flagd sidecars into pods and providing gRPC/HTTP interfaces for evaluation. It includes support for FeatureFlagSource CRs, flagd-proxy, and Helm-based installation and configuration.

Tokens
18.4K
Snippets
49
Records
81
Agent score
55%

What's inside OpenFeature Operator

  1. Understand Multi-tenancy and Security considerations

    main

    The OpenFeature Operator installs cluster-wide and resolves FeatureFlagSource and InProcessConfiguration resources across namespaces using annotation syntax.

    Security Warning: In clusters where namespaces are used as trust boundaries between tenants, a single tenant could potentially cause the operator to read resources from another tenant's namespace.

    For details on the threat model, mitigations, and the roadmap for explicit cluster-scoped resources (ClusterFeatureFlagSource and ClusterInProcessConfiguration), refer to GHSA-398h-7f66-3h4p.

  2. How flagd synchronizes flag configuration

    main

    The flagd sidecar uses different providers to maintain its internal flag state. Depending on your configuration, the security model and synchronization method will vary:

    • kubernetes sync provider: flagd makes authenticated HTTP requests to the Kubernetes API server to retrieve initial state and listens for changes to the registered Custom Resource (CR).
    • filepath sync provider: flagd opens a file watcher on a configured file path. If using the operator's pod mutation logic, a ConfigMap is created and mounted as a volume; flagd watches this file for changes. Data transit is contained within the flagd container.
    • http sync provider: flagd polls a remote HTTP endpoint for configuration. Security depends on the authentication implemented at the remote source.

  3. Understand the OpenFeature Operator architecture

    main
    The OpenFeature Operator (OFO) manages the lifecycle and synchronization of feature flags within a Kubernetes cluster. It works by injecting flagd sidecars into workload pods and configuring them to receive flag updates via various synchronization modes. The operator uses a mutating admission webhook to intercept pod creation and apply necessary configurations based on OpenFeature annotations.

  4. Configure sidecars using FeatureFlagSource

    main

    OpenFeature Operator sidecars are configured by referencing a FeatureFlagSource Custom Resource (CR). You link a Pod to a specific flag source by adding the openfeature.dev/featureflagsource annotation to the PodSpec of your deployment.

    The FeatureFlagSource acts as a central configuration point that defines how flags are synchronized to the sidecar. It can support various synchronization methods including:

    • Flag source: Direct connection to a flag source.
    • HTTP sync
    • File sync
    • GRPC sync
    • flagd-proxy
    flowchart TD
    A[Pod]-->|Annotation: openfeature.dev/featureflagsource| B[FeatureFlagSource CR]
    B--> |Flag source| C[Flag CR]
    B--> |Flag source| D[HTTP sync]
    B--> |Flag source| E[File sync]
    B--> |Flag source| F[GRPC sync]
    B--> |Flag source| G[flagd-proxy]

  5. Configure various Feature flag sources

    main

    The FeatureFlagSource supports multiple providers to fetch feature flag configurations. You define these in the spec.sources list.

    Supported Providers:

    • kubernetes: Uses the FeatureFlag custom resource. The source field should be in the format namespace/custom_resource_name.
    • flagd-proxy: An alternative to direct FeatureFlag access, useful for reducing Kubernetes API load or restricting permissions.
    • file: Mounts FeatureFlag custom resources as volumes to the sidecar. The source refers to the file path.
    • http: Fetches flags from an HTTP endpoint. Supports an optional httpSyncBearerToken and an interval (in seconds).
    • grpc: Connects via gRPC. Supports certPath, tls (boolean), providerID, and selector for filtering.
    • Cloud Blob Storage (azblob, gcs, s3): Uses Go CDK to access cloud storage.

    Note on Cloud Credentials: The operator automatically forwards environment variables with specific prefixes to the sidecar without applying the standard envVarPrefix:

    • azblob: AZURE_STORAGE_*
    • gcs: GOOGLE_*
    • s3: AWS_*
    # HTTP Example
sources:
  - source: http://my-flag-source.json
    provider: http
    httpSyncBearerToken: token
    interval: 5

# gRPC Example
sources:
  - source: my-flag-source:8080
    provider: grpc
    certPath: /certs/ca.cert
    tls: true
    providerID: flagd-weatherapp-sidecar
    selector: 'source=database,app=weatherapp'

# Azure Blob Example
sources:
  - source: azblob://my-bucket/test.json
    provider: azblob
envVars:
  - name: AZURE_STORAGE_ACCOUNT
    value: <account_name>
  - name: AZURE_STORAGE_SAS_TOKEN
    value: <SAS token>

  6. Understand the OpenFeature Operator threat model

    main

    The OpenFeature Operator (OFO) threat model identifies potential attack vectors and security controls for feature flag management. The model focuses on two primary entry points:

    1. Via the application: OFO injects a flagd sidecar container into application pods via annotations. Applications evaluate flags by calling flagd using protocols like REST, gRPC, or sockets (with or without TLS). Attackers may attempt to interact with the application to influence flag evaluation.
    2. Via the Kubernetes API server: OFO listens to webhooks from the Kubernetes control plane. It reacts to pod mutations (to inject sidecars) and flag configuration CR mutations (to update flagd state).

    Security controls primarily rely on authentication for data in transit between the Kubernetes API server, OFO, and flagd.

  8. Understand the OpenFeature Operator RBAC roles

    main

    The OpenFeature Operator operates using the open-feature-operator-controller-manager service account, which is associated with four specific RoleBindings. These roles define the permissions required for different operational aspects of the operator:

    1. leader-election-role: Used for high availability and leader election.
    2. manager-role: The primary role for managing OpenFeature resources, injecting flagd sidecars, and managing flagd-proxy resources.
    3. proxy-role: Used for authentication and access reviews.
    4. flagd-kubernetes-sync: Enables the Kubernetes sync feature within injected flagd containers, allowing them to watch for real-time changes to feature flags.

  9. Use flagd-proxy to reduce Kubernetes permissions

    main

    The flagd-proxy is an experimental pub/sub mechanism designed to watch configuration changes in FeatureFlag Custom Resources (CRs).

    By default, pods require the flagd-kubernetes-sync role binding permissions to watch FeatureFlag CRs. Using flagd-proxy allows you to bypass this requirement for individual workload pods. Instead, the flagd-proxy acts as the single source of truth, broadcasting configuration changes to subscribed flagd instances via gRPC streams. This centralizes the necessary Kubernetes permissions to the proxy itself, tightening security for all other pods in the cluster.

  10. Identify assets managed by the OpenFeature Operator

    main

    The following assets are critical to the operation of the OpenFeature Operator and should be secured:

    • Flag source configuration CR: A Kubernetes Custom Resource containing configuration for the flagd sidecar container.
    • Flag configuration CR: A Kubernetes Custom Resource containing feature flag configurations. Note that this may also contain configuration for the sidecar, though this is deprecated in favor of the flag source configuration CR. Warning: Do not store secrets in flag configurations.
    • Environment variables: Used to configure the flag source if not explicitly declared in the CRs.
    • flagd flag configuration: The active state in flagd's memory, which determines flag evaluation responses. This is sourced from the Kubernetes sync provider, a file (filepath provider), or a remote source (http provider).
    • Personally Identifiable Information (PII): PII used in targeting rules (e.g., email domains) is sent from the workload to flagd. In all currently supported deployment patterns, this data never leaves the node and is never persisted.

  12. How InProcessConfiguration merging works

    main

    When multiple InProcessConfiguration resources are specified in the openfeature.dev/inprocessconfiguration annotation, the operator merges them at runtime.

    Merging Rules:

    • The resources are merged internally by the operator; no changes are made to the actual CRs in the cluster.
    • If there are conflicting keys, the last CR in the comma-separated list takes precedence over the previous ones.

    Example Merge Scenario: If inProcessConfig-A defines port: 2424 and envVarPrefix: "my-prefix", and inProcessConfig-B defines envVarPrefix: "my-second-prefix", the resulting configuration used for environment variable injection will use my-second-prefix because inProcessConfig-B was listed last.