Working with Security Groups
This guide provides comprehensive instructions for creating and managing security groups in Thalassa Cloud VPCs. Security groups are a fundamental security control that allows you to define granular network access rules for compute instances, load balancers, NAT gateways, and managed services.
Security groups act as virtual firewalls at the resource level, providing stateful filtering for both inbound and outbound traffic. They are essential for implementing defense-in-depth security strategies and ensuring that only authorized traffic reaches your cloud resources.
Security groups have specific default behaviors that you must understand:
- Inbound Rules: If no inbound rules are defined, ALL inbound traffic is denied by default
- Outbound Rules: If no outbound rules are defined, ALL outbound traffic is denied by default
- Stateful Behavior: Return traffic for established connections is automatically allowed
Creating Security Groups
Step 1 Access the Security Groups Section
- Log into the Thalassa Cloud Console
- Navigate to IaaS → Networking → Security Groups
- Click Create Security Group
You are also able to do this through our API or Terraform.
Step 2 Basic Configuration
Fill in the basic information:
- Name: Choose a descriptive name that follows your naming convention (e.g.,
web-server-sg,db-private-sg) - Description: Add a clear description of the security group’s purpose and scope
- VPC: Select the VPC where this security group will be used
Step 3 Define Rules
After creating the security group, you can define inbound and outbound rules based on your security requirements. Rules can be added, modified, or removed at any time without affecting the resources that use the security group.
Configuring Inbound Rules
Inbound rules control what traffic can reach your resources. These rules define the sources, protocols, and ports that are allowed to initiate connections to your resources.
Important: If no inbound rules are defined, all inbound traffic is denied by default. You must explicitly allow the traffic your applications require.
Example 1: Web Server Security Group
For a web server that needs to serve HTTP and HTTPS traffic:
| Protocol | Port Range | Source | Description |
|---|---|---|---|
| TCP | 80 | 0.0.0.0/0 | HTTP traffic from anywhere |
| TCP | 443 | 0.0.0.0/0 | HTTPS traffic from anywhere |
| TCP | 22 | 10.0.0.0/8 | SSH access from private network only |
Example 2: Database Server Security Group
For a database server that should only accept connections from application servers:
| Protocol | Port Range | Source | Description |
|---|---|---|---|
| TCP | 5432 | sg-12345678 | PostgreSQL from app security group |
| TCP | 3306 | sg-87654321 | MySQL from web security group |
| TCP | 22 | 10.0.1.0/24 | SSH from management subnet |
Configuring Outbound Rules
Outbound rules control what traffic your resources can send to external destinations. These rules define the destinations, protocols, and ports that your resources are allowed to connect to.
Important
If no outbound rules are defined, all outbound traffic is denied by default. When assigning any security group, you must explicitly allow all the traffic your applications need, as the default “allow all” behavior without any security groups is switched to “deny all”.
Example 1: Web Server Outbound Rules
A web server typically needs to:
- Download updates
- Make API calls
- Connect to databases
| Protocol | Port Range | Destination | Description |
|---|---|---|---|
| TCP | 443 | 0.0.0.0/0 | HTTPS outbound (for updates, APIs) |
| TCP | 80 | 0.0.0.0/0 | HTTP outbound (for updates) |
| TCP | 5432 | sg-abc123 | Database connections |
| TCP | 53 | 172.21.8.123/32 | DNS queries (VPC internal) |
Best Practices
- Least Privilege: Only allow the minimum required ports and sources. It is advisable to use specific IP ranges or security groups instead of the default 0.0.0.0/0 whenever possible.
- Reviews: periodically review and remove unnecessary rules.
- Security Group References: When configuring security groups reference other security groups rather than relying on IP ranges. This approach results in a more maintainable and secure configuration.
- Test: After creating security groups, it is crucial to test connectivity. Tools such as
telnet,nc, orcurlcan be used to verify access and confirm that the security groups are functioning as intended.