目標

• 信頼できるプロファイルのユース・ケースについて説明します。
• 信頼できるプロファイルの作成とクラウド・リソースへのアクセスの管理
• Identity and Access Management (IAM) の知識を深める

• アプリケーションのコンテナー・イメージが Container Registry からプルされ、 Kubernetes クラスターの名前空間にデプロイされます。
• ユーザーがアプリケーションに接続します。
• アプリケーションは、 Kubernetes 環境から特殊なアクセス・トークンを読み取り、それをトラステッド・プロファイルの IAM アクセス・トークンに変換します。
• IAMは監査イベントをIBM Cloud Activity Tracker Event Routingに記録する。

開始前に

このチュートリアルでは、インストールする必要はなく、 IBM Cloud コンソールのみを使用します。

The IBM Cloud Activity Tracker Event Routing must be configured to route auditing events to a IBM Cloud Logs target instance. 現在アカウントで設定されていない場合は、IBMLogs ターゲットの設定 に記載されているように、グローバル監査イベントをルーティングします。

概要: トラステッド・プロファイル

ユーザーおよびサービス ID と同様に、 トラステッド・プロファイル は、IAM ポリシーでアクセス権限を付与できる ID です。 信頼できるプロファイルは、API キーを作成および所有できないという点で異なります。 これらは、特定のアカウント内の ID であり、API キーを必要とせずにそのアカウント内で作業するための「ゲートウェイ」として機能します。 これらのユーザーは、そのトラステッド・プロファイルの ID を想定できます。

信頼できるプロファイルのセットアップの一部として、そのユーザーまたは他のユーザー (以下を参照) を構成します。 通常使用可能なオプションはすべて、 IBM Cloud API、CLI、使用可能な SDK、Terraform、または IBM Cloud コンソールのいずれかです。

コンソールでは、IAM カテゴリーの一部として、 トラステッド・プロファイル に独自のセクションがあります。 そこでは、簡単に作成して管理することができます。 以下のスクリーン・ショットは、トラステッド・プロファイルを作成するためのダイアログの 2 番目のステップを示しています。 信頼を確立する方法を構成する ことができます。どのエンティティーがトラステッド・プロファイルの ID を引き継ぐことができます。 これは、以下の 1 つ以上です。

• フェデレーテッド・ユーザー
• コンピュート・リソース
• IBM Cloud サービス
• サービス ID

トラステッド・プロファイルのユース・ケース

トラステッド・プロファイルは、 IBM Cloud内の ID です。 これらのユーザーは、IAM アクセス・グループのメンバーになることができます。これにより、アクセス権が割り当てられます。 ユーザーおよびサービス ID と同様に、トラステッド・プロファイルへのアクセス権限を直接割り当てることもできます。 識別機能とは、特定の ID またはリソースがその ID の下で動作できるように、トラステッド・プロファイルを構成する機能のことです。 これらの ID およびリソースは、他のアカウントに配置されている場合もあります。 したがって、高水準では、 トラステッド・プロファイルを使用するための ユース・ケースは、管理作業を許可することです。

• 与えられた特権のセットで
• 特定のアイデンティティーの下で
• トラステッド・プロファイルの一部として構成された一連のプロパティーによって識別される ID またはリソースの場合。

以下のシナリオは、トラステッド・プロファイルのこのようなユース・ケースであり、信頼が確立される方法によって異なります。

