Skip to content
EOCube.ro — Powered by ROCS Tools
EOCube.Ro - Tools
Storage
RO
Sign in

Storage

The EOCube.Ro platform provides S3-compatible object storage.

Access is authenticated via the ROCS Single Sign-On (SSO) -- you do not use a static access key / secret key pair; you sign in with your EOCube.Ro account, just like the rest of the platform.

There are two S3 endpoints:

  • Primary storage -- the main, project-wide object storage.
  • User storage -- your personal object storage.

Primary S3 endpoint

S3 endpoint https://storage.svc.uvt-01.eocube.ro
Port 443 (HTTPS)
Region ro-west-uvt-01
Addressing path-style (the bucket name is in the path)
Authentication ROCS Single Sign-On -> temporary S3 credentials (AssumeRoleWithWebIdentity)

User S3 endpoint

S3 endpoint https://s3.svc.uvt-01.eocube.ro
Port 443 (HTTPS)
Region ro-west-uvt-01
Addressing path-style (the bucket name is in the path)
Authentication ROCS Single Sign-On -> temporary S3 credentials (AssumeRoleWithWebIdentity)

How authentication works

The client sends you to the ROCS Single Sign-On in the browser to sign in (EOCube.Ro account). The resulting token is then exchanged for temporary S3 credentials, which are used to sign requests. No permanent key is stored in the client; the session expires and is refreshed automatically via the refresh token.

Cyberduck

Cyberduck is a graphical S3 client (Windows / macOS). Download the connection profile for the storage you need -- each one preconfigures its endpoint and the sign-in flow:

Steps

  1. Download a profile and open it (double-click) -- Cyberduck creates a bookmark with the matching name (e.g. "EOCube.Ro User Storage (Single Sign-On)").
  2. Open the bookmark. Cyberduck opens a browser window to the ROCS Single Sign-On; sign in with your EOCube.Ro account.
  3. Once authorized you are connected. No username or password fields need to be filled in -- they are obtained automatically from the sign-in flow.

Command-line access

For the aws CLI, rclone, s5cmd or SDKs, use the same endpoint (https://storage.svc.uvt-01.eocube.ro or https://s3.svc.uvt-01.eocube.ro) with path-style addressing. These tools cannot start the interactive sign-in flow themselves, so they need temporary S3 credentials obtained separately (AssumeRoleWithWebIdentity).

Signing region

Every request is signed with Signature Version 4 for a specific region, and the storage only accepts its own (ro-west-uvt-01): a URL signed for another region -- or, when no region is set at all, a legacy Signature Version 2 URL -- is refused with 403 Forbidden. This matters mostly for the presigned URLs that eocube.integrations.notebooks.sign_in_place hands to rasterio, xarray or a Dask cluster: listing and reading through the filesystem object are signed per request, presigned links carry the region baked in.

eocube resolves the region on its own; the first source that applies wins:

  1. the AWS_DEFAULT_REGION environment variable -- the explicit override (the JupyterHub exports it per user);
  2. the STAC item being signed, when it declares one through the storage extension (storage:schemes / storage:scheme matched by platform, or storage:region);
  3. the region already configured for the request: the region of the storage definition in eocube.yml (eocube setup storage add --region ...), or, for a filesystem you built yourself and hand to get_eocube_sign, the region it is pinned with or its SDK session is configured with;
  4. the built-in list of known endpoints -- both platform endpoints above;
  5. the AWS SDK's own default region (a profile in ~/.aws/config);
  6. us-east-1, so Signature Version 4 is always used.

Endpoints are matched by host and port (an omitted port is the scheme's default), so two services on different ports of one host are different endpoints.

Outside the hub nothing needs to be set: after eocube auth login, the platform endpoints resolve to ro-west-uvt-01 by themselves. Set AWS_DEFAULT_REGION only to force a different region, before importing eocube.integrations.notebooks.

Permissions

Access to buckets and objects is governed by your ROCS Single Sign-On roles and groups, like the rest of the platform. If an operation is rejected with an Access Denied error, your account lacks the required role -- contact the ROCS project administrators.