SCCチュートリアル

このハンズオンチュートリアルは、保護された Linux 機能へのアクセスを必要とするワークロードを Red Hat OpenShift クラスタ上に展開する方法を知りたいと考えている開発者やクラスタ管理者を対象としています。このチュートリアルでは、アプリケーションが必要とするアクセスでコンテナを構成するために、デプロイメントマニフェストでセキュアコンテキスト (SC) を指定する方法を示します。また、そのアクセスをデプロイメントに付与するために、セキュリティコンテキスト制約（SCC）を構成する方法についても説明します。

デフォルトでは、コンテナはプロセスが保護された関数を呼び出すのをブロックします。以下のような機能を実行するには、セキュリティコンテキスト（SC）が明示的にアクセスを要求する必要があります。 * 特定のユーザまたはグループとしてプロセスを実行する。 * プロセスを追加のグループのメンバーにする * 特権コンテナの実行 * KILL コマンドなどの保護されたコマンドの実行

配置はこのアクセスを要求できますが、SCC はそれを承認する必要があります。このチュートリアルでは、作業の実行に必要な最小の権限セットでカスタム SCC を設定する方法と、このカスタム SCC に配置を関連付ける方法を示します。このベストプラクティスは、必要に応じて追加の権限を要求および付与する方法を提供しながら、意図的および偶発的な被害からクラスタを保護するのに役立ちます。

学習目標¶

このチュートリアルでは、簡単なデプロイメントを作成します。デプロイメントは、仕様書で要求されたポッドを立ち上げます。このチュートリアルでは、エフェメラルボリュームをマウントし、1つのコンテナを実行するシンプルなポッドを使用します。リモートシェルを使ってコンテナにコマンドを実行し、実行環境やパーミッションを調べることができます。

その方法を学びます。

ポッドの YAML をチェックして、設定されている SC と割り当てられた SCC を確認する。
デフォルトのサービスアカウントとデフォルトのSCを使用して、アクセス権限をテストする。
SCCの検証エラーを示すエラーイベントの確認
SCCを作成して、サービスアカウントに割り当てる *SCCを作成し、サービスアカウントに割り当てる * 特別な権限を要求するSCと、それを許可するSCCを使用する

セキュリティコンテキスト制約の概念¶

このハンズオンチュートリアルに挑戦する前に、SCCがどのように使用されるかを理解しておく必要があります。記事「Overview of security context constraints」では、これらの全体的な概念が説明されており、以下のようにまとめられています。

アプリケーションが保護された機能にアクセスすることは、3つのペルソナ間の合意である。

保護された機能にアクセスするアプリケーションを作成する 開発者 。
アプリケーションが必要とするアクセスを要求するデプロイメントマニフェストを作成する デプロイヤー 。
管理者：要求されたアクセスをディプロイメントに許可するかどうかを決定します。

この図は、アプリケーションがリソースにアクセスするためのコンポーネントとプロセスを示しています。

トップレベルの図

開発者が、保護された機能へのアクセスを必要とするアプリケーションを作成します。
デプロイ担当者は、アプリケーションをデプロイするための デプロイメントマニフェスト を作成し、それを構成するポッドスペックを作成する。
- アプリケーションが必要とするアクセスを要求する セキュリティ・コンテキスト(SC) (ポッドおよび/またはコンテナごとに)、それによって以下を要求する
- 要求されたアクセスを許可するための サービスアカウント です。
管理者は、要求されたアクセスを許可するサービスアカウントに セキュリティコンテキスト制約（SCC） を割り当てます。SCCは、サービスアカウントに直接、またはRBACロールやグループを介して間接的に割り当てることができます。
SCC は OpenShift の定義済み SCC の 1 つである場合もあれば、カスタム SCC である場合もあります。
SCC がアクセスを許可した場合、アドミッションプロセスによってポッドのデプロイが許可され、ポッドは指定されたとおりにコンテナを構成します。

_Note: OpenShiftのサービスアカウントは、通常のユーザーの認証情報を使用せずにプログラム的に使用される特別なタイプのユーザーアカウントです。

前提条件¶

OpenShift クラスタへのアクセス
クラスタ管理者権限
OpenShift CLI (oc)
bash または zsh ターミナル（または同様のもの）。
作業する OpenShift プロジェクト

Optional: このドキュメントまたはGitHub repoから、いくつかのコードをコピー＆ペーストする必要があります。ブラウザでレポを表示してそこからコードをコピーするか、レポをクローンしてコードのローカルコピーを作成することができます。

