非rootユーザーとして Instana エージェントを実行する（パブリックプレビュー）

オンラインで編集

systemdベースの Linux ホストでは、 Linux カーネル機能を使用することで、 Instana ホストエージェントを非rootユーザーとして実行できます。 この機能により、エージェントは最小限の必要な権限で実行されながら完全な監視機能を提供し続けるため、セキュリティが向上します。

注： この機能はパブリックプレビューとして利用可能です。 IBM いつでも変更する可能性があります。 この機能は評価目的でのみご利用ください。 本番環境で使用する前に、十分にテストしてください。

概要

非rootエージェント機能は、インストール時にエージェントランタイムに適用される Linux カーネル機能を利用します。 このアプローチにより、 Instana エージェントは昇格された権限を必要とせずに任意のユーザーアカウントで実行可能となり、監視インフラのセキュリティ態勢を大幅に強化します。

重要: 新しいカーネル機能ベースのアプローチは、rootベースのインストールと完全な機能互換性を提供します。 すべてのセンサーと監視機能を制限なくサポートします。 この手法は、センサーの制約があった従来の実験的な非ルート手法に比べて、大きな進歩である。

主なメリット

  • 強化されたセキュリティ ：エージェントを最小限の必要な権限で実行します。 攻撃対象領域を縮小する。
  • コンプライアンス : ルートユーザーとしてサービスを実行することを禁止するセキュリティ要件を満たす。
  • 柔軟性 ：組織のセキュリティポリシーに沿ったカスタムユーザーおよびグループアカウントを使用します。
  • 完全な機能性 ：すべてのセンサーと監視機能が制限なく動作します。 ルートベースのインストールと完全な機能互換性を実現します。

仕組み

非rootエージェントは、エージェントバイナリに特定の権限を付与するために Linux カーネル機能を使用します。 完全なルートアクセスは必要ありません。 インストール時、インストーラーはエージェントランタイムに必要な権限を適用し、通常は昇格された権限を必要とするすべての監視タスクを実行できるようにします。

エージェントは、非rootユーザーでの動作を特に考慮して構成されたsystemdサービスファイルを通じて管理されます。 これらの設定により、適切な起動、シャットダウン、およびサービス管理が保証されます。

前提条件

非ルートエージェントをインストールする前に、システムが以下の要件を満たしていることを確認してください：

  • オペレーティングシステム : systemdベースの Linux ディストリビューション。例: RHEL 7以降、 Ubuntu 16.04 以降、 Debian 8 以降、またはSLES 12以降。
  • systemd : バージョン 219 以降。
  • Linux カーネル : バージョン 3.10 以降で、機能サポート付き。
  • パッケージマネージャー : RPMベースのパッケージマネージャー (yum または dnf) または Debian ベースのパッケージマネージャー (apt)。
  • 権限 : 初期インストールにはルート権限またはsudoアクセスが必要です（インストール後はエージェントは非ルートユーザーとして実行されます）。

systemd のバージョンを確認するには:

systemctl --version

Linux のカーネルバージョンを確認するには:

uname -r

環境変数

以下の環境変数が非rootエージェント機能を制御します：

変数 説明 Default 必須
インスタナ_エージェント_非ルート 非ルートエージェント機能を有効にする false いいえ（ユーザーとグループの両方が指定されている場合、自動的に true に設定されます）
インスタナ_エージェント_ユーザー (オプション) エージェントを実行するユーザーアカウントを指定します instanaagent ( INSTANA_AGENT_NON_ROOT = が設定trueされている場合に使用) いいえ
インスタナ_エージェント_グループ (オプション) エージェントを実行するグループアカウントを指定します instanaagent ( INSTANA_AGENT_NON_ROOT = が設定trueされている場合に使用) いいえ

インストール前にこれらの環境変数を設定してください。 Debian およびRPMパッケージのインストール前スクリプトは、インストール中にこれらの変数を処理します。

カスタムユーザーとグループのインストール

特定のユーザーおよびグループアカウントを使用する必要がある場合、インストール時にカスタム値を指定できます。

  1. インストール前にユーザーとグループが存在しない場合は作成してください:
    sudo groupadd -r myagentgroup
sudo useradd -r -g myagentgroup -s /sbin/nologin -c "Instana Agent User" myagentuser
  2. カスタムユーザーおよびグループ環境変数を設定します:
    export INSTANA_AGENT_USER=myagentuser
