Prisma Fargate App Embedded Defender protecting a container image based on scratch image

[ebrumfield]

Hello,

I'm looking for guidance on what the App embedded defender's pre-requisites are when it is going to protect a docker image that is based on the scratch image.  From what I've briefly seen there'd at least need to be a shell (/bin/sh) available in the container image defender is attempting to override the entrypoint on.  I did briefly add busybox to a scratch based image to satisfy having a shell available, but without luck, the defender entrypoint script fails with a result of 1.  Has anyone protected a from scratch docker image using the Fargate app embedded defender sidecar before?  If so, what are all of the pre-req binaries and expectations defender needs in the image it's going to protect?

Thanks,

Eric

[RPrasadi]

I would recommend reviewing the requirements document to ensure that the docker engine version is supported and the required kernel capabilities are available for the defender to access: https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/install/system_requ... If there are still issues after reviewing this document and the document on how to deploy an app embeded defender ( https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/install/install_def... ) we would need to see any errors that are available from the docker deployment.

[ebrumfield]

We already have several images being protected by prisma defender running successfully in a handful of ECS Fargate clusters, which are based on RedHat UBI 8 and UBI 8 minimal.  I've definitely followed those links.  The issue I've seen is that you can't protect a container image that is based off scratch or even busybox.  It appears that the prisma defender agent expects that /bin/sh and other binaries are available in the image, which they may not be when running a container image deriving from scratch that you're trying to protect.

To reproduce the issue you could probably try to protect any image that derives from scratch, could be a simple hello world http application that runs in a scratch based container and you try to protect it with defender, it will fail to run with defender exiting with a result/code of 1 and not much of an error.

[musiddiqui]

Hi Ebrumfield,

I hope you are doing well. The embed process modifies the container’s entrypoint to run App-Embedded Defender. The App-Embedded Defender, in turn, runs the original entrypoint program under its control.

 

When you deploy an App-Embedded Defender, it’s embedded inside the container. The embed process modifies the container’s entrypoint to run App-Embedded Defender first, which in turn starts the original entrypoint program.

 

When App-Embedded Defender sends scan data back to Console, it must correlate it to an image. Because App-Embedded Defender runs inside the container, it can’t retrieve any information about the image, specifically the image name and image ID. As such, the deployment flow sets an image name and image ID, and embeds this information alongside the App-Embedded Defender.

 

You can use the following document to deploy an app-embedded defender manually for a hello-world image:

https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/install/install_def...

 

I hope this answers your question.

[TommyHunt]

Do I recall correctly that the Fargate AppDefender is configured as a side-car?

Thus, it comes with all the dependencies that it needs.