ContextQMD
Back to Starrocks

StarRocks FE Plugins

fe/plugin/README.md

4.1.03.3 KB
Original Source

StarRocks FE Plugins

The fe/plugin directory hosts plugin implementations and integration glue for the Frontend. Plugins extend the FE core with capabilities beyond the built-in features by implementing interfaces from fe/spi and interacting with FE core through stable contracts.

Unlike connectors:

  • Connectors focus on integrating external data sources and catalogs.
  • Plugins focus on extending core capabilities (authorization, authentication, governance, observability, etc.) and do not act as data source bridges.

Responsibilities

  • Implement FE SPI contracts to augment core behavior.
  • Provide optional features that can be enabled/disabled without altering FE internals.
  • Remain decoupled from FE private classes; depend only on fe/spi and public abstractions.

Typical plugin capabilities

  • Authorization providers (e.g., Apache Ranger integration)
  • Authentication providers (e.g., LDAP, Kerberos)
  • Auditing and logging sinks
  • Observability hooks (metrics/tracing exporters)
  • Resource governance and admission control hooks
  • Policy, masking, and row-level access integrations

Note: Exact plugin types depend on the available SPI extension points.

How it interacts with FE core

  • FE core programs against fe/spi interfaces.
  • Plugins implement those interfaces and are discovered/loaded at runtime.
  • FE core invokes plugin hooks during authentication, authorization, session, or administrative flows as defined by the SPI.

Implementing a plugin

  1. Identify relevant interfaces in fe/spi (e.g., authN/authZ, auditing, hooks).
  2. Create a new module or package for your plugin and depend on fe/spi.
  3. Implement the SPI contracts and provide discovery metadata.
  4. Add configuration parsing/validation and document required settings.
  5. Ensure thread-safety; plugins may be invoked concurrently.
  6. Write tests (unit for SPI behavior; integration for end-to-end flows).

Guidelines:

  • Keep implementations stateless where possible or guard state with proper synchronization.
  • Fail fast on misconfiguration; surface actionable error messages.
  • Do not block FE critical paths; use timeouts/backoff for I/O.
  • Never log secrets or PII; honor FE security and redaction policies.

Lifecycle

  • Initialize: receive configuration/context and validate dependencies.
  • Runtime: serve concurrent requests through defined SPI hooks.
  • Shutdown: release external resources (clients, threads) idempotently.

Configuration

  • Use namespaced keys for plugin options.
  • Support secure secret handling (env, keystores, injected credentials).
  • Provide safe defaults and minimal required parameters.

Versioning and compatibility

  • Track and declare the fe/spi version supported by the plugin.
  • Prefer backward-compatible changes; deprecate before breaking compatibility.
  • Document compatibility with external systems (e.g., Ranger/LDAP/Kerberos versions).

Security considerations

  • Enforce authorization and authentication semantics defined by FE.
  • Validate and sanitize all external inputs.
  • Avoid leaking sensitive data in logs, errors, or metrics.

Non-goals

  • Plugins are not data source connectors and should not expose catalog/table access.
  • Plugins must not depend on FE private/internal classes beyond SPI boundaries.

References