In the openBalena V2, the BALENA_SUPERVISOR_API_KEY variable on each device is same with the api secret field value in device table of the openBalena database.
But seems it’s now encrypted or modified in V3.
We were using this to authenticate our devices on our custom web server.
Is there anyway to get this api secret value from the supervisor api key of each device?
On balenaOS device:
root@viso:/usr/app# printenv | grep BALENA
BALENA_DEVICE_TYPE=intel-nuc
BALENA=1
BALENA_SUPERVISOR_HOST=127.0.0.1
BALENA_SERVICE_NAME=solution-manager
BALENA_APP_NAME=600fdf4460af6300135b184a-1
BALENA_APP_ID=13
BALENA_DEVICE_UUID=c65c923fe8f1b4951c4ee7713ed84115
BALENA_SERVICE_HANDOVER_COMPLETE_PATH=/tmp/balena/handover-complete
BALENA_DEVICE_ARCH=amd64
BALENA_SUPERVISOR_ADDRESS=http://127.0.0.1:48484
BALENA_HOST_OS_VERSION=balenaOS 2.67.0+rev1
BALENA_SUPERVISOR_PORT=48484
BALENA_DEVICE_NAME_AT_INIT=morning-bird
BALENA_SUPERVISOR_API_KEY=a9e7ba5f767b35b3e90be6305b500679
BALENA_APP_LOCK_PATH=/tmp/balena/updates.lock
But DB:
Thanks!
Hello,
Can you please check if the value for api secret matches BALENA_API_KEY instead?
You can find more info about these variables here
Thanks for your quick reply, @rahul-thakoor
This is weird, I cannot find BALENA_API_KEY value in the container! Please check my previous message… no such value from printenv | grep BALENA!
Cheers,
Shane.
Hey there
Can you add io.balena.features.balena-api: 1 to your docker-compose file? Similar to how you’ve enabled the supervisor api (since BALENA_SUPERVISOR_API_KEY key is available)
1 Like
Hmm, not same with the API_KEY, unfortunately… 
root@viso:/usr/app# printenv | grep BALENA_API_KEY
BALENA_API_KEY=bfce078320da7f59c04c95766431c349
Not sure how we can get the api secret value in the device table?
Maybe hashed? Or any other column is used instead?
Cheers,
Shane.
Hey there, I don’t quite understand your use case, you want to use the API key inside a container? I see BALENA_API_KEY is defined correctly, what is the problem you are having?
@sradevski
We were using SUPEVISOR_API_KEY in a container. Actually were using that to authenticate to our custom REST API server on the openBalena instance.
The device table has that value, so our server was able to use this value to authenticate.
But now, on V3, api secret field value in the device table is not same with the API_KEY value on device. So our custom server cannot authenticate the balenaOS devices…
Does this make sense?
It does makes sense, thanks for clarifying. We hash the value of the API key as an improved security measure, and you shouldn’t depend on being able to read the raw value from the table, so I think the approach is not the right one. You should treat the API service as your authentication service, and pass to it an API key the same way the device does it for example. I am not sure what your custom server does, but my guess would be something like this:
Current:
Device -> get something from custom server -> custom server compares key against DB value -> decides whether it should respond with 200.
Proposed:
Device -> get something from custom server -> custom server checks with API if token has the asked permission -> decides whether it should respond with 200
Does that make sense? For example, your custom server can try to get the information of the device from the API, and if it succeeds, it means that API key comes from the device it claims it does.
