Cross-account IAM principal pointing to same account: no-op?-CodePudding

In short: if I create an IAM policy containing a cross-account Principal, but the account in question is the one I'm already operating in, is that a no-op?

My understanding (from here) is that an IAM statement like the following can be used for cross-account access, i.e. to delegate to another account, allowing it to allow access to the resource in question:

{
  Action = "kms:*"
  Effect = "Allow"
  Principal = {
    AWS = "arn:aws:iam::XYZXYZXYZXYZ:root"
  }
  Resource = "*"
}

(where XYZXYZXYZXYZ is some account ID, obviously).

But what if the account ID isn't another account? I'd hope this does nothing. I'd fear it grants full access. Latter option seems insane: can anyone confirm?

CodePudding user response：

I am assuming this is in a KMS key policy otherwise specifying the principal would not make sense / would be disallowed by IAM anyway.

Therefore I am quoting https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html:

The following default key policy statement is critical.

It gives the AWS account that owns the KMS key full access to the KMS key.
Unlike other AWS resource policies, an AWS KMS key policy does not automatically give permission to the account or any of its users. To give permission to account administrators, the key policy must include an explicit statement that provides this permission, like this one.

It allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.
Without this permission, IAM policies that allow access to the key are ineffective, although IAM policies that deny access to the key are still effective.

It reduces the risk of the key becoming unmanageable by giving access control permission to the account administrators, including the account root user, which cannot be deleted.

The principals within the account do not immediately have access to the key but just adding a policy to them will grant them access. KMS is one of the few services with where both the resource and the identity policies need to grant the access.