Skip to main content
このプロファイルは、既存の顧客管理OpenShift Data Foundation（ODF）またはCeph RGWにCaseBenderを接続します。CaseBenderはS3クライアントであり、ODF、Ceph、RGW、ユーザー、またはバケットの インストール、アップグレード、バックアップ、監視、管理は行いません。
現行の実環境認定は、顧客資格情報と正確バージョン エビデンス待ちです。オーバーレイは設定済みで適格性確認の準備は完了していますが、認定済みではありません。

​
ストレージレイアウト

3つの独立した外部バケットをプロビジョニングします。 3つすべてが起動前に存在している必要があります。実行時アダプターはバケットを作成しません。 オーバーレイはHTTPS、パススタイル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コンテナはこれらのリソースを読み取り、厳密な STORAGE_CONFIG_FILE をメモリバックの emptyDir にモード 0400 で書き込みます。Webと ワーカーはそれを読み取り専用でマウントします。

​
プライベートCA

発行チェーンのみを含むCA ConfigMapを作成します。
証明書は正確な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 を使用できます。スキャナーが利用できない場合、オブジェクトは 隔離されたままで、再試行は最終的にデッドレターになる可能性があります。ダウンロードは フェイルオープンしません。

​
レンダーと検証

次に、ワークロードネットワークと信頼コンテキストから実環境適格性確認を実行します。
資格情報は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 バージョン、およびエビデンスを記録する。資格情報の値は記録しない。
ストレージヘルスとトラブルシューティング およびリポジトリ内の k8s/overlays/openshift-odf-rgw/README.md でオーバーレイの詳細を参照してください。