assetnote / ghostbuster

Eliminate dangling elastic IPs by performing analysis on your resources within all your AWS accounts.
GNU Affero General Public License v3.0
264 stars 35 forks source link

Ability to run by assuming roles instead of using credentials #11

Closed gister9000 closed 1 year ago

gister9000 commented 1 year ago

Hello

I wanted to add ghostbuster to the organisation I'm working for, but our security policy doesn't allow specifying so many account credentials at one place, even though those accounts have very limited and read-only permissions.

The solution to the problem is to use AWS IAM roles instead of specifying credentials as follows:

  1. Create GhostbusterTargetAccountRole in every AWS account (policy from README).
  2. Ghostbuster is running from lambda/ec2 with ghostbuster (master) role that can assume GhostbusterTargetAccountRole from other accounts. IAM policy that permits ghostbuster to assume all those GhostbusterTargetAccountRole roles:
    {
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Action" : "sts:AssumeRole",
        "Resource" : ["arn:aws:iam::*:role/GhostbusterTargetAccountRole"]
    }]
    }
  3. Ghostbuster will assume each of those roles and do its magic. Assuming those roles is not possible unless the permission is given from the target account as well.

When it comes to specifying which accounts should ghostbuster run on, there are 2 options: a.) --roles roles.csv b.) --autoroles

In a.), csv of account_id values is specified and used by ghostbuster to get role ARN (accound_id is the only thing we need to create GhostbusterTargetAccountRole ARN: arn:aws:iam::ACCOUNT_ID:role/GhostbusterTargetAccountRole).

In b.), ghostbuster will automatically find all account IDs from an organisation. In order to do so, it needs additional permissions:

{
    "Statement": [
        {
            "Action": [
                "organizations:ListAccounts",
                "organizations:DescribeAccount"
            ],
            "Effect": "Allow",
            "Resource": "*",
            "Sid": "BaseAccess"
        }
    ],
    "Version": "2012-10-17"
}

This organisation lookup policy should exist in AWS account which has the organisation overview. The ghostbuster role itself should be able to assume the organisation lookup policy.

Please let me know if you would appreciate terraform modules for this and I will probably share that as well.

infosec-au commented 1 year ago

@gister9000 -

Thanks a tonne for this work! This is awesome!

I've just merged a few PRs in (sorry, just catching up). There's a merge conflict for this PR now, I was wondering if you could please address it? It conflicts with JSON support added in a previous PR. Happy to merge after this.

infosec-au commented 1 year ago

After this PR is merged, I will cut a new release of Ghostbuster and push it to PyPi

gister9000 commented 1 year ago

Thanks for the kind words :)

I'll resolve the conflicts early next week along with providing examples of AWS stuff I used such as lambda function and maybe some more terraform code.

gister9000 commented 1 year ago

Let's not rush this merge, I'm adding some documentation and examples on how to use --roles and --autoroles.

Also, a bit more testing is desirable after resolving those conflicts etc

gister9000 commented 1 year ago

Hi @infosec-au

I think this is well tested and clean now - let's ship it!

infosec-au commented 1 year ago

Thanks for your hard work @gister9000 - I will also create a new release now.

infosec-au commented 1 year ago

I validated your changes and published a new version on PyPi (1.0.1). Thanks again!