The S3 API commands below are supported by Vail. For any commands not listed below, they are not supported by Vail and a 404 response will be returned.
Request options not supported across all commands:
Vail currently does not support AWS tagging.
- CopyObject — not supported: x-amz-website-redirect-location
- CreateBucket — not supported: CreateBucketConfiguration
- CreateMultipartUpload — not supported: server-side-encryption-aws-kms-key-id, server-side-encryption-context, tagging, x-amz-website-redirect-location
- DeleteObject — not supported: mfa
- DeleteObjects —not supported: mfa
- GetObject — not supported: x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key, x-amz-server-side-encryption-customer-key-MD5
- ListObjectsV2 — note: AWS returns an error if a continuation token is passed in that was not returned by a previous ListObjectsV2 request. Vail may use an arbitrary starting position in this situation.
- PutBucketVersioning — not supported: mfa
- PutObject — not supported: server-side-encryption-aws-kms-key-id, server-side-encryption-context, tagging, x-amz-website-redirect-location
Vail will typically return errors when AWS returns errors, but we do not guarantee that Vail will return the same error code or message when multiple are valid for a given situation.
Vail supports the following IAM operations.
Vail currently does not support the AssumeRole operation.
Virtual Hosting of Buckets
Vail supports only AWS Signature Version 4 Authentication.
HTTPS and HTTP
Vail supports communication via https/SSL and http. Be sure you are using the correct port number as specified in Vail. Non-standard ports (other than 80 or 443) may be used as configured by the customer. https/SSL is recommended in order to improve security. A signed SSL certificate can be installed in Vail endpoint.
Vail supports policies and ACLs for controlling access to S3 buckets and objects. Buckets and objects are owned by an account, and the owning account has full access. Bucket policies can grant access directly to IAM users and groups, or can grant access to accounts. IAM user and group policies delegate the permissions of an account to individual users and groups within that account. ACLs grant access to non-owner accounts, AWS services, and the world at large (but not to individual users). Because policies provide better control, the use of ACLs is generally discouraged.
Policies in AWS are defined in JSON. Policies grant permissions for principals to access resources. Permissions are strings like “s3:PutObject” that refer to specific rights. A principal is the entity requesting the permission, like an IAM user or group, or an AWS service. The resource is an entity the permission will operate on, like a bucket or an object. An S3 policy document describes this in more detail.
The most direct method of controlling access is using a bucket policy. A bucket policy may be defined on a bucket to grant or deny access. The bucket policy can specify access for IAM users or various other principals. Bucket and object ACLs have no effect on bucket policies. A bucket policy can give access to IAM users in a different account without requiring any additional permissions to be configured.
AWS does not allow IAM groups to be specified in a bucket policy. It’s not clear why this limitation exists. Vail allows IAM groups to be specified in a bucket policy, which greatly simplifies granting access to users in a different account. Note that if you grant access to a group in a different account, you no longer have control over what individual users get access (because the owner of the account controls what users are in that group).
Policies associated with IAM users and groups can be used to delegate account level access to S3 resources granted through an ACL. Individual buckets can be specified in those policies, and paths or portions of bucket names can be used to do things like grant access to any bucket starting with “dev”. The owning account has full permissions. Any additional account must be granted access explicitly, either through a bucket policy or an ACL. If an account is granted access, that account’s IAM user and group policies are checked to see if individual users and groups are granted access. Note that a user or group policy that specifies a Deny action will apply even if the account hasn’t explicitly been granted access.