Red Hat SummitThis documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第16章 SCC (Security Context Constraints) の管理
16.1. SCC (Security Context Constraints) について
RBAC リソースがユーザーアクセスを制御するのと同じ方法で、管理者は SCC (Security Context Constraints) を使用して Pod のパーミッションを制御できます。これらのパーミッションには、コンテナーのコレクションである pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行についての条件の一覧を定義することができます。
SCC により、管理者は以下を制御できます。
- Pod が特権付きコンテナーを実行できるかどうか。
- コンテナーが要求できる機能。
- ホストディレクトリーのボリュームとしての使用。
- コンテナーの SELinux コンテキスト
- コンテナーのユーザー ID。
- ホストの namespace およびネットワークの使用
-
Pod のボリュームを所有する
FSGroupの割り当て。 - 許可される補助グループの設定。
- コンテナーが読み取り専用のルートファイルシステムの使用を要求するかどうか。
- ボリュームタイプの使用。
-
許可される
seccompプロファイルの設定。
Docker には、Pod の各コンテナーについて許可されるデフォルトの機能一覧があります。コンテナーはこれらの機能をデフォルト一覧から使用しますが、Pod マニフェストの作成者は追加機能を要求したり、デフォルトからデフォルト動作の一部を削除してこの一覧を変更できます。allowedCapabilities、defaultAddCapabilities、および requiredDropCapabilities パラメーターは Pod からのこのような要求を制御し、要求できる機能を決定し、各コンテナーに追加するものや禁止する必要のあるものを決定するために使用されます。
クラスターには、8 つのデフォルト SCC が含まれます。
-
anyuid -
hostaccess -
hostmount-anyuid hostnetwork警告追加のワークロードをマスターホストで実行する場合、
hostnetworkへのアクセスを提供する際には注意して行ってください。マスターホストでhostnetworkを実行するワークロードには クラスター上で root アクセスを持つユーザーと同じ機能があるため、適切に信頼される必要があります。-
node-exporter -
nonroot -
privileged -
restricted
デフォルトの SCC は変更しないでください。デフォルトの SCC をカスタマイズすると、OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。代わりに新規の SCC を作成してください。
privileged SCC は以下を許可します。
- ユーザーによる特権付き Pod の実行
- Pod によるホストディレクトリーのボリュームとしてのマウント
- Pod の任意ユーザーとしての実行
- Pod の MCS ラベルの使用による実行
- Pods によるホストの IPC namespace の使用
- Pod によるホストの PID namespace の使用
- Pod による FSGroup の使用
- Pod による補助グループの使用
- Pod による seccomp プロファイルの使用
- Pod による機能の要求
restricted SCC は以下を実行します。
- Pod が特権付き Pod として実行されないようにします。
- Pod がホストディレクトリーのボリュームをマウントできないようにします。
- Pod が事前に割り当てられた UID の範囲でユーザーとして実行されることを要求します。
- Pod が事前に割り当てられた MCS ラベルで実行されることを要求します。
- Pod が FSGroup を使用することを許可します。
- Pod が補助グループを使用することを許可します。
それぞれの SCC についての詳細は、SCC で利用可能な kubernetes.io/description アノテーションを参照してください。
SCC は Pod がアクセスできるセキュリティー機能を制限する各種の設定およびストラテジーで構成されています。これらの設定は以下のカテゴリーに分類されます。
| ブール値による制御 |
このタイプのフィールドはデフォルトで最も制限のある値に設定されます。たとえば、 |
| 許可されるセットによる制御 | このタイプのフィールドはセットに対してチェックされ、それらの値が許可されることを確認します。 |
| ストラテジーによる制御 | 値を生成するストラテジーを持つ項目は以下を提供します。
|
16.1.1. SCC ストラテジー
RunAsUser
-
MustRunAs:runAsUserが設定されることを要求します。デフォルトで設定済みのrunAsUserを使用します。設定済みのrunAsUserに対して検証します。 -
MustRunAsRange: 事前に割り当てられた値を使用していない場合に、最小および最大値が定義されることを要求します。デフォルトでは最小値を使用します。許可される範囲全体に対して検証します。 -
MustRunAsNonRoot: Pod がゼロ以外のrunAsUserで送信されること、またはUSERディレクティブをイメージに定義することを要求します。デフォルトは指定されません。 -
RunAsAny: デフォルトは指定されません。runAsUserの指定を許可します。
SELinuxContext
-
MustRunAs: 事前に割り当てられた値を使用していない場合にseLinuxOptionsが設定されることを要求します。デフォルトとしてseLinuxOptionsを使用します。seLinuxOptionsに対して検証します。 -
RunAsAny: デフォルトは指定されません。seLinuxOptionsの指定を許可します。
SupplementalGroups
-
MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。すべての範囲に対して検証します。 -
RunAsAny: デフォルトは指定されません。supplementalGroupsの指定を許可します。
FSGroup
-
MustRunAs: 事前に割り当てられた値を使用していない場合に、少なくとも 1 つの範囲が指定されることを要求します。デフォルトとして最初の範囲の最小値を使用します。最初の範囲の最初の ID に対して検証します。 -
RunAsAny: デフォルトは指定されません。fsGroupID の指定を許可します。
16.1.2. ボリュームの制御
特定のボリュームタイプの使用は、SCC の volumes フィールドを設定して制御できます。このフィールドの許容値は、ボリュームの作成時に定義されるボリュームソースに対応します。
-
azureFile -
azureDisk -
flocker -
flexVolume -
hostPath -
emptyDir -
gcePersistentDisk -
awsElasticBlockStore -
gitRepo -
secret -
nfs -
iscsi -
glusterfs -
persistentVolumeClaim -
rbd -
cinder -
cephFS -
downwardAPI -
fc -
configMap -
vsphereVolume -
quobyte -
photonPersistentDisk -
projected -
portworxVolume -
scaleIO -
storageos - * (すべてのボリュームタイプの使用を許可する特殊な値)
-
none(すべてのボリュームタイプの使用を無効にする特殊な値。後方互換の場合にのみ存在します)
新規 SCC について許可されるボリュームの推奨される最小セットは、configMap、 downwardAPI、 emptyDir、 persistentVolumeClaim, secret、および projected です。
許可されるボリュームタイプの一覧は、新規タイプが OpenShift Container Platform の各リリースと共に追加されるため、網羅的な一覧である必要はありません。
後方互換性を確保するため、allowHostDirVolumePlugin の使用は volumes フィールドの設定をオーバーライドします。たとえば、allowHostDirVolumePlugin が false に設定されるが、volumes フィールドで許可される場合、hostPath 値は volumes から削除されます。
16.1.3. 受付 (Admission)
SCC が設定された 受付制御 により、ユーザーに付与された機能に基づいてリソースの作成に対する制御が可能になります。
SCC の観点では、これは受付コントローラーが、SCC の適切なセットを取得するためにコンテキストで利用可能なユーザー情報を検査できることを意味します。これにより、Pod はその運用環境についての要求を行ったり、Pod に適用する一連の制約を生成したりする権限が与えられます
受付が Pod を許可するために使用する SCC のセットはユーザーアイデンティティーおよびユーザーが属するグループによって決定されます。さらに、Pod がサービスアカウントを指定する場合、許可される SCC のセットには、サービスアカウントでアクセスできる制約が含まれます。
受付は以下の方法を使用して、Pod の最終的なセキュリティーコンテキストを作成します。
- 使用できるすべての SCC を取得します。
- 要求に指定されていないセキュリティーコンテキストの設定のフィールド値を生成します。
- 利用可能な制約に対する最終的な設定を検証します。
制約の一致するセットが検出される場合、Pod が受け入れられます。要求が SCC に一致しない場合、Pod は拒否されます。
Pod はすべてのフィールドを SCC に対して検証する必要があります。以下は、検証する必要のある 2 つのフィールドのみについての例になります。
これらの例は、事前に割り当てられる値を使用するストラテジーに関連するものです。
MustRunAs の FSGroup SCC ストラテジー
Pod が fsGroup ID を定義する場合、その ID はデフォルトの fsGroup ID に等しくなければなりません。そうでない場合は、Pod は SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.fsGroup フィールドに値 RunAsAny があり、Pod 仕様が Pod.spec.securityContext.fsGroup を省略する場合、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
MustRunAs の SupplementalGroups SCC ストラテジー
Pod 仕様が 1 つ以上の supplementalGroups ID を定義する場合、Pod の ID は namespace の openshift.io/sa.scc.supplemental-groups アノテーションの ID のいずれかに等しくなければなりません。そうでない場合は、Pod は SCC で検証されず、次の SCC が評価されます。
SecurityContextConstraints.supplementalGroups フィールドに値 RunAsAny があり、Pod 仕様が Pod.spec.securityContext.supplementalGroups を省略する場合、このフィールドは有効とみなされます。検証時に、他の SCC 設定が他の Pod フィールドを拒否し、そのため Pod を失敗させる可能性があることに注意してください。
16.1.4. SCC の優先度設定
SCC には、受付コントローラーによる要求の検証を試行する際の順序に影響を与える優先度フィールドがあります。優先度の高い SCC は並び替える際にセットの先頭に移動します。利用可能な SCC の完全なセットが判別されると、それらは以下に戻づいて順序付けられます。
- 優先度が高い順。 nil は優先度 0 とみなされます。
- 優先度が等しい場合、SCC は最も制限の多いものから少ないものの順に並べ替えられます。
- 優先度と制限のどちらも等しい場合、SCC は名前順に並べ替えられます。
デフォルトで、クラスター管理者に付与される anyuid SCC には SCC セットの優先度が指定されます。これにより、クラスター管理者は Pod の SecurityContext で RunAsUser を指定しなくても Pod を任意のユーザーとして実行できます。管理者は、希望する場合は依然として RunAsUser を指定できます。
