Restricting who can run Backstage templates before they create cloud resources
Restrict template access before a template can create repositories, cloud accounts or infrastructure, because in many Backstage setups signed-in users can see and run templates by default. The page question is simple: which templates create resources that carry cost, access or compliance consequences, and which teams should be allowed to start them. A platform team that publishes a template for new cloud accounts or production repositories should decide that scope before the template reaches the catalog, not after the first unplanned run. Confirm your current behavior by signing in as a user from a team that should not have access and checking whether the template appears and can be launched.
Backstage has two separate places to control this. The first is who may register Template entities in the catalog, which decides what appears in the portal at all. The second is the permission framework, which can allow or deny the actions a user takes on templates and on the scaffolder actions those templates call. Treat these as different controls: a template hidden from one team can still be reachable if its permission rules are missing, and a locked-down registration process does not stop an already published template from running. Check the Backstage authentication documentation for how signed-in identities are resolved, since the access rules you write depend on which group or user identity the portal actually receives.
Restrict templates when they create external resources, when they write to shared repositories or when they can reach credentials for production systems. Before writing rules, list each template, the resources it creates, the team that owns it and the groups allowed to run it. Ask your identity team whether group membership arrives reliably in the session, and confirm with the framework's permission documentation how each rule is evaluated for your Backstage version. Plan the review of this list as part of template changes, so a new template that creates a cloud account cannot ship with open access by accident.
Where access control can be applied: templates, actions and Template entities
The first control point decides which signed-in users can start a given template from the Create page. The check applies to the identity that your sign-in resolver assigned, so the accuracy of group and team membership matters as much as the rule itself. Use this layer to keep templates that create cloud resources or repositories limited to the teams that own those systems.
- What it governs: whether a user can see and execute a specific template through the scaffolder permission rules.
- What it does not govern: the steps a template performs once a run starts, or the actions those steps call.
- Group mapping: group names come from your identity provider and catalog, so confirm they resolve the same way for every sign-in provider.
- Default posture: confirm what access your version grants when the permission framework is enabled but no rule has been written for a template.
- Listing and execution: test whether a non-member can still see a template in the list and whether they can run it, because these are separate checks.
Confirm the exact permission names in your Backstage version and test each template with an account from outside the owning team.
A template is a sequence of steps, and each step calls a scaffolder action, such as one that fetches a skeleton or creates a repository. Restricting who can run a template does not restrict the actions that template calls. A template open to a broad team can still reach a sensitive action unless that action has its own rule, and the same action is reachable from every other template that calls it.
- Action-level rules: the permission framework can gate scaffolder actions by name, for example through a rule such as
scaffolder.action.execute(confirm the exact name for your version). - Covering every action: list each action that sensitive templates call, then confirm each one has a rule, including actions your own team wrote.
- Custom actions: actions added through your backend modules need to be wired into the permission policy the same way built-in actions are.
- Shared templates: a template reused by several teams passes its actions to all of them, so a rule change affects each team that uses it.
- Denied steps: test that a denied action stops the run with a clear message, so a partial result does not leave a half-created repository.
Run each sensitive template end to end with a user who lacks the action permission and confirm the step is refused.
Template entities are catalog entries, so the catalog permission rules decide who may create, edit or delete them. A registered Template publishes a scaffolding definition to everyone who can see the Create page, and changes to its YAML change what every later run does. Write access to Template entities is therefore as sensitive as the right to run them.
- What it governs: creating, updating or removing Template entities through the catalog, controlled by catalog permission names such as
catalog.entity.create(confirm the name for your version). - What it does not govern: whether anyone may run an existing template, or which actions it calls.
- Other registration paths: templates can also enter the catalog through locations or entity providers, which are separate paths that need their own review.
- Git review: if template files load from a repository, protected branches and required reviews are a second gate that sits outside Backstage.
- The owner field: the owner recorded in a Template's metadata shows who answers for it, but it does not enforce write access on its own.
List every path that can add or change a Template entity and confirm each one is covered by a rule and a review step.
Permission names, defaults and policy code change between Backstage releases, and your own policy determines the result. Treat the three control points as a test matrix that you run before rollout and after each change, because a gap in one layer leaves the other two unchanged. Record the version you tested so the results match the configuration you deploy.
- Pin the version: record the Backstage release you tested and check the permission names against its documentation and release notes.
- Run a matrix: test running, action use and entity registration with a user from each team and a user outside all teams.
- Test denial paths: confirm that a denied run fails cleanly and that the failure is logged.
- Check guest access: the authentication guidance advises against guest access in production, so confirm that no anonymous identity can run templates or register entities.
- Keep the evidence: store test results with your change records so reviewers can see what was checked.
Re-run the full matrix after every Backstage upgrade and whenever you add a template, a custom action or a new registration path.
Permission options for templates and who may register them
This table compares the main ways to limit who can run Backstage templates and who can register Template entities, from leaving everything open to restricting actions and catalog registration. Read each row as a separate control: the options combine, and the cheapest one is rarely enough on its own when templates create cloud resources or repositories.
| Option | When it fits | What it protects | Operational cost and trade-off |
|---|---|---|---|
| Leave templates open to all signed-in users | Small internal portals where every engineer may create a service and the templates only scaffold low-risk code | Little beyond sign-in itself, since any authenticated user can run any registered template | Lowest effort, but a template that provisions cloud accounts or repositories can be run by anyone who can sign in |
| Restrict template access by user or group in the permission framework | Templates tied to a team, such as a platform team's cloud sandbox or a regulated workload template | Who may see and execute a given template, enforced by the backend on each request | Requires group data from your identity provider in the catalog and a policy per template; confirm the template permission identifiers for your release in the Backstage permission documentation |
| Restrict use of individual scaffolder actions | Templates that call sensitive actions, such as creating repositories with admin settings or calling cloud APIs | Which actions a template may invoke, even when a broad group can run the template | Needs a policy that distinguishes actions and maintenance as action names change; confirm the action permission concepts and their identifiers in the Backstage permission documentation |
| Restrict who may register Template entities through catalog locations | Organizations where only platform owners should publish new templates to the catalog | The set of templates that exist at all, because unregistered templates cannot be launched from the portal | Locations must be curated and reviewed; a broad location pattern can let unreviewed templates appear, so track who edits the catalog configuration |
| Restrict Template registration through entity providers | Templates loaded from a Git repository or discovery source that teams control through pull requests | Changes to templates go through the same review as code, with the provider limited to approved repositories or paths | Adds a review step and ownership of the provider configuration; the provider's read credentials and scope must be set deliberately |
| Combine catalog control with run permissions | Regulated or multi-team estates where both creation and execution matter | Templates are both defined by approved owners and run only by authorized groups, reducing the chance of unreviewed provisioning | Highest administration effort: two policies to maintain and test after each Backstage upgrade |
How to set up template restrictions in a Backstage instance
This sequence moves template access from the default open state to a deliberate model in which each identity maps to the right teams, each template has a named owner, and only controlled sources can register Template entities. Each step ends with a check you can run before moving on.
Confirm each user resolves to one catalog identity
Before any restriction can work, sign-in must tie every person to a single User entity in the catalog. Platform engineering reviews the sign-in resolvers for each enabled authentication provider and confirms that all providers resolve to the same identity, and that guest access is off in the production configuration. Check it by signing in with one account per provider and confirming that each lands on the same User entity with the expected username and email. The step is done when no user appears twice in the catalog under different identities.
Map identity provider groups into the catalog
Group membership is what the permission policy will test, so the groups from your identity provider must appear in the catalog as Group entities with the correct members. Identity administrators and the platform team agree on the group names and confirm which directory groups carry template rights. Check it by opening a sample user's profile in the catalog and confirming the expected group memberships are listed. Ask the team who maintains group sync, how often it runs, and what happens to a user who leaves a group, because stale membership is the most common cause of incorrect access.
Assign each template an owning team
Write down which team may run each template, which is usually the team that maintains the golden path it creates. Platform engineering records the owner in each template.yaml metadata and in the matching Group entity, and removes any template with no accountable owner from the restricted set until someone claims it. Check it by listing every Template entity and confirming each has an owner that exists in the catalog. The output is a short ownership table that the permission policy will reference.
Enable the permission framework and a deny-by-default policy
Turn on the Backstage permission framework in the backend and point it at a policy module that the platform team owns and reviews. The policy should deny template and action access unless a rule grants it, so new templates stay closed until an owner opens them. Check it by starting the backend in a test environment and confirming that a user with no grants receives a denial when opening the template list. Confirm with your Backstage version's documentation how the permission policy is wired in, since the setup changes between releases.
Restrict templates and scaffolder actions by group
Write policy rules that allow each group to run the templates it owns and to use only the scaffolder actions those templates need. Actions that create cloud resources or repositories should be granted separately from the templates that call them, so a user cannot reach a sensitive action through a template they can otherwise view. Test the rules with a user from an unauthorized group, who should be unable to see or run the restricted template, and with a user from the owning group, who should succeed. Record the test results with the policy change.
Limit who can register Template entities
Access to running a template is separate from the right to add one to the catalog, and the second right is what lets someone introduce a new template with broader access. Restrict registration to the controlled sources, such as a protected repository and the catalog configuration maintained by the platform team, and remove broad registration locations. Check it by attempting to register a Template from an unapproved location and confirming it is rejected or does not appear. Ask the team whether any entity provider can add templates automatically and who controls its configuration.
Audit the catalog for unexpected Template entities
Once the restrictions are live, review the catalog for Template entities that the ownership table does not explain. Platform engineering lists all templates with their source location and owner, compares them with the approved set, and investigates any extra entry before anyone runs it. Repeat this review on a schedule the team agrees, and after every change to catalog locations. The step is complete when the catalog matches the ownership table and each template has a documented owner, source and access rule.
Security considerations when limiting template access
Restricting template access only holds if the identity, catalog, credential and audit layers agree with it. The cards below cover the places where a permission rule can be bypassed or go unnoticed, and what to verify in your own environment before relying on it.
Guest or shared sign-in
If guest access is enabled or several people share one account, group checks in the permission framework see the wrong identity and can grant or deny the wrong actions. The Backstage authentication documentation advises against guest access in production. Check that no guest provider is enabled in production configuration and that each sign-in resolves to a named identity in your directory.
Unreviewed Template registration
Any repository the catalog reads can publish a Template entity, and a template that looks official can still ask for resources it should not create. Restrict who may register Template entities by location and review changes to template repositories like application code. Confirm that catalog locations for templates point only to repositories with protected branches and required approvals.
Broad action credentials
A template may be allowed by the permission framework while the actions it calls run with a token that can do far more, such as creating repositories across an entire organization. Template-level limits do not reduce what those credentials can reach. Confirm which tokens or GitHub App installations back each publish action and scope them to the groups that own the templates.
Group membership drift
Access rules are only as current as the group data synced from your identity provider. When people move teams or leave, stale memberships can keep template access open after the business reason has ended. Verify how group membership reaches the catalog, how often it refreshes, and who is alerted when a group that gates templates changes.
Gaps in run audit trails
Teams need to answer which person ran which template, with which parameters, and what it created. Without that record, a misuse or failed run cannot be traced to an owner. Confirm that task history is retained for the period your policies require, that it is exported to your log platform, and that you can match each created repository to the run that produced it.
Guest access in production
Guest sign-in is convenient in a demo but removes the link between a person and their permissions, so every other control weakens. Treat the absence of guest access as a release gate for production. Ask your team to confirm that the production configuration file, environment overrides and any sign-in fallbacks have been checked, not only the default configuration.
Questions teams ask before restricting Backstage templates
Are Backstage software templates open to every user by default?
Yes, a fresh Backstage installation does not restrict who can run templates, so any signed-in user who can see the Create page can start a template. That default suits a proof of concept but is risky once templates create cloud accounts, Kubernetes namespaces or source control repositories. Before rollout, confirm which templates create billable or sensitive resources, confirm who can currently run them in your instance, and decide which groups should see each one. Check the permission settings in your own configuration rather than assuming the default still applies after your upgrades.
Does restricting templates require writing a custom plugin?
Usually not for the basic case. Backstage has a permission framework that lets you define policies for template execution and for the actions a template can call, so access can be decided per template and per group. Custom work appears when your rules depend on something the framework cannot see, such as a ticket reference, a cost center or a live check against another system. Policies then need to be written and tested as code. Ask whether your rules fit the standard framework, because that determines how much custom code your team will own.
What drives the effort to restrict templates?
Effort is driven mainly by four factors: how your identity directory maps to Backstage groups, how many templates and custom actions exist, how many distinct access rules you need, and how formal your review process is. Identity mapping is often the largest item because sign-in resolvers must resolve each user to a consistent identity before group membership can be trusted. Each additional template or action multiplies the test cases. Request a quote based on a written list of templates, actions, groups and rules so the scope is explicit.
What does the restriction project need from our internal team?
Your team needs to provide an inventory of templates and the actions they call, an export or description of groups from your identity provider, and named owners who can approve who should run each template. Someone must also be able to test in a non-production instance and sign off on the policies. Platform engineers will maintain the policy code and the Backstage configuration afterward. Agree these responsibilities in the written scope before work starts, so approvals do not stall the schedule.
Can our own platform team restrict templates without outside help?
Yes, if the team already runs Backstage in production, understands its authentication setup and can write and test TypeScript policy code. The hardest part is usually not the configuration but agreeing on the access model with template owners and security. A partner can help by reviewing the model, writing the first policies and building tests, then handing over the code. Be honest about how many people can own this work after the project ends, since policies need updating whenever templates or groups change.
How do we verify that template restrictions work?
Verify with tests that run as specific test users in a non-production instance. For each template, confirm that an allowed group can open and run it, and that users outside the group receive a denial before any repository or cloud resource is created. Include checks for the actions a template calls, since a user blocked from a template should not reach them through another path. Keep the test results as evidence and repeat the checks after each Backstage upgrade, because permission behavior can change between releases.
Who should be allowed to register new Template entities?
Restrict registration to a small group of platform owners, because a Template entity defines what a user can run and where it writes. If any user can register templates from an arbitrary repository, a person could publish a template that creates resources outside approved controls. Decide whether registration happens through a reviewed catalog location, a pull request process or a restricted permission, and document the owners. Confirm this approach against your change management rules before you rely on it for audit evidence.
Limits to confirm in your environment before rollout
Restricting template runs is only as strong as the permission behavior your release actually enforces. The items below are the points to verify with the Backstage documentation, your identity provider and your own test environment before any template that creates cloud resources or repositories goes to production.
Permission framework identifiers and behavior
Confirm the exact permission names, resource types and action identifiers that the Backstage permission framework exposes in the release you run. Template and action permissions have changed shape across releases, so a rule written against one version may silently match nothing in another. Test each rule against a real template run and a denied user, and record the result for the release you deploy.
Action-level checks on custom actions
Confirm whether the action-level checks you rely on apply to every custom scaffolder action, including actions built by your own teams and actions added through backend modules. Do not assume that restricting a template also restricts the actions it calls. Write a test template that calls each sensitive action and confirm that a user without permission is blocked at the action step.
Template registration across catalog providers
Confirm how restricting who may register Template entities interacts with each catalog provider you use, such as file-based locations, Git discovery or entity providers that sync from external systems. A template registered through an automated provider may bypass the restriction you set for manual registration. List every ingestion path and test each one with a user who lacks registration rights.
Support status of your release line
Confirm which release line you run and how long it receives security fixes before you commit a permission design to it. The versioning policy describes the main monthly line and the weekly next line, and it sets backport expectations for high and critical vulnerabilities. Check the current support window in the policy and your own patch plan, because a permission fix that lands only in a newer line may force an upgrade.
Restriction behavior during upgrades
Confirm how your permission rules, policy code and template ownership metadata behave when you move to a newer Backstage version. Use the Upgrade Helper to review template and configuration changes, and rerun your permission test suite on a staging copy before the upgrade reaches production. Plan a window in which denied users can still reach templates they should not run, and close it before cutover.
How DeployOpen scopes and delivers template access controls
DeployOpen plans, implements, hardens and documents self-hosted Backstage inside your own infrastructure, including the cloud accounts, data centers or private networks where the portal runs. Most engagements are fixed-scope, so the template permission work is agreed in writing before any build starts: which templates are restricted, which teams own them, which actions each template may call, and who may register Template entities. The written scope also states what is handed over and what is left for your team to run, so no one is guessing at ownership after go-live.
The scope for this topic covers four areas. Template ownership sets which group owns each template and who approves changes to it. Identity mapping ensures that the group claims from your identity provider resolve to the catalog users and groups that the permission policy checks. Policy covers the permission framework rules for templates and scaffolder actions, plus the restriction on Template registration. Testing and documentation cover how each rule is verified and how administrators update it later. You keep control of your identity provider and cloud accounts throughout, and DeployOpen works within the access you grant. Ask any partner to show the proposed role and group model before accepting a quote.
Because access rules change as teams reorganize, many clients add a retainer for ongoing support and upgrades after the initial build. A retainer covers reviewing permission changes when Backstage releases move forward, and checking that policy tests still pass after dependency updates. Confirm during scoping who will own the policy files after handover, how changes are reviewed, and what response expectations apply. DeployOpen does not issue audit reports or certifications, so if you need evidence for an assessment, agree in advance which records the permission setup will produce.
