Cross Org Account ECR image push

0

Hello,

So I am trying to push an image created from ADO pipeline. The push is failing saying USER_X is not authorized to perform: ecr:GetAuthorizationToken on resource: * with an explicit deny in an identity-based policy

The org is et up as the following:

Root
   > Accounts
       > Org 1
       > Org 2
       > Org 3

I am unable to change the above :(

root has IAM setup and configured and this is were my user ("USER_X") sits, full admin access.

I have an ECR setup in Org2 (for example), I created a policy following an example which is stated as allowing cross org. and contains the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ecr:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "aws:PrincipalOrgID": "ROOT_ACCOUNT_ID"
                }
            }
        }
    ]
}

However this does not allow my to do anything.

Any ideas or help is greatly appreciated

9 個答案
2
               "aws:PrincipalOrgID": "ROOT_ACCOUNT_ID"

Make sure that you are referencing the OrgID and not the ROOT_ACCOUNT_ID.

The Org ID should look something like o-uynqXXXXcq

profile pictureAWS
專家
iBehr
已回答 2 個月前
  • Hi iBehr,

    I have changed to the OrgID, thank you for spotting that

    Alas no change

0

What iBehr wrote is correct, but adding to that, you are also missing the "Principal" element from the policy. When you are wanting to permit all the principals in the entire organisation access, you should use the Condition element as you are attempting, but you also have to include the Principal element either as "Principal": "*" or "Principal": { "AWS": "*" }

In examples you might have seen, the Principal element isn't present in policies attached to an IAM user or IAM role, because the principal is then defined by that attachment. In a resource-based policy, like one attached to an ECR repository, the principal must be specified for the statement to have any effect.

Also, since the error message states that the access was blocked by an explicit deny in an identity-based policy, you know that it's likely one of the policies attached to the principal (probably an IAM role) on their side that has a "Deny" statement blocking the access, or an SCP on their side that perhaps blocks access outside their org. However, regardless of whether they permit access on their side, it won't work without that Principal element in the "Allow" statement in the ECR repository policy.

專家
Leo K
已回答 2 個月前
  • Hi Leo,

    I have tried to add the Principal section, but the UI complains:

0

The ECR registry policy you set with the statement ID AllowECRAccess is extremely dangerous. It allows access to everyone in the world, including criminals and opportunists.

You can specify either one or more principals, like a role or entire AWS acount, in the "Principal" element to avoid this, or you can allow "*" in the Principal element of the statement but additionally filter by authorised organisation ID, OU path, account ID, or other sufficiently restrictive criteria to allow access only by the principals you intended to permit.

With the organisation ID, the policy statement could look like this, for example. The vital addition is the aws:PrincipalOrgID key evaluation in the Condition element:

{
    "Sid": "AllowECRAccess",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "ecr:*",
    "Resource": "arn:aws:ecr:eu-west-2:XXXXXXXXX:repository/*",
    "Condition": {
        "StringEquals": {
            "aws:PrincipalOrgID": "o-abcde12345"
        }
    }
}
專家
Leo K
已回答 2 個月前
  • oh christ!! Thank you for pointing that out!!!

0

1. Check User Policies: Review the IAM policies directly attached to the user (USER_X). Look for any Deny statements related to the ecr:GetAuthorizationToken action.

2. Check Group Policies: If the user is part of any IAM groups, review the policies attached to those groups for any explicit Deny statements.

3. Check Role Policies: If the user is assuming an IAM role, review the policies attached to that role for any explicit Deny statements.

4. Check SCPs (Service Control Policies): If your account is part of an AWS Organization, check if there are any Service Control Policies (SCPs) applied to the organizational unit (OU) or the account that might explicitly deny the ecr:GetAuthorizationToken action.

5. Check Permission Boundaries: Ensure that there are no permission boundaries set that might be restricting this action.

6. Analyze Policy Simulator: Use the AWS IAM Policy Simulator to simulate the ecr:GetAuthorizationToken action for the user. This tool can help identify which policies are affecting the permission.

profile picture
專家
已回答 2 個月前
0

Enter image description here

