CT-FAC · Enterprise Entry Floor

CT-FAC · First Enterprise Client · Wave 0 Complete

Canadian Tire's managed-dev-001 sub is the fleet's first real enterprise entry floor. The EOSE agent (pemos-portal:latest) is already deployed in their eose-entry namespace. The AKS cluster is managed via Terraform Enterprise (terraform.cantire.com). What we're building: sovereign entry/exit protocol, merostone evidence store, GPU pool wiring, and the full fleet knowledge transfer pattern that every future enterprise will follow.

Three Floors · One Protocol

EOSE SOVEREIGN

EOSE Fleet

sub 427873ee · eosefleetacrdev.azurecr.io

pemos-portal v620 deployed
eoseentry.azurecr.io (Standard ACR)
GPU: T4×3 + H100×1 + adelicpool
master.dev testing sovereign
Cosmos sco entry/exit store
ct-builder-gateway live

ENTERPRISE CLIENT

Canadian Tire

sub 9ef1107f · cantirecorp.onmicrosoft.com

AKS: managed-dev-001-test-cc-aks
eose-entry namespace exists
pemos-portal:latest running
ct-azure-ops SA created
Contributor + UAA on sub
Databricks workspace (private)
3 Key Vaults (akv01/02/03)
kubelet MSI: no cross-sub ACR role
eoseentry ACR: not in CT sub
NCadsH100v5: 0/256 (needs GPU pool)

SHARED PROTOCOL

Entry Standard

ct-entry-test · Cosmos sco · merostone

ct-builder-gateway wired
merostone-store live
mdsms-router live
mrcp-agent fixed (512Mi)
Zitadel SSO auth gate
imagePullSecrets → CT AKS
Cosmos sco → CT storage
H100 pool in CT sub
Flux GitOps wire

Subscription Map · Two Tenants · One Protocol

Item	EOSE Sub (427873ee)	CT Sub (9ef1107f)	Status
Tenant	e37b389d (EOSE)	bd6704ff (cantirecorp)	Both active
AKS Cluster	aks-eose-aaas-dev	managed-dev-001-test-cc-aks	Both running
Entry Namespace	ct-entry-test	eose-entry	Both live
Portal Image	eosefleetacrdev.azurecr.io/pemos-portal:v620	eoseentry.azurecr.io/pemos-portal:latest	CT uses eoseentry (cross-sub)
Kubelet MSI	AKS-managed	2fa83671 (policytesting-kubelet-msi)	No ACR role in CT sub
GPU Quota T4	12/24 vCPUs used	0/0 (need quota request)	T4 not available in CT
GPU Quota H100	40/64 vCPUs	0/256 vCPUs FREE	256 vCPUs = 6 H100 nodes!
A10 GPU	0 (NVADSA10v5=0/512 in EOSE)	0/512 vCPUs FREE	MASSIVE unused quota
Total vCPUs	78/156	6/1590 (1584 free!)	CT sub barely touched
Databricks	none	azurerm_databricks_workspace.main	Private endpoint, clusters configured
Key Vaults	5 KVs	akv01 + akv02 + akv03	All private endpoint
Storage	20+ accounts	storage1: auto-trigger/clusterlogs/datascience/featurestore/model-outputs	ML-ready containers
Terraform	az CLI direct	terraform.cantire.com (Enterprise)	TFE logged in, state managed
Flux GitOps	Flux in ct-entry-test	flux extension on AKS cluster	Both have Flux

⚡ CT Sub GPU Quotas · canadacentral · sub 9ef1107f

H100 (NCadsH100v5)

0 / 256 vCPUs

256 FREE = 6 H100 nodes

A10 (NVADSA10v5)

0 / 512 vCPUs

512 FREE = massive A10 fleet

AMD (NVSv4)

0 / 256 vCPUs

256 FREE

Total Regional vCPUs

6 / 1590

1584 FREE

Note: NCASv3_T4 = 0/0 in CT sub — T4 quota needs a separate request. H100 and A10 have enterprise-scale quota already provisioned. This is a managed enterprise subscription — Canadian Tire has pre-allocated GPU capacity at scale.

What We Can Create in CT Sub (NCadsH100v5 = 256 vCPUs)

PLAN · H100 ARC pool

NC40ads_H100_v5 × 4

