08

Connect Enterprise Systems with Workload Authority

Establish an administrator-approved machine grant before any optional user-delegated connector access.

Run it in the public monorepo

This course is built around the public Zheta Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.

Source: services/shared/auth.py

if claims.get("iss") != issuer or claims.get("aud") != audience or int(claims.get("exp", 0)) <= int(time.time()):
        raise PermissionError("expired or wrong-scope bearer token")
    if not claims.get("sub") or not claims.get("org"):
        raise PermissionError("bearer token lacks tenant identity")
    return Identity(str(claims["sub"]), str(claims["org"]))

Code to reality

Declared intent
Derive actor and tenant authority only from a signed, scoped, unexpired identity token.
Interpreter
The shared authentication adapter verifies cryptographic and semantic claims before MVC dispatch.
Software effect
Accepted requests carry an immutable actor and organization identity; invalid requests stop at the boundary.
Hardware effect
Signature verification consumes service CPU but denied calls allocate no downstream runtime or data resources.
Observable evidence
Positive tenant access and wrong-signature, wrong-audience, and cross-tenant denials identify the boundary.

Start with the people and the result they need

The source tables below remain the detailed contract. Begin with these customer paths:

  • D08-UC-01
    • Person: Enterprise connector administrator
    • Job: Allow one generated app workload to read a named source scope
    • Observable result: Bound workload identity reads only approved resources and records source-owned references
  • D08-UC-02
    • Person: Security operator
    • Job: Revoke a compromised workload grant without deleting the app
    • Observable result: Subsequent connector calls fail while generated-app local data remains available

Turn each customer job into a testable story

Now turn each customer job into a story with a result that an engineer can check:

  • D08-US-01
    • Story: As a connector administrator, I want grants scoped to one workload and source resource set, so that another app cannot reuse them
    • Observable acceptance: App, environment, workload identity, actions, resources, expiry, and source decision are recorded
  • D08-US-02
    • Story: As a security operator, I want connector authority independently revocable, so that source access can stop without destroying app data
    • Observable acceptance: Revoked request is denied; local-domain positive control still succeeds

Add real state and observable proof

Finally trace each story through the system that owns its state and the evidence that proves the outcome:

  • D08-FLOW-01
    • Trigger: Administrator approves a read-only connector request
    • Responsible systems: Connector Broker, workload identity verifier, secrets adapter, enterprise source
    • Authoritative state: Connector Grant store; source system owns source records
    • Owned record: WorkloadConnectorGrant
    • Observable evidence: Admin, app, workload, scope, secret version, source request/decision, trace, environment, timestamp, grant ID
    • Failure signal: Invalid admin, identity mismatch, scope denial, source error, expired credential
  • D08-FLOW-02
    • Trigger: Workload requests an unapproved source collection after grant revocation
    • Responsible systems: Connector Broker, Audit Evidence, generated app
    • Authoritative state: Grant state and immutable evidence; app DB remains separate
    • Owned record: SourceReference
    • Observable evidence: Denial rule, zero source request ID, revocation event, local read trace, immutable evidence ID
    • Failure signal: Call after revoke succeeds, source contacted after local denial, or app data unavailable

The enterprise problem and today’s slice

Enterprise problem: Generated applications often receive copied API keys with broad source access, so credentials outlive approvals and the platform cannot prove which workload read which resource.

Whole-course context: The ownership design reserves app-domain data for a future generated-app store; today adds only provider metadata representing an intended machine connector grant.

Today’s slice: Model an admin-provisioned workload grant and inspect the current connector_grants state transition; the monorepo does not yet contain a Connector Broker, source credential exchange, scoped source call, or revoke operation.

End-of-day evidence: Owner-only connector-name attachment, durable project state, non-owner denial, and connector.service_granted evidence are reproducible; workload identity, source scope, source call, and revocation remain unproved gaps.

Still unsolved: Human delegated access, private network paths, user identity mapping, sharing, and publication remain separate decisions.

Customer use cases

A machine grant answers what the application may do when no end user is present. These use cases provision least privilege and prove independent revocation.

Use case IDActorCustomer jobSuccess outcomeDenial or recovery evidence
D08-UC-01Enterprise connector administratorAllow one generated app workload to read a named source scopeBound workload identity reads only approved resources and records source-owned referencesOut-of-scope resource returns source denial with trace evidence
D08-UC-02Security operatorRevoke a compromised workload grant without deleting the appSubsequent connector calls fail while generated-app local data remains availableRevocation event and unaffected local-data probe share an observation window

Actor-centred user stories

Possessing a connector name cannot imply permission. These stories bind authority to workload identity, resource scope, and expiry.

Story IDUse case IDsUser storyObservable acceptance conditions
D08-US-01D08-UC-01As a connector administrator, I want grants scoped to one workload and source resource set, so that another app cannot reuse themApp, environment, workload identity, actions, resources, expiry, and source decision are recorded
D08-US-02D08-UC-02As a security operator, I want connector authority independently revocable, so that source access can stop without destroying app dataRevoked request is denied; local-domain positive control still succeeds

End-to-end product flows

Connector setup begins with an administrator approving exact machine authority. The generated app calls Connector Broker; it never receives the enterprise credential itself.

Flow IDUse case IDsPathTriggerNumbered stepsTerminal evidence
D08-FLOW-01D08-UC-01, D08-UC-02HappyAdministrator approves a read-only connector request1. Verify admin authority.; 2. Register source credential in secrets owner.; 3. Bind workload identity and scope.; 4. App calls broker.; 5. Broker calls source.; 6. App stores opaque source reference.Admin, app, workload, scope, secret version, source request/decision, trace, environment, timestamp, grant ID
D08-FLOW-02D08-UC-01, D08-UC-02DeniedWorkload requests an unapproved source collection after grant revocation1. Broker resolves workload.; 2. Grant lookup finds revoked or absent scope.; 3. Broker denies before source call.; 4. App reads local record as positive control.Denial rule, zero source request ID, revocation event, local read trace, immutable evidence ID

The administrator grants a machine, not a human, a bounded capability. User authority cannot be inferred from this approval.

System design derived from the flows

If generated code handles enterprise credentials, sandbox compromise becomes source compromise. Connector Broker exchanges its own controlled secret only after verifying the hosted workload and grant.

Use case IDEntry pointResponsible servicesAuthoritative storeFailure evidence
D08-UC-01Forge Studio connector administrationConnector Broker, workload identity verifier, secrets adapter, enterprise sourceConnector Grant store; source system owns source recordsInvalid admin, identity mismatch, scope denial, source error, expired credential
D08-UC-02Revoke action and connector callConnector Broker, Audit Evidence, generated appGrant state and immutable evidence; app DB remains separateCall after revoke succeeds, source contacted after local denial, or app data unavailable

Connector Broker owns grant enforcement, while the enterprise system remains authoritative for source records and its own access decision.

Data model and ownership

Copying source records into the application would silently transfer retention and authorization duties. The app stores only approved derived data and opaque source references.

Generated-application database: Not created in this runnable slice — connector names are provider project metadata only; source references and generated-app derived records remain design targets until a broker and app-owned store exist.

Record or entityStore and ownerPrimary keyForeign key or opaque referenceTenant keyMaterial constraintLifecycle and deletionUse case IDs
WorkloadConnectorGrantControl-plane PostgreSQL and secret manager, owned by Connector Brokergrant_idOpaque app, workload identity, secret version, source scopeorganization_idApp+environment+identity+scope bound; secret never returned to appRequested, approved, active, expired/revoked; evidence retained after secret deletionD08-UC-01, D08-UC-02
SourceReferenceGenerated-app PostgreSQL, owned by generated appsource_reference_idOpaque connector and source-record IDsapp_tenant_idReference grants no authority; every refresh reauthorizes through brokerCreated on allowed read; refreshed, exported, or deleted with app dataD08-UC-01, D08-UC-02

Evidence preserves both authorities: Zheta Forge allowed the broker operation and the source system independently allowed or denied its record.

Prove scope and revocation

Configuration inspection cannot prove a source was not called. The current model can record an owner-approved connector name, but it has no source adapter and therefore proves neither scoped source access nor revocation. Read the implemented state transition in services/control_plane/domain.py.

def grant_connector(self, project: Project, actor: str, connector: str) -> None:
    self._owner(project, actor)
    project.connector_grants.add(connector)
    self._save_and_audit(project, actor, "connector.service_granted")
Declared intentInterpreterSoftware effectHardware effectEvidence
Let only the project owner attach one connector name to provider project statePython executes the Forge owner check; injected repository and event publisher persist state and evidenceAdds a deduplicated string to connector_grants, saves the project, and publishes connector.service_granted; no credential or source authority is createdThe control-plane process uses CPU and the local SQLite/event paths write storageOwner success plus non-owner PermissionError, restored project state, and the audit event prove only the implemented metadata boundary

Decision rules

Provision machine authority before optional user delegation. The current connector-name set is a teaching seam, not production authority; a real workload grant still needs workload identity, resource/action scope, secret ownership, expiry, revoke, source-call denial, and an unaffected positive control.