AWS solutions documentation change
Summary
Added documentation for creating new assets via project-scoped triggers and ingesting derived files from external S3 locations. Introduced 'assets' output target with allowedTemplateIds and securityConfig fields.
Security assessment
The changes document new security features including template-based authorization (allowedTemplateIds) and cross-account access controls (securityConfig IAM roles). No vulnerability fix is indicated; these are new security capabilities.
Diff
diff --git a/solutions/latest/spatial-data-management-on-aws/connector-configuration.md b/solutions/latest/spatial-data-management-on-aws/connector-configuration.md index 11db00429..b8e4bd4a2 100644 --- a//solutions/latest/spatial-data-management-on-aws/connector-configuration.md +++ b//solutions/latest/spatial-data-management-on-aws/connector-configuration.md @@ -30 +30 @@ Resource | Description -`project` | Triggered when a project is created, updated, or deleted. +`project` | Triggered when a project is created, updated, or deleted. Project-scoped triggers can produce assets via the `assets` output target without requiring a triggering asset. @@ -102,0 +103 @@ Target | Description +`assets` | Creates new assets in the project from envelope files the step produced. Each entry specifies an `allowedTemplateIds` list and an optional `filter` to match output files. Only valid on triggers with `"resources": ["project"]`. @@ -141 +142,86 @@ In this example, the step writes quality scores into asset metadata and ingests -Any trigger that declares an `output` block makes the connector asset-content-scoped, which means you must approve it through the template authorization chain. +Any trigger that declares an `output` block with `metadataAttributes`, `derivedFiles`, or `files` makes the connector asset-content-scoped, which means you must approve it through the template authorization chain. The `assets` target additionally requires that the connector is approved on each template ID listed in `allowedTemplateIds`. + +### Creating assets from connector output + +The `assets` target lets a connector create new assets in the project. This is used with project-scoped triggers — typically a Deadline Cloud job that produces one or more assets without an originating asset. + +Each entry in the `assets` array specifies which templates the connector is allowed to create assets under, and an optional filter to identify envelope files in the step output: + + + "output": { + "assets": [ + { + "allowedTemplateIds": ["<TEMPLATE_ID>"], + "filter": { "fileExtensionFilter": ".json" } + } + ] + } + +The connector’s step output must contain asset envelopes — JSON objects with: + + * `idempotencyKey` – A unique key per asset to enable deduplication across retries. + + * `templateId` – Must be listed in `allowedTemplateIds`. + + * `name` – The asset name. + + * `metadataAttributes` – (Optional) Metadata to set on the created asset. + + * `manifest` – (Optional) File manifest for the asset. + + + + +SDMA validates that the triggering user has at least Contributor membership in the project before creating the asset. Each created asset fires a standard `create` lifecycle event. + +The `assets` output target is only eligible on triggers with `"resources": ["project"]`. Declaring it on asset-scoped or file-scoped triggers causes a validation error at connector creation time. + +### Ingesting derived files from an external S3 location + +When a step writes output files to S3 and returns the location in its response, you can use `${response.*}` expressions in the `uri` field of a `derivedFiles` entry to ingest those files without hardcoding paths. + +The `uri` field supports two forms depending on whether `filter` is present: + + * **S3 object form** (no `filter`) – Ingests a single object at the resolved S3 URI. + + * **S3 prefix form** (with `filter`) – Lists objects under the resolved S3 URI prefix and ingests those matching the filter. + + + + +Example — ingest `.png` files from a location returned by a Lambda step: + + + "output": { + "derivedFiles": [ + { + "filter": { "fileExtensionFilter": ".png" }, + "uri": "${response.outputLocation}" + } + ] + } + +In this example, the Lambda function returns `{"outputLocation": "s3://my-bucket/renders/job-123/"}` in its response payload. SDMA lists objects under that prefix, filters for `.png` files, copies them into the managed content store, and attaches them as derived files on the asset. + +You can also reference a single file directly: + + + "output": { + "derivedFiles": [ + { + "uri": "${response.thumbnailUrl}" + } + ] + } + +Supported fields on each `derivedFiles` entry: + +Field | Form | Description +---|---|--- +`uri` | Both | S3 URI or S3 URI prefix. Supports `${response.*}` variable substitution. +`filter` | Prefix only | Narrows which objects under the prefix are ingested. Supports `fileExtensionFilter`, `fileNameRegex`, `minFileSizeMB`, and `maxFileSizeMB`. +`hash` | In-bucket only | xxh128 hash (32 hex chars). When present, indicates the file is already at the canonical SDMA key — no copy is performed. +`path` | All | Override the display path for the derived file. +`securityConfig` | Object and prefix | Per-entry IAM role to assume when reading from the source bucket. Use when the source bucket is in a different account. + +The `uri` and `hash` forms are mutually exclusive. When `hash` is present, SDMA assumes the bytes are already in the managed content store at the canonical key. @@ -579,0 +666 @@ Field | Required | Description +`output` | No | Output routing configuration for the trigger. The eligible output targets depend on the trigger’s `resources` scope: `metadataAttributes` (project, asset, file, derivedFile), `derivedFiles` (asset, file, derivedFile), `files` (asset only), `assets` (project only).