Deployment Issue: Old contents not deleted from S3 Bucket after bundler migration to vite

[ronakseth96]

After migrating our webapp's bundler from React Scripts to Vite due to npm install issues, the deployment was successful, but older contents in the S3 bucket (generated with React Scripts) were not deleted. This causes outdated files to persist, leading to potential conflicts and inconsistencies.

This deployment issue is related to Issue #49.

[ronakseth96]

Due to limited privileges, integrating the delete operation during the CodePipeline build and deployment phases was unsuccessful, resulting in an access denied issue with the S3 bucket service on AWS.

Operation: This command syncs all local objects to the specified bucket and deletes all files that do not match. aws s3 sync ./my-app/build s3://<mybucket> --delete

Here are the steps I tried: 1. AWS Lambda: Initially, I attempted to integrate the delete functionality during deployment, where contents were moved using an AWS Lambda function. However, this integration was not possible due to permission restrictions for the lambda function.

2. Build Phase: I tried to achieve the same during the build phase via AWSCodeBuild. I attempted to access the S3 bucket via the aws-cli used in buildspec file during the post-build operation which is running on the custom image. Unfortunately, this also faced privilege issues for S3 requests that return Access Denied exceptions.

[ronakseth96]

Note: I learned that when we attach an IAM service role to an AWS CodeBuild project, there's no need to configure the AWS CLI separately. The IAM service role is part of the environment configuration and will be automatically assumed when accessing AWS resources. This also applies to custom images used in AWS CodeBuild, eliminating the need for separate AWS account configurations.

[ronakseth96]

Upon encountering the errors, I investigated the AWS CodeBuild IAM roles and their attached policies. To proceed with this, I requested specific IAM permissions from Rodo. Specifically, I reviewed the assume-env-manager and CodeBuildPolicy policies for the pipeline-BuildProjectRole.

Subsequently, I proceeded with the following steps to resolve the errors: An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied [Container] Command did not exit successfully aws s3 ls exit status 254 Resolution: Granted the s3:ListAllMyBuckets permission to fix this.

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied Resolution: Granted the s3:ListBucket permission to fix this.

Even with these permissions, I could not access all the buckets because the resource was restricted to the pipelinebuiltartifact. To resolve this, I modified the resource to * so that all the resources (buckets) could be accessed.

After these changes, I was able to list all the S3 buckets successfully.

[ronakseth96]

After resolving the initial errors, the synchronization with the delete operation continued to fail with the following error: Error: An error occurred (AccessDenied) when calling the DeleteObject operation: Access Denied Resolution: Granted the s3:DeleteObject permission.

And, we successfully deleted all the old objects from the bucket.

[ronakseth96]

S3 sync operations were initially granted broad permissions (*), potentially allowing access to all buckets. To enhance security, I updated the permissions to restrict actions exclusively to a specific bucket, aligning with best practices for least privilege and resource management in AWS.

To mitigate this, I refined the policy to restrict operations exclusively within the specific reg-webapp-test-bucket. Here are the adjustments made to ensure more secure access:

{
    "Action": [
        "s3:PutObject",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "s3:DeleteObject"
    ],
    "Resource": [
        "arn:aws:s3:::<reg-webapp-test-bucket>",
        "arn:aws:s3:::<reg-webapp-test-bucket>/*"
    ]
}

[ronakseth96]

Since I manually updated the IAM policy through the AWS Management Console, I see that these changes are not automatically reflected in the existing CloudFormation stack. While the current deployment is functioning correctly, I am reviewing it, though, as it might cause potential issues during stack updates or deployments.

[ronakseth96]

I am closing this issue as the object deletion was successful. I will update the other issue regarding the CF stack update.