설명
Pod의 특권 실행, 권한 상승과 호스트 접근을 제한하는 admission 정책이 없으면 불필요하게 강한 실행 권한이 허용될 수 있습니다. 보안 컨텍스트 제한은 워크로드 요구에 맞춰 적용해야 합니다.
기존 SecurityContextDeny 플러그인은 Kubernetes 1.27에서 사용 중단되었고 1.30에서 제거되었습니다. 현재 클러스터에서 이 플러그인을 활성화하려 하지 말고 Pod Security Admission 또는 지원되는 정책 엔진을 사용하세요.
잠재적 영향
- 제한이 없는 보안 컨텍스트로 인해 특권 컨테이너나 불필요한 권한이 허용될 수 있습니다.
- 워크로드가 침해되면 호스트나 다른 자원에 대한 영향이 커질 수 있습니다.
해결 방법
- Pod Security Admission의 적절한 정책 수준이나 지원되는 정책 엔진으로 보안 컨텍스트를 제한하세요.
- 실제 워크로드를 점검하고 경고·감사 결과를 확인한 뒤 차단 정책을 적용하세요.
- 필요한 예외만 승인하고 새 Pod 요청에서 의도한 제한이 적용되는지 시험하세요.
예시
아래는 SecurityContextDeny가 존재했던 Kubernetes 1.24의 인수 비교용 발췌입니다. 지원이 종료된 버전을 배포하라는 권장이 아니며, Kubernetes 1.30 이상에서는 뒤의 플러그인 설정을 사용할 수 없습니다. 나머지 제어면 설정은 생략되어 있습니다.
변경 전
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: registry.k8s.io/kube-apiserver:v1.24.17
command: ["kube-apiserver"]
args: ["--disable-admission-plugins=SecurityContextDeny"]
변경 후
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: registry.k8s.io/kube-apiserver:v1.24.17
command: ["kube-apiserver"]
args:
["--enable-admission-plugins=SecurityContextDeny"]
설명:
- 변경 전: 이전 플러그인을 명시적으로 끕니다. 다른 admission 정책의 적용 여부는 별도로 확인해야 합니다.
- 변경 후: 이전 플러그인을 활성화하는 역사적 예시입니다. 현재 운영 환경에서는 지원되는 Pod 보안 정책으로 대체하세요.