develop

.github/workflows/build.yml

@@ -18,9 +18,9 @@ jobs:
       matrix:
         node-version: [22.x]
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
       - name: Use Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@3235b876344d2a9aa001b8d1453c930bba69e610 # v3
         with:
           node-version: ${{ matrix.node-version }}
           cache: yarn

.github/workflows/copilot-setup-steps.yml

@@ -20,10 +20,10 @@ jobs:
     # If you do not check out your code, Copilot will do this for you.
     steps:
       - name: Checkout code
-        uses: actions/checkout@v4
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
 
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
         with:
           node-version: "18.x"
           cache: "yarn"

.github/workflows/release.yml

@@ -15,7 +15,7 @@ jobs:
   release:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
         with:
           ref: develop
           fetch-depth: 0

.github/workflows/stale.yml

@@ -12,7 +12,7 @@ jobs:
   stale:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@v8
+      - uses: actions/stale@1160a2240286f5da8ec72b1c0816ce2481aabf84 # v8
         with:
           days-before-stale: 7
           days-before-close: -1

.github/workflows/sync.yml

@@ -19,7 +19,7 @@ jobs:
 
     steps:
       - name: Checkout current repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
         with:
           fetch-depth: 0
           token: ${{ secrets.GITHUB_TOKEN }}

amplify/main.tf

@@ -381,6 +381,10 @@ locals {
       source = "/meshstack.how-to.get-started-building-blocks"
       target = "/guides/core/how-to-launch-a-new-opentofu-building-block"
     },