• フェデレーテッド・ユーザーとそのグループ・メンバーシップを IBM Cloud 特権にマップ: フェデレーテッド ID プロバイダーのユーザーがその ID を使用できるように、トラステッド・プロファイルを構成します。 どの IdP とどのユーザー属性を考慮するかを定義できます。
• 専用のコンピュート・リソースから管理用タスクを実行する: 既知のコンピュート・リソースを介して信頼を確立するようにトラステッド・プロファイルを構成できます。 このようなリソースは、 Kubernetes クラスター内の特定のポッド ( Red Hat OpenShift on IBM Cloudを含む) または仮想プライベート・クラウド内の仮想サーバー・インスタンス (VSI) (IBM Cloud VPC) である可能性があります。
• 既知のサービス ID から管理用タスクを実行する: 同じアカウントまたは別のアカウントからのサービス ID は、トラステッド・プロファイルの ID を引き継ぐことができます。
• 特別なクラウド・サービスのインスタンスからクラウド・リソースをデプロイする: CRN (クラウド・リソース名) で識別される IBM Cloud サービスのインスタンスを、信頼できるプロファイルの ID を想定するように構成します。 典型的なシナリオは、 エンタープライズ・プロジェクトでアーキテクチャー をデプロイする場合です。

信頼の確立

概要に概説されているように、信頼を確立する方法、およびエンティティーがトラステッド・プロファイルの ID を想定する方法については、さまざまなオプションを使用できます。

コンピュート・リソースを含むトラステッド・プロファイル

理論を実践するために、IBM Cloudアカウントでタスクを実行するコンテナ化されたアプリを認可する。 このアプリは Kubernetes クラスタにデプロイされます。 これは、トラステッド・プロファイルを使用するための信頼を確立するために使用される計算リソースとして機能します。 複数のタブが開いている Web ブラウザーで、以下のすべてのステップを実行できます。 ブラウザーのタブは、必ず指示どおりに開いたままにしてください。

セキュリティー上の理由から、アプリは読み取り専用モードで動作しています。 デプロイされたリソースのリストを収集しようとします。 読み取ることができるリソースを決定する特権をアプリに割り当てます。 さらに、パブリック・インターネットからではなく、 Kubernetes クラスター内からのみアクセスできるように、アプリをある方法でデプロイします。

ブログ投稿 Turn Your Container Into a Trusted Cloud Identity では、同じシナリオについて説明しています。

コンピュート・リソースとしての Kubernetes クラスター

Kubernetes Service は、Kubernetes クラスターで実行されるコンテナーに高可用性のアプリをデプロイする環境を提供します。

このチュートリアルで再利用したい既存のクラスタがある場合は、このセクションをスキップしてください。このチュートリアルの残りの部分では、クラスタ名は 「mycluster-tpcr」 として参照されます。ご自身のクラスタ名に置き換えてください。 Kubernetes の 1.21 の最小要件バージョンに注意してください。

このチュートリアルでは、ゾーン 1 つ、ワーカー・ノード 1 つ、提供されている最小サイズ ( フレーバー ) で構成される最小クラスターで十分です。 1.21 の Kubernetes バージョン以上が必要です。 クラスターの作成時には、適切なバージョンを選択してください。

Kubernetes クラスター を開き、 「クラスターの作成」 をクリックします。 クラスター・タイプに基づく詳細については、以下の資料を参照してください。 要約:

• 標準クラスタをクリック
• VPC インフラストラクチャー上の Kubernetes については、参照資料 VPC クラスターの作成 を参照してください。
  • 「VPC の作成」 をクリックします。
    • VPC の名前を入力します。
    • クラスターと同じリソース・グループを選択します。
    • 「作成」 をクリックします。
  • 作成した各サブネットに Public Gateway を接続します。
    • 仮想プライベート・クラウド にナビゲートします。
    • クラスターに使用する、以前に作成した VPC をクリックします。
    • 「サブネット」セクションまでスクロールダウンし、サブネットをクリックします。
    • Public Gateway セクションで、 「切り離し」 をクリックして状態を 「接続済み」 に変更します。
    • ブラウザーの 「戻る」 ボタンをクリックして、VPC の詳細ページに戻ります。
    • 上記の 3 つのステップを繰り返して、各サブネットにパブリック・ゲートウェイを接続します。
