Step 5: Re-deploy the Application to test the fix
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.
Push to ECR
docker push $REPO/thumbnailer:latestRe-deploy the Application to EKS
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=1Wait for the pod to start…
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
...Run the ImageMagick Exploit again to verify the fix.
Re-upload the encoded image:
./exploit.py upload encoded-k8s.png $THUMBNAILER_LBAnd 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.