Security

Four verification layers.
Zero tolerance for partial state.

ntkDeploy is designed for intranet-only operation. No internet-facing surface. No cloud authentication. Every deployment is gated, verified, and logged before a single byte reaches a device share.

Gate Architecture

Fail-Closed Deploy Gate

The deployment wizard enforces a four-stage verification pipeline before the deploy button becomes active. Each stage must pass independently. Failure at any stage halts the pipeline — there is no override path in the standard workflow.

The gate operates at the UI layer: the cubit checks each condition and holds state as a sealed discriminated union. The deploy action is only available when the union resolves to GateOpen.

Stage 1 Connectivity Gate

Calls /capabilities and /readyz on the Policy Manager endpoint. Both must return 200.

pass → proceed
Stage 2 Ownership Mapping

Every device path in the assignment must have an owner. Unassigned paths block the gate regardless of policy status.

pass → proceed
Stage 3 Preflight API

Calls preflightBulkVerify against Policy Manager V2. Any blocking finding prevents deployment.

pass → proceed
Stage 4 Snapshot Retrieval

A deterministic policy snapshot is fetched and its hash verified. The snapshot is embedded in the deployment artifact.

pass → gate open

Gate Error Codes

Code Stage Meaning
E_GATE_CONNECT 1 — Connectivity Policy Manager endpoint unreachable or returning non-200
E_GATE_OWNERSHIP 2 — Ownership One or more device paths have no assigned owner
E_GATE_PREFLIGHT 3 — Preflight preflightBulkVerify returned blocking findings
E_GATE_SNAPSHOT 4 — Snapshot Snapshot fetch failed or hash mismatch

Policy Layer

ABAC Policy Enforcement

ntkDeploy integrates with Policy Manager V2 to enforce attribute-based access control at the deployment layer. ABAC policies are evaluated server-side; the deploy tool never interprets policy logic directly — it submits facts and accepts the server's verdict.

preflightBulkVerify is called with the full set of device identifiers before deployment begins. The API evaluates attribute conditions across all targets in one call, returning a consolidated finding set. A single blocking finding prevents the deploy gate from opening.

Policy Manager V2 Capability Flags

preflight_bulk_verify supported
snapshot_retrieval supported
per_device_identity supported
attribute_assignment supported
enrollment_queue supported

Each deployment artifact includes an embedded policy snapshot — a deterministic representation of the ABAC state at deployment time. If the policy state changes after deployment, the snapshot remains as a forensic record of what was in effect.

Transport Security

mTLS + Certificate Configuration

All communication with Policy Manager V2 uses mutual TLS. The client presents a certificate on every connection. The server validates it against the configured CA before processing any request.

Certificate material is stored in the provider configuration and is never written to the deployment artifact. The mTLS client is instantiated fresh per-session from the provider settings. Rotating certificates requires only updating the provider record — no deployment artifact re-signing is necessary.

provider.mtls_config 
client_cert:      PEM-encoded client certificate
client_key:       PEM-encoded private key
ca_cert:          PEM-encoded CA certificate (optional)
endpoint:         https://policy-manager.intranet:8443
──────────────────────────────────────────────────
All fields stored in local SQLite — never transmitted

Credential Handling

Credential & Secret Handling

  • Provider secrets (certificates, keys) are masked by default throughout the UI
  • Secret reveal is explicit — the field must be toggled to show plaintext — and resets on navigation
  • Deployment artifacts include resolved credentials: treat generated artifact packages as sensitive material
  • No credentials are transmitted to any cloud service; all storage is local SQLite on the administrator's machine
  • The SMB write uses pass-through Windows authentication — no credentials are stored for UNC share access
  • Rotating a certificate requires only updating the provider record and triggering a new deployment

Observability

Audit Trail

ntkDeploy maintains an append-only audit log in local SQLite. Every action that changes system state generates an immutable audit entry. The log cannot be modified or deleted through the application UI.

What is recorded

  • Actor (the authenticated user session)
  • Action type (create, update, delete, deploy, rollback)
  • Entity and entity ID
  • Timestamp (UTC)
  • Policy snapshot reference for deployments
  • Per-device success/failure status for rollouts

What is NOT recorded

  • Raw credential values or private key material
  • Preflight finding detail for per-device runs (summary only)
  • Policy engine internal evaluation traces
  • UNC path contents or file data

Threat Model

Threat Model Highlights

ntkDeploy is intentionally scoped to intranet operation. The attack surface is limited to local access to the administrator's machine and the internal network path to Policy Manager.

  • No internet-facing surface. The application makes no outbound connections outside the local network. Policy Manager endpoints are internal.
  • No cloud authentication. Identity is managed locally. There are no cloud accounts, OAuth flows, or token refresh cycles. Compromise of a cloud IdP does not affect ntkDeploy.
  • Pass-through Windows auth for SMB. The application does not store or handle SMB credentials. Share write access is determined by the Windows session's domain identity.
  • Artifacts are sensitive. Deployment artifacts contain resolved configuration and policy snapshots. Restrict UNC share ACLs to prevent unauthorized reads of deployed configurations.
  • Local SQLite is the trust boundary. All application state lives in the SQLite database on the admin machine. Physical or remote access to that machine is the primary threat vector.