Docker/LXC의 AppArmor 구성 파일

Docker/LXC의 AppArmor 구성 파일

MySQL을 실행하는 Docker 컨테이너(LXC)가 있습니다. Docker의 기본 아이디어는 일반적으로 "컨테이너당 하나의 실행 프로세스"이므로 MySQL 바이너리를 대상으로 하는 AppArmor 프로필을 정의하면 적용됩니까? 이것을 테스트할 수 있는 방법이 있나요?

답변1

첫째, cgroup은 시스템의 다른 애플리케이션과 애플리케이션을 격리하는 데 사용되지 않습니다. 리소스 사용 및 장치 액세스를 관리하는 데 사용됩니다. 다양한 네임스페이스(PID, UTS, 마운트, 사용자...)는 일부(제한된) 격리를 제공합니다.

또한 Docker 컨테이너 내에서 시작된 프로세스는 실행 중인 AppArmor 프로필을 관리하지 못할 수도 있습니다. 현재 접근 방식은 컨테이너를 시작하기 전에 특정 AppArmor 프로필을 설정하는 것입니다.

Docker의 libcontainer 실행 드라이버가 지원하는 것 같습니다.컨테이너용 AppArmor 프로필 설정, 그러나 문서에서 예제나 참조를 찾을 수 없습니다.

분명히 AppArmor도 이를 지원합니다.우분투의 LXC.

애플리케이션에 대한 AppArmor 구성 파일을 작성하고 컨테이너 내부에서 프로세스를 시작하기 전에 LXC/libcontainer/Docker/...가 로드되었는지 확인해야 합니다.

이런 방식으로 사용되는 프로필은 강제 적용되어야 하며, 이를 테스트하려면 불법적인 액세스를 시도하여 실패하는지 확인해야 합니다.

이 경우 바이너리와 실제 실행된 구성 파일 사이에는 링크가 없습니다. 컨테이너에서 이 구성 파일을 사용하려면 Docker/LXC에 명시적으로 지시해야 합니다. MySQL 바이너리에 대한 구성 파일을 작성하면 컨테이너가 아닌 호스트에서만 실행이 적용됩니다.

답변2

대답은 아마도 '아니요'일 것입니다.

이것Ubuntu 서버 가이드 항목 LXC귀하의 정확한 문제에 대해 거의 논의하고 다음과 같이 진술했습니다.

컨테이너 내의 프로그램은 더 이상 제한할 수 없습니다. 예를 들어 MySQL은 컨테이너 프로필(호스트 보호)에서 실행되지만 MySQL 프로필(컨테이너 보호)에 들어갈 수는 없습니다.

악용으로 인한 부작용을 방지하는 더 나은 옵션은 컨테이너를 실행하는 사용자를 제한하고 악용을 사용하는 것입니다.커널 특성. 그러나 docker제가 아는 한 현재는 지원되지 않습니다 userns.

이 경우 호스트의 관점에서 MySQL은 권한이 없는 사용자로 실행되지만, 컨테이너 내에서는 root원하는 경우 iptablesMySQL을 호스트의 외부 포트에 바인딩할 수 있습니다.

관련 정보