Yes they are. The only catch is - getting them to work in control-plane is more difficult, but since your flexvolume plugin worked in 3.11 where controller-manager is already conainerized, it may not be so for your particular use case.
[DC]: if you don't mind, curious to understand why you think in v4 is harder to get it working with the control-plane?
In both v3.11 and v4 - it is generally harder to use control-plane capabilities of a flexvolume driver, because controller-manager runs in a pod, the flexvolume plugin must be present inside the pod. Another aspect of this is - even if flexvolume plugin *was* present inside controller-manager pod but if flexvolume plugin binary had dependencies on the host, then the flexvolume plugin will be broken. So, in a nutshell - if your flexvolume plugin has contol-plane capabilities such as attach/detach or control-plane resizing then it is more difficult for it to work in v4 (and 3.11 also to some extent). Since control-plane in v4 is managed by an operator, there is good chance that custom overrides might be wiped away by the operator.
The flexvolume is for cifs and in order to work needs to:
1. Have the cifs packages installed
2. Have the user's kerberos keytab available (we're not allowed to use usernames and passwords)
on 3.11 we're managing this with a combination of FreeIPA (every node is a member of the ipa domain), Ansible and OpenUnison. Given 4.x's reliance on a container os (RHCOS or FCOS) my assumption was this wouldn't work anymore. Is that assumption wrong?
In v4 kubelet is directly running on the host and new location for Flexvolume plugins is /etc/kubernetes/kubelet-plugins/volume/exec . So as long as your plugin is installed there and has necessary dependencies on the host, it should work. I would assume you should still be able to install cifs package and make kerberos keytab available.