At one of my jobs, if you ran the sudo command that would immediately sound alarm bells if you were not a sysadmin. I am having a hard time parsing what is best practice vs. what Ryan is doing for our benefit in the course videos. Is it best practice to leave port 22 open to the world and is it necessary to use sudo to make pre-signed URLs happen in AWS?
One of the first sentences of the lecture is: "You’d normally do this using one of the SDKs …".
Nothing about what Ryan does in this lecture is how anyone would actually do it in the real world – to my mind it’s demonstrative.
As a SysAdmin I wouldn’t follow many of these practices in a production environment and no you don’t necessarily need su access. Most servers should never have anything open to the world or even live outside private subnets. That being said, if you look it objectively there are 3 key issues here: 22 open to the world, su privilege and s3 admin access from the instance. Simplest way to quantify the risk is to ask what if? What if someone got the IP and tried to SSH in? They couldn’t easily break in because they wouldn’t have the keys. What if Ryan broke something ie the instance because of su privilege? He’d blow away the instance and spin up another, from the snapshot he would have created prior to making a change in prod. Newer/junior staff would be locked down with RBAC. This leaves s3 admin access from the instance, which I’d be more concerned about mainly because if another person made a mistake from the instance, the damage wouldn’t be contained to the object or bucket. Not a massive one if you trust your staff but still I’d lock down the policy. Security has to maintain C+I and not just restrict, but allow, A. This means balancing access between devs who constantly want to spin up instances with public IPs and 0.0.0.0/0:0 access because hey it’s only staging, and security specialists who dream about locking all servers in safes and dropping them at the bottom of the ocean so no one can access them, ever. When in doubt, start with the consequences and work backwards 🙂
The basic concept which lacks here is Security. For other associate courses its still ok to prefer convenience. But for a security course we should only consider best practices.