Why this exists

The problem Atlas Core solves

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

  • Split DNS causes SSO failures and Kerberos timeouts
  • Expired certificates break internal services silently
  • No CMDB means no accurate asset inventory for audits
  • Time skew >5min breaks Kerberos authentication entirely
  • No patch management = untracked CVE exposure
  • BSI OPS.1 and NIS2 Art. 21 cannot be evidenced

With Atlas Core

  • Internal DNS resolves all services reliably, split-horizon
  • step-ca issues and renews certs automatically over ACME
  • NetBox provides an audit-ready, single-source asset inventory
  • Chrony synchronises all hosts to <1ms offset
  • Ansible patch runs documented in version-controlled logs
  • Compliance evidence ready for NIS2, BSI, and ISO 27001

Architecture

From Foundation to Enterprise

Atlas Core Foundation tier architecture
Fig 1. Atlas Core — Foundation tier. All services co-located on one VM. NGINX Proxy Manager provides TLS termination for all internal services using step-ca-issued certificates.
Atlas Core Enterprise tier multi-site architecture
Fig 2. Atlas Core — Enterprise tier. EJBCA runs as the policy CA (Admin/RA GUI, HSM-backed) with Vault PKI chained beneath it for short-lived M2M certificates. PowerDNS uses native database replication (or AXFR/IXFR zone transfer) between sites; ISC Kea runs an HA lease pair. OpenCloud uses S3-compatible object storage (MinIO or AWS) for cross-site file replication. The Vault secrets engines run on the same 3-node Raft cluster.

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

Component specifications

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.

# /etc/powerdns/recursor.conf — split-horizon, Foundation tier local-address=10.10.50.10 # internal zones -> the authoritative server (:5300) forward-zones=corp.xpert-one.internal=10.10.50.10:5300 # everything else -> upstream over DNS-over-TLS forward-zones-recurse=.=9.9.9.9;1.1.1.1 dot-to-auth=yes

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.

# /etc/kea/kea-dhcp4.conf — options + pool (excerpt) "option-data": [ { "name": "domain-name-servers", "data": "10.10.50.10" }, # opt 6 -> PowerDNS { "name": "ntp-servers", "data": "10.10.50.10" } # opt 42 -> Chrony ], "subnet4": [ { "subnet": "10.10.60.0/24", "pools": [ { "pool": "10.10.60.50 - 10.10.60.240" } ] } ]

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.

# step-ca (Foundation) — enrol a host cert over ACME (auto-renewing) step ca certificate "nginx.corp.xpert-one.internal" nginx.crt nginx.key # Vault PKI (Plus) — one role per certificate type vault write pki_int/roles/server allowed_domains="corp.xpert-one.internal" server_flag=true max_ttl=2160h vault write pki_int/roles/client client_flag=true max_ttl=720h # mTLS, 30 d vault write pki_int/roles/m2m allow_any_name=true max_ttl=24h # workload identity

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.

# Secrets engines (Enterprise add-on) — separate from the PKI engine vault secrets enable -path=secret kv-v2 vault secrets enable database # Dynamic, short-lived database credentials vault write database/roles/app \ db_name=postgres \ default_ttl=1h max_ttl=24h

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.

# Dynamic Ansible inventory from NetBox # inventory/netbox.yml plugin: netbox.netbox.nb_inventory api_endpoint: https://netbox.corp.xpert-one.internal token: "{{ lookup('env', 'NETBOX_TOKEN') }}" validate_certs: true group_by: - device_roles - sites - tags query_filters: - status: "active"

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.

# /etc/chrony.conf — Atlas Core NTP server server ptbtime1.ptb.de iburst server ptbtime2.ptb.de iburst server 0.de.pool.ntp.org iburst # Allow LAN clients to sync allow 10.0.0.0/8 allow 172.16.0.0/12 allow 192.168.0.0/16 makestep 1.0 3 rtcsync logdir /var/log/chrony

Regulatory compliance

What Atlas Core satisfies

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

Install one component — no full integration required

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 GUI

Internal 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.

  • Authoritative + recursor, up to 3 internal domains
  • Forward zone to upstream DoT resolver
  • PowerDNS-Admin web GUI behind NGINX/TLS
  • Zabbix monitoring hook
  • 5-day post-install support

