feat(cos-dev): Service mesh

[MichaelThamm]

Issue

COS-Dev lacked support for a service mesh (Istio) as an alternative networking layer. Users who want mTLS and configurable mesh authorization policies in COS-Dev had no way to enable it.

Solution

This PR adds service mesh support to the COS-Dev Terraform module using Istio (istio-beacon-k8s and istio-ingress-k8s).

Summary

• service_mesh=true (default false) that gates all mesh-related resources.
  • A validation rule prevents service_mesh and internal_tls from both being true.
  • both can be false i.e., no networking security
• istio-ingress and istio-beacon modules are conditionally deployed when service_mesh = true.
• juju_integration.istio_ingress, juju_integration.grafana_istio_ingress, and juju_integration.istio_ingress_route mirror the existing Traefik ingress integrations but route through Istio. They replace the Traefik integrations when mesh is enabled.
• juju_integration.istio_beacon wires the istio-beacon charm's service_mesh endpoint to all COS components.
• No mesh endpoints are offered for CMR integrations e.g., provides_cmr_mesh for COS components since a user can communicate securely with a mesh-enabled COS component via Istio ingress.

Testing Instructions

Run the Terraform tests:

tf -chdir=terraform/cos-dev init
tf -chdir=terraform/cos-dev test

[adhityaravi]

First pass - we need to add the istio-k8s charm into the deployment which seems to be missing at the moment. It probably needs to be in its own model istio-system

[MichaelThamm]

@adhityaravi I would argue that this does not belong in our product, rather deployed separately. Similar to what we do with external-ca model in our itests for external-tls:

• https://github.com/canonical/observability-stack/blob/main/tests/integration/cos_dev/tls_external/track-dev.tf#L29-L41

However, this is up for debate because the CC008 spec does impose anything on us. I guess the question is: could COS operate without istio-k8s in the COS model? Since the "best-practice" is to have this in a separate model, then we want this to be integrated with COS via juju_offers and accepting integrations via inputs. We need to think carefully about this as this will start to become more and more of an API burdon: previously we only had to support the external__offer_url. We should try to see if implementing:

For optional external integrations (e.g. COS), the product modules should expose the variables to allow the external integrations with user-defined endpoint/offers

make sense. Ref link

[MichaelThamm]

We need to feature resources here like in this PR for example:

• feat: Resource image configuration #360

This requires the beacon and istio modules to feature this as an input as well, e.g.:

• feat: TF resources variable alertmanager-k8s-operator#411