Introduction

Security Groups act as virtual firewalls that control inbound and outbound traffic for your network resources in STACKIT. By defining rules based on IP addresses, protocols, and port ranges, Security Groups enable you to implement fine-grained network access control at the Network Interface level. They operate on an allow-list basis with default deny behavior, meaning all traffic is blocked unless explicitly permitted by a rule. This stateful filtering mechanism remembers connection states, automatically allowing return traffic for established connections.

Use cases

Common scenarios for using Security Groups include:

• Web application Servers: Allow HTTP (80) and HTTPS (443) from any IP, and SSH (22) from specific management IPs
• Database servers: Allow database port access (e.g., 3306 for MySQL, 5432 for PostgreSQL) only from application server Security Groups
• Internal services: Allow traffic only between servers within the same Security Group for internal microservices communication
• Tiered architecture: Create separate Security Groups for web tier, application tier, and database tier with appropriate rules between them

Best practices

Follow these recommendations when working with Security Groups:

• Principle of least privilege: Only allow the minimum required traffic.
• Organize by function: Create Security Groups based on server roles (web servers, databases, etc.) rather than creating one Security Group per server.
• Use descriptive names: Give Security Groups meaningful names that clearly indicate their purpose and the type of servers they protect.
• Regular audits: Periodically review your Security Group rules to ensure they still match your security requirements and remove unnecessary rules.
• Avoid overly permissive rules: Instead of allowing traffic from 0.0.0.0/0 (any IP), restrict to specific IP ranges when possible.
• Layer security: Use Security Groups in combination with other security measures like NIC Security and application-level security controls.

Considerations

• Security Group rules take effect immediately upon creation or modification
• There is no additional charge for using Security Groups
• Security Groups cannot be applied directly to servers. They must be attached via Network Interfaces
• Changes to Security Groups affect all attached Network Interfaces simultaneously
• IPv4 and IPv6 rules are configured separately within the same Security Group
• You cannot create “deny” rules—Security Groups work on an allow-list basis with default deny behavior