CMDB as config master — deployment config from ServiceNow

Beyond mapping services into the CMDB, SARC can make ServiceNow CMDB the master of non-secret deployment configuration. Replica counts, CPU/memory limits, and feature-flag environment variables live on the service’s CI in ServiceNow — per environment — and the pipeline renders them into the actual deployment. Change a value in ServiceNow (or the portal), and it flows to the running pods with full audit and governance.

Secrets never go here

CMDB holds non-secret tunables only. Credentials stay in Secrets Manager / Key Vault via external-secrets. An allow-list of permitted keys is the trust boundary — a stray or hostile row can never set an image tag or a service account.

User story

As a platform / compliance operator, I want a service’s deployment tunables (replicas, resources, feature flags) to live in ServiceNow CMDB as governed, audited config, per environment, so that a change is a controlled CMDB edit — traceable, reversible, and visible to auditors — instead of an untracked edit to a values file.

The model

Config rows are cmdb_key_value records attached to the Application Service CI (cmdb_ci_service) — the CSDM-correct owner of app-level config. Each row is scoped to an environment by its tag (<cloud>-<env>, e.g. aws-dev):

Key	Value	Tag
replicaCount	2	aws-dev
replicaCount	3	aws-qa
replicaCount	4	aws-prod
resources.limits.cpu	300m	aws-dev
entry.env.FEATURE_HAT	true	aws-dev

So dev, qa, and prod can each carry different values on the same service.

How it flows

⛶ Fullscreen

flowchart LR
  A[ServiceNow CMDB · cmdb_key_value on the service CI] --> B[Pipeline reads allow-listed keys per env]
  B --> C[Renders a Helm values file per cloud + env]
  C --> D[GitOps branch]
  D --> E[ArgoCD sync]
  E --> F[Running pods reflect the CMDB values]

The pipeline is a passive consumer: it reads only allow-listed keys, validates the values, writes a per-environment values file to the GitOps branch, and ArgoCD applies it. Production stays manual-sync by policy.

Edit it from the portal

Each service’s config appears on its service detail page under a Deployment Config card. Everyone sees the values (with the environment scope); ADMINs edit a value inline. Edits write straight back to ServiceNow cmdb_key_value, are validated against the same allow-list the pipeline uses, and are recorded in the portal’s hash-chained audit log. The card self-hides where no config exists.

Why it matters

Deployment configuration becomes governed data in your system of record, not scattered YAML. Every change is a CMDB edit an auditor can follow, per-environment values are explicit, and the same allow-list protects both the pipeline and the portal editor. Full reference: docs/ci/servicenow/CMDB-CONFIG.md.