AWS Setup: Secure Identity Foundation with Terraform When it comes to access management in AWS, often I see a basic setup, with Users in IAM, as described here. Clearly, most people focus on building actual running applications, at first. After the first running POCs, the next migrations are on the road map; your architecture evolves, but the initial IAM setup stays. So it’s better to have a super secure set-up right from the beginning.
Articles tagged with "level-300"
Update October 2020 AWS has finally added a feature to solve our problem, now all that’s missing is CloudFormation support :-) Amazon S3 Object Ownership is available to enable bucket owners to automatically assume ownership of objects uploaded to their buckets In the process of building a data lake in a multi-account environment, we encountered a problem that didn’t fit into our existing mental model of how S3 and S3 cross account permissions work.
CloudFormation does not cover all AWS Resource types. Terraform does a better job in covering resource types just in time. So if you want to use a resource type which CloudFormation does not support yet, but you want to use CloudFormation, you have to build a Custom Resource with an own Lambda Function. CDK to the rescue: use AwsCustomResource.
According to the Well-Architected Framework and the least privileges principle, you should change your access keys and login password regularly. Therefore the user should have the right to edit their credentials. But only their own. Also using MFA - multi-factor authentication enhances the security even more. Therefore the user should be able to change MFA. But only their own. But how to do that? You have to combine two parts of AWS documentation. We will show you how you provide a “self-editing” group for your users with the CDK.