nicholasjackson/cnitchContainer Snitch는 Docker Engine에서 실행 중인 프로세스를 확인하고, 루트로 실행 중인 프로세스가 발견되면 경고합니다.
cnitch(스니치 또는 컨테이너 스니치)는 Docker 컨테이너를 모니터링하여 루트로 실행 중인 모든 프로세스를 식별하는 간단한 프레임워크이자 명령줄 도구입니다.
왜 이것이 나쁜 일일까요? 아직 can I haz non-privileged containers? by mhausenblas에 방문하지 않으셨다면 지금 바로 가서 모든 정보를 얻으시길 권장합니다.
cnitch를 개발할 때 애플리케이션의 버그라고 생각한 문제를 만났습니다. cnitch가 Docker 컨테이너 내에서 자신을 루트 프로세스로 보고하고 있었습니다. Dockerfile에 사용자를 만들고 루트로 실행하지 않는다고 명시적으로 적혀 있었기 때문에 어떻게 이런 일이 발생할 수 있는지 확신할 수 없었습니다. 많은 디버깅과 확인 끝에 Dockerfile을 다시 확인하기로 결정했고, 다음과 같은 내용을 발견했습니다.
FROM alpine
RUN adduser -h /home/cnitch -D cnitch cnitch
COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch
#USER cnitch
ENTRYPOINT ["/home/cnitch/cnitch"]
애플리케이션 컨테이너를 테스트하여 Docker 소켓의 권한 문제를 파악하려고 할 때 USER 명령을 주석 처리했었던 것 같습니다. 꽤 메타적이었습니다. cnitch가 cnitch의 문제를 찾는 데 도움을 준 것입니다. 이 내용은 통합 테스트에 반드시 포함될 것입니다.
cnitch는 API를 사용하여 Docker Engine에 연결하고 현재 실행 중인 컨테이너를 쿼리한 다음, 이 컨테이너 내에서 실행 중인 프로세스를 검사하여 루트 사용자로 실행 중인 프로세스를 식별합니다. 루트 프로세스가 발견되면 이 정보는 구성 가능한 보고 모듈로 전송되어 이 정보를 감사하거나 조치를 취할 수 있습니다.
2017/07/29 16:04:27 Starting Cnitch: Monitoring Docker Processes at: tcp://172.16.255.128:2376
2017/07/29 16:04:27 Checking for root processes every: 10s
2017/07/29 16:05:08 Checking image: ubuntu, id: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> WARNING: found process running as root: tail -f /dev/null pid: 365
현재 cnitch는 StatsD와 StdOut에 보고하는 기능을 가지고 있습니다. 보고 백엔드는 확장 가능하여 모든 백엔드를 쉽게 지원할 수 있습니다. 예를 들어, 로그 스태시 또는 다른 로그 파일 집계 도구를 지원하는 백엔드를 구축하는 것은 비교적 간단한 과정입니다.
예외는 cnitch.exception.root_process 메트릭을 사용하여 statsD 엔드포인트에 카운트로 전송됩니다. 메트릭은 cnitch 인스턴스의 host 이름과 container 이름으로 태그 지정됩니다.
StdOut 로거는 보고된 예외를 StdOut으로 전송하는 간단한 출력 로거입니다.
Docker 컨테이너에서 cnitch를 실행하든 바이너리로 실행하든, 환경 변수 DOCKER_HOST로 서버의 URL 또는 소켓 경로를 설정하여 Docker API에 액세스해야 합니다.
--hostname=[hostname] 메트릭 집계에 사용할 이름 또는 IP 주소--statsd-server=[hostname:port] statsD 수집기의 URI, 생략하면 statsD 보고가 비활성화됩니다.--check=[duration (예: 10s (10초), 1m (1분))] 스니치가 루트 프로세스를 스캔하는 빈도환경 변수 DOCKER_HOST를 Docker 엔진 API로 설정한 다음 필요한 플래그와 함께 snitch를 실행합니다.
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
cnitch는 권한이 없는 컨테이너에서 실행되며, Docker 소켓을 사용하여 API에 액세스하려면 cnitch 사용자를 docker 그룹에 추가해야 합니다. 이는 --group-add 플래그를 사용하여 수행할 수 있으며, docker 사용자 그룹의 그룹 ID로 설정하면 됩니다. 예를 들어:
--group-add=$(stat -f "%g" /var/run/docker.sock
API 액세스를 위해 Docker 소켓 파일을 사용하는 예
$ docker run -i -t --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
--group-add=$(stat -f "%g" /var/run/docker.sock) \
-e "DOCKER_HOST:unix:///var/run/docker.sock" \
quay.io/nicholasjackson/cnitch [options]
Mac에서 Docker Machine을 사용하여 실행하는 경우 Docker 소켓은 VM 내에 있으므로 stat 명령을 사용하여 그룹 ID를 찾을 수 없습니다.
cnitch가 statsd에 데이터를 내보내는 방법을 보여주는 예제 Docker Compose 스택이 ./example 폴더에 있습니다. 이 예제를 실행하려면:
$ cd ./example
$ docker-compose up
모든 것이 실행되면 웹 브라우저에서 http://[docker host ip]:3000을 열면 Grafana 로그인 화면이 나타납니다.
다음 자격 증명을 사용하여 Grafana에 로그인합니다:
그런 다음 cnitch 대시보드를 선택합니다. 이 대시보드는 현재 실행 중인 루트 프로세스를 보여줍니다.
/var/run/docker.sock을 사용하여 Docker 호스트와 통신하지 않는 경우, ./example/docker-compose.yml 파일의 일부 설정을 변경해야 합니다.
Docker Bench Security 스크립트의 기능 구현 https://github.com/docker/docker-bench-security
[ ] 1.1 컨테이너를 위한 별도의 파티션이 생성되었는지 확인
[ ] 1.2 컨테이너 호스트가 강화되었는지 확인
[ ] 1.3 Docker가 최신 버전인지 확인
[ ] 1.4 신뢰할 수 있는 사용자만 Docker 데몬을 제어할 수 있는지 확인
[ ] 1.5 Docker 데몬에 대한 감사가 구성되었는지 확인
[ ] 1.6 Docker 파일 및 디렉토리 - /var/lib/docker에 대한 감사가 구성되었는지 확인
[ ] 1.7 Docker 파일 및 디렉토리 - /etc/docker에 대한 감사가 구성되었는지 확인
[ ] 1.8 Docker 파일 및 디렉토리 - docker.service에 대한 감사가 구성되었는지 확인
[ ] 1.9 Docker 파일 및 디렉토리 - docker.socket에 대한 감사가 구성되었는지 확인
[ ] 1.10 Docker 파일 및 디렉토리 - /etc/default/docker에 대한 감사가 구성되었는지 확인
[ ] 1.11 Docker 파일 및 디렉토리 - /etc/docker/daemon.json에 대한 감사가 구성되었는지 확인
[ ] 1.12 Docker 파일 및 디렉토리 - /usr/bin/docker-containerd에 대한 감사가 구성되었는지 확인
[ ] 1.13 Docker 파일 및 디렉토리 - /usr/bin/docker-runc에 대한 감사가 구성되었는지 확인
[ ] 2.1 기본 브리지에서 컨테이너 간 네트워크 트래픽이 제한되는지 확인
[ ] 2.2 로깅 수준이 'info'로 설정되었는지 확인
[ ] 2.3 Docker가 iptables를 변경할 수 있는지 확인
[ ] 2.4 안전하지 않은 레지스트리가 사용되지 않는지 확인
[ ] 2.5 aufs 스토리지 드라이버가 사용되지 않는지 확인
[ ] 2.6 Docker 데몬에 대한 TLS 인증이 구성되었는지 확인
[ ] 2.7 기본 ulimit가 적절하게 구성되었는지 확인
[ ] 2.8 사용자 네임스페이스 지원 활성화
[ ] 2.9 기본 cgroup 사용이 확인되었는지 확인
[ ] 2.10 기본 장치 크기가 필요할 때까지 변경되지 않는지 확인
[ ] 2.11 Docker 클라이언트 명령에 대한 권한 부여가 활성화되었는지 확인
[ ] 2.12 중앙 집중식 및 원격 로깅이 구성되었는지 확인
[ ] 2.13 레거시 레지스트리(v1)에 대한 작업이 비활성화되었는지 확인
[ ] 2.14 실시간 복원이 활성화되었는지 확인
[ ] 2.15 사용자 공간 프록시가 비활성화되었는지 확인
[ ] 2.16 필요한 경우 데몬 전체 사용자 지정 seccomp 프로필이 적용되었는지 확인
[ ] 2.17 프로덕션에서 실험적 기능이 사용되지 않는지 확인
[ ] 2.18 컨테이너가 새로운 권한을 획득하지 못하도록 제한되었는지 확인
[ ] 3.x ...
[x] 4.1 컨테이너용 사용자가 생성되었는지 확인
[ ] 4.2 컨테이너가 신뢰할 수 있는 기본 이미지를 사용하는지 확인
[ ] 4.3 컨테이너에 불필요한 패키지가 설치되지 않았는지 확인
[ ] 4.4 이미지가 스캔되고 재구축되어 보안 패치가 포함되었는지 확인
[ ] 4.5 Docker에 대한 콘텐츠 신뢰가 활성화되었는지 확인
[ ] 4.6 컨테이너 이미지에 HEALTHCHECK 명령이 추가되었는지 확인
[ ] 4.7 Dockerfile에서 업데이트 명령이 단독으로 사용되지 않는지 확인
[ ] 4.8 이미지에서 setuid 및 setgid 권한이 제거되었는지 확인
[ ] 4.9 Dockerfile에서 ADD 대신 COPY가 사용되었는지 확인
[ ] 4.10 Dockerfile에 비밀이 저장되지 않았는지 확인
[ ] 4.11 검증된 패키지만 설치되었는지 확인
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...