Prisma Cloud Compute Edition Administrator’s Guide
    : App-Embedded Defender
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. Install
    6. Install Defender
    7. App-Embedded Defender
    Download PDF

    Prisma Cloud Compute Edition Administrator’s Guide

    App-Embedded Defender

    Table of Contents
    End-of-Life (EoL)

    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 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
      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 aggregagted 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 aggregagted 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

    © 2023 Palo Alto Networks, Inc. All rights reserved.