export INSTANA_AGENT_GROUP=myagentgroup
注: INSTANA_AGENT_USER と INSTANA_AGENT_GROUP の両方を設定した場合、インストーラーは自動的に INSTANA_AGENT_NON_ROOT フラグを有効にします。

インストール

デフォルトでは、非ルートエージェントはシステムユーザーおよびグループを作成し、それらを使用します instanaagent。 このアプローチは、ほとんどのデプロイメントで推奨されます。

注: 非rootエージェントを使用した IBM MQ 監視の詳細については、 制限事項のセクションでインストールに関する詳細を確認してください。
  1. インストール前に、非root機能を有効にするため、 INSTANA_AGENT_NON _ROOT環境変数を設定してください:
    export INSTANA_AGENT_NON_ROOT=true
  2. エージェントは、 Linux のメインインストールセクションに記載されている標準的な方法のいずれかを使用してインストールしてください：

制限

非ルートエージェントを使用する際には、以下の制限事項を確認してください：

Systemd の要件

非rootエージェント機能は、systemdベースの Linux ディストリビューションでのみ利用可能です。 SysV init や Upstart などの他の init システムを使用するシステムはサポートされていません。

Linux -のみ対応

この機能は Linux ホストでのみご利用いただけます。 Windows、 macOS,、 Unix などの他のオペレーティングシステムは、非rootユーザーでの操作にはサポートされていません。

Kubernetes および Red Hat OpenShift

非ルートエージェントは、現時点では Kubernetes および Red Hat OpenShift デプロイメントをサポートしていません。 Kubernetes または Red Hat OpenShift Container Platform (OCP) にエージェントをインストールするには、依然として管理者権限が必要です。

IBM MQ 要件

非rootエージェントを使用した IBM MQ の監視を行う場合、エージェントのユーザー名およびグループ名が12文字以下であることを確認する必要があります。 デフォルトのユーザー名およびグループ名である「 instanaagent」で十分です。 また、12文字以下であれば、任意のユーザー名やグループ名を使用することもできます。

カスタムユーザー名やグループ名を使用する場合は、インストーラーを実行する前に、適切な環境変数を設定してください。 詳細については、 「カスタムユーザーおよびグループのインストール 」のセクションを参照してください。

PHP モニター

非rootエージェントは監視機能をサポートしていません：
  • PHP rootlessな Podman 環境における実行時間。
  • PHP - `or` または listen ` PHPpm.status_listen ` の `FPM` 設定ディレクティブで、 TCP のリスンアドレスを使用する `FPM` ランタイム。

アップグレードに関する考慮事項

初期のパブリックプレビューリリースでは、標準的なアップグレード手順を使用してルートベースのエージェントを非ルートエージェントにアップグレードすることはできません。 既存のエージェントをアンインストールしてください。 その後、エージェントを再インストールし、非rootユーザーの設定を有効にしてください。
注記: 非ルートエージェントバージョン間では、標準的なパッケージ管理ツールのアップグレード手順を使用してバージョンアップが可能です。

外部から提供された Java ランタイム

エージェントを非rootユーザーとして実行する場合、外部から提供される Java ランタイムはサポートされません。 サポートされるのは、 Instana エージェントのinstall-packageから提供される Java ランタイムのみです。

センサーおよび機能の完全なサポート

カーネル機能を利用する非rootエージェントは、すべての Instana センサーおよび監視機能をサポートしています。 このサポートには以下が含まれます：
  • すべてのインフラ監視センサー
  • サポート対象の全技術におけるアプリケーションパフォーマンス監視（APM）
  • プロセス監視とトレーシング

このカーネル機能ベースのアプローチにより、ルートベースのエージェントインストールと完全な機能互換性が実現されます。 従来の実験的な非ルートアプローチがセンサーの制限を受けていたのとは異なり、この新しい実装は完全な監視機能を提供する。

カーネル機能リファレンス

非ルートエージェントは、監視機能を実行するために特定の Linux カーネル機能が必要です。 インストール時、systemdサービス設定はこれらの権限を自動的にエージェントバイナリに適用します。 以下の表は、必要なすべての機能とその目的を包括的にまとめたものです：

