Mode privilégié vs mode non privilégié

L’intégration Kubernetes de New Relic s’exécute en mode privilégié par défaut. Cela permet à l'agent d'infrastructure d'accéder directement aux informations de l'hôte sous-jacent.

Bien que cela fournisse la télémétrie la plus complète, certaines politiques de sécurité (telles que les Pod Security Standards ou les SCC OpenShift) peuvent exiger l'exécution de charges de travail en mode non privilégié.

Pourquoi le mode privilégié est requis

L'agent New Relic Infrastructure est inclus dans le pod Kubelet et nécessite un accès de bas niveau au système d'exploitation du nœud pour collecter des métriques système approfondies.

La valeur par défaut pour privileged dans la bibliothèque commune est false. Cependant, ce chart le définit à true par défaut (voir values.yaml) pour garantir que l'agent puisse :

Lire les systèmes de fichiers /proc et /sys de l'hôte.
Collectez des statistiques précises sur le processeur, la mémoire, le stockage et le réseau de l'hôte sous-jacent.
Collectez des listes complètes de processus et des métadonnées qui corrèlent la santé de l'infrastructure avec vos objets Kubernetes.

Exécution en mode non privilégié

Si la politique de sécurité de votre cluster n'autorise pas privileged dans le contexte de sécurité de vos pods, vous pouvez le désactiver en définissant privileged sur false.

Impact sur la collecte de données

Important

La désactivation du mode privilégié entraînera la perte des métriques de l’hôte et des métadonnées. Les entités hôtes ne seront pas créées dans New Relic.

En mode non privilégié, l'Agent d'infrastructure ne peut pas voir l'utilisation des ressources de l'hôte et les entités d'hôte ne seront pas créées. Vous perdrez l'accès aux métriques d'hôte standard, notamment :

SystemSample : CPU, mémoire et charges moyennes au niveau de l'hôte.
StorageSample : Utilisation du disque et E/S pour le système de fichiers du nœud.
NetworkSample : Statistiques de l'interface réseau physique.
ProcessSample : Données sur les processus s'exécutant en dehors du conteneur New Relic.

Pour une liste détaillée des attributs et métriques indisponibles en mode non privilégié, consultez la documentation sur les modes d’exécution de l’agent Linux.

Comment le configurer

Mettez à jour votre fichier de valeurs personnalisées pour définir l'indicateur global privilégié sur false:

global:
  privileged: false

Nœuds Windows

Les nœuds Windows prennent en charge à la fois les modes privilégié et non privilégié. Contrairement à Linux, où le mode privilégié fonctionne via le contexte de sécurité du conteneur, le mode privilégié de Windows utilise les conteneurs HostProcess — le mécanisme natif de Windows pour accorder à un conteneur un accès direct aux ressources de l’hôte.

Que sont les conteneurs HostProcess ?

Lorsque vous déployez avec windows.privileged=true (la valeur par défaut pour les nœuds Windows), les conteneurs de monitoring s'exécutent en tant que conteneurs Windows HostProcess. Il s'agit d'un modèle d'exécution fondamentalement différent de l'isolation des conteneurs Windows standard :

Les processus du conteneur s’exécutent directement dans l’ espace de processus du système d’exploitation hôte Windows — ils sont visibles dans le Gestionnaire des tâches sur le nœud, non isolés dans un espace de nommage de conteneur.
hostNetwork: true est automatiquement appliqué, donnant au processus accès à toutes les interfaces réseau sur le nœud.
Le conteneur a accès au système de fichiers et au registre de l’hôte.
Il s'exécute en tant que NT AUTHORITY\Local Service, un compte Windows intégré avec des privilèges locaux limités, mais la capacité de s'authentifier auprès des ressources réseau en tant que compte d'ordinateur.

Le mode HostProcess est requis pour collecter les métriques de l'hôte — le processeur, la mémoire, le disque et les interfaces réseau — à partir du nœud Windows lui-même.

Mode non privilégié pour Windows

Lorsque vous définissez windows.privileged=false, les conteneurs s'exécutent en tant que ContainerUser standard sans accès au réseau de l'hôte. L’agent fonctionne en mode transfert uniquement — il transmet les données du scraper de l’intégration kubelet mais n’accède pas directement aux ressources de l’hôte. Les échantillons au niveau des nœuds (SystemSample, StorageSample, NetworkSample) ne sont pas collectés dans ce mode.

