> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Stockage OpenShift ODF et Ceph RGW > Connecter CaseBender à un stockage OBC ou Ceph RGW autonome géré par le client 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 : | Profil d'usage | Comportement requis | | -------------- | ------------------------------------------------------------------------------------------------- | | `quarantine` | Téléversements utilisateur initiaux ; chemin de promotion réservé au scanner ; pas d'accès public | | `records` | Pièces jointes/preuves/exports durables ; versioning et contrôles WORM requis | | `ephemeral` | Canaries profonds et exports de courte durée ; politique de cycle de vie bornée | 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 : ```bash theme={null} oc get storageclass \ -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner oc api-resources | rg -i objectbucketclaim ``` 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. ```bash theme={null} oc apply -f '' oc -n casebender wait --for=jsonpath='{.status.phase}'=Bound \ objectbucketclaim/casebender-quarantine \ objectbucketclaim/casebender-records \ objectbucketclaim/casebender-ephemeral \ --timeout=10m ``` 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 : ```bash theme={null} oc -n casebender create configmap casebender-rgw-ca \ --from-file=ca.crt='' \ --dry-run=client -o yaml | oc apply -f - ``` 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 ```bash theme={null} kubectl kustomize k8s/overlays/openshift-odf-rgw \ > /tmp/casebender-openshift-odf-rgw.yaml ./scripts/openshift/validate.sh \ /tmp/casebender-openshift-odf-rgw.yaml oc apply --server-side --dry-run=server \ -f /tmp/casebender-openshift-odf-rgw.yaml oc apply --server-side \ -f /tmp/casebender-openshift-odf-rgw.yaml oc -n casebender rollout status deployment/webapp deployment/worker \ --timeout=10m ``` Exécutez ensuite la qualification en direct depuis le réseau des charges de travail et le contexte de confiance : ```bash theme={null} STORAGE_TEST_ENDPOINT='https://' \ STORAGE_TEST_BUCKET='' \ AWS_REGION='' \ STORAGE_TEST_CA_BUNDLE='' \ STORAGE_TEST_ODF_VERSION='' \ STORAGE_TEST_CEPH_VERSION='' \ STORAGE_TEST_CAP_VERSIONING='' \ STORAGE_TEST_CAP_DELETE_MARKERS='' \ STORAGE_TEST_CAP_OBJECT_LOCK='' \ ./scripts/storage/validate-ceph-rgw.sh ``` 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](/fr/deployment/storage-health-troubleshooting) et le fichier interne au dépôt `k8s/overlays/openshift-odf-rgw/README.md` pour les détails de l'overlay.