Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

ECS 3.6.2 Data Access Guide

PDF

S3 and Swift Interoperability

S3 and Swift protocols can interoperate so that S3 applications can access objects in Swift buckets and Swift applications can access objects in S3 buckets.

When considering whether objects created using the S3 head is accessible using the Swift head, and conversely, you should first consider whether users can access the bucket (called a container in Swift). A bucket is assigned a bucket type (S3 or Swift, for example) based on the ECS head that created it. The object users must have appropriate permissions for the type of bucket, for an application to access both Swift and S3 buckets. Consider giving the permissions, because of the way in which permissions are determined for Swift and S3 buckets is different.

NOTE: S3 and Swift interoperability is not compatible with the use of bucket policies. Bucket policies apply only to bucket access using the S3 head and are not enforced when accessing a bucket using the Swift API.

In ECS, the same object user name can be given both S3 and Swift credentials. So, as far as ECS is concerned, a user who is called john who authenticates as a Swift user, can then access any S3 resources that john is allowed to access.

Access to a resource is determined either by being the bucket owner, or by being assigned permission on the bucket using ACLs. When a S3 user creates a bucket, for example, that bucket is owned by the S3 user name. That user has full permissions on the bucket, and a Swift user with the same name similarly has full permissions on the bucket.

Where you want users other than the owner to be able to access a bucket, permissions can be assigned using ACLs. Access to Swift containers can be granted using group ACLs (Custom Group ACLs, in ECS), and the Swift head performs a check on group membership before checking group ACL permissions. Swift containers add the admin group implicitly, and any user that is a member of the admin group (an admin user) can access any other admin user’s containers. Only admin users have permissions to create, delete, and list-all containers. The admin user’s permissions only apply to the namespace to which the user belongs. Access to S3 buckets depends on user permissions (User ACLs), not group permissions. To determine access to a bucket, the S3 head checks if the user has ACL permissions on the bucket. See the illustration in the following illustration.

Figure 1. S3 user access checks
S3 User access checks

Swift uses groups to enable access to resources, for an S3 user to be able to access a Swift container. The S3 user must be assigned to a Swift group, either the admin group, or a group that has been given Custom Group ACLs on the container.

In summary, one of the following conditions should be met for access to S3 buckets:

  • The Swift or S3 user must be the bucket owner.
  • The Swift or S3 user must have been added to the user ACL for the bucket.

One of the following conditions should be met for access to Swift containers:

  • The S3 or Swift user must be the container owner.
  • The S3 user must also be a Swift user and must have been added to a Swift group. The Swift group must be added as a custom group, unless the user is a member of the Swift admin group, which is added automatically to the custom groups.
  • The Swift user must have been added to a group ACL for the container, or the user must be in the Swift admin group, which is added automatically to the custom groups.
NOTE:

Reading a Swift DLO object through the S3 API does not work. The request follows a generic code path for the read without acknowledging the presence of the X-Object-Manifest metadata key, to stitch the object back from its individual paths.

NOTE:

For an MPU upload, the Swift list parts operation fails since it does not understand the '?uploadId=<uploadId>' sub-resource.


Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\