All https connections to/from the Kubelet server don't do any certificate verification. MiTM, if possible, should work. It is a known weakness, the internal communications between cluster members are considered trusted: https://kubernetes.io/docs/concepts/architecture/master-node-communication/: "By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks."
Helm charts are a way to deploy a full K8s cluster, basically combining multiple yaml config files together, hence often considered as being a "package manager" for K8s.
Before v3 of Helm, a server component was used, called "Tiller". This component was installed within a pod and is known to be a classic privilege escalation weakness as it accepts, within the cluster, unauthenticated connections to deploy any "chart". Attackers being on a pod can of course abuse this to deploy pods of their choosing, create service accounts, etc.
A good writeup from ropnop perfectly describes the type of chart you would want to deploy as an attacker. Basically downloading the binary helm client and pushing charts that help you read files on the Tiller pod (the Tiller service account is usually cluster admin) or create other pods/service accounts you can use to elevate privileges. Helm version 3 has completely removed the Tiller component as it is/was indeed difficult to integrate securely within the cluster.