Fix permissive access policy for backup vaults

[ppmathis]

Back in 2021 the PR #643 has been merged to handle the proper deletion of backup vault access policies and recovery points of default automatic backup vaults for EFS. This is required as AWS by default pushes the following vault access policy, which makes it impossible to delete these resources by any user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "backup:DeleteBackupVault",
                "backup:DeleteBackupVaultAccessPolicy",
                "backup:DeleteRecoveryPoint",
                "backup:StartCopyJob",
                "backup:StartRestoreJob",
                "backup:UpdateRecoveryPointLifecycle"
            ],
            "Resource": "*"
        }
    ]
}

The workaround implemented by said PR was to first attempt to push a more permissive policy, which would then make deletion feasible again. The policy that is being attempted to be set as of today is:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "backup:DeleteBackupVaultAccessPolicy",
            "Resource": "*"
        }
    ]
}

Unfortunately this approach no longer works, as AWS is preventing the deployment of an overly permissive policy like this, which would apply to all AWS accounts due to using a wildcard principal. The specific error message which is being generated today, when trying to push this policy, is:

The specified policy cannot be added to the vault due to cross-account sharing restrictions. Amend the policy or the vault's settings, then retry request.

As errors during this operation are being silently ignored, this leads to the deletion of the policy itself as well as other resources to fail, just like before #643 has been merged. To get this operation working again, it is required to push a permissive but more precise policy, which will be accepted by AWS.

This MR accomplishes that by first looking up the caller identity, then building a permissive vault access policy which is specifically targeting arn:aws:iam::<account-id>:root as the principal. This updated policy is happily accepted by AWS and then allows for the deletion of the vault access policy, after which all other resources can be deleted too.

I successfully replicated the original issue on different AWS accounts and also verified that this solution worked on all of them.

[ekristen]

It's unclear if this or #1150 is the correct way to handle this, so for now I've opened an issue to track ekristen/aws-nuke#353 -- I believe this might be the most logical way to handle this problem.

---

Please see the copy of the notice from the README about the deprecation of this project. Sven was kind enough to grant me access to help triage and close issues and pull requests that have already been addressed in the actively maintained fork. Some additional information is located in the welcome issue for more information.

Caution

This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke.
We appreciate all the support and contributions we've received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke.
Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository.
Thank you for your understanding and support.