De nombreuses métriques liées aux nœuds sont toujours disponibles en mode non privilégié via l’événement K8sNodeSample. Pour la liste complète des métriques indisponibles en mode non privilégié, consultez Limites de l’intégration Kubernetes pour Windows.

Considérations de sécurité pour le mode privilégié de Windows

Étant donné que les conteneurs HostProcess s'exécutent avec un accès direct au système d'exploitation de l'hôte, New Relic recommande les pratiques suivantes lors de l'utilisation de windows.privileged=true:

Activez l’autorisation Kubelet à granularité fine pour restreindre le RBAC aux points de terminaison en lecture seule spécifiques que l’intégration utilise, plutôt qu’à la sous-ressource nodes/proxy plus étendue. Cela nécessite Kubernetes 1.32+ avec la porte de fonctionnalité KubeletFineGrainedAuthz.

Dans le chart Helm newrelic-infrastructure :

rbac:
  kubeletFineGrainedAuth: true

Stockez la clé de licence en tant que secret Kubernetes plutôt que de procéder à son incorporation (embedding) dans values.yaml ou de la transmettre via --set, où elle serait visible dans l'historique du shell et helm get values:
bash
```
$kubectl create secret generic newrelic-license \
>  --namespace newrelic \
>  --from-literal=licenseKey=<YOUR_KEY>
```
```
global:
  customSecretName: newrelic-license
  customSecretLicenseKey: licenseKey
```
Épingler le DaemonSet aux nœuds désignés à l'aide de kubelet.windowsNodeSelector. Si votre cluster possède des nœuds Windows avec différentes classifications de workload, vous pouvez restreindre le monitoring uniquement aux nœuds que vous avez l'intention de monitorer.
Appliquez la sortie réseau au niveau du nœud à l'aide des règles du pare-feu Windows Defender ou d'un proxy. Les objets NetworkPolicy Kubernetes ne s'appliquent pas aux pods HostProcess parce que hostNetwork: true contourne entièrement le réseau des pods. Notez que l'application de NetworkPolicy dépend également de votre plug-in CNI — tous les plug-in CNI n'appliquent pas les politiques réseau par défaut. Si vous comptez sur NetworkPolicy pour le contrôle de sortie ailleurs dans votre cluster, vérifiez que l'application est réellement active avant de vous y fier. Si vous utilisez un proxy :
```
global:
  proxy: "http://your-proxy:3128"
```
Définir des limites de ressources pour protéger la stabilité du nœud, car les conteneurs HostProcess sont directement en concurrence pour les ressources du nœud. Le chart définit une limite de mémoire par défaut — vous pouvez la conserver ou définir la vôtre :
```
kubelet:
  windows:
    agent:
      resources:
        limits:
          memory: 300Mi
```
Une limite de CPU n'est pas définie par défaut. Pour un agent de monitoring, une limite stricte de CPU risque de faire manquer des intervalles de scrape sous la charge du nœud. Si la politique de votre cluster en exige un, évaluez ce compromis avant de le définir.
Exécutez la stack de monitoring dans un espace de nommage dédié et restreignez les personnes qui peuvent y créer ou modifier des ressources. Comme les pods HostProcess s'exécutent avec un accès direct à l'hôte, l'accès latéral à cet espace de nommage doit être traité comme équivalent à un accès au nœud.
Assurez-vous que votre monitoring de sécurité Windows existant couvre ces nœuds. Les processus de conteneur HostProcess s'exécutent directement dans l'espace de processus de l'OS hôte et sont visibles par l'hôte comme n'importe quel autre processus. Ils apparaissent dans la sortie Get-Process et, avec l'audit de création de processus activé, dans les événements de log de Security 4688 (création de processus) et 4689 (fin de processus).
Le signal identifiable pour le lancement d'un conteneur HostProcess dans le log de Security est containerd-shim-runhcs-v1.exe en tant que processus créateur générant cmd.exe en tant que NT AUTHORITY\Local Service, suivi des processus de l'agent (newrelic-infra.exe et nri-kubernetes) plus loin dans la chaîne.
Notez que l'audit de création de processus est désactivé par défaut sous Windows et nécessite des privilèges administrateur ou système pour l'activer et pour lire le log de Security — il ne peut pas être configuré depuis l'intérieur du conteneur New Relic lui-même. Si votre organisation utilise un SIEM, Windows Event Forwarding, ou un outil EDR pour collecter des logs d'événements à partir des hôtes Windows, assurez-vous que la couverture s'étend à vos nœuds Windows Kubernetes.