I use a private Azure Container Registry to host my containers and I follow this doc to setup authentication in Torizon OS on the deployed device.
Basically it works, but when I run the command
WARNING! Your password will be stored unencrypted in /etc/docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Since security is a hot topic, is it possible to setup such kind of credential helper in Torizon OS?
Is there any documentation on how to do this?
The other (minor) issue is that when the file /etc/docker/config.json is deployed as TCB customization, only root has rights over the file
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, there is no specific information about setting up a credential helper for Docker authentication on Torizon OS. The context discusses using the TorizonCore Builder Tool and Torizon Remote Updates to manage Docker credentials, but it does not mention configuring a credential helper to store credentials securely.
To address the warning about storing passwords unencrypted, you would typically configure a credential helper as suggested in the Docker documentation. However, without specific instructions or documentation from Toradex on setting this up in Torizon OS, I cannot provide a detailed solution.
I recommend checking the official Docker documentation for setting up a credential helper and seeing if it can be adapted for use on Torizon OS. Additionally, reaching out to Toradex support or community forums might provide more specific guidance or updates on this topic.
Please, also check if these links can help you solve your problem:
Since security is a hot topic, is it possible to setup such kind of credential helper in Torizon OS?
Is there any documentation on how to do this?
At the moment we do not have any articles about this topic. However, it is something we will discuss and explore during our 7.X releases since security will be at the forefront with this major release series.
Is there a way to give read rights to torizon use through TCB?
Just to understand. Why do you want the torizon user to have read access to this?
So during production when your device is in the field it’s assumed you’re using the docker-compose.service to start/run your containers. Since this is a systemd process it will look in /etc/docker and since systemd uses by default root this is fine.
So in what case would you want a non-root user to have access to /etc/docker as well? Do you plan to have the torizon user access this when your device is in the field already?
Thanks for the explanation.
Your’re right. I don’t need a non-root user to have access to /etc/docker file.
During my development stage, I connect to the device through SSH (with torizon user) and I would like being able to call docker pull
This would require that ~/.docker/config.json is customized as needed.
So the real question is: how can I use TCB to deply files under the home folder for torizon user (with proper rights for torizon user)?
A possible alternative for development would be to use TorizonCore Builder to bundle a container with the required files and bind-mount the home directory.
Depending on the desired outcome, this container could run a simple script to copy the right file to the host system.
Just to expand on What Bruno has said. TorizonCore Builder is tool for creating production images. Since you’re talking about creating this file for development purposes it’s sort of out of scope of the tool’s purpose.
Just to understand why do you want to do this with TCB specifically? If it’s for development purposes can’t you just make the file on the device manually? Since it won’t be needed in production if I understand you correctly, right?
When I wrote about “development” I mean an activity done by a team. The members of the team have different skills/knowledge and work on different SoMs on their desk.
So I search a way to “make a Torizon OS image available to the development team”.
It’s not production, but it’s not development on my desk.
Correct, that’s all I can provide at the moment since we just started Torizon OS 7.X. And it will really depend on our own planning and priorities which are always changing.
This is rather delayed, but I wanted to write a public response here because @jeremias.tx and I discussed this internally.
A docker credential helper is generally intended to be a way for the docker daemon to interact with some system-level credentials provider, that can leverage user interactivity to unlock credentials from a keychain or similar. It’s actually a really simple interface: you just need to create an executable called docker-credential-yourhelpername somewhere in your path, and configure docker to use the yourhelpername credsStore. The executable should accept a URL as a string on stdin, and write the credentials for that URL on stdout if those credentials are known to the helper.
So the idea of a credential helper is to use some kind of system credentials store, whose access would presumably be controlled by some other policy engine, usually with user interaction. If you use the docker-provided osxkeychain helper, for example, it will use the keychain, and ask the user to enter their password, or authenticate with a fingerprint, to authorize the release of the credential.
This dynamic is less useful on an embedded system: we generally don’t want user interaction to be required before a docker image can be pulled. It’s still quite possible to implement a credential helper that might, for example, grant access to a secret stored in an HSM. But the excess security benefit here of implementing this as a credentials helper is less clear than in the user interactivity case. I think that what I would recommend as simpler alternative if you need to have hardware-backed security would be to store the credentials in an encrypted-at-rest partition you’ve created using meta-toradex-security.
But that being said, if the encrypted partition option doesn’t work for you it’s really quite easy to implement a credentials helper that meets your specific needs; it can even be something as simple as a bash script that calls out to your underlying secret store, whatever it may be, and mangles the response into a json object with jq (which is available by default in Torizon OS).
