サポートコンソール開発者トライアルの開始お問い合わせ

7.9. コンテナーでの sysctl の使用

Sysctl の設定は Kubernetes を通じて公開され、ユーザーは実行時に特定のカーネルパラメーターを変更することができます。namespace を使用する sysctl のみを Pod 上で独立して設定できます。sysctl に namespace がない場合 (ノードレベルと呼ばれる)、Node Tuning Operator をしようなどなど、sysctl を設定する別の方法を使用する必要があります。

ネットワーク sysctl は特殊な sysctl カテゴリーです。ネットワーク sysctl には、以下が含まれます。

  • すべてのネットワークで有効な、net.ipv4.ip_local_port_range ようなシステム全体の sysctl。これらは、ノード上の各 Pod に対して個別に設定できます。
  • 特定の Pod の特定の追加ネットワークインターフェイスにのみ適用されるインターフェイス固有の sysctl (net.ipv4.conf.IFNAME.accept_local など)。これらは、追加のネットワーク設定ごとに個別に設定できます。ネットワークインターフェイスの作成後に tuning-cni で設定を使用して、これらを設定します。

さらに 安全 とみなされる sysctl のみがデフォルトでホワイトリストに入れられます。 他の 安全でない sysctl はノードで手動で有効にし、ユーザーが使用できるようにできます。

sysctl を設定しており、ノードレベルではない場合、この手順に関する情報は Node Tuning Operator の使用 セクションを参照してください。

7.9.1. sysctl について

Linux では、管理者は sysctl インターフェイスを使用してランタイム時にカーネルパラメーターを変更することができます。パラメーターは /proc/sys/ 仮想プロセスファイルシステムから利用できます。これらのパラメーターは以下を含む各種のサブシステムを対象とします。

  • カーネル (共通の接頭辞: kernel.)
  • ネットワーク (共通の接頭辞: net.)
  • 仮想メモリー (共通の接頭辞: vm.)
  • MDADM (共通の接頭辞: dev.)

追加のサブシステムについては、カーネルのドキュメント で説明されています。すべてのパラメーターの一覧を表示するには、以下のコマンドを実行します。 

$ sudo sysctl -a

7.9.2. namespace とノードレベルの sysctls

Linux カーネルでは、数多くの sysctl に namespace が使用されています。これは、それらをノードの各 Pod に対して個別に設定できることを意味します。namespace の使用は、sysctl を Kubernetes 内の Pod 環境でアクセス可能にするための要件になります。

以下の sysctl は namespace を使用するものとして知られている sysctl です。

  • kernel.shm*
  • kernel.msg*
  • kernel.sem
  • fs.mqueue.*

また、net.* グループの大半の sysctl には namespace が使用されていることが知られています。それらの namespace の使用は、カーネルのバージョンおよびディストリビューターによって異なります。

namespace が使用されていない sysctl は ノードレベル と呼ばれており、クラスター管理者がノードの基礎となる Linux ディストリビューションを使用 (例: /etc/sysctls.conf ファイルを変更) するか、特権付きコンテナーでデーモンセットを使用することによって手動で設定する必要があります。Node Tuning Operator を使用して node-level を設定できます。

注記

特殊な sysctl が設定されたノードに taint のマークを付けることを検討してください。それらの sysctl 設定を必要とするノードにのみ Pod をスケジュールします。taint および toleration 機能を使用してノードにマークを付けます。

7.9.3. 安全および安全でない sysctl

sysctl は 安全な および 安全でない sysctl に分類されます。

システム全体の sysctl を安全に考慮するには、namespace を指定する必要があります。namespace を使用した sysctl は namespace と Pod 間で分離されるようにします。1 つの Pod に sysctl を設定する場合は、以下のいずれかを追加することはできません。

  • この設定はノードのその他の Pod に影響を与えないものである。
  • ノードの正常性に切り離す。
  • この設定は Pod のリソース制限を超える CPU またはメモリーリソースの取得を許可しないものである。
注記

namespace を使用するだけでは、sysctl を安全に考慮するには不十分です。

OpenShift Container Platform で許可リストに追加されていない sysctl は、OpenShift Container Platform では安全でないと見なされます。

