Exécution de l'agent d' Instana ation en tant qu'utilisateur non root (aperçu public)

Modifier en ligne

Vous pouvez exécuter l'agent hôte Instana en tant qu'utilisateur non root sur les hôtes d' Linux s basés sur systemd en utilisant les capacités du noyau Linux. Cette fonctionnalité améliore la sécurité en permettant à l'agent de fonctionner avec les privilèges minimaux requis tout en continuant à fournir toutes les fonctions de surveillance.

Remarque : cette fonctionnalité est disponible en avant-première publique. IBM peut le modifier à tout moment. Utilisez cette fonctionnalité à des fins d'évaluation uniquement. Testez-le minutieusement avant de l'utiliser dans un environnement de production.

Présentation

La fonctionnalité d'agent non root utilise les capacités du noyau d' Linux, qui sont appliquées au runtime de l'agent lors de l'installation. Cette approche permet à l'agent d' Instana s de fonctionner avec un compte utilisateur arbitraire sans nécessiter de privilèges élevés, ce qui améliore considérablement la sécurité de votre infrastructure de surveillance.

Important : la nouvelle approche basée sur les capacités du noyau offre une parité complète des fonctionnalités avec les installations basées sur root. Il prend en charge tous les capteurs et toutes les fonctionnalités de surveillance sans aucune limitation. Cette approche représente une avancée significative par rapport aux méthodes expérimentales antérieures sans racine, qui comportaient des restrictions au niveau des capteurs.

Avantages principaux

  • Sécurité renforcée : exécutez l'agent avec les privilèges minimaux requis. Réduisez la surface d'attaque.
  • Conformité : respectez les exigences de sécurité qui interdisent l'exécution de services en tant qu'utilisateur root.
  • Flexibilité : utilisez des comptes utilisateurs et groupes personnalisés qui correspondent aux politiques de sécurité de votre organisation.
  • Fonctionnalité complète : tous les capteurs et toutes les capacités de surveillance fonctionnent sans aucune restriction. Parité complète des fonctionnalités avec les installations basées sur la racine.

Fonctionnement

L'agent non root utilise les capacités du noyau Linux pour accorder des privilèges spécifiques au binaire de l'agent. Il ne nécessite pas d'accès root complet. Lors de l'installation, le programme d'installation applique les capacités nécessaires au runtime de l'agent, lui permettant ainsi d'effectuer toutes les tâches de surveillance qui nécessitent généralement des autorisations élevées.

L'agent est géré via des fichiers de service systemd spécialement configurés pour fonctionner sans droits root. Ces paramètres garantissent un démarrage, un arrêt et une gestion des services corrects.

Prérequis

Avant d'installer l'agent non root, assurez-vous que votre système répond aux exigences suivantes :

  • Système d'exploitation : Une distribution Linux basée sur systemd, par exemple RHEL 7 ou ultérieure, Ubuntu 16.04 ou ultérieure, Debian 8 ou ultérieure, ou SLES 12 ou ultérieure.
  • systemd : version 219 ou ultérieure.
  • Linux noyau : version 3.10 ou ultérieure avec prise en charge des capacités.
  • Gestionnaire de paquets : un gestionnaire de paquets basé sur RPM (yum ou dnf) ou un gestionnaire de paquets basé sur l' Debian (apt).
  • Autorisations : accès root ou sudo pour l'installation initiale (l'agent s'exécute en tant que non-root après l'installation).

Pour vérifier la version de systemd :

systemctl --version

Pour vérifier la version du noyau d' Linux :

uname -r

Variables d'environnement

Les variables d'environnement suivantes contrôlent la fonctionnalité de l'agent non root :

Variables Description Par défaut Obligatoire
INSTANA_AGENT_NON_ROOT Activer la fonctionnalité d'agent non root false Non (définie automatiquement sur true si l'utilisateur et le groupe sont tous deux spécifiés)
INSTANA_AGENT_UTILISATEUR (facultatif) Spécifie le compte utilisateur qui exécute l'agent instanaagent (utilisé lorsque INSTANA_AGENT_NON_ROOT =true) Non
INSTANA_AGENT_GROUP (facultatif) Spécifie le compte de groupe qui exécute l'agent instanaagent (utilisé lorsque INSTANA_AGENT_NON_ROOT =true) Non

Définissez ces variables d'environnement avant l'installation. Les scripts de préinstallation des paquets RPM et de l' Debian e traitent ces variables pendant l'installation.

Installation personnalisée pour les utilisateurs et les groupes

Si vous devez utiliser un compte utilisateur et un compte de groupe spécifiques, vous pouvez fournir des valeurs personnalisées lors de l'installation.

  1. Créez l'utilisateur et le groupe avant l'installation s'ils n'existent pas :
    sudo groupadd -r myagentgroup
sudo useradd -r -g myagentgroup -s /sbin/nologin -c "Instana Agent User" myagentuser
  2. Définissez les variables d'environnement utilisateur et groupe personnalisées :
    export INSTANA_AGENT_USER=myagentuser