• クラシック・インフラストラクチャー上の Kubernetes については、参照資料 クラシック・クラスターの作成 を参照してください。
• リソース・グループを選択してください。
• 1 つを除くすべてのゾーンのチェック・マークを外します。
• 1 つの ワーカー・ノード/ゾーンにスケールダウンします。
• 最小の ワーカー・プール・フレーバーを選択します。
• 「クラスター名」 には mycluster-tpcr を使用します。
• このチュートリアルの完了後に削除されるこのデモクラスタのセキュリティオプションをすべてオフにします。 他のクラスターを作る際には、これらを慎重に評価することが重要になるだろう。

クラスターがプロビジョンされたら、ブラウザー (「クラスターの概要 (cluster overview)」) タブを開いたままにし、後で使用できるようにします。 それでも次のステップに進むことができます。

トラステッド・プロファイルの作成

1. 新しいブラウザー・タブ (「IAM トラステッド・プロファイル」) で、上部ナビゲーション 「管理」 > 「アクセス (IAM)」 を使用し、左側の 「トラステッド・プロファイル」 を使用して、 トラステッド・プロファイル の概要を表示します。 次に、新しい信頼済みプロファイルを作成します。
2. TPwithCR を 「名前」 として使用し、短い 説明(例: Test trusted profile with compute resource) を入力します。 その後、 「続行」 をクリックします。
3. 「Select trusted entity type」 の下の 2 番目のフォーム・タブで、 「Compute resources」 を選択すると、 「Create trust relationship」 ダイアログが表示されます。 そこで、 「サービス・タイプの計算 (Compute service type)」 として Kubernetes を選択します。
4. 次に、すべてのサービス・リソースを決定することも、特定のサービス・リソースを決定することもできます。
   • 「特定のリソース」 をクリックすると、次のフォーム・フィールドが表示されます。
   • 「インスタンスを入力または選択してください」 で、 「リソースの追加」 をクリックします。 次に、 「アクセスを許可 (Allow access to)」 フィールドで、 Kubernetes クラスター mycluster-tpcr を選択します。
   • 次に、 「名前空間」 の値として tptest と入力します。 「サービス・アカウント」 のフィールドは、デフォルトのままにします。
   • 「続行」 をクリックして終了します。
5. 次に、 「アクセス・ポリシー」 をクリックします。 サービスのリストで、 「すべての ID およびアクセス対応サービス」 を選択し、 「次へ」 をクリックします。 「すべてのリソース (All resources)」 を選択し、 「次へ」 を再度クリックし、 「ビューアー (Viewer)」 を選択して、 「次へ」 を再度クリックします。 「役割とアクション」 セクションで、 「サービス・アクセス」 の場合は 「リーダー」 を選択し、 「プラットフォーム・アクセス」 の場合は 「ビューアー」 を選択します。 完了したら、 「次へ」 をクリックし、最後に 「追加」 をクリックします。
6. 右側の 「要約」 を確認し、表示された信頼関係とリストされたアクセス権を使用してトラステッド・プロファイルを 作成 します。 後で使用するために、ブラウザー・タブを開いたままにします。

アクセス・グループを使用したアクセス権限の割り当ては、ベスト・プラクティスです。 簡単にするために、直接アクセス・ポリシーを使用して読み取り専用アクセス権限を割り当てることを選択しました。 割り当てられた特権を持つアクセス・グループを作成してから、トラステッド・プロファイルをそのグループのメンバーにすることをお勧めします。

アプリのデプロイ

Kubernetes クラスターと信頼できるプロファイルを配置することで、単純なテスト・アプリをデプロイすることができます。 アプリと構成のソース・コードは、 GitHub リポジトリー trusted-profile-enterprise-securityにあります。 デプロイメントには必要ありませんが、それでも機能する方法に関心がある場合があります。

1. ブラウザーの *「クラスターの概要」*タブで、クラスターが完全にデプロイされていることを確認します。 1ノード構成では、イングレス・ステータスは警告を報告するかもしれない。 ブラウザを更新し、他のチェックマークが緑色になっていることを確認するとよい。 その場合は、 Kubernetes ダッシュボード をクリックすると、新しいブラウザー・タブが開きます (Kubernetes ダッシュボード)。

2. 左上で、名前空間セレクターを見つけて、 「すべての名前空間」 に切り替えます。

