ASK Core Service — Overview
Core Service is the central control plane of the ASK platform. It is the single API that every other service calls for user identity, organisation management, AI model configuration, file storage authorisation, and async job dispatch. Nothing in ASK works without Core Service running.
What it does
| Responsibility |
Detail |
| Authentication & identity |
Delegates to Zitadel (OpenID Connect). Issues session tokens consumed by the frontend and all backend services |
| Organisation management |
Multi-tenant: each organisation has its own model list, feature flags, subscription plan, and user roster |
| AI model configuration |
Stores which models are enabled per org, provisions per-org Foundry LiteLLM keys via the admin API, and exposes the model list to the frontend |
| File storage authorisation |
Presigns S3 URLs for upload/download against the Ceph RGW backend. Bucket: ask-core-service |
| Async job dispatch |
Publishes Hatchet workflow triggers for bulk operations, billing metering, cron scheduling, and cron job runs |
| Machine-to-machine auth |
Issues core_services_machine_token consumed by assistant-service and KMS for internal API calls |
Integrations
| System |
Role |
| Zitadel |
IAM / SSO — user login, token issuance, org provisioning. In-cluster at core-service-zitadel.ask.svc.cluster.local:8080 |
CNPG core-pg |
Primary database — schema core_service. Accessed via core-pg-rw.ask.svc.cluster.local |
| Redis |
Session cache and short-lived KV. core-service-redis-master.ask.svc.cluster.local:6379 |
| Hatchet |
Async job queue — Core Service enqueues workflows; workers run in separate pods |
| Foundry LiteLLM |
Admin API — Core Service provisions per-org API keys and manages the model catalogue |
| Ceph RGW (S3) |
Object storage for user-uploaded files. Endpoint: https://s3.cl1.sq4.aegis.internal |
| Vault / ESO |
All secrets sourced from Vault KV v2, synced by ESO into core-service-secret |
| ArgoCD |
Delivers the Helm chart from GitLab; Stakater Reloader watches the model ConfigMap for hot-reload |
Pages in this section
| Page |
Purpose |
| Inventory (Air-Gap) |
Start here before deploying — every image, chart, secret, and Kubernetes pre-req; includes mirror commands and pre-deploy checklist |
| Discovery |
What the repo contains, how the app deploys, all findings from reading the source and chart |
| Sanitization |
Every file removed or modified before pushing to the air-gap GitLab, with the reason for each change |
| Air-Gap Alignment |
Architecture changes required to run in an air-gapped environment — images, charts, storage, auth |
| Config Updates |
Side-by-side comparison of every configuration value changed from upstream defaults |
| TOML Config Flow |
How the Dynaconf TOML travels from repo → ConfigMap → container environment |
| Sync-Wave & Ordering |
ArgoCD sync-wave assignments and resource ordering for Core Service |
| Deployment Runbook |
Step-by-step deploy runbook — the empirical record of what was run and verified |
| Onboarding Runbook |
First-time setup: Zitadel console → org → Super Admin → seed data |
| Zitadel Onboarding |
Create the org, service user, and PAT in Zitadel; wire the PAT into Vault |
| Hatchet Wiring |
How Core Service connects to Hatchet and which workflows it enqueues |
| Hatchet Test Cases |
IAM async flow test cases — verifying workers pick up Core Service jobs |
| Ceph S3 Wiring |
Bucket creation, IAM user, and presigned URL flow for file storage |