Feature Requests

meshStack's AWS integration for IAM Identity Center requires a SCIM token to manage groups and memberships. This approach presents two significant security challenges: Violation of Least Privilege: The SCIM token is overly permissive. It grants meshStack permissions beyond its actual needs (e.g., onboarding or modifying users), when it only needs to manage group creation and memberships. Requires manual/semi-automated secret rotation of the SCIM token AWS SCIM API only supports bearer tokens. This is a documented AWS limitation > IAM Identity Center SCIM implementation supports the bearer HTTP authentication scheme [...] Other authentication schemes described in the SCIM specifications are not supported at this time. If meshStack would use the AWS Identity Store APIs (e.g., identitystore:CreateGroup, identitystore:AddMemberToGroup, etc.) for its integration with AWS this would enable Enhanced Security (Least Privilege): Customers could attach a granular IAM policy to the role, limiting meshStack only to the specific Identity Store actions it requires. Simplified Operations: This would eliminate the need to securely store, manage, and rotate a long-lived SCIM token for the meshStack integration. Future-Proof (Secret-less): By moving fully to the AWS SDK (for both Identity Store and SSO Admin), we can enable authentication via Workload Identity Federation (WIF), allowing for a completely secret-less integration.

Managing access in meshStack can be a bit cumbersome sometimes: invites aren't always clear adding users field is hidden all the way at the bottom. the access management screen performs poorly on screen readers & more

I want to restrict usage of production Landing Zones to groups. Users and groups are synced from AAD to meshStack via SCIM. I need to add "tag = development, production" to all groups" and "tag = development" to all users.

As a Platform Operator I want to manage and automate my custom integration also using meshcloud API. This includes the possibility to automate the API User credential rotation. Possible Scenario: I create 2 API Users - e.g one for the actual retrieval of data from meshStack and another one for change the API Users credentials. API User 1 is therefore used for getting the data only based on the permissions and the second API User can only change and retrieve the new API credentials for other API users (also based on the permissions). This allows me to have short lived credentials for fetching data or integrations and another longer lived credentials to manage my API Users

We'd like to define platform-specific roles that are only available to tenants using that particular platform. Key use cases include roles for security specialists and backup engineers.

As a Application team I want to enable specific users only reader permission on the workspaces financial information (Controller). The Controller should not be able to create or delete tenants, projects and services.

As the owner of a workspace I want to receive a summarized e-mail of everyone that is about to lose access in my workspace so I can be made aware of the fact and timely do the role recertification in my workspace.

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 Workspace Manager for critical projects or productive environments, I want that developers must use PIM to access the critical Azure Subscription so that the access to the ressources is more secure and audited. One idea would be, that as effect of a setting on project level, the team members (except project readers) are not automatically replicated as member to the Entra ID group but replicated as "eligible assignment", see screenshot.

In cases where a team owns or manages multiple meshStack workspaces, it should be feasible to assign a single api key to multiple workspaces, without giving the global platform admin role. Kind regards