Skip to main content

Platform Hardening

This page describes how the OpenShift platform underneath DuoKey is hardened. These controls are configured during installation and validated during handover.

Workload security: SCC & Pod Security​

  • Security Context Constraints (SCC) — DuoKey workloads run under the restricted-v2 SCC: non-root, no privilege escalation, dropped Linux capabilities, and a read-only root filesystem where possible.
  • Pod Security Admission (PSA) — namespaces are labeled to enforce the restricted Pod Security Standard, blocking privileged pods at admission.
# Enforce the restricted Pod Security Standard on the namespace
apiVersion: v1
kind: Namespace
metadata:
  name: duokey
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

No DuoKey component requires privileged, hostNetwork, or hostPath.

Encryption at rest​

  • etcd encryption — enable OpenShift etcd encryption so Kubernetes Secrets and config are encrypted at rest with aescbc/aesgcm.
  • Volume encryption — persistent volumes are encrypted via ODF cluster-wide encryption or LUKS at the storage layer.
  • Secrets — application secrets are never stored in etcd long-term; they are injected in-memory from your secret manager (see Secret Manager Integration).
# Enable etcd encryption
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aesgcm

Image security & supply chain​

  • Trusted registry — images are pulled from your internal registry (Quay / mirror). For air-gapped sites, all images are mirrored ahead of time.
  • Image signing — container images are signed and verified with Sigstore/cosign; admission policy rejects unsigned images.
  • Vulnerability scanning — integrate Quay/Clair or your scanner into the pipeline; block deployment of images above your CVE threshold.
  • Admission control — use OpenShift's signature verification and, optionally, a policy engine (Kyverno / OPA Gatekeeper) for organizational guardrails.

RBAC​

DuoKey and platform access follow least privilege:

  • Workload ServiceAccounts are granted only the permissions they need.
  • Human access is brokered through your IdP (see Identity & SSO) and mapped to scoped cluster roles.
  • No standing cluster-admin for routine operations; privileged actions use just-in-time, audited elevation.

FIPS mode (defense / regulated)​

OpenShift can run in FIPS 140-2/3 validated cryptographic mode. When enabled at install time, the cluster uses FIPS-validated crypto modules end to end. For the key root of trust, combine FIPS mode with the DuoKey MPC KMS or a Securosys HSM (see Secret Manager Integration).

Node & OS hardening​

  • Immutable OS — worker/control-plane nodes run Red Hat CoreOS (RHCOS), an immutable, container-optimized OS managed by the Machine Config Operator.
  • No SSH drift — node configuration is declarative; ad-hoc changes are reverted automatically.
  • Benchmarks — apply CIS Kubernetes/OpenShift Benchmark and, for defense, DISA STIG profiles via the OpenShift Compliance Operator.
# Run a CIS/STIG scan with the Compliance Operator
oc apply -f - <<'EOF'
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis-scan
  namespace: openshift-compliance
profiles:
  - name: ocp4-cis
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
EOF

Audit logging​

  • The Kubernetes/OpenShift API audit log records every privileged action.
  • Application and access logs are shipped to your SIEM.
  • See Compliance & Audit for retention and SIEM integration.

Hardening checklist​

  • Workloads run under restricted-v2 SCC, namespace enforces restricted PSA
  • etcd encryption enabled (aesgcm)
  • Persistent volumes encrypted at rest
  • Images signed (cosign) and pulled from a trusted/mirrored registry
  • Default-deny NetworkPolicies in place (see Network Security)
  • RBAC least privilege; no standing cluster-admin
  • FIPS mode enabled (if required) + HSM root of trust
  • CIS/STIG scan passing via Compliance Operator
  • API audit logging forwarded to SIEM