IBM Cloud security groups are a set of IP filter rules (five-tuple rules: source and destination IP, source and destination port, and protocol) that define how to handle incoming (ingress) and outgoing (egress) traffic to both the public and private interfaces of a virtual server instance. The rules added to the security group are known as security group rules.
Here are a few things to keep in mind about security groups:
You can assign security groups to a single virtual server or multiple virtual server instances.
You can assign security groups provided by IBM or ones you create.
Only “Allow” rules can be added to a security group, which means only the traffic that satisfies the rule is allowed; the rest of the traffic is denied.
Security groups provided by IBM
You can assign any of the following security groups that are provided by IBM to the network interfaces of your virtual server instances:
allow_ssh: This security group defines the IP rules that allow ingress TCP traffic on the SSH port only (22/TCP). All other traffic is blocked.
allow_http: This security group defines the IP rules that allow ingress traffic on HTTP port only (80/TCP). All other traffic is blocked.
allow_https: This security group defines the IP rules that allow ingress TCP traffic on HTTPS port only (443/TCP). All other traffic is blocked.
allow_outbound: This security group defines the IP rules that allow all egress traffic from the server.
allow_all: This security group defines the IP rules that allow all ingress traffic on all ports.
Each predefined security group contains one security group rule.
Using security groups
In the following diagram, virtual server instances are associated with a set of security groups to restrict network traffic. The arrows represent network traffic flow. The application developer has restricted access to the various infrastructure layers, as follows:
The application developer can access only the web layer on TCP port 443 (https).
Only web layer instances can access the application layer instances.
Only the application layer instances can access the database layer instances.
User pain points and solutions
Now we’ll take you through a few network security scenarios you might encounter and how security groups can address those issues.
Security from the start
Pain point: Customers want to secure their virtual server as soon as it is provisioned. They want complete control over the traffic passing through the server from the point when it was provisioned.
Solution: Use security groups at the time of ordering the virtual server. It is protected right from the time it is provisioned for the customer.
Cost-efficient instance level firewall
Pain point: Customers want to have granular control over traffic at an instance level (apart from network-level firewalling), but at the same time, the costs of a shared hardware firewall (which is IBM’s other instance level multi-tenant firewall offering) can add up quickly if the customer desired to protect multiple servers in different data centers.
Solution: There is no extra charge for using security groups feature. Use security groups for all virtual servers that need protection in any of our global data centers.
Globally scalable and easily manageable firewall
Pain point: Customers want to avoid configuring firewall rules on each server separately. Instead, they want an easily manageable firewall solution which spans servers in different global data centers.
Solution: Define N security groups for N different types of servers in your cloud workload. Manage all rules for a security group in one place. Manage the security group associations appropriately with the virtual servers.
Guidelines for security groups
Security groups cannot be assigned to bare metal servers. All users within an account can read, attach, and detach security groups on the virtual server instances to which they have access, but only users with the “Manage Security Groups” privilege in Network Permissions can create, update, and delete security groups.
If virtual server instances cannot communicate with one another, adding them to a security group does not change that behavior. Gateways must allow the traffic that is defined by the selected security groups.
Customers are encouraged to use security groups with other firewalls offerings (e.g., dedicated hardware firewalls, FortiGate Security Appliances, etc.) to add multiple security safeguards at different levels (instance level, network level)
Some performance limitations exist for security groups and their associated rules.
Learn more about our APIs
For more information about our API, virtual server, and security group APIs, see the following resources:
You can also use the SoftLayer API Python Client to interact with security groups:
Python examples for softlayer_network_securitygroup
Security groups will be available in these data centers at launch:
Our plan is to roll out security groups in all of our global data centers. We continue to work on rolling out security groups in the data centers not currently listed above.