Advanced Deployment Considerations
The CloudFormation template can optionally be customized beyond the default settings.
Last updated
The CloudFormation template can optionally be customized beyond the default settings.
Last updated
The 5 fields discussed in are the minimum fields that have to be set to get the product successfully deployed. For many deployments, the default settings will work well. With that said, the other options in the CloudFormation Template could be beneficial for you to configure and therefore could warrant your attention.
To view details for configuring additional settings within your CloudFormation Template you can review the sections below on this page. Feel free to SKIP this article if you just want to start with the defaults. However, please consider two exceptions:
By default, the stack will deploy without the use of a Load Balancer. There are times when this will not work for your use case. Two such scenarios are: you want to use your own DNS and SSL certificate or you want to deploy in a private subnet behind a NAT. These are both great reasons to leverage a load balancer.
If you would like to include a load balancer at the time of deployment you can do so in your CloudFormation Template. You can also add a load balancer to an existing deployment without one. And you can remove the load balancer after the fact as well. Simply run a Stack Update and add or remove the load balancer. This must be done manually through the CloudFormation Console. Specific steps to setting up a load balancer in your CloudFormation Template can be viewed below.
Resources can only be renamed to match your particular naming scheme at the time of deployment. Changing these values later will result in errors. The default values are fine to leave but if you feel the need to rename values such as your quarantine bucket you should do so now before you've deployed.
The default values provided for both the Console and the Agents will meet the needs of the vast majority of customers. If any changes are made initially, you could up the Console settings if you plan to do large sets of Scheduled Scanning or regular assessment reports. You could also adjust the Agents down to 1vCPU and 3GB Memory for similar performance and about half the cost. All of the we have done has been with 2/4, but we saw very little impact on CPU overhead and memory that reducing both of those should work. Additional testing will come with different configurations in the near future.
If you do decide to make changes for either task, you must specify the proper vCPU:Memory ratio. The memory must be in the range of 2x to 8x of the vCPU.
vCPU = .5, then 1gb <= memValue <= 4gb
vCPU = 1, then 3gb <= memValue <= 8gb
vCPU = 2, then 4gb <= memValue <= 16gb
vCPU = 3, then 6gb <= memValue <= 24gb
vCPU = 4, then 8gb <= memValue <= 32gb
If the memory specified for the Console and Agent are not within the proper range, you will see the following:
The default value is Yes and this is our preference to simplify scanning for you. In order to scan objects in buckets with a KMS Key assigned, the Scanning Agent Role requires access to the key. This setting gives the scanner role access to all KMS keys, but with only the scope to use with Amazon S3. This is good for when new buckets come online and use new keys for the encryption or you change the keys on existing buckets. The scanning agent will automatically be ready to go without a hitch.
The default value is Enabled and this will assign public IPs to the Console and Scanning Agent tasks. For the scenarios where you will not be leveraging the public IP or do not want the IP assigned at all, you can switch these values (one or both) to Disabled and we will not assign a public IP.
When you switch Only Run ... to Yes, you must change the Minimum Number of Agents Per Region to 0. Maximum Number of Running Agents Per Region can be set to any value. It can be left high or reduced down to some smaller number so you know exactly how many agents will spin up at any given time.
Number of Messages in Queue to Trigger Scaling is used to determine when the first or next scanning agent will spin up. If you are in Smart Scan mode then it will determine when the first agent spins up. Most leverage Smart Scan with a value of 1, but some like to let the work build up a bit before they spin a scanning agent up. Choose a number that makes sense for your organization.
There are times when this will not work for your use case. Two such scenarios are:
You want to use your own DNS and SSL cert
You want to deploy using private subnets behind a NAT but you also want a persistent URL that you can use to access the management console, instead of the private IP address of the console service task which will change anytime the console service reboots.
These are both great reasons to leverage a load balancer.
There are 5 fields you must provide values for in your CFT in order to stand up a load balancer:
Use a Load Balancer for the Console - change this to Yes
You'll need to specify that you want to use a load balancer. If this option is set to No the load balancer will not be deployed.
SSL Certificate ARN - specify the ARN to a certificate accessible in-region
While load balancers in AWS may not require SSL certificates in order to be stood up, because we are security-centric we require an SSL certificate as part of the LB setup process. Usually, we recommend using a wildcard SSL certificate since most of our customers access their console through a subdomain. This SSL certificate needs to either be requested through AWS Certificate Manager (ACM) OR created elsewhere with any third-party you may use for your certificate authority and then imported into ACM.
Once you have an SSL certificate that you can use in ACM you will need to take the ARN value of the certificate and paste it into the SSL Certificate ARN field of your CFT.
Should the load balancer be internet-facing or internal?
If you are using public subnets for your Load Balancer then it would make sense to set this to internet-facing. If you are using private subnets then you should set this to internal.
Load Balancer Subnet A ID - specify the Subnet ID found in the AWS console
Load Balancer Subnet B ID - specify a different Subnet ID found in the AWS console
Similar to your Management Console, you'll need to select two public or private subnets for your Load Balancer. You can choose the same subnets that you used for your Management Console if you want to reuse them.
Load Balancer subnets and the Console subnets must be in the same Availability Zones (this is an AWS requirement). For example, the Console gets put in private-subnet1 in AZ-a and private-subnet2 in AZ-b, then the load balancer should be placed in public-subnet1 in AZ-a and public-subnet2 in AZ-b. If the subnets do not match availability zones the load balancer will not be able to communicate with the console
Once the above fields have been configured you are ready to submit the CFT and let it run. After the load balancer has been stood up there will be a load balancer URL that is generated.
If you use the Load Balancer URL you may receive a browser warning that the SSL certificate is not valid, since the certificate is associated with a different domain/subdomain. It is perfectly fine to continue using just the Load Balancer URL, however if you'd like to use a custom URL you can configure a CNAME record, either in Route53 or wherever you manage your DNS records, that points a custom URL to the Load Balancer URL.
If you use Route53 you can setup the custom URL as part of the optional fields mentioned below.
The remaining fields are optional. If you happen to be using Route53 for your domain, then you can leverage these fields to setup the DNS value (although this can be done after deployment sa well). If you are managing DNS in some other way, you can skip these fields and setup DNS how you normally would to point at the Load Balancer URL.
Register a subdomain on Route53 - change this to Yes
Hosted Zone Name - specify the base domain value
Subdomain - specify the unique meaningful name to access the Antivirus for Amazon S3 application
Info Opt-Out - do not send any DNS info and version information to us
Container Security Group ID - You may specify your own security groups for us to utilize. We will add the necessary ingress routes to them. This is generally only necessary if you have an internal policy that requires all resources to be tagged at creation time
If you have a requirement to host the repo for the container images, you can specify an account number in this field to instruct the Console and Scanning Agents where to look to retrieve their images. Simply create the repos in your own account, name them as required (cloudstoragesecurity/console and cloudstoragesecurity/agent), download the images from our repos and place them into your own repo. When the console or scanning agents boot up they will look to your local repo for updates.
Go to CodeBuild
Go to "Build projects"
Click "Create build project"
Provide name, such as "ReplicateCloudStorageSecEcr"
Choose "No source" for Source provider
Select Managed image - Ubuntu - Standard - aws/codebuild/standard:5.0 - Always use latest
Check box for "Enable this flag if you want to build Docker images..."
Either create a new service role or point at an existing one you have (that you can modify to add additional permissions to)
Expand Additional configuration.
Add environment variables:
Name: AWS_DEFAULT_REGION Value: the region name you are placing this project and the ECR repos in (for example, us-east-1, but your specific region)
Name: AWS_ACCOUNT_ID Value: the account ID you are placing this project and the ECR repos in
You can leave everything else in the additional config as default settings, or customize as desired (vpcs/subnets/etc)
Buildspec - switch to editor, and paste in the provided code
Logs - customize as desired
Click "Create build project"
In the new build project, go to "Build triggers" and if desired, add a trigger for the project to run at the desired interval (recommended to run daily)
In IAM, go to the role that was created or the existing role you pointed to, and add a new inline policy matching the one provided. Keep in mind that you have to fill the <region> and <your_account_id> pieces.
You are now responsible for ensuring your local repos get updated. Our solution will now only look to your repo for updates.
By default, we uniquely name each resource we deploy with CloudStorageSec-. We often include the resource type (i.e. Queue) and append the unique application ID. When customers have a formal naming standard they would like to see our resource naming follow suite. Leveraging the fields in this section will allow you to rename all resources. Be aware, you should do this at the time of deployment. It can be done after, but it has to be done with care.
You may specify your own security groups for us to utilize. We will add the necessary ingress routes to them. This is generally only necessary if you have an internal policy that requires all resources to be tagged at creation time.
We do tag all resources, but CloudFormation will perform that tagging action in a separate step for Security Groups, so there is a short period of time during which they are untagged.
These values can be changed after the fact. Go to the page to modify the console specs. Go to the page to modify the agent specs.
Alternatively, you can select No and then manually, individually assign keys to the scanner role. Check this for more information. This value can be changed post-deployment as well by following the trouble shooting link.
The default selections will set you up to have an scanning agent running 24x7x365. Depending on your workflow and your time-to-verdict requirements, you may not need a scanning agent running all the time. Changing the Only Run Scanning Agents When Files are in Queue option to Yes will set the scanning agents to shut down completely when there is no work to be done. We call this feature This is great for cost efficiencies, but does slow down how quickly a file is scanned as it takes 60-90 seconds to spin a scanning agent up. Decide what your requirements are and then fill this section out.
Alternatively, you can create that allow you to only spin up scanning agents on a schedule basis to scan your objects (all or new).
Note: all of these settings can be changed after the fact from our page
By default, the stack will deploy without the use of a Load Balancer. Instead if you deploy using public subnets, we register your console IP with a subdomain tied to the cloudstoragesecapp.com domain in a Route53 hosted zone inside one of our Cloud Storage Security AWS accounts. If you deploy using private subnets, you will need to use the private IP that is generated by the ECS task that is stood up to host the console .
If you are unfamiliar with ACM or importing certificates into ACM, of the AWS ACM User Guide discusses importing certificates.
If you are exporting the certificate from a third-party it may not be in the PEM format AWS requires for importing certificates. If that's the case, AWS offers a blog article that discusses converting the certificate file to the PEM format using OpenSSL. You can read that article . While this article discusses converting from PFX to PEM format, other common formats for SSL certificates do exist and you'll be able to find resources online for converting the format using OpenSSL.
Do not change after the initial deployment. If you feel you need to rename any resources after deployment, please . There are ways to rename most services, but you need to be aware of the impacts.
