The AWS script can not work without boto3.

And boto3 is missing in the requirements.txt.

I would like to propose that we start using tagged releases for our project. Tagged releases can significantly improve project management, making it easier for users and developers to understand the project's progress and history.

Benefits of tagged releases:

1. Versioning: Tagged releases provide clear and well-defined version numbers, making it easy for users and developers to identify the latest stable version of the project. This helps avoid confusion when multiple releases or updates are made.

2. Changelogs: With tagged releases, we can generate and maintain a changelog that summarizes the changes made in each release. This allows users and developers to quickly understand the differences between versions, and identify new features, bug fixes, or performance improvements.

3. Easier collaboration: Tagged releases make it easier for contributors to track the project's progress and identify the specific version they are working on. This can prevent potential issues when merging code or addressing bugs.

4. Dependency management: When our project is used as a dependency by other projects, tagged releases help ensure that users can easily specify and update the version of our project they depend on. This can minimize compatibility issues and improve the overall stability of the dependent projects.

5. Rollbacks: In case a new release introduces a bug or breaks compatibility, tagged releases make it easy to roll back to a previous stable version, ensuring minimal disruption for users.

Suggested approach:

1. Adopt a versioning scheme, such as Semantic Versioning, to provide a consistent and meaningful versioning system for our project.
2. Use Git tags to mark each release with the corresponding version number.
3. Publish tagged releases on GitHub, providing release notes that summarize the changes made in each version.

By adopting tagged releases, we can improve project management and make it easier for users and developers to understand and contribute to our project.

Please share your thoughts and suggestions on this proposal.

Run Cloud Benchmark script at AWS Org Level (and other cloud equivalents) to more easily obtain numbers.

Issue: When an account is deleted in an AWS Organization, it remains in a suspended state for 90 days before it's permanently removed from the organization. As a result, the script may fail if it attempts to discover and assess an account in suspended state. Therefore, it's important to modify the script to skip any accounts that are in a suspended state during the discovery process.

Background: AWS Organizations places accounts in a suspended state for 90 days after they're deleted from the organization. During this period, the account is inaccessible and cannot be discovered or assessed. If the script attempts to discover and assess a suspended account, it will likely fail and generate errors, which can negatively impact the performance of the script.

Proposed Solution: To address this issue, we recommend modifying the script to skip any accounts that are in a suspended state during the discovery process. This will prevent the script from attempting to assess accounts that cannot be accessed, and avoid generating unnecessary errors.

Example output:

[cloudshell-user@ip-10-6-167-65 cloud-benchmark]$ python3 [aws_cspm_benchmark.py [aws_cspm_benchmark.py]
Cannot access adjacent account:  631025991766 An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::115255193357:assumed-role/AWSReservedSSO_AWSAdministratorAccess_b737e96d1e697324/[[email protected]](mailto:[email protected]) is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::631025991766:role/xxxxxxxxxxxxxxxxxxxxxx
Traceback (most recent call last):
  File "aws_cspm_benchmark.py", line 125, in <module>
    for aws in AWSOrgAccess().accounts():
  File "aws_cspm_benchmark.py", line 52, in accounts
    return [self.aws_handle(a) for a in accounts]
  File "aws_cspm_benchmark.py", line 52, in <listcomp>
    return [self.aws_handle(a) for a in accounts]
  File "aws_cspm_benchmark.py", line 60, in aws_handle
    return AWSHandle(aws_session=self.new_session(account['Id']), account_id=account['Id'])  File "aws_cspm_benchmark.py", line 76, in new_session
    raise exc
  File "aws_cspm_benchmark.py", line 66, in new_session
    RoleSessionName=account_id
  File "/home/cloudshell-user/.local/lib/python3.7/site-packages/botocore/client.py", line 530, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/home/cloudshell-user/.local/lib/python3.7/site-packages/botocore/client.py", line 960, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::115255193357:assumed-role/AWSReservedSSO_AWSAdministratorAccess_b737e96d1e697324/[[email protected]](mailto:[email protected]) is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::631025991766:role/xxxxxxxxxxxxxxxxxxxxx

Issue: The script assumes into child accounts using the default OrganizationAccountAccessRole role name, which can cause issues if a user specifies a custom name for the role. As a result, there is a need to add a CLI argument to the script that allows for the role name to be overwritten.

Background: AWS Organizations creates a default IAM Role named OrganizationAccountAccessRole in each child account by default. This role is used to manage child accounts with a trust relationship to the root account. However, a user has the option to specify a custom name for this role. If a user specifies a custom name, scripts that use the default role name to assume into child accounts may fail.

Proposed Solution: To address this issue, we recommend adding a CLI argument to the script that allows the user to specify the role name to be used for assuming into child accounts. This would provide more flexibility and allow the script to be customized to work with different role names, regardless of whether the default or a custom name is used.

Additional Information: For more information about the OrganizationAccountAccessRole role and managing accounts in AWS Organizations, please refer to the AWS Organizations documentation: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html

Please add the ability to count containerized workloads (For AWS|Azure|GCP) including:
k8 Clusters
K8 Pods
Containers per Pod
Containers running in other locations

Issue: When running the benchmark script in an AWS account, I noticed an oddly large number of EC2s being accounted for. When looking into this further I noticed that 36, of the total instances, were actually “Terminated”. When running the script in an account that does not use Spot Instances, we did not see any discrepancies.

Possible Solution: Looking at the instance description, from the CLI/API, you should be able to filter on the Instance’s State.Name == 'terminated' to remove these special cases from the results.

From what I can derive, I think AWS tracks the Terminated Spot Instances to allow the owner to look into why a Spot Instance might have been terminated, and when.