hashicorp
Worflow (Fluxos de trabalho), não tecnologias. Mudança de infraestrutura estática para um novo ambiente dinâmico
A abordagem da HashiCorp é focar no objetivo final e no fluxo de trabalho. O software e o hardware evoluirão e melhorarão, toda a linha da Hashicorp tem como objetivo: simplificar a adoção de modelos e fluxos (através de produtos), além de proporcionar a experiência do usuário mais simplificada possível.
O design de toda solução tecnológica, começa com um fluxo de trabalho ágil para um determinado fim. E isto é feito de acordo com mapeamento do que existe, e a construção de novas ferramentas complementares para simplificar o fluxo de trabalho.
Desta forma, a visão é construir soluções independente, novas, e a melhor tecnologia disponível para resolver o problema. As tecnologias mudam, mas os objetivos finais permanecem os mesmos.
Simples, Modular, Composto
A abordagem simples, modular e composto, permite a Hashicorp criar produtos com um nível mais alto de abstração. Em vez de resolver o problema holístico, a proposta é dividir blocos.
A abordagem da Hashcorp e todos seus módulos, busca a melhor solução possível para o escopo de cada problema e, em seguida, combinar os blocos para formar uma solução sólida e completa.
Os principais blocos da solução HashiCorp são:
Automação de segurança: Gerenciamento de segredos e proteção de dados confidenciais com base na identidade do usuário e na identidade do workload (serviços, servidores e aplicações).
Automação de infraestrutura: Automatização do provisionamento, da conformidade (Governance) e o gerenciamento da infraestrutura em cloud através de um fluxo de trabalho simples e comum, tornando possível o conceito de infra as a code (IaC).
Automação de redes: Entrega e agilidade de ambientes de rede automatizados , incluindo dispositivos físicos, dispositivos virtuais e malha de serviço distribuído (Service Mesh).
Automação de aplicativos: Implementação de qualquer aplicativo e com segurança com entrega progressiva, estratégias de failover, segurança e de redes integradas.
Com o Vault podemos gerenciar e administrar segredos computacionais de uma maneira segura, simples e eficaz. Os segredos (entre outros mais) são qualquer informação que desejamos controlar rigidamente o acesso, como por exemplo:
- Chaves de API
- Senhas
- Certificados
O Vault é fornecido como Open Source ou versão Enterprise (versões pagas0, onde provê funcionalidades para alta disponibilidade e balanceamento para cenários grandes e complexos, além de suporte oficial em diferentes modelos (Silver e Gold).
Segundo o Gartner, “By 2022, more than half of enterprises using privileged access management (PAM) tools will emphasize just-in-time privileged access over long-term privileged access, up from less than 25% today.
By 2021, over 50% of organizations using DevOps will adopt PAM-based secrets management products, rising rapidly from less than 10% today”
Benefícios do Vault:
Vault aplica abordagem de geração de credencial por demanda. Vault pode gerar chaves One-Time-Passwords (OTP), RSA, ou atuar como autoridade de autenticação (signing), com uso de chaves públicas
Segredos Dinâmicos possibilitam a gestão de intenção (exemplo: web server precisa acessar um banco), com seguintes benefícios:
Evitar Vazamento: Minimiza impacto de vazamento e ataque, pois credenciais são efêmeras. (deixam de existir, após seu uso).Não-Repudiação. Credenciais únicas por acesso, deixam processo mais seguro e identificado.
Rotação Automática. Anexando junto ao segredo, o tempo de vida, eles são automaticamente rotacionados. Isto melhora postura de segurança quanto a padrões de mercado (SOX, BASEL, LGPD, GPDR, PCI).
Revogação Prática. Devido ao mecanismos de expiração, o Vault conhece cada segredo que cada entidade possui. Isto torna possível, a revogação automática em caso de comprometimento. Credenciais únicas, automatizam o controle e limitando o impacto de uma revogação pontual.
E então, quer bater um papo e compartilhar nossos casos de uso?
A ferramenta possui uma gama de funcionalidades, entre as principais são: Armazenamento seguro de segredos, segredos dinâmicos (sob demanda), Leasing, renovação e revogação de segredos.
Com o Vault é possível armazenar de maneira segura, permitindo auditoria de quem teve acesso a informação, acrescentou, modificou ou deletou registros. Esse tipo de controle se faz cada vez mais importante para as organizações, como a LGPD (Lei Geral de proteção de dados). Além do armazenamento, a solução pode criar segredos dinâmicos sob demanda, como credenciais de acesso ao AWS.
Então, os riscos de alguém roubar ou por exemplo, ser utilizado por outro cliente, é drasticamente reduzido, pois até a solicitação do usuário a credencial não existia. A solução provê mecanismos nativos para revogar estes segredos dinâmicos, desta maneira, caso desejado, pode ser revogado automaticamente após o término de uso, minimizando o tempo total que o segredo existiu.
A HashiCorp disponibiliza versões do Vault nos maiores sistemas operacionais modernos, como Linux, Windows, MacOs , FreeBSD, NetBSD, OpenBSD e no Solaris. A configuração da ferramenta não será abordada nesse artigo, a instalação é extremamente simples, como mostrado em sua documentação disponibilizada, bastando apenas descompactar o pacote e com um comando, já está pronto para inicializar-lo em modo desenvolvedor.
O Vault não armazena as informações, ele apenas cifra e transfere o armazenamento para seu backend. O backend por sua vez não tem meios para decifrar as informações contidas, dependendo do Vault pra decifrar.
É possível configurar uma série de backends para o Vault, desde soluções mais simples, como memória RAM ou sistemas de arquivos, para soluções mais complexas, como bancos de dados, S3, Google Spanner e Google Storage.
Outra funcionalidade muito importante da solução, são os Secrets Engines. De maneira resumida, são componentes que armazenam, geram ou cifram dados. Para utilização mais simples e familiar, o Vault funciona de maneira similar a um sistema de arquivos.
O secret engine é habilitado em um caminho e o Vault consegue rotear a requisição para o prefixo e transferir para o correto secret engine habilitado.
Os Secrets Engines são extremamente flexíveis, então é mais simples pensar sobre sua função. Normalmente eles recebem algum tipo de dado, tomam alguma ação com estes dados, e então, retornam um resultado.
Existe uma porção de outros Secrets Engines e estes podem ser consultados na documentação provida pela HashiCorp!
Outro recurso semelhante a um sistema de arquivos são as políticas. É possível criar políticas para usuários e ou grupos, permitindo assim controlar quem pode realizar qual tipo de ação em determinado caminho ou registro. Por padrão, todo acesso é bloqueado, conforme necessidade é preciso ser liberado caso a caso.
Na criação de um Vault, ele gera alguns elementos em que é necessário guardar com muito cuidado, estes são o Root_Token e os fragmentos da chave master.
O Root Token é um token com acesso total ao Vault. Ele poderá tomar qualquer tipo de ação nele, então, ele deve ser utilizado apenas para a configuração inicial e após esta fase, outro usuário deve ser criado para o uso do dia a dia. Já os fragmentos da chave mestre, como o nome diz, são fragmentos da chave mestre do Vault.
A chave mestre cifra a chave utilizada pelo Vault, e consequentemente precisamos destes fragmentos para podermos utilizar o Vault. Apenas neste momento que o Vault fornece estes dados, e devem ser mantidos seguros, pois caso estes dados forem perdidos, o acesso ao Vault é perdido.
Os fragmentos da chave mestre são gerados utilizando o algoritmo de Shamir’s Secret Sharing, onde ele pega a chave mestre, cria fragmentos, e por meio destes fragmentos, tendo um threshold mínimo atingido, a chave mestre é recriada.
Algoritmo de Shamir’s Secret Sharing
Outro ponto importante a ser entendido é o ato de Seal e Unseal o Vault. Sempre que o Vault é inicializado ele inicia selado, neste momento, não temos acesso a nenhuma informação e acesso ao Vault. Precisamos desselar o Vault e para isso utilizamos os fragmentos da chave mestre para ela ser recriada. Uma vez com a chave mestre recriada, ele fica no modo “Desselado” permitindo o acesso ao Vault e as informações contidas (depois de ser autenticar).
A autenticação dos usuários pode ser realizada de várias maneiras. É possível configurar o Vault para realizar autenticação interna, seja por usuários/senhas tradicionais ou tokens, ou ainda, usando uma base externa de usuários, como por exemplo uma base LDAP, GitHub , ou usando o Gmail com o OpenID Connect (OIDC).
Neste conceito de Autenticação, uma curiosidade do Vault, foi que mudar o modelo de autenticação via Kerberous, foi uma das grandes inspirações deste novo modelo de acesso proposto pela Hashicorp:
“Terraform” ferramenta para o “Infra-as-code”. E diferencia-se em lidar com múltiplos cloud providers, como Google Cloud, AWS e etc., e tem uma notação bem amigável (HCL — semelhante ao JSON), com aprendizado simples.
Em times multidisciplinares, é comum que o “DevOps” seja o principal responsável pela infraestrutura e manutenção do “Infra-as-code”. Em alguns casos, ele até torna o ambiente em uma “caixa-preta” para os desenvolvedores.
O objetivo da “Infraestrutura como código (Infra-as-code — IaC)” é dar visibilidade do estado da infraestrutura para todos os envolvidos, como operações e desenvolvimento, por exemplo. Essa técnica é considerada uma boa prática para criar e evoluir ambientes e essencial para adoção em qualquer modelo de infraestrutura, seja cloud computing, on-premisses ou qualquer outro.
Terraform
É uma ferramenta para construir, alterar e configurar uma infraestrutura de rede de forma segura e eficiente. Com ele é possível gerenciar serviços de nuvem bem conhecidos, bem como soluções internas personalizadas. Segue a lista de serviços de infraestrutura de nuvem suportados em:
https://www.terraform.io/docs/providers/
Os arquivos de configuração do Terraform descrevem os componentes necessários para executar um único aplicativo ou todo o seu datacenter. Ele pode gerar um plano de execução descrevendo o que ele fará para atingir o estado desejado e, em seguida, ele pode executar as instruções para construir a infraestrutura descrita. Conforme a configuração muda, o Terraform é capaz de determinar o que mudou e criar planos de execução incrementais que podem ser aplicados.
O Terraform trata a infraestrutura como código e dessa forma você pode versioná-lo usando o Git, por exemplo, e ter um backup, fazer rollback em caso de problemas e fazer auditoria à medida que o tempo passa e as alterações vão sendo realizadas no seu ambiente.
Workspaces
Além de otimizar o fluxo de trabalho, criar workspaces facilita a evolução do “infra-as-code”, evita repetição de código e mantém a equivalência entre os ambientes produtivos e não-produtivos.
Terraform não é uma Configuration management tool (Chef / Puppet / Ansible) ou ferramenta de gerenciamento de configuração. Seu foco é a criação dos recursos / infra, enquanto que nessas ferramentas o foco é o bootstraping, ou seja, uma vez que a infra foi criada, essas ferramentas entram em cena para provisionar (instalar e configurar) o ambiente.
O Terraform nasceu com este objetivo em mente. Indo mais além: é multi provider. Tem suporte tanto para aws, Google Cloud, Azure e outros providers, como Cloudflare, SimpleDNS e vários outros.
Terraform é uma simples, poderosa e eficiente ferramenta para a criação e gerenciamento da stack de infraestrutura como código.
Com o Terraform, conseguimos criar/descrever toda a infraestrutura usando uma sintaxe declarativa simples, chamada de Hashicorp Configuration Language.
Por que Terraform?
Os principais motivos que nos fizeram decidir pelo Terraform foram:
- Ter a infraestrutura como código.
- Ser multi provider (podemos criar tanto para AWS, como Google Cloud e Azure)
- Curva de aprendizagem relativamente baixa.
- Sintaxe declarativa.
- Suporte à gama de serviços AWS gigantesca.
E então, quer bater um papo e compartilhar nossos casos de uso?
Lançado em 2014, o Hashicorp Consul foi pensado como uma ferramenta de service discovery e configuração em infraestruturas multi-cloud.
Com ele é possível prover uma comunicação eficiente entre serviços de aplicações tradicionais, VMs, containers ou de orquestradores, de forma simples e automatizada.
Os services meshes costumam ser formados por um plano de controle e um plano de dados. No Consul, o Control Plane faz a proteção da malha, com verificação da integridade, descoberta de serviços e decisões operacionais, enquanto o Data Plane atua na comunicação entre os serviços.
Consul e gestão da malha
A Hashicorp elenca as seguintes features como as principais na gestão da malha:
- Segurança (mTLS e ACLs)
- Observabilidade
- Gerenciamento de tráfego
- Segmentação de redes
- Tratamento de falhas
No nível de rede o serviço de automação de infraestrutura de rede (NIA, em inglês) é fornecido pelo Consul como meio de aplicar dinamicamente atualizações na rede gerenciada.
Há ainda o balanceamento de carga dinâmico: balanceadores como NGINX, F5 e HAProxy podem receber atualizações automaticamente do Consul, sem intervenção manual.
Em termos de malha de serviços, o Consul gerencia o tráfego da camada 7, adota autorização por identidade e encriptação serviço-a-serviço, sendo capaz de permear mais de um datacenter e/ou região, criando a chamada malha de serviços global.
Além disso, a descoberta de serviços do consul fornece um meio de comunicação entre serviços, replicando a informação entre clientes.
Sendo a peça mais recente da HashiStack, a proposta do Nomad é ser um gerenciador e planejador de clusters num cenário de microsserviços. Através de job’s escritos em HCL, o Nomad executa grupos de tarefas que são executadas pelos drivers especificados no job.
Esses drivers podem ser, por exemplo, Docker para containers, Java para aplicações independentes, Qemu para VMs ou exec para aplicativos pré-instalados.
Os casos de uso do Nomad são:
Orquestração de containers (3)
Com suporte aos drivers do Docker, Podman e Singularity, o Nomad possibilita a orquestração de containers de forma simples. No exemplo abaixo é possível ver a descrição de uma task para executar um container do redis, por exemplo.
Orquestração de aplicações não conteinerizadas (4)
Através do empacotamento de binários, o Nomad é capaz de orquestrar aplicações que não estejam conteinerizadas, isolando-as em tempo de execução – e aplicando tratamento de erros automático. Isso fornece maior aproveitamento de recursos, dado que a execução dessa aplicação será gerenciada de forma inteligente pelo Nomad.
Automação de Serviços de Rede – com Consul
Quando instalado em hosts que têm clientes Consul em execução, o Nomad é capaz de reconhecer – através do service mesh outros agentes na mesma rede e com isso formar o cluster automaticamente.
Além dessa facilidade, quando o job é escrito para o uso do Consul Connect, o Nomad cria um proxy junto com a aplicação, fornecendo comunicação segura com os aplicativos no cluste.
Estratégias de Deploy
O Nomad suporta diferentes estratégias de atualização de aplicações em produção, como o canary deploy.
Quando temos duas versões da aplicação, A0.1 e A0.2, temos três momentos: No primeiro apenas a versão A0.1 está ativa, no segundo as versões A0.1 e A0.2 estão ativas, e por fim a versão A0.2 é a única ativa.
O Nomad tem um recurso de job chamado update, com uma flag de canary que seta quantas instâncias com determinada versão devem ser executadas no deploy.
No cenário anterior, o primeiro deploy teria por exemplo 3 instâncias da aplicação A0.1, o segundo criaria 3 instâncias da A0.1 e 3 da A0.2 – e possibilitaria o desvio de tráfego gradativo para a nova versão= e o terceiro apenas 3 da A0.2, desativando a versão passada.
Caso haja uma falha no deploy da segunda versão é possível manter a aplicação A0.1 ativa até a correção.
E então, quer bater um papo e compartilhar nossos casos de uso?
