ASM fails to start up in clusters that have PodSecurityPolicies enabled

[alexbrand]

Clusters that have the PodSecurityPolicy admission controller enabled do not admit the ASM pods, given that the istio/asm service accounts do not have use privileges on PSPs.

I am wondering if the ASM package should include PSPs and corresponding role bindings. On one hand, it would make the installation experience better. On the other, it could be considered a layer/responsibility violation.

Curious about everyone's thoughts on this.

[zerobfd]

I'm not too familar with PSPs, but my initial feeling is that it feels like a responsibility violation. That being said, looking at https://kubernetes.io/docs/concepts/policy/pod-security-policy/#via-rbac it does seem like install_asm could help make the config smoother.

One option would be to have the --print-config option spit out a ClusterRole/ClusterRoleBinding/ServiceAccount that are pre-configured to use workload identity, and have the user apply them. Can you think of anything else we can do without actually having the installer apply anything to the cluster?