プラットフォームハードニング

このページでは、DuoKey の基盤となる OpenShift プラットフォームをどのようにハードニングするかを 説明します。これらのコントロールはインストール時に構成され、引き渡し時に検証されます。

ワークロードセキュリティ: SCC と Pod Security

• Security Context Constraints (SCC) — DuoKey ワークロードは restricted-v2 SCC の下で実行されます: 非 root、権限昇格なし、Linux ケーパビリティのドロップ、可能な限り 読み取り専用ルートファイルシステム。
• Pod Security Admission (PSA) — 名前空間には restricted Pod Security Standard を強制するようにラベルが付けられ、アドミッション時に特権 Pod をブロックします。

# 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

DuoKey のコンポーネントは privileged、hostNetwork、hostPath のいずれも必要としません。

保存時の暗号化

• etcd 暗号化 — OpenShift の etcd 暗号化を有効にして、Kubernetes Secret と構成が aescbc/aesgcm で保存時に暗号化されるようにします。
• ボリューム暗号化 — 永続ボリュームは、ODF クラスター全体の暗号化またはストレージ層の LUKS を介して暗号化されます。
• シークレット — アプリケーションシークレットは etcd に長期間保存されることはありません。 シークレットマネージャーからインメモリで注入されます (シークレットマネージャー統合を参照)。

# Enable etcd encryption
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aesgcm

イメージセキュリティとサプライチェーン

• 信頼されたレジストリ — イメージは内部レジストリ (Quay / ミラー) から取得されます。 エアギャップサイトでは、すべてのイメージが事前にミラーリングされます。
• イメージ署名 — コンテナイメージは Sigstore/cosign で署名・検証されます。 アドミッションポリシーは未署名のイメージを拒否します。
• 脆弱性スキャン — Quay/Clair またはお客様のスキャナーをパイプラインに統合します。 CVE しきい値を超えるイメージの展開をブロックします。
• アドミッション制御 — OpenShift の署名検証を使用し、オプションでポリシーエンジン (Kyverno / OPA Gatekeeper) を組織的なガードレールとして使用します。

RBAC

DuoKey とプラットフォームのアクセスは最小権限に従います:

• ワークロードの ServiceAccount には、必要な権限のみが付与されます。
• 人間のアクセスは IdP を介して仲介され (アイデンティティと SSOを参照)、 スコープ付きのクラスターロールにマッピングされます。
• 日常的な操作のための常設クラスター管理者はありません。特権アクションはジャストインタイムで 監査された昇格を使用します。

FIPS モード (防衛 / 規制対象)

OpenShift は FIPS 140-2/3 検証済み暗号モードで実行できます。インストール時に有効にすると、 クラスターはエンドツーエンドで FIPS 検証済みの暗号モジュールを使用します。鍵のトラストルートに ついては、FIPS モードを DuoKey MPC および/または Securosys HSM と組み合わせます (シークレットマネージャー統合を参照)。

ノードと OS のハードニング

• 不変 OS — ワーカー/コントロールプレーンノードは、Machine Config Operator によって 管理される不変でコンテナ最適化された OS である Red Hat CoreOS (RHCOS) を実行します。
• SSH ドリフトなし — ノード構成は宣言的です。アドホックな変更は自動的に元に戻されます。
• ベンチマーク — CIS Kubernetes/OpenShift Benchmark を適用し、防衛用途には OpenShift Compliance Operator を介して DISA STIG プロファイルを適用します。

# 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

監査ロギング

• Kubernetes/OpenShift の API 監査ログは、すべての特権アクションを記録します。
• アプリケーションログとアクセスログは SIEM に送信されます。
• 保持と SIEM 統合については、コンプライアンスと監査を参照してください。

ハードニングチェックリスト

• ワークロードが restricted-v2 SCC の下で実行され、名前空間が restricted PSA を強制
• etcd 暗号化が有効 (aesgcm)
• 永続ボリュームが保存時に暗号化されている
• イメージが署名 (cosign) され、信頼された/ミラーリングされたレジストリから取得
• デフォルト拒否の NetworkPolicy が配置されている (ネットワークセキュリティを参照)
• RBAC 最小権限、常設クラスター管理者なし
• FIPS モードが有効 (必要な場合) + HSM トラストルート
• Compliance Operator を介して CIS/STIG スキャンに合格
• API 監査ロギングが SIEM に転送されている