Skip to main content
Este perfil conecta o CaseBender a OpenShift Data Foundation (ODF) ou Ceph RGW existente, gerenciado pelo cliente. O CaseBender é um cliente S3; ele não instala, atualiza, faz backup, monitora nem administra ODF, Ceph, RGW, usuários ou buckets.
A certificação live atual está pendente de credenciais do cliente e de evidência de versão exata. O overlay está configurado e pronto para qualificação, não certificado.

​
Layout de armazenamento

Provisione três buckets externos independentes: Os três devem existir antes da inicialização. O adaptador de runtime nunca cria um bucket. O overlay usa HTTPS, endereçamento S3 path-style, confiança verificada de CA privada, solicitações de criptografia no servidor AES-256 e integridade SHA-256 da aplicação.

​
Opção A: OBCs externos gerenciados

Identifique o StorageClass de bucket RGW aprovado pelo cliente:
Copie k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml para o repositório do ambiente do cliente, substitua o placeholder do StorageClass e aplique-o separadamente do CaseBender. O ciclo de vida do bucket permanece de propriedade do operador de armazenamento.
Confirme, sem imprimir valores, que cada ConfigMap gerado fornece BUCKET_HOST, BUCKET_PORT, BUCKET_NAME e BUCKET_REGION, e cada Secret fornece AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Se o operador OBC usar outras chaves, faça patch de valueFrom; nunca copie credenciais para um ConfigMap ou arquivo Kustomize.

​
Opção B: RGW externo independente

Use k8s/overlays/openshift-odf-rgw/standalone-rgw-resources.example.yaml como exemplo de mapeamento. Substitua todos os placeholders de endpoint .invalid e de bucket no overlay do cliente. Use o controlador de external-secret instalado ou outro injetor de segredos aprovado. Mantenha endpoints e nomes de bucket em ConfigMaps, credenciais em Secrets e todos os valores reais fora deste repositório. O init container restrito lê esses recursos e grava um STORAGE_CONFIG_FILE restrito em um emptyDir backed por memória com modo 0400. Web e worker o montam somente leitura.

​
CA privada

Crie um ConfigMap de CA contendo apenas a cadeia emissora:
O certificado deve cobrir o hostname exato do RGW. A verificação TLS permanece habilitada. Nunca use um endereço IP não listado, um endpoint HTTP, --insecure ou uma opção de bypass de certificado.

​
Egresso

A política incluída permite que web e worker alcancem TCP 443 em pods rotulados app=rook-ceph-rgw em openshift-storage. Verifique o namespace real, os rótulos, a porta e o comportamento do CNI. Para RGW externo, copie e adapte external-rgw-network-policy.example.yaml com CIDRs aprovados e estáveis, ou roteie por um proxy de egresso controlado pelo operador. O NetworkPolicy do Kubernetes não pode selecionar FQDNs. Não restaure egresso curinga 0.0.0.0/0 ou ::/0. Adicione políticas separadas de menor privilégio para PostgreSQL, Redis, identidade, scanner e integrações aprovadas.

​
Pré-requisito do scanner

Uploads de usuário em produção exigem clamd externo. O patch do worker fornecido espera casebender-malware-scanner (host, port) e casebender-malware-scanner-ca (ca.crt) e habilita TLS. Um scanner no mesmo pod pode, em vez disso, usar CLAMD_SOCKET_PATH. Se o scanner estiver indisponível, os objetos permanecem em quarentena e as retentativas podem eventualmente ir para dead-letter; os downloads não falham em aberto.

​
Renderizar e validar

Em seguida, execute a qualificação live a partir da rede do workload e do contexto de confiança:
Forneça credenciais pela cadeia de credenciais da AWS, com escopo limitado ao bucket/prefixo de teste dedicado. Conclua e assine apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md. Uma renderização, teste de emulador ou transcrição não assinada não é certificação live.

​
Rotação de credenciais

  1. Rotacione pelo procedimento suportado de ODF/Ceph; não edite manualmente um Secret de OBC de propriedade do operador.
  2. Permita uma sobreposição limitada enquanto o Secret gerado ou o ExternalSecret é atualizado.
  3. Reinicie web e worker para que o init container regenere o arquivo montado.
  4. Exija que /api/health/ready e a validação de contrato live sejam aprovados.
  5. Revogue a credencial antiga e verifique métricas/logs de autenticação sanitizados.

​
Rotação de CA

  1. Publique um bundle temporário de CA contendo as CAs emissoras antiga e nova.
  2. Reinicie e valide web e worker.
  3. Rotacione o certificado de serviço do RGW.
  4. Publique o bundle de CA somente com a nova, reinicie e valide novamente.
  5. Registre as versões de recurso do ConfigMap, hashes SHA-256 da CA, versões exatas de ODF/Ceph e evidência — nunca valores de credenciais.
Consulte Saúde e solução de problemas do armazenamento e o k8s/overlays/openshift-odf-rgw/README.md no repositório para detalhes do overlay.