Fail fast on multitenant object store without shared kind#866
Conversation
In multitenant deployments the OSS handler only prefixes object keys with the tenant ID when the object store kind is 'shared'. With any other (or no) kind, keys are unprefixed and tenants share a single keyspace with no isolation, while separate per-tenant stores are not yet supported. The OSS registration now refuses to start when multitenancy is enabled and the object store kind is not 'shared', instead of silently registering a handler that provides no tenant isolation.
Updates RegistrationTest so that enabling multitenancy with a non-shared or unset object store kind now expects a ServiceException and no handler registration, replacing the previous assertions that documented the insecure silent-fallback behavior.
SummaryThe following content is AI-generated and provides a summary of the pull request: Fail Fast on Multitenant Object Store Without Shared KindBug Fix🐛 Closes a silent security misconfiguration: when multitenancy is enabled but Changes
PR Bot InformationVersion:
|
![hyperspace-pr-bot[bot]](https://avatars.githubusercontent.com/u/2531208?s=60&v=4){kind=small}
There was a problem hiding this comment.
The PR correctly implements a fail-fast security guard against misconfigured multitenant setups, with well-updated tests. Two minor issues were flagged: the ServiceException should carry an explicit ErrorStatuses.BAD_REQUEST status to match the project convention and avoid a misleading 500, and the null-kind test should explicitly stub the objectStore.kind property to null for clarity rather than relying on Mockito's default unstubbed return.
PR Bot Information
Version: 1.28.2
- Event Trigger:
pull_request.opened - Correlation ID:
e45c2410-84ef-11f1-8a5b-8e98efce6618 - Agent Instructions:
- File Content Strategy: Full file content
- LLM:
anthropic--claude-4.6-sonnet
2 participants
Issue
The OSS attachments handler only prefixes object keys with the tenant ID when
cds.attachments.objectStore.kindisshared. If multitenancy is enabled with any other value (or none),buildObjectKeyreturns the rawcontentId, so all tenants share a single unprefixed keyspace with no isolation. Separate per-tenant object stores are documented as not yet supported.A misconfiguration (multitenancy on,
kindnot set toshared) therefore silently results in no tenant isolation in the bucket.Fix
The OSS
Registrationnow fails fast: when multitenancy is enabled and the object store kind is notshared, startup throws aServiceExceptionwith a message pointing tocds.attachments.objectStore.kind: shared, instead of registering a handler that provides no isolation.Tests
RegistrationTestupdated: enabling multitenancy with a non-shared or unset kind now expects aServiceExceptionand no handler registration (previously these tests documented the insecure silent-fallback).