Backstage Chart
You deploy a backstage chart by installing the official Helm package onto your Kubernetes cluster. This chart sets up your developer portal pods, storage, and network rules in one step. Most teams start with default values to get the portal running fast. Still, default setups often grant broad cluster roles and use static database keys. If an attacker compromises a pod, those broad permissions put your cluster at risk. How the backstage chart works in Kubernetes A Helm package bundles all the
Backstage Security Plugins + Helm Chart Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You deploy a backstage chart by installing the official Helm package onto your Kubernetes cluster. This chart sets up your developer portal pods, storage, and network rules in one step. Most teams start with default values to get the portal running fast. Still, default setups often grant broad cluster roles and use static database keys. If an attacker compromises a pod, those broad permissions put your cluster at risk.
How the backstage chart works in Kubernetes
A Helm package bundles all the Kubernetes files needed to run your developer portal. When you install the backstage chart, the cluster creates deployments, services, and secret objects. You can run a built-in database container or point the app to an external database.
The chart also sets up a Kubernetes service account for the portal pods. This service account links to cluster roles so the portal can read cluster state. The portal uses these roles to show pod health, logs, and build status to engineers. You pass values files during install to set your domain name and login provider.
Teams also store cloud API keys and source control tokens inside Kubernetes secrets. The chart mounts these secrets into the portal container as environment variables or files. When the pod starts, the portal reads these keys to talk to outside tools. Every plugin you add to the portal relies on these mounted keys to work.
Managing service accounts and secrets
Your developer portal acts as a central hub for many internal tools and cloud services. Because it reads data from everywhere, teams often give its service account cluster-wide read access. Some plugins even ask for write roles so engineers can trigger jobs from the portal. Storing all these static keys in one pod creates a major security target.
To lower this risk, you should scope Kubernetes roles down to specific namespaces. Avoid giving the portal service account admin rights or broad secret read permissions. You should also turn off the built-in database chart for production workloads. Instead, use a managed database service and rotate your login keys on a strict schedule.
Backstage Security Plugins + Helm Chart Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Even with tight roles, rotating keys across dozens of portal plugins takes constant manual work. When a key changes, you must update the secret and restart the portal pods. If you miss a step, the portal breaks and engineers lose visibility into their apps.
What native chart permissions leave open
Native Kubernetes roles and Helm settings solve the initial deployment problem well. They control which pods can start and which cluster APIs the portal can reach. They also let you separate test portals from production portals using standard namespaces.
Still, chart settings only decide who logs in and which static keys get mounted. They cannot inspect what individual database queries or API commands do in flight. Once the portal or an engineer holds a valid session, native controls step out of the way. A broad role cannot block a risky delete command or rewrite sensitive fields in results. To control live queries and mask data like emails or card numbers, you need runtime checks.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Should I use the built-in PostgreSQL database in production?
No, the built-in database container is meant for local testing and quick demos. For production, point your chart values to a managed PostgreSQL service with automated backups.
How do I pass custom API keys to portal plugins?
Create a standard Kubernetes secret in the same namespace before you install the chart. Then reference that secret name in your custom values file so the pod mounts it.
Why can my portal see pods in every namespace?
The Kubernetes plugin often uses a cluster role binding that grants cluster-wide read permissions. Switch to role bindings in specific namespaces if you want to limit what the portal sees.