Skip to main content
Lo storage di produzione CaseBender è di proprietà del cliente e provisionato esternamente. L’applicazione esegue solo operazioni data-plane sugli oggetti. Non crea, elimina né configura mai un bucket o un container a runtime.

​
Stato della release attuale

L’autorità machine-readable è scripts/storage/certification-matrix.json:
Il repository ha risultati di emulator, ma la compatibilità con l’emulator non è certificazione live. L’attuale certificazione live di ODF/Ceph RGW è in attesa delle credenziali fornite dal cliente e delle evidenze di versione esatta. Il profilo è configurato e pronto per la qualificazione, non certificato.
“Implementato” significa che esiste un adapter per le operazioni sugli oggetti. “Dichiarato supportato” significa che la matrice della release seleziona un profilo prodotto per un gate di supporto. “Certificato” richiede inoltre evidenze live complete e firmate per il prodotto e la versione esatti. Non inferire mai la certificazione da un nome di adapter, da un’esecuzione di emulator, da un render Kubernetes o dal risultato di un altro cliente.

​
Contratto di configurazione

Usa un STORAGE_CONFIG_FILE montato (preferito) o STORAGE_CONFIG_JSON con tre profili: quarantine, records ed ephemeral. Il bridge legacy a profilo singolo usa solo questi ID provider canonici e queste variabili:
  • s3: S3_BUCKET, AWS_REGION, S3_ENDPOINT HTTPS opzionale
  • gcs: GCS_BUCKET, GCS_PROJECT_ID opzionale
  • azure: AZURE_STORAGE_ACCOUNT, AZURE_CONTAINER
  • local: STORAGE_PATH, solo al di fuori della produzione
azure-blob, AWS_S3_BUCKET e AZURE_STORAGE_CONTAINER non sono nomi runtime validi. La produzione rifiuta la configurazione di storage esplicita mancante, i profili local e gli endpoint HTTP personalizzati. Usa l’identità del workload o la catena di credenziali predefinita del provider. Le chiavi S3 statiche, i file di chiavi GCS, le shared key Azure e le connection string Azure sono solo modalità di compatibilità. Conserva eventuali credenziali nel secret manager della piattaforma; non inserirle mai nel codice sorgente, nei ConfigMap, nelle immagini, nella cronologia della shell, nei log, nelle evidenze o nei bundle di supporto.

​
Confine di produzione richiesto

  • Usa bucket o container esterni pre-creati senza accesso pubblico.
  • Separa quarantine, records persistenti e oggetti ephemeral in modo che retention, scanner e policy di scadenza possano differire.
  • Mantieni abilitata la verifica TLS; monta i bundle CA privati quando richiesto.
  • Richiedi crittografia at rest e in transito, versioning, backup e verifica SHA-256 applicativa.
  • Abilita e qualifica i controlli di retention/legal-hold quando la distribuzione richiede WORM. Le versioni esatte degli oggetti sono obbligatorie per le operazioni di retention e hold.
  • Non abilitare la generazione di URL firmati, URL pre-firmati o SAS. I download passano attraverso l’autorizzazione autenticata di CaseBender.
  • Configura clamd esterno; gli upload utente restano in quarantine e non disponibili quando la scansione non può produrre un verdetto pulito terminale.
  • Monitora readiness, età del deep-canary, dead letter di mutazione, età della quarantine, oggetti mancanti, orphan confermati, errori di checksum, latenza e capacità.
Vedi Baseline di sicurezza dello storage e Stato di salute e risoluzione dei problemi dello storage.

​
Qualificazione e controllo delle modifiche

Valida dalla stessa rete, identità, endpoint e contesto CA dei workload web e worker. Riesegui la qualificazione dopo un upgrade di CaseBender, un upgrade del provider, una modifica della bucket-policy, una rotazione delle credenziali, una rotazione della CA, una modifica della network-policy o una modifica WORM.
La validazione live specifica del provider e le evidenze firmate sono richieste in aggiunta ai test del repository. Vedi Selezione e certificazione del provider e Certificazione S3-compatibile.

​
Riferimenti al ciclo di vita