By Appunni M, DevOps & Product Engineer
Building applications in the cloud is the new fad among the geeks of the 21st century. All those new DevOps Engineers and Full Stack Developers out there bringing their creativity to life. It’s like dreaming in the cloud, but it’s not always a pleasant experience if you do not look out for those grave dangers of the cloud. You could fall and cause serious damage. Keep those points in mind to avoid pitfalls while developing your dream product.
Security is a relative term, you can never be completely secure. Keeping that aside, it’s foolishness to assume that there is nothing you can do. It’s always better to be cautious than regret it later. Security is such an aspect in every tech company, you are only as secure as your weakest links. Having said that this post, in a nutshell, talks about how to keep your weakest links strong. Most hacking happens through networks, especially in the cloud. So it’s important to put these basic security measures on your network. We are currently using AWS so I will explain it in terms of AWS features but I am sure you may find similar features in most IaaS providers.
Private is always better than public
Organizations from within are secure for confidential communication to an extent. The trust factor is higher compared to the outside world. This is not only applicable to humans but also machines. In AWS it’s called a Virtual Private Cloud or VPC. This is your private cloud at an organizational level. It makes sure that no one else can listen to your network calls.
It also ensures that you can make more restrictions inside your organization. But it’s always a headache to manage your internal resources especially in case you have more than 10 EC2 instances running simultaneously. This is where Route53 helps, it assists you to manage your Internal DNS very easily. Make sure to check out the documentation on Private hosted Zones in AWS.
Security Groups are the new gatekeepers
While keeping things private is a good start, it’s always good to have some backup restrictions in place. Do not sit back thinking that you are now untouchable, like I said, your security is only good as your curiosity to make it better. Depending upon the IP address or DNS, creating restrictions on EC2 inbound connections is a very outdated method. It’s time to start using Security Groups, as you can handle multiple EC2 instances doing similar jobs under that. Also, it makes it easier to remove the instances and add new ones and not having to configure it over and over again. Security Groups are these reusable components of AWS which make it a powerful service. Want to explore Security Groups in depth? Go here.
Secure Socket Shell (SSH) is not so secure
As you’re the weakest link, I would definitely go against trusting yourself. You have the private key that’s trying to login into the remote EC2 server. There are many cases where people get hacked because of Private Keys getting leaked due to poor management or overuse of the same key everywhere. It’s very difficult for a System Manager to handle multiple servers, having to change SSH keys from time to time, that’s just a headache. A better solution would be to prevent public access to your SSH port in your EC2 instances. Look for a VPN service, or if you have enough resources run an openvpn server yourself. Whip up a VPN server in seconds using this simple script.
Red(is) the flag
Do you have a redis server running somewhere? Is it running and open over public internet? Then you are doomed as this is a perfect invitation for hackers. Manipulating Redis can cause a lot of damage to the owner of the resources. For example, they could be running a cryptocurrency miner in your extra large 16x instance, which can end up giving you nightmares for days. Well, to defeat such attempts at the early stage, you need to be cautious. Make sure your config is binding only to your private IP address. Your private IP address is the private IP address of the instance in which you are running Redis. The better solution would be to use docker and create a network to your instance exposing the port.
On top of all this, you can definitely make Redis secure with authentication. Most of the Redis use cases were meant to be inside sandboxed environments, which explains the poor security by default.
IAM the best
On the topic of security, I would like to shed some light on how growing companies manage their access control for different users. As I always say, you are the weakest link, multiplied by the number of people having access. In a startup, where only a single person is handling everything, its very easy to manage access. But beware, AWS account access means you have complete access. It’s always good to be explicit rather than implicit regarding access right? Define the boundaries of access for different employees within your organization using IAM users. IAM users provide the ability to divide access into different groups. Groups like Lead Developer, Lead Devops, Jr DevOps and Data Scientists and many more. Every employee has a particular set of access only on resources which they require. To top it off, it’s always better to use IAM roles in order to give access for EC2 servers to run on your behalf.
For a much deeper discussion, I would suggest that you explore AWS OpsWorks for managing access to EC2 instances separately. Opsworks helps create users in EC2 instances on the same username as IAM accounts and helps you manage authorization in servers through separate SSH keys. AWS has all the documentation you will ever need to show you exactly how to implement this.
MySQL user access control
Are you a SQL administrator? Then you might have run a bunch of commands like this:
mysql>grant all privileges on db.* to ‘user’@test.spoonshot.com’%’ identified by ‘weak password’;
If you do then you are in deep water. This is a mistake all rookie admins make. Always sticking to the easiest method. Just like Redis binding to 0.0.0.0, using ‘%’ as host will cause MySQL to accept connections from remote locations. This is a huge red flag. Your persistent storage should always be under heavy protection from the outside world. Only whitelisted hosts should be able to communicate with it. What you can do is use your Private VPC DNS to identify hosts and have a separate user for each application with passwords generated securely. Along with this, make sure you don’t actually delegate administrator access to all users.
mysql>grant select,update,insert privileges on db.* to ‘user’@test.spoonshot.com’private_dns_host’ identified by ‘random strong password’;
It should be highly restricted. This will help you in case one user ever gets compromised. You will still be much more secure than you otherwise would be.
There will be one moment in your life as a DevOps Engineer where you think you’re secure and boom, you get hacked. Getting hacked is always a learning point, but those who hack themselves before others are the true DevOps Engineers. The ultimate creation of DevOps is the “Master Work”, and it consists of two parts. One, a button made from HTML, the other, processes that consist of magic. When you click the button, all processes do their jobs securely, efficiently and without the need for intervention.
Before you go, tell us how insightful was this article
Leave a Reply