Solr image uses configs directly from the contrib module which may lead to security issues

[AlexSkrypnyk]

lagoon/.docker/Dockerfile.solr

Line 11 in 99bfd5b

COPY --from=cli /app/web/modules/contrib/search_api_solr/jump-start/solr8/config-set/ /opt/solr/server/solr/configsets/drupal/conf

Using configs directly creates a supply chain poisoning possibility: if the search_api_solr module maintainer's account is compromised, the malicious user can add malicious configs that would be "blindly" added to the image and deployed, which can potentially wipe the Solr index.

The solution is to copy the configurations from the jump-start into a configs/solr directory manually on every new version of search_api_solr module.

[jackwrfuller]

@AlexSkrypnyk are you able to confirm if this is still an issue?

[AlexSkrypnyk]

There was no change done to the Dockerfile to mitigate this. This is still an issue.

[sonnykt]

Hi @AlexSkrypnyk @jackwrfuller

It's not an issue actually. The COPY command ensures that the latest configset from Search API exists on the Solr service on SaaS but /opt/solr/server/solr/configsets/drupal/conf is not the directory of Solr core. The directory of Solr core is /var/solr/data/drupal/conf.

To update the configset of an existing Solr core on SaaS, the following command needs to be explicitly run:

solr-recreate drupal /opt/solr/server/solr/configsets/drupal

This command is only run when there is a major upgrade, such as Solr 9 https://github.com/govCMS/lagoon/blob/3.x-develop/.docker/images/solr/890-migrate-solr9-config.sh#L13

If you look at the PaaS scaffold, you could see that the configset is manually managed https://github.com/govCMS/scaffold/blob/develop/.docker/Dockerfile.solr.paas#L7 and Dockerfile runs the solr-recreate command at https://github.com/govCMS/scaffold/blob/develop/.docker/Dockerfile.solr.paas#L13C5-L13C18