Guidelines for Managed Public Cloud Solutions

Some work notes:

• Use Ubuntu 16.04.1 LTS Xenial Xerus
• use Landscape for patch management on all linux instances – Talk to CloudOps for Agent Key.
• Use windows XXXX
• Use labtech for patch management on windows instances. - Talk to CloudOps for details.
• Use Datadog for monitoring - talk to CloudOps for API keys
• All client built as much as possible with IAS (Infrastructure as Code), this includes most IaaS components.
• All code stored in Bit Bucket repo – Talk to CloudOps for access to the bitbucket team.
• All repos populated with reasonable README.md
• Try to include a diagram.
• Use Terraform ( https://www.terraform.io/ )
• Use Pass ( https://www.passwordstore.org/ )
• Use the “snapshots” terraform module, at least, to protect against data loss. Possibly upgrade to “proper backup”
• Ensure that a Statement about opting in or out of Anti Virus has been included in the Design.
• Copy all community AMIs to client specific clones. This is so that if the community release goes away a client can still be (re)built.
• Use cloud-init where possible
• Use ansible where possible to automate builds.
• Use a least privilege approach in all things.
• Do not run services as root
• Do not use stars "*" in IAM policies.
• Do not use stars "*" in Network access control rule.
• Deploy to us-east-1 unless otherwise required. Outline those requirements in the documentation.
• VPC Peer client VPC with scalar-ms-tools VPC for admin access.
• If you can't use VPC peering then use a vpn between scalar-ms-tool vpc and the client build environment.
• No not use "any any" rules for administrative access.
• Hardening - TBD - a goodstart would be just the ansible hardening that Alan Lok spliced into Tiff. It's easy, non-intrusive, and gets us off the ground. We can iterate over this.
• Use aws-logs to get system logs in to cloudwatch.
• Usernames should be valid email addresses ( se we can email when expireing )
• "Standing Army" windows instance get 100GB C: Drives by default.