특권 모드 vs. 비특권 모드

뉴렐릭 Kubernetes 통합은 기본적으로 특권 모드 로 실행됩니다. 이를 통해 인프라 에이전트가 기본 호스트 정보에 직접 액세스할 수 있습니다.

이는 가장 완전한 텔메트리를 제공하지만 일부 보안 정책(예: 파드 보안 표준 또는 OpenShift 표준 계약 조항(SCC))에서는 워크로드를 비특권 모드 로 실행해야 할 수도 있습니다.

특권 모드가 필요한 이유

뉴렐릭 인프라 에이전트는 Kubelet 파드에 포함되어 있으며 심층적인 시스템 지표를 수집하려면 노드의 운영 시스템에 대한 낮은 수준의 액세스가 필요합니다.

공통 라이브러리 에서 privileged 의 기본값은 false입니다. 하지만 이 차트는 에이전트가 다음을 수행할 수 있도록 기본적으로 이를 true 로 설정합니다(values.yaml 참조):

호스트의 /proc 및 /sys 파일 시스템을 읽습니다.
해당 호스트 의 CPU, 메모리, 스토리지 및 네트워크 통계를 정확하게 수집합니다.
인프라 상태와 Kubernetes 객체 간의 연관성을 보여주는 전체 프로세스 목록 및 메타데이터를 수집합니다.

권한 없이 실행 중

클러스터 보안 정책이 파드의 보안 컨텍스트에서 privileged 을(를) 허용하지 않는 경우, privileged 을(를) false(으)로 설정하여 비활성화할 수 있습니다.

데이터 수집에 미치는 영향

중요

권한 있는 모드를 비활성화하면 호스트 레벨 메트릭 및 메타데이터가 손실됩니다. 호스트 엔티티는 뉴렐릭에서 생성되지 않습니다.

권한이 없는 모드에서는 인프라 에이전트가 호스트의 리소스 사용량을 볼 수 없으며 호스트 엔티티가 생성되지 않습니다. 다음을 포함한 표준 호스트 메트릭에 대한 액세스 권한을 잃게 됩니다:

SystemSample: 호스트 수준의 CPU, 메모리 및 부하 평균.
StorageSample: 노드의 파일 시스템에 대한 디스크 사용량 및 I/O.
NetworkSample: 물리적 네트워크 인터페이스 통계.
ProcessSample: 블루렐릭 컨테이너 외부에서 실행되는 프로세스에 대한 데이터입니다.

권한 없는 모드에서 사용할 수 없는 속성 및 메트릭의 정확한 세부 목록은 Linux 에이전트 실행 모드 문서를 참조하십시오.

설정 방법

사용자 지정 값 파일을 업데이트하여 전역 권한 플래그를 false 으로 설정하십시오.

global:
  privileged: false

Windows 노드

Windows 노드는 권한 있는 모드와 권한 없는 모드를 모두 지원합니다. 권한 있는 모드가 컨테이너 보안 컨텍스트를 통해 작동하는 Linux와 달리, Windows 권한 있는 모드는 HostProcess 컨테이너를 사용합니다 — 이는 컨테이너에 호스트 리소스에 대한 직접 액세스 권한을 부여하는 Windows 네이티브 메커니즘입니다.

HostProcess 컨테이너란 무엇인가요?

windows.privileged=true (Windows 노드의 기본값)을 사용하여 배포하는 경우 모니터링 컨테이너는 Windows HostProcess 컨테이너로 실행됩니다. 이는 표준 Windows 컨테이너 격리와는 근본적으로 다른 실행 모델입니다:

컨테이너의 프로세스는 Windows 호스트 OS 프로세스 공간 에서 직접 실행되며, 컨테이너 네임스페이스에 격리되지 않고 노드의 작업 관리자에서 볼 수 있습니다.
hostNetwork: true 자동으로 적용되어, 프로세스가 노드의 모든 네트워크 인터페이스에 액세스할 수 있게 합니다.
컨테이너는 호스트 파일 시스템 및 레지스트리에 액세스할 수 있습니다.
로컬 권한은 제한되어 있지만 컴퓨터 계정으로 네트워크 리소스에 인증할 수 있는 기본 제공 Windows 계정인 NT AUTHORITY\Local Service(으)로 실행됩니다.

Windows 노드 자체에서 호스트 메트릭(CPU, 메모리, 디스크 및 네트워크 인터페이스)을 수집하려면 HostProcess 모드가 필요합니다.

Windows용 권한 없는 모드

windows.privileged=false을(를) 설정하는 경우 컨테이너는 호스트 네트워크 액세스 없이 표준 ContainerUser (으)로 실행됩니다. 에이전트는 전달 전용 모드로 작동합니다. 즉, kubelet 통합 스크래퍼에서 데이터를 전달하지만 호스트 리소스에 직접 액세스하지는 않습니다. 이 모드에서는 노드 수준 샘플(SystemSample, StorageSample, NetworkSample)이 수집되지 않습니다.

