Cross Org Account ECR image push

               "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

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.

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"
        }
    }
}

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.

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>/*"
				}
			}
		}
	]
}

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.

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,

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:

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