WG06 Meeting minutes 17/04/2025
Agenda
- Flux D2 Reference architecture
- Manage CVE of CNF at runtime / NIS2 regulation
- GitOps limits (upgrade/termination/source of truth): open discussion on the difficulties when the cloud native functions are not so cloud native
Supports
Minutes
Flux D2 Reference architecture
Leigh Capili (Control-plane.io shared the new D2 reference architecture. This 41 page document details the Fluxcd architecture evolution promoting OCI registry in order to decouple source control from deployment control, while improving auditability and reducing risk.
Leveraging on the FlucCD operator available under AGPL license, this new architecture seems adapted for large organizations.
Thanks to built-in security in OCI registry (signature, SBOM, workload authentication), this new architecture consolidates security for GitOps
The code is split into 3 repositories:
- Cluster wide components
- Shared infra, monitoring, networking capabilities
- application specific configuration
Leigh also detailed the new ResourceSet object, as well as some Github Action (available on control-plane github). See recording for details.
GitOps limitations
Orange shared some feedback on some limits detected when trying to apply GitOps methodology (using Fluxcd but we assume the questions coudl be generic to any GitOps implementation) to CNFs that are not really as cloud native as promise. If installation procedures are pretty straight forward, termination is often under documented. Upgrade is clearly the challenging part, which depends on the way the CNF is managed (Multiple Helm Charts, deployed through operators, deploy through Vendor orchestrator).
Orange is testing a small GO development aiming to be a GitOps watcher able to set all the FluxCD helmRelease and kustomization objects as not reconciliated in order to re-force the dependencies in case of upgrade. In fact complex upgrades require to suspend some resources and DependsOnfeature is not sufficient to ensure the synchronicity between the objects created via fluxcd and the one created by the operator deployed by flux.
The work is in progress.
Martin raised the question on the interest for operators. In one hand it is supposed to hide the complexity of the CNF LCM, in the other it is a black box ensuring a kind of locking. It could be interesting to launch a discussion on the expectations dealing with operators. Morgan indicates that today we observe different flavours of operators but the definition is not very clear. Some vendor uses operator to put some imperative deployment, some have good CRDs.
The notion of Cloud Nativeness is also very variable and could deserve a WG6 guideline to share with vendors.
We should also find a way to invite vendor to WG6 especially if they started their GitOps journey to exchange on these different aspects.
NIS2: consequence to manage 5G CVE
Due to NIS2 regulation, we will have to better manage the 5G CVE. Through The presentation, Orange shared some scenario and open question on the way to properly mange the CVE. Some questions make reference to the software supply chain and have been discussed partially in the software supply chain guideline (use a centralized reference registry with local mirrors). Launching CVE scans on production clusters will not be very efficient. Some scenarios were identified to be able to maintain a good topology of the images in a multi-countries and multi-vendors / multi-clusters context.
The question will be shared also with WG3 as it is not clear whether the management of applicative CVE could be fully handled by cluster administrators or if the knowledge of the CNF by the GitOps team could be used to manage the CNF CVE.
Misc
Review of WG6 resources: