Forem: Karol Havrillay

How Helpful and Secure can AI be? A Little Comparison of ChatGPT and Amazon Q Developer

Karol Havrillay — Mon, 31 Mar 2025 20:16:18 +0000

Every now and then there are these small tasks that end up on my table that are too tedious to write from scratch but there is too much overhead to delegate. So naturally I ask AI for help and hope to get it done in a manner of minutes instead of manually writing the required code. Since I mostly do infra stuff, the code in this case is Terraform.

The task is quite simple:

Create terraform code with an IAM user with permissions to upload to an S3 bucket. Create an S3 bucket using KMS encryption and the corresponding KMS Key.

ChatGPT Response and Analysis

Since its launch some time ago, ChatGPT earned its place on the bookmark bar in my browser. Just thanks to muscle memory it tends to be the tool of choice for similar tasks. And mostly it also does the job right, however this time I was a bit disappointed.

provider "aws" {
  region = "us-east-1"  # Specify the AWS region of your choice
}

# Create an S3 bucket with KMS encryption
resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-bucket-with-kms-encryption"  # Change to your desired bucket name

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm     = "aws:kms"
        kms_master_key_id = aws_kms_key.s3_bucket_key.arn
      }
    }
  }
}

# Create the KMS key for S3 bucket encryption
resource "aws_kms_key" "s3_bucket_key" {
  description             = "KMS key for S3 bucket encryption"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow S3 to use the key",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:aws:s3:arn": "${aws_s3_bucket.example_bucket.arn}"
        }
      }
    }
  ]
}
EOF
}

# Create an IAM user without console or programmatic access
resource "aws_iam_user" "upload_user" {
  name = "s3-upload-user"
}

# Attach a policy to allow the IAM user to upload to the S3 bucket
resource "aws_iam_policy" "s3_upload_policy" {
  name        = "S3UploadPolicy"
  description = "Policy for uploading objects to the S3 bucket"

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Action = [
          "s3:PutObject",
          "s3:PutObjectAcl"
        ],
        Resource = "${aws_s3_bucket.example_bucket.arn}/*"
      }
    ]
  })
}

# Attach the policy to the IAM user
resource "aws_iam_user_policy_attachment" "upload_policy_attachment" {
  user       = aws_iam_user.upload_user.name
  policy_arn = aws_iam_policy.s3_upload_policy.arn
}

Let's dissect this step by step.

Deprecated Code

The aws_s3_bucket_server_side_encryption_configuration argument in the s3 bucket resource definition is deprecated and should be replaced by a separate resource.. Doesn't break anything, perhaps the model in the backend is outdated, but nothing major.

Potential Ransomware Attack

Here comes the interesting part. The actual KMS key policy and its statements.

    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "kms:*",
      "Resource": "*"
    }

Thank you ChatGPT, you've just enabled any principal in any AWS account to do anything with my KMS key, including updating its key policy. That could lead to a potential ransomware attack where the attacker could make the key defunct and allow only himself to fix the key policy and thus release your data. AWS Support might be of help here too, but not everyone is aware of this option.

Wrong and Unnecessary Statement in the Key Policy

    {
      "Sid": "Allow S3 to use the key",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:aws:s3:arn": "${aws_s3_bucket.example_bucket.arn}"
        }
      }

This is not wrong per se, it just doesn't work like this. What ChatGPT wanted to achieve is to allow the key to be used only within a certain encryption context, meaning the KMS key can only be used for the given S3 bucket. This wasn't requested in the prompt. Furthermore, the S3 service itself doesn't really need the given permissions, the principal (e.g. an IAM user) does. Perhaps what ChatGPT wanted to do was to use the kms:ViaService condition to allow usage of the key only when when S3 in involved.

Insufficient Permissions

      {
        Effect = "Allow",
        Action = [
          "s3:PutObject",
          "s3:PutObjectAcl"
        ],
        Resource = "${aws_s3_bucket.example_bucket.arn}/*"
      }

Lastly, the permissions given to the user are not sufficient to successfully upload files to the S3 bucket because there are no explicit Allows in the user's IAM policy or in the KMS key policy.

Result

Result? Not only the code doesn't do what it's supposed to, it also opens the door into my AWS account and possibly exposes my data to attackers. There are some safety measures to alert you about this even if such code gets deployed, such as AWS IAM Access Analyzer, provided it's configured correctly and the alerting works.

Amazon Q Developer Response and Analysis

The installation of Amazon Q Developer into your IDE is ridiculously quick and easy and requires just a Builder ID. Installing the Amazon Q Developer VS Code Extension and logging in with the Builder ID took less than 5 minutes. Upon clicking on the Q logo in VS Code a chat window opens and lets you input your prompts.

Now let's check the code provided by the Amazon Q Developer.
Compared to ChatGPT, Q spat out a clean code with no deprecated parameters and included a few interesting pieces where it's obvious that it follows the AWS best practices also in terms of security.

To improve readability I'm not including the code provided by the Q Developer, just the interesting bits.

Versioning Enabled

Versioning is enabled on the S3 bucket allowing you to restore accidentally deleted or overwritten data.

resource "aws_s3_bucket_versioning" "bucket_versioning" {
  bucket = aws_s3_bucket.encrypted_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

Public Access Blocked Preemptively

Public access is explicitly blocked on the bucket preventing you from accidentally exposing your data.

resource "aws_s3_bucket_public_access_block" "bucket_public_access_block" {
  bucket = aws_s3_bucket.encrypted_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Working KMS and IAM Policies

Using a default KMS key policy allows usage of the key only within the AWS account:

      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      }

The IAM permissions for the user allow him to encrypt uploaded data with the KMS key.

      {
        Sid    = "AllowKMSAccess"
        Effect = "Allow"
        Action = [
          "kms:Decrypt",
          "kms:GenerateDataKey"
        ]
        Resource = [
          aws_kms_key.s3_key.arn
        ]
      }

Result

I'm quite happy with the results and especially with the nice to have features and quirks such as public access block which is not really necessary at this stage but is a good safeguard measure if the bucket policy gets updated later.

Conclusion

Humans are creatures of habit. Sometimes it's a good idea to reevaluate your habits and try something new especially in the fast-paced industry that IT is. Amazon Q Developer convinced me of it. An even more important message: make sure you understand every single line of code before deploying.

How (not) to Expose Your Password in Plain Text When Using AWS Transfer Family SFTP

Karol Havrillay — Sun, 16 Mar 2025 22:49:30 +0000

Recently I was approached by one of my customers who wanted a storage service in AWS and wanted to use their existing corporate Entra ID credentials for authentication.

Looking at the possible options to achieve this and available guidance from AWS, the option with the custom Lambda IDP seemed to be a quick and easy way forward.

(Please note it is now possible to use Entra ID Domain Services for such use case but requires more effort to setup and doesn't illustrate the purpose of this article.)

Solution at a Glance

So how does a Lambda function as a custom IDP work in a high level? As depicted in the diagram below:

First a user connects to the Transfer Family SFTP server. The server prompts for the user's username and password. The user types in their Entra ID credentials.
The credentials are then passed to the Lambda function that validates the credentials by contacting the Entra ID public API URL and using the supplied credentials to log in.
If the login is successful, the Lambda returns an IAM role and a session policy to the SFTP server which enables the user to interact with the SFTP server (e.g. write files).

So far so good, the workflow works as expected, the Lambda function even logs some part of the payload to CloudWatch for monitoring or debugging purposes.

An example output from logs can look as follows:

Opportunity Makes the Thief

From the functional perspective there is nothing wrong with the setup above, the users are happy and can upload data to the SFTP server and enjoy the benefits of the highly durable S3 storage in the background.

However let's assume that the AWS account where the SFTP server is running is used by multiple users and the Security team didn't spend too much time with IAM management, let alone enforce the principle of least privilege. So such a user with over-permissive privileges might go unnoticed for quite some time.

Let's say this user is a developer or a DevOps engineer so he/she has some pretty common permissions, e.g.:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DevAccess",
            "Effect": "Allow",
            "Action": [
                "lambda:*",
                "dynamodb:*",
                "sqs:*",
                "sns:*"
                ],
            "Resource": "*"
        }
    ]
}

And furthermore, the user has the ReadOnlyAccess AWS managed job policy attached:

arn:aws:iam::aws:policy/ReadOnlyAccess

What this combination of access the user can browse through the source code of the IDP Lambda function and not only that. The user can also inject malicious code into the Lambda function and thus exfiltrate sensitive data into CloudWatch. It can go from this:

To this:

Upon looking into the corresponding CloudWatch log group, indeed the adversary (or just an overprivileged user) can indeed read passwords in plain text!

Mitigation

So, how to fix this? As stated in the beginning there are now better ways how to integrate the SFTP server with e.g. Entra ID or Entra ID Domain Services.
However, if you end up in a situation where you need to use an IDP Lambda function such as above, following the below best practices should considerably improve the security posture of your environment.

1. Employ a multi-account strategy

Isolate your workloads by deploying them into multiple AWS accounts. A rule of thumb is one account per application/workload per SDLC stage plus other AWS accounts for specific use cases. This limits the blast radius and makes sure the AWS accounts can't "talk" to each other unless you explicitly allow them to do so on either IAM (cross-account IAM roles) or networking (VPC Peering, Transit Gateway) layer. A good way to start with this approach is using AWS Control Tower which sets up the whole landing zone for you and allows you to enforce various controls and guardrails across AWS accounts.

2. Establish a proper IAM management

Ideally manage the identities at one place (e.g. corporate Entra ID / Active Directory) and federate with AWS Identity Center. This allows users to use their corporate credentials to access AWS, you don't need to duplicate your organisational structure in the cloud and allows you to make use of concepts such as ABAC and RBAC.
The above approach provides an additional benefit where you get rid of any static long-lived credentials or forgotten over-privileges IAM users.

3. Enforce least privilege

Use services such as AWS IAM Access Analyzer to help you fine tune the permissions of your IAM entities based on their historical usage patterns. Or find excessive permissions which were not used in a given time frame.

4. Encrypt, encrypt, encrypt

The password exfiltration scenario above wouldn't be successful if the CloudWatch log group was encrypted by a KMS key with a proper KMS policy. This is a quick win and a recommended approach for any use case.

How Can AWS IAM Access Analyzer Help You Improve Security Checks in Your CI/CD Pipeline?

Karol Havrillay — Sun, 31 Mar 2024 17:30:40 +0000

Recently I was working on improving a client's CI/CD Pipeline security and one of the aspects I wanted to explore was how to use AWS native tools to identify over-permissive IAM policies or detect privilege escalation possibilities. In this article I would like to have a look at what the AWS IAM Access Analyzer has to offer with its policy validation feature. Apart from checking policy grammar, it can also raise a security finding if the "policy provides access that AWS considers a security risk because the access is overly permissive". Or can it?

Let's Get the Basics Right

Privilege escalation is the act of exploiting a flaw to gain elevated access to resources that normally shouldn't be accessible to you. In AWS it is done by (enumerating and) abusing permissions assigned to your principal or to the principal the attacker gained access to. The permissions are assigned to principals using IAM policies. In turn, the policies are made of one or more statements, each statement containing a tuple of action, resource, effect and optionally a condition.

How Does Privilege Escalation Work?

In terms of privilege escalation, it boils down to the individual IAM actions in the statement or their combination. At the time of writing the article, AWS provided whopping 16458 individual IAM actions. The most critical area are the IAM actions related to the IAM service itself. Filtering only IAM actions, we still get 171 actions that could be potentially dangerous. Obviously we can't deny all those IAM actions for everyone in our AWS account or AWS Organization e.g. by a Service Control Policy as that would render the AWS pretty unusable. For example you wouldn't be able to assign an EC2 instance an IAM role allowing it to put items in DynamoDB or read data from an S3 bucket or make any other services talk to each other.

So, which actions really pose a threat? A great security researcher Nick Frichette (worth following on social networks) and his project https://hackingthe.cloud identified 37 ways how an IAM policy can be abused to gain more privileges. Some of them are quite surprising, e.g. DetachRolePolicy which sounds counterintuitive, but if the policy being detached contains a Deny statement, then detaching it can in fact allow you to perform more actions which is considered privilege escalation.

Looking at the checks performed by the IAM Access Analyzer, we can see some resemblance with the list at https://hackingthe.cloud, however both lists look at the problem from a slightly different perspective.

Whereas the Hacking The Cloud approach leans more towards auditing and penetration testing by looking for real exploitation possibilities thanks to a combination of permissions for multiple AWS services, the Access Analyzer looks more at prevention and mostly misuse of the iam:PassRole permission. A good explanation of why the iam:PassRole permission can be dangerous is explained in detail for example here.

How Can AWS IAM Access Analyzer Help?

Based on the observations above, the best place for such checks would be a CI/CD pipeline where the Access Analyzer can check IAM policies before they are deployed to AWS and identify possible security issues. Usually, the IAM policies are part of Infrastructure as Code templates such as Cloud Formation or Terraform. That's where the first problem arises. The input for the aws iam accessaanalyzer validate command is NOT a CloudFormation template or a Terraform plan file, but a JSON document containing the policy. It looks something like this:

aws accessanalyzer validate-policy
    --policy-document file://myfile.json
    --policy-type IDENTITY_POLICY

The second problem is that CloudFormation templates and the IAM policies in the templates more often than not contain also intrinsic functions, such Fn::Join or Fn::Sub to join or substitute values which might not be known by simply parsing the template as a JSON or YAML file. This might not be the case though in case of scanning Terraform plan files where the variables are already replaced with the respective values.
So, how to deal with a template looking like this?

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  BobUser:
    Type: AWS::IAM::User
    Properties:
      UserName: Bob

  BobPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: BobEC2Policy
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - "ec2:RunInstances"
              - !Join
                - ""
                - - "iam:"
                  - "PassRole"
            Resource: "*"
      Users:
        - Ref: BobUser

  BobPolicyAttachment:
    Type: AWS::IAM::UserPolicyAttachment
    Properties:
      UserName: !Ref BobUser
      PolicyArn: !Ref BobPolicy

The critical iam:PassRole action is constructed here by joining the two parts of the action together using the Fn::Join intrinsic function.

Luckily, AWS provides a solution called cfn-policy-validator which can parse CloudFormation templates and uses IAM Access Analyzer in the background. (There is also a version of the tool for Terraform). It can be installed by simply running:

pip install cfn-policy-validator

Then the actual check of a CloudFormation template is performed by running

cfn-policy-validator validate --template-path DangerousTemplate.yaml --region eu-central-1

Note: The command requires valid AWS credentials with permissions to run AWS IAM Access Analyzer checks.

Running it against the template above, we get a JSON document as a result correctly identifying the dangerous action iam:PassRole with * as a Resource, meaning the user Bob could pass any IAM role and possibly escalate his privileges.