export INSTANA_AGENT_GROUP=myagentgroup
Remarque : lorsque vous définissez à la fois INSTANA_AGENT_USER et INSTANA_AGENT_GROUP, le programme d'installation active automatiquement l'indicateur INSTANA_AGENT_NON_ROOT.

Installation

Par défaut, l'agent non root crée et utilise un utilisateur et un groupe système nommés instanaagent. Cette approche est recommandée pour la plupart des déploiements.

Remarque : pour plus d'informations sur la surveillance d' IBM MQ s avec un agent non root, consultez la section relative aux limitations pour obtenir plus de détails sur l'installation.
  1. Avant l'installation, définissez la variable d'environnement INSTANA_AGENT_NON_ROOT pour activer la fonctionnalité non root :
    export INSTANA_AGENT_NON_ROOT=true
  2. Installez l'agent à l'aide de l'une des méthodes standard décrites dans les sections principales consacrées à l'installation d' Linux :

Limitations

Vérifiez les limitations suivantes lorsque vous utilisez l'agent non root :

Configuration requise pour Systemd

La fonctionnalité d'agent non root n'est disponible que sur les distributions d' Linux s basées sur systemd. Les systèmes qui utilisent d'autres systèmes d'initialisation, tels qu' SysV init ou Upstart, ne sont pas pris en charge.

Linux - prise en charge exclusive

Cette fonctionnalité est uniquement disponible pour les hébergeurs d' Linux. Les autres systèmes d'exploitation, tels que Windows, macOS, et Unix, ne sont pas pris en charge pour les opérations non root.

Kubernetes et Red Hat OpenShift

L'agent non root ne prend pas encore en charge les déploiements Kubernetes et Red Hat OpenShift. L'installation de l'agent sur Kubernetes ou Red Hat OpenShift Container Platform (OCP) nécessite toujours des autorisations élevées.

IBM MQ condition

Pour la surveillance d' IBM MQ s à l'aide de l'agent non-root, vous devez vous assurer que le nom de l'utilisateur et du groupe de l'agent ne dépasse pas 12 caractères. Le nom d'utilisateur et de groupe par défaut, instanaagent, suffit. Vous pouvez également utiliser n'importe quel nom d'utilisateur ou de groupe dont la longueur est inférieure ou égale à 12 caractères.

Si vous utilisez un nom d'utilisateur ou de groupe personnalisé, veillez à définir les variables d'environnement appropriées avant de lancer le programme d'installation. Pour plus d'informations, consultez la section consacrée à l'installation personnalisée des utilisateurs et des groupes.

Surveillance de PHP

L'agent non-root ne prend pas en charge la surveillance :
  • PHP exécutions dans des environnements d' Podman s sans root.
  • PHP - Les instances FPM qui utilisent des adresses d'écoute TCP dans les directives de pm.status_listen configuration ou listen PHP -FPM.

Remarques concernant la mise à niveau

Dans la version préliminaire publique initiale, vous ne pouvez pas mettre à niveau un agent basé sur root vers un agent non root à l'aide du processus de mise à niveau standard. Désinstallez l'agent existant. Ensuite, réinstallez l'agent et activez la configuration non root.
Remarque : vous pouvez effectuer une mise à niveau entre des versions d'agent non root à l'aide du processus de mise à niveau standard du gestionnaire de paquets.

Environnement d'exécution d' Java fourni en externe

Un runtime d' Java externe pour l'agent n'est pas pris en charge lorsque vous exécutez l'agent en tant qu'utilisateur non root. Seul le runtime Java de l'agent Instana install-package est pris en charge.

Prise en charge complète des capteurs et des fonctionnalités

L'agent non-root qui utilise les fonctionnalités du noyau prend en charge tous les capteurs et toutes les fonctionnalités de surveillance d' Instana. Ce soutien comprend :
  • Tous les capteurs de surveillance des infrastructures
  • Surveillance des performances des applications (APM) pour toutes les technologies prises en charge
  • Surveillance et traçabilité des processus

Cette approche basée sur les capacités du noyau permet d'obtenir une parité complète des fonctionnalités avec les installations d'agents basées sur la racine. Contrairement aux précédentes approches expérimentales sans accès root qui comportaient des restrictions au niveau des capteurs, cette nouvelle implémentation offre des fonctions de surveillance complètes.

Référence des capacités du noyau

L'agent non root nécessite des capacités spécifiques du noyau d' Linux pour exécuter ses fonctions de surveillance. Lors de l'installation, la configuration du service systemd applique automatiquement ces capacités au binaire de l'agent. Le tableau suivant fournit une référence complète de toutes les capacités requises et de leurs objectifs :

