The developer portal hides the production option from most users. That looks like a control until a caller reaches the underlying action directly. Platform security has to survive a different interface, a changed template and an automated caller.
Enforce access beyond the interface
Consider a fictional service-creation template with environment and project fields. Filtering those fields helps developers make a valid request. The operation that creates resources must still verify the caller, target project and requested environment. Those checks need to apply even when the request did not come through the form.
Backstage documents authorization for template parameters, steps, actions and tasks through its permission framework. These controls offer places to express platform policy. Their existence does not mean every installation has already defined the right policy for its own resources.
Source: Backstage · Authorizing scaffolder tasks and actions.
Define permissions for each action
A scaffolding task may create a repository, provision an environment and write an application setting. Each step can reach a different system with a different identity. List those identities and what they can change. A user-facing project restriction is ineffective if a downstream step blindly trusts the project value while using broad credentials.
In this example, the platform should confirm that the caller may request resources for the named project. The destination should also restrict what the platform identity can create. Application-level access remains a separate responsibility: a service created through an approved template can still contain a broken authorization check.
Provide a clear exception process
Sometimes the supported template cannot meet a legitimate need. A blocked dropdown with no explanation invites work to move into private scripts. An exception route should identify the requested capability, the reason the standard path fails, the person deciding and the resources affected.
An exception is a specific decision. It should not silently grant every later task the same authority. Keep the accepted conditions with the request so another engineer can understand why that resource differs from the default.
Test denied requests
Use a disposable test project and harmless requests. Try an allowed environment, a denied environment and another team’s project through each supported interface. Inspect the destinations afterward. The absence of an error in the portal is not the evidence you need; the actual creation or denial is.
- Allowed work completes with the expected owner and resource scope.
- Denied work creates no partial resource that escapes the policy.
- A task record identifies the caller and decision without exposing secrets.
- An approved exception applies only to its documented scope.