{
    "BlockingFindings": [
        {
            "findingType": "SECURITY_WARNING",
            "code": "PASS_ROLE_WITH_STAR_IN_RESOURCE",
            "message": "Using the iam:PassRole action with wildcards (*) in the resource can be overly permissive because it allows iam:PassRole permissions on multiple resources. We recommend that you specify resource ARNs or add the iam:PassedToService condition key to your statement.",
            "resourceName": "Bob",
            "policyName": "BobEC2Policy",
            "details": {
                "findingDetails": "Using the iam:PassRole action with wildcards (*) in the resource can be overly permissive because it allows iam:PassRole permissions on multiple resources. We recommend that you specify resource ARNs or add the iam:PassedToService condition key to your statement.",
                "findingType": "SECURITY_WARNING",
                "issueCode": "PASS_ROLE_WITH_STAR_IN_RESOURCE",
                "learnMoreLink": "https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html#access-analyzer-reference-policy-checks-security-warning-pass-role-with-star-in-resource",
                "locations": [
                    {
                        "path": [
                            {
                                "value": "Statement"
                            },
                            {
                                "index": 0
                            },
                            {
                                "value": "Action"
                            },
                            {
                                "index": 1
                            }
                        ],
                        "span": {
                            "start": {
                                "line": 1,
                                "column": 91,
                                "offset": 91
                            },
                            "end": {
                                "line": 1,
                                "column": 105,
                                "offset": 105
                            }
                        }
                    },
                    {
                        "path": [
                            {
                                "value": "Statement"
                            },
                            {
                                "index": 0
                            },
                            {
                                "value": "Resource"
                            }
                        ],
                        "span": {
                            "start": {
                                "line": 1,
                                "column": 120,
                                "offset": 120
                            },
                            "end": {
                                "line": 1,
                                "column": 123,
                                "offset": 123
                            }
                        }
                    }
                ]
            }
        }
    ],
    "NonBlockingFindings": []
}

Checking the return code by running

$?

we get a non-zero code, 2 in this case.

Conclusion

The Validate feature of AWS IAM Access Analyzer is certainly not an almighty tool but I think it has its place in the CI/CD tooling and beside security findings it also provides other warnings and suggestions possibly pointing out an unintentional mistake in IAM policies. Besides IAM policies it also supports resource policies and service control policies.
The checks are free of charge and together with the cfn-policy-validator it is surprisingly easy to integrate into CI/CD pipelines and provides an easy-to-parse output and decision-making. Furthermore, it has further capabilities how to treat findings, so you can treat certain findings or resources as non-blocking. Overall, it seems to be a versatile tool and was worth checking.

How about privilege escalation though? Besides detecting some iam:PassRole related dangerous policies, it doesn't provide much in this area, but then again it's not the main purpose of the service. When it comes to detecting overly permissive statements as stated in the feature description of the feature, the tool does the job just fine.
If you are interested in finding or exploiting the privilege escalation possibilities, there are multiple great write-ups and tools, such as: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/ and their pentesting tool pacu, or https://bishopfox.com/blog/privilege-escalation-in-aws and their tool IAM Vulnerable.

How to Improve Your Security Posture in Just a Few Clicks with AWS IAM Access Analyzer

Karol Havrillay — Thu, 29 Feb 2024 22:48:14 +0000

When talking about security on AWS, the first services that pop up are usually Security Hub, Cloud Trail, Guard Duty and so on. They are all important and have their place in your AWS environment, however there is one service which is often overlooked but it can provide a lot of value in almost no time. Yes, it is the AWS IAM Access Analyzer and its capability that finds AWS resources with external access. The best part is, this feature of AWS IAM Access Analyzer is free of charge!

Basics

What exactly is meant by external access? It means that an entity (including unauthenticated anonymous users) outside of your zone of trust can access your resource, e.g. read files in your S3 bucket or access your EBS volumes snapshots. Under the hood, AWS IAM Access Analyzer uses automated reasoning powered by Zelkova to analyze a policy (e.g. an IAM policy or a bucket policy) and provide a definitive answer whether it allows (unintended) access to the resource from outside of your zone of trust.

The zone of trust can be:

a single AWS Account
the whole AWS Organization if you setup an organizational Analyzer from the management AWS account or from a delegated admin account.

Important to note is that unlike IAM, the Access Analyzer is a regional service so it needs to be enabled in each region you are actively using.

Which Resources Are Supported?

