Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Bucket Policy is a JSON-based access policy language that allows you to create fine-grained permissions for your S3 buckets. With Bucket Policy, you can specify which users or services can access specific objects and what actions users can perform.
Note: Granting access to a bucket for another IONOS user does not make the bucket appear in the user's S3 web console due to the S3 protocol's architecture. To access the bucket, the user must utilize other S3 Tools as the granted access does not translate to interface visibility.
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.
Use Bucket ACL instead of Bucket Policy if you need to:
Define permissions in a simple way such as READ, WRITE, or FULL CONTROL.
Apply different sets of permissions to many objects.
Use Share Objects with Pre-Signed URLs for granting temporary access to authorized users for a specified period, after which the URL and the access to the object expires.
A JSON-formatted bucket policy contains one or more policy statements. Within a policy's statement blocks, IONOS S3 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, Statement1 or Only allow access from specific source IPs.
Effect (required): Specifies the effect of the statement. Possible values: Allow, Deny.
Principal (required): Specifies the user, account, service, or other entity to which the statement applies.
* – Statement applies to all users (also known as 'anonymous access').
{"CanonicalUser": "<canonicalUserId>"} – Statement applies to the specified IONOS S3 Object Storage user.
{"CanonicalUser": ["<canonicalUserId>", "<canonicalUserId>",...]} – Statement applies to the specified IONOS S3 Object Storage users.
Action (required): Specifies the action(s) that are allowed or denied by the statement. See section 'Supported Action Values'. Example: s3:GetObject for allowing read access to objects.
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 section 'Supported Condition Values'. Example: {"aws:SourceIp": "123.123.123.0/24"} restricts access to the specified IP range.
You can apply Bucket Policy using the web console by following these steps:
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the required S3 bucket and click the Bucket settings.
3. In the Bucket Policy, click Edit, copy and paste the provided JSON policy, replacing BUCKET_NAME and CANONICAL_USER_ID with the actual values. You can retrieve your Canonical user ID from the Key management section. For more information, see Retrieve User IDs.
4. Click Save.
This action grants the specified user full access to your bucket.
You have the option to restrict actions, define the scope of access, or incorporate conditions into the Bucket Policy for more tailored control.
You can delete a Bucket Policy at any time using the Bucket Policy section in the Bucket settings and click Delete.
Info: Removing a bucket policy is irreversible and it is advised to create a backup policy before deleting it.
Use the Bucket Policy API to manage the Bucket Policy configuration.
Use the CLI to manage Bucket Policy.
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.
Object Lock is a feature that enables you to apply Write-Once-Read-Many (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.
Note: Once a bucket is created without an object lock, you cannot add it later.
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, 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, meeting requirements for transparency and accountability.
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.
For the objects under Governance mode, the retention configuration can be modified or removed 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.
Note: Under Object Lock or Object Hold, permanent deletion of an object's version is not permissible. Instead, a deletion marker is generated for the object, causing IONOS S3 Object Storage to consider that the object has been deleted.
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.
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.
Note: Object Lock configuration can only be enabled during the initial creation of a bucket and cannot be applied to an existing bucket.
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.
Prerequisite: Make sure you are creating a new bucket for which you want to enable Object Lock.
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. Create a new bucket with Object Lock enabled.
3. From the Buckets list, choose the bucket for which Object Lock is enabled and click Bucket settings.
4. Click Object Lock to manage these settings on the bucket.
Result: The object lock is successfully applied on the bucket upon creation.
The following are a few limitations to consider while using Object Lock:
Versioning will be automatically enabled in addition to 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.
Manage your Object Storage buckets, objects and their access permissions effectively by using the data management, access management, and public access settings.
Following are a few examples of common use cases and their corresponding bucket policy configurations.
To grant full control over a bucket and its objects to other IONOS S3 Object Storage users:
To grant read-only access to objects within a specific prefix of a bucket to other IONOS S3 Object Storage users:
To allow read access to certain objects within a bucket while keeping other objects private:
To restrict all users from performing any S3 operations within the designated bucket, unless the request is initiated from the specified range of IP addresses:
You can manage ACL permission for buckets through the web console, IONOS S3 Object Storage API, or the command-line tool.
The following table shows the ACL permissions that you can configure for buckets in the IONOS S3 Object Storage.
Note: For security, granting some of the access permissions such as Public access WRITE, Public access WRITE_ACP, Authenticated users WRITE, Authenticated users WRITE_ACP is possible only through an API Call.
To manage ACL for buckets using the web console, follow these steps:
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket to which you want to access the ACL.
3. Click Bucket settings and choose the Access Control List (ACL) under the Access management section.
6. Click Save to apply the ACL settings to the bucket.
Result: The bucket ACL permissions are successfully applied on the bucket.
Prerequisites:
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket to which you want to add the grantee.
3. Click Bucket settings and choose the Access Control List (ACL) under the Access management section.
5. Add any number of grantees to the bucket by following step 4.
6. Click Save to add the additional grantees with corresponding ACL permissions to the bucket.
Result: The grantees are successfully added to the bucket.
Use the to manage the Object Lock configuration on the specified buckets.
Use the to manage Object Lock.
For more information on bucket policy configurations, see , supported actions and condition values, and .
4. Select the checkboxes against the access permissions to grant at each user level such as bucket owner, public access, authenticated users, and logging. For more information, see .
5. Add grantees to provide additional users with access permission to the bucket. For more information, see .
Make sure the canonical user ID of the grantee is known. To retrieve the ID, see .
The grantee should already exist. If not, create a user and retrieve the Canonical user ID by following the steps in .
4. In the Additional Grantees section, enter the retrieved Canonical user ID of the grantee, select the checkboxes on the ACL permissions to grant, and click Add. For ACL permissions, see .
Note: Granting access to a bucket for another IONOS user does not make the bucket appear in the user's S3 web console due to the S3 protocol's architecture. To access the bucket, the user must utilize other as the granted access does not translate to interface visibility.
Use the Object Storage API to manage bucket ACL permissions.
Use to manage ACL permission for buckets.
User | Console permission | ACL permission | Access granted |
Bucket Owner | Objects - Read | READ | Allows grantee to read the object data and its metadata. |
Bucket Owner | Objects - Write | WRITE | Enables the grantee to write object data and its metadata, including deleting the object. |
Bucket Owner | Bucket ACL - Read | READ_ACP | Grants the ability to read the ACL of the bucket. |
Bucket Owner | Bucket ACL - Write | WRITE_ACP | Allows the grantee to write the ACL of the bucket. |
Public access | Objects - Read | READ | Grants public read access for the objects in the bucket. Anyone can access the objects in the bucket. |
Public access | Bucket ACL - Read | READ_ACP | Grants public read access for the bucket ACL. Anyone can access the bucket ACL. |
Authenticated users | Objects - Read | READ | Grants read access to objects in the bucket to anyone with an IONOS account using which they can access the objects in the bucket. |
Authenticated users | Bucket ACL - Read | Read_ACP | Grants read access to bucket ACL to anyone with an IONOS account. |
Logging | Objects - Read | READ | Allows grantee to read the object log data. |
Logging | Objects - Write | WRITE | Enables the grantee to write object data and its metadata, including deleting the object. |
Logging | Bucket ACL - Read | READ_ACP | Grants the ability to read the log data of the bucket. |
Logging | Bucket ACL - Write | WRITE_ACP | Allows the grantee to write the ACL of the bucket. |
With the help of a detailed authorization system, based on the S3 Access Control List (ACL), you can control precisely who accesses and edits your content. By assigning ACLs to a group of users as per S3-compliant ACL, you can manage who may access the buckets and objects of your IONOS S3 Object Storage.
Use Bucket Policy instead of ACLs if you need to:
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.
Use Share Objects with Pre-Signed URLs instead of ACL for granting temporary access to authorized users for a specified period, after which the URL expires.
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 S3 Object Storage offers the following ACL management methods:
If you have defined ACLs granting public access, activating the Block Public Access revokes 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 ACL settings.
Use the Object Lock to protect critical objects in a bucket for an immutable period. |
Manage multiple versions of the same object using Versioning. |
Use the Bucket Policy to define granular access permissions and actions users can perform on buckets and objects. |
Use the ACL to define access permissions on buckets and objects to control who can access them. |
With Logging, track and record storage requests for your buckets. |
You can manage ACL permission for objects through the web console, IONOS S3 Object Storage API, or the command-line tool.
The following table shows the ACL permissions that you can configure for objects in a bucket in the IONOS S3 Object Storage.
These permissions are applied at individual object levels within a bucket, offering a high level of granularity in access control.
Note: For security, granting some of the access permissions such as Public access WRITE_ACP and Authenticated users WRITE_ACP is possible only through an API Call.
To manage ACL for objects using the web console, follow these steps:
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket under which the object ACL to be modified exists.
3. From the Objects list, choose the object for which ACL permissions are to be modified.
4. From the Object Settings, click Access Control List (ACL).
5. Select the checkboxes against the access permissions to grant at each user level such as bucket owner, public access, and authenticated users. For more information, see ACL permission for objects.
6. Add grantees to provide additional users with access permission to the object. For more information, see Add grantees for objects.
7. Click Save to apply the ACL settings to the object.
Result: The object ACL permissions are successfully applied to the object.
Prerequisites:
Make sure the canonical user ID of the grantee is known. To retrieve the ID, see Object Lock.
The grantee should already exist. If not, create a user and retrieve the Canonical user ID by following the steps in Retrieve the Canonical User ID of a new user.
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket under which the object ACL to be modified exists.
3. From the Objects list, choose the object for which you want to add the grantee.
4. In the Additional Grantees section, enter the retrieved Canonical user ID of the grantee, select the checkboxes on the ACL permissions to grant, and click Add. For ACL permissions, see ACL permission for objects.
5. Add any number of grantees to the object by following step 4.
6. Click Save to add the additional grantees with corresponding ACL permissions to the object.
Result: The grantees are successfully added to the object.
Use the PutObjectAcl Object Storage API to manage object ACL permissions.
Use CLI to manage ACL permission for objects.
User
Console permission
ACL permission
Access granted
Bucket Owner
Objects - Read
READ
Allows grantee to read the object data and its metadata.
Bucket Owner
Object ACL - Read
READ_ACP
Grants the ability to read the object ACL.
Bucket Owner
Object ACL - Write
WRITE_ACP
Allows the grantee to write the ACL of the applicable object.
Public access
Objects - Read
READ
Grants public read access for the objects in the bucket. Anyone can access the objects in the bucket.
Public access
Object ACL - Read
READ_ACP
Grants public read access for the object ACL. Anyone can access the object ACL.
Authenticated users
Objects - Read
READ
Grants read access to objects in the bucket to anyone with an IONOS account using which they can access the objects in the bucket.
Authenticated users
Object ACL - Read
Read_ACP
Grants read access to object ACL to anyone with an IONOS account.
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.
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.
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 - suspended: 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.
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 versioning activation 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.
You can manage Versioning using the web console, APIs, and command-line tool.
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket for which versioning must be enabled and click Bucket settings.
3. In the Versioning, click Enable to have versioning of objects. On choosing Disable option, it suspends object versioning but preserves existing object versions.
Result: Based on the selection, versioning is either enabled or disabled for objects in the bucket.
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket in which the desired object exists.
3. Click the object name within the bucket listing.
4. Navigate to the object's Versions tab by clicking the object name or clicking the three dots against the object name.
5. Copy Version IDs or download non-current versions of the object. You can also select and delete non-current object versions.
Result: Based on the selection, Version IDs and non-current object versions are successfully managed.
Use the Versioning API to configure and manage Versioning for a bucket.
Use the CLI to manage Versioning.
IONOS S3 Object Storage allows the setup of lifecycle rules for managing both current and non-current versions of objects in versioning-enabled buckets. For instance, you can automate the deletion of non-current object versions after a specified number of days post their transition to a non-current status.
For a bucket with Object Lock enabled, Versioning is automatically enabled and cannot be suspended.
For Bucket Replication to function correctly, Versioning must be enabled.
Logging in IONOS S3 Object Storage enables the tracking and storage of requests made to your bucket. When you enable logging, S3 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.
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. S3 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 S3 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.
You can manage Logging using the web console, APIs, and command-line tool.
Prerequisite: Make sure you have provided access permissions for Log Delivery Group. For more information, see Grant access permission for Logging.
To activate logging, follow these steps:
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket and click Bucket settings.
3. Go to Logging and click Browse S3 to select the destination bucket in the same region to store logs.
Note: Although it is possible to store logs in the same bucket being logged, it is recommended to use a different bucket to avoid potential complications with managing log data and user data together.
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.
Result: Logging is enabled for the selected bucket.
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.
1. In the DCD, go to Menu > Storage > IONOS S3 Object Storage.
2. From the Buckets list, choose the bucket for which the logging must be enabled.
3. Click Bucket settings and go to Access Control List (ACL).
4. For Logging, select the OBJECTS:WRITE and BUCKET ACL:READ checkboxes.
5. Click Save.
Result: The required access permissions to enable Logging for a bucket is enabled.
Use the Logging API to configure and manage Logging for a bucket.
