Table of contents

G-Cubed Cloud Security Architecture Overview

This document sets out the G-Cubed Cloud Security Architecture. Security policies are also available in relation to dev container deployments locally or via Github Codespaces are documented

G-Cubed Cloud is a secure, browser-based modelling workspace for running G-Cubed macroeconomic models. It combines the proprietary G-Cubed Code library, customer-specific model repositories, the SYM processor, Python tooling, and a managed cloud workspace so users can run scenarios without installing local development software.

The design goal is straightforward: give each customer a controlled modelling environment, keep durable work in GitHub, and make the cloud compute layer rebuildable. This reduces both operational drift and the direct data-exposure consequences of a security incident.

What G-Cubed Cloud Runs

G-Cubed is a macroeconomic model used for scenario analysis across a multi-region, multi-sector representation of the global economy. Users typically work with baseline projections, scenario adjustments, simulation scripts, charts, and model outputs. Those inputs and outputs are expressed as model variables rather than as records about individuals.

That matters for security. The environment is designed for high-level economic modelling, not for clinical records, payment-card processing, identity documents, consumer profile stores, or other bulk personal-information systems. Customer judgement still matters for any source material introduced into a workspace, but the normal G-Cubed workflow does not require sensitive personal or health data.

The G-Cubed platform is the software environment used to run that work. It includes Python, the G-Cubed Code library, the SYM processor used to preprocess model equations, supporting scripts, browser VS Code, and the package/runtime tooling needed to create repeatable modelling environments.

G-Cubed Cloud hosts that platform on Oracle Cloud Infrastructure (OCI), fronts access through Cloudflare, uses Coder and code-server for browser-based VS Code, and treats GitHub as the durable system of record for model code, configuration, scenario files, and approved outputs.

Users need only a browser. Code execution happens in customer-dedicated OCI workspace virtual machines, and modelling changes are persisted by committing them back to GitHub with git.

Architecture

Each customer receives a dedicated public hostname, Cloudflare Tunnel, Coder deployment, database and database user, OCI compartment, private workspace subnet, customer-scoped OCI provisioning credential, workspace template set, and GitHub application/repository access path.

G-Cubed Cloud request flow showing a customer user reaching browser VS Code through Cloudflare, a customer tunnel, a customer Coder container, and a workspace VM, with durable source and outputs stored in GitHub.

The public entry point is Cloudflare. The OCI origin is private. A customer user authenticates through the configured access path, reaches that customer’s Coder deployment, and opens browser VS Code through code-server. When the user creates a workspace, Coder provisions an OCI virtual machine in the customer’s compartment and private subnet. The workspace agent then connects back to that customer’s Coder deployment over the private OCI network.

G-Cubed Cloud customer isolation diagram showing separate customer boundaries for Coder containers, databases, GitHub repositories, Cloudflare tunnels, and OCI private workspace subnets, with a shared OCI platform layer.

The shared platform host is not a shared Coder tenancy. It runs separate customer Coder containers and customer databases on a private OCI host. Operator SSH for provisioning and maintenance goes through OCI Bastion. Workspace VMs are launched in private subnets with NAT-backed outbound internet access.

Customer OCI compartments are normally operated by McKibbin Software Group inside the MSG OCI tenancy. For customers that require direct cloud-account control, the same pattern can be deployed into a customer-owned OCI tenancy as a separate project. In that model, the customer owns the tenancy boundary and can control the surrounding OCI policies, logging, and administrative access model.

Security Mechanisms

Zero Inbound Origin Exposure

G-Cubed Cloud is designed so customer application traffic enters through Cloudflare, not through public application ports on OCI. The origin services do not expose public listeners to the internet: the platform host, customer Coder containers, databases, and workspace subnets sit on private OCI network paths, with no routable direct inbound path from an external client.

The connection model is origin-initiated. Private OCI resources use controlled outbound access, including NAT-backed egress where required, and the platform host runs cloudflared to establish an outbound tunnel from the private origin to Cloudflare. Customer browser sessions then reach the service through Cloudflare over that tunnel. External systems cannot directly address the private Coder containers, databases, platform host, or workspace subnets.

This makes Cloudflare the public control point for TLS, DDoS protection, WAF policy, bot controls, access logging, and optional Zero Trust policy. It also keeps the OCI network simple: private services remain private, and publication of a customer URL does not require exposing a public origin listener.

Corporate Identity Integration

Cloudflare Access can sit in front of each customer hostname and integrate with corporate identity providers using SAML or OIDC, including Microsoft Entra ID and Okta. That allows customer policy to enforce MFA, group membership, session duration, device posture, location rules, and other access conditions before a user reaches Coder.

Coder then applies workspace-level controls: only approved users can enter the customer deployment, and only approved templates are offered. Repository access is governed separately through customer-scoped GitHub credentials and GitHub repository permissions.

Customer Compartmentalisation

Customers are separated by hostname, Cloudflare Tunnel, Coder container, database, database user, OCI compartment, private workspace subnet, OCI provisioning credential, Coder template set, and GitHub application/repository.

