Document the communications that occur to/from charm pods in Charmed Kubeflow's control plane

[ca-scribner]

Context

To support improved network isolation of Charmed Kubeflow components, we need to document all the communication paths that exist between Charmed Kubeflow's charms. This is important so we have a reference doc that we can design off of when hardening the networking security within Charmed Kubeflow.

In particular, this will be useful for defining tests cases and identifying special cases within the communication. The documentation should include the URLs that need to be exposed (eg: /metrics, etc) so we can know what AuthorizationPolicy objects need to be defined, and possibly so we can define broader AuthorizationPolicy objects that apply to multiple applications.

What needs to get done

see DoD

Definition of Done

1. have a document that lists all communication required into, out of, and by the Kubeflow control plane

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5167.

This message was autogenerated

[ca-scribner]

Some different communication paths to keep track of:

• charm -> Juju controller (could be inside or outside cluster)
  • also document how this communication is only one-way -- juju does not reach out to the charm
• charm -> kubernetes API
• user workloads (notebooks, pipelines) -> object storage
• user workloads -> katib or kfp?
• observability: how do we handle this? Obs cluster will be off-site (separate cluster).
• mlflow: users need to talk to MLFlow? From pipelines, notebooks, etc?