Add IAM minutes for 20240911

iam/20240911.md

@@ -0,0 +1,62 @@
+# 2024-09-11
+
+## Participants
+
+- @gtema
+- @garloff
+- @josephineSei
+- @bitkeks
+- @90n20
+- @markus-hentsch
+- @JuanPTM
+- @o-otte
+
+## Housekeeping
+
+* Minutes taking & transfer: @gtema
+* Reporting in Comm Call: @garloff
+
+## Agenda
+
+### Security infra pipelines (@bitkeks, @90n20)
+
+* There's multiple PRs in the infra pipeline repo looking at performance of VMs. How do we proceed?
+    * https://github.com/SovereignCloudStack/security-infra-scan-pipeline/pull/10
+    * https://github.com/SovereignCloudStack/security-infra-scan-pipeline/pull/11
+    * https://github.com/SovereignCloudStack/security-infra-scan-pipeline/pull/13
+    * Currently issues with gx-scs (starting VMs stall
+* We should also add limits to the triggers of Zuul pipelines so they do not run in full when e.g. a license file is updated
+    * https://github.com/SovereignCloudStack/security-infra-scan-pipeline/issues/14
+    * Filtering is hard: Only trigger when certain files are changed (inclusive approach) or not triggering on certain files (exclusive approach)
+    * Differentiation between base and full job -- ensure that [PR#10](https://github.com/SovereignCloudStack/security-infra-scan-pipeline/pull/10) does not break that differentiation
+        * suffix `-test` indicates that we just check whether the test pipeline works, without suffix we have a full ("production") test run
+        * avoid putting everything into base job
+        * variables with yaml anchors make things reusable
+* ToDo: Look into SBOM generation via pipelines
+    * Assumption is that we have a yaml file with a list of artifacts
+        * Works also with artifacts that come from other registries also
+        * Scan results end up in depdency track
+        * save/publish SBOM artifacts
+    * AI @gtema: Drive the creation of the yaml
+        * Release-Notes repository is the right place
+        * Future: Maybe rename the repo to Release-Artifacts or so (if we can avoid broken links)
+
+
+### IAM (@garloff, @gtema, @juanptm)
+
+* Drawing the bigger IAM picture based on the input from the [IAM workshop](https://input.scs.community/Workshop-IAM-20240830#)
+* Working on a [requirements and design document](https://input.scs.community/scs-federation#)
+    * May need splitting
+    * Please contribute
+
+### Domain Manager Standard (@markus-hentsch)
+
+- upstreaming almost done
+    - feature merged! -> domain manager will be available natively starting with OpenStack 2024.2
+    - upstream documentation and tempest test additions currently under review
+- currently, SCS will be based on 2024.1 = no native domain manager feature yet, only optional downstream implementation via policies as per SCS Domain Manager standard
+    - with a future SCS release (as soon as 2024.2 or later lands in SCS), native integration will take over and the downstream implementation will be discontinued
+        - issue tracking the planned discontinuation: [issues#723](https://github.com/SovereignCloudStack/standards/issues/723)
+- Using Domain-Manager inside C&H?
+    - Under evaluation at C&H
+    - Federation not required in the current projects