Access
When you have been provided access to the web interfaces, hereby named the CMC (Cloudian Management Console), you should be able to log in via this link:
Note that the site is only open from an UiO or Educloud based network.
Depending on whether you want to store green or yellow data, log in using the correspond "cloudian-green-owners" or "cloudian-yellow-owners" groups with the cl-user you requested.
Creating buckets
Upon login, you will be located in the tab containing your buckets.
Creation of a bucket is simply done by providing a bucket name, and clicking "Add new bucket" using the default storage policy:
To assure all buckets have unique names, we suggest the following naming standard:
<ID provided in case> - <green/yellow> - up_to_you
The object lock button can be toggled, but we advise not to before consulting us about what it does beforehand.
Versioning of objects can be enabled without activating object lock on the buckets, more on this further down on this page!
Access control
To begin with, a bucket will only be accessible to the keys of the system user which created it. However, since the system user's keys can be used to perform any API request towards any of its buckets from anywhere, we strongly recommend creating separate key pairs which can be provided fine-tuned access.
To do this, we have IAM, short for Identity and Access Management.
Start by navigating to the IAM tab at the top of the page, and click "Add new user".
Choose a fitting name for the use case, ex. "iam-[application]-prod-rw".
For the path you may provide something to identify its organizational connection (ex. /uio/it/), but you can also just leave it empty.
Click the name of the newly created user, and you should see this page:
The user will need a key added by clicking + Create new key (1), which will immediately bring up a notification with the secret access key. It will only be present until the page is refreshed, so be prepared to store it somewhere (worst case, delete the key and create another). The corresponding access key id will be added to the list.
The key pair will not have any permissions until they are connected to an IAM policy document, configured in the IAM policies tab (2).
This process requires a bit more finesse, you can access some usual templates, or read more about how to construct your own policies here:
Bucket options
Versioning of buckets
Bucket versioning means that the bucket will retain a history of changes done to its objects. In other words, if you have uploaded a document, and upload another with the same name, the storage will keep the former copy as a version of the same object with references in its metadata.
Versioning is an excellent way to safeguard against accidental overwrites, or simply for the ability to track changes to an object.
Versioning is turned on like this:
When active, you can see in its contents that new objects now will have underlying identifiers to the different versions of the object.
For example, here you see three versions of the file "foo.txt" (note the timestamps):
You can then download the version you'd like directly in the CMC, or via your favorite language/tool.
Note: when the bucket retains all object versions, this could lead to a potentially large increase in storage use. Therefore, consider combining versioning with timed expiration of non-current version. More on this in the next section!
Automatic expiration of old objects (Lifecycle policy)
You can set up a policy which will automatically clean up old objects for you to keep your bucket clean, and save storage. Open a bucket's properties, and navigate to the "Lifecycle Policy" tab to get started.
When clicking "add new rule", you'll be met by the following window (full window appears when checking "Expire objects"):
In the example above we've set up a simple rule which automatically deletes objects not accessed in the last 30 days, in addition to deleting non-current versions of objects after 7 days. For further tidiness, we also checked off the option for cleaning up any lingering, failed multipart uploads after 7 days.
Furthermore, you have the options to specify which objects should be affected by enforcing a prefix, or assign upper or lower object sizes.
Publication of objects
Upon creation, buckets are by default private such that only access keys which are granted access may see the contents.
This is of course wanted in most use cases, however, there are exceptions where you want the bucket's (green) contents to be publicly accessible. For example if there's an image you want to reference to in a website, or want to publish an open document.
For single files, public read-access can be granted as shown below:
Caution: Know what you're doing!
Be careful about which data you're about to share, and make sure you're only providing read access for the Public.
"ACP readable" means you grant access to list who has access to the object, which in practice have minimal impact.
If you want to make a specific directory, or the while bucket public, you'll need to create a bucket policy. Due to the complexity and pitfalls you may encounter when attempting to fix this yourself, we suggest contacting us if you have such a need.