Atlas Core
Foundation Infrastructure — DNS · DHCP · PKI · Proxy · File Sync · Inventory · CMDB · NTP · Patch
The layer every other Atlas product depends on. No identity management, no firewall, no monitoring without Atlas Core running first.
Why this exists
Most organisations of 50–500 people run their internal services on a mix of ad-hoc decisions: DNS is handled by the router, certificates are self-signed and expired, file sharing is a mix of Dropbox and shared drives, nobody knows what IP ranges are in use, and the CMDB is a spreadsheet someone stopped updating two years ago.
This is not a failure of intent — it is a failure of having the right foundation in place. Identity management cannot be centralised without reliable internal DNS. VPN certificates cannot be managed without a certificate authority. Log timestamps are worthless without synchronised time across all hosts. Patch management cannot be automated without an accurate inventory.
Without Atlas Core
With Atlas Core
Architecture
Hosting & provisioning server. Every Atlas Core service runs on a single internal server built on Proxmox VE — one host at Foundation (mini-PC class, e.g. Minisforum MS-01), an HA pair at Plus (1U rack, ECC), and a cluster at Enterprise. The same host carries the provisioning plane that builds and maintains every node: PXE/preseed for the hardened Debian 12 base, Ansible + Gitea (AWX/AAP at higher tiers), Terraform/OpenTofu, and NetBox as the source of truth. The hardware and software specification is defined per tier so the box that hosts the services also provisions them.
Technical reference
PowerDNS — Internal DNS with a web interface
PowerDNS Authoritative 4.9 + Recursor 5.1 + PowerDNS-Admin GUI · SQLite/MySQL backend · HTTP API
PowerDNS replaces the router's built-in DNS and provides split-horizon resolution: the Authoritative server holds internal zones (.corp, .internal), the Recursor forwards them locally and recurses everything else to an upstream resolver (Quad9 9.9.9.9 or Cloudflare 1.1.1.1 over DoT). Zones and records are managed in the PowerDNS-Admin web GUI — no hand-edited zone files, no manual serial bumps — and reconciled from NetBox over the HTTP API. Required by Kerberos (SRV records), FreeIPA, and any SSO where clients resolve internal service hostnames.
Prometheus metrics scraped by Atlas Observe; the PowerDNS-Admin GUI is published through NGINX Proxy Manager with TLS.
ISC Kea — DHCP with a web interface
ISC Kea 2.6 (kea-dhcp4/6 + Control Agent) + Stork dashboard · memfile/MySQL leases · REST API
Kea is the modern, API-driven replacement for the router's DHCP. It leases addresses per VLAN and hands every client its core services automatically — DNS (PowerDNS) via option 6 and NTP (Chrony) via option 42 — so no device is ever manually configured. Subnets, pools and reservations mirror NetBox IPAM (the address-plan source of truth). Pool utilisation, live leases and server health are visible in the Stork web dashboard; at Plus/Enterprise a second Kea runs as an HA lease pair.
The Kea Control Agent REST API drives Stork and automation; the Stork GUI is published through NGINX Proxy Manager with TLS.
PKI & Certificate Management — with a web interface
Tiered CA: step-ca (Foundation) · HashiCorp Vault PKI + Vault UI (Plus) · EJBCA + Admin/RA GUI (Enterprise) — server, client & M2M certificates
One trust root per customer, generated offline and kept air-gapped; only an issuing intermediate is ever online. The PKI scales by tier and is always managed through a web interface — never hand-rolled OpenSSL. Foundation runs step-ca for automated ACME TLS. Plus upgrades to HashiCorp Vault PKI with the Vault web UI: issuing CA plus per-type roles (server, client, M2M) issued over ACME/API. Enterprise runs EJBCA as the full policy CA — Admin GUI (mgmt VLAN, mTLS) and RA GUI (self-service), certificate profiles, approvals, CRL/OCSP, EST/SCEP/CMP, HSM-backed — with Vault PKI chained beneath it as the short-lived M2M issuing engine. Every issue/renew/revoke is audited to Atlas Observe.
Certificate types: server (TLS, 90 d, ACME) · client (mTLS, 30 d, RA/EST/SCEP) · M2M (workload identity, ≤ 24 h, Vault AppRole/JWT). Admin surfaces are published only through NGINX Proxy Manager with TLS.
HashiCorp Vault OSS — Secrets Management Enterprise add-on
hashicorp/vault · Raft storage backend · also the Plus-tier PKI engine (above)
Beyond issuing certificates (the PKI role above), Vault is offered as an Enterprise-tier add-on for secrets: dynamic database credentials, automated API-key rotation, and a versioned K/V secret store with full audit logging — every secret access is forwarded to Graylog. The secrets engines are intentionally not deployed on the Foundation tier: the operational overhead (unseal keys, Raft quorum) is only warranted once an organisation has dynamic-secret requirements.
At Enterprise tier: Vault runs as a 3-node Raft cluster with auto-unseal via AWS KMS or Azure Key Vault.
NetBox — Network Inventory & IPAM
netbox-community/netbox · 4.x · PostgreSQL backend · Redis caching
NetBox is the single source of truth for IP address management (IPAM), network device inventory, and the CMDB — there is no second inventory tool. Every subnet, VLAN, prefix, and device is registered here before being provisioned. Ansible reads the NetBox inventory API dynamically — no more static inventory files. Custom fields extend NetBox to track asset lifecycle (lease-end, warranty-expiry, refresh cycle), making it the single system of record for Atlas Blueprint hardware lifecycle too.
Chrony — NTP Time Synchronisation
chrony 4.x · stratum 2 server · NTP pool or GPS reference
All hosts must be time-synchronised to within 5 seconds for Kerberos to function, and to within 1ms for meaningful log correlation in a SIEM. Chrony is configured as a stratum-2 NTP server, synchronising from ptbtime1.ptb.de (German national standard, Physikalisch-Technische Bundesanstalt). All internal clients receive the NTP server address via DHCP option 42. NTP offset is monitored in Zabbix with alerting on offset >50ms.
Regulatory compliance
Each control below maps to the Atlas Core component that satisfies it and the evidence it produces.
| Regulation / Control | Requirement | Atlas Core component | Evidence |
|---|---|---|---|
| NIS2 Art. 21(2)(e) | Use of secure communication channels; encryption of data in transit | step-ca — all internal TLS certs; NGINX — TLS termination | Cert inventory export from step-ca |
| NIS2 Art. 21(2)(j) | Patch and vulnerability management — maintain up-to-date software | Ansible patch management — weekly runs, documented in AWX job history | AWX job history export; before/after CVE scan |
| GDPR Art. 25 | Data protection by design — access control, encryption by default | step-ca — TLS everywhere by default; NGINX — no plaintext HTTP internally | step-ca audit log; NGINX access log review |
| GDPR Art. 32(1)(a) | Pseudonymisation and encryption of personal data | OpenCloud — server-side encryption; step-ca — key management | OpenCloud encryption config export |
| BSI OPS.1.1.3 | Patch management — documented policy, tracked application of patches | Ansible + AWX — all patch runs version-controlled in GitLab | Git history of Ansible playbooks + AWX job log |
| BSI OPS.1.2.1 | Change management — all changes documented and traceable | NetBox — change history per object (built-in journal & changelog) | NetBox changelog export |
| DORA Art. 9(2) | ICT asset inventory — complete and up-to-date register of ICT assets | NetBox — single CMDB for all network devices, IPs, and IT assets | NetBox API / report export |
| CRA Annex I §1 | Products shall be delivered without known exploitable vulnerabilities | Ansible patch management ensures all deployed components are at latest stable release | Greenbone scan post-deployment (Atlas Perimeter) |
Standalone installation
Each component can be deployed independently without committing to a full Atlas Core integration. Fill in the Customer Request Form, we scope the job, we deploy. Fixed price, fixed scope, 5-day post-install support included.
PowerDNS — standalone
PowerDNS 4.9 + PowerDNS-Admin · :53 UDP/TCP · web GUIInternal DNS with a browser interface for your organisation. Split-horizon: internal zones resolved locally, external queries forwarded over DNS-over-TLS. Zones and records managed in the PowerDNS-Admin GUI. Replaces router DNS immediately.
€ 790
Net, excl. VAT · travel included within 100km Hamburg · hardware not included
Download CRF & request quotestep-ca — Certificate Authority
smallstep/certificates · ACME · :443 HTTPSEntry-level internal CA for your organisation. Root CA generated offline, intermediate CA in step-ca. Issues certificates for internal services automatically over ACME with short TTLs. Upgradeable to the Vault PKI / EJBCA web interface below.
€ 790
Net, excl. VAT · travel included within 100km Hamburg · hardware not included
Download CRF & request quotePKI web interface — Vault PKI / EJBCA
Vault PKI + Vault UI · or EJBCA + Admin/RA GUI · server · client · M2MA managed PKI with a browser interface for the full certificate lifecycle. Vault PKI (with the Vault UI) or EJBCA (Admin + RA GUI, certificate profiles, HSM). Issues and revokes server (TLS), client (mTLS) and M2M (workload identity) certificates, with CRL/OCSP.
from € 1,490
Net, excl. VAT · travel included within 100km Hamburg · hardware not included
Download CRF & request quoteChrony — Time synchronisation
chrony 4.x · stratum 2 · PTB referenceStratum-2 NTP server synchronised to the German national time standard (PTB Braunschweig). Required for Kerberos, SIEM log correlation, and any compliance audit trail.
€ 390
Net, excl. VAT · travel included within 100km Hamburg · hardware not included
Download CRF & request quoteISC Kea DHCP — standalone
ISC Kea 2.6 + Stork · :67/68 UDP · web dashboardModern, API-driven DHCP with a browser dashboard. Leases addresses per VLAN and hands out DNS (option 6) and NTP (option 42) automatically. Live leases and pool utilisation in the Stork web dashboard. Replaces router DHCP cleanly.
€ 690
Net, excl. VAT · travel included within 100km Hamburg · hardware not included
Download CRF & request quoteFull integration
Full Atlas Core integration requires an audit first. The audit (2–3 weeks) maps your existing environment, identifies gaps, and produces a statement of work. Integration is then priced per project. On-site engineer included for the duration.
5–50 users · 1 site · single server
from € 19,500
Net, excl. VAT · fixed price scoped by audit
50–500 users · 1–5 sites · HA pair
from € 62,000
Net, excl. VAT · fixed price scoped by audit
500+ users · multi-site · full cluster
from € 135,000
Net, excl. VAT · fixed price scoped by audit
Before any integration engagement, XpertOne conducts a 2–3 week technical audit of your existing environment. The audit produces a gap analysis, architecture recommendation, bill of materials, and statement of work. The audit is a separate paid engagement — it is not a free sales activity. This ensures the integration scope is accurate and protects both parties from scope creep.
Week 1
Discovery — network scan, existing DNS/PKI/inventory review, stakeholder interviews
Week 2
Gap analysis — map current state to target regulation (NIS2/BSI/DORA), identify missing controls
Week 3
Architecture design — proposed Atlas Core deployment, BOM, integration dependencies, timeline
Deliverable
Audit report + statement of work + fixed-price integration proposal
Copyright © XpertOne Security Consulting GmbH. All Rights Reserved. | Impressum | Datenschutz