Skip to main content
Questo profilo connette CaseBender a OpenShift Data Foundation (ODF) o Ceph RGW esistente e gestito dal cliente. CaseBender è un client S3; non installa, aggiorna, esegue backup, monitora né amministra ODF, Ceph, RGW, utenti o bucket.
L’attuale certificazione live è in attesa delle credenziali del cliente e delle evidenze di versione esatta. L’overlay è configurato e pronto per la qualificazione, non certificato.

Layout dello storage

Provisiona tre bucket esterni indipendenti: Tutti e tre devono esistere prima dell’avvio. L’adapter runtime non crea mai un bucket. L’overlay usa HTTPS, addressing S3 path-style, trust della CA privata verificato, richieste di crittografia server-side AES-256 e integrità applicativa SHA-256.

Opzione A: OBC esterni gestiti

Identifica lo StorageClass del bucket RGW approvato dal cliente:
Copia k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml nel repository dell’ambiente del cliente, sostituisci il placeholder dello StorageClass e applicalo separatamente da CaseBender. Il ciclo di vita del bucket resta di proprietà dell’operatore di storage.
Conferma, senza stampare i valori, che ogni ConfigMap generato fornisce BUCKET_HOST, BUCKET_PORT, BUCKET_NAME e BUCKET_REGION, e ogni Secret fornisce AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Se l’operatore OBC usa altre chiavi, patcha valueFrom; non copiare mai le credenziali in un ConfigMap o in un file Kustomize.

Opzione B: RGW esterno standalone

Usa k8s/overlays/openshift-odf-rgw/standalone-rgw-resources.example.yaml come esempio di mapping. Sostituisci ogni endpoint .invalid e ogni placeholder di bucket nell’overlay del cliente. Usa il controller external-secret installato o un altro iniettore di secret approvato. Conserva endpoint e nomi dei bucket nei ConfigMap, le credenziali nei Secret e tutti i valori reali al di fuori di questo repository. L’init container ristretto legge queste risorse e scrive un STORAGE_CONFIG_FILE rigoroso su un emptyDir backed da memoria con modalità 0400. Web e worker lo montano in sola lettura.

CA privata

Crea un ConfigMap CA contenente solo la catena di emissione:
Il certificato deve coprire l’hostname RGW esatto. La verifica TLS resta abilitata. Non usare mai un indirizzo IP non elencato, un endpoint HTTP, --insecure o un’opzione di bypass del certificato.

Egress

La policy inclusa consente a web e worker di raggiungere TCP 443 sui pod etichettati app=rook-ceph-rgw in openshift-storage. Verifica namespace, label, porta e comportamento CNI effettivi. Per RGW esterno, copia e adatta external-rgw-network-policy.example.yaml con CIDR approvati e stabili, oppure instrada attraverso un proxy di egress controllato dall’operatore. Kubernetes NetworkPolicy non può selezionare FQDN. Non ripristinare l’egress wildcard 0.0.0.0/0 o ::/0. Aggiungi policy least-privilege separate per PostgreSQL, Redis, identità, scanner e integrazioni approvate.

Prerequisito dello scanner

Gli upload utente in produzione richiedono clamd esterno. La patch worker fornita si aspetta casebender-malware-scanner (host, port) e casebender-malware-scanner-ca (ca.crt) e abilita TLS. Uno scanner nello stesso pod può invece usare CLAMD_SOCKET_PATH. Se lo scanner non è disponibile, gli oggetti restano in quarantine e i retry possono alla fine diventare dead-letter; i download non falliscono in apertura.

Render e validazione

Quindi esegui la qualificazione live dalla rete del workload e dal contesto di trust:
Fornisci le credenziali attraverso la catena di credenziali AWS, con ambito limitato al bucket/prefisso di test dedicato. Completa e firma apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md. Un render, un test di emulator o un transcript non firmato non è certificazione live.

Rotazione delle credenziali

  1. Ruota attraverso la procedura ODF/Ceph supportata; non modificare a mano un Secret OBC di proprietà dell’operatore.
  2. Consenti una sovrapposizione delimitata mentre il Secret generato o l’ExternalSecret si aggiorna.
  3. Riavvia web e worker in modo che l’init container rigeneri il file montato.
  4. Richiedi che /api/health/ready e la validazione live del contratto superino i test.
  5. Revoca la vecchia credenziale e controlla metriche/log di autenticazione sanitizzati.

Rotazione della CA

  1. Pubblica un bundle CA temporaneo contenente le CA di emissione vecchia e nuova.
  2. Riavvia e valida web e worker.
  3. Ruota il certificato di serving RGW.
  4. Pubblica il bundle CA solo-nuovo, riavvia e valida di nuovo.
  5. Registra le versioni della risorsa ConfigMap, gli hash SHA-256 della CA, le versioni esatte di ODF/Ceph e le evidenze—mai i valori delle credenziali.
Vedi Stato di salute e risoluzione dei problemi dello storage e il k8s/overlays/openshift-odf-rgw/README.md nel repository per i dettagli dell’overlay.