Hey Jan I read through the JIRA thread and it's an interesting discussion. For our circumstances we typically use a combination of A and B but my guess is our environment is atypical as none of our hosts are exposed externally or have internet connectivity. Getting the images on our hosts is a manual process and we're also bound by monthly patching cycles so patching more frequently than that for only Solr software and its base images is not a particularly advantageous in our environment. The thread has me thinking we should probably be updating our images more frequently than we do as typically we lean towards A unless there is serious bugfix/vulnerability identified. Obviously, we do use other defence in depth security measures to complement our environment (proxied requests that limit allowed request params, basic auth, ip access/deny lists ...etc) but this should still be complemented with regular patching/pulling of these images. After this discussion going forward I'll be keeping an eye on these the images a little closer and including a fresh deploy of Solr in each release of our monthly patching cycle. I think like all environments there's not going to be a one size fits all approach and it's just up to you as a user of the software to identify your threat surface and your acceptable risk levels within it.
Thanks for the interesting discussion on the topic. Dwane ________________________________ From: Jan Høydahl <jan....@cominvent.com> Sent: Saturday, 5 February 2022 1:06 AM To: users@solr.apache.org <users@solr.apache.org> Subject: Re: Solr Docker images and timely security patching in production Indeed, helm/solr-operator makes it very smooth to do those upgrades. A thing worth noting is that if you have pinned, say 9.0, then you will get 9.0.1, 9.0.2 etc, but once 9.1 is released, there will not be new Solr bugfix releases for 9.0.x. So if you choose that route, you need to monitor new releases[1] or new security announcements[2] closely in order to upgrade manually. [1] https://solr.apache.org/feeds/solr/news.atom.xml [2] https://solr.apache.org/feeds/solr/security.atom.xml Jan > 4. feb. 2022 kl. 03:13 skrev Steve Davids <sdav...@gmail.com>: > > Just as an FYI - it looks like the Solr Helm Chart > <https://artifacthub.io/packages/helm/apache-solr/solr#running-solr> > (Kubernetes installer) goes with A by default. Though, it does allow for > easy configurability to go with other options: > > image.repository string "solr" The repository of the Solr image > image.tag string "8.9" The tag/version of Solr to run > image.pullPolicy string > PullPolicy for the Solr image, defaults to the empty Pod behavior > > Those are the defaults, you can update the Image.pullPolicy to "Always" > <https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy> > which will then mimic option C, but would require the containers to > "updated" in some capacity to trigger a re-pull/replace of that particular > container. > > Having said all that, the joy of Helm templates is that you can easily > update the Image.tag version to perform a `helm upgrade` which will then > roll out the patched version you are trying to deploy out to your cluster. > Users should be diligent with regularly updating their clusters and luckily > Kubernetes/Helm makes that very easy to orchestrate > <https://apache.github.io/solr-operator/docs/solr-cloud/solr-cloud-crd.html#update-strategy> > . > > -Steve > > On 2022/02/03 14:40:40 Jan Høydahl wrote: >> Hi, >> >> The project produces official Docker images for every release, including > our own bugfix releases. >> These images are based on an OpenJDK base image, which is again based on > a Linux base image. >> Once in a while, when there is a serious bugfix in either Linux or Java > the Solr image gets re-built by Docker. >> >> I wanted to invite to a discussion on how you as users handle security > patching in your Docker/k8s production environments. >> >> Do you: >> >> A) just pull the image once and let it sit there until next upgrade? >> B) pin the exact version, e.g. solr:8.11.1 and pull routinely for Linux / > JDK updates? >> C) pin the minor version only, e.g. solr:8.1 and pull regularly for any > new patch releases >> D) pin the major oversion only, e.g. solr:8 and pull regularly for any > new minor releases >> E) make a custom Dockerfile FROM solr:8 and add "RUN apt upgrade" or > similar to stay up to date? How often? >> F) Neither of the above. Please share your best practice >> >> This thread was triggered from > https://issues.apache.org/jira/browse/SOLR-15967, which is really about RPM > but strayed into security patching in general. >> >> Thanks, >> Jan
