MENU
  1. ホーム
  2. 環境構築・運用
  3. OpenShift構築
  4. OpenShift の SCCが難しいので整理する

OpenShift の SCCが難しいので整理する

OpenShift構築

OpenShift では、Pod やコンテナのセキュリティ設定を管理するために、Security Context Constraints（SCC） を使用します。SCC は、OpenShift 特有のリソースです。
SCCを使用すると、コンテナがどのような権限やリソースにアクセスできるかを制限できます。例えば、特権コンテナの実行制限、UID/GIDの設定、ネットワークアクセス制限などを行うことができます。
OpenShiftでは、既存のSCCを利用したり、カスタムSCCを作成して、特定の要件に応じたセキュリティ制御を行うことができます。

私はSCCに謎の苦手意識がありまして、勉強してもしっくりきていなかったのでこれを機に実際に設定をしてみて、身に着けたいと思います！

目次

1. OpenShiftのSCCとは？

OpenShiftのSCCとは？

SCC（Security Context Constraints）は、OpenShiftにおけるセキュリティ設定の仕組みです。OpenShiftでは、セキュリティを強化するために、デフォルトでrootユーザーでのPod実行を禁止しています。これにより、悪意のある攻撃がシステム全体に影響を与えるリスクを減らします。

ただし、特定の状況ではrootユーザーで実行する必要がある場合もあります。そこで、SCCを使うことで、必要なPodだけに特権を付与し、セキュリティを確保しながら柔軟な設定を行うことができます。

2. カスタムSCCと既存SCCを利用する違い

2.1. 既存のSCCを利用する

OpenShift にはあらかじめいくつかの組み込みSCCが提供されています。

SCC 名説明用途特典
restricted制限の多いSCCで、通常のユーザー向けに適用されます。特権モードでの実行が許可されず、UIDやGIDも制限されます。通常ユーザーのアプリケーション、一般的なPod特権モードを無効にし、セキュアなUID/GID制限
privileged高い権限を持つSCCで、特権コンテナの実行を許可します。クラスタ管理者や特別な用途で必要なPod特権コンテナを許可、全てのセキュリティ制限が解除される
defaultデフォルトのSCCで、特に制限はありませんが、必要最低限の制限を加えています。通常のPodでの利用、特定の制限が必要ない場合一般的な使用に適している
anyuidPodが任意のUIDで実行されることを許可します。通常はユーザーIDの制限が必要な場合に使用されます。特定のUID制限なしでPodを実行したい場合任意のUIDでコンテナを実行可能
hostaccessPodがホストネットワークやホストのリソースにアクセスすることを許可します。ノード間通信を行うPod、またはホストリソースにアクセスする必要があるアプリホストリソースへのアクセス、ホストネットワーク利用可能
nobody特権が最小限の制限付きでPodを実行できるSCCです。限られたリソースアクセスが必要なPod高い制限で最小限の権限を提供

既存のSCCを利用する場合、管理者は自分でポリシーを設定する手間が減りますが、あらかじめ用意された制限や設定に従わなければならないため、カスタマイズ性が制限されることがあります。

2.2. カスタムSCCの作成

カスタムSCCを作成する場合、特定のセキュリティ要件に応じて、既存のSCCを拡張したり、まったく新しいSCCを作成することができます。これにより、より柔軟にセキュリティ制御を行えます。

カスタムSCCを作成するYAML例：

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: custom-scc
allowPrivilegedContainer: false  # 特権コンテナの実行を無効
runAsUser:
  type: MustRunAsRange  # UIDの範囲を制限
  ranges:
    - min: 1000
      max: 2000

この例では、特定のServiceAccountに対してカスタムSCCを適用し、特権コンテナの実行を無効にし、UID範囲を制限しています。

3. ServiceAccount（SA）にバインディングする場合

ServiceAccount（SA）は、Kubernetes や OpenShift のアプリケーションがクラスタ内で操作を行うために使用されるユーザーアカウントの一種です。SCCは、特定のServiceAccountにバインドして適用することができます。

例えば、my-saというServiceAccountに対して、custom-sccをバインドするには、以下のコマンドを使用します。

$ oc adm policy add-scc-to-user custom-scc -z <my-sa> -n <my-namespace>

これにより、my-saが属するPodにはcustom-sccが適用され、Podは指定されたセキュリティコンテキストで実行されます。
このコマンド実行により作成されるリソースは対象が SA で project 内のリソースなので、RoleBindingです。

SAバインディングのメリット：

  • アクセス制御：各アプリケーションが使用するServiceAccountに適切な権限を与えることができます。
  • 粒度の高いセキュリティ設定：サービスアカウントごとに異なるSCCを適用することで、アプリケーションごとに
    　　　　　　　　　　　　　　異なるセキュリティポリシーを適用できます。

4. グループにバインディングする場合

ServiceAccountの代わりに、ユーザーグループに対してSCCをバインディングすることもできます。グループバインディングを使うと、特定のグループに所属する全てのユーザーにSCCが適用されます。

例えば、developersというグループにcustom-sccを適用する場合、以下のコマンドを使用します。

$ oc adm policy add-scc-to-user custom-scc -z my-sa -n my-namespace

このコマンド実行により作成されるリソースは対象が group でクラスターワイドなリソースなので、ClusterRoleBindingです。

グループバインディングのメリット：

  • 広範な適用：複数のユーザーに対して一度にセキュリティ設定を適用できます。
  • 管理の簡便さ：個別にServiceAccountを設定するよりも、グループ単位でポリシーを管理できるため、管理が楽になります。

5. use 権限の必要有無

SCCを適用する際、use権限が必要かどうかは、バインディングする対象によって異なります。

  • ServiceAccount にSCCをバインドする場合、use権限は必要ありません。ServiceAccountは、その project 内でPodを実行する権限を持っているため、追加で権限を与える必要はありません。
  • ユーザーグループ にSCCをバインドする場合、use権限が必要になることがあります。use権限は、そのグループのユーザーがSCCを利用できるようにするために必要です。

通常、cluster-admin権限を持つユーザーがSCCを作成・管理しますが、use権限を持っていなくても、アプリケーションごとに適切な権限が付与されたServiceAccountを利用すれば、cluster-admin権限がなくてもSCCを設定することができます。

6. cluster-admin権限なしでのSCC設定方法

通常、SCCを作成・管理するにはcluster-admin権限が必要ですが、ServiceAccountやグループへの適用を通じて、通常のユーザーでもSCCを設定することができます。例えば、custom-sccを作成した後、グループやServiceAccountへのバインディングにより、特権のないユーザーでもアプリケーションに必要なセキュリティ設定を適用できます。

実例：

  • my-saというServiceAccountに対して、custom-sccを適用： 
$ oc adm policy add-scc-to-user custom-scc -z my-sa -n my-namespace

これにより、cluster-admin権限を持たないユーザーでも、自分が管理するアプリケーションにSCCを設定できるようになります。

7. まとめ

なんとな～～～くでも、わかった気になれましたか？
実際に設定して慣れていきたいですね！最後までご視聴ありがとうございました(^^♪

OpenShift構築
ClusterRoleBinding OpenShift RedHatOpenShift RoleBinding SA SCC セキュリティ
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

コメント

コメントする

CAPTCHA


目次