(aws-cdk/aws-s3): bucket.grantRead does nothing when bucket is imported and grantee identity policy is absent

Describe the bug

I created an S3 bucket in Stack1. In Stack 2, referencing this bucket using bucket.fromAttributes methods. In Stack2 I also created a CloudFrontDistribution and OriginAccessIdentity. Then grant access to OriginAccessIdentity. After deploying these stacks, no updates made to Bucket policy. Also no errors thrown during deployment.

Expected Behavior

OriginAccessIdentity should be granted Read access on S3 Bucket.

Current Behavior

It doesn’t grant read access.

Reproduction Steps

Code for Stack1

export default class StaticAssetsStack extends Stack {

    public readonly staticAssetsBucket : IBucket;
  
  constructor(parent: App, name: string, props: StaticAssetsStackProps) {
    super(parent, name, props);

    this.staticAssetsBucket = new Bucket(this, `AssetBucket`, {
        versioned: false,
        bucketName: `website-assets`.toLowerCase(),
        removalPolicy: RemovalPolicy.RETAIN,
        enforceSSL: true,
        encryption: BucketEncryption.S3_MANAGED,
      });
  }
}

Code for Stack2

export default class WebsiteStack extends Stack {
  constructor(parent: App, name: string, props: WebsiteStackProps) {
    super(parent, name, props);

     const staticAssetsBucket = Bucket.fromBucketAttributes(this, `staticAssetsBucket`, {
      bucketName: props.staticAssetsBucketName,
      region: props.staticAssetsBucketRegion
    });
   const originAccessIdentity =
      new OriginAccessIdentity(this, `${props.name}-OAI`);
   staticAssetsBucket.grantRead(originAccessIdentity);
   const s3Origin = new S3Origin(staticAssetsBucket, {
      originAccessIdentity,
    });

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

CDKv2

Framework Version

No response

Node.js Version

14.x

OS

Linux

Language

Typescript

Language Version

No response

Other information

No response

[kornicameister]

Well, that’s not quite true, at least now all the way. One example can be found in my app, where I augmented legacy instance role with necessary permissions. So in other words; I had imported construct and was able to modify it. Point taken; that was indirect modification via ManagedPolicies where role is attached.

Just wanted to clarify that a bit; that some resources have a way to support that while others don’t.

[kornicameister]

My problem: https://github.com/aws/aws-cdk/issues/22047 is maybe not related but at the very least have the same ancestry.
If you had transfer a bucket between stacks via reference i.e. creating implicit Fn::Export and Fn::Import things would work. On the other hand, if you are importing bucket that way I am pretty sure that addToResourcePolicy calls will be simply be ignored. Maybe not ignored, but imported bucket has no policy that is required to be set. To generalize that, if you import a resource it really doesn’t matter (if I am right) if that’s a bucket, a key or a dynamo db table as long as you’re interested in seeing those resources’ policies updated during any grant* operation or by hand.

---

All in all, I feel like the proper response here is to fail the synth instead of silently ignoring the fact. However, you can verify things on your own i.e:

if(!Bucket.fromBucketAttributes(..).grantRead().statementAdded){
   throw new Error('Failed to grant read')
}

There’s this iam.AddToResourcePolicyResult thingy that contains statementAdded property.