安全でない sysctl はデフォルトでは許可されません。システム全体の sysctl の場合、クラスター管理者はノードごとに手動で有効にする必要があります。無効にされた安全でない sysctl が設定された Pod はスケジュールされますが、起動されません。

注記

インターフェイス固有の安全でない sysctls を手動で有効にすることはできません。

OpenShift Container Platform は以下のシステム全体およびインターフェイス固有の安全な sysctl を許可された安全なリストに追加します。

表7.4 システム全体の安全な sysctl
sysctl説明

kernel.shm_rmid_forced

1 に設定すると、現在の IPC namespace のすべての共有メモリーオブジェクトは自動的に IPC_RMID を使用します。詳細は、shm_rmid_forced を参照してください。

net.ipv4.ip_local_port_range

TCP および UDP によって使用されるローカルポート範囲を定義して、ローカルポートを選択します。最初の番号は最初のポート番号で、2 番目の番号は最後のローカルポート番号になります。可能であれば、これらの数値は異なるパリティー (偶数値と奇数値) を持つ方が良い。ip_unprivileged_port_start よりも大きくなければなりません。デフォルト値は、それぞれ 32768 および 60999 です。詳細は、ip_local_port_range を参照してください。

net.ipv4.tcp_syncookies

net.ipv4.tcp_syncookies を設定すると、カーネルは、通常、半分に開いた接続キューが満杯になるまで TCP SYN パケットを処理します。この時点で、SYN クッキー機能が開始します。この機能により、サービス拒否攻撃下であっても、システムは有効な接続を受け入れることができます。詳細は、tcp_syncookies を参照してください。

net.ipv4.ping_group_range

これにより、ICMP_PROTO データグラムソケットがグループ範囲内のユーザーに制限されます。デフォルトは 1 0 で、nobody は root であっても ping ソケットを作成できます。詳細は、ping_group_range を参照してください。

net.ipv4.ip_unprivileged_port_start

これは、ネットワーク namespace 内の最初の権限のないポートを定義します。特権ポートをすべて無効にするには、これを 0 に設定します。特権ポートは ip_local_port_range と重複できません。詳細は、ip_unprivileged_port_start を参照してください。

net.ipv4.ip_local_reserved_ports

アプリケーションまたはサービス用に予約するローカルポートの範囲をコンマ区切りで指定します。

net.ipv4.tcp_keepalive_time

接続がアイドル状態になった後に最初の keepalive プローブを送信するまでの間隔を秒単位で指定します。

net.ipv4.tcp_fin_timeout

接続が中止されるまでに FIN-WAIT-2 状態のままになる時間を秒単位で指定します。

net.ipv4.tcp_keepalive_intvl

keepalive プローブ間の間隔を秒単位で指定します。この値に tcp_keepalive_probes 値を掛けて、接続が切断されたと判断されるまでに必要な合計時間を決定します。

net.ipv4.tcp_keepalive_probes

接続が切断されたと判断されるまで送信する keepalive プローブの数を指定します。

表7.5 インターフェイス固有の安全な sysctl
sysctl説明

net.ipv4.conf.IFNAME.accept_redirects

IPv4 ICMP リダイレクトメッセージを受信します。

net.ipv4.conf.IFNAME.accept_source_route

SRR (Strict Source Route) オプションの付いた IPv4 パケットを受け入れる。

net.ipv4.conf.IFNAME.arp_accept

ARP テーブルにない IPv4 アドレスで余計な ARP フレームの動作を定義します。

  • 0: ARP テーブルに新しいエントリーを作成しません。
  • 1: ARP テーブルに新しいエントリーを作成します。

net.ipv4.conf.IFNAME.arp_notify

IPv4 アドレスとデバイスの変更を通知するモードを定義します。

net.ipv4.conf.IFNAME.disable_policy

この IPv4 インターフェイスの IPSEC ポリシー (SPD) を無効にします。

net.ipv4.conf.IFNAME.secure_redirects

インターフェイスの現在のゲートウェイリストにリストされているゲートウェイに対する ICMP リダイレクトメッセージのみを受信します。

