2.14. Linux ユーザー名前空間での Pod の実行


Linux ユーザー名前空間を使用すると、管理者はコンテナーのユーザーおよびグループ識別子 (UID および GID) を分離できるため、実行されているホストシステムとは異なる権限セットを、ユーザー名前空間でコンテナーに付与できます。これにより、ユーザー名前空間内で完全な権限を使用してプロセスを実行することをコンテナーに許可する一方で、ホストマシンに対する操作の権限をプロセスに与えないことが可能になります。

デフォルトでは、コンテナーはホストシステムの root ユーザー名前空間で実行されます。コンテナーをホストのユーザー名前空間で実行することは、そのユーザー名前空間でのみ使用可能な機能がコンテナーに必要な場合に便利です。しかし、コンテナーブレイクアウトの問題など、セキュリティー上の懸念が生じます。コンテナーブレイクアウトが発生すると、コンテナー内のプロセスがホストに脱出し、プロセスがホストや他のコンテナー上のファイルにアクセスしたり、ファイルを変更したりできるようになります。

個々のユーザー名前空間でコンテナーを実行すると、コンテナーブレイクアウトや、侵害されたコンテナーから他の Pod やノード自体に及ぶ可能性のあるその他のいくつかの脆弱性を軽減できます。

次の手順に示すように、Pod 仕様で hostUsers パラメーターを false に設定することにより、Linux ユーザー名前空間の使用を設定できます。

重要

Linux ユーザー名前空間のサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

2.14.1. Linux ユーザー名前空間のサポートの設定

前提条件

  • cluster という名前の FeatureGate CR を編集して、クラスターに必要なテクノロジープレビュー機能を有効にした。

    $ oc edit featuregate cluster

    FeatureGate CR の例

    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      name: cluster
    spec:
      featureSet: TechPreviewNoUpgrade 1

    1
    必要な UserNamespacesSupport および ProcMountType 機能を有効にします。
    警告

    クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、元に戻すことができず、マイナーバージョンの更新が妨げられます。この機能セットを使用すると、該当するテクノロジープレビュー機能をテストクラスターで有効にして、完全にテストすることができます。実稼働クラスターではこの機能セットを有効にしないでください。

    変更を保存すると、新規マシン設定が作成され、マシン設定プールが更新され、変更が適用されている間に各ノードのスケジューリングが無効になります。

  • ワーカーノードで crun コンテナーランタイムを有効にした。現在、crun はユーザー名前空間をサポートする唯一のリリース済み OCI ランタイムです。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: ContainerRuntimeConfig
    metadata:
     name: enable-crun-worker
    spec:
     machineConfigPoolSelector:
       matchLabels:
         pools.operator.machineconfiguration.openshift.io/worker: "" 1
     containerRuntimeConfig:
       defaultRuntime: crun 2
    1
    マシン設定プールのラベルを指定します。
    2
    デプロイするコンテナーランタイムを指定します。

手順

  1. 次のコマンドを実行して、Pod がデプロイされている OpenShift Container Platform の namespace のデフォルトユーザー ID (UID) およびグループ ID (GID) の範囲を編集します。

    $ oc edit ns/<namespace_name>

    namespace の例

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/description: ""
        openshift.io/display-name: ""
        openshift.io/requester: system:admin
        openshift.io/sa.scc.mcs: s0:c27,c24
        openshift.io/sa.scc.supplemental-groups: 1000/10000 1
        openshift.io/sa.scc.uid-range: 1000/10000 2
    # ...
    name: userns
    # ...

    1
    Pod 仕様で指定した値と一致するようにデフォルトの GID を編集します。Linux ユーザー名前空間の範囲は 65,535 未満である必要があります。デフォルトは 1000000000/10000 です。
    2
    Pod 仕様で指定した値と一致するようにデフォルトの UID を編集します。Linux ユーザー名前空間の範囲は 65,535 未満である必要があります。デフォルトは 1000000000/10000 です。
    注記

    範囲 1000/10000 は、ID 1000 から始まる 10,000 個の値を意味するため、1000 から 10,999 までの範囲の ID を指定します。

  2. restricted プロファイルで動作するように設定した Pod を作成し、hostUsers パラメーターを false に設定することで、Linux ユーザー名前空間の使用を有効にします。

    1. 以下のような YAML ファイルを作成します。

      Pod 仕様の例

      apiVersion: v1
      kind: Pod
      metadata:
        name: userns-pod
      
      # ...
      
      spec:
        containers:
        - name: userns-container
          image: registry.access.redhat.com/ubi9
          command: ["sleep", "1000"]
          securityContext:
            capabilities:
              drop: ["ALL"]
            allowPrivilegeEscalation: false 1
            runAsNonRoot: true 2
            seccompProfile:
              type: RuntimeDefault
            runAsUser: 1000 3
            runAsGroup: 1000 4
        hostUsers: false 5
      
      # ...

      1
      Pod が権限昇格を要求できないことを指定します。これは restricted-v2 Security Context Constraints (SCC) に必要です。
      2
      UID が 0 以外のユーザーでコンテナーが実行されるように指定します。
      3
      コンテナーの実行に使用する UID を指定します。
      4
      コンテナーの実行に使用するプライマリー GID を指定します。
      5
      Pod をユーザー名前空間で実行するように要求します。true の場合、Pod はホストのユーザー名前空間で実行されます。false の場合、Pod は Pod 用に作成した新しいユーザー名前空間で実行されます。デフォルトは true です。
    2. 以下のコマンドを実行して Pod を作成します。

      $ oc create -f <file_name>.yaml

検証

  1. 作成した Pod コンテナーで使用されている Pod ユーザー ID とグループ ID を確認します。Pod は Linux ユーザー名前空間内にあります。

    1. Pod 内のコンテナーでシェルセッションを開始します。

      $ oc rsh -c <container_name> pod/<pod_name>

      コマンドの例

      $ oc rsh -c userns-container_name pod/userns-pod

    2. コンテナー内で使用されているユーザー ID とグループ ID を表示します。

      sh-5.1$ id

      出力例

      uid=1000(1000) gid=1000(1000) groups=1000(1000)

    3. コンテナーのユーザー名前空間で使用されているユーザー ID を表示します。

      sh-5.1$ lsns -t user

      出力例

              NS TYPE  NPROCS PID USER COMMAND
      4026532447 user       3   1 1000 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000 1

      1
      プロセスの UID は 1000 です。これは Pod 仕様で設定したものと同じです。
  2. Pod が作成されたノードで使用されている Pod ユーザー ID を確認します。ノードは Linux ユーザー名前空間の外部にあります。このユーザー ID がコンテナーで使用されている UID と異なっている必要があります。

    1. そのノードのデバッグセッションを開始します。

      $ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9

      コマンドの例

      $ oc debug node/ci-ln-z5vppzb-72292-8zp2b-worker-c-q8sh9

    2. /host をデバッグシェル内のルートディレクトリーとして設定します。

      sh-5.1# chroot /host
    3. ノードのユーザー名前空間で使用されているユーザー ID を表示します。

      sh-5.1#  lsns -t user

      コマンドの例

              NS TYPE  NPROCS   PID USER       COMMAND
      4026531837 user     233     1 root       /usr/lib/systemd/systemd --switched-root --system --deserialize 28
      4026532447 user       1  4767 2908816384 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000 1

      1
      プロセスの UID は 2908816384 です。これは Pod 仕様で設定したものと異なります。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.