Skip to main content
Ce profil connecte CaseBender à un OpenShift Data Foundation (ODF) ou Ceph RGW existant, géré par le client. CaseBender est un client S3 ; il n’installe, ne met à niveau, ne sauvegarde, ne surveille ni n’administre ODF, Ceph, RGW, les utilisateurs ou les buckets.
La certification en direct actuelle est en attente d’identifiants client et de preuves de version exacte. L’overlay est configuré et prêt pour la qualification, non certifié.

​
Disposition du stockage

Provisionnez trois buckets externes indépendants : Les trois doivent exister avant le démarrage. L’adaptateur d’exécution ne crée jamais de bucket. L’overlay utilise HTTPS, l’adressage S3 path-style, la confiance CA privée vérifiée, les requêtes de chiffrement côté serveur AES-256 et l’intégrité applicative SHA-256.

​
Option A : OBC externes gérés

Identifiez la StorageClass de bucket RGW approuvée par le client :
Copiez k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml vers le dépôt d’environnement client, remplacez l’espace réservé StorageClass et appliquez-le séparément de CaseBender. Le cycle de vie des buckets reste propriété de l’opérateur de stockage.
Confirmez, sans afficher les valeurs, que chaque ConfigMap générée fournit BUCKET_HOST, BUCKET_PORT, BUCKET_NAME et BUCKET_REGION, et que chaque Secret fournit AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Si l’opérateur OBC utilise d’autres clés, corrigez valueFrom ; ne copiez jamais les identifiants dans un ConfigMap ou un fichier Kustomize.

​
Option B : RGW externe autonome

Utilisez k8s/overlays/openshift-odf-rgw/standalone-rgw-resources.example.yaml comme exemple de mapping. Remplacez chaque point de terminaison .invalid et chaque espace réservé de bucket dans l’overlay client. Utilisez le contrôleur external-secret installé ou un autre injecteur de secrets approuvé. Conservez les points de terminaison et les noms de buckets dans les ConfigMaps, les identifiants dans les Secrets, et toutes les valeurs réelles hors de ce dépôt. Le conteneur d’init restreint lit ces ressources et écrit un STORAGE_CONFIG_FILE strict vers un emptyDir en mémoire avec le mode 0400. Le web et le worker le montent en lecture seule.

​
CA privée

Créez un ConfigMap CA contenant uniquement la chaîne d’émission :
Le certificat doit couvrir le nom d’hôte RGW exact. La vérification TLS reste activée. N’utilisez jamais une adresse IP non listée, un point de terminaison HTTP, --insecure ou une option de contournement de certificat.

​
Egress

La politique incluse autorise le web et le worker à atteindre le TCP 443 sur les pods étiquetés app=rook-ceph-rgw dans openshift-storage. Vérifiez l’espace de noms réel, les labels, le port et le comportement CNI. Pour un RGW externe, copiez et adaptez external-rgw-network-policy.example.yaml avec des CIDR stables approuvés, ou routez via un proxy d’egress contrôlé par l’opérateur. Kubernetes NetworkPolicy ne peut pas sélectionner de FQDN. Ne restaurez pas un egress générique 0.0.0.0/0 ou ::/0. Ajoutez des politiques distinctes de moindre privilège pour PostgreSQL, Redis, l’identité, le scanner et les intégrations approuvées.

​
Prérequis du scanner

Les téléversements utilisateur de production exigent un clamd externe. Le correctif worker fourni attend casebender-malware-scanner (host, port) et casebender-malware-scanner-ca (ca.crt) et active TLS. Un scanner dans le même pod peut à la place utiliser CLAMD_SOCKET_PATH. Si le scanner est indisponible, les objets restent en quarantaine et les tentatives peuvent finalement aboutir en lettre morte ; les téléchargements n’échouent pas en mode ouvert.

​
Rendu et validation

Exécutez ensuite la qualification en direct depuis le réseau des charges de travail et le contexte de confiance :
Fournissez les identifiants via la chaîne d’identifiants AWS, limitée au bucket/préfixe de test dédié. Complétez et signez apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md. Un rendu, un test d’émulateur ou une transcription non signée n’est pas une certification en direct.

​
Rotation des identifiants

  1. Effectuez la rotation via la procédure ODF/Ceph supportée ; ne modifiez pas à la main un Secret OBC appartenant à l’opérateur.
  2. Autorisez un chevauchement borné pendant que le Secret généré ou l’ExternalSecret se rafraîchit.
  3. Redémarrez le web et le worker afin que le conteneur d’init régénère le fichier monté.
  4. Exigez que /api/health/ready et la validation de contrat en direct réussissent.
  5. Révoquez l’ancien identifiant et vérifiez les métriques/journaux d’authentification assainis.

​
Rotation de CA

  1. Publiez un lot CA temporaire contenant les CA d’émission ancienne et nouvelle.
  2. Redémarrez et validez le web et le worker.
  3. Effectuez la rotation du certificat de service RGW.
  4. Publiez le lot CA uniquement nouveau, redémarrez et validez à nouveau.
  5. Enregistrez les versions de ressource ConfigMap, les hachages SHA-256 de CA, les versions ODF/Ceph exactes et les preuves — jamais les valeurs d’identifiants.
Voir Santé et dépannage du stockage et le fichier interne au dépôt k8s/overlays/openshift-odf-rgw/README.md pour les détails de l’overlay.