[Bug]: Pod Role Security Issues

[mmckane]

Bug Description

The service account that pods run as is granted rights to patch itself. This seems like a security issue as anyone compromising a pod can manipulate any pod settings which could be used to further escalate and attack the cluster. such as changing security settings and even the image or its start args.

Removing these security roles breaks Solace as it appears that solace is trying to update it's own labels based on the role of the pod.

This approach for the app to intelligently label itself while clever seems to present a large security risk

Expected Behavior

Pods that have ingress to them and that could be exploited, should not be able to talk to the kubernetes api, or have roles that allow patching of pods. I would suggest that either the way labels are being added be changed or another method of tagging pods in the statefulsets with active be changed.

I think moving the logic to label pods into a standalone container that runs as an elevated service account that does not have ingress open to it might be a good compromise. This would probably require a way to query pods in the statefulset to determine their role and tag the pods out of band.

Steps to Reproduce

Deploy Solace and view pod service accounts. Or set network policy to block access to the kubernetes API (note if this is the case you get no errors other than the pods never go healthy due to the current health check scripts)

Solace Broker version

all

Solace API

all

Solace API version

all

[LewisKSaint]

Thank you for raising this @mmckane.