net.ipv4.conf.IFNAME.send_redirects

送信リダイレクトは、ノードがルーターとして動作する場合にのみ有効になります。つまり、ホストは ICMP リダイレクトメッセージを送信しないでください。これは、特定の宛先で利用可能なルーティングパスの改善についてホストに通知するためにルーターによって使用されます。

net.ipv6.conf.IFNAME.accept_ra

IPv6 ルーター広告を受け入れ、それらを使用して自動設定します。また、ルーター要請の送信の可否を判断します。ルーターへの通知は、機能の設定がルーター広告を受け入れる場合にのみ送信されます。

net.ipv6.conf.IFNAME.accept_redirects

IPv6 ICMP リダイレクトメッセージを受信します。

net.ipv6.conf.IFNAME.accept_source_route

SRR オプションで IPv6 パケットを受信します。

net.ipv6.conf.IFNAME.arp_accept

ARP テーブルに存在しない IPv6 アドレスで余計な ARP フレームの動作を定義します。

  • 0: ARP テーブルに新しいエントリーを作成しません。
  • 1: ARP テーブルに新しいエントリーを作成します。

net.ipv6.conf.IFNAME.arp_notify

IPv6 アドレスとデバイスの変更を通知するモードを定義します。

net.ipv6.neigh.IFNAME.base_reachable_time_ms

このパラメーターは、IPv6 の neighbour テーブルで、IP マッピングの有効期間に対するハードウェアアドレスを制御します。

net.ipv6.neigh.IFNAME.retrans_time_ms

隣接する検出メッセージの再送信タイマーを設定します。

注記

tuning CNI プラグインを使用してこれらの値を設定する場合は、値 IFNAME をそのまま使用します。インターフェイス名は IFNAME トークンによって表され、ランタイム時にインターフェイスの実際の名前に置き換えられます。

7.9.4. インターフェイス固有の安全な sysctls リストの更新

OpenShift Container Platform には、安全なインターフェイス固有の sysctl の定義済みリストが含まれています。このリストを変更するには、openshift-multus namespace で cni-sysctl-allowlist を更新します。

重要

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

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

この手順に従って、安全な sysctl の定義済みリストを変更します。この手順では、デフォルトの許可リストを拡張する方法を説明します。

手順

  1. 次のコマンドを実行して、既存の定義済みリストを表示します。 

    $ oc get cm -n openshift-multus cni-sysctl-allowlist -oyaml

    予想される出力

    apiVersion: v1
data:
  allowlist.conf: |-
    ^net.ipv4.conf.IFNAME.accept_redirects$
    ^net.ipv4.conf.IFNAME.accept_source_route$
    ^net.ipv4.conf.IFNAME.arp_accept$
    ^net.ipv4.conf.IFNAME.arp_notify$
    ^net.ipv4.conf.IFNAME.disable_policy$
    ^net.ipv4.conf.IFNAME.secure_redirects$
    ^net.ipv4.conf.IFNAME.send_redirects$
    ^net.ipv6.conf.IFNAME.accept_ra$
    ^net.ipv6.conf.IFNAME.accept_redirects$
    ^net.ipv6.conf.IFNAME.accept_source_route$
    ^net.ipv6.conf.IFNAME.arp_accept$
    ^net.ipv6.conf.IFNAME.arp_notify$
    ^net.ipv6.neigh.IFNAME.base_reachable_time_ms$
    ^net.ipv6.neigh.IFNAME.retrans_time_ms$
