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.
Articles tagged with "IAM"
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.
During one of our recent AWS Security Reviews, I ran across an interesting technique that attackers can use to create a backdoor in AWS accounts. It works by using three S3 IAM actions, CloudFormation, and an administrator who is not careful enough. This vector is not new but still scary - and today, I will show you how to check your account for this risk and any previous compromises.
During some R&D for a new blog post, I experimented with IAM conditions in Trust Policies. Some small mistakes during this led to instances that have limited privileges according to the AWS Web Console and CLI. But in reality, they can work with administrative permissions for a few hours - unnoticed. Have I piqued your interest? Let’s see how to reproduce this effect then.
IAM Roles are a critical security feature in AWS. Handling them is not very intuitive in the beginning. In this blog post we take a look behind the curtain and explain what’s going on when you assume a role.
Keeping accounts decoupled is important in cross account scenarios. Setting permissions in the wrong way can lead to unwanted behavior. Better avoid setting a principal in a resource policy to a specific ARN as it may lead to ‘Invalid Principal’-errors. Using conditions provides you a more reliable and least privileged architecture.
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.
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.