Kick-off Scoping Questionnaire — On-Premise Cockpit (v2)
Use this questionnaire at the kick-off meeting of an on-premise DuoKey Cockpit (v2) engagement. It captures the technical and organisational inputs that feed the Prerequisites, the sizing, the DNS records, and the security setup. Fill in the Your input columns and check the boxes that apply; anything left open becomes a follow-up action.
This document covers the DuoKey Cockpit — configured through environment variables and deployed on OpenShift.
Onboarding has two phases — an initial delivery (docs, registry and credentials, covered by the Proof of Delivery) and the deployment project, run as a Time & Material engagement. See Onboarding & Proof of Delivery. This questionnaire prepares the deployment project.
0. Session logistics
| Field | Your input |
|---|---|
| Customer / entity | |
| Kick-off date | |
| DuoKey lead (name) | |
| Customer project lead (name / email) | |
| Target environment(s) | Production / Staging / PoC |
1. Contacts & responsibilities
Grounded in Onboarding & Proof of Delivery.
| Role | Name / email | Notes |
|---|---|---|
| Business owner | Signs off scope | |
| Technical / platform lead | Owns OpenShift | |
| Security / IAM lead | Owns identity & crypto | |
| Network / DNS owner | ||
| Credentials recipient | Who receives registry credentials (secure channel) | |
| Proof of Delivery recipient | Where to send the signed PoD | |
| Invoice recipient | Billing contact | |
| Order / PO number | Quoted on PoD and invoice |
Responsibility model (RACI): who performs the install?
- Customer-led, DuoKey advises (T&M)
- DuoKey-led, customer provides access
- Joint / shared
2. Products & use cases in scope
Which DuoKey capabilities will this deployment serve?
- Double Key Encryption (DKE) for Microsoft 365
- SQL Server EKM
- PDF Signing
- Salesforce BYOK
- SAP Data Custodian
- Workday BYOK
- PKI / SSL (certificate issuance)
- KMIP clients (databases, storage, backup appliances)
- Post-quantum / crypto-agility (CPM)
- Other: ______________________
If DKE is in scope:
| Question | Your input |
|---|---|
| Microsoft 365 tenant(s) — domain(s) | |
| Entra ID (Azure AD) tenant ID | |
| Can you register an Entra ID app for DuoKey (with admin consent)? | Yes / No |
| Sensitivity labels already in use? | Yes / No |
| Expected protected-document population |
Each DKE key service is published on its own subdomain, so DKE needs a wildcard DNS record and a matching wildcard TLS certificate (captured in §6).
If KMIP / EKM / BYOK is in scope: list the client systems (product + version) that will connect:
| System | Version | Protocol (KMIP / PKCS#11 / REST) |
|---|---|---|
3. Scale, availability & continuity
Drives the sizing tiers.
| Question | Your input |
|---|---|
| Total user population | |
| Expected peak concurrency (users active at once) | |
| Growth over 12–24 months | |
| Availability target (e.g. 99.9%) | |
| RPO (max acceptable data loss) | |
| RTO (max acceptable downtime) |
Topology:
- Single datacenter (HA within one site)
- Active/passive across two datacenters
- Active/active / multi-site
- Air-gapped (no internet egress)
4. OpenShift platform
| Question | Your input |
|---|---|
| OpenShift version (4.x) or OKD | |
| Existing cluster, or new build for DuoKey? | Existing / New |
| Control-plane / worker node counts | |
| Failure domains (racks / AZs) available | |
| CNI plugin | |
| Storage — ODF or CSI driver (name)? | |
ReadWriteOnce block + snapshots available? | Yes / No |
| Ingress — built-in Router or custom? | |
| S3-compatible object storage for backups | ODF NooBaa / MinIO / External |
Operators already available (check what is installed):
- OpenShift GitOps (ArgoCD)
- External Secrets Operator (ESO)
- PostgreSQL operator (CloudNativePG / Patroni)
- OpenShift Data Foundation
- Velero / OADP (backup)
5. Data & VM tier
The data tier can run in-cluster or on dedicated VMs — see Prerequisites → Compute sizing.
| Component | Provided by | Notes |
|---|---|---|
| PostgreSQL | Customer / DuoKey / Managed | Version, HA (primary + replicas)? |
| Redis (≥ 7) | Customer / DuoKey | In-cluster or VMs? |
| OpenBao (secrets, Raft HA) | Customer / DuoKey | Existing Vault/OpenBao to reuse? |
| Git source (for GitOps / ArgoCD) | Self-hosted / SaaS / DuoKey | GitLab, Azure DevOps, etc. |
| Question | Your input |
|---|---|
| Hypervisor for the VM tier | VMware / Proxmox / KVM-OpenStack / Other |
| Can OpenBao and PostgreSQL sit on separate hosts? | Yes / No |
6. Networking, DNS & TLS
See Prerequisites → Network and DNS records.
| Question | Your input |
|---|---|
Application base domain (e.g. duokey.example.local) | |
Wildcard DNS record available (*.<domain>)? | Yes / No |
| Public or internal-only resolution? | |
| TLS certificate source | Public CA / Internal CA / Provided by DuoKey |
| Can you issue certs for the app hostnames? | Yes / No |
| Network segmentation (app / secure / backend VLANs)? | |
| Air-gapped — mirror registry available? | Yes / No / N/A |
Confirm the required flows can be opened (see the network table):
- Clients → Ingress Router
443/TCP - Workers → OpenBao
8200/TCP - Workers → PostgreSQL
5432/TCP - ArgoCD → GitLab
443/TCP(+22/TCP) - Cluster/Velero → object storage
443/TCP - OpenBao → HSM (if applicable) — per vendor
KMIP uses a binary protocol on its own TLS port that must bypass the HTTP ingress at layer 4 (a dedicated LoadBalancer / TCP route). In production it runs with mutual TLS, so you will also need to provide the KMIP clients' client-CA bundle. Flag this now so the L4 path and certificates are planned.
7. Identity & Single Sign-On
Cockpit v2 authenticates administrators and users through your identity provider. See Secure → Identity & SSO.
| Question | Your input |
|---|---|
| Identity provider | Entra ID / Okta / Keycloak / Ping Identity / RSA SecurID Access / ForgeRock / UAE Pass |
| Protocol | OIDC (OAuth2 Authorization Code + PKCE) |
Issuer / discovery (.well-known) URL | |
| Can you register an application / client for DuoKey? | Yes / No |
| Group or role claim to map to DuoKey roles | |
| MFA enforced at the IdP? | Yes / No |
| Multi-tenant (multiple business units) in one deployment? | Yes / No |
Cockpit v2 integrates with a defined set of OIDC identity providers (SAML is not supported) — see Identity & SSO for the supported list. Each tenant configures its own IdP in the console. Cockpit also supports built-in passkey / WebAuthn MFA for local administrators.
Administrator model:
- Central admin team
- Delegated admins per tenant / business unit
- Break-glass / emergency access defined
8. Key custody & cryptography
The Cockpit API manages keys through a configurable vault backend: the built-in Software Vault (default), the DuoKey MPC KMS (DuoKey's own 3+ node cluster, optional), or a Securosys HSM for a hardware root of trust (optional). Third-party TSM backends are not part of the on-premise deployment. See Prerequisites → Key custody.
| Question | Your input |
|---|---|
| Vault backend | Software Vault (default) / DuoKey MPC KMS / Securosys HSM |
| If HSM: Securosys model / endpoint (on-prem or Cloud HSM) | |
| HSM reachability from OpenBao VMs (dedicated VLAN)? | Yes / No |
| HSM client credentials / partition available? | Yes / No |
| Existing KMS/vault to integrate or migrate from? | |
| Key ceremony / custodian requirements | |
| Regulatory constraints on key location (residency)? |
DuoKey's hardware root-of-trust partner is Securosys (PKCS#11 / KMIP), on-prem or Securosys Cloud HSM. Other integrations are discussed case-by-case with DuoKey.
9. Backup, recovery & DR
See Operate → Backup & Recovery.
| Question | Your input |
|---|---|
| Backup target (S3-compatible endpoint) | |
| Backup tooling | Velero / OADP / Customer standard |
| Backup frequency / retention policy | |
| Dedicated DR site / restore test cadence | |
| Who owns backup operations? | Customer / DuoKey |
10. Observability & SIEM
See Operate → Monitoring.
| Question | Your input |
|---|---|
| Metrics stack (Prometheus / customer standard) | |
| Logging stack (retention target) | |
| SIEM to forward audit logs to (Splunk / Sentinel / QRadar / Other) | |
| Alerting / on-call channel | |
| Log retention required (months / years) |
11. Compliance & data residency
| Question | Your input |
|---|---|
| Regulatory frameworks in scope | GDPR / SOC 2 / ISO 27001 / DORA / Other |
| Data residency constraints (country / region) | |
| Audit-log retention requirement | |
| Penetration test / security review required before go-live? | Yes / No |
| Change-management / approval process to respect |
12. Timeline & milestones
| Milestone | Target date | Owner |
|---|---|---|
| Prerequisites ready (environment, DNS, access) | ||
| Registry access & credentials received | ||
| Installation start | ||
| Pilot / PoC | ||
| Production go-live | ||
| Change windows / freeze periods to avoid |
13. Open questions & risks
| # | Item | Owner | Due |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 |
Once this questionnaire is filled in, validate the environment against the Prerequisites and confirm sizing with your DuoKey representative. Final sizing is always validated against your actual user population, document activity and availability targets — the tiers are indicative starting points, not a contractual mapping.