많은 노드 관련 메트릭은 K8sNodeSample 이벤트를 통해 권한 없는 모드에서 여전히 사용할 수 있습니다. 권한 없는 모드에서 사용할 수 없는 메트릭의 전체 목록은 Windows용 Kubernetes 통합 제한 사항을 참조하십시오.

Windows 권한 있는 모드에 대한 보안 고려사항

HostProcess 컨테이너는 호스트 OS에 직접 액세스하여 실행되므로, 뉴렐릭은 windows.privileged=true을(를) 사용할 때 다음 방법을 권장합니다:

세분화된 kubelet 권한 부여를 활성화 하여 더 광범위한 nodes/proxy 하위 리소스가 아닌 통합이 사용하는 특정 읽기 전용 엔드포인트로 RBAC를 제한합니다. 이를 위해서는 KubeletFineGrainedAuthz 기능 게이트가 있는 Kubernetes 1.32+가 필요합니다.

newrelic-infrastructure Helm 차트에서:

rbac:
  kubeletFineGrainedAuth: true

셸 기록 및 helm get values에 표시될 수 있으므로 values.yaml 에 포함하거나 --set을(를) 통해 전달하는 대신 라이선스 키를 Kubernetes Secret으로 저장하세요:
bash
```
$kubectl create secret generic newrelic-license \
>  --namespace newrelic \
>  --from-literal=licenseKey=<YOUR_KEY>
```
```
global:
  customSecretName: newrelic-license
  customSecretLicenseKey: licenseKey
```
kubelet.windowsNodeSelector을(를) 사용하여 지정된 노드에 DaemonSet를 고정합니다. 클러스터에 워크로드 분류가 다른 Windows 노드가 있는 경우, 모니터하려는 노드로만 모니터링을 제한할 수 있습니다.
Windows Defender 방화벽 규칙 또는 프록시를 사용하여 노드 수준에서 네트워크 이그레스를 강제합니다. Kubernetes NetworkPolicy 개체는 hostNetwork: true 이(가) 파드 네트워킹을 완전히 우회하기 때문에 HostProcess 파드에 적용되지 않습니다. NetworkPolicy 적용은 CNI 플러그인에 따라 달라진다는 점에 유의하세요 ― 모든 CNI 플러그인이 기본적으로 네트워크 정책을 적용하는 것은 아닙니다. 클러스터의 다른 곳에서 이그레스 제어를 위해 NetworkPolicy 에 의존하는 경우, 이에 의존하기 전에 실제로 적용이 활성화되어 있는지 확인하십시오. 프록시를 사용하는 경우:
```
global:
  proxy: "http://your-proxy:3128"
```
HostProcess 컨테이너는 노드 리소스를 두고 직접 경쟁하므로, 노드 안정성을 보호하려면 리소스 제한을 설정 하세요. 차트는 기본적으로 메모리 제한을 설정합니다 ― 이를 유지하거나 직접 설정할 수 있습니다:
```
kubelet:
  windows:
    agent:
      resources:
        limits:
          memory: 300Mi
```
기본적으로 CPU 제한은 설정되어 있지 않습니다. 모니터링 에이전트의 경우, 하드 CPU 제한은 노드 로드 시 스크래핑 간격을 놓칠 위험이 있습니다. 클러스터 정책에서 요구하는 경우, 설정하기 전에 해당 트레이드오프를 고려하십시오.
전용 네임스페이스에서 모니터링 스택을 실행하고 해당 네임스페이스에서 리소스를 생성하거나 수정할 수 있는 사용자를 제한합니다. HostProcess 파드는 직접적인 호스트 액세스 권한으로 실행되므로, 이 네임스페이스에 대한 수평적 액세스는 노드 액세스와 동일하게 취급되어야 합니다.
기존 Windows 보안 모니터링이 이러한 노드를 포함하는지 확인하십시오. HostProcess 컨테이너 프로세스는 호스트 OS 프로세스 공간에서 직접 실행되며 다른 프로세스와 마찬가지로 호스트에 표시됩니다. Get-Process 출력에 나타나며, 프로세스 생성 감사가 활성화된 경우 보안 로그 이벤트 4688(프로세스 생성) 및 4689(프로세스 종료)에 나타납니다.
보안 로그에서 HostProcess 컨테이너 출시에 대한 식별 가능한 신호는 containerd-shim-runhcs-v1.exe 이(가) 생성자 프로세스로서 cmd.exe 을(를) NT AUTHORITY\Local Service(으)로 생성하고, 그 뒤를 이어 체인 더 아래에 있는 에이전트 프로세스(newrelic-infra.exe 및 nri-kubernetes)가 따르는 것입니다.
Windows에서 프로세스 생성 감사는 기본적으로 비활성화되어 있으며, 이를 활성화하고 보안 로그를 읽으려면 관리자 또는 SYSTEM 권한이 필요하다는 점을 참고하십시오 ― 뉴렐릭 컨테이너 자체 내에서는 구성할 수 없습니다. 조직에서 SIEM, Windows 이벤트 전달 또는 EDR 도구를 사용하여 Windows 호스트에서 이벤트 로그를 수집하는 경우, 적용 범위가 Kubernetes Windows 노드까지 확장되는지 확인하십시오.