Focus
Focus
Table of Contents

Deploy App-Embedded Defender

App-Embedded Defenders monitor and protect your applications from the entrypoint script and all the entrypoint child processes 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 the entrypoint in applications in containers that run on container-on-demand services, such as Google Cloud Run (GCR) and Azure Container Instances (ACI).
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 applications 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 is 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 is 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 Prisma Console 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 > Deployed Defenders > Manual deploy
    .
  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. Enable file system runtime protection
    if your runtime policy requires it.
    If App-Embedded Defender is deployed with this setting enabled, 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 disabled.
    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 set a default file system protection state 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 aggregated 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 > Deployed Defenders > Manual
    .
  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. Enable
    Monitor file system events
    , if your runtime policy requires it.
    If App-Embedded Defender is deployed with this setting enabled, 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 to disable the sensor completely, you must re-embed App-Embedded Defender with this setting disabled.
    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 set a default file system protection state for all App-Embedded Defender deployments.
  6. In
    Deployment Type
    , select
    Manual
    .
    A set of instructions for embedding App-Embedded Defender into your images is provided.
    1. Using the provided curl command, download the App-Embedded Defender binary into your image’s build context directory.
    2. Open your Dockerfile for editing.
    3. Add the App-Embedded Defender to the image.
      ADD twistlock_defender_app_embedded.tar.gz /twistlock/
    4. Add the specified environment variables.
      When setting DEFENDER_APP_ID, specify a value that lets you easily trace findings back to the image. All vulnerability, compliance, and runtime findings for the container will be aggregated under this App ID In Console, the App ID is presented as the image name.
    5. Modify the entrypoint so that your app starts under the control of App-Embedded Defender.
      For example, to start the hello-world program under the control of App-Embedded Defender, specify the following entrypoint.
      ENTRYPOINT ["/twistlock/defender", "app-embedded", "hello-world"]
  7. Rebuild your image.
    $ docker build .
  8. Tag and push the updated image to your repository.

Embed App-Embedded Defender with twistcli

Prisma Cloud supports automation for embedding App-Embedded Defender into container images with either twistcli or the API. This section shows you how to use twistcli. To learn how to use the API, see the API docs.
Prerequisites:
  • The container where you’re embedding App-Embedded Defender can reach Console’s port 8084 over the network.
  • You have the Dockerfile for your image.
  1. Download twistcli.
    1. Log into Console, and go to
      Manage > System > Utilities
      .
    2. Download the twistcli binary for your platform.
  2. Generate the artifacts for an updated container with twistcli.
    A file named app_embedded_embed<app_id>.zip_ is created.
    $ ./twistcli app-embedded embed \ --user <USER> --address "https://<CONSOLE>:8083" \ --console-host <CONSOLE> \ --app-id "<APP-ID>" \ --data-folder "<DATA-FOLDER>" \ Dockerfile
    • <USER> — Name of a Prisma Cloud user with a minimum role of Defender Manager.
    • <CONSOLE> — DNS name or IP address for Console.
    • <APP-ID> — Unique identifier. When setting <APP-ID>, specify a value that lets you easily trace findings back to the image. All vulnerability, compliance, and runtime findings for the container will be aggregated under this App ID. In Console, the App ID is presented as the image name. For example, my-app.
    • <DATA-FOLDER> — Readable and writable directory in the container’s filesystem. For example, /tmp.
    • To enable file system protection, add the --filesystem-monitoring flag to the twistcli command.
  3. $ mkdir tmp $ unzip app_embedded_embed_help.zip -d tmp/
  4. Build the updated image.
    $ cd tmp/ $ docker build .
  5. Tag and push the updated image to your repository.

Connected Defenders

You can review the list of all Defenders connected to Console under
Manage > Defenders > Manage > Defenders
. To see just App-Embedded Defenders, filter the table by type, Type: Container Defender - App-Embedded.
By default, Prisma Cloud removes disconnected App-Embedded Defenders from the list after an hour. As part of the cleanup process, data collected by the disconnected Defender is also removed from
Monitor > Runtime > App-Embedded observations
.
There is an advanced settings dialog under
Manage > Defenders > Manage > Defenders
, which lets you configure how long Prisma Cloud should wait before cleaning up disconnected Defenders. This setting doesn’t apply to App-Embedded Defenders. Disconnected App-Embedded Defenders are always removed after one hour.

Recommended For You