Now that we have rebuilt our image, let’s push it up to the ECR and re-deploy the more secure build of the application.
docker push $REPO/thumbnailer:latest
Deploy it to EKS by scaling the goof deployment with kubectl now that the newer image is in the repo. The ImagePullPolicy of the deployment will force EKS to pull the latest image from the ECR.
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 /home/ubuntu/environment/goof/thumbnailer/result.png...
Unable to find hacker metadata in the image. Nothing to see here!
We get a different result because the block in the png metadata that contains the payload no longer exists. 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.