Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workaround for Docker images not identifying the true base image #17

Closed
nishakm opened this issue Mar 7, 2018 · 3 comments
Closed

Workaround for Docker images not identifying the true base image #17

nishakm opened this issue Mar 7, 2018 · 3 comments
Labels
arch Architecture changes are needed show-stopper We really really need a solution!
Milestone

Comments

@nishakm
Copy link
Contributor

nishakm commented Mar 7, 2018

When using FROM in a Dockerfile, the image that gets pulled from the Docker registry does not identify the images that they may have been based off. The only indication that this actually happens is from the 'history' in the json config file of the Docker container. There is, however, no indentifier for each of the layers in this base image other than the layer sha.

Currently the implementation uses a direct lookup in base.yml. Perhaps we can do something like this:

  1. Rather than look up base.yml, look up cache
  2. In cache have an optional repo and tag listing
  3. Use the base.yml listing for that repo and tag for the right method of getting packages
  4. Have a mapping of 'history' and layers to get clues on what commands were used to get the packages
@nishakm nishakm added arch Architecture changes are needed show-stopper We really really need a solution! labels Mar 7, 2018
@nishakm nishakm added this to the Release 0.2.0 milestone Apr 26, 2018
@nishakm
Copy link
Contributor Author

nishakm commented May 18, 2018

#41 might be a good solution. The flow might go something like this:

  1. For every entry in the snippets library add where the binary might be
  2. Get a list of tuples with the package manager and the binary path
  3. Go through the list to see whether any of the package managers are in the first layer of the container
  4. When one gets found, use the snippets to find the package metadata

There is still a distinction between baseOS package managers and application level package managers. Some name changes in the architecture is needed here for clarity.

nishakm pushed a commit that referenced this issue May 24, 2018
In order to use the layer-by-layer inspection, the control flow
for the reporting needs to change from inspecting the base image
first and then inspecting the full image to just building the
image and then inspecting it layer by layer. This is a lot of
architecture work referenced in #17 but for now, use the old
method of using Docker containers.

Added chroot=False flags for get_pkg_attr_list function call

Signed-off-by: Nisha K <nishak@vmware.com>
@nishakm nishakm modified the milestones: Release 0.2.0, Release 0.1.0 Jun 18, 2018
@nishakm
Copy link
Contributor Author

nishakm commented Jun 18, 2018

Will be solved if #51 #60 and #61 are solved

nishakm pushed a commit that referenced this issue Jul 14, 2018
Changes to work with bare filesystem layers

Tern will now use overlayfs to apply diff filesystem layers one by one
and run commands against them in a chroot environment. This
allows us to isolate the context in with the diff filesystems are created
and hence have more accuracy on what packages are installed in
which layers.

This also allows us to inspect the true base filesystem of
the image that was built using a Dockerfile and if not, then try to
inspect just the base image that would be pulled from Dockerhub or
another container registry. This will also help us provide a raw
container image to inspect instead of just the Dockerfile.

Note that the tern executable will work as expected at this merge but
may not work elsewhere along the development branch.

Resolves #5 #17 #51 #60 #61 #63

Signed-off-by: Nisha K <nishak@vmware.com>
@nishakm
Copy link
Contributor Author

nishakm commented Jul 14, 2018

Resolved in #67

@nishakm nishakm closed this as completed Jul 14, 2018
rnjudge pushed a commit to rnjudge/tern that referenced this issue Jun 5, 2020
In order to use the layer-by-layer inspection, the control flow
for the reporting needs to change from inspecting the base image
first and then inspecting the full image to just building the
image and then inspecting it layer by layer. This is a lot of
architecture work referenced in tern-tools#17 but for now, use the old
method of using Docker containers.

Added chroot=False flags for get_pkg_attr_list function call

Signed-off-by: Nisha K <nishak@vmware.com>
rnjudge pushed a commit to rnjudge/tern that referenced this issue Jun 5, 2020
Changes to work with bare filesystem layers

Tern will now use overlayfs to apply diff filesystem layers one by one
and run commands against them in a chroot environment. This
allows us to isolate the context in with the diff filesystems are created
and hence have more accuracy on what packages are installed in
which layers.

This also allows us to inspect the true base filesystem of
the image that was built using a Dockerfile and if not, then try to
inspect just the base image that would be pulled from Dockerhub or
another container registry. This will also help us provide a raw
container image to inspect instead of just the Dockerfile.

Note that the tern executable will work as expected at this merge but
may not work elsewhere along the development branch.

Resolves #5 tern-tools#17 tern-tools#51 tern-tools#60 tern-tools#61 tern-tools#63

Signed-off-by: Nisha K <nishak@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch Architecture changes are needed show-stopper We really really need a solution!
Projects
None yet
Development

No branches or pull requests

1 participant