Deploy App-Embedded Defender

App-Embedded Defenders monitor and protect your containers to ensure they execute as designed. Deploy App-Embedded Defender anywhere you can run a container, but can’t deploy Container Defender. App-Embedded Defenders are typically used to protect containers that run on container-on-demand services, such as Google Cloud Run and Azure Container Instances.
To learn when to use App-Embedded Defenders, see Defender types.
To learn more about App-Embedded Defender’s capabilities, see:
App-Embedded Defender is the only supported option for securing containers at runtime when you’re using nested virtualization, also known as Docker-in-Docker. Docker-in-Docker is a setup where you have a Docker container that itself has Docker installed, and from within the container you use Docker to pull images, build images, run containers, and so on. To secure the containers inside a container, use App-Embedded Defender.

Securing containers

To secure a container, embed the App-Embedded Defender into it. You can embed App-Embedded Defenders with the Console UI, twistcli, or Prisma Cloud API. App-Embedded Defender has been tested on Azure Container Instances, Google Cloud Run, and Fargate on EKS.
The steps are:
  1. Define your policy in Prisma Cloud Console.
    App-Embedded Defenders dynamically retrieve rules from Console as they are updated. You can embed the App-Embedded Defender into a task with a simple initial policy, and then refine it later, as needed.
  2. Embed the App-Embedded Defender into the container.
  3. Start the service that runs your container.
The embed process takes a Dockerfile as input, and returns a ZIP file with an augmented Dockerfile and App-Embedded Defender binaries. Rebuild your container image with the new Dockerfile to complete the embedding process. 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 embedding App-Embedded Defender, specify a unique identifier for your container image. This gives you a way to uniquely identify the App-Embedded Defender in the environment.
When securing your apps with runtime rules, target rules to apps using the App ID. (Because the App-Embedded Defender runs inside the container, it can’t reliably get information such as image and container names.)

App ID

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.
During the embed flow, you must specify a value for App ID (or more accurately, app name, which becomes part of the final App ID). In the Console, this value is presented as the image name. When specifying App ID, choose a value you can easily trace back to the image when reviewing and mitigating security findings.
As part of the embed flow, Prisma Cloud automatically generates a universally unique identifier (UUID) to represent the image ID. The image ID is a primary key in the Prisma Cloud Compute database, so it’s essential that it’s defined.
Together, the app name plus the generated UUID form the final App ID. The final App ID has the following format:
<app-name>:<uuid>
The following screenshot shows how images protected by App-Embedded Defender are listed under
Monitor > Vulnerabilities
. The
Repository
column, which represents the image name, shows two images: ian-app1 and ian-app2. Both ian-app1 and ian-app2 were specified as the App IDs when embedding Defenders into the images.
The next screenshot shows the scan report for ian-app1. Notice that
Image
is set to
ian-app1
, which was the App ID specified when embedding Defender. Also notice that the value for
Image ID
is a UUID.
Finally, back in
Monitor > Vulnerabilities
, notice that the
Apps
column shows the final App ID, which is the combination of the app name (specified as App ID in the embed flow) plus the internally generated UUID.

Embed App-Embedded Defender

Embed App-Embedded Defender into a container image from Console’s UI.
Prerequisites:
  • At runtime, the container where you’re embedding App-Embedded Defender can reach Console over the network. For Enterprise Edition, Defender talks to Console on port 443. For Compute Edition, Defender talks to Console on port 8084.
  • You have the Dockerfile for your image.
  1. Open Console, and go to
    Manage > Defenders > Deploy > Defenders
    .
  2. In
    Deployment method
    , select
    Single Defender
    .
  3. Select the DNS name or IP address that App-Embedded Defender uses to connect to Console.
  4. In
    Choose the Defender type
    , select
    Container Defender - App-Embedded Defender
    .
  5. In
    Monitor file system events
    , set the toggle to
    On
    if your runtime policy requires it.
    If App-Embedded Defender is deployed with this setting turned on, the sensor will monitor file system events, regardless of how your runtime policy is configured, and could impact the underlying workload’s performance.
    If you later decide you want to disable the sensor completely, you must re-embed App-Embedded Defender with this setting turned off.
    Conversely, if you deploy App-Embedded Defender with this setting disabled, and later decide you want file system protection, you’ll need to re-embed App-Embedded with this setting enabled.
    You can specify the default setting for this toggle so it’s set the same way for all App-Embedded Defender deployments.
  6. In
    Deployment type
    , select
    Dockerfile
    .
  7. In
    App ID
    , enter a unique identifier for the App-Embedded Defender.
    All vulnerability, compliance, and runtime findings for the container will be aggregagted under this App ID In Console, the App ID is presented as the image name. Be sure to specify an App ID that lets you easily trace findings back to the image.
  8. In
    Dockerfile
    , click
    Choose File
    , and upload the Dockerfile for your container image.
  9. Click
    Create embedded ZIP
    .
    A file named app_embedded_embed_help.zip is created and downloaded to your system.
  10. Unpack app_embedded_embed_help.zip.
    $ mkdir tmp $ unzip app_embedded_embed_help.zip -d tmp/
  11. Build the modified Docker image.
    $ cd tmp/ $ docker build .
  12. Tag and push the updated image to your repository.

Embed App-Embedded Defender manually

Embed App-Embedded Defender into a container image manually. Modify your Dockerfile with the supplied information, download the App-Embedded Defender binaries into the image’s build context, then rebuild the image.
Prerequisites:
  • At runtime, the container where you’re embedding App-Embedded Defender can reach Console over the network. For Enterprise Edition, Defender talks to Console on port 443. For Compute Edition, Defender talks to Console on port 8084.
  • The host where you’re rebuilding your container image with App-Embedded Defender can reach Console over the network on port 8083.
  • You have the Dockerfile for your image.
  1. Open Console, and go to
    Manage > Defenders > Deploy > Defenders
    .
  2. In
    Deployment method
    , select
    Single Defender
    .
  3. Select the DNS name or IP address that App-Embedded Defender uses to connect to Console.
  4. In
    Choose the Defender type
    , select
    Container Defender - App-Embedded Defender
    .
  5. In
    Monitor file system events
    , set the toggle to
    On
    if your runtime policy requires it.
    If App-Embedded Defender is deploy