S3 Object Storage

The S3 object storage of the noris Sovereign Cloud (nSC) is provided by Ceph and accessible via an S3-compatible API and the OpenStack API. S3 is originally an AWS product that has become the industry standard. We aim to be as compatible as possible, and the vast majority of clients work with our Ceph S3 API without issues. A known incompatibility with recent versions of the AWS CLI or an AWS SDK is described in the Known Issues section.

Utilize S3

Using EC2

Credential creation

To access the S3 API, you need to create EC2 credentials:

openstack ec2 credentials create

Note: The application credentials used must have the Unrestricted option enabled to create EC2 credentials. See OpenStack Application Credentials.

Security

OpenStack Application Credentials and EC2 credentials created from these Application Credentials are project-scoped. If the credentials with which a bucket is accessed are also created via OpenStack Application Credentials, that Access Control List can be overridden by these same credentials. For true separation of concerns, it is thus advised to create separate projects.

Example: s3cmd

This allows all S3 clients to be utilized. To showcase this, we are using the s3cmd client. Please change the following parameters in your ~/.s3cfg file:

access_key = <ec2-key>
host_base = rgw.nbg.nsc.noris.cloud
host_bucket =
secret_key = <ec2-secret>

Now an S3 bucket can be created:

s3cmd mb s3://example-bucket

S3 Object Lock

Object Lock prevents objects from being deleted or overwritten (write-once-read-many, WORM). This mechanism helps meet regulatory requirements that require WORM storage, and protects against ransomware or accidental deletion.

Note

Object Lock automatically enables S3 versioning for the bucket. This means that every time an object is overwritten or deleted, new versions are created instead of replacing the existing one. Old versions accumulate and consume storage space until their retention period expires and they can be deleted. Keep this in mind when planning capacity.

The AWS CLI is used for this example. You need to place your credentials in your ~/.aws/credentials file:

[default]
aws_access_key_id = <your-access-key>
aws_secret_access_key = <your-secret-key>

Now a new bucket example-bucket can be created with object lock. Enabling object lock must be done during bucket creation, enabling it retroactively is not possible.

aws --endpoint-url=https://rgw.nbg.nsc.noris.cloud s3api create-bucket --object-lock-enabled-for-bucket --bucket example-bucket

Afterwards, the object lock configuration must be configured:

aws --endpoint-url=https://rgw.nbg.nsc.noris.cloud s3api put-object-lock-configuration --bucket example-bucket --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "GOVERNANCE", "Days": 14 }}}'

This object-lock configuration actually enables the object lock and configures the default retention mode “governance” with a duration of 14 days.

Important explanation of the object lock modes:

Compliance

Objects can’t be overwritten or deleted by any user, not even privileged users. An object’s retention mode can’t be changed or shortened once it has been placed in the bucket.

Please be careful what you place in this mode and which retention period you configure, given we can’t help you remove specific objects from that bucket, only delete the whole bucket.

Governance

Objects can only be overwritten or deleted by privileged users with the s3:BypassGovernanceRetention permission. Lock settings are also only configurable by these privileged users.

Please note that your default user does have the s3:BypassGovernanceRetention permission. For this mode to actually protect your data, you’d need to create separate user accounts that don’t have this permission, and use those for regular bucket access.

Using swift

The following command creates the bucket example-bucket:

openstack container create example-bucket

There is also the optional --public parameter to make the bucket publicly readable to anyone with the link (using this with private data is NOT advisable, please use private if in doubt).

Encryption

Server-Side Encryption

We currently only support SSE-C (Server-Side Encryption with Customer-Provided Keys), which lets you bring your own customer-managed keys. The SSE-S3 and SSE-KMS variants are currently not offered. An example of configuring SSE-C with rclone can be found in the Backup and Restore section.

Client-Side Encryption

Client-side encryption is supported, or more precisely we do not distinguish between regular data and client-side encrypted data. For implementation and configuration, follow the documentation of the encryption tool you are using. The following best practices apply generally: store encryption keys separately from your S3 credentials and in multiple safe locations, and test key retrieval and restoration periodically. Note that client-side encryption protects object content but not metadata.

Backup and Restore

Backup via CLI

The easiest way to back up S3 is to copy the bucket’s content into another S3 bucket. Please contact your sales representative if you are interested in additional S3 buckets in other geolocations.

In this example, we are using rclone. You need to create a config in ~/.config/rclone/rclone.conf:

[s3]
type = s3
provider = Other
access_key_id = <your-access-key>
secret_access_key = <your-secret-key>
endpoint = https://rgw.nbg.nsc.noris.cloud

[s3-backup-destination]
type = s3
provider = Other
access_key_id = <your-access-key>
secret_access_key = <your-secret-key>
endpoint = <your-backup-destination>

# ServerSideEncryption (SSE-C) can be enabled as follows:
# sse_customer_algorithm = AES256
# sse_customer_key_base64 = # Generate key with: "openssl rand -base64 32" - please preserve this key in a safe and secure location!

The commented lines show the SSE-C configuration.

This command copies the contents of your source bucket to your destination bucket:

rclone copy s3:SOURCE-BUCKET s3-backup-destination:TARGET-BUCKET

You can also look at the sync command, which is faster and works well with incremental changes, but also deletes data in the target bucket when it is deleted from the source bucket.

To validate the expected bucket content, use:

rclone ls s3:
rclone ls s3-backup-destination:

Managed S3 Backup

Please contact your sales representative to get a quote for managed S3 backup.

Important Notes Regarding Backups

• Test the restoration of your backups regularly to ensure data safety and functionality.
• The rclone sync command deletes data in the target bucket that is no longer present in the source bucket. Use rclone copy instead for pure backup copies to avoid data loss in the target.
• Store SSE-C encryption keys separately from your S3 credentials and in multiple safe locations. Without the key, access to the encrypted objects is no longer possible.
• Object Lock automatically enables S3 versioning, causing old versions to accumulate and consume storage space until their retention period expires. Keep this in mind when planning capacity.
• These backups are one-time jobs. To trigger them periodically, you can utilize Application Credentials on a server and run these commands via a cronjob.

Known Issues

Object Storage AWS SDK Incompatibility

Object Storage customers who use a current version (released January 15, 2025) of the AWS CLI or an AWS SDK, or a tool based on such a version, must expect problems uploading files to Object Storage RGW S3 in all regions. The reason is a change in the AWS libraries from January 15, 2025, which requires the use of “Data Integrity Protection for Amazon S3”. The recommended solution for now is to revert to an older version of the AWS CLI or AWS SDK, or use another tool compatible with Object Storage.

• Data Integrity Protections for Amazon S3
• GitHub Issue 9214

Facts and Numbers

S3 Object Storage

• Alternative names: Object Storage, Swift
• Type: Object-based cloud storage
• Provisioning: S3 API, OpenStack API, web console
• Access Pattern: HTTP(S), REST API, global, similar to RWX
• Availability: Global
• Redundancy: Tri-zonal
• Encryption: Optional (SSE-C)
• Access Control: IAM, ACLs, bucket policies
• Backup: Managed by customer
• Description: Backup, archiving, web applications, data lakes.

If your use case requires NFS, please contact your sales representative for a Managed Storage quote.

S3 Placement Targets

We offer the following S3 placement targets:

Placement	Backend Type	Information
default-placement	Mixed HDD+Flash	Should be best for most use cases. Spread over 3 zones in the geolocation.

Please note that the placement target can’t be retroactively changed after creation.