The error in question ^^

Updated policy:

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "VisualEditor0",
			"Effect": "Allow",
			"Principal": "*",
			"Action": "ecr:*",
			"Resource": "*",
			"Condition": {
				"ForAnyValue:StringLike": {
					"aws:PrincipalOrgID": "o-<OrgID>/r-<RootID>/*"
				}
			}
		}
	]
}
gavinc
已回答 2 個月前
0

In the revised policy, the request context condition key aws:PrincipalOrgID is single-valued, so you should not use the ForAnyValue or ForAllValues modifiers for the operator. You only need the regular, single-valued operators, such as StringEquals. ForAnyValue and ForAllValues only go with keys that can contain multiple values.

The key also only contains the organisation ID, such as "o-xxxxxxxxxxx". It doesn't contain the path to the account that contains the principal, so adding the /r-... segment will prevent that condition from ever matching. If you want to permit the whole org, you'll need to use the StringEquals operator to match the org ID only, such as "o-12345abcde" -- without anything preceding or following it.

If you want to specify a particular OU path in the organisation, the appropriate request context condition to evaluate is aws:PrincipalOrgPaths. That key is multi-valued, so you should use the ForAnyValue:StringLike operator as in your example.

Is the screenshot of the policy validator error for the Principal element of the ECR repository policy or the identity-based policy that is attached to the IAM role or user? The Principal element must be present in a resource-based policy, such as an ECR repository policy, but it mustn't be present in an identity-based policy attached to a principal, like an IAM user or IAM role.

專家
Leo K
已回答 2 個月前
0

Re-reading your question a couple of times, I think you are writing the policy statement in the identity-based policy attached to an IAM user. The "Principal" element isn't required or possible to use, indeed, because the principal is indicated by the policy attachment.

However, also the aws:Principal* condition keys don't make much sense attached to an IAM user or role. They would only filter based on your (=the IAM user's/role's) own organisation matching the criteria, but you already know which account and org you are in.

The aws:PrincipalOrgID condition should be in the statement in the ECR registry policy that allows access for all principals in the entire organisation whose ID you specified.

The policy that you attach to the IAM user or IAM role in the source organisation (the one that hosts the identity) doesn't need to check its own organisational affiliation. If you want to allow the user/role to access resources only in a given remote organisation, then you should identify the target repository in the "Resource" in the policy statement or specify it as a wildcard ("*"), and additionally in the "Condition" clause of that same policy statement, require that the resource resides in the expected target organisation by doing a StringEquals comparison of aws:ResourceOrgID and the organisation ID that owns the ECR repository.

In short, in the identity-based policy (=the policies attached to the IAM user or IAM role), you should use the aws:Resource* condition keys to verify that the target resources are owned by the organistation, account, or account residing in a given OU in the authorised target organisation. The resource-based policy (=the ECR repository policy) should use the aws:Principal* keys to restrict the organisation, account, or OU location of the AWS account in which the IAM user or IAM role resides.

專家
Leo K
已回答 2 個月前
0

Leo,

Thank you for that.

Ok so I have a policy attached to the ECR as follows:

{
  "Sid": "AllowECRAccess",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "ecr:*",
  "Resource": "arn:aws:ecr:eu-west-2:XXXXXXXXX:repository/*"
}

An IAM policy attached to a Rule, attached to the user (USER-X) in the other org:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetAuthorizationToken",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ManageRepositoryContents",
            "Effect": "Allow",
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
            ],
            "Resource": "*"
        }
    ]
}

Which I will go though once working and reduce the access. However this is still failing . I ran it through the simulator for USER-X which states allowed:

Simulator Access

gavinc
已回答 2 個月前
0

All,

Thank you for your input on this.

I have resolved!!

Policy was added to the registry as noted above. Policy for top tier Org added to Role (this is the bit I was missing)

Reran the simulator, and this time failed, went through and corrected where needed

gavinc
已回答 2 個月前

您尚未登入。 登入 去張貼答案。

一個好的回答可以清楚地回答問題並提供建設性的意見回饋,同時有助於提問者的專業成長。

回答問題指南