Auto-defend hosts
Host auto-defend lets you automatically deploy Host Defenders on virtual machines/instances in your AWS, Azure and Google Cloud accounts.
This covers AWS EC2 instances, Azure Virtual Machines, and GCP Compute Engine instances.
Deployment process
After setting up auto-defend for hosts, Prisma Cloud discovers and protects unsecured hosts as follows:
- Discover - Prisma Cloud uses cloud provider APIs to get a list of all VM instances.
- Identify - Prisma Cloud identifies unprotected instances.
- Verify - Ensure unprotected resources meet auto-defend prerequisites.
- Install - Prisma Cloud installs Host Defender on unprotected instances using cloud provider APIs.
Regardless of the underlying container runtime, the host deployment process skips your worker nodes.
AWS EC2 instances
Prisma Cloud uses AWS Systems Manager (formerly known as SSM) to deploy Defenders to EC2 instances.
Minimum requirements
The following sections describe the minimum requires to auto-defend to hosts in AWS.
AWS Systems Manager
Prisma Cloud uses AWS Systems Manager (formerly known as SSM) to deploy Defenders to instances.
This means that:
- The SSM Agent must be installed on every instance.
- AWS Systems Manager must have permission to perform actions on each instance.
To view all SSM managed instances, go to the AWS console here.
SSM Agent
Prisma Cloud uses the SSM Agent to deploy Host Defender on an instance. The SSM Agent must be installed prior to deploying the Host Defenders.
The SSM Agent is installed by default on the following distros.
- Amazon Linux
- Amazon Linux 2
- Amazon Linux 2 ECS-Optimized AMIs
- Ubuntu Server 16.04, 18.04, and 20.04
The SSM Agent doesn’t come installed out of the box but supported on the following distributions. Ensure its installed ahead of time before proceeeding. :
- CentOS
- Debian Server
- Oracle Linux
- Red Hat Enterprise Linux
- SUSE Linux Enterprise Server
IAM instance profile for Systems Manager
By default, AWS Systems Manager doesn’t have permission to perform actions on your instances.
You must grant it access with an IAM instance profile.
If you’ve used System Manager’s Quick Setup feature, assign the
AmazonSSMRoleForInstancesQuickSetup
role to your instances.Required permissions
Prisma Cloud needs a service account with the following permissions to automatically protect EC2 instances in your AWS account.
Add the following policy to an IAM user or role:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ec2:DescribeImages", "ec2:DescribeInstances", "ssm:SendCommand", "ssm:DescribeInstanceInformation", "ssm:ListCommandInvocations", "ssm:CancelCommand", "ec2:DescribeRegions", //You can ignore if you already have these permissions as apart of the discovery feature "ec2:DescribeTags",//You can ignore if you already have these permissions as apart of the discovery feature "ssm:SendCommand" ], "Resource": "*" } ] }
Azure virtual machines
Prisma Cloud uses the Azure VM agent Run Command option to invoke the script to deploy Host defenders.
You are required to configure the permissions below in your subscription and create host deploy rules to begin installing Defenders.
Minimum requirements
The following sections describe the minimum requires to auto-defend to hosts on Azure.
Azure Linux VM agent & Run command
Prisma Cloud uses the run command action on the Azure Linux VM agent to deploy Defenders on instances.
The VM Agent must be on every instance.
By default, the VM agent is available on most Linux OS machines.
Refer to the documentation for more information.
Currently cancelling running operation is not supported.
Dangling command will automatically timeout after 90 minutes.
Also, run command is only supported on Linux VMs.
Required permissions
In addition to the Reader role to get the list and details of the virtual machines, the Azure credential user needs permissions to invoke the runcommand.
Microsoft.Compute/virtualMachines/runCommand/action
Typically, the Virtual Machine Contributor role and higher levels have this permission. You can either directly use the role or create a custom role with the above permission.
GCP Compute Engine instances
The installation uses OS Patch Management service.
Prisma Cloud creates an OS patch job with the information of the installation script stored in the temporarily created storage bucket and the list of instances to deploy the Host defender on the instances.
Minimum requirements
The following sections describe the minimum requires to auto-defend hosts on GCP.
Storage Buckets
Prisma cloud auto creates a temporary storage bucket in the region you selected for the auto-defend rule. The bucket is named 'prisma-defender-bucket-<hash>' where <hash> is a randomly generated string, e.g., 'prisma-defender-bucket-346a7e425d344c8a7dd9ce75da674970'.
The Prisma defender installation script 'prisma-defender-script.sh' is stored in the bucket.
The service account user needs permissions to be able to create and delete the bucket.
OS Patch Management
VM Manager is a suite of tools that can be used to manage operating systems for large virtual machine (VM) fleets running Windows and Linux on Compute Engine.
Prisma cloud uses OS Patch Management service which is a part of a broader VM Manager service to deploy the host defenders.
- Setup VM Manager for OS patch management. Users can do auto enablement of VM Manager from the Google cloud console as shown here
- VM is supported on most of the active OS versions for Linux. For more information, refer to Operating system for details.
- In Google Cloud project, OS Config API should be enabled. This needs to be done via the google cloud console.
Required permissions
Prisma Cloud needs a service account with the following permissions to automatically protect GCP compute instances in your Google project.
Add the following permissions:
Compute.instances.list Compute.zones.list Compute.projects.get osconfig.patchJobs.exec osconfig.patchJobs.get osconfig.patchJobs.list storage.buckets.create storage.buckets.delete storage.objects.create storage.objects.delete storage.objects.get storage.objects.list compute.disks.get
Instance types
Auto-defend is supported for stand-alone hosts only, not hosts that are part of clusters.
For hosts that are part of clusters, use one of the cluster-native install options (e.g., DaemonSets on Kubernetes).
When configuring the scope of hosts that should be auto-defended, ensure that the scope doesn’t include any hosts that are part of a cluster or that run containers.
Auto-defend doesn’t currently check if a host is part of cluster.
If you mistakenly include nodes that are part of a cluster in an auto-defend rule, and the cluster is not already protected, the auto-defend rule will deploy Host Defenders to the cluster nodes.
Add a host auto-defend rule
Host auto-defend rules let you specify which hosts you want to protect.
You can define a specific account by referencing the re