How to Set up AWS Security Groups for Software Evaluation

Deploying and evaluating “big software” like Kubernetes requires setting up flocks of machines: often, for the sake of convenience, on private or public clouds. That often means deploying on AWS, which gives you means to launch well-resourced virtual machines quickly and (fairly) simply.

Working with AWS, however, means thinking — at least a little — about how to secure what you’re deploying. This is perhaps less of a consideration with Mirantis products than some others, since Mirantis stuff self-deploys in hardened configurations. But it’s always good hygiene to think about protecting systems under evaluation from exposure to the open internet.

On AWS, that means thinking about security groups. After some hundreds of Kubernetes deployments, we’ve worked out some simple ways of ensuring that clusters on AWS remain unmolested.

This tutorial describes one easy recipe for accomplishing that goal. The idea is that — if you need to deploy software across a cluster of AWS virtual machines and then exercise that software from one location (e.g., a laptop on your desk), you can pretty-well secure your servers by wrapping them all in a common security group (call this ‘eval clusters’ or something) with the following characteristics:

• Outbound

  • Lets all your machines communicate outbound without restriction. So you can deploy downloadable software on them, etc.

  • Inbound

    • Enables All Traffic to machines from other machines within the security group. This lets the machines talk to one another, unrestricted.

    • Enables All Traffic to machines from your laptop’s public IP address. This lets you deploy and evaluate the software using various helper applications (e.g., kubectl, Lens, etc.)

    • The illustration below shows such a simple security group in the AWS Security Group console:

This set of security group rules lets target machines in the same security group communicate with one another, and with the bootstrap machine on the public IP address shown.

Simple, but it does the job you need done, most. And the approach can be expanded and refactored easily to add layers of “principle of least privilege” — for example, you can replace the “all traffic from any machine in my security group” rule with inbound rules permitting only traffic on designated ports required by the application under test.