In the Oracle Cloud Infrastructure Object Storage service, a bucket is a container for storing objects in a compartment within an Object Storage namespace. A bucket is associated with a single compartment. The compartment has policies that indicate what actions you can perform on a bucket and all the objects in the bucket.
You cannot nest buckets—a bucket cannot contain other buckets.
Required IAM Policy
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
If you are new to policies, see Getting Started with Policies and Common Policies.
- The policy Let Object Storage admins manage buckets and objects lets the specified group do everything with buckets and the associated objects.
- If you must write more restrictive policies for buckets, see Details for Object Storage, Archive Storage, and Data Transfer.
Security Zones ensure that your cloud resources comply with Oracle security principles. If any operation on a resource in a security zone compartment violates a policy for that security zone, then the operation is denied.
The following security zone policies affect your ability to manage buckets:
- You can't move a bucket from a security zone to a compartment that isn't in the same security zone, because it might be less secure. For details, see Restrict Resource Movement.
- Buckets in a security zone must be private.
- Buckets in a security zone must use customer-managed master encryption keys in the Vault service.
Pre-authenticated requests provide a way to let you access a bucket or an object without having your own credentials. For example, you can create a request that lets you upload backups to a bucket without owning API keys. See Using Pre-Authenticated Requests for details.
You can enable object versioning to retain previous versions of objects. Object versioning lets you view, retrieve, and recover previous versions of objects and provides protection against accidental or malicious object overwrite or deletion. For information about this feature, see Using Object Versioning.
Object Lifecycle Policies
Using object lifecycle policies applied at the bucket level, you can automatically manage the archiving and deletion of objects according to a pre-defined schedule. For information about this feature, see Using Object Lifecycle Management.
You can apply retention rules at the bucket level to provide immutable object storage options for data written to Object Storage for governance, regulatory compliance, and legal requirements. For information about this feature, see Using Retention Rules to Preserve Data.
Using a replication policy for a bucket, you can automatically replicate the objects in one Object Storage bucket to another bucket in the same region or a different region. For information about this feature, see Using Replication.
Object Storage currently supports adding tags to buckets.
You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.
For information about monitoring buckets, see Object Storage Metrics.
A usage report is a comma-separated value (CSV) file that can be used to get a detailed breakdown of resources in Oracle Cloud Infrastructure for audit or invoice reconciliation. A usage report is generated daily and stored in an Object Storage bucket. For more information, see Cost and Usage Reports Overview and Accessing Cost and Usage Reports.
Creating Automation for Buckets and Objects Using the Events Service
Buckets emit events for bucket state changes by default. Events for objects are handled differently than other resources. Objects do not emit events by default. Use the Console, CLI, or API to enable a bucket to emit events for object state changes. You can enable events for object state changes during or after bucket creation.
Bucket names are system generated by default, but you can overwrite the default with a name you specify.
System-Generated Bucket Names
When a bucket is created, the system generates a default name for that bucket, for example bucket-20190306-1359. This bucket name identifies the current year, month, and day that the bucket was created. You can use that system-generated name for your new bucket or you can specify a different name.
User-Specified Bucket Names
If you change this default bucket name or the name of any bucket, observe the following:
- Make the name unique within your tenancy's Object Storage namespace.
- Use from 1 to 256 characters.
- Valid characters are letters (upper or lower case), numbers, hyphens,
underscores, and periods. Important
Bucket names and object names are case-sensitive. Object Storage handles accounts-payable and Accounts-Payable as separate buckets.
- Avoid entering confidential information.
Default Storage Tiers
When you create a bucket, you decide which default storage tier is appropriate for storing the objects:
- Use the Standard tier for data to which you need fast, immediate, and frequent access.
- Use the Archive tier for data to which you seldom or rarely access, but that must be retained and preserved for long periods of time.
The storage tier property is then assigned to each object that you upload to a bucket.
For more information, see Understanding Storage Tiers. To automate the movement of data to the most cost effective tier, see Enabling Auto-Tiering.
You cannot change the default storage tier of a bucket after creation.
When you create a bucket, the bucket is considered a private bucket and the access to the bucket and bucket contents requires authentication and authorization. However, Object Storage supports anonymous, unauthenticated access to a bucket that is not in a security zone. You make a bucket public by enabling read access to the bucket.
Carefully assess the business requirement for public access to a bucket. When you enable anonymous access to a bucket, any user can obtain object metadata, download bucket objects, and optionally list bucket contents. We recommend using pre-authenticated requests instead of public buckets. Pre-authenticated requests support more authorization, expiry, and scoping capabilities not possible with public buckets. See Using Pre-Authenticated Requests for details.
The following permissions are required to configure a public bucket:
- To enable public access when creating a bucket, use permission
- To enable public access for an existing bucket, use permission
When creating a public bucket, you have the following options:
- You can configure the access to allow listing and downloading objects. List and download access is the default.
- You can configure the access to allow downloading objects only. A user would not be able to list bucket contents.
Scope and Constraints
Understand the following scope and constraints regarding public access:
- Buckets in a security zone can't be public.
- Changing the type of access is bi-directional. You can change a bucket's access from public to private or from private to public.
- Changing the type of access doesn't affect existing pre-authenticated requests. Existing pre-authenticated requests still work.
You can enable anonymous public access for new or existing buckets using the Console, CLI, or an SDK to access the API.