In September of 2018, Amazon Web Services (AWS) announced the addition of the Session Manager to the AWS Systems Manager. The session manager enables shell or remote desktop level access to your AWS EC2 Windows and Linux instances, along with other benefits. This is a great new feature, but care should be taken when enabling this capability.
While the goal for many is immutable infrastructure deployed as code, there are often cases where monolithic legacy systems must still be manually tended to. Additionally, in many situations, debugging problems on a live machine is simply the easiest path forward.
This brings up the question of how to securely give access to your cloud computing instances. Some users may choose to accept enhanced risk by opening virtual firewalls to allow internet connectivity to cloud assets. Others will accept the higher management overhead of using a bastion host with tighter controls.
Now Session Manager gives a new option for shell access where a local console access is granted within your web browser when logged into the AWS management console. This can both drastically reduce your time to troubleshoot problems as well as increase security since the only point of access is the credentialed AWS console, which should be protected by multi-factor authentication. This single point for console access is managed by the centralized identity and access management (IAM) capabilities of AWS, including logging and auditing of sessions, all without needing to open network ports.
In other words, using the new session manager is kind of a no-brainer. But just what are you agreeing to when you enable it? The following is a real-world example of a permission mix-up that commonly occurs in the wild.
*** This is a Security Bloggers Network syndicated blog from The State of Security authored by Ben Layer. Read the original post at: https://www.tripwire.com/state-of-security/security-data-protection/cloud/aws-system-manager-default-permissions/