Objects: Buckets, Access Keys, and S3 Compatibility
Buckets, keys, and S3 compatibility
Nutanix Objects runs on AHV and exposes an S3-compatible endpoint. Clients sign requests with an access key ID and a secret access key, typically using Signature V4. A bucket is a namespace for objects. Access is controlled by bucket policies, ACLs, and key permissions. Objects supports standard S3 operations such as bucket create and delete, object PUT and GET, multipart upload, and versioning depending on the release.
Deployment and access
- Deploy Objects from Prism and size worker nodes for capacity and performance.
- Use the TLS endpoint and protect access keys like passwords.
- Rotate or disable compromised keys promptly.
- Bucket policies can grant cross-account or anonymous access; do so only deliberately.
- Objects is not SMB or NFS. Do not expect to mount a bucket as a native file share without a gateway.
Worked example
An application receives 403 SignatureDoesNotMatch. The key exists, but the application may be using the wrong secret, signing for a different endpoint, or suffering clock skew. Verify the endpoint URL, access key ID, secret access key, and time sync. If the error is 404 NoSuchBucket, check the bucket name and endpoint before changing permissions.
Traps
A 403 is usually authentication or signature related, not always a bucket policy issue. An explicit bucket policy deny overrides a valid key. The secret access key is shown only at creation time in many workflows. Do not confuse Objects with Files when troubleshooting a path-style S3 request.
Key points
- Objects provides an S3-compatible API on AHV.
- Access keys use an ID and secret to sign requests.
- Buckets are controlled by policies, ACLs, and key permissions.
- Signature and endpoint mismatches cause 403 errors.
- Objects is object storage, not a native SMB or NFS share.