Fonctionnalité Fonction Informations
CAP_AUDIT_WRITE Consignation dans le journal d'audit Permet à sudo et à d'autres assistants privilégiés d'écrire des événements d'audit dans le sous-système d'audit du noyau. Sans cette fonctionnalité, sudo continue de fonctionner mais enregistre le message « sudo : impossible d'envoyer le message d'audit : opération non autorisée ».
CAP_SYS_ADMIN Opérations sur l'espace de noms Requis pour setns() sur la plupart des espaces de noms (net, ipc, uts, pid et cgroup). Permet nsenter d'accéder aux espaces de noms hôtes pour une surveillance complète du système.
CAP_SYS_CHROOT Accès à l'espace de noms du montage Obligatoire pour entrer dans les espaces de noms de montage avec setns(--mount). Permet à l'agent d'inspecter les hiérarchies du système de fichiers dans différents espaces de noms de montage.
CAP_SYS_PTRACE Inspection des processus Nécessaire pour inspecter et interagir avec les processus appartenant à d'autres utilisateurs. Nécessaire pour l' JVM ter-utilisateurs et la lecture de répertoires /proc/pid/ étrangers pour une surveillance complète des processus.
CAP_SYS_RESOURCE Limites des ressources et « eBPF » Nécessaire pour augmenter les limites de ressources (setrlimit). Nécessaire pour le profilage d' eBPF, afin d'augmenter la mémoire disponible RLIMIT_MEMLOCK et de permettre ainsi le verrouillage en mémoire des cartes BPF et des tampons de l'anneau de performance.
CAP_NET_ADMIN Surveillance réseau Utilisé par les fonctionnalités de découverte du réseau et d'inspection du réseau hôte. Permet une cartographie complète de la topologie du réseau et une analyse de la configuration.
CAP_NET_RAW Opérations sur les sockets brutes Nécessaire pour les sockets brutes (par exemple, ICMP ou ping, et les opérations au niveau des paquets). Indispensable pour le diagnostic réseau et la surveillance réseau de bas niveau.
CAP_DAC_OVERRIDE Contournement DAC (écriture et exécution) Permet de contourner les vérifications d'écriture et d'exécution DAC. Permet d'accéder aux sockets de domaine ou aux fichiers Unix qui peuvent utiliser le mode 0600. Permet d'accéder aux sockets des conteneurs pour leur surveillance.
CAP_DAC_READ_SEARCH Contournement du contrôle d'accès discrétionnaire (DAC) (lecture) Contourne le DAC pour les opérations de lecture et de recherche. Nécessaire pour lire les répertoires et les informations /proc/pid/ cgroup d'autres utilisateurs sans restrictions d'autorisation.
CAP_FOWNER Contournement des droits de propriété du système de fichiers Nécessaire pour les tâches de nettoyage au cours desquelles l'agent Instana supprime les répertoires d' IBM J9 attach obsolètes (par exemple, /tmp/.com_ibm_tools_attach/<pid>) laissés par d'autres JVM et appartenant à différents utilisateurs.
CAP_KILL Opérations de signalisation Requis pour les opérations d'attachement d' JVM. Par exemple, Byte Buddy envoie un signal à l' JVM cible. Nécessaire pour contourner les contrôles d'autorisation des signaux entre les limites des utilisateurs pour la surveillance des applications.
CAP_SETUID ou CAP_SETGID Changement d'utilisateur et de groupe Nécessaire pour modifier l'UID ou le GID effectif d'un processus. S'il est présent à la fois dans CapabilityBoundingSet et AmbientCapabilities, l'agent d' Instana JVM peut effectuer des changements d'utilisateur en cours de traitement. Si elle n'est présente que dans CapabilityBoundingSet (mais pas dans AmbientCapabilities), l' JVM e ne dispose pas de ces capacités, mais setuid-root les aides telles que sudo peuvent tout de même les acquérir. Sans ces limites dans l'ensemble de bornes, sudo ne peut pas effectuer ses transitions internes setresuid()setresgid() ou et échoue avec une erreur « Opération non autorisée ».
CAP_SYSLOG Symboles du noyau EBPF Permet de lire les adresses des /proc/kallsyms/ symboles du noyau lorsque cette option kptr_restrict est activée. Nécessaire au profilage via ` eBPF ` pour résoudre les symboles du noyau et les traces de pile pour les kprobes et le profilage au niveau du noyau. Sans cette fonctionnalité, les adresses du noyau risquent d'être masquées, ce qui empêcherait une résolution correcte des symboles dans les résultats du profilage.

Le fichier de service systemd configure ces capacités. Le processus agent les hérite automatiquement au démarrage. Les capacités sont définies avec les indicateurs « autorisé » et « effectif » afin de garantir leur disponibilité pour le runtime de l'agent.

Exécutez la commande suivante pour vérifier les capacités attribuées au processus de l'agent en cours d'exécution :

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

Exécutez la commande suivante pour décoder les valeurs hexadécimales des capacités :

capsh --decode=<hex_value>
Important : ne modifiez pas manuellement ces capacités. La suppression d'une fonctionnalité requise entraîne l'échec des fonctionnalités de surveillance.