With our image rebuilt, let’s push it up to GAR and redeploy the more secure build of the application
docker push $REPO/thumbnailer:latest
Now that the newer image is in the repo, deploy it to GKE by scaling the goof deployment with kubectl. The deployment’s ImagePullPolicy forces GKE to pull the latest image from the registry.
kubectl scale deployment thumbnailer --replicas=0
kubectl scale deployment thumbnailer --replicas=1
Check for the pod to return to “Running” state with kubectl get pod
kubectl get pod
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
thumbnailer-6bbfb9cb98-p8956 0/1 ContainerCreating 0 11s
...
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
thumbnailer-6bbfb9cb98-p8956 1/1 Running 0 50s
...
Re-upload the encoded image:
./exploit.py upload encoded-k8s.png $THUMBNAILER_LB
And then try to decode the result:
./exploit.py decode result.png
Decoding content from /Users/me/goof/thumbnailer/result.png...
Traceback (most recent call last):
File "./exploit.py", line 51, in <module>
print(decode_png(png_file=sys.argv[2]))
File "./exploit.py", line 31, in decode_png
start_raw_data = ["Raw profile type:" in line for line in lines].index(True) + 3
ValueError: True is not in list
The error is because the block in the png metadata that container the payload no longer exists so we can see that the imagemagick exploit no longer works, and our container image is more secure than it was when we started.
This is one example of how a vulnerable component introduced by the container base image can have serious security implications. Without scanning it for vulnerabilities, the app works and looks harmless, but can leave a security hole in your infrastructure. Well done!
In the next module, we’ll demonstrate how the open source components in our application also open up security holes that can be exploited in our running application.