3. 右上で、 「+」 をクリックして新規リソースを作成します。 以下の内容を 「入力から作成」 テキスト・フォームに貼り付けます。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: tptest
     labels:
       name: tptest
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: trustedprofile-test
     namespace: tptest
   spec:
     ports:
     - port: 8080
       targetPort: 8080
       protocol: TCP
     type: ClusterIP
     selector:
       app: tptest
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: trustedprofile-test-deployment
     namespace: tptest
   spec:
     selector:
       matchLabels:
         app: tptest
     replicas: 1
     template:
       metadata:
         labels:
           app: tptest
       spec:
         containers:
         - name: tptest-container
           image: icr.io/solution-tutorials/tutorial-trusted-profile-enterprise-security:v1.0.3
           imagePullPolicy: Always
           ports:
           - containerPort: 8080
           volumeMounts:
           - mountPath: /var/run/secrets/tokens
             name: sa-token
         serviceAccountName: default
         volumes:
         - name: sa-token
           projected:
             sources:
             - serviceAccountToken:
                 path: sa-token
                 expirationSeconds: 3600
                 audience: iam
   

   次に、 「アップロード」 をクリックして、アプリケーションのリソースを作成します。 これには、新しい Kubernetes 名前空間 tptest、デプロイメント、ポッド付きのサービスが含まれています。

   上記の YAML 構成の ソース・コードは、 GitHubにあります。

4. 左側のナビゲーション列で、 「デプロイメント」 をクリックして、新規デプロイメント trustedprofile-test-deployment の状態を確認します。 次に、同じナビゲーション列で 「ポッド」 をクリックし、 trustedprofile-test-deployment で始まる名前のポッドに注目します。 緑色の状況が表示されたら、次のセクションに進みます。

トラステッド・プロファイルのテスト

信頼できるプロファイルと、実行中のアプリが配置されている Kubernetes クラスターを使用して、テストを行います。 ブラウザベースのシェルを開いてコマンドを実行し、コンテナログ用のタブを開き、IBM Cloud Logsログ用の別のタブを開くことから始める。

1. ポッドが含まれている現在アクティブなタブ Kubernetes ダッシュボード で、右側に 3 つのドットがあるメニューをクリックし、そのメニューの 「実行」 を 右クリック します。 新しいタブ (コンテナー・シェル) でリンクを開くことを選択します。 実行中のコンテナーのシェルを開きます。 ブラウザーのタブ Kubernetes ダッシュボードで、3 つのドットのメニューを再度クリックし、 「ログ」 を左クリックします。 新しい 3 つのドットのメニューで、 「自動最新表示」 を有効にします。

   最後に、IBM Cloud Logsサービスのタブを開き、クラウドログタブを選択して、監査イベントを受信しているインスタンスの名前をクリックします。

2. ブラウザー・タブの *「コンテナー・シェル」*で、シェルで以下のコマンドを実行してアプリをテストします。

   curl -s localhost:8080
   

   上記は、 codeversion と result を含む JSON オブジェクトを返します。 Kubernetes ダッシュボード ・タブに、ログを含む新しいログ・アクティビティーが表示されます。 次に、 「コンテナー・シェル」 タブで、以下のコマンドを実行します。

   curl -s localhost:8080/api/listresources_crn | jq
   

   このコマンドは、アカウント内のリソースのリストを取得しようとしてアプリを呼び出しますが、信頼できるプロファイル名が指定されていません。 結果は、エラー・メッセージを含むフォーマット済み JSON オブジェクトになります。