+    {
+      source = "/administration.emergency-users"
+      target = "/guides/core/how-to-get-emergency-workspace-access"
+    },
 
     ## renames after the new docs launch
     {
@@ -483,8 +487,8 @@ resource "aws_amplify_app" "docs" {
     target = "/metering-api/metering-api-root/"
     status = "301"
   }
-  
-  // some legacy links still use the format /mydocs instead of /mydocs/ 
+
+  // some legacy links still use the format /mydocs instead of /mydocs/
   // for these links fallback to client side routing
   // https://docs.aws.amazon.com/amplify/latest/APIReference/API_CustomRule.html
   // "404-200" means "if the request 404s because the requested file does not exist, return index.html instead as a "rewrite"

blog/2025-12-03-Release-0.md

@@ -0,0 +1,194 @@
+---
+author: meshcloud
+title: Release 2025.52.0
+---
+
+Release period: 2025-11-26 to 2025-12-03
+
+This release includes the following issues:
+* Security Hardening - Pin Panel Dependencies to Stable Versions
+* Fixed Building Block Run API Documentation
+* Fix Workload Identity Federation Input Generation in Building Block Definitions
+* Enhanced Author Information in meshEventLog API
+* Improved User Experience When Creating Tenants With Landing Zones
+* Improved Building Block Input Change Detection
+* Add workspaceIdentifier Query Parameter for Event Logs API
+* Fixed AWS Landing Zone Detection for Control Tower Enrollment
+* meshUser API Now Exposes UUID
+* Remove Legacy Config-Based Message of the Day Configuration
+* Event Logs for Policies
+* Event Log API Supports Title Exclusion for Efficient Filtering
+* Improved Building Block Definition Form Order
+* Improved Event Log Author Information in Admin Area
+* New meshIntegration API for Integration Management
+* Improved Unmanaged Tenant Import Stability
+* Event Logs for API Users
+<!--truncate-->
+
+## Ticket Details
+### Security Hardening - Pin Panel Dependencies to Stable Versions
+**Audience:** User<br>
+
+#### Description
+We have proactively pinned all Angular panel dependencies to stable versions that are older than 4 months as a preventive
+measure against the Shai Hulud 2.0 worm. Based on current information, the library versions we used previously were not
+known to be affected by this vulnerability. Additionally, our backend already uses fixed dependency versions, and we have
+secured our CI/CD pipelines following all recommended security measures to protect against this threat.
+
+#### How to use
+No action is required from you. meshStack was not affected by the Shai Hulud 2.0 vulnerability, and we have taken
+comprehensive preventive measures across the entire platform to ensure continued security.
+
+### Fixed Building Block Run API Documentation
+**Audience:** User<br>
+
+#### Description
+We fixed an issue where the "Update source for a building block run" endpoint was not appearing correctly in the API
+documentation sidebar. The endpoint documentation is now properly displayed and easier to find in the navigation.
+
+### Fix Workload Identity Federation Input Generation in Building Block Definitions
+**Audience:** User<br>
+
+#### Description
+Fixed an issue where the workload identity federation (WIF) input generation was broken during building block
+definition creation. This affected building blocks using Terraform and other runners that require
+WIF configuration.
+
+### Enhanced Author Information in meshEventLog API
+**Audience:** User<br>
+
+#### Description
+The meshEventLog API now provides more detailed information about the author of each event. This enhancement makes
+it easier to understand who performed specific actions in your meshStack environment.
+
+#### How to use
+When retrieving event logs via the meshEventLog API, you will now receive additional author details for each event.
+For a complete description of all available author fields and their meanings, please refer to the official meshStack
+documentation.
+
+### Improved User Experience When Creating Tenants With Landing Zones
+**Audience:** User<br>
+
+#### Description
+We improved the user experience when creating tenants for platforms with landing zones that have mandatory building
+blocks. Previously, it was possible to navigate to the access control screen before all mandatory building blocks
+were fully loaded, which could result in incomplete tenant configurations. Now, the landing zone selection dropdown
+displays a clear loading indicator while building blocks are being fetched, and navigation to the next step is
+disabled until all necessary building block definitions are fully loaded. This ensures that you can only proceed
+when all mandatory building blocks are properly configured and ready for your tenant.
+
+### Improved Building Block Input Change Detection
+**Audience:** User<br>
+
+#### Description
+We fixed an issue where changes to building block input properties were not properly detected when the input value
+came from another building block's output (dependent inputs). Previously, if you changed properties like the
+environment flag or sensitivity flag on such inputs, these would not be recognized as
+changes and could lead to missing variables during building block execution.
+
+### Add workspaceIdentifier Query Parameter for Event Logs API
+**Audience:** User<br>
+
+#### Description
+The meshEventLog API now supports filtering by workspace identifier. A new `workspaceIdentifier` query parameter has
+been added to the event logs list endpoint, allowing API consumers to filter event logs by the exact workspace
+identifier. This is in addition to the existing `workspaceName` parameter which performs a partial match on the
+workspace display name.
+
+### Fixed AWS Landing Zone Detection for Control Tower Enrollment
+**Audience:** User<br>
+
+#### Description
+We resolved an issue where meshStack was unable to detect if an AWS account was already part of an AWS Landing Zone
+during Control Tower enrollment. This caused enrollment attempts to fail without proper error handling when accounts
+were already managed by an existing Landing Zone. The fix ensures that the replication process now correctly checks
+Landing Zone manifests.
+
+#### How to use
+In order to successfully incorporate the AWS Landing Zone detection feature, please ensure
+that your meshfed-service role for the AWS replication contains the two new permissions for reading
+landing zone attributes as described in the documentation.
+
+### meshUser API Now Exposes UUID
+**Audience:** User<br>
+
+#### Description
+The meshUser meshObject API now includes a unique identifier (UUID) in the metadata section. This UUID uniquely
+identifies each user in meshStack. Additionally, you can now filter meshUsers by their UUID using the new `uuid`
+query parameter.
+
+### Remove Legacy Config-Based Message of the Day Configuration
+**Audience:** User<br>
+
+#### Description
+We have removed the legacy deployment config-based message of the day (MOTD) system from meshPanel. This
+simplifies the deployment configuration and reduces complexity.
+
+#### How to use
+You can continue using the built-in message of the day capabilities through the self-service features in
+meshPanel. The removal of the config-based motd does not affect the functionality of displaying
+messages to users - it only changes how these messages are configured by administrators.
+
+### Event Logs for Policies
+**Audience:** User<br>
+
+#### Description
+We now create event logs for policies. When you create, modify, or delete a policy, these changes
+are now visible in the Event Logs section in the admin area. This provides you with better visibility and
+auditability of policy changes in your meshStack installation.
+
+### Event Log API Supports Title Exclusion for Efficient Filtering
+**Audience:** User<br>
+
+#### Description
+The meshEventLog API now supports a new excludeTitle query parameter that allows you to filter out event logs by
+title. This is particularly useful when exporting event logs to SIEM systems or other monitoring tools where you
+want to exclude high-volume event types like "Building Block Run Requested" to reduce noise and focus on relevant
+events. You can specify the parameter multiple times to exclude multiple event titles in a single request.
+
+### Improved Building Block Definition Form Order
+**Audience:** User<br>
+
+#### Description
+The form layout for creating and editing building block definitions has been reorganized to follow a more logical
+sequence. Implementation details now appear before runner configuration, making the creation process more intuitive.
+Additionally, an outdated beta notification for GitLab integrations has been removed.
+
+### Improved Event Log Author Information in Admin Area
+**Audience:** User<br>
+
+#### Description
+The event logs in the Admin Area now display more detailed author information. The Author column clearly shows what
+type of principal performed the action (API key, API user, or human user) and identifies the specific API
+key/API user/human user that executed the action. This enhancement provides better transparency and traceability
+for administrative actions in your meshStack installation.
+
+#### How to use
+Navigate to the Admin Area and open the event logs view. You will see the improved author information in the
+Author column for all newly created event logs. Please note that event logs created before this change was
+implemented will continue to show the previous author format without the detailed principal type information.
+
+### New meshIntegration API for Integration Management
+**Audience:** User<br>
+
+#### Description
+A new meshIntegration API is now available for programmatic access to integrations. The API 
+enables automated management of building block integrations (GitHub, GitLab, Azure DevOps), including 
+creation, modification, and deletion of integration configurations. Users can manage integrations within 
+their workspace scope.
+
+### Improved Unmanaged Tenant Import Stability
+**Audience:** User<br>
+
+#### Description
+We improved the reliability of importing unmanaged tenants to projects. The import process is now more stable 
+providing you with a smoother experience when assigning unmanaged tenants to your projects.
+
+### Event Logs for API Users
+**Audience:** User<br>
+
+#### Description
+We now create event logs for API Users. When you create, modify, or delete an API User, these changes
+are now visible in the Event Logs section in the admin area. This provides you with better visibility and
+auditability of API User changes in your meshStack installation.
+

docs/concepts/building-block.md

@@ -93,6 +93,23 @@ This input type is useful for granting users access to specific resources within
 ]
 ```
 
+### Sensitive Inputs
+
+Sensitive inputs are a useful feature for passing secrets like API keys or tokens to your building blocks.
+However, you should be aware of their limitations. Before using sensitive inputs, Platform engineers should consider if their use case can be alternatively solved using [Workload Identity Federation](#cloud-provider-authentication-methods) or an external key management system.
+
+Sensitive inputs are encrypted at rest using asymmetric cryptography. Our API can technically never return plaintext secrets. Values are only decryptable by the building block runner assigned to the building block definition.
+
+:::warning Changing Runners
+When changing the runner or changing the runner's public key, inputs can no longer be decrypted.
+- **For static inputs:** You need to publish a new building block definition version and resubmit plaintext values to make the building block runnable again.
+- **For user inputs:** Users need to update input values on their building blocks.
+:::
+
+Building block runners will decrypt sensitive inputs and have them accessible in their environment. Run logs are thus at risk of leaking these secrets, for example in GitHub Actions logs or Terraform logs. Platform engineers should carefully review their pipeline configuration to ensure they are not inadvertently exposing secrets.
+
+meshStack does currently not support sensitive outputs.
+
 ## Building Block Outputs
 
 Building Blocks can provide output values to both admins and users after provisioning. These outputs can include information such as resource IDs, connection strings, or other relevant data generated during automation.

docs/guides/core/how-to-get-emergency-workspace-access.md

@@ -0,0 +1,63 @@
+---
+id: how-to-get-emergency-workspace-access
+title: How To Get Emergency Workspace Access
+---
+
+meshStack manages access to cloud platforms, projects and resources. In case urgent intervention is required by someone without regular access permissions there must be a defined process to securely access projects and associated tenants. This page outlines step-by-step procedures that users with the role "Platform Engineer" can use as the basis for their own emergency procedures. Depending on your organization's requirements, these procedures can be augmented with additional organisational or technical procedures.
+
+Example use cases for emergency users and emergency intervention include
+
+- An important application has stopped functioning and operating users needs access to debug and fix the problem
+- Project access for a specific user must be immediately revoked (e.g. due to an account compromise)
+
+In all cases access permissions can always be modified through the Admin Area account which is managed by an operations team. If available, a user with workspace manager access is also sufficient for some cases.
+
+## Emergency Access with Workspace Manager
+
+If a user with workspace manager access is available, project users and roles can be managed the normal way, even if the workspace manager is not assigned to the project.
+
+First, the user requiring emergency access must be invited to the workspace
+
+- Ensure that the correct workspace is selected
+- Open the **Workspace Access** tab in the workspace control plane and navigate to **Current Access** subtab.
+- At the bottom of the screen, type in the name or e-mail of the new user and invite them with the desired role.
+
+You can also grant workspace manager rights to the newly invited user, i.e. if the emergency user needs to modify other user permissions. In this case, the new user can perform the following steps themselves.
+
+### Adding emergency as Workspace Manager
+
+The user can then be assigned to projects belonging to the workspace:
+
+- In the project overview in the workspace control plane, open the designated project by clicking on its name.
+- Navigate to the **Project Access** tab and open the **Current Access** subtab.
+- Add the user with the desired project role.
+
+Since emergency access should only be temporary, it's strongly advised to assign the user a role with a set expiration date which will ensure that the user is automatically removed from the project after the specified date.
+
+### Approving emergency user requests
+
+User project role assignments can be configured to require consent from multiple workspace managers (4 eye principle). To avoid situations where not enough workspace managers are available to confirm an urgent user role request, an admin user can confirm project role requests directly:
+
+- Ensure that the admin user is selected from the workspace drop down
+- Open "Administration" from the settings menu in the top right
+- Navigate to "Workspaces" and select "User Pending Role Requests" from the actions column for the workspace to which the project is assigned
+- Approve the user role request
+
+### Removing emergency user via workspace
+
+When emergency access is no longer required the following steps will revert performed changes:
+
+- Remove user from project by opening the project again and navigating to **Project Access** > **Current Access** (performed automatically if expiration date was set)
+- Remove user from workspace via the workspace control plane: go to **Workspace Access** > **Current Access**.
+
+## Workspace Access as an admin user
+
+Even when no workspace manager is available, admin users can manage permissions for workspaces.
+
+### Workspace History
+
+- Ensure that the admin user is selected from the workspace drop down
+- Open "Administration" from the settings menu in the top right
+- Navigate to "Workspaces" and select "Workspace History"
+
+The list contains all workspace events (i.e. sent invitations, added/removed users, role changes), when they occurred and who initiated the action. Event specific information (i.e. who the recipient of an invite was) is available via the “Details” button.

docs/integrations/aws/how-to-integrate.md

@@ -423,9 +423,11 @@ The following prerequisites must be fulfilled for the enrollment to work:
         "controltower:CreateManagedAccount",
         "controltower:DescribeManagedAccount",
         "controltower:DeregisterManagedAccount",
+        "controltower:ListLandingZones",
+        "controltower:GetLandingZone",
         "s3:GetObject",
         "organizations:describeOrganization",
-        "sso:DescribeRegisteredRegions"
+        "sso:DescribeRegisteredRegions"        
       ],
       "Resource": "*"
     }