AWS Inventory with EC2 Beacon, region setting in powershell

[mag00_75]

We are running 2019R2 on-premise with a beacon in AWS to be able to fetch the instance data directly thru IAM roles assigned to the beacon instance. The powershell script do not check which region the beacon server is installed in (which I think should be improved), so we need to add the default region somehow. Any thoughts where it shall be defined for the out of the box adapter? - It works if we logon and run powershell as administrator and run Set-DefaultAwsRegion -region eu-north-1 and then starts the batch job. But it doesn't stick if we logout. - It doesn't work to set the commands and region variable in the $profile.AllUsersAllHosts $StoredAWSRegion=’eu-north-1’ Set-DefaultAwsRegion -region eu-north-1

[mrichardson]

We recently did some updates on this so I'm speaking to the developers who worked on it to get some insights for you.

[ccrawford]

Hello @mag00_75,

Sorry to hear you're having trouble with our latest version of the AWS adapter. It was me who made the changes to this adapter - and I agree, the way we handle the region is poor.

I looked at this today and I made some changes which I hope you could possibly try to apply to your environment and see if the behaviour is more desireable?

1. Please first back up the original 'Logic.ps1' from the Batch server in the AWS adapter folder, this is typically located C:\ProgramData\Flexera Software\Compliance\ImportProcedures\Inventory\Reader\Amazon Web Services
2. Overwrite the file with the attached file on the Batch server
3. Run the connection in the beacon - which should download the updated file from the Batch server using the following command line (without the workaround you mention) - does it now connect to the desired location?
   ComplianceReader.exe -v -s "connection name"
   ComplianceReader.exe is located typically by default in C:\Program Files (x86)\Flexera Software\Inventory Beacon\DotNet\bin
4. Please provide the log output file.

[mag00_75]

Hi

I attached the last part of the log, the initial account now got the region set. which is good 🙂

Our cloud team is working with all sub accounts, so I'm not sure if the fault with regions for those are related to the script or how our environment is setup. But I would expect that it shouldn't need to shift region for each account.

[ccrawford · Accepted solution]

It looks like you've found a bug caused by a use case we hadn't expected - well done 🙂

Am I right in assuming that one of your policies specifies multiple roles which it can assume? Similar to this?

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::429345039360:role/TestRole_EC2",
                "arn:aws:iam::429345039360:role/TestRole_EC22"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "sts:GetCallerIdentity"
            ],
            "Resource": "*"
        }
    ]
}

If so, then yes this is a bug which is because the adapter was not designed to handle cases where there'd be multiple resources on one policy. I was able to replicate your error by creating the above policy.

Would you please raise a support case referencing this community post and request that a bug is raised to track this issue?

I've attached a version I think should resolve this issue - but the bug may return if not permanently fixed in a later version of FNMS.

[ccrawford]

Additionally, the first parts of the script will use the region that the beacon is installed in - but the later parts loop through the regions.

This is because when creating this adapter it was noticed that if you had EC2 instances in say, eu-west-1 - you'd not be able to see them if you queried us-east-1 - so we loop over all regions to get all the region's data.

[mag00_75]

Hi @ccrawford 

I have asked our cloud team how they have setup the roles and will come back with an answer on your question.

I tested the new script but it hangs on the sa-east-1 for several minutes, then I cancelled the job.
I will also open up a ticket and refer to this dialogue

[ccrawford]

Hello @mag00_75,

Yes - that would be best to raise a support case at this point. I should note however:

* It looks like your AWS administrators may have possibly specified the same resource (role) for that policy multiple times (as indicated by the multiple lines showing the same role assumed multiple times arn:aws:sts::XXXXXXXXX397:assumed-role/ListEC2ForFNMSRole). This won't harm the adapter from working, but it will likely cause a repeat inventory to occur for each of the listed roles, meaning you are potentially inventorying the same data multiple times for no benefit (the duplicates will be discarded) - which will hurt performance.

* When it is hanging on the sa-east-1 part, this is where the runspaces are initialized. There is one runspace per region and each runspace runs against each role that is assumed. So you can imagine the more roles you specify, the more work that must be done. The factor is R = 17 * Ro (where R = runspaces and Ro = Roles).

[ccrawford]

The factor is R = 18 * Ro (where R = runspaces and Ro = Roles).

Can't edit my posts for some reason 🙂

[mag00_75]

@ccrawford
For now we have only 5 out of 400+ accounts configured. We followed the instructions and with that it seams we shall create a role (referencing master account) and policy per account.
Is it possible todo it with only 1 role for 400 accounts?
I’m letting the script run until it’s finished but I think its running for an hour. Next I think I will customize and only instantiate regions we use to save some runtime.

[ccrawford]

Yes, you can have one role which specifies multiple policies - the default adapter is designed to handle multiple policies, each with a single Arn for each policy pointing to a different account.

The version I provided last will also allow you to specify multiple Arns per policy (which appears to be the situation in your environment).

I would note that I think the reason it is taking so long, is that you have multiple of the same policy referring to the same Arn - so you're getting inventory once, then you get it again, and again - each time having to remove the duplicates.

It may be an idea to start off with setting up the basic account access (to the master account) - confirm it is working as expected and within performance figures, and then slowly add one at a time to confirm if everything is working.

With the amount of accounts you have, it may be an idea to split them up into groups which use different roles / policies so it's easier to manage - but that's just a simple suggestion 🙂