Right now, we employ a "keys to the kingdom" approach to access control to our EC2 instances. if you have the oldevops SSH key on your filesystem, you can get in. Otherwise, you can't.
This isn't great, because developers ask us regularly for shell access to EC2 instances for django/edx management purposes, and also because with our current system, even devops must jump through hoops (manually adding ssh to the security group for a given instances) to access a given machine.
With SSM, we use IAM to provide appropriately scoped remote access to EC2 resources without requiring any SSH keys or connectivity.
Description/Context
Right now, we employ a "keys to the kingdom" approach to access control to our EC2 instances. if you have the oldevops SSH key on your filesystem, you can get in. Otherwise, you can't.
This isn't great, because developers ask us regularly for shell access to EC2 instances for django/edx management purposes, and also because with our current system, even devops must jump through hoops (manually adding ssh to the security group for a given instances) to access a given machine.
With SSM, we use IAM to provide appropriately scoped remote access to EC2 resources without requiring any SSH keys or connectivity.
Note that https://github.com/mitodl/ol-infrastructure/issues/1243 should be considered a companion task to this as having per person IAM rules is a part of this effort as well.
Plan/Design