160 vCPUs · 4 H100s in CT sub
ARC Fleet Runner enterprise tier
BACHRHONE-CT = 72b enterprise model

PLAN · A10 inference pool

NVADSA10v5 × 8 nodes

~192 vCPUs · A10 24GB VRAM each
Inference + embedding workloads
Cost-effective vs H100 for serve

PLAN · Databricks GPU

Wire GPU to Databricks

storage1 has featurestore+model-outputs
GPU cluster → Databricks cluster1
EOSE fleet runners as Databricks jobs

P0 · Blocking Issues

P0 · BLOCKING

IRF-CT-ACR-001 · imagePullSecrets

eoseentry.azurecr.io is in EOSE sub (427873ee). Kubelet MSI (2fa83671) in CT sub has no AcrPull role there. Image pull fails silently — currently only works because pemos-portal:latest was pre-pulled.

Fix A: az role assignment create --assignee 2fa83671 --role AcrPull --scope /subscriptions/427873ee/.../eoseentry
Fix B: Create CT-local ACR, mirror images → eoseentry-ct.azurecr.io

P0 · BLOCKING

IRF-CT-MSI-001 · Kubelet MSI no sub access

az login --identity --client-id 2fa83671 → "No access configured". The kubelet MSI works for IMDS token (expires_on returned) but has no ARM permissions in CT sub. Bearer token → AuthorizationFailed on resourcegroups/read.

az role assignment create --assignee da88ec22 --role Reader --scope /subscriptions/9ef1107f
Or assign custom role: only needs ACR pull + storage read

P1 · IMPORTANT

IRF-CT-VNET-001 · VNet list empty

az network vnet list --resource-group managed-dev-001-dr1l-cc-rg returned []. Databricks and AKS have private endpoints but VNet may be in a different RG or peered from hub. Need to map the full network topology.

az network vnet list --subscription 9ef1107f (no RG filter)
Check if hub VNet is in separate RG (managed-dev-001-hub-cc-rg pattern)

P1 · IMPORTANT

IRF-CT-GPU-001 · No T4 quota in CT sub

NCASv3_T4 = 0/0. H100 (256) and A10 (512) quotas are massive but T4 is zero. KRSRHONE cap needs T4. Either request T4 quota via Azure support or promote KRSRHONE to A10 (cost increase) or repurpose to use H100 for all 3 caps.

Submit quota increase: Standard NCASv3_T4 Family → 24 vCPUs
Or: use NC4ads_A10_v4 as KRSRHONE replacement (24GB A10 vs 16GB T4)

Solved Issues (Wave 0)

SOLVED · Wave 0

IMDS token works

kubectl run imds4/imds5 with client_id=2fa83671 → expires_on returned. Kubelet MSI CAN get ARM + ACR tokens. Just needs role assignments wired.

SOLVED · Wave 0

eose-entry namespace live

ct-azure-ops ServiceAccount created. pemos-portal:latest running. Contributor + UAA role assigned to SA objectId 5d30b993.

SOLVED · Wave 0

Terraform Enterprise connected

kewin_joffe authenticated to terraform.cantire.com. State list shows full infra: AKS + Databricks + 3 KVs + storage + NSGs + MSIs + role assignments.

SOLVED · Wave 0

Policy enforcement = dryrun

k8sazurev2containerallowedimages enforcementAction = dryrun. External images (curlimages/curl) can run. Policy gate is advisory not blocking.

CT Sub Full Resource Map · sub 9ef1107f · managed-dev-001

