Auto Scaling and Deep Security
You can set up automatic protection in Deep Security for new instances created by AWS Auto Scaling.
Each instance created by Auto Scaling will need to have a Deep Security agent installed on it. There are two ways that you can do this: you can include a pre-installed agent in the EC2 instance used to create the AMI, or you install the agent by including a deployment script in the launch configuration for the AMI. There are pros and cons for each option:
- If you include a pre-installed agent, instances will spin up more quickly because there is no need to download and install the agent software.
- If you use a deployment script to install the agent, it will always get the latest version of the agent software from the Deep Security Manager. If you use a pre-installed agent, it will use the version included in the AMI.
If you have an EC2 instance already configured with a Deep Security Agent, you can use that instance to create the AMI for Auto Scaling. Before creating the AMI, you must deactivate the agent on the EC2 instance and stop the instance:
You should never create an AMI that contains an activated agent because each agent must be activated individually. The only exception to this is if you are using Deep Security as a Service or Deep Security AMI from AWS Marketplace (see Bake the Deep Security Agent into your AMI).
Each new EC2 instance created by Auto Scaling needs to have its agent activated and a policy applied to it, if it doesn’t have one already. There are two ways to do this:
- You can create a deployment script that activates the agent and optionally applies a policy. Then add the deployment script to the AWS launch configuration so that it is run when a new instance is created. For instructions, see the “Install the Agent with a deployment script” section below, but omit the section of the deployment script that gets and installs the agent. You will only need the dsa_control –a section of the script.
For the deployment scripts to work, agent-initiated communication must be enabled on your Deep Security Manager. For details on this setting, see Use agent-initiated communication with cloud accounts
- You can set up an Event-Based Task in Deep Security Manager that will activate the agent and optionally apply a policy when an instance it launched and the “Computer Created (By System)” event occurs.
Deep Security provides the ability to generate customized deployment scripts that you can run when EC2 instances are created. If the EC2 instance does not contain a pre-installed agent, the deployment script should install the agent, activate it, apply a policy, and optionally assign the machine to a computer group and relay group.
There are several ways to run the deployment script on your instances. The method described below is to add the deployment script to the launch configuration for the AMI but, alternatively, you could run it using an orchestration tool like Chef, Puppet, or Ansible. For Windows machines, you could also run it using Microsoft GPO or System Center.
In order for the deployment script to work:
- You must create AMIs from machines that are stopped.
- Agent-initiated communication must be enabled on your Deep Security Manager. For details on this setting, see Use agent-initiated communication with cloud accounts.
To set up automatic protection for instances using a deployment script:
- Sign in to the Deep Security Manager.
- From Support menu in the top right-hand corner, select Deployment Scripts.
- Select your platform.
- Select Activate Agent automatically after installation.
- Select the appropriate Security Policy, Computer Group and Relay Group.
- Copy the script to your clipboard.
- Go to the AWS launch configuration, expand Advanced Details and paste the deployment script into User Data.
If you are encountering issues getting the PowerShell deployment script to run on a Microsoft Windows-based AMI, the issues may be caused by creating the AMI from a running instance. AWS supports creating AMIs from running instances, but this option disables ALL of the
Ec2Config tasks that would run at start time on any instance created from the AMI. This behavior prevents the instance from attempting to run the PowerShell script.
When you build an AMI on Windows, you need to re-enable user-data handling manually or as part of your image-building process. The user-data handling only runs in the first boot of the Windows base AMI unless it’s explicitly told otherwise (it’s disabled during the initial boot process), so instances built from a custom AMI won’t run user-data unless the feature is re-enabled. Configuring a Windows Instance Using the EC2Config Service has a detailed explanation and instructions for how to reset the feature or ensure it’s not disabled on first boot. The easiest mechanism is to include
<persist>true</persist> in your user data, providing that you have EC2Config version 2.1.10 or later.
After you have added an AWS Account in the Deep Security Manager, instances that no longer exist in AWS as a result of Auto Scaling will be automatically removed from the Deep Security Manager.
See Start protecting AWS instances with Deep Security as a Service for details on adding an AWS account.