terraform plan && terraform apply
https://aws.amazon.com/blogs/security/defense-in-depth-open-...
I would also suggest taking a look at the various articles around AWS IAM privilege escalation:
https://rhinosecuritylabs.com/aws/aws-privilege-escalation-m...
https://know.bishopfox.com/research/privilege-escalation-in-... (just shared on HN recently)
If Facebook, Google and Amazon are technology companies banks definitely are.
Only if the banks actually write the software. A credit union that pays someone else for an online banking solution is as much of a tech company as the motel that pays for an online reservation system. At that point the term is useless.
I'm kind of surprised AWS doesn't just enable VPC endpoints for all services by default. Having to leave the network to talk to services seems like overkill for most things.
It’s also worth noting that whilst I’m a HUGE believer in VPC endpoints, it comes with a cost. Which then makes it a security vs cost trade off. As you’ll still pay bandwidth charges on the network interfaces (ENIs) for the VPCEs, along with the hourly price for said ENIs.
If Amazon changed this, I’d happily change all my networking to use VPCEs for all AWS services (where applicable). Unfortunately it seems they’re not going to do this, despite continuously adding new services to the list of VPCE-enabled services.
- flAWS (flaws.cloud / flaws2.cloud) by Scott Piper
- CloudGoat (https://rhinosecuritylabs.com/aws/cloudgoat-vulnerable-desig...) by Rhino Security Labs
Possibly more intriguing: I'll bet Capital One deals with more compliance initiatives than 99% of the public sector. Another Heartland Payment Systems example? Did leadership have a false sense of safety after passing an audit?
That said, it's almost impossible to implement least privilege with EC2 instance roles unless you manage application identity in a separate control plane. Otherwise you have a single role that must satisfy the union of all access requirements for infrastructure automation, software deployment, logging, monitoring and discrete application runtime components. It's a mess and IMHO a terrible architecture.
The fact that the STS creds for that role are then made available via unauthenticated network service which then are by default active from any endpoint on the planet unless explicitly locked down is insanity. Furthermore, locking said roles down requires discrete references to VPC endpoints and CIDR ranges that are unique to individual regions and have to be able to breathe with the environment. This makes your IAM lockdown policies gnarly and volatile, not a good recipe for availability.
It's no mean feat to really prevent this kind of thing in a fast-moving environment. Defense in depth is essential.
I don't know why this isn't 'enabled by default' for IAM roles associated with EC2 instances.
[0]: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_p...
To me, IAM is one of the most difficult AWS services to design securely. Every service has 20-50 sub-permissions (so developers simply default to using wildcards instead of carefully tuning each policy), there are 4+ different systems that combine to create each policy (a trust relationship, the permission body, optional conditions, plus managed policies and group policies), IAM roles can now have permission "boundaries" that further complicate their access rights, roles can be assumed by services (EC2, Lambda, etc.) and yet the credentials obtained as part of that role assumption can be used outside of those services (as demonstrated in the Capital One incident), and some services (e.g. S3, ECR) have additional permission policies at the resource level that interact with IAM policies in a two-way trust of sorts.
The entire thing is woefully complicated and it shows when AWS is in the news nearly every week because someone misconfigured yet another service.
