4 ms·
IAM policies can be so complex, that become close to unusable. Use multiple AWS accounts, and keep your policies simple. One account for DB, one for the backen
by cyberax 2y ago
IAM policies can be so complex, that become close to unusable.
Use multiple AWS accounts, and keep your policies simple. One account for DB, one for the backend servers, etc. Each environment (prod, staging, dev) also gets its own set of accounts.
This way, a misconfigured policy won't give admin access to everything.
- potamic 2y agoWouldn't that lead to cross account policies, which appear to be even more quirky?
- devonkim 2y agoYeah, error messages start to become more opaque as well which makes debugging even tougher, which is kind of the opposite of the point of using multiple accounts. But really, AWS not having proper namespaces in its constructs that’s ubiquitously supported (IAM paths were attempted. Attempted) hampers a lot of things
- cyberax 2y agoIn my practice? Not really. For resources like databases, you don't need cross-account access if you're using internal DB authentication systems. For IAM-based DB authentication, you can simply write policies to trust the target accounts. Occasionally, you'll need to create a cross-account trust (via AssumeRole), but it's not at all that frequent. My personal wish is for AWS to allow account _names_ instead of ID numbers in policies.
- laurent_du 2y agoI honestly can't imagine a situation where this would be a good advice. Can you give an example of such an IAM policy?
- cyberax 2y agoFor example, if you want your CI/CD to deploy to CloudFormation and allow it to generate IAM resources, then it's essentially root-level access. Because you can simply create an IAM role that gives admin permissions to you. Or even without that, there are plenty of footguns. AWS has a good blog post: https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/ https://aws.amazon.com/blogs/security/protect-sensitive-data...
- Hikikomori 2y agoOne account per system and environment with shared vpcs is great.
- shakiXBT 2y agoHaving one account per database/backend/frontend is not only overkill, but actually a bad practice. You're going to have to expose your DB to the internet instead of having everything inside a single VPC. What you should do instead is have one account per environment (as you said).
- kroolik 2y agoYou can peer-connect vpcs cross-account
- dilyevsky 2y agoUp to 125 peers before you have to setup a transit vpc which is a lot more complex
- Hikikomori 2y agoTransit gateway can have 5000 VPCs connected in a region, and you have multiple TGWs. And rather than have a VPC per account you can use Shared VPCs instead.
- tenplusfive 2y agoI've recently stumbled upon the possibility to share a VPC and use one VPC with multiple accounts: https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/amazon-vpc-sharing.html https://docs.aws.amazon.com/whitepapers/latest/building-scal... I'm honestly not sure if thats a great idea, but this might be a possible way to do one account per DB/backend/frontend in a somewhat sane way.
- LilBytes 2y agoIt's fine, but you're going to attract a lot of network costs bridging data between AWS accounts. Generally I'd stick to accounts per environment, you'll be worrying about a lot more when you get to FAANG scale.