Resource	Name / Details	Status	EOSE Use
AKS	managed-dev-001-test-cc-aks RG: managed-dev-001-dr1l-cc-rg Node pool: web001 (DDSv5, 3 nodes = 6 vCPUs)	Running · Flux enabled	eose-entry NS · pemos-portal live
Databricks	azurerm_databricks_workspace.main cluster1: configured Private endpoint + private DNS	Live	Wire GPU runners as Databricks jobs
Storage	storage1 (Standard_LRS) Containers: auto-trigger · clusterlogs datascience · featurestore · model-outputs Private endpoint (blob)	Live	model-outputs → EOSE ARC results
Key Vaults	akv01 · akv02 · akv03 All private endpoint KV secrets: azdb-spa-id/key/spn/spn-key kube-config + cert secrets in AKS KV	Live	Wire EOSE API keys into CT KVs
MSIs	azdb-policymlab-msi control-plane-msi policytesting-kubelet-msi (2fa83671) corp-dev-001-azdb-policym-msi	All provisioned	Kubelet MSI needs ACR + ARM roles
NSGs	adb-container · adb-lz · adbhost-public Route table: rt_databricks	Applied	Add EOSE gateway inbound rules
GPU Quota	NCadsH100v5: 0/256 vCPUs NVADSA10v5: 0/512 vCPUs NVSv4: 0/256 vCPUs Total vCPUs: 6/1590	MASSIVE available	Add H100 + A10 node pools to AKS
Terraform	terraform.cantire.com (Enterprise) Workspace: corp-dev-001/2rl5-cc-rg Branch: add-aks	Authenticated	Add EOSE modules to TF state
Flux GitOps	azurerm_kubernetes_cluster_extension.flux[0] On managed-dev-001-test-cc-aks	Enabled	Wire EOSE fleet-sync repo as Flux source

Onboarding Protocol · Wave 0 Done · Wave 1 Next

✓

Wave 0 · Foothold Established

eose-entry namespace, ct-azure-ops SA, pemos-portal:latest running, IMDS token working, TF Enterprise connected, policy=dryrun confirmed.

✓ COMPLETE · 2026-04-02

Fix ACR Pull · imagePullSecrets or cross-sub role

Kubelet MSI needs AcrPull on eoseentry ACR. Two options: grant cross-sub role (quick) or mirror eoseentry into a CT-local ACR (clean).

az role assignment create \
  --assignee 2fa83671-2431-4694-aa60-a38ba579102d \
  --role AcrPull \
  --scope /subscriptions/427873ee.../eoseentry

✗ BLOCKING · IRF-CT-ACR-001

Wire ct-builder-gateway into CT AKS

Deploy ct-builder-gateway (eoseentry.azurecr.io/openclaw:latest) into eose-entry namespace. Point it at EOSE fleet gateway. This is the agent that will run in CT's environment.

kubectl apply -f ct-builder-gateway.yaml -n eose-entry
# Gateway token: ct-fac-eose-2026
# Gateway: wss://ct-fac.eose.ca:18830

○ NEXT · after IRF-CT-ACR-001

Add H100 node pool to CT AKS

256 vCPUs of H100 quota sitting unused. Add NC40ads_H100_v5 node pool. Label it role=eose-inference. Wire Ollama enterprise instance serving qwen2.5:72b inside CT's own sub.

az aks nodepool add \
  --cluster-name managed-dev-001-test-cc-aks \
  --resource-group managed-dev-001-dr1l-cc-rg \
  --name h100pool \
  --node-vm-size Standard_NC40ads_H100_v5 \
  --node-count 1 --labels role=eose-inference

○ PLANNED · IRF-CT-GPU-002

Wire Merostone + Cosmos evidence store

Deploy merostone-store into eose-entry. Wire it to CT's storage1 account (private endpoint). Route findings/evidence/assessments into CT's own storage so data sovereignty is clean — their data never leaves their sub.

kubectl apply -f merostone-ct.yaml -n eose-entry
# STORAGE_CONN_STR → CT akv01 secret
# Containers: findings, evidence, assessments

○ PLANNED · IRF-CT-MERO-001

Flux GitOps wire · fleet-sync as CT source

Flux is already enabled on managed-dev-001-test-cc-aks. Add fleet-sync repo (or a CT-specific branch) as a Flux GitRepository source. Enables declarative EOSE fleet updates into CT's cluster without kubectl access.

flux create source git eose-fleet \
  --url=https://github.com/eose-sre/openclaw-fleet \
  --branch=feat/ct-entry \
  --namespace=eose-entry

○ PLANNED · Wave 2

Merostone · Evidence Architecture for CT

Merostone is the fleet's sovereign evidence store. For CT, it runs inside eose-entry namespace, backed by CT's own storage1 account. Their data never leaves their Azure sub. EOSE sees the evidence hashes (SHA-256) but not the data itself. Clean data sovereignty.

📋

findings

What the EOSE agent found in CT's environment. Policy gaps, config drift, security posture. Partition key: findingId. Read-only for CT team.

Storage container: findings · in storage1

