aws-iam: Assigning the same user policies in multiple stacks can cause previous policies to be overwritten

[TheRealMintd]

Describe the bug

When a user is imported into multiple CDK stacks, and is granted policies through ISecret.grantRead (or similar), the last deployed stack's policy overrides whatever was granted before on the user.

Seems to be similar to #23080, but for users instead of roles.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

Each policy should be unique on a per-stack basis, such that each stack's policies don't overwrite one another.

Current Behavior

Only the last deployed stack's policy is attached to the user, overwriting all previous policies.

Reproduction Steps

With a created user, bucket, and function, deploy these two stacks:

export class FirstStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: FirstStackProps) {
    super(scope, id, props);

    const bucket = new Bucket(this, 'Bucket', {
      autoDeleteObjects: true,
      removalPolicy: RemovalPolicy.DESTROY
    })
    const user = User.fromUserArn(this, "User", "<userArn>")
    bucket.grantWrite(user)
  }
}

export class SecondStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: SecondStackProps) {
    super(scope, id, props);

    const fn = new Function(this, 'MyFn', ...)
    const user = User.fromUserArn(this, "User", "<userArn>")
    fn.grantInvoke(user)
  }
}

Possible Solution

Perhaps a similar fix to what was done for #23080?

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.235.1

AWS CDK CLI version

2.1118.4

Node.js Version

18.20.8

OS

Linux

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Thanks for filing this — I was able to reproduce the issue locally via cdk synth. Two stacks importing the same user via User.fromUserArn() both produce a policy named UserPolicy7D689AB7, confirming the overwrite behavior.

You're correct that this is the user-side equivalent of #23080. The root cause is in User.fromUserAttributes(), where the default policy is created with a hardcoded construct ID 'Policy':

aws-cdk/packages/aws-cdk-lib/aws-iam/lib/user.ts

Lines 212 to 217 in 818574f

	public addToPrincipalPolicy(statement: PolicyStatement): AddToPrincipalPolicyResult {
	if (!this.defaultPolicy) {
	this.defaultPolicy = new Policy(this, 'Policy');
	this.defaultPolicy.attachToUser(this);
	}
	this.defaultPolicy.addStatements(statement);

The fix for roles (PR #23100) used Names.uniqueId(this) behind a feature flag to generate stack-unique policy names, but this was never applied to the imported User class:

aws-cdk/packages/aws-cdk-lib/aws-iam/lib/private/imported-role.ts

Lines 73 to 84 in 17f69d6

	const useUniqueName = FeatureFlags.of(this).isEnabled(IAM_IMPORTED_ROLE_STACK_SAFE_DEFAULT_POLICY_NAME);
	// To preserve existing policy names, use Names.uniqueResourceName() only when exceeding the limit of policy names
	// See https://github.com/aws/aws-cdk/pull/27548 for more
	const prefix = 'Policy';
	let defaultDefaultPolicyName = useUniqueName
	? `${prefix}${Names.uniqueId(this)}`
	: prefix;
	if (defaultDefaultPolicyName.length > MAX_POLICY_NAME_LEN) {
	defaultDefaultPolicyName = `${prefix}${Names.uniqueResourceName(this, { maxLength: MAX_POLICY_NAME_LEN - prefix.length })}`;
	}
	const policyName = this.defaultPolicyName ?? defaultDefaultPolicyName;
	this.defaultPolicy = new Policy(this, policyName, useUniqueName ? { policyName } : undefined);

It appears PR #37683 is already addressing this with the same pattern — introducing @aws-cdk/aws-iam:importedUserStackSafeDefaultPolicyName (and a bonus fix for imported Groups). The approach looks solid and follows the established precedent from the role fix.

Workaround until the fix lands: avoid using convenience grant methods (like bucket.grantWrite(user)) on imported users shared across stacks. Instead, create a manually-named policy with explicit statements instead.