Since the time I wrote my first article on this topic the number of supported resources types has more than doubled. The supported resources include those resources which you can make public by either attaching a resource policy, e.g. Secrets Manager, SQS Queue; create a grant, e.g. KMS key; or make them public explicitly, e.g. RDS Snapshots, EBS volumes snapshots.

How Does It Work?

If you are working in a multi-account setup which should be the case if you run more than one workload in more than one SDLC stage, it is a best practice to use AWS Organizations to govern and manage your AWS accounts. Going further into the best practices, it is a a recommendation to have a separate Security or Audit AWS Account to manage your security services on the organizational scale.
In that case, you need to first log in to your Administrative account and navigate to AWS IAM Access Analyzer in the web UI and select Analyzer Settings under the Access Analyzer section.

Clicking on the Add delegated administrator will allow you to specify the account ID of your Security account which you will use to manage the Access Analyzer.

Next, you need to login to the Security or Audit account which you specified in the previous step as the Delegated administrator account and navigate to the IAM Access Analyzer section and hit the Create analyzer button. It is important to select the right type of Analyzer (external access), give it a meaningful name and define the scope or the zone of trust. Since we are in a multi-account setup we are going for the Organization as the zone of trust.

Voilà, your Access Analyzer is up and running. It will take some time to populate the findings, but you just made your AWS environment much safer with almost zero effort.

Working with the Findings

After observing the findings in an environment using AWS IAM Identity Center (formerly AWS SSO) to manage identities and access, we can see that we have a lot of findings related to the IAM Identity Center roles and the SAML provider which the IAM IC creates in each account. The Access analyzer considers these SAML providers external to the Organization because theoretically you could federate with Identity Providers outside of your Organization or AWS.

So, the easy way to get rid of the findings would be to just select all findings and archive them. However, if you create another AWS account in your enviornment, the IAM IC will again create a SAML provider in it together with multiple AWS roles. So the long term solution is to create archive rules.

Creating Archive Rules

Archive AWS IAM IC findings

By navigating to Analyzer Settings, selecting the Analyzer, and hitting the Create archive rule, we can create Archive rules. They are applied automatically when new findings are created and can help us, if crafted properly, eliminate false positives.

So, to exclude (or auto-archive) the IAM roles related to AWS IAM Identity Center, the rule could look like this:

Make sure the rule matches the active findings and click the Create and archive active findings button.

Archive IAM Roles in Non-primary Regions

If you are actively using multiple regions, you will see findings for IAM roles in each region since IAM roles are global resources. To prevent these duplicates, you should pick a primary region and create an archive rules in all other regions to auto archive all IAM Roles findings, i.e. Resource Type is IAM::Role.

Integration with Other Services

Security Hub

If you are using Security Hub to manage your security posture, you will find AWS IAM Access Analyzer findings there automatically.

Event Bridge

The other option would be an SNS topic or virtually endless possibilities of integration via the Event Bridge.
The corresponding Event rule would look like this:



{
  "source": [
    "aws.access-analyzer"
  ],
  "detail-type": [
    "Access Analyzer Finding"
  ],
  "detail": {
    "status": [
      "ACTIVE"
    ]
  }
}

Currently it is not possible to drill down further in the event rule and to specify only External access type of findings.

Pricing

The external access feature of Access Analyzer that detects resources with external access is free of charge!

Tips and Recommendations

Always create an organizational Analyzer if you run more than one AWS account.
Create or use a delegated admin account for managing the organizational Analyzer to limit the needed operative tasks in the Administrative account. The delegated admin account would be usually your Audit or Security account.
Don't forget that AWS IAM Access Analyzer is a regional service so enable it in all regions which you are not actively blocking (e.g. by an SCP).
Related to the previous point, if you are using more than one region, pick a primary one where you want the Access Analyzer to scan all supported resources. In all other regions exclude the finding related to IAM roles otherwise you would see duplicit findings for the same roles in more regions.
General advice, unless you are just evaluating and testing the service in a sandbox environment, always use Infrastructure as Code to set up and manage your AWS services and resources.

