You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been able to successfully create the oracle 19.3 base image, and also have patched it up through and including the 19.17 4th quarter 2022 patches.
The problem I am facing is that the oracle 19.3 base image layer contains older versions of log4j. and when security scans are run on the host, the base image layers in the /docker/overlay2 folder are getting flagged.
I understand this is a false positive because the container itself does not have the offending files in it because in a later layer we delete all the log4j files. However because the host is getting scanned, the libraries are getting flagged as vulnerabilities. And no matter what documentation we provide about them being false positives they will not accept the host having the libraries on them.
If I use the docker experimental flag to squash the image, the resulting image, and its layers no longer contain the offending files in the overlay 2 directory. This meets the scan requirements. However we have been told that the experimental squash functionality should not be used since its experimental.
After reading all the docker documentation "squash could be removed at any time because multi step builds can be used instead".
I'm sure this isn't the best place for this. But my understanding of the multi step builds is fairly limited. Our current process is that we build an oraclePatchedBase image from the /extensions/patching/Dockerfile process as documented in this project.
We then have another dockerfile where we start from that oraclePatchedBase. From that we do yum updates, stip out the offending files (basically rm log4j*) since we don't need anything using log4j. and also add in setup scripts and some dump files to load our db on startup.
what i've been trying to figure out is how I could take the oraclePatchedBase, strip the offending files with out scripts. And then start a new image from that, that only contains that final layer, and not all subsequent layers. Then we could run our yum updates and place our setup scripts and dump files.
Any help anyone might have on how to achieve this squashed without squashing image would be greatly appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have been able to successfully create the oracle 19.3 base image, and also have patched it up through and including the 19.17 4th quarter 2022 patches.
The problem I am facing is that the oracle 19.3 base image layer contains older versions of log4j. and when security scans are run on the host, the base image layers in the /docker/overlay2 folder are getting flagged.
I understand this is a false positive because the container itself does not have the offending files in it because in a later layer we delete all the log4j files. However because the host is getting scanned, the libraries are getting flagged as vulnerabilities. And no matter what documentation we provide about them being false positives they will not accept the host having the libraries on them.
If I use the docker experimental flag to squash the image, the resulting image, and its layers no longer contain the offending files in the overlay 2 directory. This meets the scan requirements. However we have been told that the experimental squash functionality should not be used since its experimental.
After reading all the docker documentation "squash could be removed at any time because multi step builds can be used instead".
I'm sure this isn't the best place for this. But my understanding of the multi step builds is fairly limited. Our current process is that we build an oraclePatchedBase image from the /extensions/patching/Dockerfile process as documented in this project.
We then have another dockerfile where we start from that oraclePatchedBase. From that we do yum updates, stip out the offending files (basically rm log4j*) since we don't need anything using log4j. and also add in setup scripts and some dump files to load our db on startup.
what i've been trying to figure out is how I could take the oraclePatchedBase, strip the offending files with out scripts. And then start a new image from that, that only contains that final layer, and not all subsequent layers. Then we could run our yum updates and place our setup scripts and dump files.
Any help anyone might have on how to achieve this squashed without squashing image would be greatly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions