Extensibility Model
Understand how GlobalStacks uses extensions for provider integrations, storage, runtime operations, user interface (UI) surfaces, and brokered permissions.
Extensibility model
GlobalStacks extensions add capability without giving third-party code unrestricted access to the control plane, host shell, or tenant secrets.
Extensions can provide:
- storage providers
- infrastructure provider integrations
- build or release workflows
- observability integrations
- console user interface (UI) surfaces
- brokered operations
Provider extensions
Provider extensions let GlobalStacks integrate with external infrastructure application programming interfaces (APIs). External provider adapters are not generally available yet; the current production path is the GlobalStacks Internal provider model.
Provider extensions should sit behind broker operations:
- capacity describe
- capacity reserve
- capacity status
- capacity release
- capacity usage
- fulfillment quote
- fulfillment create
- fulfillment status
- fulfillment cancel
- fulfillment complete
The extension reports provider facts. GlobalStacks still owns placement, tenant boundaries, runtime approval, pricing, and customer-facing cluster state.
User Interface (UI) boundaries
Extension user interface (UI) runs in sandboxed iframe surfaces and uses the GlobalStacks extension bridge. It cannot reach console internals, parent Document Object Model (DOM), browser credentials, host application programming interfaces (APIs), or tenant data unless a declared permission and brokered operation allow it.
Runtime boundaries
Extension runtime code should call typed GlobalStacks and agent application programming interfaces (APIs). It must not shell into hosts or bypass the control plane. Build egress, runtime egress, and install consent are separate declarations.