설명
AppArmor는 Linux 컨테이너가 파일, 네트워크 등 시스템 자원에 접근하는 범위를 제한합니다. 의도한 프로필이 적용되지 않으면 침해된 애플리케이션의 접근 범위가 넓어질 수 있습니다. 명시적 설정이 없다는 사실만으로 보호가 전혀 없다고 단정할 수는 없으며, 노드 지원과 런타임 기본 프로필을 확인해야 합니다.
잠재적 영향
- 불필요한 시스템 자원 접근이 허용되면 침해의 영향이 커질 수 있습니다.
- 잘못된 프로필 이름이나 지원하지 않는 노드로 인해 컨테이너 실행이 실패할 수 있습니다.
해결 방법
- 지원되는 API에서는 securityContext.appArmorProfile에 RuntimeDefault 또는 검증된 Localhost 프로필을 지정하세요. 기존 annotation은 해당 Kubernetes 버전의 지원 여부를 확인하세요.
- AppArmor가 노드에서 활성화되어 있는지 확인하고, 사용자 정의 프로필은 실행 가능한 모든 노드에 미리 로드하세요. 실제 프로필 적용과 필요한 애플리케이션 동작을 시험하세요.
예시
기존 AppArmor annotation 형식을 비교합니다. 새 구성에는 해당 버전이 지원하는 appArmorProfile 필드를 사용하세요.
변경 전
yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: dummy
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
dummy는 유효한 기존 AppArmor 프로필 지정 형식이 아닙니다. 보호 없이 정상 실행된다고 가정하지 말고 실행 거부 여부를 확인해야 합니다.
변경 후
yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: runtime/default
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
기존 형식으로 런타임 기본 프로필을 요청합니다. 노드의 AppArmor 지원과 실제 적용을 확인해야 합니다.