AWS IAM Access Analyzer Demystified

Karol Havrillay — Wed, 13 Apr 2022 22:51:36 +0000

Given how fast AWS release new products and features, it can be quite easy to lose track about what each individual service does or what features it provides. To make the matter even more complicated, AWS also likes to pack a broad range of functionalities under one umbrella.

Once such example is AWS Systems Manager which consists of services with functionalities ranging from storing configuration data for your applications to securely accessing your EC2 instances via a shell session or patching them at scale just to name a few.

Another example is AWS IAM Access Analyzer which provides a set of very interesting security related functionalities which do not exactly serve the same purpose, but they are covered by one service. Let’s have a look at them one by one.

Who Knows My Secrets?

Historically, this was the first functionality of Access Analyzer. It is backed by mathematical proofs, and it analyzes resource policies on subset of your AWS resources to determine whether they are shared outside of the defined boundaries. Btw, I recommend watching a great video on the internals of the service from one of the Re:Invents.

The boundary can be either an AWS account or the whole AWS Organization and the service refers to it as the Zone of trust. In case you define as a boundary the whole AWS Organization, the Access Analyzer needs to be setup in the Management account (previously known as Master) of the Organization or from an account designated by the Management account.

The list of supported resources is not particularly long but it covers some of the most critical ones:

IAM roles which can be assumed from outside of your zone of trust
KMS keys
Lambda functions and layers
SQS queues
Secrets Manager secrets
S3 buckets

So, in case you want to be notified if someone in your AWS account or an Organization opened up a way in through one of these services, this is the feature of AWS IAM Access Analyzer you should definitely enable and configure it accordingly.

Is My Policy Going To Work As Intended?

Another AWS IAM Access Analyzer functionality is policy validation. There is also an API for that, but the functionality seems to be mostly useful in the web console when you are drafting or testing your policies before you deploy them finally via Infrastructure as Code, e.g. CloudFormation, Terraform or others.

In the web console you can see a similar interface as depicted in the picture when working with IAM policies, Service Control Policies and S3 bucket policies.

It comes with 100+ checks and will warn you mostly about syntactical errors in your policy e.g., a missing mandatory element. But it will also raise a warning, a security warning or a suggestion e.g., if you use the condition operators incorrectly, or your policy might end up to be way more permissive that you might have intended, especially with the iam:PassRole action which is commonly used in privilege escalation techniques.

Can I Get Fewer Permissions?

This is the latest feature of AWS IAM Access Analyzer, and its purpose is to generate least privilege policies for an IAM principal (a user or a role) based on its previous activity.

It was introduced approximately one year ago and as it often is the case with AWS, it was more of an MVP with limited functionality. It was quite restricted in terms of number of supported services, on source data (you had to have your Cloud Trail in the same account as the IAM user or role for which you wanted to generate policies), and strict quotas in terms of number of generated policies per day.

Nowadays it seems to be much more mature and returns fine-grained policies for dozens of services and less granular policies for the rest of the services. For the former, it uses CloudTrail and works fine also in enterprise environments with centrally stored CloudTrail logs in a separate account. For the latter, it uses the “last accessed” information only to find out whether the service has been used or not without returning the individual actions.

I’m quite sure that over time, the coverage of services where fine-grained policies can be generated will grow significantly.

Conclusion

AWS IAM Access Analyzer is a great tool, or better said, a great toolset, which can help you in many ways. Whether you are a software developer deploying code on AWS and wanting to check if your policies adhere to best practices, or a security engineer wanting to get an additional view on the security posture of your AWS Organization or if you are part of a central infrastructure or security team creating and finetuning least-privileged IAM roles and policies.

I’ve spent some deploying and using the functionalities described above and I plan to do a deep dive about some of them in one of my next articles, so stay tuned!