Give platform services their own connections
Platform services need access to the services they use, without each receiving the operator’s administrative credentials. The applications manager provisions their connection material and makes the registered services’ configuration available through the trusted platform control plane.
Object storage uses short-lived sessions confined to the service’s platform identity. The provisioner keeps the administrative authority needed to create access; the consuming service receives the connection or session intended for its work.
Example — Prepare storage access for a platform service
An authenticated platform service requests storage access. The manager ensures the bucket exists, then issues a session constrained to that service’s platform application identifier. The response includes the expiry and identifier needed by the storage client, without returning the object store’s root credential.
For engineers
Register the consumer before it asks for access
The platform infrastructure manager provisions the explicit PLATFORM_SERVICES population. Its type coverage checks require services to be listed or explicitly excluded. Provisioning establishes the platform application record atomically, then prepares the applicable Redis, RabbitMQ and signing-key material.
The platform-service retrieval route checks the shared PLATFORM_APPLICATION_PRIMARY_SECRET, then resolves the registered service named by the SERVICE_ID header. This authenticates membership in the trusted platform control plane; it does not independently bind a holder of that shared secret to one service identifier. The signed route through which platform services access application configuration has a different authentication contract. Provisioner administrative connections and boot signing-key inputs must already exist; provisioning does not create its own root authority from nothing.
Issue storage access from the registered service record
The following actual controller excerpt runs after authentication and bucket preparation. storage is the manager’s resolved storage configuration; platformApplication is the registered service selected after the shared-secret check. The root values remain inside the manager’s call to the broker.
const credentials = await this.objectStorageStsBroker.issueApplicationScopedCredentials({
stsEndpoint: storage.stsEndpoint,
rootAccessKey: storage.accessKey,
rootSecretKey: storage.secretKey,
bucket: storage.bucket,
applicationId: String(platformApplication._id),
durationSeconds: storage.sessionDurationSeconds,
});
The confinement identifier comes from that selected record, never a caller-supplied storage prefix. Prefix confinement of the issued session and authentication of the caller are separate boundaries. The manager ensures bucket existence with administrative rights first, because the confined session is intentionally unable to create the bucket.
Distinguish the credentials’ lifecycles
| Material | Owner and lifecycle |
|---|---|
| Provisioner administrative connections | Operator-supplied authority held by the manager |
| Service connection material | Provisioned and persisted for the registered service |
| Signing keys | Service-specific identity material, including required boot inputs on applicable services |
| Storage session | Broker-issued, prefix-confined and returned with expiresAt |
The storage response also carries applicationId so the consumer builds keys from the issuer’s decision. It must renew expiring sessions through its credential flow rather than widen storage permissions. Session expiry is not scheduled rotation of every longer-lived service credential.
A provisioning result and a ready consumer are different observations. Check the authenticated retrieval path and the consuming runtime’s storage readiness together when diagnosing connection failures. The storage credential end-to-end lane exercises both that success path and refusal of unauthenticated or unregistered callers.