A workspace created for one customer is launched into that customer’s private subnet and can reach only that customer’s Coder service path on the shared platform host. Customer private subnets are not shared with each other. This creates clear blast-radius boundaries across identity, network, compute, database state, template configuration, and repository access.

Ephemeral Compute, Durable GitHub Store

Workspace VMs are runtime environments, not the authoritative data store. A stopped workspace may resume on the same OCI VM for convenience, but the durable collaboration and recovery path is GitHub: source code, notebooks, SYM files, scenario adjustments, dependency manifests, and approved outputs should be committed back to the customer repository.

If a workspace is deleted or rebuilt, the environment is recreated from the customer template, pinned workspace host image, and repository contents. This keeps recovery practical and avoids relying on long-lived, manually configured machines.

Customer GitHub repositories are normally built and maintained by McKibbin Software Group with strict access controls. If required, a customer can own and operate the repository directly as a separate engagement, with repository permissions, branch rules, and organisation controls managed by the customer.

GitHub as the Secure Source of Truth

GitHub provides mature controls for private repositories, branch protection, pull-request review, repository permissions, SAML SSO and 2FA in enterprise environments, audit logs, secret scanning, Dependabot vulnerability alerts, and security reporting.

G-Cubed Cloud uses customer-specific GitHub App credentials for workspace repository access. That keeps repository access separate from Coder login and allows access to be reviewed, restricted, or revoked using normal GitHub organisation controls.

Controlled Python and Modelling Runtime

Workspaces boot from operator-published OCI custom images rather than installing the modelling stack at first login. The current direct workspace image profile bakes in the supported prerequisites: Git, Node, Codex CLI, uv, sym, code-server, browser VS Code extensions, the G-Cubed VSIX, and the gcubed-build-switcher Python package.

Images are versioned in an operator catalog by alias, OCI image OCID, region, architecture, runtime mode, profile, version, build time, and source revision. Customer configuration references catalog aliases rather than raw image IDs, and only active catalog entries can be used for template generation.

At workspace boot, cloud-init performs fast compatibility checks for required commands and baked assets. If a required command or asset is missing, that is treated as an image-build problem, not as a reason to install ad hoc packages on a customer VM.

Python project dependencies are managed through standard manifests and, where applicable, lock files, with uv available for reproducible environment creation. The SYM processor is compiled from source and included as a purpose-built executable for preprocessing G-Cubed model equations. Purpose-built G-Cubed executables, extensions, and launchers are packaged into the image so users receive a consistent modelling environment.

The practical result is that the operating-system, toolchain, editor, and modelling prerequisites are captured into an immutable workspace image at publication time. Rebuilds produce new image aliases rather than silently changing existing workspaces, giving the platform a clear path for repeatable rollout, rollback, and assurance review.

Infrastructure as Code and Repeatability

Shared and customer infrastructure is provisioned through Terraform, Ansible, and explicit operator scripts. Non-secret customer configuration is stored in the repository. Secrets such as Cloudflare tokens, GitHub client secrets, OCI private keys, and customer identity material stay outside the repo.

Reapplying a customer deployment recreates the customer stack, tunnel, database bindings, Coder configuration, and workspace templates from declared configuration. This reduces hidden manual state and gives security reviewers a clearer chain from configuration to deployed infrastructure.

Monitoring and Assurance Points

The architecture creates several natural evidence sources: Cloudflare access and tunnel logs, Coder workspace activity and container logs, GitHub audit/security events, OCI compartment and instance events, Terraform history, and Ansible run output.

Retention, export, alerting, SIEM integration, vulnerability scanning, penetration testing, DLP, incident reporting, and customer assurance packs can be aligned to the customer’s governance model.

Data and Privacy Posture

The platform is intended for economic models, code, configuration, scenario adjustments, and model outputs. It is not intended to host health records, payment-card systems, identity-document stores, or bulk personal data. This materially reduces the privacy and clinical-regulatory risk profile compared with platforms designed to process sensitive personal or health information.

Data residency can be controlled at the cloud placement layer. The default OCI workspace host image catalog is built in the Sydney OCI region (ap-sydney-1), and customer compartments and subnets are normally kept in that Australian region.

GitHub repository ownership, GitHub organisation policy, customer workspace location, Cloudflare data-localisation options, logging retention, and any customer-managed key requirements can be agreed as part of the engagement.

Shared Responsibility

McKibbin Software Group is responsible for the secure workspace factory: platform architecture, customer isolation model, workspace templates, host image publication process, infrastructure automation, operational runbooks, and the standard G-Cubed Cloud deployment pattern.

The customer remains responsible for data classification, user approval, corporate identity policy, GitHub organisation membership, repository permissions, and deciding which model inputs and outputs are appropriate for the environment.

This split keeps the model practical. McKibbin Software Group controls the repeatable modelling environment; the customer controls who may enter it and what data may be used in it.

Technical References

G-Cubed and SYM

OCI Concepts

Workspace, Ingress, and Repository Controls

This site uses Just the Docs, a documentation theme for Jekyll.