kind: ConfigMap
metadata:
  annotations:
    kubernetes.io/description: |
      Sysctl allowlist for nodes.
    release.openshift.io/version: 4.16.0-0.nightly-2022-11-16-003434
  creationTimestamp: "2022-11-17T14:09:27Z"
  name: cni-sysctl-allowlist
  namespace: openshift-multus
  resourceVersion: "2422"
  uid: 96d138a3-160e-4943-90ff-6108fa7c50c3

  2. 次のコマンドを使用してリストを編集します。 

    $ oc edit cm -n openshift-multus cni-sysctl-allowlist -oyaml

    たとえば、より厳密なリバースパス転送を実装できるようにするには、次のように ^net.ipv4.conf.IFNAME.rp_filter$ と ^net.ipv6.conf.IFNAME.rp_filter$ をリストに追加する必要があります。 

    # Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  allowlist.conf: |-
    ^net.ipv4.conf.IFNAME.accept_redirects$
    ^net.ipv4.conf.IFNAME.accept_source_route$
    ^net.ipv4.conf.IFNAME.arp_accept$
    ^net.ipv4.conf.IFNAME.arp_notify$
    ^net.ipv4.conf.IFNAME.disable_policy$
    ^net.ipv4.conf.IFNAME.secure_redirects$
    ^net.ipv4.conf.IFNAME.send_redirects$
    ^net.ipv4.conf.IFNAME.rp_filter$
    ^net.ipv6.conf.IFNAME.accept_ra$
    ^net.ipv6.conf.IFNAME.accept_redirects$
    ^net.ipv6.conf.IFNAME.accept_source_route$
    ^net.ipv6.conf.IFNAME.arp_accept$
    ^net.ipv6.conf.IFNAME.arp_notify$
    ^net.ipv6.neigh.IFNAME.base_reachable_time_ms$
    ^net.ipv6.neigh.IFNAME.retrans_time_ms$
    ^net.ipv6.conf.IFNAME.rp_filter$

  3. 変更をファイルに保存して終了します。

    注記

    sysctl の削除もサポートされています。ファイルを編集し、sysctl または sysctls を削除してから、変更を保存して終了します。

検証

IPv4 のより厳密なリバースパス転送を強制するには、次の手順に従います。リバースパスフォワーディングの詳細は、リバースパスフォワーディング を参照してください。

  1. 次の内容で、reverse-path-fwd-example.yaml などのネットワーク接続定義を作成します。 

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: tuningnad
  namespace: default
spec:
  config: '{
    "cniVersion": "0.4.0",
    "name": "tuningnad",
    "plugins": [{
      "type": "bridge"
      },
      {
      "type": "tuning",
      "sysctl": {
         "net.ipv4.conf.IFNAME.rp_filter": "1"
        }
    }
  ]
}'

  2. 以下のコマンドを実行して yaml を適用します。 

    $ oc apply -f reverse-path-fwd-example.yaml

    出力例

    networkattachmentdefinition.k8.cni.cncf.io/tuningnad created

  3. 次の YAML を使用して、examplepod.yaml などの Pod を作成します。 

    apiVersion: v1
kind: Pod
metadata:
  name: example
  labels:
    app: httpd
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/networks: tuningnad  1
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: httpd
      image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest'
      ports:
        - containerPort: 8080
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    1
    設定済みの NetworkAttachmentDefinition の名前を指定します。

  4. 以下のコマンドを実行して yaml を適用します。 

    $ oc apply -f examplepod.yaml

  5. 次のコマンドを実行して、Pod が作成されていることを確認します。 

    $ oc get pod

    出力例

    NAME      READY   STATUS    RESTARTS   AGE
example   1/1     Running   0          47s

  6. 次のコマンドを実行して、Pod にログインします。 

    $ oc rsh example

  7. 設定された sysctl フラグの値を確認します。たとえば、次のコマンドを実行して値 net.ipv4.conf.net1.rp_filter を見つけます。 

    sh-4.4# sysctl net.ipv4.conf.net1.rp_filter

    予想される出力

    net.ipv4.conf.net1.rp_filter = 1

関連情報

7.9.5. 安全な sysctl での Pod の起動

Pod の securityContext を使用して sysctl を Pod に設定できます。securityContext は同じ Pod 内のすべてのコンテナーに適用されます。

安全な sysctl はデフォルトで許可されます。

この例では、Pod securityContext を使用して以下の安全な sysctl を設定します。

  • kernel.shm_rmid_forced
  • net.ipv4.ip_local_port_range
  • net.ipv4.tcp_syncookies
  • net.ipv4.ping_group_range
警告

オペレーティングシステムが不安定になるのを防ぐには、変更の影響を確認している場合にのみ sysctl パラメーターを変更します。

