Diseño del almacenamiento
Aprovisione tres buckets externos independientes:
Los tres deben existir antes del arranque. El adaptador en tiempo de ejecución
nunca crea un bucket. El overlay usa HTTPS, direccionamiento S3 path-style,
confianza de CA privada verificada, solicitudes de cifrado del lado del servidor
AES-256 e integridad SHA-256 de la aplicación.
Opción A: OBC externos gestionados
Identifique el StorageClass de bucket RGW aprobado por el cliente:k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml
al repositorio del entorno del cliente, reemplace el marcador de StorageClass
y aplíquelo por separado de CaseBender. El ciclo de vida del bucket sigue
siendo propiedad del operador de almacenamiento.
BUCKET_HOST, BUCKET_PORT, BUCKET_NAME y BUCKET_REGION, y que cada
Secret proporciona AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY. Si el
operador OBC usa otras claves, parchee valueFrom; nunca copie credenciales
a un ConfigMap o archivo Kustomize.
Opción B: RGW externo independiente
Usek8s/overlays/openshift-odf-rgw/standalone-rgw-resources.example.yaml
como ejemplo de mapeo. Reemplace cada endpoint .invalid y cada marcador de
bucket en el overlay del cliente. Use el controlador de secretos externos
instalado u otro inyector de secretos aprobado. Mantenga los endpoints y los
nombres de bucket en ConfigMaps, las credenciales en Secrets y todos los
valores reales fuera de este repositorio.
El init container restringido lee estos recursos y escribe un
STORAGE_CONFIG_FILE estricto en un emptyDir respaldado en memoria con
modo 0400. Web y worker lo montan en solo lectura.
CA privada
Cree un ConfigMap de CA que contenga solo la cadena emisora:--insecure ni una opción que omita el certificado.
Egreso
La política incluida permite que web y worker alcancen TCP 443 en pods etiquetadosapp=rook-ceph-rgw en openshift-storage. Verifique el
namespace real, las etiquetas, el puerto y el comportamiento del CNI.
Para RGW externo, copie y adapte
external-rgw-network-policy.example.yaml con CIDR estables aprobados, o
enrute a través de un proxy de egreso controlado por el operador.
NetworkPolicy de Kubernetes no puede seleccionar FQDN. No restaure el egreso
comodín 0.0.0.0/0 ni ::/0.
Añada políticas de mínimo privilegio separadas para PostgreSQL, Redis,
identidad, escáner e integraciones aprobadas.
Prerrequisito del escáner
Las cargas de usuario en producción requierenclamd externo. El parche de
worker proporcionado espera casebender-malware-scanner (host, port) y
casebender-malware-scanner-ca (ca.crt) y habilita TLS. Un escáner en el
mismo pod puede usar en su lugar CLAMD_SOCKET_PATH. Si el escáner no está
disponible, los objetos permanecen en cuarentena y los reintentos pueden
acabar en dead-letter; las descargas no fallan en abierto.
Renderizar y validar
apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md. Un render, una
prueba de emulador o una transcripción sin firmar no es certificación en vivo.
Rotación de credenciales
- Rote mediante el procedimiento soportado de ODF/Ceph; no edite a mano un Secret OBC propiedad del operador.
- Permita un solapamiento acotado mientras se actualiza el Secret generado o el ExternalSecret.
- Reinicie web y worker para que el init container regenere el archivo montado.
- Exija que
/api/health/readyy la validación de contrato en vivo pasen. - Revoque la credencial anterior y revise las métricas/registros de autenticación saneados.
Rotación de CA
- Publique un paquete de CA temporal que contenga las CA emisoras antigua y nueva.
- Reinicie y valide web y worker.
- Rote el certificado de servicio de RGW.
- Publique el paquete de CA solo nuevo, reinicie y valide de nuevo.
- Registre las versiones de recurso del ConfigMap, los hashes SHA-256 de la CA, las versiones exactas de ODF/Ceph y la evidencia; nunca los valores de las credenciales.
k8s/overlays/openshift-odf-rgw/README.md del repositorio para los detalles
del overlay.