如何利用日志排查AWS S3 Bucket文件删除权限问题？

Hey there! Let's work through figuring out which principal lacks the necessary delete permissions for your S3 audio files. Here's a step-by-step approach to narrow it down:

• Dig into your S3 access logs for specific details
  Your access logs hold the key clues. Look for log entries where the requestURI includes a DELETE operation and the errorCode shows AccessDenied. Focus on these critical fields:

  • principalId: This will tell you the AWS identity (IAM user, role, etc.) that attempted the delete. It might look like AWS:arn:aws:iam::123456789012:user/parse-server-user or just the plain username for an IAM user.
  • sourceIPAddress: Cross-reference this with your Parse-Server's public IP (if hosted outside AWS) or your EC2 instance's IP (if deployed on AWS) to confirm the request is coming from your app server.

• Verify the Parse-Server's S3 credentials' IAM entity
  Parse-Server usually relies on either an IAM user's access key/secret or an IAM role (if running on EC2/EKS with an instance profile). Check this entity's permissions:

  1. Head to the AWS IAM console, locate the user/role linked to your Parse-Server's S3 configuration.
  2. Review attached policies—make sure there’s a rule explicitly allowing s3:DeleteObject for your target bucket and object path (e.g., arn:aws:s3:::your-audio-bucket/*).
  3. Don’t overlook deny policies—they take precedence over allow rules, so even a single deny statement can block the delete action.

• Check your S3 Bucket Policy
  Sometimes the issue isn’t with the IAM entity’s policies, but the bucket’s own policy. Go to your S3 bucket’s "Permissions" tab, then "Bucket Policy":

  • Confirm there’s no statement denying s3:DeleteObject for the principal you identified in the logs.
  • If you have allow statements, ensure the principal (your Parse-Server’s IAM user/role) is included, and the resource covers the audio files you’re trying to delete.

• Rule out permission boundaries and inline policies
  If your IAM entity has a permission boundary set, double-check that it doesn’t block s3:DeleteObject. Also, review any inline policies attached directly to the entity—these can sometimes have restrictive rules that are easy to miss.

• Test with a temporary targeted policy (carefully!)
  To confirm it’s a permission issue, temporarily attach a policy like this to your Parse-Server’s IAM entity:

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": "s3:DeleteObject",
              "Resource": "arn:aws:s3:::your-audio-bucket/*"
          }
      ]
  }
  

  If the delete works after adding this, you know the original policy was missing the necessary permission. Remember to remove this temporary policy once confirmed, and replace it with a more restrictive one following the principle of least privilege.

内容的提问来源于stack exchange，提问作者Michel