ECS Object Storage Access Denied Object-Level vs Bucket-Level ACL Ownership Mismatch
Article ID: 442924
Updated On:
Products
Issue/Introduction
After migrating objects from one Dell EMC ECS bucket to another and binding applications to a new ECS service instance, applications receive Access Denied errors when attempting to read or write objects in the new bucket despite the binding user having bucket-level ACL access.
The error appears in application logs as follows:
Amazon.S3.AmazonS3Exception: Access Denied
The application is running, the service binding is present in VCAP_SERVICES with valid credentials, and the binding user has bucket-level ACL permissions. However all object-level operations return Access Denied
Environment
ECS Service Broker version 2.3.3 (final release EOL May 25, 2025)
Cause
ECS enforces access control at two independent layers:
- Bucket-level ACL
- Controls which users can perform operations against the bucket itself (list, create objects, delete objects). This is managed by the ECS Service Broker during cf bind-service. The broker creates a binding-specific IAM user (pcfpre-<binding-guid>) and grants it ACL permissions on the bucket.
- Object-level ACL
- Controls which users can access individual objects stored inside the bucket. Object-level ACLs are set independently of bucket-level ACLs and are not inherited from bucket permissions.
- When objects are copied from one ECS bucket to another using standard S3 copy operations, the objects retain their original owner and object-level ACLs from the source bucket. The original owner is the binding user from the source bucket (pcfpre-<original-binding-guid>), which is a different user from the binding user of the new bucket (pcfpre-<new-binding-guid>).
The result is that the new binding user has bucket-level ACL access but cannot read or write any of the migrated objects because those objects have object-level ACLs that only grant access to the original source bucket's binding user.
Resolution
Apply a bucket policy on the bucket that explicitly grants the new binding users full access to all objects. This overrides the object-level ACL restrictions inherited from the source bucket without requiring re-migration or individual object ACL updates.
Navigate to the destination bucket in the ECS Management UI and apply the following bucket policy, substituting the actual binding user identities obtained from cf env <app-name> under the ecs-bucket credentials accessKey field:
{
"Version": "2012-10-17",
"Id": "DefaultPCFBucketPolicy",
"Statement": [
{
"Action": [
"s3:*"
],
"Resource": [
"pcfpre-bucket-name"
],
"Effect": "Allow",
"Principal": "pcfpre-binding-guid",
"Sid": "ecs-cf-broker-sid-guid"
},
{
"Action": [
"s3:*"
],
"Resource": [
"pcfpre-bucket-name"
],
"Effect": "Allow",
"Principal": "pcfpre-binding-guid",
"Sid": "ecs-cf-broker-sid-guid"
}
{
"Sid": "AllowUserReadAccess",
"Effect": "Allow",
"Principal": {
"AWS": "pcfpre-binding-guid"
},
"Action": [
"s3:GetObject"
],
"Resource": [
"pcfpre-bucket-name/*"
]
}
]
}
Feedback
