Bucket Policy is a JSON-based access policy language that allows you to create fine-grained permissions for your Object Storage buckets. With Bucket Policy, you can specify which users or services can access specific objects and what actions users can perform.

Use cases

• Use this feature to grant access to a specific user or group to only a subset of the objects in your bucket.

• Restrict access to certain operations on your bucket, for example, list objects or remove object lock.

• Using Bucket Policy, you can grant access based on conditions, such as the IP address of the user.

• Create fine-grained access control rules to allow a user to put objects to a specific prefix in your bucket, but not to get objects from that prefix.

Bucket Policy alternatives

• Use Bucket ACL and Object ACL instead of Bucket Policy if you need to define different sets of permissions such as READ, WRITE, or FULL CONTROL to many objects.

• Use Share Objects with Pre-Signed URLs to grant temporary access to authorized users for a specified period, after which the URL and the access to the object expire.

Policy format

A JSON-formatted bucket policy contains one or more policy statements. Within a policy's statement blocks, IONOS Object Storage support for policy statement elements and their values is as follows:

• Id (optional): A unique identifier for the policy. Example: SamplePolicyID.

• Version (required): Specifies the policy language version. The current version is 2012-10-17.

• Statement (required): An array of individual statements, each specifying a permission.

• Sid (optional): Custom string identifying the statement. For example, Delegate certain actions to another user.

• Action (required): Specifies the action(s) that are allowed or denied by the statement. See the Action section in the Request for the supported values. Example: s3:GetObject for allowing read access to objects.

• Effect (required): Specifies the effect of the statement. Possible values: Allow, Deny.

