Compute Infrastructure

Regulate access to your network resources with IBM Cloud security groups

Share this post:

What are security groups?

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:

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.

More Compute Infrastructure stories

How to Run SAP Workloads in the Cloud on a Budget

We’ve completed SAP HANA certification for our latest generation of Intel Broadwell-based SAP HANA servers, and they’re now generally available worldwide. Learn about how you can migrate your SAP workloads to the cloud—all at a low cost.

Continue reading

Aerospike on IBM Cloud bare metal servers: Powering your cognitive architectures

Fast and flexible, we hear this constantly when talking about cloud infrastructure, but it’s not to be taken lightly. A fast and flexible solution could make or break your workload and overall cloud performance. This means you need to choose a cloud solution that provides fast and flexible infrastructure, all while meeting the constant demands of […]

Continue reading

Obtain and visualise uniform metrics, logs, traces across microservices using Istio

In this blog post, you will learn how to setup Istio on your Kubernetes cluster using Helm or Kubernetes-YAML and you will be using add-ons like Jaeger, Prometheus, Grafana, & Weavescope to collect, query and visualize metrics, logs & traces (in-depth telemetry) for your microservices.

Continue reading