Feature Requests

As a platform engineer I want to get an ephemeral (short-lived, limited purpose) API key for meshStack in my building block run. This would enable me to interact with meshStack as part of a building block run (e.g. provision a new building block in the background) without needing almighty admin permissions. The UI should show in the marketplace when a building block uses this so it is transparent to users what side effect certain building blocks might have. It could show for examlpe "This building block has the permission to provision other building blocks in your workspace.". My use case is that I want to provide an "extension" of another building block. Rather than defining a dependency and having the user book both, I want to automatically create a Building Block via Terraform in the background.

Since we are dealing with multiple Entra IDs, we must ensure that marketplaces/platforms or building blocks can use meshtack definded permission groups which are replicated to the different Entra IDs via a custom platform. Example: Azure in Location X would require the custom Entra ID platform in Location X etc.

Currently, when meshObjects are created via API users from the admin area, it is possible to bypass policy checks, allowing the creation of objects that may not comply with defined policies or contain unsupported tag values. In the future, I would like to enable validation for admin-initiated API requests as well, ensuring that all meshObjects—regardless of how they are created—are consistently validated and compliant with meshStack policies.

We would like to request the ability to aggregate usage data based on workspace tags, specifically tags that correspond to organizational structures such as sector, area, or business unit. This would allow administrators and stakeholders to view usage reports grouped by these tags, providing clearer insights into how different parts of the organization are utilizing resources. Use Case: For organizations with multiple business units or regions, it's crucial to understand usage patterns across these divisions. Aggregating by workspace tags would simplify internal reporting, budget tracking, and help in making data-driven decisions at the sector or business unit level.

We have have done a Pre-Check for an ISO27016 certification. One of the requirements we need to implement is a regular recertification of all permissions by a defined list of owners. We want to implement this using meshStack's workspace role recertification feature. Per Workspace, we have set two Owners. Out of those Owners, there is at least one available at all times, since they are each others holiday replacement. Only the Owners must be allowed to recertify access to the Workspace. I see two ways to implement this, both require changes to meshStack: Make it possible to deactivate the Workspace Manager role for our meshStack Make it possible to remove the "recertification" permission for Workspace Managers

As a platform team operating out of the service management area I would also like to reach out to other workspaces via communication. This way I can announce new versions, deprecations, maintenance windows and so on without admin access.

In the "General" tab of the BB definition you can only select platform types for the supported platforms even though the header "supported platforms" suggests, that you should be able to select individual platforms. This is at the very least misleading. We would like to be able to select the platform instead of the platform type here.

We would the ability to apply security labels to groups as they are created. This comes as a requirement from our Identity/Security teams. https://support.google.com/a/answer/10607394?hl=en https://cloud.google.com/identity/docs/how-to/update-group-to-security-group

Currently the meshStack CRUD APIs for Workspace and Project User Bindings are missing the possibility to get or add role expiration dates to limit the access for a period of time. This is a gap between the UI/UX behaviour and the API behaviour.

We have to ensure that only certain users or groups can be assigned to the "Project Admin" role. Therefore we need a mechanism to restrict that. At the moment Workspace Managers can assign any user / group to any role, e.g. you could have a group "MyApp-Project-Reader" and assign it to the role "Project-Admin".