‫Em seguida.
‫Este é um grande problema.
‫Não execute seus aplicativos como root no contêiner, se
‫puder evitá-lo.
‫Se eu fizer isso bem rápido, em uma pequena
‫demonstração aqui.
‫Tudo certo. Eu tenho o Docker funcionando, pelo
‫menos eu deveria. Tudo certo.
‫E se eu apenas correr ...
‫Se eu apenas executar o Nginx, certo, e fizer
‫uma janela de encaixe
‫nesse contêiner.
‫O que vemos aqui?
‫Dentro do contêiner, o Nginx iniciou um processo
‫na raiz e, em seguida, criou um
‫novo processo como um usuário não
‫raiz. Veja como esse usuário é 101.
‫Isso é comum em muitos programas baseados em daemon,
‫como MySQL, Postgres, Nginx.
‫Muitos deles que não são linguagens de programação
‫farão isso automaticamente. Então, isso é seguro.
‫O que isto está fazendo é permitir ao Nginx gerar
‫processos de trabalho que não são executados como raiz
‫para realizar a maior parte do trabalho.
‫Portanto, eles têm um processo mestre que é executado como raiz, mas
‫não é isso que aceita conexões e realiza a maior
‫parte do trabalho. A maior parte
‫disso está nesses processos de trabalho. Eles são executados como um
‫usuário normal, o que significa que, se houver uma vulnerabilidade
‫no Nginx, é provável que as
‫conexões entrem e alguém esteja tentando explorar o protocolo
‫HTTP do Nginx, ele será bloqueado ou preso nesse usuário em
‫.. . na maioria das vezes, a
‫menos que exista uma vulnerabilidade séria aqui.
‫Aqui em baixo, e então eles estão limitados ao que
‫podem fazer, certo. Mesmo se eles assumirem esse
‫processo de alguma forma, eles ainda serão limitados como usuário.
‫Então, tudo bem.
‫Isso ainda não está sendo executado como raiz
‫verdadeira dentro do contêiner. O que realmente estou falando
‫é que, se você
‫deve executar um aplicativo Python, ou um
‫aplicativo Node, ou algo parecido com uma linguagem de programação, será
‫um padrão para o root, porque a
‫linguagem de programação no contêiner não ' Não sei como
‫seu programa funciona. Não sabe o que você quer fazer.
‫Então, ele fará root por padrão, e isso
‫é mais sobre compatibilidade de aplicativos.
‫Podemos dizer que queremos que isso seja seguro por padrão,
‫mas o Docker escolheu que todos esses contêineres oficiais realmente sejam executados
‫como raiz das linguagens de programação.
‫Vamos verificar isso.
‫Opa Não aquele.
‫Raposa de fogo.
‫Então, se formos, digamos, ao Hub.
‫Vamos apenas fazer o Node.
‫Isso é comum na maioria dos idiomas.
‫Vou apenas escolher o Node como exemplo.
‫Nó interno, se
‫eu for para um dos arquivos do Docker aqui.
‫Então eu procuro pelo usuário.
‫Você notará que na verdade não encontro nada.
‫É apenas esse usuário que adiciona aqui.
‫Você notará que faz isso, certo.
‫É tecnicamente adicionando um grupo chamado Node e adicionando
‫um usuário chamado Node.
‫Se você pesquisar o restante deste arquivo, perceberá que ele nunca muda
‫para esse usuário com a estrofe U S E
‫R, certo.
‫Você deve ver o nó do usuário em algum lugar como uma linha.
‫Eles não fazem isso porque esse é o seu trabalho.
‫Então, o que você deve fazer no seu
‫Dockerfile de nível inferior. Portanto, qualquer arquivo Docker
‫que você esteja criando a partir dessas imagens
‫oficiais para linguagens de programação, você deve estar aproveitando os usuários
‫que eles estão criando para você. Se eles não estiverem criando esses usuários, você poderá
‫criar um da mesma maneira. Você pode roubar
‫essa coisinha de duas linhas e mudar para o usuário
‫que você quer que seja. Se for para Python, você
‫pode chamá-lo de usuário Python, seja o que for.
‫Se você estiver fazendo isso, os
‫aplicativos executados não serão executados como raiz no
‫contêiner. Por padrão,
‫se você apenas executar qualquer aplicativo Node padrão, ele usará o usuário
‫raiz em um contêiner.
‫Por que isso é tão importante?
‫Bem, duas coisas.
‫Primeiro, se alguém conseguir invadir seu aplicativo e
‫invadir seu aplicativo e obter acesso ao sistema
‫de arquivos, se ... se esse aplicativo for raiz,
‫no contêiner, eles poderão fazer o que quiserem
‫no contêiner, certo. Eles podem gravar
‫arquivos no sistema de arquivos. Eles podem instalar mais programas nesse
‫contêiner que podem ser executados sempre que desejarem nesse contêiner.
‫Então, nós realmente não queremos que eles façam isso.
‫Preferimos que eles sejam muito limitados.
‫Portanto, se seus aplicativos suportam, você
‫sabe, faça isso. Basicamente, verifique se você tem
‫o usuário disponível.
‫Então, eu tenho um exemplo do DockerCon aqui.
‫Na DockerCon, tive uma palestra inteira sobre o Node. js, e um
‫dos tópicos estava no usuário.
‫Deixe-me ver se consigo encontrar isso.
‫Viu o que eu fiz aqui? É um arquivo bastante simples.
‫Vou vincular isso e colocá-lo.
‫Neste Dockerfile.
‫Então, neste Dockerfile eu tenho ...
‫Não criei um usuário porque a imagem do Nó
‫já a criou para mim. Estou apenas mudando para o nó do usuário.
‫Depois, instalo meus pacotes com essas duas linhas e,
‫depois, vou executá-lo.
‫Você notará que eu tenho que
‫começar a usar a opção chown em meus comandos de cópia para garantir
‫que meus arquivos sejam agora o mesmo usuário que o usuário que
‫meu programa executará. Caso contrário, pode haver problemas,
‫certo. Minha aplicação provavelmente ... se
‫não consegue ler os arquivos, não pode executá-lo, certo.
‫Então, eu preciso das alterações dessas permissões.
‫Eu posso fazer isso com um liner em um comando de cópia.
‫Você também verá aqui que estou criando o diretório e exibindo-o
‫também para que, sempre que o aplicativo for copiado, eu
‫apenas tenha certeza, com certeza, de que as permissões
‫estejam lá para que ele possa gravar.
‫Como no minuto em que altero esse usuário,
‫esse comando de cópia, ou especificamente esse comando de execução, será executado
‫como esse usuário. Se não tiver
‫permissões para gravar nos diretórios, também falhará.
‫Portanto, o motivo pelo qual o Docker não faz isso por você é
‫porque eles sabem que suas coisas provavelmente vão quebrar.
‫Portanto, você precisa executar essas etapas extras.
‫Mas, não é tão difícil. Realmente não é.
‫Provavelmente, você pode fazer todos esses testes em um dia e,
‫em seguida, desejará executar seus sistemas por meio de IC completo
‫e testes completos em seus servidores, porque às vezes o PHP é
‫um dos que são ruins nisso.
‫O PHP gosta de executar um monte de arquivos de log
‫e escrever bastante no disco.
‫Realmente, qualquer coisa que permita o upload de usuários será
‫gravada no disco. Portanto, você precisa garantir
‫que essas permissões estejam corretas para que, quando as pessoas estiverem gravando arquivos,
‫digamos que estejam executando um blog WordPress.
‫Esse blog do WordPress estará gravando em disco quando os usuários fizerem
‫o upload de imagens em seus respectivos blogs.
‫Você deseja garantir que essas permissões funcionem.
‫Então, você definitivamente precisará fazer alguns testes.
‫Depois de fazer isso, seu aplicativo não será
‫executado como root. Portanto, ele não pode ter
‫controle total no contêiner. O outro motivo
‫pelo qual você deseja fazer isso é se houver
‫uma vulnerabilidade no Linux, que é rara, ou no Docker, que
‫também é muito raro, e há menos probabilidade de
‫que eles saiam desse contêiner. Isso só aconteceu, bem, uma vez
‫que eu estou muito ciente, e na verdade documentei um
‫pouco disso aqui.
‫VACA suja. Dirty COW era
‫uma vulnerabilidade no Linux que permitia que você
‫saísse
‫de um contêiner, certo. A mudança de seu
‫usuário aqui,
‫não necessariamente resolveria o problema inteiro,
‫mas certamente não o afetou.
‫Outras vulnerabilidades, provavelmente protegeria contra.
‫Mas esta é uma prática recomendada.
‫Eu acho que se você tiver uma equipe de segurança,
‫eles vão insistir para que você não execute as coisas como raiz.
‫Então, você faria
‫isso.