Flux Backstage Plugin
The flux backstage plugin lets developers view and sync GitOps deployments from their portal. You set it up by linking your portal backend to Kubernetes cluster APIs. Platform teams often use one shared service account to read cluster objects. If that role has broad write rules, any portal user can alter live workloads. How the flux backstage plugin works Backstage acts as a central catalog for all your software services and teams. Flux runs inside your Kubernetes clusters and matches cluster
Backstage Security Plugins + Flux Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The flux backstage plugin lets developers view and sync GitOps deployments from their portal. You set it up by linking your portal backend to Kubernetes cluster APIs. Platform teams often use one shared service account to read cluster objects. If that role has broad write rules, any portal user can alter live workloads.
How the flux backstage plugin works
Backstage acts as a central catalog for all your software services and teams. Flux runs inside your Kubernetes clusters and matches cluster state to your Git repos. The plugin bridges these two tools so engineers do not need direct cluster keys.
First, the portal backend reads custom resources from the target Kubernetes API server. It looks for Git sources, Helm releases, and Kustomize objects tied to an app. Then, the frontend displays the sync status, recent events, and version history. Engineers can see if a deployment succeeded or failed right on the service page.
To make this work, you create a Kubernetes role for the portal backend. This role needs permission to list and watch Flux objects across target namespaces. You also add labels or annotations to your catalog items in the portal. These tags tell the portal which cluster objects belong to which software service.
What native setup solves and where gaps remain
A read-only setup solves visibility issues for fast-moving software teams. Developers no longer need to run command line tools just to check deployment progress. They can spot broken syncs, failed health checks, and drift from one screen. This cuts down on ticket queues for the platform group.
Still, many teams also want to trigger actions from the portal screen. They enable buttons to suspend, resume, or force a sync on cluster resources. To allow this, the portal service account must hold write permissions in the cluster. This creates a major security gap in most standard setups.
The native setup decides which server logs in, not what each user request does. When a developer clicks a button, the cluster only sees the shared portal role. Kubernetes audit logs record the portal service account rather than the real person. You lose track of who paused a production sync or forced an update.
Backstage Security Plugins + Flux Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing cluster roles and action permissions
To reduce risk, teams must split read roles from write roles in Kubernetes. The default portal view should only hold permission to read status fields. Do not grant cluster-wide admin rights to the portal backend just to save time. Scope every role down to the exact custom resource groups that Flux uses.
When engineers need to fix a stuck release or inspect a live pod, pause. Ask if that action belongs in a shared portal or requires direct cluster checks. Even when engineers use standard cluster roles, broad permissions remain a problem. A role lets a user into the cluster, but it cannot inspect individual commands.
In live fixing, an engineer might query a database pod or read secret configs. Standard cluster roles cannot rewrite sensitive fields like emails or phone numbers in output. They also cannot ask a team lead to approve a risky command in flight. Teams need fine-grained controls at the command level to keep production safe.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the flux backstage plugin need write access to Kubernetes?
No, the plugin only needs read access to show sync status and deployment history. You only need write permissions if you turn on sync and pause buttons.
How does the portal know which Flux resources belong to an app?
You link them by adding matching tags to your catalog files and cluster objects. The backend filters cluster resources based on those shared service labels and namespaces.
Can the plugin show resources across multiple Kubernetes clusters?
Yes, the portal backend can read from multiple clusters at the same time. You must set up a valid service account role on each target cluster first.