機能 目的 詳細
CAP_AUDIT_WRITE 監査ロギング 許可し sudo 、その他の特権ヘルパーがカーネル監査サブシステムに監査イベントを書き込むことを可能にします。 この機能がなければ、 sudo sudo は動作しますが、「sudo: 監査メッセージを送信できません: 操作が許可されていません」というメッセージがログに記録されます。
CAP_SYS_ADMIN 名前空間操作 ほとんどの名前空間（net、ipc、uts、pid、cgroup）で setns() 必要です。 ホストネームスペースへのアクセスを nsenter 可能にし、包括的なシステム監視を実現します。
CAP_SYS_CHROOT マウント名空間へのアクセス マウントネームスペースには「 setns(--mount).」で入力する必要があります。 エージェントが異なるマウントネームスペース間でファイルシステム階層を検査できるようにします。
CAP_SYS_PTRACE 工程検査 他のユーザーが所有するプロセスを検査し、操作することが必要です。 包括的なプロセス監視のため、クロスユーザー JVM の添付および外部 /proc/pid/ ディレクトリの読み取りが必要。
CAP_SYS_RESOURCE リソースの制限と eBPF リソース制限の引き上げ（setrlimit）が必要です。 eBPF のプロファイリングで必要とされるため RLIMIT_MEMLOCK 、BPFマップとperfリングバッファをメモリに固定できるようにします。
CAP_NET_ADMIN ネットワーク・モニタリング ネットワーク検出およびホストネットワーク検査機能で使用されます。 包括的なネットワークトポロジーマッピングと構成分析を可能にします。
CAP_NET_RAW 生ソケット操作 生ソケット（例：ICMPやping、パケットレベルの操作）に必要なもの。 ネットワーク診断および低レベルネットワーク監視に不可欠。
CAP_DAC_OVERRIDE DACバイパス（書き込みと実行） DAC書き込みおよび実行チェックをバイパスすることを許可します。 Unix0600モードを使用する可能性があるドメインソケットまたはファイルへのアクセスを有効にします。 コンテナ監視のためのコンテナソケットへのアクセスを許可します。
CAP_DAC_READ_SEARCH 裁量アクセス制御（DAC）バイパス（読み取り） 読み取りおよび検索操作においてDACをバイパスする。 他のユーザーの /proc/pid/ ディレクトリやcgroup情報を、権限制限なしに読み取る必要がある。
CAP_FOWNER ファイルシステムの所有権の回避 /tmp/.com_ibm_tools_attach/<pid>Instana エージェントが、他のJVMによって残され、異なるユーザーが所有する古い IBM や J9 のattachディレクトリ（例：）を削除するクリーンアップタスクに必要です。
CAP_KILL 信号操作 JVM のattach操作に必要なもの。 例えば、Byte Buddyはターゲット JVM にシグナルを送信します。 アプリケーション監視のため、ユーザー境界を越えた信号許可チェックをバイパスする必要があった。
CAP_SETUIDまたはCAP_SETGID ユーザーとグループの切り替え プロセスの実効UIDまたは実効GIDを変更するために必要です。 Instana エージェント（ JVM ）は、 AmbientCapabilitiesCapabilityBoundingSet と両方に存在する場合は、プロセス内ユーザー切り替えを実行できます。 ( CapabilityBoundingSet にのみ存在し、には存在しない AmbientCapabilities場合)、 JVM はこれらの機能を持たないが、などの setuid-root ヘルパーは依然として sudo それらを取得できる。 境界集合にこれらのキャップが含まれていない場合、内部 setresuid() 遷移 setresgid() や遷移を実行できず sudo 、「操作が許可されていません」エラーで失敗します。
CAP_SYSLOG EBPF カーネルシンボル が有効になっている kptr_restrict 場合 /proc/kallsyms/ 、カーネルシンボルのアドレスを読み取ることができます。 eBPF のプロファイリングでは、kprobesおよびカーネルレベルのプロファイリングにおけるカーネルシンボルとスタックトレースを解決するために、これが必要です。 この機能がないと、カーネルアドレスが隠蔽され、プロファイリング出力でのシンボル解決が正しく行われなくなる可能性があります。

systemd サービスファイルはこれらの機能を設定します。 エージェントプロセスは起動時にそれらを自動的に継承します。 これらの機能は、エージェントランタイムが確実に利用できるように、許可フラグと有効フラグの両方で設定されます。

実行中のエージェントプロセスに割り当てられた機能を検証するには、次のコマンドを実行します:

grep CapEff /proc/$(pgrep -f 'karaf.home=.*instana')/status

以下のコマンドを実行して、機能の16進値をデコードします：

capsh --decode=<hex_value>
重要： これらの機能を手動で変更しないでください。 必須の機能を削除すると、監視機能が動作しなくなります。