wpa_supplicant will not be running in the container unless you start it.
A major difference between docker containers and a normal environment is that there are no system services running in the container unless you run it with
systemd as the base command, since it is init (systemd is an init implementation) that manages these.
Containers are intended to do specialised things, not simply duplicate the host environment. Rather than umpteen background processes running, you have only those that you explicitly start.
You do not need to need to use init to run
wpa_supplicant, however -- and not having it running simplifies things considerably, because there are no networking daemons to interfere with your intentions.
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/my.conf -B
Will start it, and go to the background if successful (
-B). You may have to first:
ip link set wlan0 up
Both these require root privilleges. Wpa_supplicant and the
wpa_cli interface use a local socket for communication, so should not require any other system services. You may need to indicate the socket; see
man wpa_cli and
ctrl_interface in the conf file.
If what you are trying to do is communicate with the
wpa_supplicant already running in the host, you can't. This is not about permissions, this is about the logic of containerization. Although
wpa_supplicant uses a socket to communicate, it is a unix local socket, meaning it is only accessible on the local system via a file path, not an inet address.
You should not need to do this. If you need to do things with the host networking, you need to do it from the host.
If that's not what you are up to (i.e., you want to actually initiate an internet connection from within the container), note
wpa_supplicant is not the only component of such.