€ 790

Net, excl. VAT · travel included within 100km Hamburg · hardware not included

Download CRF & request quote

step-ca — Certificate Authority

smallstep/certificates · ACME · :443 HTTPS

Entry-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.

  • Root CA (offline) + intermediate CA in step-ca
  • ACME provisioner + issuance roles
  • One application integration (NGINX or internal service)
  • ACME client on one target host
  • 5-day post-install support

€ 790

Net, excl. VAT · travel included within 100km Hamburg · hardware not included

Download CRF & request quote

PKI web interface — Vault PKI / EJBCA

Vault PKI + Vault UI · or EJBCA + Admin/RA GUI · server · client · M2M

A 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.

  • Offline root → online issuing CA
  • Roles/profiles for server, client & M2M certs
  • Web GUI behind NGINX/TLS + OIDC/mTLS admin auth
  • ACME / EST / SCEP enrolment + CRL/OCSP
  • 5-day post-install support

from € 1,490

Net, excl. VAT · travel included within 100km Hamburg · hardware not included

Download CRF & request quote

Chrony — Time synchronisation

chrony 4.x · stratum 2 · PTB reference

Stratum-2 NTP server synchronised to the German national time standard (PTB Braunschweig). Required for Kerberos, SIEM log correlation, and any compliance audit trail.

  • Chrony configured to PTB stratum-1 servers
  • LAN subnet ACL for client access
  • DHCP option 42 update
  • Zabbix offset monitoring hook
  • 5-day post-install support

€ 390

Net, excl. VAT · travel included within 100km Hamburg · hardware not included

Download CRF & request quote

ISC Kea DHCP — standalone

ISC Kea 2.6 + Stork · :67/68 UDP · web dashboard

Modern, 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.

  • DHCPv4 scope for up to 3 subnets/VLANs
  • Options 6 (DNS) + 42 (NTP) + reservations
  • Stork web dashboard behind NGINX/TLS
  • Zabbix pool-utilisation monitoring hook
  • 5-day post-install support

€ 690

Net, excl. VAT · travel included within 100km Hamburg · hardware not included

Download CRF & request quote
Note: Standalone components do not include integration with other systems. If you need PowerDNS integrated with FreeIPA, Kea DHCP reservations driven from NetBox IPAM, OpenCloud connected to your Active Directory, or full PKI management across multiple hosts — that requires an integration engagement starting with an audit. Contact us to discuss scope.

Full integration

Foundation · Plus · Enterprise

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.

Foundation

5–50 users · 1 site · single server

On-site: 1 month

from € 19,500

Net, excl. VAT · fixed price scoped by audit

  • PowerDNS + PowerDNS-Admin (single node)
  • ISC Kea DHCP + Stork (single node)
  • step-ca PKI — ACME TLS (single node)
  • NGINX Proxy Manager
  • OpenCloud (local storage)
  • NetBox (IPAM + CMDB)
  • Chrony NTP server
  • Ansible patch baseline (CLI)
  • NetBird management VPN + web dashboard
  • Oxidized — router/switch config backup to Gitea
  • Documentation + runbook
Request audit to start
Enterprise

500+ users · multi-site · full cluster

On-site: 6 months

from € 135,000

Net, excl. VAT · fixed price scoped by audit

  • PowerDNS cluster (3+ nodes, anycast) + PowerDNS-Admin
  • ISC Kea DHCP HA cluster + Stork monitoring
  • EJBCA CA + Admin/RA GUI (HSM) + Vault PKI M2M + Vault secrets cluster
  • NGINX cluster + global load balancing
  • OpenCloud + federated S3
  • NetBox — full CMDB + lifecycle tracking
  • NTP hierarchy (stratum 1 GPS optional)
  • Ansible Automation Platform (AAP) GUI + GitOps (PR-gated) — Ansible + Terraform/OpenTofu
  • NetBird VPN GUI — group ACLs, posture checks, SSO/MFA
  • Oxidized config backup — fleet-wide, drift alerting to SIEM
  • ISO 27001 evidence package
  • SIEM integration (Atlas Observe)
Request audit to start

Start with an 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

Request audit engagement