November 16, 2017 | Written by: Leslie Lundquist and Dan Moravec
Categorized: Network | Products | Security
Share this post:
In a cloud environment, you must consider “who talks to whom.” One way to regulate this conversation is through security groups.
Implementation of security groups
Our implementation of security groups is a traditional one. It’s based on rules for allowing (or not allowing) network connections, which apply to groups and their assigned members. We provide the tools to associate your security groups with virtual server instances (VSIs) easily. In fact, using the graphical user interface, you can quickly apply a security group to any VSI in your account.
As shown above, the private network interfaces along with the public interfaces are displayed on the UI screen, based on how you created your VSIs. You can point and click to select the interfaces to which you want to apply a security group.
A security group rule defines the source and the destination for all traffic (packets). The source type is either a range of IP addresses (specifically, a CIDR block) or another security group, which we call a “remote security group.”
You can select among your groups and establish the security mappings accordingly. Using remote groups, you can establish network security mappings between dynamic groups of VSIs. The mappings can be “many to many,” as in a classic three-tier security architecture model. The remote security groups define the mappings between the layers. As you add VSIs to a security group, the network security mappings you’ve defined are applied automatically.
Our security groups are not restricted in terms of regions and availability zones. Rule changes may fan out to many hosts across different data centers; however, our infrastructure provides an easy way to keep your virtual servers secure and updated with your latest policies.
Strategy for your security groups usage
Security groups are defined to suit your requirements. For example, if you deploy different applications on different subnets, you can easily control traffic at the subnet level by placing your instances in security groups that correspond to the subnet. You can also apply rules based on a CIDR block (subnet). Essentially, a rule can say, “You can trust anything from this CIDR block” or anything from another security group, which could be defined in various ways (again, including mapping to a subnet).
So our implementation is powerful because you can mix and match using inbound and outbound CIDR block ranges along with remote security groups, which fits well for most cloud installations. Remote security groups are essentially good “handles” to manage instance-based security, either individually or in groups.
Using our security groups, you can take control of your cloud apps and lock down network security. You’re the one to decide who’s talking (and who isn’t talking) to your apps. There is value and ease in having both capabilities that our infrastructure provides—managing security groups by subnet and by instance.
Get started with the security groups API
Want to see how security groups are used? We’ve got programmers’ examples of how to use the API for security groups. Examples are available primarily for Python, but also for REST APIs.