Problem
The current ocr-service process initializes both signed upload/quarantine verification and normalized-result reading. In the reviewed runtime IAM matrix those capabilities are intentionally separated: kora-doc-signer may create quarantine objects while kora-doc-result-api may read result objects. One Pod has one Workload Identity, so deploying the current all-routes process requires broadening a reviewed identity across both data classes. That would violate the approved least-privilege and product-isolation design.
Required design
- Expose an upload capability that owns only upload intent, uploaded-object verification and completion routes, runs as the product signer identity, and has no result-bucket access.
- Expose a job/result capability that owns job creation/status/cancellation/result routes, runs as the result-reader identity, and has no quarantine read/write authority.
- Preserve the versioned
/v1/ocr contract behind a single internal gateway/route boundary; clients must not receive bucket credentials beyond the short-lived signed upload URL.
- Make readiness capability-specific, preserve HMAC product/tenant verification and idempotency, and fail closed when a capability is unconfigured.
- Extend tests to prove an upload identity cannot read results, a result identity cannot issue/read uploads, and a second tenant receives no resource existence signal.
Acceptance evidence
A synthetic sandbox PDF travels upload intent → create-only upload → scanner/accepted source → durable job → result retrieval without any workload identity having both quarantine and result-object privileges. Helm/IAM validation proves the split before GKE deployment.
Dependencies
Blocks the secure runtime deployment in #32. Aligns with the bucket/identity design tracked in tesserix/tesserix-k8s#914 and #946.
Problem
The current
ocr-serviceprocess initializes both signed upload/quarantine verification and normalized-result reading. In the reviewed runtime IAM matrix those capabilities are intentionally separated:kora-doc-signermay create quarantine objects whilekora-doc-result-apimay read result objects. One Pod has one Workload Identity, so deploying the current all-routes process requires broadening a reviewed identity across both data classes. That would violate the approved least-privilege and product-isolation design.Required design
/v1/ocrcontract behind a single internal gateway/route boundary; clients must not receive bucket credentials beyond the short-lived signed upload URL.Acceptance evidence
A synthetic sandbox PDF travels upload intent → create-only upload → scanner/accepted source → durable job → result retrieval without any workload identity having both quarantine and result-object privileges. Helm/IAM validation proves the split before GKE deployment.
Dependencies
Blocks the secure runtime deployment in #32. Aligns with the bucket/identity design tracked in tesserix/tesserix-k8s#914 and #946.