Object Storage Bucket Policy Statements

Bucket policies in Thalassa Cloud are JSON documents made of one or more statements. Each statement grants or denies specific actions on resources (your bucket and its objects) for a set of principals (who the policy applies to). This guide explains the fields that make up a statement, how to refer to buckets and objects, and how to scope principals to everyone in your organisation, a single service account, or broader access when that is intentional.

Policy document shape

Policies use a familiar structure: a Version and a Statement array. Each element of Statement is one rule.

Thalassa Cloud uses an extended principal map so you can express Thalassa IAM identities alongside any AWS-style fields your tooling expects.

Resources

Object storage resources use the arn:thalassa:s3::: prefix.

• Bucket-level ARN — arn:thalassa:s3:::<bucket-name>
  Targets the bucket itself (for operations that apply to the bucket).

• Objects under the bucket — arn:thalassa:s3:::<bucket-name>/*
  Targets all objects in that bucket. Narrow prefixes by using a longer key path instead of * if your policy language supports it in the ARN.

For a bucket named test, you will often include both the bucket ARN and the /* object ARN when you want the statement to cover listing-style bucket access and object access, depending on the actions you allow.

Example resource list:

"Resource": [
  "arn:thalassa:s3:::test",
  "arn:thalassa:s3:::test/*"
]

Replace test with your bucket name.

Principals

The Principal object can include AWS and Thalassa arrays. For Thalassa identities, use the Thalassa list with IAM ARNs (or a controlled wildcard).

Principal wildcard (*)

Using "*" in the Thalassa principal list applies the statement to all callers the policy engine considers in scope, including anonymous and public access where that applies. Only use this when you intend broad access (for example a deliberately public bucket). For normal workloads, prefer explicit IAM principals or organisation-scoped patterns below.

All users in your organisation

To allow every service account and every user in a single organisation, use two ARN patterns with your organisation ID (the segment starting with o- in the console or API):

• Service accounts:
  arn:thalassa:iam:::serviceaccount/o-<organisation-id>:*
• Users:
  arn:thalassa:iam:::user/o-<organisation-id>:*

Substitute your real organisation ID for o-<organisation-id> (for example o-d54s7m2acp3ao2lj0d20).

Example Principal for all users and service accounts in that organisation:

"Principal": {
  "AWS": [],
  "Thalassa": [
    "arn:thalassa:iam:::serviceaccount/o-d54s7m2acp3ao2lj0d20:*",
    "arn:thalassa:iam:::user/o-d54s7m2acp3ao2lj0d20:*"
  ]
}

Replace o-d54s7m2acp3ao2lj0d20 with your organisation ID.

Specific service account

To grant access to one service account, use its full IAM ARN:

arn:thalassa:iam:::serviceaccount/o-<organisation-id>:sa-<service-account-id>

The organisation ID is the o-... segment; the service account has its own sa-... identifier.

Example: read-only access for any principal (use with care)

This example allows s3:GetObject on bucket test for the broad Thalassa principal *. Review carefully before applying; it is appropriate only when you want that wide scope.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:thalassa:s3:::test",
        "arn:thalassa:s3:::test/*"
      ],
      "Principal": {
        "AWS": [],
        "Thalassa": [
          "*"
        ]
      }
    }
  ]
}

Example: read-only access for one service account

This example allows the same actions and resources, but only for a single service account in your organisation:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:thalassa:s3:::test",
        "arn:thalassa:s3:::test/*"
      ],
      "Principal": {
        "AWS": [],
        "Thalassa": [
          "arn:thalassa:iam:::serviceaccount/o-d54s7m2acp3ao2lj0d20:sa-d5rucrqacp3mlcftvr8g"
        ]
      }
    }
  ]
}

Replace the bucket name, organisation ID, and service account ARN with your own values.

Organisation ID in ARNs

In IAM ARNs, the segment o-... is your organisation ID. It appears in both user and service account ARNs so policies can be scoped to one tenant. When you copy ARNs from the console or API, keep that segment unchanged; swapping organisations will break access.

Practices

• Least privilege: Prefer the narrowest principal (one service account, or org patterns) instead of * unless you explicitly need public or fully open access.
• Match resources to actions: Ensure Resource ARNs align with the Action list (bucket-only vs object paths).
• Test: After changing a policy, verify access with a representative identity and with an identity that should be denied.

For supported S3 operations and bucket policy integration with IAM, see Object Storage.