Securing Backstage Plugins

Embracing the Permissions API

Backstage has emerged as a pivotal platform for crafting developer portals. It’s a universe of its own, bustling with a diverse range of plugins. But here's a twist: as these plugins expand, so does the number of companies that use them. One reality of corporate adoption is the need for security measures. In this post, let's unravel how the Permissions API that is part of the Backstage Core helps secure plugins.

Backstage is a framework for building developer portals with built-in features like software catalogue, templates and plugins. As Backstage's plugin ecosystem flourishes, it brings unparalleled value. Yet, this is accompanied by a crucial responsibility for the plugin providers to ensure security and especially Authorization. The dilemma is the Permissions API, which is the basis for Authorization, is not enabled by default.

Decoding Permissions

In Backstage, plugins reach out to the Permissions API, which in turn consults the Permission Policy. This policy, often provided by vendors or created by in-house platform teams, is where the decisions about who gets to do what are made. Typically, permission policy matches users, groups, roles, attributes, etc., to permissions depending on the implementation and returns an ALLOW, DENY or a maybe to the plugin. Well, two things are alarming in that sentence. 1. there is a maybe decision, which basically expects the plugin to run a conditional and ultimately decide. 2. It is completely left to the plugin to decide to do a permission check and even enforce the decision from the Permission Policy. Unfortunately, this is the reality as of this writing, and the best we can do is to guide the plugin developers to use the Permissions API and use it correctly. Fortunately, securing a Backstage plugin is very well explained in the documentation for backstage.

Incorporating the Permissions API in Backstage plugins is not just about adding layers of security; it's about crafting a seamless developer experience. The combination of well-defined permissions, thorough checks, conditional logic, and front-end integration ensures that plugins remain both functional and secure.

As a plugin developer, how can you decide if your plugin needs to take the Permissions API in use? Here are the criteria that I think you should consider.

• User Roles: Consider the roles and responsibilities of the users of your plugin. If there are diverse user roles with varying levels of access and responsibilities, you may need finer-grained permissions to accommodate these roles effectively.

• Sensitivity of Data: The sensitivity of the data or resource is a key factor. Highly sensitive data, such as personal or financial information, typically requires finer-grained access control.

• Regulatory Compliance: Regulatory requirements, such as GDPR or HIPAA, may dictate the level of granularity for certain types of data access.

• Principle of Least Privilege: Apply the principle of least privilege. Fine-grained permissions can help ensure that users or roles have access only to the specific resources they need to perform their tasks.

Once you decide to use the permissions API and create your own permissions, some best practices to consider are

User Interface: If your plugin has a user interface, design it to present missing actions clearly to users, indicating what options are accessible to them. Do not allow users to click on an action to realize they are not authorized to do the operation.

Separation of Concerns: Ensure that permissions are well-separated concerns and do not unnecessarily mix responsibilities. For example, reading and modifying data should typically be separate permissions.

Testability: Ensure that permissions are testable and that you can verify that users have the correct permissions. Implement tests to verify that access control is functioning as expected.

Documentation and Naming: Document each permission clearly. Use descriptive and consistent naming conventions to make it easy for administrators and developers to understand the purpose of each permission both in terms of its purpose and its impact on the system. Avoid ambiguous or overlapping permissions.

Monitoring and Auditing: Implement mechanisms for monitoring and auditing permissions. It should be possible to track who performs which actions for security monitoring and compliance purposes.

Security Implications: Assess the security implications of your conditions. Be mindful of potential vulnerabilities, such as injection attacks, and implement safeguards to mitigate these risks.

In summary, the expansion of Backstage's plugin ecosystem underscores the necessity of integrating robust security measures into the plugins. This is crucial for maintaining the integrity and reliability of the platform as it grows. Developers are urged to judiciously use the permission API, considering key aspects such as user roles, data sensitivity, and compliance with regulations. By adhering to best practices in design, testing, and documentation, they can ensure that their plugins are not only functional but also secure. Ultimately, applying these principles will bolster Backstage's position as a trusted and versatile platform for developer portals. Failing to do so… well.