Organizing Security Groups

You can add several security groups to an instance during its creation, and add or remove groups later in the instance detail.

It is important to carefully think about your Security Groups when setting up any infrastructure. A common practice is to identify roles in your infrastructure. For example, an application infrastructure could be composed of:

• application servers
• cache servers
• load balancers
• database servers
• et cetera

In this case you could have:

• A security group called “Common” that defines rules that are common to all instances, such as SSH access or internal communication.
• One security group per role, defining rules specifically for database servers or load balancers.

When setting up a new database server, you would give it the “Common” and the “Database” security groups.

It is also good practice to apply this technique even with small architectures, where a single instance can play all different roles. This way, your infrastructure is ready for any future growth and allows for later separation of services across different instances.

Public Security Groups

In addition to groups you define yourself, Exoscale maintains a list of public security groups with particular characteristics, useful for referencing in your architecture. These groups represents Exoscale resources that are dynamically managed. At the time of writing the public security groups are:

• public-nlb-healthcheck-sources: a group with all IP addresses from Exoscale infrastructure that may reach out to test the availability of a pool of resources.
• public-sos-endpoints: a group with the Simple Object Storage endpoint that can be used to limit egress traffic for example for an instance that could only retrieve data from an SOS bucket but not the global Internet.
• public-sks-apiservers: a group with the IP addresses used by SKS Nodepools to communicate with the API Server of the Kubernetes control plane.

Extending Security Group Members with Static IP Ranges

If you intend to use security groups as a way to manage both your Exoscale hosted infrastructure and some external resources, external source support allows for registering static CIDRs as security group members.

External sources are added as valid sources for ingress rules or valid destinations for egress rules on target hosts. An alternative use case could be to create a security group dedicated to holding a set of external sources, then reference this security group in other security groups that are actually applying the network filtering rules.