Skip to content

feature_flag_source.md

Latest commit

 

History

History
284 lines (228 loc) · 9.71 KB

feature_flag_source.md

File metadata and controls

284 lines (228 loc) · 9.71 KB

Flag Source configuration

The injected sidecar is configured using the FeatureFlagSource custom resource definition. The openfeature.dev/featureflagsource annotation is used to assign Pods with their respective FeatureFlagSource custom resources.

A minimal example of a FeatureFlagSource is given below,

apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
  name: feature-flag-source
spec:
  sources:                        # flag sources for the injected flagd
    - source: flags/sample-flags  # FeatureFlag - namespace/name
      provider: kubernetes        # kubernetes flag source backed by FeatureFlag custom resource
  port: 8080                      # port of the flagd sidecar

Feature flag sources

This section explains how to configure feature flag sources to injected flag sidecar.

FeatureFlagSource support multiple flag sources. Sources are configured as a list. Supported sources and their configurations are listed below.

kubernetes aka FeatureFlag

This is FeatureFlag custom resource backed flagd feature flag definition. Read more about the custom resource at the dedicated documentation of FeatureFlag

The following example of a FeatureFlagSource uses kubernetes as the provider type:

sources:                        
  - source: flags/sample-flags  # FeatureFlag - namespace/custom_resource_name
    provider: kubernetes        # kubernetes flag source backed by FeatureFlag custom resource

flagd-proxy

flagd-proxy is an alternative to direct resource access on FeatureFlag custom resources. This source type is useful when there is a need for restricting workload permissions and/or to reduce k8s API load.

Read more about proxy approach to access kubernetes resources: flagd-proxy

file

In this mode, FeatureFlag custom resources are volume mounted to the injected flagd sidecar. flagd then source flag configurations from this volume.

For example, given FeatureFlag exist at flags/sample-flags, this source configuration look like below,

sources:                        
  - source: flags/sample-flags
    provider: file

http

Feature flags can be sources from a http endpoint using provider type http,

sources:
  - source: http://my-flag-source.json
    provider: http
    httpSyncBearerToken: token                  # optional bearer token for the http connection
    interval: 5                                 # optional interval in seconds for http requests

grpc

Given below is an example configuration with provider type grpc and supported options,

sources:                        
  - source: my-flag-source:8080
    provider: grpc
    certPath: /certs/ca.cert                    # certificate for tls connectivity
    tls: true                                   # enforce tls connectivity
    providerID: flagd-weatherapp-sidecar        # identifier for this connection 
    selector: 'source=database,app=weatherapp'  # flag filtering options

Cloud blob storage providers

The azblob, gcs, and s3 providers use Go CDK to access cloud object storage. Because the underlying SDKs expect their native credential env vars (e.g. AWS_ACCESS_KEY_ID, GOOGLE_APPLICATION_CREDENTIALS, AZURE_STORAGE_ACCOUNT), the operator forwards env vars matching the following prefixes to the flagd sidecar without applying the configured envVarPrefix:

Provider Passthrough prefix
azblob AZURE_STORAGE_*
gcs GOOGLE_*
s3 AWS_*

All other env vars are prefixed as usual (e.g. FLAGD_MY_VAR).

Azure Blob Storage

Given below is an example configuration with provider type azblob and supported options,

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

Other types of credentials for Azure Blob Storage are supported; for details see AZ credentials config.

Google Cloud Storage

Given below is an example configuration with provider type gcs and supported options,

sources:
  - source: gs://my-bucket/flags.json # my-bucket - GCS bucket name
    provider: gcs
    interval: 10                      # optional polling interval in seconds, defaults to 5
envVars:
  - name: GOOGLE_APPLICATION_CREDENTIALS
    value: /var/run/secrets/gcp/key.json

On GKE, prefer Workload Identity over static credentials. For the full set of supported URL options see the gocloud blob/gcsblob URL reference.

Amazon S3

Given below is an example configuration with provider type s3 and supported options,

sources:
  - source: s3://my-bucket/flags.json # my-bucket - S3 bucket name
    provider: s3
    interval: 10                      # optional polling interval in seconds, defaults to 5
envVars:
  - name: AWS_REGION
    value: us-east-1
  - name: AWS_ACCESS_KEY_ID
    valueFrom:
      secretKeyRef:
        name: s3-credentials
        key: access-key-id
  - name: AWS_SECRET_ACCESS_KEY
    valueFrom:
      secretKeyRef:
        name: s3-credentials
        key: secret-access-key

On EKS, prefer IRSA or EKS Pod Identity over static access keys; both auto-inject the right AWS_* variables via the pod's service account.

For S3-compatible endpoints such as MinIO or LocalStack, set AWS_ENDPOINT_URL_S3 and (usually) AWS_S3_FORCE_PATH_STYLE=true, or pass URL query parameters directly on the source URI. See the gocloud blob/s3blob URL reference for the full set of supported URL options.

Sidecar configurations

FeatureFlagSource provides configurations to the injected flagd sidecar. Table given below is non-exhaustive list of overriding options. (see full list)

Configuration Explanation Default
port Flag evaluation endpoint port 8013
managementPort Management port 8014
evaluator Evaluator to use json
probesEnabled Enable/Disable health probes true
otelCollectorUri Otel exporter uri
resources flagD resources operator sidecar-cpu-* and sidecar-ram-* flags

Merging of configurations

The annotation value is a comma separated list of values following one of two patterns: {NAME} or {NAMESPACE}/{NAME}. If no namespace is provided, it is assumed that the CR is within the same namespace as the deployed pod, for example:

    metadata:
        namespace: test-ns
        annotations:
            openfeature.dev/enabled: "true"
            openfeature.dev/featureflagsource: "config-A, test-ns-2/config-B"

In this example, 2 CRs are being used to configure the injected container (by default the operator uses the flagd:main image), config-A (which is assumed to be in the namespace test-ns) and config-B from the test-ns-2 namespace, with config-B taking precedence in the configuration merge.

The FeatureFlagSource version v1beta1 CRD defines a CR with the following example structure. The documentation for this CRD can be found here:

apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
    name: feature-flag-source-sample
spec:
    metricsPort: 8080
    port: 80
    evaluator: json
    image: my-custom-sidecar-image
    defaultSyncProvider: file
    tag: main
    sources:
    - source: namespace/name
      provider: kubernetes
    - source: namespace/name2
    - source: not-a-real-host.com
      provider: http
    envVars:
    - name: MY_ENV_VAR
      value: my-env-value
    probesEnabled: true
    debugLogging: false
    otelCollectorUri: http://localhost:4317
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

The relevant FeatureFlagSources are passed to the operator by setting the openfeature.dev/featureflagsource annotation, which provides the full configuration of the injected sidecar.

Configuration Merging

When multiple FeatureFlagSources are provided, the configurations are merged. The last CR takes precedence over the first.

flowchart LR
    FeatureFlagSource-values  -->|highest priority| environment-variables -->|lowest priority| defaults
Loading

An example of this behavior:

    metadata:
        annotations:
            openfeature.dev/enabled: "true"
            openfeature.dev/featureflagsource:"config-A, config-B"

Config-A:

apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
    name: config-A
spec:
    metricsPort: 8080
    tag: latest

Config-B:

apiVersion: core.openfeature.dev/v1beta1
kind: FeatureFlagSource
metadata:
    name: config-B
spec:
    port: 8000
    tag: main

Results in the following configuration:

spec:
    metricsPort: 8080
    port: 8000
    tag: main