Merge branch 'main' into dependabot/npm_and_yarn/npm_and_yarn-25d1bbb627

Author: garloff

.github/workflows/build.yml

@@ -16,7 +16,7 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v3
         with:
-          node-version: 20
+          node-version: 24
       - name: Cache dependencies
         uses: actions/cache@v3
         with:

.github/workflows/build_and_deploy.yml

@@ -22,7 +22,7 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v3
         with:
-          node-version: 20
+          node-version: 24
 
       - name: Cache dependencies
         uses: actions/cache@v3

.github/workflows/build_and_staging.yml

@@ -20,7 +20,7 @@ jobs:
       - name: Setup Node
         uses: actions/setup-node@v3
         with:
-          node-version: 20
+          node-version: 24
 
       - name: Cache dependencies
         uses: actions/cache@v3

.gitignore

@@ -8,7 +8,6 @@
 /docs/02-iaas/guides/troubleshooting-guides
 /docs/02-iaas/guides/upgrade-guides
 /docs/02-iaas/guides/index.md
-/docs/02-iaas/deployment-examples/cloud-in-a-box
 /docs/02-iaas/deployment-examples/testbed
 /docs/03-container/components
 /docs/04-operating-scs/components

.nvmrc

@@ -1 +1 @@
-v20
+v24

blog/2026-06-16-cve-2026-46448.md