3. 上記のコマンドを繰り返しますが、ここで、使用するトラステッド・プロファイルを指定します。

   curl -s localhost:8080/api/listresources_crn?tpname=TPwithCR | jq
   

   これで、結果は、アカウント内のリソースに関する情報を含むフォーマット設定された JSON オブジェクトになります。 読みやすくするために、リソース CRN のみが返されます。 オブジェクトの全詳細については、 localhost:8080/api/listresources を使用してください。 また、存在しない別のトラステッド・プロファイル名を試して、エラー・メッセージを調べることもできます。

   呼び出されると、アプリは最初にコンピュート・リソースのトークンを読み取ります。 次に、指定されたトラステッド・プロファイルの トークンを IAM アクセス・トークンに変換 します。 最後に、 IBM Cloud リソース・コントローラー API を呼び出して、サービス・インスタンスに関する情報を取得します。 結果は、トラステッド・プロファイルの構成済み特権によって異なります。 関心がある場合は、 アプリのソース・コードを調べます。

4. ブラウザのタブをIBM Cloud Logsに切り替え、一番下にある検索ボックスを使ってプロファイルという用語を探します。 これは監査イベント・ターゲットとして構成されたインスタンスでなければならない。 It should return at least one line with IAM Identity Service: login.computeresource-token TPwithCR. Open the info panel to expand the record to examine details, look for the イニシエーター section. これは、要求に使用されたトラステッド・プロファイルと、計算リソースに関する情報をリストします。 authName は、Kubernetesダッシュボードのブラウザタブからあなたのデプロイメントと一致する必要があります。

   

5. 次に、ブラウザー・タブ Kubernetes ダッシュボード にアクセスして、コンテナー・ログを確認します。 アプリケーションは、リソースをリストするための認証に使用する JWT アクセス・トークン に詳細を出力します。 sub (サブジェクト) を 2 回含めて、個々のキー/値のペアを調べます。 これらは、トラステッド・プロファイルと計算リソースに関連しています。

6. TPwithCR の構成を使用して、ブラウザー・タブ 「IAM トラステッド・プロファイル」 に切り替えます。 フォームで、 「アクセス」 タブをクリックし、 「すべての ID およびアクセス対応サービス」 の 3 つのドット・メニューで 「編集」 を選択します。 ここで、 「 TPwithCRのポリシーの編集 (Edit policy for TPwithCR)」 が表示されます。 「リソース」 の 「編集」 をクリックし、 「特定のリソース」 を選択します。 「属性タイプ」 および 「値」 として 「地域」 を選択します (例: フランクフルト)。 「保存」 を押して終了します。

7. ブラウザー・タブ container shell に戻り、以下のコマンドを再度実行してリソースをリストします。

   curl -s localhost:8080/api/listresources?tpname=TPwithCR | jq
   

   結果は、アカウント内の他のリソースをどこにデプロイしたかによって、上記とは異なる場合があります。 IBM Cloud Logsログと Kubernetesダッシュボードのブラウザタブを再確認して、新しいログアクティビティを確認します。

8. ステップ 6 に戻り、アクセス・ポリシーを再度編集してから、ステップ 7 で再テストすることをお勧めします。 アクセス・ポリシーを編集する方法として、 「すべての ID およびアクセス対応サービス (All Identity and Access enabled services)」 ではなく、地域を追加したり、特定のサービスに制限したりすることが考えられます。

リソースを削除する

信頼できるプロファイルとコンピュート・リソースを使用して上記のシナリオのテストが完了したら、以下の手順に従ってリソースを削除できます。

1. Kubernetes クラスターを削除するには、ブラウザー・タブ *「クラスターの概要」*の右上にある 「アクション」 をクリックし、 「クラスターの削除」 をクリックします。
2. 信頼済みプロファイル TPwithCR があるタブIAM trusted profilesで、Actions と Remove をクリックして信頼済みプロファイルを削除します。

リソースによっては、即時に削除されずに保持される場合があります (デフォルトでは 7 日間)。 リソースを完全に削除して再利用することも、保存期間内に復元することもできます。 リソースの再利用を使用する方法については、この資料を参照してください。

関連コンテンツ

• アプリと構成のソース・コードは、 GitHub リポジトリー trusted-profile-enterprise-security にあります。
• ブログ投稿 Turn Your Container Into a Trusted Cloud Identity
• ブログ投稿 Secure Onboarding for Your Work子 and Hackathons