Bug 2017635

All of the actions listed in the policy are required for cloud meter to function. Removing any of them may cause unexpected failures and will likely result in the customer's source being updated as "unavailable".

Our customer-facing documentation generally explains the purpose of each action: https://access.redhat.com/documentation/en-us/subscription_central/2021/html/getting_started_with_the_subscriptions_service/assembly-adding-sources-publiccloudmetering#ref-actions-allowed-by-AWS-IAM-policy_assembly-adding-sources-publiccloudmetering-ctxt

Please let me know if you need more specific details about how we use each of those actions, and I can explain. We are aware that this policy also casts a wide net with its "*" resource definition, but we cannot easily shrink that without making complex and frequent changes to the policy itself to grant access to specific resources as they are created and destroyed.

If the customer is unable or unwilling to allow this broad level of access, my suggestion is to disable or remove the related source because cloud meter cannot perform its required operations without that access.

Hi, 

Below is the reply from the Customer

=======================================================
The Australian Government laws do not allow data that is classified as sensitive to be taken outside the Australia without being granted a specific exemption or agreement. These are the rules I must work with. The data inside the EC2 Images is classified as sensitive.

The RHSM public cloud metering process appears to want to copy an EC2 Image from the AWS ap-southeast-2 (Sydney) region into the AWS us-east-1 (N. Virginia) region which Australian laws do not allow.

In order to meet full compliance with Australian law I am forced to change the IAM policy used by RHSM  to the one below which breaks RHSM compliance. Fortunately so far, I do not seem to have suffered any negative side effects probably because the pool that is being managed by RHSM is very small (14 nodes).

New AWS IAM Policy for arn:aws:iam::828388250414:role/redhat-cloud-meter-role-2c5aa4b26280af2a

 {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudigradePolicy1",
            "Action": [
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeSnapshotAttribute",
                "ec2:DescribeSnapshots",
                "ec2:DescribeRegions"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Sid": "CloudigradePolicy2",
            "Action": [
                "cloudtrail:DescribeTrails"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Sid": "CloudigradePolicy3",
            "Action": [
                "cloudtrail:CreateTrail",
                "cloudtrail:UpdateTrail",
                "cloudtrail:PutEventSelectors",
                "cloudtrail:StartLogging",
                "cloudtrail:DeleteTrail"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:cloudtrail:us-east-1:828388250414:trail/prod-828388250414"
        }
    ]
}
========================================================

Hi all,

As Brad notes above, the specific permission is necessary for the "is this RHEL" inspection to work. What we provision and what we do with that permission is in our docs, and customers for whom this permission is no good should ABSOLUTELY not use Cloud Metering and can instead rely on the lower fidelity OS-level agents for subs management.

There's a side concept in this ticket that the inspection would be less of a problem if it remained in AUS, and we agree that it is highly desirable that a broad range of Insights services operate in the "home" region of the systems that they're working with. I'm going to attach this case to our geographical concerns issue in Jira, which can be found here: https://issues.redhat.com/browse/RHIN-24

Because one half of this BZ is currently unfixable and we're addressing the other half in a trackable Jira issue, I'm going to close this BZ out.

Cheers,
Dan