> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.
# OpenShift ODFおよびCeph RGWストレージ
> 顧客管理のOBCまたはスタンドアロンCeph RGWストレージにCaseBenderを接続する
このプロファイルは、既存の顧客管理OpenShift Data
Foundation（ODF）またはCeph RGWにCaseBenderを接続します。CaseBenderはS3クライアントであり、ODF、Ceph、RGW、ユーザー、またはバケットの
インストール、アップグレード、バックアップ、監視、管理は行いません。
現行の実環境認定は、顧客資格情報と正確バージョン
エビデンス待ちです。オーバーレイは設定済みで適格性確認の準備は完了していますが、認定済みではありません。
## ストレージレイアウト
3つの独立した外部バケットをプロビジョニングします。
| 用途プロファイル | 必須の動作 |
| ------------ | --------------------------------------- |
| `quarantine` | 初期ユーザーアップロード。スキャナー専用のプロモーションパス。公開アクセスなし |
| `records` | 永続的な添付/証拠/エクスポート。バージョニングと必須のWORM制御 |
| `ephemeral` | ディープカナリアと短寿命エクスポート。有界のライフサイクルポリシー |
3つすべてが起動前に存在している必要があります。実行時アダプターはバケットを作成しません。
オーバーレイはHTTPS、パススタイルS3アドレッシング、検証済みプライベートCA信頼、
AES-256サーバーサイド暗号化リクエスト、およびSHA-256アプリケーション整合性を使用します。
## オプションA: 外部管理OBC
顧客承認済みのRGWバケットStorageClassを特定します。
```bash theme={null}
oc get storageclass \
-o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner
oc api-resources | rg -i objectbucketclaim
```
`k8s/overlays/openshift-odf-rgw/object-bucket-claims.example.yaml`
を顧客環境リポジトリにコピーし、StorageClassプレースホルダーを置き換えて、
CaseBenderとは別に適用します。バケットライフサイクルの所有権は
ストレージ運用担当者に残ります。
```bash theme={null}
oc apply -f ''
oc -n casebender wait --for=jsonpath='{.status.phase}'=Bound \
objectbucketclaim/casebender-quarantine \
objectbucketclaim/casebender-records \
objectbucketclaim/casebender-ephemeral \
--timeout=10m
```
値を表示せずに、生成された各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コンテナはこれらのリソースを読み取り、厳密な
`STORAGE_CONFIG_FILE` をメモリバックの `emptyDir` にモード `0400` で書き込みます。Webと
ワーカーはそれを読み取り専用でマウントします。
## プライベートCA
発行チェーンのみを含むCA ConfigMapを作成します。
```bash theme={null}
oc -n casebender create configmap casebender-rgw-ca \
--from-file=ca.crt='' \
--dry-run=client -o yaml | oc apply -f -
```
証明書は正確なRGWホスト名をカバーする必要があります。TLS検証は
有効のままです。未掲載のIPアドレス、HTTPエンドポイント、`--insecure`、または
証明書バイパスオプションを使用してはなりません。
## Egress
同梱のポリシーは、Webとワーカーが `openshift-storage` 内の
`app=rook-ceph-rgw` ラベル付きポッドのTCP 443に到達することを許可します。実際の名前空間、ラベル、
ポート、およびCNIの動作を検証してください。
外部RGWでは、安定した承認済みCIDRで
`external-rgw-network-policy.example.yaml` をコピーして適応するか、
運用担当者が管理する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` を使用できます。スキャナーが利用できない場合、オブジェクトは
隔離されたままで、再試行は最終的にデッドレターになる可能性があります。ダウンロードは
フェイルオープンしません。
## レンダーと検証
```bash theme={null}
kubectl kustomize k8s/overlays/openshift-odf-rgw \
> /tmp/casebender-openshift-odf-rgw.yaml
./scripts/openshift/validate.sh \
/tmp/casebender-openshift-odf-rgw.yaml
oc apply --server-side --dry-run=server \
-f /tmp/casebender-openshift-odf-rgw.yaml
oc apply --server-side \
-f /tmp/casebender-openshift-odf-rgw.yaml
oc -n casebender rollout status deployment/webapp deployment/worker \
--timeout=10m
```
次に、ワークロードネットワークと信頼コンテキストから実環境適格性確認を実行します。
```bash theme={null}
STORAGE_TEST_ENDPOINT='https://' \
STORAGE_TEST_BUCKET='' \
AWS_REGION='' \
STORAGE_TEST_CA_BUNDLE='' \
STORAGE_TEST_ODF_VERSION='' \
STORAGE_TEST_CEPH_VERSION='' \
STORAGE_TEST_CAP_VERSIONING='' \
STORAGE_TEST_CAP_DELETE_MARKERS='' \
STORAGE_TEST_CAP_OBJECT_LOCK='' \
./scripts/storage/validate-ceph-rgw.sh
```
資格情報はAWS資格情報チェーン経由で、専用の
テストバケット/プレフィックスにスコープして供給します。
`apps/docs/en/deployment/odf-ceph-rgw-validation-evidence.md` を完成させて署名します。レンダー、
エミュレーターテスト、または未署名のトランスクリプトは実環境認定ではありません。
## 資格情報ローテーション
1. サポートされるODF/Ceph手順でローテーションする。オペレーター所有のOBC Secretを
手編集しない。
2. 生成されたSecretまたはExternalSecretが
更新される間、有界のオーバーラップを許可する。
3. Webとワーカーを再起動し、initコンテナがマウントファイルを再生成するようにする。
4. `/api/health/ready` および実環境契約検証の合格を要求する。
5. 古い資格情報を失効させ、サニタイズした認証メトリクス/ログを確認する。
## CAローテーション
1. 新旧の発行CAを含む一時CAバンドルを公開する。
2. Webとワーカーを再起動して検証する。
3. RGWサービング証明書をローテーションする。
4. 新CAのみのバンドルを公開し、再起動して再度検証する。
5. ConfigMapのリソースバージョン、CA SHA-256ハッシュ、正確なODF/Ceph
バージョン、およびエビデンスを記録する。資格情報の値は記録しない。
[ストレージヘルスとトラブルシューティング](/ja/deployment/storage-health-troubleshooting)
およびリポジトリ内の
`k8s/overlays/openshift-odf-rgw/README.md` でオーバーレイの詳細を参照してください。