以下の手順を使用して、設定される sysctl 設定で Pod を起動します。

注記

ほとんどの場合、既存の Pod 定義を変更し、securityContext 仕様を追加します。

手順

  1. 以下の例のように、サンプル Pod を定義し、securityContext 仕様を追加する YAML ファイルの sysctl_pod.yaml を作成します。 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
  namespace: default
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000 1
      runAsGroup: 3000 2
      allowPrivilegeEscalation: false 3
      capabilities: 4
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true 5
    seccompProfile: 6
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "1"
    - name: net.ipv4.ip_local_port_range
      value: "32770       60666"
    - name: net.ipv4.tcp_syncookies
      value: "0"
    - name: net.ipv4.ping_group_range
      value: "0           200000000"
    1
    runAsUser は、コンテナーが実行されるユーザー ID を制御します。
    2
    runAsGroup は、コンテナーが実行されるプライマリーグループ ID を制御します。
    3
    allowPrivilegeEscalation は、Pod が特権の昇格を許可するように要求できるかどうかを決定します。指定しない場合、デフォルトで true に設定されます。このブール値は、no_new_privs フラグがコンテナープロセスに設定されるかどうかを直接制御します。
    4
    capabilities は、完全なルートアクセスを許可せずに権限操作を許可します。このポリシーにより、すべての機能が Pod から削除されます。
    5
    runAsNonRoot: true は、コンテナーが 0 以外の任意の UID を持つユーザーで実行されることを要求します。
    6
    RuntimeDefault は、Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを有効にします。

  2. 以下のコマンドを実行して Pod を作成します。 

    $ oc apply -f sysctl_pod.yaml

  3. 次のコマンドを実行して、Pod が作成されていることを確認します。 

    $ oc get pod

    出力例

    NAME              READY   STATUS            RESTARTS   AGE
sysctl-example    1/1     Running           0          14s

  4. 次のコマンドを実行して、Pod にログインします。 

    $ oc rsh sysctl-example

  5. 設定された sysctl フラグの値を確認します。たとえば、以下のコマンドを実行して kernel.shm_rmid_forced の値を見つけます。 

    sh-4.4# sysctl kernel.shm_rmid_forced

    予想される出力

    kernel.shm_rmid_forced = 1

7.9.6. 安全でない sysctl での Pod の起動

安全でない sysctl が設定された Pod は、クラスター管理者がそのノードの安全でない sysctl を明示的に有効にしない限り、いずれのノードでも起動に失敗します。ノードレベルの sysctl の場合のように、それらの Pod を正しいノードにスケジュールするには、taint および toleration、またはノードのラベルを使用します。

以下の例では Pod の securityContext を使用して安全な sysctl kernel.shm_rmid_forced および 2 つの安全でない sysctl net.core.somaxconn および kernel.msgmax を設定します。仕様では 安全な sysctl と 安全でない sysctl は区別されません。

警告

オペレーティングシステムが不安定になるのを防ぐには、変更の影響を確認している場合にのみ sysctl パラメーターを変更します。

以下の例は、安全な sysctl を Pod 仕様に追加する際に発生する内容を示しています。

手順

  1. 以下の例のように、サンプル Pod を定義し、securityContext 仕様を追加する YAML ファイル sysctl-example-unsafe.yaml を作成します。 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example-unsafe
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.core.somaxconn
      value: "1024"
    - name: kernel.msgmax
      value: "65536"

  2. 以下のコマンドを使用して Pod を作成します。 

    $ oc apply -f sysctl-example-unsafe.yaml

  3. 以下のコマンドを使用して安全でない sysctl がノードに許可されないため、Pod がスケジュールされているがデプロイされないことを確認します。 

    $ oc get pod

    出力例

    NAME                       READY             STATUS            RESTARTS   AGE
sysctl-example-unsafe      0/1               SysctlForbidden   0          14s

7.9.7. 安全でない sysctl の有効化

クラスター管理者は、高パフォーマンスまたはリアルタイムのアプリケーション調整などの非常に特殊な状況で特定の安全でない sysctl を許可することができます。

