frostmoln_bucket_cors_configuration (Resource)

Manages the CORS configuration of an object storage bucket, so browsers may call the bucket's S3 endpoint directly from a web application.

REPLACE SEMANTICS, AND ONE CONSEQUENCE WORTH KNOWING: a bucket carries a single CORS configuration, and applying this resource replaces it whole. Frostmoln adds a default CORS rule for the customer portal's origin to every new bucket, which is what lets the portal's object browser upload and list objects browser-direct via presigned URLs. Taking the bucket's CORS under Terraform removes that rule unless you declare it yourself, and the portal's object browser will stop working for this bucket. The plan warns and names the origins it is about to stop allowing; declare the ones you want to keep.

That default is applied only when a bucket is created, so nothing restores it later: terraform destroy on this resource leaves the bucket with NO CORS configuration at all, not with the rule it had beforehand. Read the current configuration (terraform import, or the API) before you take it over, and re-declare what is actually there — the portal's origin is deployment configuration, so do not assume a particular hostname.

Example Usage

# Let a web application call the bucket's S3 endpoint directly from the browser.
#
# A bucket carries a SINGLE CORS configuration and this resource replaces it
# whole. Frostmoln adds a default rule for the customer portal's origin to every
# new bucket, which is what lets the portal's object browser upload and list
# objects browser-direct — and that default is only ever applied at bucket
# create, so nothing puts it back.
#
# Read the bucket's current configuration before taking it over (terraform
# import, or the API) and re-declare the rules you want to keep. The portal's
# origin is deployment configuration, so do not assume a hostname: the plan
# names the origins it is about to stop allowing.

resource "frostmoln_bucket_cors_configuration" "example" {
  bucket = frostmoln_bucket.example.name

  rules = [
    {
      id              = "web-app"
      allowed_origins = ["https://app.example.com"]
      # Grant only the methods the application actually issues.
      allowed_methods = ["GET", "HEAD", "PUT"]
      expose_headers  = ["ETag"]
      max_age_seconds = 3600
    },
  ]
}

Schema

Required

• bucket (String) The name of the bucket whose CORS configuration this is. Also the import ID.
• rules (Attributes List) The CORS rules, in order. At least one rule is required — an empty list is refused rather than sent, because the API treats it as "delete the whole CORS configuration" and answers 204, which would wipe the bucket's CORS from a config that reads like it is adding rules. Use terraform destroy to leave the bucket without one. (see below for nested schema)

Nested Schema for rules

Required:

• allowed_methods (Set of String) HTTP methods allowed for the origins. One or more of GET, PUT, POST, DELETE, HEAD — the values are case-sensitive.
• allowed_origins (Set of String) Origins allowed to make cross-origin requests, e.g. https://app.example.com. * allows any origin — combined with a write method that lets any page on the internet drive a request against this bucket, so scope it to the origins you serve unless the bucket is public.

Optional:

• allowed_headers (Set of String) Request headers allowed in the preflight response. * allows any header.
• expose_headers (Set of String) Response headers a browser may expose to the calling script, e.g. ETag.
• id (String) An optional identifier for the rule.
• max_age_seconds (Number) How long a browser may cache the preflight response, in seconds. Must be at least 1: the field is omitted from the request when zero, so a 0 cannot be transmitted and would read back as unset on every plan.

Import

Import is supported using the following syntax:

The terraform import command can be used, for example:

# Import a bucket's CORS configuration by the bucket name.
terraform import frostmoln_bucket_cors_configuration.example "my-data-bucket"