I would also suggest taking a look at the various articles around AWS IAM privilege escalation:
https://know.bishopfox.com/research/privilege-escalation-in-... (just shared on HN recently)
Ultimately I think it just shows that securing cloud infrastructure is difficult to do consistently when you move quickly and broadly at scale. It also shows that the specific mechanism for authenticating EC2 instances had some design issues. These have been known about for a long time of course and it is kind of disappointing how long it took AWS to do something about it.
terraform plan && terraform apply
Really should, I've always thought AWS was just a bunch of hacked together services and it kinda shows. This is why you don't let the engineers talk to the customers... er design for the customers.
(Disclaimer: I am the author)
Not one step exactly, but it is by far the easiest way to write least privilege IAM policies. Otherwise, it becomes impossible to ensure IAM policies are written securely and at scale. This way, all custom IAM policies are written with the exact same methodology.
`aws s3api create-bucket --bucket somecoolname --region us-west-2 --grant-write iamuser`
I don’t know why all the hate for IAM permissions here.
They are complicated but also extremely powerful if setup correctly.
We manage all of our IAM policies and groups with terraform and it’s incredibly easy to understand imho
It’s a ton easier for on boarding and giving contractors temporary access to resources.
*former worker at 3rd party merchant
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.
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.
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.