unsafe sysctl을 허용하는 Kubernetes 클러스터 구성

unsafe sysctl은 다른 Pod의 격리와 노드 안정성에 영향을 줄 수 있으므로 필요한 범위에서만 허용해야 합니다.

설명

워크로드의 securityContext.sysctls나 노드의 허용 설정으로 unsafe sysctl을 사용하면 Pod 간 격리와 노드 안정성에 영향을 줄 수 있습니다. 일반 애플리케이션에서는 사용 중인 Kubernetes와 Linux 커널이 지원하는 안전한 sysctl을 우선 사용해야 합니다.

unsafe sysctl은 기본적으로 비활성화되어 있으며 필요한 노드에서 별도로 허용해야 합니다. 레거시 PodSecurityPolicy의 allowedUnsafeSysctls도 허용 범위를 넓힐 수 있습니다. PSP는 Kubernetes 1.21에서 사용 중단되고 1.25에서 제거되었으므로 현재 클러스터에서는 Pod Security Admission이나 별도 승인 제어 정책으로 제한하세요.

잠재적 영향

  • 잘못된 커널 설정이 컨테이너 동작이나 노드 안정성에 영향을 줄 수 있습니다.
  • 같은 노드의 다른 Pod가 자원 부족이나 격리 약화의 영향을 받을 수 있습니다.
  • 허용되지 않은 sysctl을 요청한 Pod는 실행되지 않아 서비스 시작이 실패할 수 있습니다.

해결 방법

  • 불필요한 unsafe sysctl 요청과 허용 설정을 제거하세요. 안전한 sysctl도 실제 버전과 필요한 값을 확인하세요.
  • 예외가 꼭 필요하면 영향을 검증하고 전용 노드와 스케줄링 제한으로 사용 범위를 좁히세요.
  • 변경 후 Pod 시작, 자원 사용량과 다른 워크로드의 정상 동작을 확인하세요.

예시

다음 예제는 Deployment의 sysctl 설정을 비교합니다. 이미지와 실행 명령은 실제 애플리케이션에 맞게 구성하세요.

변경 전

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
spec:
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      securityContext:
        sysctls:
          - name: kernel.sem
            value: "128 32768 128 4096"
      containers:
        - name: test-ubuntu
          image: ubuntu

kernel.sem은 unsafe sysctl입니다. 노드에서 명시적으로 허용하지 않으면 Pod가 시작되지 않으며, 허용하기 전에 자원과 격리에 미치는 영향을 검토해야 합니다.

변경 후

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app-neg
spec:
  selector:
    matchLabels:
      app: test-app-neg
  template:
    metadata:
      labels:
        app: test-app-neg
    spec:
      securityContext:
        sysctls:
          - name: kernel.shm_rmid_forced
            value: "0"
          - name: net/ipv4/tcp_syncookies
            value: "1"
      containers:
        - name: test-ubuntu
          image: ubuntu

두 설정은 Kubernetes의 안전한 sysctl 목록에 포함됩니다. 이름에 /를 사용하는 표기는 Kubernetes 1.25 이상에서 지원되며, 값의 적합성은 애플리케이션 요구에 맞게 확인해야 합니다.

참조