When you work with any of the big public cloud providers, one thing is for sure – there will be many changes and improvements to the services that they provide to you. Some changes may perhaps change the way you would architect and design a solution entirely, while others may bring smaller, but still useful improvements.
This post is a story of one of these smaller improvements. It is pretty technical, the gist of it is that with a mindset of continuous improvement, we can find nuggets to make life easier and better and it does not have to be completely new architectures and solutions.
A cloud journey
In 2012, before TIQQE existed, and when some of us at TIQQE started our journey in the public cloud, we created virtual machines in AWS to run the different solutions we built. It was a similar set-up to what we had used in on-premises data centres, and we used the EC2 service in AWS.
Using VPC (Virtual Private Cloud) we could set up different solutions isolated from each other. A regularly used pattern used back then was a single account per customer solution, with separate VPCs for test and production environments. These included both private and public (DMZ) subnets.
To login to a server (required in most cases, not so much immutable infrastructure back then) you needed credentials for the VPN server solution, with appropriate permissions set up. To log in to an actual server, you also needed a private SSH key. One such SSH key is the one which you select or create when you create the virtual machine, for the ec2-user user.
While this worked, it did provide some challenges in terms of security and management – which persons or roles should be able to connect to the VPNs, which VPCS should they be able to access? Of those users and roles, who should be able to SSH into a server and which servers?
There was a centrally managed secrets store solution for the SSH keys for the ec2-user user and different keys for different environments and purposes, but this was a challenge to maintain.
Serverless and Systems Manager
The serverless trend which kind of started with AWS Lambda removed some of these headaches since there were no server access or logins to consider – at least not where solution components can be AWS Lambda implementations. That was great – and still is!
Going serverless can provide other challenges, and it is not the answer to all problems either. There is a lot to say about benefits with serverless solutions. However, this story is focusing on when you still need to use servers.
AWS has another service, called Systems Manager, which is essentially a collection of tools and services to manage a fleet of servers. That service has steadily improved over the years, and a few years back it introduced a new feature called Session Manager. This feature allows a user to login to a server via the AWS Console or via the AWS CLI – no SSH keys necessary to be maintained and no ports to configure for SSH access. This feature also removes the need for a VPN solution for people who need direct access to the server for some reason.
Access control uses AWS Identity and access management (IAM) – no separate credential solution.
Some other major cloud providers already had similar features, so in this regard, AWS was doing some catch-up. It is good that they did!
A new solution to an old problem
For a solution that requires servers, there is a new access pattern to use. No VPN, no bastion hosts. Those that should have direct access to a server and login to that server can now login directly via the AWS Console in a browser tab. No VPN connections, no SSH keys to manage – only select to connect log in to the server via the browser. That is, assuming you have the IAM permissions to do so!
For those cases that the browser solution is not good enough, it is still possible to perform an SSH login from a local machine. In this case, it is possible with the help of the AWS CLI to make a connection to a server using Systems Manager Session Manager. The user can have their SSH key, which can be authorized temporarily for accessing a specific server.
Since it is then possible to use regular SSH software locally, it is then also possible to do port forwarding for example, so that the user can access some other resource (e.g. a database) that is only accessible via that server. AWS Systems Manager also allows for an audit trail of the access activities.
Overall, I believe this approach is useful and helpful for situations where we need direct server access. The key here is though, with a mindset of continuous improvement – we can pick up ways to do better, both big and small.
