Skip to content

S3 object storage on MinIO

    Object storage is a data storage architecture for storing unstructured data, which sections data into units—objects
    and stores them in a structurally flat data environment. Each object includes the data, metadata, and a unique 
    identifier that applications can use for easy access and retrieval.
    - What is Object storage?, Google Documentation, https://cloud.google.com/learn/what-is-object-storage,24.05.2024

Requesting access to s3.hpc.ut.ee

To gain access to a S3 object storage is University of Tartu High Performance Computing Center Object storage, you need to write to support@hpc.ut.ee with the following information:

  • Name of the bucket
  • Users who need access to the bucket (MyAccessID account need to be set)

Pricing for S3 object storage is available here Pricing calculator.

Permissions

By default users who have requested access to a bucket will have all of the permissions related to their bucket. This is dangerous when you need to deploy S3 object storage as a backend/data storage for your applications. Application based access to Object storage should be handled by Access Keys

Access Keys

MinIO Access Keys are child accounts of the authenticated user that created them, that support programmatic access by applications. Every permission the Access Key creator has the Access Key will have by default. Access Keys can not be used to log into MinIO Console.

Create an Access Key

Get started with creating an Access Key: S3-create-access-key.png

By default the Access Key name and Secret Key are already filled out. And restrictions beyond user policy are OFF. The latter is the dangerous part, that can cause issues. S3-create-access-key.png

Restricting Access Key's permissions can be done during creation when Restrict beyond user policy is turned ON. S3-ak-restrictions.png

Let's give the Access Key only read permissions for the bucket. The default permissions JSON will look something like this:

{
    "version": "2012-10-17",
    "statement": [
        {
            "effect": "allow",
            "action": [
                "s3:*"
            ],
            "resource": [
                "arn:aws:s3:::testuserbucket",
                "arn:aws:s3:::testuserbucket/*"
            ]
        }
    ]
}
Under Action (mentioned in two places) there currently exists a very liberal s3:* which grants the Access Key same permissions as the user. By modifying the json to:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::testuserbucket",
                "arn:aws:s3:::testuserbucket/*"
            ]
        }
    ]
}
This kind of default Access Key policy modification will grant read-only permissions on any object in specified bucket for the Access Key.

Policy examples

{
    "version": "2012-10-17",
    "statement": [
        {
            "effect": "allow",
            "action": [
                "s3:*"
            ],
            "resource": [
                "arn:aws:s3:::testuserbucket",
                "arn:aws:s3:::testuserbucket/*"
            ]
        }
    ]
}

This option is suitable, when you want to allow traffic from everywhere, to a Pod on a certain port. This use case is typical with public websites or services.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::testuserbucket",
        "arn:aws:s3:::testuserbucket/*"
      ]
    }
  ]
}