OpenTofu ganha criptografia de estado, então o que vem a seguir

Quando o OpenTofu foi anunciado pela primeira vez, um refrão comum da comunidade era: “Se você fornecer criptografia estatal, nós migraremos”. Veja só, o tão aguardado recurso de criptografia de estado foi lançado no OpenTofu v1.7. Recentemente compilamos uma lista de motivos pelos quais agora é a hora de considerar a migração para o OpenTofu, e este é apenas mais um motivo a considerar.

Esta solicitação de recurso está na lista de pendências do Terraform desde 2016, gerando extensas discussões na comunidade sobre sua importância crítica. Dito isto, apesar dos pedidos sinceros para a sua implementação, o recurso não foi entregue em nenhuma versão do Terraform.

Muito ceticismo foi testemunhado quando o OpenTofu foi inicialmente anunciado, com grande parte do feedback da comunidade sendo – e estou parafraseando aqui – “vamos esperar para ver”.

Alcançar o marco do GA foi notável, ocorrendo apenas alguns meses após o anúncio do fork em agosto de 2023. Hoje, estamos orgulhosos de entregar um dos recursos mais esperados que a comunidade Terraform estava esperando – um grande aprimoramento de recurso apenas alguns meses após o Marco do OpenTofu 1.6 GA.

O que é criptografia de estado e por que devo me importar?

Os arquivos de estado no Terraform (e ferramentas semelhantes) geralmente contêm informações confidenciais, incluindo chaves de acesso — que, se não forem criptografadas, representam um risco de segurança significativo.

Quando os arquivos de estado de texto simples não são criptografados como eram até o OpenTofu 1.7, qualquer pessoa com acesso a esses arquivos pode explorá-los, levando a acesso não autorizado e violações de dados. A criptografia desses arquivos de estado protege os dados em repouso e evita o acesso não autorizado. Daniel Grzelak, que inicialmente escreveu o código de criptografia de estado para o Terraform, sublinhou esse ponto durante um episódio recente do meu podcast IaC. Ele compartilha uma experiência em que um arquivo de estado do Terraform em texto simples em um bucket S3 levou a vulnerabilidades de segurança na conta AWS de uma organização.

Este é apenas um exemplo de muitos ataques potenciais ao Terraform. Outros incluem a alteração de referências de recursos em arquivos de estado, levando a exclusões ou modificações não intencionais de recursos, ou a inserção de uma referência de provedor personalizada para executar código malicioso durante a fase do plano do Terraform, comprometendo o pipeline de CI/CD.

Embora a criptografia estatal não possa impedir todos os tipos desses ataques, ela garantirá que os dados sejam lacrados em caso de violação, protegendo as informações confidenciais contidas neles.

Os riscos são agravados quando observamos as permissões excessivas em pipelines de CI/CD em organizações de engenharia modernas, como aquelas usadas em ações do GitHub para implantações do Terraform.

Isso por si só pode expor a infraestrutura sensível ao acesso não autorizado, o que também se deve ao fato de que as equipes de segurança geralmente têm menos envolvimento nos pipelines de CI/CD, fazendo com que desenvolvedores e engenheiros configurem a segurança sem compreensão total, aumentando os riscos de segurança.

É por isso que a criptografia de estado foi uma solicitação de recurso inicial e óbvia no OpenTofu, e sua implementação oferece os benefícios práticos de aumentar a segurança para todos os seus usuários.

A introdução da criptografia de arquivos de estado no OpenTofu fornecerá agora uma camada adicional de segurança destinada a impedir que invasores explorem credenciais de texto simples e deve ser considerada um aspecto fundamental da automação e escalabilidade para mitigar riscos de forma eficaz.

Por que a criptografia de estado não foi entregue antes?

As opiniões variam sobre por que a criptografia de estado nunca foi priorizada nas versões do Terraform. Esta questão foi inclusive objeto de uma discussão recente entre Mitchell Hashimoto, cofundador da HashiCorp e cocriador do Terraform, e Adam Jacob, cofundador do Chef e agora cofundador da System Initiative.

Eu escutei esse! Apenas alguns pontos meus:

Você disse que eu não gostava do Chef! Isso não é verdade e espero nunca ter dito isso. Usei o Chef por pelo menos 3 anos antes de começar a usar o Puppet (e pelo mesmo período de tempo). Você sabe melhor do que ninguém que Chef foi o…

-Mitchell Hashimoto (@mitchellh) 26 de abril de 2024

De acordo com esta discussão, Mitchell Hashimoto observa que o código existente não satisfazia o modelo de ameaça da Hashicorp e permaneceu apodrecido no backlog.

No entanto, a comunidade argumentaria que há especulações de longa data de que a implementação da criptografia estatal canibalizaria o modelo de negócios da Hashicorp.

Ao fornecer criptografia de estado, os arquivos de estado do Terraform poderiam então ser hospedados em qualquer provedor de nuvem, como AWS S3, com muito mais segurança, enquanto o Terraform Cloud – que oferece essa criptografia de estado integrada, era uma oferta comercial primária do lado comercial do código aberto. negócios.

