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:
Primary storage -- EOCube.Ro Storage (Single Sign-On) User storage -- EOCube.Ro User Storage (Single Sign-On)
Steps
- 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)").
- Open the bookmark. Cyberduck opens a browser window to the ROCS Single Sign-On; sign in with your EOCube.Ro account.
- 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:
- the
AWS_DEFAULT_REGIONenvironment variable -- the explicit override (the JupyterHub exports it per user); - the STAC item being signed, when it declares one through the
storage extension
(
storage:schemes/storage:schemematched byplatform, orstorage:region); - the region already configured for the request: the
regionof the storage definition ineocube.yml(eocube setup storage add --region ...), or, for a filesystem you built yourself and hand toget_eocube_sign, the region it is pinned with or its SDK session is configured with; - the built-in list of known endpoints -- both platform endpoints above;
- the AWS SDK's own default region (a profile in
~/.aws/config); 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.