_Note: このチュートリアルでは、SCCがユーザー、グループ、ファイルシステムグループ、サプリメンタルグループなどのLinuxの機能を使って、ファイルのアクセス許可や所有権の設定を管理する方法を説明します。これらの機能についての再確認は、「【Linuxを学ぶ】101：ファイルのパーミッションとオーナーシップの管理」(https://developer.ibm.com/tutorials/l-lpic1-104-5/)をご覧ください。

見積もり時間¶

このチュートリアルを完了するには、約1時間かかります。

ステップ¶

デフォルトのデプロイメントを作成する
- ベースイメージを使用してアプリケーションをシミュレートします。
- デフォルトのSCとSCCを調べる
- コンテナのランタイムパーミッションをテストする
SC を使ったデプロイメントの試み
- デプロイメントに特別なパーミッションを要求する
- 割り当てられていない権限を要求したときに、デプロイメントがどのように失敗するかを確認する
SCCの作成と割り当て
- デプロイメントの SC を許可する SCC を作成します。
- SCCを使用するロールを作成します。
- ロールをサービスアカウントにバインドする
SCC を使用するサービスアカウントを使用して配置を作成する
- SCC を使用して配置を検証します。
- 結果のSCと選択されたSCCを調べる
- コンテナの新しいランタイムパーミッションをテストする

ペルソナ¶

ステップ1、2、4は、デプロイメントを作成する権限を持つユーザー（デプロイ担当者）が行います。デプロイ担当者は、ポッドやコンテナが必要とするパーミッションを要求するSCを指定する責任があります。デプロイ担当者は、要求されたパーミッションを検証するために使用するサービスアカウントも選択できます。

ステップ3は、クラスタ管理者が実行します。SCCの作成と割り当ては、パーミッションを制限するために行うことができますが、パーミッションを緩和して脆弱性を作り出すこともできます。このため、クラスター管理者は、どのSCCをクラスター内で許可するか、いつプロジェクトのサービスアカウントに割り当てるかを決定する必要があります。

_WARNING:SCC に特権が与えられ、SCC がプロジェクト・サービス・アカウントに付与されると (例えば、ロール・バインディングを介して)、プロジェクト内のどのデプロイ担当者もその特権を利用することができます。

ステップ 1: デフォルトのデプロイメントの作成¶

この最初のステップでは、以下の方法を説明します。

ベースイメージを使用してアプリケーションをシミュレートする
デフォルトのSCとSCCを確認する。
コンテナのランタイムパーミッションのテスト

見ることができます。

デフォルトで割り当てられているSCC
ポッドとコンテナに追加されたデフォルトのSC
コンテナを実行するために割り当てられたユーザーID
ユーザーのグループメンバーシップ
ユーザーIDとグループメンバーシップがデータアクセスに与える影響

ベースイメージを使ったアプリケーションのシミュレーション¶

ここでは、シンプルなコンテナを使って、ファイルシステムに書き込むアプリケーションをシミュレートし、パーミッションを実験します。GUIを持つアプリケーションの代わりに、ベースイメージに過ぎないコンテナを実行し、そのコンテナ内でシェルを使用します。ファイルシステムの代わりに、コンテナ内に emptyDir ボリュームをマウントします。これにより、一時的にマウントされたボリューム上でLinuxコマンドを実行し、権限やアクセス制御をテストすることができます。

ターミナルで起動します。
- 認証情報を入力してログインしてください。
- プロジェクトに切り替えます。
アピバージョン: アプリ/v1 kind:デプロイメント metadata: name: scc-tutorial-deploy-sc spec: セレクタ matchLabels: アプリ: scc-tutorial-sc template: metadata: ラベルを表示します。アプリ: SCC-TUTORI-SC spec: コンテナを使用しています。 - イメージ: ubi8/ubi-minimal 名前: ubi-minimal コマンドを実行します。['sh', '-c', 'echo "Hello from user $(id -u)" && sleep infinity'] です。 securityContext: runAsUser: 1234 runAsGroup:5678 volumeMounts: - mountPath:マウントパス: /var/opt/app/data 名前: データ serviceAccountName: default securityContext: fsGroup:5555 supplementalGroups:[5777, 5888] のボリュームです。 - emptyDir: {} 名前: データ oc create -f deploy_sc.yaml

出力には ReplicaFailure が表示されます。

レプリカセットが失敗した理由をもっと具体的に知りたい場合は、oc get eventsを使います。

* FailedCreateの警告は、fsGroupとrunAsUserの値が原因で、どのセキュリティコンテキスト制約*に対しても検証できなかったことを明確に示しています。

このエラーは、ディプロイメント マニフェストが特定のパーミッションを要求し、デフォルトのサービス アカウントがこれらのパーミッションを許可する SCC を使用できないために発生します。これは、ディプロイメント担当者がマニフェストで要求したアクセス数が多すぎるか、クラスタ管理者がより多くのアクセスを許可するSCCを提供する必要があることを示しています。

ディプロイメントがディプロイされていないように見えるかもしれませんが、それは問題ではありません。`scc-tutorial-deploy-sc`という名前のディプロイメントが作成されています。それを探すには、`oc get deployment` または OpenShift Web Console のいずれかを使用できます。`scc-tutorial-deploy-sc-<generated-suffix>`という名前のレプリカセットも作成されていますが、どちらも1ポッド中0ポッドが作成されたことを示しており、レプリカセットには問題を説明するイベントがあります。

つまり、最終的にデータアクセスエラーが発生するアプリケーションをデプロイするのではなく、原因を説明するエラーメッセージを表示して早期に失敗させるのです。早期に失敗することは、間違いなく良いことです。このアプリケーションに必要な特別なパーミッションを明確に示すことで、開発者、デプロイ担当者、セキュリティ管理者は、このデプロイメントに必要な特別なセキュリティ要件をうまく伝えることができます。

ステップ 3: SCC の作成と割り当て¶

_Note: このステップでは、クラスタ管理者である必要があります。

ここからは、SCCとロールベースのアクセス制御（RBAC）を使用して、ワークロードが作業を行うために必要な権限を与えることになります。

YAMLファイルをthis GitHub repoからダウンロードするか、コピー/ペーストして、scc-tutorial-scc.yamlという名前のファイルに保存します。

oc create -f deploy_sc_sa.yaml
以下のコードリストでは、興味深い部分を強調しています（次のセクションで詳しく説明します）。