🔬

evidence

Raw artifacts: kubectl outputs, az CLI results, Terraform state diffs. Immutable audit trail. Partition key: assessmentId. Full chain of custody.

Storage container: evidence · in storage1

⚖️

assessments

Structured assessments: LSOS audit scores, STE-6 ratings, Canon compliance. The verdict layer. Links back to findings + evidence. Exportable as PDF.

Storage container: assessments · in storage1

🔐

Sovereignty Protocol

EOSE never reads CT data directly. Only SHA-256 hashes are shared cross-sub. CT's akv01 holds the encryption keys. EOSE holds the verification logic.

○ Protocol defined · wiring pending IRF-CT-MERO-001

📊

Databricks Integration

CT's Databricks workspace has datascience + featurestore + model-outputs containers. EOSE fleet runners can push ARC/Lean results to model-outputs via Databricks jobs.

○ PLANNED · Wave 3

🌐

Exit Protocol

When CT exits: export findings+evidence+assessments → SHA-256 parity check → signed exit receipt. They keep the data. EOSE keeps the methodology. Clean offboard.

○ STANDARD · applies to all enterprise clients

Learning Log · What This Client Taught Us

CT is Client #1. Everything we learn here becomes the standard for every future enterprise. This tab is the institutional memory for the CT onboarding pattern.

LESSON 1 · IMDS IDENTITY

Multiple MSIs → must specify client_id

First IMDS call returned "Multiple user assigned identities exist". Always pass &client_id= in IMDS requests in enterprise subs. The kubelet MSI clientId is the right one: 2fa83671.

LESSON 2 · CROSS-SUB ACR

eoseentry ACR is in EOSE sub, not CT sub

az acr show eoseentry in CT sub → not found. The ACR lives in EOSE sub 427873ee. For enterprises, either grant AcrPull cross-sub OR maintain a mirrored registry per client. Mirror is cleaner long-term — data sovereignty, cost visibility, version pinning.

LESSON 3 · BEARER TOKEN SCOPE

Token acquired ≠ authorization to act

IMDS returned a 2383-char token (valid JWT) but ARM returned AuthorizationFailed. The kubelet MSI can get tokens but has no RBAC roles assigned in the CT sub. Token ≠ access. Always verify role assignments separately from token acquisition.

LESSON 4 · ENTERPRISE GPU QUOTAS

Managed enterprise subs have pre-allocated GPU at scale

CT's sub has 256 H100 vCPUs and 512 A10 vCPUs pre-provisioned. Enterprise managed subscriptions often have quota pre-arranged with Microsoft. Don't assume enterprise = limited. The GPU fleet potential is bigger than EOSE's own sub for most clients.

LESSON 5 · POLICY ENFORCEMENT

k8sazurev2containerallowedimages = dryrun in dev

Policy gates in enterprise K8s clusters are often advisory in dev environments. Check enforcementAction early. dryrun = you can run any image but violations are logged. This is the Wave 0 window — work quickly before they enable enforcement.

LESSON 6 · TERRAFORM ENTERPRISE

Enterprise infra is IaC-first, not CLI-first

CT's entire infra (AKS, Databricks, KVs, storage, NSGs, MSIs, roles) is in TFE state. CLI changes will drift from state. For enterprise onboarding: always propose as Terraform modules, not ad-hoc az CLI. The add-aks branch = the right pattern to follow.

IRFs Open

IRF-CT-ACR-001 · P0

AcrPull cross-sub role for kubelet MSI (2fa83671) on eoseentry.azurecr.io

IRF-CT-MSI-001 · P0

Kubelet MSI Reader/AcrPull role in CT sub. IMDS token works, ARM auth fails.

IRF-CT-VNET-001 · P1

Map CT network topology. VNet not in managed-dev-001-dr1l-cc-rg — find hub VNet.

IRF-CT-GPU-001 · P1

T4 quota = 0 in CT sub. Request NCASv3_T4 24 vCPUs or use A10 as alternative.

IRF-CT-GPU-002 · P2

Add NC40ads_H100_v5 node pool (1 node = 40 vCPUs) to CT AKS. 256 vCPU quota available.

IRF-CT-MERO-001 · P2

Deploy merostone-store in eose-entry. Wire to storage1. Sovereign data model: hashes only cross-sub.