This blog provides an overview and a simple example use case for Security Groups, which are an effective and versatile way to provide access protection for your virtual servers in the IBM Cloud.
In my last blog post, I talked about there being a shared responsibility for security in the cloud. To paraphrase, the cloud provider has a responsibility to ensure that the cloud platform itself meets certifiable industry standards for security, while the consumer of cloud services has a responsibility to secure their apps. Fortunately, IBM Cloud provides a range of services to help users secure their apps and provisioned infrastructure. One such means is through the use of Security Groups.
You can think of a Security Group as a set of one or more access rules which are in turn applied to one or more virtual machines. The aim of a Security Group is to block or allow access to server ports via particular protocols. In essence, they work like a firewall but there is nothing to provision and IBM Cloud does not charge for their use.
Security Groups are ‘permissive’. This means that they will block access by default but grant permission as per the rules they contain. They are not applied in any particular order – if a virtual machine has a two Security Groups applied, one which allows HTTP access and one which blocks it, then HTTP access will be allowed.
Security Group Examples
The most basic Security Group is one with no rules at all. The effect of applying this to a virtual machine would be to block all access via all protocols on all ports. The second most basic would be a Security Group with two rules – one to give full access via IPv4 and another to give full access via IPv6. Similarly, if you applied a Security Group to a server that just contained rules to allow HTTP over port 80, all access to the server would be blocked except of course, HTTP over port 80. Straight away, you might see that this is a good Security Group for a web server!
IBM Cloud Infrastructure provides 5 pre-defined Security Groups. These are:
- Allow_all – allow all incoming (ingress) traffic
- Allow_http – allow all ingress TCP traffic on port 80
- Allow_https – allow all ingress TCP traffic on port 443
- Allow_outbound – allow all outbound (egress) traffic
- Allow_ssh – allow all ingress TCP traffic on port 22
A Simple Use Case
It’s simple to edit these pre-defined groups as well as to create your own. For example, you might decide to deploy a management server in your environment. Here, admins must first log into this server to be able to get ssh access to other servers in the IBM Cloud environment.
A ‘Management_SG’ Security Group can be created that allows ssh connections from a defined IP address or address range range on port 22. This Management Group can be applied to the management server. A second Security Group, say ‘DevServer_SG’ can then be created which allows ssh access on port 22 where the source of access is a server that has the Management Security Group assigned. This second security group is then applied to all other servers in the environment. The diagram below shows this simple configuration:
The net result of applying these Security Groups is that the only means of gaining access to a virtual server belonging t the DevServer_SG group via ssh, is to ‘hop’ from a virtual server in the Management_SG group. Similarly, the only way to gain ssh access to one of those is to access it from a client that has an IP address in the authorized address range. Note that other virtual machines in the environment that are not in the Management_SG group also cannot gain ssh access.
This is, of course, a simple example of how Security Groups can be used. In reality, it’s down to your environment as to how simple or complex the Security Groups need to be. Currently, an account can have up to 500 Security Groups defined and each can contain up to 50 rules. A Security Group can be applied to up to 100 network interfaces and a single network interface can have up to 5 Security Groups applied to it. The scope for protecting your virtual server infrastructure with Security Groups is therefore quite wide.
For more information about Security Groups and how they can help secure your virtual machine environment, why not check out Getting Started with Security Groups on the IBM Cloud.