Hello
I am looking into deploying applications using the Amazon Elastic Container Registry. The main issue I am facing is with the credentials being short-lived (12 hours).
Can I somehow add the credentials to the device OTA before an update is done?
We plan on doing our updates via a synchronous update containing Torizon OS + applications + cortex-M.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for reaching out with your question about deploying applications using Amazon Elastic Container Registry (ECR) on Toradex devices with Torizon OS. I understand your concern about the short-lived nature of AWS credentials.
To address this, you can indeed prepare your devices to handle these credentials efficiently. Here’s a streamlined approach:
Custom Torizon OS Image: Use the TorizonCore Builder Tool to create a custom Torizon OS image that includes your Docker credentials. This involves logging into your ECR from a TorizonCore device to generate a config.json file in /etc/docker with your authentication details.
Deploy via Toradex Easy Installer: Flash this custom image onto your devices using the Toradex Easy Installer. This ensures that all devices have the necessary credentials embedded in the OS image from the start.
Automate Credential Renewal: Given the short-lived nature of AWS credentials, consider automating their renewal. You can use AWS Identity and Access Management (IAM) roles and policies to manage access, and implement a script or service that periodically refreshes the credentials. This script can update the config.json file on your devices as part of your Torizon update process.
Use Torizon Cloud for OTA Updates: If your devices are already deployed, Torizon Cloud can facilitate OTA updates. You can push your custom Torizon OS image with the credentials to Torizon Cloud and deploy it to your devices, ensuring they always have valid credentials.
By embedding the credentials in the OS image and automating their renewal, you can efficiently manage your deployments, even with the challenge of short-lived AWS credentials.
I hope this helps! If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Dear @i.staehli,
Could you elaborate on what credentials you are referring to? Do you mean the token used to fetch the containers from AWS ECR?
Could you also explain how exactly you are doing the cortex M updates?
Would it be possible for you to share the actual error log/ image of “credentials being short-lived (12 hours).”
Best regards,
Collin
Yes, I mean the token that is created when calling aws ecr get-login-password.
The cortex M is updated via subsystem update. However, I didn’t add anything special that takes care of a synchronous update here.
I created a container application following the template and uploaded it to our AWS registry. When I try to update it via Torizon Cloud it fails with Secondary download failed.
If I save the authentication token to /etc/docker/config.json as explained here I can update it successfully. However, after 12 hours pass I can no longer update the application, because the token expired.
You would need to update the credentials prior to any docker-compose/application update on your devices. A synchronous update would not work here. This is because the flow of a synchronous update is that it downloads the new OS (but does not deploy it yet), and then tries to pull the new container images. Since the new OS is not deployed yet at that point, any new credentials are not yet deployed either and can’t be used for the pulling of the new container images.
This means you would need to do this separately, update the credentials let that update complete, then update the docker-compose/applications component using the newly provided credentials. There’s not really a better way to do this given the current mechanisms. It’s unfortunate ECR does not support more persistent credentials like most other container registries seem to.
If you want to do this in a single update, then you would probably need to create your own custom update logic using subsystem updates. There you could provide new credentials, log-in with them, then perform the usual docker pull and run your containers in a single update component. Though now you’d be essentially partially re-creating what we already did for docker-compose updates, which isn’t ideal. Also this theoretical subsystem update might interfere with the already existing update logic we have by default for docker-compose updates, which may lead to strange issues going forward.
In my opinion it’s probably simpler to just use the two-step update method. To summarize, first update the credentials via OS update and let that complete. Then right after (or within 12 hours at least), update the docker-compose/application componenet with the new credentials that should now be deployed. This is actually what we recommend in our documentation anyways: Using Private Registries With the Torizon Cloud | Toradex Developer Center
Best Regards,
Jeremias
