I’m curious how patching works for docker instances vs buildpack instances.
Say I release a django service on the standard python buildpack, and a django service using docker as python:3.10.1-slim as the base. In 6 months, a new heartbleed style attack comes out and both services need patching. In both cases the underlying image will need to be updated to patch the exploit.
Will I need to manually trigger a new release for both services? What, if any automatic updating is available for either service?
Hi @bbeecher,
In the scenario that you provided, Render would be responsible for updating the python native environment with the necessary patches, while the Render user would be responsible for applying any patches for the docker build. In both cases, a new deploy would be required to take advantage of the updates. We don’t currently have any way to automate this, but I could see how it would be useful to allow users to optionally opt into the latest updates and patches, so that they are deployed automatically. Please feel free to submit a feature request around this if this is something you’d like to see!
I think that would be useful - I have a fair number of services/clients I don’t want to touch after the engagement ends but it would be nice to be able to guarantee some amount of security.
It wouldn’t help for any services that are still docker based though (redis/minio). Since those are driven by the base image updating, is there anything on the roadmap about automatically triggering a redeployment when a base image is updated?
So (even when using a native environment and not depending on a docker image which would need its own update) for libraries security updates or security updates of the kernel to be applied a “manual” redeploy is necessary ? If I leave a service without regularly manually redeploying or triggering a deployment through github/gitlab I’d be running my app in a potentially vulnerable environment ?
What about GNU/Linux distros’ upgrades ? Is a manual redeploy needed to switch from a Debian/Ubuntu (or whatever distro) release to another when you’ve decided it’s time ?
Thanks in advance.
One of the comparisons to Heroku is that render never does scheduled restarts, and I assume they’d need to break that guarantee to do patching of existing services. I’d rather have the security guarantee though, especially if the restart/deploy could be zero-downtime like a normal deploy.
Thanks @bbeecher, you definitely bring up some very valid concerns. I’ve created a feature request to outline both of the cases you mentioned here: Allow users to opt into auto-deploy for security updates | Feature Requests | Render
@Heroe-D That’s correct - patches that are applied to our native environments would require a redeploy to take advantage of the latest updates. Regarding the base image, we currently use Debian for all of our base images. A manual redeploy would be required to pull the latest updates there as well. If you choose that you want to have more control over the distro then we would recommend deploying via Docker instead of our native environments.
Seems like setting up a cron job in our own to hit the redeploy endpoint every X days is necessary then, while still taking advantage from zero downtime feature.
Thanks for creating the issue - upvoted it!