Give each runtime credentials for its own work
Wildo provisions application credentials and narrows background-runtime material to declared access. Database, queue, cache and storage access can follow the runtime’s responsibilities instead of inheriting a shared platform credential.
Example — Limit credentials to their runtime purpose
A minion allowed to read todos receives its scoped material. It does not inherit the backend’s database credential when a narrower credential is absent.
For engineers
The application backend uses the application’s provisioned material. Additional runtime principals derive their grants from their declarations. A minion’s resourceAccess.read and write lists govern application data; platform-access scopes are a separate axis.
Database ownership and a scoped table grant use distinct provider operations. Scoped synchronization replaces the previous authority so removing a declared resource can remove the grant instead of leaving an accumulating permission set.
Declare read and write separately
Inside the minion’s entry in wildo.saas.config.ts, an illustrative editing task would declare:
resourceAccess: {
read: ['todos'],
write: ['todos'],
},
| Intended work | Declaration and effect |
|---|---|
| Inspect todos | Put todos in read; leave write empty |
| Read, validate and update todos | Put todos in both lists |
| Write without any read | Put it only in write; reads still refuse, including reads needed by validation or read-modify-write logic |
These identifiers name resource types, not database collection names. User-relative self-resource doors are rejected by this authoring contract. Write permission deliberately does not imply read permission.
Synchronize the changed configuration and inspect the provisioned principal’s grants. Removing a resource must remove the corresponding authority, while a read-only declaration must still refuse a write. The neighboring runtime-topology guide shows the enclosing minion registration. Storage sessions remain scoped to the application’s prefix; a database read-only grant does not also make object storage read-only.
Confine delivery as well as provisioning
The authenticated configuration fetch resolves the presenting principal. Before overlaying a non-backend principal’s material, the manager removes every path that a provider can mint per principal:
Selected source from apps-to-manager.apps-manager.platform.controller.ts:
const isApplicationBackend = principal.kind === ApplicationRuntimePrincipalKind.APPLICATION_BACKEND;
const projected: Record<string, unknown> = structuredClone(rest);
if (!isApplicationBackend) {
for (const path of collectPerPrincipalSecretBlobPaths()) {
AppsToPlatformAppsManagerPlatformController.deleteSecretBlobPath(projected, path);
}
}
if (!section) {
return projected;
}
// Overlay the principal's own material, by the same JSON paths the provider modules mint into.
for (const [path, value] of Object.entries(section.secretBlobValues)) {
AppsToPlatformAppsManagerPlatformController.assignSecretBlobPath(projected, path, value);
}
return projected;
This selected section is from the controller’s credential projection. Stripping occurs even when the principal has no credential section. Otherwise an absent narrow grant could accidentally leave the broad application value in place. The application backend is explicitly distinguished by principal kind because that base material is its own.
Match storage access to the application identity
Object storage uses short-lived sessions with a policy tied to the platform-issued application identifier and storage prefix. Bucket provisioning remains a platform operation; a prefix-confined session does not need permission to create the bucket.
Review the resulting principal grants and delivered material when changing a runtime declaration. Credential generation, network reachability and resource-service permissions reinforce one another, but they are distinct controls with distinct consumers.