nicholasjackson/cnitchContainer Snitch verifica processos em execução no Docker Engine e alerta se algum estiver sendo executado como root
cnitch (snitch ou container snitch) é um framework simples e ferramenta de linha de comando para monitorar contêineres Docker e identificar quaisquer processos que estejam executando como root.
Por que isso é ruim? Se você ainda não visitou can I haz non-privileged containers? por mhausenblas, então recomendo que vá até lá agora para obter todas as informações.
Quando eu estava desenvolvendo o cnitch, me deparei com o que pensei ser um bug na aplicação: o cnitch estava se reportando como um processo root dentro de um contêiner Docker. Não sabia como isso era possível, já que o Dockerfile declarava explicitamente que eu estava criando um usuário e não executando como root. Após muita depuração e verificação, decidi revisar o Dockerfile e encontrei isto:
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"]
Quando estava testando o contêiner da aplicação para descobrir um problema de permissões no socket Docker, devo ter comentado o comando USER. Bem meta: o cnitch ajudou a encontrar um problema no próprio cnitch; isso vai definitivamente para os testes de integração.
O cnitch conecta-se ao Docker Engine via API e consulta os contêineres em execução no momento; em seguida, inspeciona os processos em execução dentro desse contêiner e identifica aqueles que estão sendo executados como usuário root. Quando um processo root é encontrado, essa informação é enviada para os módulos de relatório configuráveis, permitindo auditar ou tomar ação com base nessa informação.
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
Atualmente, o cnitch tem a capacidade de reportar para StatsD e StdOut. Os backends de relatório são extensíveis para facilitar o suporte a qualquer backend; por exemplo, seria um processo bastante trivial construir um backend para suportar log stash ou outra ferramenta de agregação de arquivos de log.
As exceções são enviadas para o endpoint statsD como uma contagem usando a métrica cnitch.exception.root_process. As métricas também são marcadas com o nome do host da instância do cnitch e o nome do container.
O logger StdOut é um logger de saída simples que envia as exceções reportadas para o StdOut.
Se você executar o cnitch em um contêiner Docker ou como binário, ele precisa de acesso à API Docker definindo a URL do servidor ou o caminho para o socket com a variável de ambiente DOCKER_HOST
--hostname=[hostname] o nome ou endereço IP a ser usado para agregação de métricas--statsd-server=[hostname:port] a URI do coletor statsd; se omitido, o relatório statsd será desabilitado--check=[duração, ex.: 10s (10 segundos), 1m (1 minuto)] a frequência de verificação que o snitch usará para escanear processos rootDefina a variável de ambiente DOCKER_HOST para a API do seu Docker Engine e então execute o snitch com as flags necessárias.
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
O cnitch é executado em um contêiner não privilegiado e, se você deseja usar o socket Docker para acesso à API, é necessário adicionar o usuário cnitch ao grupo docker. Isso pode ser feito através da flag --group-add, definindo-a para o ID do grupo do grupo de usuários Docker.
Por exemplo:
--group-add=$(stat -f "%g" /var/run/docker.sock
Exemplo usando o arquivo de socket Docker para acesso à API
$ 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]
Se você estiver executando em um Mac e usando o Docker Machine, o socket Docker está dentro da VM, o que significa que você não pode usar o comando stat para descobrir o ID do grupo.
Há uma pilha de exemplo do Docker Compose dentro da pasta ./example para mostrar como o cnitch exporta dados para o statsd. Para executar este exemplo:
$ cd ./example
$ docker-compose up
Depois que tudo estiver em execução, abra http://[docker host ip]:3000 no seu navegador e você verá a tela de login do Grafana.
Faça login no Grafana usando as seguintes credenciais:
Em seguida, selecione o painel cnitch. Este painel mostra os processos root em execução no momento.
Se você não estiver usando /var/run/docker.sock para se comunicar com seu host Docker, precisará alterar algumas configurações dentro do arquivo ./example/docker-compose.yml para corresponder às suas configurações.
Implementar funcionalidades do Docker Bench Security Script https://github.com/docker/docker-bench-security
[ ] 1.1 Garantir que uma partição separada para contêineres tenha sido criada
[ ] 1.2 Garantir que o host do contêiner tenha sido endurecido
[ ] 1.3 Garantir que o Docker esteja atualizado
[ ] 1.4 Garantir que apenas usuários confiáveis tenham permissão para controlar o daemon Docker
[ ] 1.5 Garantir que a auditoria esteja configurada para o daemon Docker
[ ] 1.6 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /var/lib/docker
[ ] 1.7 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /etc/docker
[ ] 1.8 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - docker.service
[ ] 1.9 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - docker.socket
[ ] 1.10 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /etc/default/docker
[ ] 1.11 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /etc/docker/daemon.json
[ ] 1.12 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /usr/bin/docker-containerd
[ ] 1.13 Garantir que a auditoria esteja configurada para arquivos e diretórios Docker - /usr/bin/docker-runc
[ ] 2.1 Garantir que o tráfego de rede seja restrito entre contêineres na bridge padrão
[ ] 2.2 Garantir que o nível de log esteja definido como 'info'
[ ] 2.3 Garantir que o Docker tenha permissão para fazer alterações no iptables
[ ] 2.4 Garantir que registros inseguros não sejam usados
[ ] 2.5 Garantir que o driver de armazenamento aufs não seja usado
[ ] 2.6 Garantir que a autenticação TLS para o daemon Docker esteja configurada
[ ] 2.7 Garantir que o ulimit padrão esteja configurado adequadamente
[ ] 2.8 Ativar suporte a namespaces de usuário
[ ] 2.9 Garantir que o uso padrão de cgroup tenha sido confirmado
[ ] 2.10 Garantir que o tamanho do dispositivo base não seja alterado até que necessário
[ ] 2.11 Garantir que a autorização para comandos do cliente Docker esteja habilitada
[ ] 2.12 Garantir que o log centralizado e remoto esteja configurado
[ ] 2.13 Garantir que operações no registro legado (v1) estejam desabilitadas
[ ] 2.14 Garantir que a restauração ao vivo esteja habilitada
[ ] 2.15 Garantir que o Proxy de Userland esteja desabilitado
[ ] 2.16 Garantir que o perfil seccomp personalizado (para todo o daemon) seja aplicado, se necessário
[ ] 2.17 Garantir que funcionalidades experimentais sejam evitadas em produção
[ ] 2.18 Garantir que contêineres sejam restritos de adquirir novos privilégios
[ ] 3.x ...
[x] 4.1 Garantir que um usuário para o contêiner tenha sido criado
[ ] 4.2 Garantir que os contêineres usem imagens base confiáveis
[ ] 4.3 Garantir que pacotes desnecessários não sejam instalados no contêiner
[ ] 4.4 Garantir que as imagens sejam escaneadas e reconstruídas para incluir patches de segurança
[ ] 4.5 Garantir que a confiança de conteúdo do Docker esteja habilitada
[ ] 4.6 Garantir que instruções HEALTHCHECK tenham sido adicionadas à imagem do contêiner
[ ] 4.7 Garantir que instruções de atualização não sejam usadas sozinhas no Dockerfile
[ ] 4.8 Garantir que permissões setuid e setgid sejam removidas nas imagens
[ ] 4.9 Garantir que COPY seja usado em vez de ADD no Dockerfile
[ ] 4.10 Garantir que segredos não sejam armazenados em Dockerfiles
[ ] 4.11 Garantir que apenas pacotes verificados sejam instalados
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...