Aller au contenu principal

Renforcement de la plateforme

Cette page décrit comment la plateforme OpenShift sous-jacente à DuoKey est renforcée. Ces contrôles sont configurés durant l'installation et validés lors de la remise.

Sécurité des charges de travail : SCC et Pod Security​

  • Security Context Constraints (SCC) — les charges de travail DuoKey s'exécutent sous la SCC restricted-v2 : non-root, aucune élévation de privilège, capacités Linux supprimées et système de fichiers racine en lecture seule lorsque c'est possible.
  • Pod Security Admission (PSA) — les namespaces sont étiquetés pour appliquer le standard de sécurité de pod restricted, bloquant les pods privilégiés à l'admission.
# Appliquer le standard de sécurité de pod restricted au 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

Aucun composant DuoKey ne nécessite privileged, hostNetwork ou hostPath.

Chiffrement au repos​

  • Chiffrement etcd — activez le chiffrement etcd d'OpenShift afin que les Secrets Kubernetes et la configuration soient chiffrés au repos avec aescbc/aesgcm.
  • Chiffrement des volumes — les volumes persistants sont chiffrés via le chiffrement à l'échelle du cluster ODF ou LUKS au niveau du stockage.
  • Secrets — les secrets applicatifs ne sont jamais stockés dans etcd à long terme ; ils sont injectés en mémoire depuis votre gestionnaire de secrets (voir Intégration du gestionnaire de secrets).
# Activer le chiffrement etcd
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  encryption:
    type: aesgcm

Sécurité des images et chaîne d'approvisionnement​

  • Registre approuvé — les images sont récupérées depuis votre registre interne (Quay / miroir). Pour les sites en air-gap, toutes les images sont mises en miroir à l'avance.
  • Signature d'images — les images de conteneurs sont signées et vérifiées avec Sigstore/cosign ; la politique d'admission rejette les images non signées.
  • Analyse de vulnérabilités — intégrez Quay/Clair ou votre scanner dans le pipeline ; bloquez le déploiement des images dépassant votre seuil de CVE.
  • Contrôle d'admission — utilisez la vérification de signature d'OpenShift et, optionnellement, un moteur de politique (Kyverno / OPA Gatekeeper) pour les garde-fous organisationnels.

RBAC​

L'accès à DuoKey et à la plateforme suit le moindre privilège :

  • Les ServiceAccounts de charge de travail ne se voient accorder que les permissions dont ils ont besoin.
  • L'accès humain est intermédié par votre IdP (voir Identité et SSO) et mappé sur des rôles de cluster à portée limitée.
  • Aucun cluster-admin permanent pour les opérations de routine ; les actions privilégiées utilisent une élévation just-in-time et auditée.

Mode FIPS (défense / réglementé)​

OpenShift peut s'exécuter en mode cryptographique validé FIPS 140-2/3. Lorsqu'il est activé au moment de l'installation, le cluster utilise des modules cryptographiques validés FIPS de bout en bout. Pour la racine de confiance des clés, combinez le mode FIPS avec DuoKey MPC et/ou un HSM Securosys (voir Intégration du gestionnaire de secrets).

Renforcement des nœuds et du système d'exploitation​

  • OS immuable — les nœuds de travail/plan de contrôle exécutent Red Hat CoreOS (RHCOS), un OS immuable et optimisé pour les conteneurs, géré par le Machine Config Operator.
  • Aucune dérive SSH — la configuration des nœuds est déclarative ; les changements ad hoc sont annulés automatiquement.
  • Benchmarks — appliquez le CIS Kubernetes/OpenShift Benchmark et, pour la défense, les profils DISA STIG via l'Compliance Operator d'OpenShift.
# Exécuter une analyse CIS/STIG avec le 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

Journalisation d'audit​

  • Le journal d'audit de l'API Kubernetes/OpenShift enregistre chaque action privilégiée.
  • Les journaux applicatifs et d'accès sont expédiés vers votre SIEM.
  • Voir Conformité et audit pour la rétention et l'intégration SIEM.

Liste de contrôle de renforcement​

  • Les charges de travail s'exécutent sous la SCC restricted-v2, le namespace applique la PSA restricted
  • Chiffrement etcd activé (aesgcm)
  • Volumes persistants chiffrés au repos
  • Images signées (cosign) et récupérées depuis un registre approuvé/en miroir
  • NetworkPolicies default-deny en place (voir Sécurité réseau)
  • Moindre privilège RBAC ; aucun cluster-admin permanent
  • Mode FIPS activé (si requis) + racine de confiance HSM
  • Analyse CIS/STIG réussie via le Compliance Operator
  • Journalisation d'audit de l'API transmise au SIEM