canonical/istio-operators

Decide how charms should create AuthorizationPolicies they need

ca-scribner opened this issue · 5 comments

ca-scribner commented

Context

To support improved network isolation of Charmed Kubeflow components, we need to define how a Kubeflow charm should set up an AuthozationPolicy. This should establish a uniform and easy way to be used across all Charmed Kubeflow charms

What needs to get done

See DoD

Definition of Done

  1. Recommend a go-forward plan for how our charms can request AuthorizationPolicies
  2. implement a POC or define a spec that outlines usage
syncronize-issues-to-jira commented

Thank you for reporting us your feedback!

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

This message was autogenerated

ca-scribner commented

Some ideas include:

  1. directly creating AuthorizationPolicy objects in the respective charms (essentially using lightkube to deploy the object via k8s api, for example with a KubernetesResourceDispatcher). We might be able to structure this a little by providing a helper class (via package or lib) that wraps lightkube and adds more structure to the generic resource
  2. implementing a relation (in istio-pilot?) that lets applications request one or more AuthorizationPolicy objects from istio-pilot (similar to how we create VirtualServices, although maybe with a bit less magic?), and providing a library for each charm to use
  3. use the resource dispatcher to deploy AuthorizationPolicys for each user separately?
ca-scribner commented

option (2) would be great if we can simplify what the charms need to provide, but it'll also be hard to generically support the entire CRD if we need to. Depends on how flexible we want the relation to be.

ca-scribner commented

This topic has turned out more complicated than initially expected. The main blocker is that charms typically do not know enough information to request an AuthorizationPolicy since they need to know:

  • the ServiceAccount of who wants to communicate
  • the WorkloadSelector of who is the target of the communication
    Generally, most charms will only one one of the above two.

This is documented in more detail in this spec and decisions will be made based on that spec

ca-scribner commented

Closing in favor of #377 and the tasks that follow it