Skip to main content
이 프로필은 CaseBender를 기존 고객 관리 OpenShift Data Foundation(ODF) 또는 Ceph RGW에 연결합니다. CaseBender는 S3 클라이언트이며 ODF, Ceph, RGW, 사용자, 버킷을 설치, 업그레이드, 백업, 모니터링, 관리하지 않습니다.
현재 실환경 인증은 고객 자격 증명과 정확한 버전 증거를 대기 중입니다. 오버레이는 구성되고 자격 검증 준비 상태이며, 인증된 상태가 아닙니다.

​
스토리지 레이아웃

세 개의 독립된 외부 버킷을 프로비저닝하세요. 세 버킷 모두 시작 전에 존재해야 합니다. 런타임 어댑터는 버킷을 생성하지 않습니다. 오버레이는 HTTPS, path-style S3 주소 지정, 검증된 프라이빗 CA 신뢰, AES-256 서버 측 암호화 요청, SHA-256 애플리케이션 무결성을 사용합니다.

​
옵션 A: 외부 관리 OBC

고객이 승인한 RGW 버킷 StorageClass를 식별하세요.
k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml을 고객 환경 리포지토리로 복사하고, StorageClass 플레이스홀더를 교체한 뒤, CaseBender와 별도로 적용하세요. 버킷 수명 주기는 스토리지 운영자가 계속 소유합니다.
값을 출력하지 않은 채, 생성된 각 ConfigMap이 BUCKET_HOST, BUCKET_PORT, BUCKET_NAME, BUCKET_REGION을 제공하고, 각 Secret이 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY를 제공하는지 확인하세요. OBC 운영자가 다른 키를 사용하면 valueFrom을 패치하고, 자격 증명을 ConfigMap이나 Kustomize 파일에 복사하지 마세요.

​
옵션 B: 독립형 외부 RGW

k8s/overlays/openshift-odf-rgw/standalone-rgw-resources.example.yaml을 매핑 예로 사용하세요. 고객 오버레이에서 모든 .invalid 엔드포인트와 버킷 플레이스홀더를 교체하세요. 설치된 external-secret 컨트롤러 또는 다른 승인된 시크릿 인젝터를 사용하세요. 엔드포인트와 버킷 이름은 ConfigMap에, 자격 증명은 Secret에 두고, 실제 값은 모두 이 리포지토리 밖에 두세요. 제한된 init 컨테이너가 이러한 리소스를 읽고 메모리 백업 emptyDir에 모드 0400의 엄격한 STORAGE_CONFIG_FILE을 씁니다. 웹과 워커는 읽기 전용으로 마운트합니다.

​
프라이빗 CA

발급 체인만 포함하는 CA ConfigMap을 만드세요.
인증서는 정확한 RGW 호스트 이름을 포함해야 합니다. TLS 검증은 활성화된 상태로 유지됩니다. 목록에 없는 IP 주소, HTTP 엔드포인트, --insecure, 인증서 우회 옵션을 사용하지 마세요.

​
Egress

포함된 정책은 openshift-storage에서 app=rook-ceph-rgw로 레이블된 파드의 TCP 443에 웹과 워커가 도달하도록 허용합니다. 실제 네임스페이스, 레이블, 포트, CNI 동작을 확인하세요. 외부 RGW의 경우 external-rgw-network-policy.example.yaml을 복사하여 안정적인 승인 CIDR로 조정하거나, 운영자가 제어하는 egress 프록시를 통해 라우팅하세요. Kubernetes NetworkPolicy는 FQDN을 선택할 수 없습니다. 와일드카드 0.0.0.0/0 또는 ::/0 egress를 복원하지 마세요. PostgreSQL, Redis, 아이덴티티, 스캐너, 승인된 통합에 대해 별도의 최소 권한 정책을 추가하세요.

​
스캐너 전제 조건

프로덕션 사용자 업로드에는 외부 clamd가 필요합니다. 제공된 워커 패치는 casebender-malware-scanner(host, port)와 casebender-malware-scanner-ca(ca.crt)를 기대하고 TLS를 활성화합니다. 동일 파드 스캐너는 대신 CLAMD_SOCKET_PATH를 사용할 수 있습니다. 스캐너를 사용할 수 없으면 객체는 quarantine 상태로 남고 재시도는 결국 데드 레터가 될 수 있으며, 다운로드는 fail open하지 않습니다.

​
렌더 및 검증

그런 다음 워크로드 네트워크와 신뢰 컨텍스트에서 실환경 자격 검증을 실행하세요.
자격 증명은 전용 테스트 버킷/접두사로 범위가 제한된 AWS 자격 증명 체인을 통해 제공하세요. apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md를 작성하고 서명하세요. 렌더, 에뮬레이터 테스트, 서명되지 않은 트랜스크립트는 실환경 인증이 아닙니다.

​
자격 증명 로테이션

  1. 지원되는 ODF/Ceph 절차로 로테이션하고, 운영자가 소유한 OBC Secret을 수동으로 편집하지 마세요.
  2. 생성된 Secret 또는 ExternalSecret이 갱신되는 동안 제한된 중첩을 허용하세요.
  3. 웹과 워커를 재시작하여 init 컨테이너가 마운트된 파일을 다시 생성하게 하세요.
  4. /api/health/ready와 실환경 계약 검증이 통과해야 합니다.
  5. 이전 자격 증명을 폐기하고 정제한 인증 메트릭/로그를 확인하세요.

​
CA 로테이션

  1. 이전 및 새 발급 CA를 포함하는 임시 CA 번들을 게시하세요.
  2. 웹과 워커를 재시작하고 검증하세요.
  3. RGW 서비스 인증서를 로테이션하세요.
  4. 새 CA만 포함하는 번들을 게시하고, 재시작한 뒤 다시 검증하세요.
  5. ConfigMap 리소스 버전, CA SHA-256 해시, 정확한 ODF/Ceph 버전, 증거를 기록하세요. 자격 증명 값은 절대 기록하지 마세요.
스토리지 상태 확인 및 문제 해결과 리포지토리 내 k8s/overlays/openshift-odf-rgw/README.md에서 오버레이 세부 정보를 참고하세요.