@@ -0,0 +1,88 @@
+---
+title: Lacking sanitization of Nova scheduler hints (OSSA-2026-022 / CVE-2026-46448)
+authors: [garloff]
+slug: nova_lacking_scheulder_hints_sanitization_ossa_2026_022
+tags: [security, openstack, nova, cve]
+---
+
+## The vulnerability
+
+When talking to the OpenStack Nova Compute API, Users can specify scheduler
+hints, expressing preferences for Server (VM) placement. Users can however
+inject a values `{"_nova_check_type": "rebuild"}` that is only meant to be used
+internally in the rebuild context which causes certain resource checks to be
+skipped. This can cause placement contraints such as host aggregates, AZs, image
+traits to be ignored and cause PCI pass-through resources to not be properly
+mapped. While the assigned quota is still observed, the vulnerability may cause
+exhaustion of resources and confusion of the scheduler (placement) state and
+thus may result in a Denial of Service for certain resource types.
+
+This issue was reported by Erichen, Institute of Computing Technology, Chinese
+Academy of Sciences and was subsequently analyzed and handled by Goutham Pacha Ravi,
+Dan Smith and Sylvain Bauza. It was assigned CVE-2026-46448.
+
+## Impact on the SCS software ecosystem
+
+Malevolent authenticated users could use this to schedule VMs on hosts that
+would normally not be accessible to their VMs (e.g. because they are in a
+host aggregate only available to GPU flavors which are manually enabled for
+selected customers only). This could result in resource exhaustion for
+legitimate users and cause the placement accounting to be confused.
+
+This will mainly affect providers that exposed specialized features via
+special flavors (such as e.g. GPUs) which may be scarce. In particular,
+PCI devices may be assigned without proper accounting in the placement
+service.
+
+## Embargo
+
+The issue was reported to the OpenStack Vulnerability Management Team.
+Following coordination with the reporters and upstream developers, the official
+OpenStack Security Advisory
+[OSSA-2026-022](https://security.openstack.org/ossa/OSSA-2026-022.html) was
+published on Tuesday, 2026-06-16, 15:00 UTC.
+
+## Mitigation and Fixes
+
+The fix consists in ensuring that internal `_nova_` scheduler hints are properly
+filtered out in the API exposed to users.
+
+Providers are advised to deploy fixed nova-api containers.
+The SCS ecosystem software providers will provide fixed nova images along with
+update instructions.
+
+- [OSISM](https://osism.tech/docs/appendix/security/ossa-2026-022)
+- [yaook](https://yaook.cloud/security-advisories-cve-2026-46448/)
+
+Operators where users may have caused confusion in the placement accounting
+will need to run
+
+```shell
+nova-manage placement heal_allocations
+```
+
+to ensure that accounting in the placement service is consistent again.
+
+## References
+
+- [OSSA-2026-022 Advisory](https://security.openstack.org/ossa/OSSA-2026-022.html)
+- [Launchpad Bug #2151252](https://bugs.launchpad.net/nova/+bug/2151252)
+
+## Thanks
+
+The author would like to thank the reporters, the OpenStack vulnerability
+management team and the abovementioned maintainers for reporting,
+analyzing, fixing and handling the issue.
+
+## Sovereign Cloud Stack Security Contact
+
+SCS security contact is
+[security@scs.community](mailto:security@scs.community), as published on
+[https://sovereigncloudstack.org/.well-known/security.txt](https://sovereigncloudstack.org/.well-known/security.txt).
+
+## Version history
+
+- Initial draft, v0.5, 2026-06-16, 13:30 CEST
+- Initial publication, v1.0, 2026-06-16, 17:00 CEST
+- Link OSISM advisory, v1.1, 2026-06-16, 19:30 CEST
+- Link yaook advisory, v1.2, 2026-06-17, 13:30 CEST

contributor-docs/operations/iam/identity-federation-in-scs.md

@@ -10,18 +10,18 @@ administration of user identities to the organizational entities that the
 users are part of. Usually that's customer organizations but it could also
 be the operator itself. Federation protocols like OpenID Connect can be used
 to achieve that goal. To simplify connecting the different parts of SCS
-to customer owned IAM solutions, SCS deploys Keycloak as central Identity
-Provider (IdP) service.
+to customer owned IAM solutions, the SCS reference implementation uses
+Keycloak as central Identity Provider (IdP) service.
 
-Currently this is deployed automatically only in the [osism/testbed](https://docs.scs.community/docs/iaas/guides/deploy-guide/examples/testbed/),
-which provides [its own documentation for authentication with OIDC](https://docs.scs.community/docs/iaas/guides/deploy-guide/examples/testbed#authentication-with-oidc).
+Keycloak is available as a [component of OSISM](https://osism.tech/docs/concepts/components/keycloak/)
+that operators can enable and configure as the central IdP.
 
 The following sections describe how this is done.
 
 ## 1. IaaS / OpenStack
 
 To provide Infrastrucure as a Service SCS builds upon
-OpenStack. See section [OpenStack Federation via OpenID-Connect](https://docs.scs.community/dev-docs/operations/iam/openstack-federation-via-oidc)
+OpenStack. See section [OpenStack Federation via OpenID-Connect](https://docs.scs.community/contributor-docs/operations/iam/openstack-federation-via-oidc)
 for more details on identity federation for OpenStack.
 
 ## 2. CaaS

docs.package.json

@@ -5,36 +5,12 @@
     "target": "docs",
     "label": "06-releases"
   },
-  {
-    "repo": "osism/osism.github.io",
-    "source": "docs/guides/operations-guide/openstack/tools/*",
-    "target": "docs/02-iaas/components",
-    "label": ""
-  },
   {
     "repo": "SovereignCloudStack/standards",
     "source": ["Standards/*.md", "Tests/scs-*.yaml"],
     "target": "standards",
     "label": ""
   },
-  {
-    "repo": "osism/osism.github.io",
-    "source": "docs/guides",
-    "target": "docs/02-iaas/",
-    "label": ""
-  },
-  {
-    "repo": "osism/osism.github.io",
-    "source": "docs/cloud-in-a-box",
-    "target": "docs/02-iaas/deployment-examples",
-    "label": ""
-  },
-  {
-    "repo": "osism/osism.github.io",
-    "source": "docs/testbed",
-    "target": "docs/02-iaas/deployment-examples",
-    "label": ""
-  },
   {
     "repo": "SovereignCloudStack/k8s-harbor",
     "source": "docs",