Deploy App-Embedded Defender
Table of Contents
Self.Hosted 31.xx
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
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:
- 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.
- Embed the App-Embedded Defender into the container.
- 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.
- Open Console, and go toManage > Defenders > Deployed Defenders > Manual deploy.
- InDeployment method, selectSingle Defender.
- Select the DNS name or IP address that App-Embedded Defender uses to connect to Console.
- InChoose the Defender type, selectContainer Defender - App-Embedded Defender.
- Enable file system runtime protectionif 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.
- InDeployment type, selectDockerfile.
- InApp 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.
- InDockerfile, clickChoose File, and upload the Dockerfile for your container image.
- ClickCreate embedded ZIP.A file named app_embedded_embed_help.zip is created and downloaded to your system.
- Unpack app_embedded_embed_help.zip.$ mkdir tmp $ unzip app_embedded_embed_help.zip -d tmp/Build the modified Docker image.$ cd tmp/ $ docker build .Tag and push the updated image to your repository.
- 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.
- Open Console, and go toManage > Defenders > Deployed Defenders > Manual.
- InDeployment method, selectSingle Defender.
- Select the DNS name or IP address that App-Embedded Defender uses to connect to Console.
- InChoose the Defender type, selectContainer Defender - App-Embedded Defender.
- EnableMonitor 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.
- InDeployment Type, selectManual.A set of instructions for embedding App-Embedded Defender into your images is provided.
- Using the provided curl command, download the App-Embedded Defender binary into your image’s build context directory.
- Open your Dockerfile for editing.
- Add the App-Embedded Defender to the image.ADD twistlock_defender_app_embedded.tar.gz /twistlock/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.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"]
- Rebuild your image.$ docker build .Tag and push the updated image to your repository.
Embed App-Embedded Defender with twistcliPrisma 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.
- Download twistcli.
- Log into Console, and go toManage > System > Utilities.
- Download the twistcli binary for your platform.
- 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.
Unpack app_embedded_embed_help.zip.$ mkdir tmp $ unzip app_embedded_embed_help.zip -d tmp/Build the updated image.$ cd tmp/ $ docker build .Tag and push the updated image to your repository.Connected DefendersYou can review the list of all Defenders connected to Console underManage > 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 fromMonitor > Runtime > App-Embedded observations.There is an advanced settings dialog underManage > 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.
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: