The project steampipe uses a fast programing language and an intelligent caching approach outrunning prowler speed tenfold. While I tried to workaround prowlers limits I learned a lot about optimizing.
We can use permissions boundaries to give developers and teams more freedom to create their own resources. For forcing them to provide specific tags during resource creation, we need a deeper understanding of how this can be achieved. We talk about the example of creating a security group.
There is a conflict between developer freedom and the requirements of security teams. In this post we’ll look at one approach to address this tension: permission boundaries. They’re an often overlooked part of IAM, but provide a valuable addition to our security toolkit.
Encrypting objects at rest is a best practice when working with S3. Enforcing this with policies is not as trivial as you may think. There are subtle issues with default encryption, which may result in compliance risks. We’re going to investigate these issues and show you how to solve them.
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.
