シナリオ: Secrets Manager からユーザーの Kubernetes クラスターへのシークレットを統合する

あなたは金融機関のセキュリティ・アーキテクトである。 会社は、その競合上の優位性を維持および拡張するために、自社のお客様に強力な新しい体験をより早く提供する必要があります。 ところが、そのサービスとアプリケーションは、多くの場合、手動プロセスに依存する従来型のツールおよびインフラストラクチャー上に構築されているため、組織の開発速度は時間の経過とともに遅くなります。 速度を加速する必要がありますが、セキュリティーを犠牲にすることはできません。 お客様を危険にさらすことは許容されません。

IT 部門の速度を加速するために、ユーザーの組織は多くの検討を経て、大規模なイニシアチブで IBM Cloud を選択しました。 ユーザーのチームは移行開始にあたって、IBM Cloud Kubernetes Service を使用して、アプリケーションをコンテナー化して、クラウドに移動します。 自動化の一環として、数千の Kubernetes Service アプリケーション・シークレットを生成、保護、参照する機能が必要です。 デプロイメント時にこれらのシークレットを注入するのではなく、外部のシークレット管理サービスでこれらのシークレットを保護してから、アプリケーションの実行時にシームレスに取得する機能が必要です。

中央リポジトリーにシークレットを保管するためのソリューションとして、Secrets Manager を検討しました。 KubernetesAPIを External Secrets Operatorオープンソースプロジェクトで拡張することで、チームはIBM Cloud Secrets Managerを使用してKubernetesに安全にシークレットを追加できるようになります。

このシナリオは、Kubernetes クラスターで実行されるワークロードのコンプライアンスの準備に影響を及ぼす可能性のある、サード・パーティー・ツールを特徴としています。 コミュニティーまたはサード・パーティー・ツールを追加する場合、アプリのコンプライアンスを維持し、適切なプロバイダーと連携してあらゆる問題をトラブルシューティングする責任はお客様にあることに注意してください。 詳細については、IBM Cloud Kubernetes Service 使用の際の責任を参照してください。

アーキテクチャーおよびチュートリアルの例

PoC (概念検証) の構築を開始する準備はできましたか? このパターンについて詳しくは、開始に役立つチュートリアルを参照してください。