安全でない sysctl を使用する必要がある場合、クラスター管理者は特定のタイプのノードに対してそれらを個別に有効にする必要があります。sysctl には namespace を使用する必要があります。

Security Context Constraints の allowedUnsafeSysctls フィールドに sysctl または sysctl パターンのリストを指定することで、どの sysctl を Pod に設定するかをさらに制御できます。

  • allowedUnsafeSysctls オプションは、高パフォーマンスやリアルタイムのアプリケーションチューニングなどの特定ニーズを管理します。
警告

安全でないという性質上、安全でない sysctl は各自の責任で使用されます。 場合によっては、コンテナーの正しくない動作やリソース不足、またはノードの破損などの深刻な問題が生じる可能性があります。

手順

  1. 以下のコマンドを実行して、OpenShift Container Platform クラスターの既存の MachineConfig オブジェクトをリスト表示し、マシン設定にラベルを付ける方法を決定します。 

    $ oc get machineconfigpool

    出力例

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-bfb92f0cd1684e54d8e234ab7423cc96   True      False      False      3              3                   3                     0                      42m
worker   rendered-worker-21b6cb9a0f8919c88caf39db80ac1fce   True      False      False      3              3                   3                     0                      42m

  2. 以下のコマンドを実行して、安全でない sysctl が設定されたコンテナーが実行されるマシン設定プールにラベルを追加します。 

    $ oc label machineconfigpool worker custom-kubelet=sysctl

  3. KubeletConfig カスタムリソース (CR) を定義する YAML ファイル set-sysctl-worker.yaml を作成します。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: custom-kubelet
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: sysctl 1
  kubeletConfig:
    allowedUnsafeSysctls: 2
      - "kernel.msg*"
      - "net.core.somaxconn"
    1
    マシン設定プールからラベルを指定します。
    2
    許可する必要のある安全でない sysctl を一覧表示します。

  4. 以下のコマンドを実行してオブジェクトを作成します。 

    $ oc apply -f set-sysctl-worker.yaml

  5. 以下のコマンドを実行して、Machine Config Operator が新規のレンダリングされた設定を生成し、これをマシンに適用します。 

    $ oc get machineconfigpool worker -w

    数分後、UPDATING のステータスが True から False に変化します。 

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-f1704a00fc6f30d3a7de9a15fd68a800   False     True       False      3              2                   2                     0                      71m
worker   rendered-worker-f1704a00fc6f30d3a7de9a15fd68a800   False     True       False      3              2                   3                     0                      72m
worker   rendered-worker-0188658afe1f3a183ec8c4f14186f4d5   True      False      False      3              3                   3                     0                      72m

  6. 次の例に示すように、サンプルの Pod を定義する YAML ファイル sysctl-example-safe-unsafe.yaml を作成し、securityContext の仕様を追加します。 

    apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example-safe-unsafe
spec:
  containers:
  - name: podexample
    image: centos
    command: ["bin/bash", "-c", "sleep INF"]
    securityContext:
      runAsUser: 2000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.core.somaxconn
      value: "1024"
    - name: kernel.msgmax
      value: "65536"

  7. 以下のコマンドを実行して Pod を作成します。 

    $ oc apply -f sysctl-example-safe-unsafe.yaml

    予想される出力

    Warning: would violate PodSecurity "restricted:latest": forbidden sysctls (net.core.somaxconn, kernel.msgmax)
pod/sysctl-example-safe-unsafe created

  8. 次のコマンドを実行して、Pod が作成されていることを確認します。 

    $ oc get pod

    出力例

    NAME                         READY   STATUS    RESTARTS   AGE
sysctl-example-safe-unsafe   1/1     Running   0          19s

  9. 次のコマンドを実行して、Pod にログインします。 

    $ oc rsh sysctl-example-safe-unsafe

  10. 設定された sysctl フラグの値を確認します。たとえば、以下のコマンドを実行して net.core.somaxconn の値を見つけます。 

    sh-4.4# sysctl net.core.somaxconn

    予想される出力

    net.core.somaxconn = 1024

安全でない sysctl が許可され、値は更新された Pod 仕様の securityContext 仕様で定義されているように設定されるようになりました。

7.9.8. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.