podman inspect registry.access.redhat.com/ubi8/ubiContainer images can easily be pulled from any public registry and run on a container host but is this good practice? Can you trust this image and what are its contents? A better practice would be to inspect the image before running it.
Podman inspect
Use podman to inspect the registry.access.redhat.com/ubi8/ubi image. Remember, this image must be present in local storage. Examine the output to determine who is the maintainer and what is the version of that image?
Podman diff
The podman diff command can help understand the difference between a container image and its parent.
podman diff --format=json registry.access.redhat.com/ubi8/ubiPodman live mounts
Next we’ll use the podman command to inspect a container’s filesystem by mounting it to the host.
First, launch a long running container in the background.
sudo podman run -d --name sleepy registry.access.redhat.com/ubi8/ubi sleep 99997ce0fdb9d8a9345e760fbcbf460d795a0a50cba1ac6e0ffe0e894c7a927cdcda
Next, enter the container’s namespace, create some data then exit back to the host.
sudo podman exec -it sleepy bashThe previous podman command will give you a shell within the container shell. Now, create some data:
date >> /tmp/date.txt
exitNext, mount the container. The host mount point should get displayed.
sudo podman mount sleepy/var/lib/containers/storage/overlay/<container-id>/merged
Using the directory returned from the above mount command, confirm the date.txt file exists in the mounted file system.
export MOUNTED=`sudo ls -tr /var/lib/containers/storage/overlay | tail -2 | grep -v backingFsBlockDev`
sudo cat /var/lib/containers/storage/overlay/$MOUNTED/merged/tmp/date.txtTue Apr 16 19:45:11 UTC 2019
How might you search this container’s file system for all programs that are owned by root and have the SETUID bit set?
sudo find /var/lib/containers/storage/overlay/$MOUNTED/merged -user root -perm -4000 -exec ls -ldb {} \;-rws--x--x. 1 root root 47424 Nov 20 2018 /var/lib/containers/storage/overlay/c1add9d7 571f099af67704bea5774efaa3df3351d8ccafc60dc0678e91e5ff5c/merged/usr/sbin/userhelper -rwsr-xr-x. 1 root root 13376 Dec 7 2018 /var/lib/containers/storage/overlay/c1add9d7 571f099af67704bea5774efaa3df3351d8ccafc60dc0678e91e5ff5c/merged/usr/sbin/pam_timestamp_ check ... ... ...
Un-mount the container when you’re finished.
sudo podman umount sleepy<container-id>
Stop and remove the running container.
sudo podman stop sleepy
sudo podman rm sleepyWorking with Skopeo
Skopeo is an additional low level tool that can perform image operations on local or remote images. Give the examples below a try.
Inspecting images
Try the following skopeo commands to inspect images from a remote registry. How
many layers does the ubi image contain?
Try to inspect an image in local container storage. What command did you use?
skopeo inspect docker://registry.access.redhat.com/ubi8/ubi{
"Name": "registry.access.redhat.com/ubi8/ubi",
"Digest": "sha256:1f0e6e1f451ff020b3b44c1c4c34d85db5ffa0fc1bb0490d6a32957a7a06b67f"
,
"RepoTags": [
"8.1",
...
...
...
}
Skopeo can also copy images between two registries. See the skopeo(1) man page for details and give it a try. An example is shown below. To make this work, the proper image tags must exist and authentication to registries must be in place.
skopeo copy docker://node1-0.example.redhatgov.io:5000/fedora/latest docker://node2-0.example.redhatgov.io:5000/fedora/latestGetting image source signatures Copying blob ba795627ed38 done Copying blob 5d5058e0252a done Copying config 8121a9f530 done Writing manifest to image destination Storing signatures
×
Workshop Details
| Domain |
|
|
| Workshop | ||
| Student ID |
Workshop Details
| Domain |
|
|
| Workshop | ||
| Student ID |