• Resource (required): Must be one of the following:

  • arn:aws:s3:::<bucketName> – For bucket actions (such as s3:ListBucket) and bucket subresource actions (such as s3:GetBucketAcl).

  • arn:aws:s3:::<bucketName>/* or arn:aws:s3:::<bucketName>/<objectName> – For object actions (such as s3:PutObject).

• Condition (optional): Specifies conditions for when the statement is in effect. See the Condition section in the Request for the supported values. Example: {"aws:SourceIp": "123.123.123.0/24"} restricts access to the specified IP range. For the list of supported bucket and object actions and condition values, see Supported Action Values.

• Principal (required): Specifies the user, account, service, or other entity to which the statement applies. For information specific to the bucket types, see the following:

Request

{

 "Id": "Delegate certain actions to another user",
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "Delegate certain actions to another user",
     "Action": [
       "s3:ListBucket",
       "s3:PutObject",
       "s3:GetObject"
     ],
     "Effect": "Allow",
     "Resource": [
       "arn:aws:s3:::my-bucket",
       "arn:aws:s3:::my-bucket/*"
     ],
     "Condition": {
       "IpAddress": {
         "aws:SourceIp": [
           "123.123.123.123/32"
         ]
       }
     },
     "Principal": {
        "AWS": "arn:aws:iam:::user/31000000:9acd8251-2857-410e-b1fd-ca86462bdcec"
     }
   }
 ]
}

{
  "Id": "Delegate certain actions to another user",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Delegate certain actions to another user",
      "Action": [
        "s3:ListBucket",
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "123.123.123.123/32"
          ]
        }
      },
      "Principal": {
        "CanonicalUser": "783fa49356820b211a4283526fe24343"
      }
    }
  ]
}

For more information, see Bucket Policy Examples and supported bucket and object actions and condition values.

DCD

Apply a Bucket Policy

You can apply Bucket Policy using the DCD by following these steps:

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the required bucket and click the Bucket settings.

4. Go to the Bucket Policy setting under the Access management section and click Edit.

5. Copy and paste the provided JSON policy by replacing BUCKET_NAME and USER_ID with the actual values. Depending on the Bucket Types, replace the USER_ID as follows:

• Use Contract user ID for contract-owned buckets.

• Use Canonical user ID for user-owned buckets.

6. Click Save.

{

 "Id": "Share access to the bucket",
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "Share access to the bucket",
     "Action": [
       "s3:*"
     ],
     "Effect": "Allow",
     "Resource": [
       "arn:aws:s3:::BUCKET_NAME",
       "arn:aws:s3:::BUCKET_NAME/*"
     ],
     "Principal": {
       "AWS": "arn:aws:iam:::user/31000000:9acd8251-2857-410e-b1fd-ca86462bdcec"
     }
   }
 ]

}

{
  "Id": "Share access to the bucket",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Share access to the bucket",
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::BUCKET_NAME",
        "arn:aws:s3:::BUCKET_NAME/*"
      ],
      "Principal": {
        "CanonicalUser": "CANONICAL_USER_ID"
      }
    }
  ]
}

Delete a Bucket Policy

You can delete a Bucket Policy at any time using the Bucket Policy section in the Bucket settings and click Delete.

IONOS Object Storage API

Use the API to manage the Bucket Policy configuration.

CLI

Use the CLI to manage Bucket Policy.

Related feature

Block Public Access

If you have defined a bucket policy to grant public access, activating the Block Public Access feature will revoke these permissions, ensuring your data remains private. This feature is invaluable in scenarios where ensuring data privacy is paramount, or when you want to enforce a blanket no-public-access rule, irrespective of Bucket Policy settings. Currently, Block Public Access is available only via the IONOS Object Storage API.

Replication allows you to create and manage replicas of your data across Endpoints.

Use cases

• Disaster Recovery: In the event of a regional outage, your data remains accessible from another region.

• Compliance Requirements: Meet legal and compliance mandates by storing copies of data in different geographical locations.

• Latency Reduction: Serve data from the nearest region to your users, minimizing latency and improving performance.

• Data Aggregation: Aggregate logs or other data from multiple buckets to a central bucket, where they can be analyzed.

How Replication works

• Only objects directly uploaded into a bucket by a client application are replicated.

• Replication traffic, including cross-region replication, is not counted towards data usage; thus, Object Storage offers free data transfer.

• Objects are not replicated if they are themselves replicas from another source bucket.

• In the case of an object deletion request specifying the object version, the object version is deleted from the source bucket but not from the destination bucket.

• If an object deletion request does not specify the object version, the deletion marker added to the source bucket is replicated to the destination bucket.

Bi-directional Replication

With bi-directional replication, you can configure two buckets to replicate each other. For example, objects directly uploaded into bucket1 can be copied to bucket2, and objects directly uploaded into bucket2 are replicated to bucket1. It is possible to replicate objects uploaded from one bucket into another bucket. Still, objects will not be copied back into the source bucket, thus avoiding an endless replication loop.

Manage Replication

You can manage Replication using the DCD, API, and CLI.

DCD

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the Buckets list, choose the bucket for which the Replication rule must be added and click Bucket settings.

3. Go to the Replication setting under the Data management section and click Add a rule.

4. Enter a Rule name.

5. Choose the Replication scope. You can either apply the replication rule to all objects in the bucket or limit to objects filtered by prefix.

6. Browse Object Storage to choose the Destination bucket.

7. Click Add a rule.

IONOS Object Storage API

Use the API to manage the replication of objects.

CLI tool

Use the CLI to manage Replication.

Limitations

• Replication configuration is possible only if Versioning is enabled for both source and destination buckets participating in Replication.

• Each Replication rule serves to identify a specific prefix for replication, and it must be unique.

• Version 2 of the AWS S3 specification for Replication configuration XML is not supported. Only the version 1 is currently supported.

• The following options are not supported: DeleteMarkerReplication, EncryptionConfiguration, ReplicationTime, ExistingObjectReplication, Filter (use Prefix instead), Priority, SourceSelectionCriteria, AccessControlTranslation, Account, and Metrics.

• Replication is not possible in the following cases:

  • A source bucket that has Object Lock enabled. However, an Object Lock enabled bucket can be a destination bucket for Replication.

  • A source bucket that has Lifecycle for auto-tiering enabled.

  • Objects uploaded before enabling Replication.

  • Objects encrypted by the SSE-C method.

  • Objects that are themselves replicas from other source buckets. For example, if you configure bucket1 to replicate to bucket2, and you configure bucket2 to copy to bucket3, then an object that you upload to bucket1 will get replicated to bucket2 but will not get reproduced from there on to bucket3. Only objects you directly upload into bucket2 will be copied to bucket3.

Related feature

Versioning

Versioning allows you to keep multiple versions of the same object and it must be set up for both the source and the target bucket before enabling the replication.

Manage your Object Storage buckets, objects, and their access permissions effectively using the data management, access management, and public access settings.

An Access Control List (ACL) is a mechanism that defines who can access or modify specific resources, such as buckets and objects. ACLs allow resource owners to grant varying levels of permissions such as read, write, or full control to different users or groups.

Manage ACLs

You can use ACLs to make a bucket or object public or to share access with certain authorized users by setting the right permissions. IONOS Object Storage offers the following ACL management methods:

The feature functions in the IONOS Object Storage regions and supports both contract-owned buckets and user-owned buckets.

ACL alternatives

Use instead of ACLs which offers the following additional capabilities:

• Manage access to prefixes like /folder/* or *.jpg.

• Use conditions to grant access, for example, IP address.

• Allow or deny certain actions like listing the object list.

We recommend using instead of ACL for granting temporary access to authorized users for a specified period, after which the URL expires.

Related feature

Block Public Access

Versioning allows you to keep multiple versions of the same object. Upon enabling Versioning for your bucket, each version of an object is considered a separate entity contributing to your storage space usage. Every version represents the full object, not just the differences from its predecessor. This aspect will be evident in your usage reports and will influence your usage-based billing.

Use cases

• Data Recovery: Versioning can be used as a backup solution for your data. If you accidentally overwrite or delete an object, you can restore it to a previous version.

• Tracking Changes: Versioning can be used to track changes to your data over time. This can be useful for debugging purposes or auditing changes to your data.

Version states

Buckets can exist in one of three states:

• Unversioned: Represents the default state. No versioning is applied to objects in a bucket.

• Versioning - enabled: In this state, each object version is preserved.

• Versioning - disabled: No new versions are created, but existing versions are retained.

Objects residing in your bucket before the activation of versioning possess a version ID of null. Once versioning is enabled, it cannot be disabled but can be suspended. During suspension:

• New object versions are not created.

• Existing object versions are retained.

You can resume Versioning anytime, with new versions being created henceforth.

Version IDs

Upon enabling Versioning for a bucket, every object version is assigned a unique, immutable Version ID, serving as a reliable reference for different object versions. New object versions are generated exclusively through PUT operations, with actions such as COP entailing a PUT operation, thus spawning a new version.

Notably, a new Version ID is allocated for each version, even if the object content remains unaltered. Objects residing in the bucket before the activation of versioning bear a Version ID of null.

When an object is deleted, all its versions persist in the bucket, while Object Storage introduces a delete marker, which is also assigned its Version ID.

Manage Versioning

You can manage Versioning using the DCD, API, and CLI.

DCD

Enable or disable Versioning

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket to which you want to manage Versioning.

4. Click Bucket settings and go to the Versioning setting under the Data management section.

5. In the Versioning, click Enable to have object versions. On choosing the Disable option, it suspends object versioning but preserves existing object versions.

Manage object versions

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either to Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket in which the desired object exists.

4. Click the object name within the bucket listing.

5. Navigate to the object's Versions tab by clicking the object name or clicking the three dots against the object name.

6. Copy Version IDs or download non-current versions of the object. You can also select and delete non-current object versions.

IONOS Object Storage API

CLI

Limitations

• For Bucket Replication to function correctly, Versioning must be enabled.

Related feature

Lifecycle Management

You can manage ACL permission for buckets through the DCD, IONOS Object Storage API, or the CLI.

ACL permission for buckets

The following table shows the ACL permissions that you can configure for buckets in the IONOS Object Storage:

DCD

To manage ACL for buckets using the DCD, follow these steps:

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket to which you want to manage the ACL.

4. Click Bucket settings and choose the Access Control List (ACL) under the Access management section.

6. Click Save to apply ACL permissions and add the grantee to the bucket.

IONOS Object Storage API

CLI

Object Lock is a feature that enables you to apply WORM protection to objects, preventing them from being deleted or modified for a specified duration. It provides robust, programmable safeguards for storing critical data that must remain immutable. Enabling Object Lock automatically enables bucket .

Use cases

• Data Preservation: Protects critical data from accidental or malicious alteration and deletion, ensuring integrity and consistency.

• Regulatory Compliance: Aligns with European regulations such as GDPR, Markets in Financial Instruments Directive (MiFID) II, and the Electronic ID and Trust Services (eIDAS) regulation, maintaining records in an unalterable state.

• Legal Holds and Audits: Facilitates legal holds and audits that offer immutable data preservation, providing a transparent data record. It also offers an auditable trail of when and why the data is placed on hold, which is essential for legal and regulatory audits.

Modes

Object lock can be applied in two different modes:

• Governance: Allows specific users with special permissions to override the lock settings. Ideal for flexible control.

• Compliance: Enforces a strict lock without any possibility of an override. Suited for regulatory and legal mandates.

These two lock modes require configuring the duration for which the object will remain locked. The period can range from days to years, depending on the object's compliance needs.

The Retention period refers to the duration for which the objects stored in a particular Object Storage bucket are protected from deletion or modification. You can set the retention period to a maximum of 365 days via the DCD. To set a longer retention period, use the .

The retention configuration can be modified or removed for the objects under Governance mode by including a specific header variable in the API request. However, for objects in Compliance mode, reducing the retention period or removing the retention configuration is not possible.

However, the delete markers on the objects are not subject to protection from deletion, irrespective of any retention period or legal hold on the underlying object. Deleting the delete markers restores the previous version of the objects.

Legal Hold

An additional setting called Legal Hold can place a hold on an object, enforceable without specifying a retention period. It could be applied both to objects with or without Object Lock. The Legal Hold will continue to be applied till manual removal even if the object’s retention period for Governance or compliance mode is over.

Manage Object Lock

When a bucket is created with Object Lock enabled, you can set up Object Lock configurations. These configurations determine the default mode and retention period for newly uploaded objects. Alternatively, Object Lock settings can be explicitly defined for each object during its creation, overriding the bucket's default settings.

DCD

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

3. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you created.

4. From the Buckets list, choose the bucket for which the Object Lock is enabled.

5. Click Bucket settings and go to the Object Lock setting under the Data management section.

6. Modify the Object Lock mode applied on the bucket and the Retention period as needed.

7. Click SAVE.

IONOS Object Storage API

CLI tool

Limitations

The following are a few limitations to consider while using Object Lock:

• Once the Object Lock is enabled during bucket creation, both Object Lock and Versioning cannot be disabled afterward.

• When you place or modify an Object Lock, updating the object version's metadata does not overwrite the object version or change its Last-Modified timestamp.

• A bucket with Object Lock enabled cannot be chosen as a source for replication or tiering, but it could be a destination for replication or tiering.

• In the Compliance mode, an object is immutable until its retention date has passed. It is not possible to disable this mode for the object or shorten the retention period. This setting could not be changed either by the bucket owner or IONOS.

You can manage ACL permission for objects through the DCD, IONOS Object Storage API, or the CLI.

ACL permission for objects

The following table shows the ACL permissions that you can configure for objects in a bucket in the IONOS Object Storage:

These permissions are applied at individual object levels offering a high granularity in access control.

DCD

To manage ACL for objects using the DCD, follow these steps:

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets, depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket under which the object ACL to be modified exists.

4. From the Objects list, choose the object for which ACL permissions must be modified.

5. From the Object Settings, go to the Access Control List (ACL).

7. Click Save to apply ACL permissions and add the grantee to the object.

IONOS Object Storage API

CLI

Following are a few examples of common use cases and their corresponding bucket policy configurations.

Grant full control of the bucket to other users

To grant full control over a contract-owned bucket or a user-owned bucket and its objects to other IONOS Object Storage users:

Grant read-only access to a specific prefix

Public read access

To allow read access to certain objects within a contract-owned bucket or a user-owned bucket while keeping other objects private:

Restrict access to specific IP addresses

To restrict all users from performing any S3 operations within the designated bucket type, unless the request is initiated from the specified range of IP addresses:

Lifecycle management allows you to automate the deletion of objects and their versions to optimize costs and adhere to compliance requirements.

The Lifecycle comprises rules with actions applied to objects within a bucket. These policies help automate processes that manage the lifecycle of your data.

Use cases

• Object Expiration: Automatically deletes objects no longer needed after a certain period, such as temporary files, logs, or other transient data. It helps to declutter the storage and reduce costs.

• Regulatory Compliance: Assists in meeting legal and compliance requirements by deleting objects according to the defined Lifecycle rules.

• Version Control: Manages multiple versions of objects by automatically deleting the non-current object versions and saves storage costs.

• Temporary Storage: Stores data generated from batch processing or other workloads and deletes these provisional data when no longer needed using the object expiration Lifecycle actions.

Lifecycle actions

A Lifecycle rule supports the following actions:

• Expire current versions.

• Permanently delete noncurrent versions of objects.

• Delete expired object delete markers.

• Delete incomplete multipart uploads.

Expire current versions

With this action, you can specify a period after which the object's current version must expire. Depending on whether the Versioning is enabled for a bucket or not, the action Expire current versions of the object impacts in the following ways:

• If the Versioning is enabled for the bucket, then the expiration of the current version of an object does not result in the deletion of the object data from the storage. Instead, when the object's current version reaches its expiration date, a "delete marker" is created for this object and retained as its "current version"; the object data transitions to a non-current object version.

• If the Versioning is not enabled for the bucket, then the current versions are the only versions of objects in your bucket. When the object reaches its expiration date, it is permanently deleted from the storage.

When the Expire current versions action is set for a bucket that uses Versioning, the system automatically deletes the expired delete markers as part of the lifecycle processing. An expired delete marker is a delete marker for which there is no corresponding object data because all non-current versions of the object have been deleted. This functionality aids in maintaining a clean and organized bucket and retains only necessary data.

Permanently delete non-current version of objects

This action is applicable only if the bucket uses Versioning. Permanently deleting non-current versions of objects takes place after the specified retention period, and it helps to ensure the removal of outdated versions of objects from the storage.

A non-current object version refers to those that are superseded by a newer object version or a delete marker. When a non-current version of an object reaches its scheduled expiration, it is permanently deleted from the storage. The expiration scheduling for non-current versions of objects is based on the number of days since the objects became non-current, which is the number of days since being superseded by a newer version or a "delete marker."

If the bucket has Object Lock enabled, then the non-current object versions are not deleted before their defined retention period is completed. Suppose the expiration date of a non-current object version (based on your configured expiration schedule) comes before the end of the object version's lock period, then the Object Lock setting overpowers. The system retains the non-current object version until the end of its lock period. Shortly after the lock period concludes, the system automatically deletes the non-current object version, ensuring adherence to expiration and retention policies.

Delete expired objects delete markers

However, if all older versions subsequently expire (through the execution of the expiration rule for non-current versions), an orphaned delete marker remains. With the Delete expired object delete markers action, you enable the system to automatically remove a delete marker after a few hours of all the older object versions have expired or been deleted.

Delete incomplete multi-part uploads

Manage Lifecycle

You can manage the Lifecycle using the DCD, API, and CLI.

DCD

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket to which you want to perform Lifecycle Management.

4. Click Bucket settings, go to the Lifecycle setting under the Data management section and click Add a rule.

5. Enter the following details to configure the Lifecycle rule:

• Lifecycle Rule name: Enter a name to identify the rule uniquely.

• Set Rule Scope: Choose whether to apply the Lifecycle rule to all objects in the bucket or limit to objects filtered by the prefix. The prefix is subject to a single Lifecycle rule.

• Select an action: Choose one or more from the following Lifecycle actions to apply to the objects in the bucket:

  • Expire current versions: You can choose to enter the number of days after object creation should the current object version expire or select a date from the calendar shown, after which the current object version must expire. The rule application varies depending on whether the bucket is versioned or not.

  • Permanently delete noncurrent versions of objects: Mention the number of days after the object version becomes non-current should it be permanently deleted.

  • Delete expired object delete markers: Select this action to remove all object delete markers and improve performance. You cannot apply this action if the Expire current versions action is selected.

  • Delete incomplete multipart uploads: Mention the number of days after upload initiation should the incomplete multipart uploads be deleted.

6. Click Save.

IONOS Object Storage API

CLI tool

Limitations

• Currently, IONOS Object Storage only supports Standard storage class. You cannot use lifecycle rules to transition objects to another storage class.

• A maximum of 1,000 rules can be set in the Lifecycle configuration.

• Multiple Lifecycle rules can be created for a bucket, each applying to a different object prefix. However, more than one Lifecycle rule cannot be set for the same object prefix.

• If the bucket uses Object Lock, non-current object versions cannot be deleted before the completion of their defined retention period.

• The NewerNoncurrentVersions setting is not supported for the NoncurrentVersionExpiration option.

Related feature

Versioning

Logging in IONOS Object Storage enables the tracking and storage of requests made to your bucket. When you enable Logging, Object Storage automatically records access requests, such as the requester, bucket name, request time, request action, response status, and error codes, if any. By default, Logging is disabled for a bucket.

Use cases

• Security Monitoring: Tracks access patterns and identifies unauthorized or suspicious access to your data. In the event of a security breach, logs provide vital information for investigating the incident, such as IP addresses, request times, and the actions that were performed.

• Auditing: Many industries require compliance with specific regulatory standards that mandate the monitoring and logging of access to data. Logging facilitates compliance with regulations like HIPAA, GDPR, or SOX by providing a detailed record of who accessed what data and when.

• Troubleshooting: If there are issues with how applications are accessing your Object Storage data, logs can provide detailed information to help diagnose and resolve these issues. Logs show errors and the context in which they occurred, aiding in quick troubleshooting.

Manage Logging

You can manage Logging using the DCD, API, and CLI.

DCD

Activate Logging

To activate Logging, follow these steps:

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the Buckets list, choose the bucket and click Bucket settings.

3. Go to the Logging setting under the Access management section and click Browse Object Storage to select the destination bucket in the same region to store logs.

4. (Optional) Specify the prefix for log storage, providing flexibility in organizing and accessing your log data. If no prefix is entered, the log file name is derived from its time stamp alone.

5. Click Save.

Deactivate Logging

You can modify or deactivate Logging at any time with no effect on existing log files. Log files are handled like any other object. Using the Logging section in the Bucket settings, you can click Disable Logging to stop collecting log data for a bucket.

Grant access permission for Logging

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the Buckets list, choose the bucket for which the logging must be enabled.

3. Click Bucket settings and go to the Access Control List (ACL).

4. For Logging, select the OBJECTS:WRITE and BUCKET ACL:READ checkboxes.

5. Click Save.

IONOS Object Storage API

CLI

Limitations

Logs can only be stored in the same-region buckets.

Related feature

Lifecycle Management

Static Website Hosting enables the hosting of static content, including HTML, CSS, JavaScript, and images, directly, eliminating the need for an external web server. You can specify both an index page and an error page. Additionally, there is an option to link a custom domain.

Depending on the region of your Object Storage bucket, the static website URL varies. For more information on the static website endpoint, see .

Use cases

• Static Content Hosting: Directly serve HTML, CSS, JavaScript, and media files statically on a website.

• Publish Landing Pages: Host promotional or event-specific landing pages with high availability.

• Documentation Sites: Host product documentation or manuals with easy access to the users.

Manage Static Website Hosting

You can manage Versioning using the DCD, API, and CLI.

DCD

Enable Static Website Hosting

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket for which you want to manage Static Website Hosting.

4. Click Bucket settings and go to the Static Website Hosting setting under the Public access section.

5. Click Edit and add the following details:

• Index document: Enter the file name that serves as an index document. Example: index.html. An index document is a default webpage that IONOS Object Storage returns upon receiving a request to the root of a website or a subfolder.

• Error document: Enter the file name of the HTML error document that is uploaded to the Object Storage bucket. An error document is a default HTML file with details you want the user to view when an error occurs.

6. Click Enable.

IONOS Object Storage API

CLI

Limitations

Static Website Hosting is unsuitable for hosting websites that require server-side processing, such as PHP and Python.

Cross-origin Resource Sharing (CORS) allows you to specify which domains can make cross-origin requests to your Object Storage. CORS is beneficial when you need to serve resources from your bucket to web applications hosted on different domains.

Use cases

• Cross-Domain Image Serving: Suitable for websites that need to display images stored in the Object Storage buckets on the various domains without encountering cross-domain restrictions.

• Multi-Domain: Supports complex web applications that operate across multiple domains to access and use data stored in the buckets seamlessly.

• Development and Testing Environment: Facilitates the access of development and staging versions of your web applications hosted on different domains to the same Object Storage resources. You can configure the CORS headers on the staging servers to allow requests from the development or testing domains, ensuring seamless testing without running into cross-origin restrictions.

Manage CORS

You can manage CORS using the DCD, API, and CLI.

DCD

1. In the DCD, go to Menu > Storage > IONOS Object Storage.

2. From the drop-down list in the Buckets tab, choose either Show user-owned buckets or Show contract-owned buckets depending on the bucket type you want to view.

3. From the Buckets list, choose the bucket for which the CORS rule must be configured and click Bucket settings.

4. Go to the CORS setting under the Access management section and click Add a rule.

4. Enter the following details to configure the CORS rule:

• Rule name: Enter a name to identify the rule uniquely.

• Allowed origins: Enter the complete domain of the client you want to access your bucket's content from and click Add. The domain should start with a protocol identifier, such as HTTP, and end with a hostname; for example, https://*.example.com. You can add one or more origins.

• Allowed headers (Optional): Specify the non-default headers that your Object Storage bucket must accept from your client and click Add. The CORS automatically takes default headers such as Content-Length and Content-Type.

• Allowed methods: Select the API method checkbox to allow interaction with your Object Storage bucket. You can enable or restrict the following API methods:

  • GET: Fetch the CORS configuration of the bucket.

  • POST: Create a new bucket.

  • PUT: Update the bucket's property or content.

  • HEAD: Retrieve the bucket's metadata.

  • DELETE: Delete a bucket.

• Expose headers (Optional): Specify the headers in the response that you want users to be able to access from their applications and click Add.

• Max age (Optional): Specify the time in seconds for how long a request’s verification is cached. The Object Storage bucket can accept more requests from the same origin while the verification is cached.

5. Click Add a rule.

IONOS Object Storage API

CLI tool