Também é bastante interessante notar que a documentação do Terraform orienta explicitamente os usuários a não criptografarem, apesar de todas as ameaças de segurança conhecidas de deixar arquivos de estado criptografados.

OpenTofu versão 1.7 – Com o que mais podemos ficar entusiasmados?

Como diz o velho ditado “as ações falam mais alto que palavras”, e estamos entusiasmados em ver o OpenTofu cumprir a promessa de evoluir e manter o projeto.

É ainda mais interessante notar que as principais considerações para todo e qualquer desenvolvimento de recursos são orientadas pela comunidade e promovidas pelo modelo hospedado pela fundação.

Isso torna possível que todos os recursos sejam desenvolvidos de uma forma verdadeiramente baseada no mérito e garanta que os recursos enviados sejam aqueles impulsionados pela demanda da comunidade.

Já nas primeiras semanas em que o OpenTofu foi introduzido, o criador do Terragrunt e principal mantenedor do OpenTofu, Yvgeny Brikman, começou a mexer nesta solicitação de recurso de alta demanda para mostrar os esforços proativos para fornecer criptografia de estado. Veja esta postagem no LinkedIn com os primeiros teasers.

No entanto, este é apenas um único recurso em uma lista continuamente limpa e mantida de solicitações de recursos e problemas abertos por nossa crescente comunidade de entusiastas.

Muitos recursos mais populares e de alta demanda estão sendo avaliados e implementados, desde a atribuição de configuração dinâmica do provedor até o suporte a registros OCI, por meio do suporte ao OpenTofu no servidor de linguagem Visual Studio Code.

Você pode acompanhar as solicitações de recursos mais populares no repositório do projeto ou em nossa comunidade Slack (link) e sugerir as suas próprias, se estiver pronto.

Os projetos se reunirão?

Claro, não podemos ignorar o elefante na sala. Em nosso post anterior, onde falamos sobre o 1.6 ser um substituto imediato para o Terraform e como realmente nunca foi tão fácil migrar. Agora é a hora de reconhecer a divergência esperada entre Terraform e OpenTofu. Isto é particularmente verdadeiro com o recente anúncio de aquisição pela IBM.

Desde o anúncio da aquisição, tem havido muita discussão sobre se o OpenTofu e o Terraform se reunirão. O conselho administrativo do OpenTofu acredita que a neutralidade do fornecedor beneficiou enormemente o projeto em sua curta vida. Com uma comunidade forte, crescente e engajada, esperamos que o projeto continue florescendo.

Estamos até vendo sinais iniciais semelhantes ao OpenStack vs. Tendência da AWS para grandes empresas de varejo como Nike, Target e Walmart há alguns anos, que historicamente optaram por hospedar sua infraestrutura com OpenStack e não com a Amazon devido a considerações competitivas.

A Oracle anunciou recentemente sua saída do Terraform e a adoção do OpenTofu para Oracle E-Business Suite (EBS) Cloud Manager, o que pode ser motivado por considerações semelhantes.

Isso não quer dizer que a IBM não será uma boa administradora do Terraform. No mínimo, os temores em torno da aquisição da Red Hat provaram ser infundados, e a IBM demonstrou um impressionante histórico de código aberto até o momento com a Red Hat, juntamente com muitos outros projetos interessantes e inovadores, como IBM Z e LinuxOne.

Ainda assim, o modelo de base também provou ser um forte catalisador para a inovação tão necessária, não apenas para o projeto Terraform, e esta neutralidade do fornecedor parece ser a direção certa para a manutenção e sustentabilidade a longo prazo do projeto.

Estamos apenas começando

A implementação da criptografia de estado no OpenTofu v1.7 marca o primeiro do que esperamos que sejam muitos marcos significativos para este projeto, cujo roteiro reflete a demanda impulsionada pela comunidade para o desenvolvimento contínuo do projeto.

Este recurso foi criado para aprimorar a segurança do OpenTofu, protegendo dados confidenciais em arquivos de estado contra acesso não autorizado e possíveis violações, abordando uma vulnerabilidade crítica.

Isto demonstra o compromisso da OpenTofu com o desenvolvimento orientado para a comunidade e a entrega rápida de funcionalidades, onde esta atualização não só cumpre um requisito de segurança crucial, mas também reforça a dedicação da plataforma em evoluir de acordo com as prioridades dos utilizadores. À medida que o OpenTofu continua a divergir do Terraform, promete um futuro robusto e seguro, com foco na inovação impulsionada pela comunidade.

Se você está entusiasmado com a criptografia de estado e os outros recursos que planejamos, convidamos você a se juntar à nossa crescente comunidade, contribuir com ideias e começar a explorar o OpenTofu.

A postagem OpenTofu ganha criptografia de estado, então o que vem a seguir apareceu pela primeira vez em The New Stack.