Remoção do docker.io/Bitnami

• A equipe da Bitnami adiou para 29 de setembro a remoção do catálogo público docker.io/bitnami
• Antes da remoção, serão realizados vários brownouts (bloqueio temporário de algumas imagens) para ajudar os usuários a se adaptar
• Daqui para frente, as imagens de contêiner e charts Helm da Bitnami serão movidos para o Bitnami Secure Images (BSI), com recursos robustos de segurança, ou para o Bitnami Legacy Registry
• As imagens do BSI serão oferecidas gratuitamente para uso em desenvolvimento e testes, mas será necessária uma assinatura paga para acesso ao catálogo completo e suporte de longo prazo
• A mudança é necessária para responder à segurança da cadeia de suprimentos open source e às mudanças regulatórias

---

Cronograma de remoção do catálogo público docker.io da Bitnami e orientações de migração

Atualização

• Após ouvir a comunidade e avaliar o impacto, a equipe da Bitnami adiou para 29 de setembro de 2024 a remoção do catálogo público docker.io/bitnami
• Antes da exclusão do registry, serão realizados 3 brownouts (bloqueio temporário de algumas imagens de contêiner por 24 horas) para que os usuários percebam a mudança
  • 28 de agosto, 08:00 UTC ~ 29 de agosto, 08:00 UTC
  • 2 de setembro, 08:00 UTC ~ 3 de setembro, 08:00 UTC
  • 17 de setembro, 08:00 UTC ~ 18 de setembro, 08:00 UTC
• Em cada brownout, as imagens afetadas serão anunciadas no próprio dia
• A partir de 28 de agosto, a Bitnami deixará de distribuir imagens de contêiner e Helm charts no Docker Hub no novo formato (OCI)
• O código-fonte dos contêineres e dos Helm charts continuará disponível no GitHub sob licença Apache 2.0

O que muda

• A partir de 28 de agosto, a Bitnami moverá o registry OCI existente (charts e imagens) para o Bitnami Legacy e, depois disso, fará a transição para novas imagens com segurança reforçada

• Se você usa as imagens atuais, será necessário alterar para o novo local os caminhos de pull das imagens em pipelines automatizados, mirrors internos e clusters Kubernetes

• Opções disponíveis para os usuários

  1. Migrar para o Bitnami Secure Images (BSI)
  2. Migrar para o Bitnami Legacy Registry (temporariamente)

• Para manter a continuidade e a funcionalidade do sistema, a migração para o Bitnami Secure Images (BSI) é recomendada

• Com o BSI, há a vantagem de melhorar a resposta a requisitos de segurança e compliance por meio de imagens reforçadas

Migração para o Bitnami Secure Images (BSI)

• Algumas imagens do BSI são oferecidas gratuitamente para desenvolvimento e testes, mas o acesso ao catálogo completo, tags estáveis e versões com suporte de longo prazo exige assinatura paga
• Assinantes do BSI continuarão recebendo o catálogo completo de imagens baseadas em Debian da Bitnami e suas atualizações
• Também é recomendada a atualização e migração para imagens baseadas em Photon Linux ainda mais reforçadas
  • Elas são compatíveis com as imagens Debian existentes e os Helm charts podem ser usados da mesma forma
• Principais vantagens das imagens baseadas em Photon
  • Grande redução no número de CVEs (há casos de 100+ para 0)
  • Suporte a diagnósticos VEX e integração com pontuações KEV/EPSS, facilitando o gerenciamento de vulnerabilidades
  • UI/API self-service com recursos robustos de relatórios e metadados
  • Suporte a Helm charts avançados, incluindo charts distroless com 83% menos superfície de ataque
  • Possibilidade de personalizar imagens construídas em uma software factory em conformidade com SLSA 3 (padrão de segurança da cadeia de suprimentos)
  • Fornecimento de registry OCI privado de segurança dedicado ao cliente (sem relação com limites públicos/rate limit do Docker Hub)
  • Disponibilidade de mais de 90 imagens de VM em formato OVA
  • Suporte corporativo para empacotamento e instalação

Migração para o Bitnami Legacy Registry

• Como medida temporária, a Bitnami oferece o Bitnami Legacy Registry para usuários atuais
  • São imagens em formato de arquivo não suportado (sem aplicação de patches de segurança etc.)
  • Não há plano de oferta de longo prazo: existe risco de acúmulo rápido de vulnerabilidades e obsolescência
  • Se for usado temporariamente, recomenda-se copiar as imagens necessárias para um registry próprio
  • No fim das contas, é necessária uma migração rápida para o novo sistema com segurança reforçada (BSI)

Necessidade de transição em segurança da cadeia de suprimentos open source e compliance

• Um dos principais contextos por trás da mudança é a transformação recente do ecossistema open source e o forte aumento de pacotes maliciosos (mais de 245.000 casos entre 2019 e 2023, segundo a Sonatype)
  • Isso equivale ao dobro de todo o período anterior somado
• Com o crescimento do ecossistema de IA/modelos, o uso de open source também aumentou bastante → a superfície de ataque e os riscos também cresceram
• Regulamentações como o Cyber Resilience Act (UE) estão criando uma responsabilidade de comprovação sobre a origem e a integridade do software open source
• Com a adoção do Bitnami Secure Images, a Bitnami passa a oferecer às organizações um ambiente que facilita a implementação de segurança da cadeia de suprimentos e compliance
  • Menor TCO (custo total de propriedade), reduzindo a carga de custos com segurança e regulação
  • Criação de uma base para gerenciar com solidez um ambiente de software open source cada vez mais complexo

Alegações de concorrentes sobre a mudança da Bitnami

• Alguns concorrentes têm induzido ao erro de que a Bitnami estaria "acabando com as imagens públicas gratuitas e os Helm charts"
  • Na prática, os Helm charts continuarão públicos no GitHub sob licença Apache 2
  • O ponto central da mudança está nos artefatos OCI (imagens já construídas)
  • Os custos de operação de pipelines de build/distribuição em larga escala e de registries são muito altos, o que inviabiliza uma oferta de baixo custo
  • O código-fonte dos Helm charts (incluindo imagens Debian) continua acessível gratuitamente a qualquer pessoa
• Empresas que precisarem diretamente de imagens OCI prontas deverão receber esse suporte por meio de uma assinatura do BSI, o que também serve para garantir mais segurança e uso estratégico de OSS

Forma concreta da transição após 28 de agosto

• A partir de 28 de agosto, o repositório da Bitnami começará uma organização por etapas das imagens, e toda a transição não acontecerá de uma vez só
• Ao longo de várias semanas, a exclusão/migração das imagens ocorrerá gradualmente → uma medida para minimizar a confusão dos usuários
  • Devido ao processamento de um volume massivo de conteúdo OCI de 84 TB, não é possível saber com precisão quais imagens serão removidas e quando
  • A partir de 28 de agosto, imagens necessárias para funções críticas de negócio exigirão a preparação de um registry alternativo
• No novo registry da Bitnami, as imagens Photon reforçadas serão publicadas com os mesmos nomes das imagens Debian anteriores
• Usuários atuais e novos usuários poderão responder às exigências do ecossistema open source mais recente por meio de imagens com segurança reforçada
• Mais detalhes sobre a transição podem ser consultados no FAQ da Bitnami

[jic5760]

Para manter o Bitnami dentro da comunidade, ontem criei o Bitmoa.
O objetivo é substituir as imagens do Bitnami com mudanças mínimas (algo no nível de ENV).

https://github.com/bitmoa/containers (build das imagens com GitHub Actions)
https://github.com/bitmoa/charts

[GN⁺]

Comentários do Hacker News

• É meio surpreendente pensar em fazer uma virada comercial no estilo Oracle apenas “empacotando” software público sem contribuir de volta, embora a intenção não seja diminuir o trabalho deles; fica a dúvida sobre quanto disso realmente pode ser objeto de direito autoral, porque na maioria dos casos cada pacote parece só uma receitinha de algumas linhas, quase como tentar reivindicar copyright sobre uma linha de comando tipo make build; e, se a distribuição dos binários é coberta por licença open source, então o usuário deveria ter acesso ao código-fonte, ao método de build e ao direito de redistribuição
  • Os Makefiles e afins criados pela Bitnami são partes que exigiram esforço considerável, e tornar vários softwares utilizáveis só com variáveis de ambiente não é nada trivial; vale ver este exemplo, e para parte do público atual uma licença comercial tem valor suficiente
  • Na prática, o valor mais importante provavelmente está nos Helm charts; mas, como já existem imagens oficiais como substitutas, não há motivo tão forte para usar especificamente as imagens de Node ou Postgres da Bitnami, então fica a dúvida sobre quantas pessoas realmente usavam os Helm charts da Bitnami
• As hardened images que a Bitnami oferecia eram um sinal de goodwill e ajudavam a dar o primeiro passo onde isso era realmente necessário, mas não conseguiam competir no mercado com opções melhores; essa mudança para “subscription” não parece solução, parece quase venda forçada, parecido com o que o Terraform Cloud fez, e por lá também acho que a situação anda ruim; a contribuição da Bitnami no fundo parece se resumir a alguns ajustes de configuração, algo que, pela capacidade do OperatorFramework, mal chega ao nível 2 ou 1 link de referência
  • Acho exagerado chamar de “venda forçada” uma situação em que a Bitnami só deixou de oferecer algo gratuito e agora os usuários precisam buscar substitutos; já é algo pelo qual dá para ser grato
  • Chamar de venda forçada o fato de eles não quererem mais dar algo de graça é uma formulação extrema; no fim só fica a frustração de ter que fazer isso por conta própria agora
  • Parece haver confusão sobre o tipo de empresa que é a Broadcom; a Broadcom não é uma empresa interessada em “saúde de longo prazo”; quando compra um produto, demite 90% dos funcionários e aumenta licenças e suporte em 2 a 100 vezes, explorando o fato de que empresas Fortune 500 não conseguem sair facilmente, para extrair dinheiro por uns 5 anos de contrato; mesmo com reação negativa do mercado, a estratégia é não ligar e, ainda que haja disputa judicial, o efeito final de aumento de preço permanece
  • Em 2025, a estratégia de uma empresa de infraestrutura conquistar primeiro popularidade entre desenvolvedores para depois converter isso em receita não funciona; é preciso gerar receita desde o início, e no fim o único alvo é o mercado enterprise, com todo mundo competindo por esse espaço estreito
  • O valor que eles agregaram é muito pequeno, mas o fato de agora ainda assim ser difícil substituir isso para alguns usuários já é algo em que vale pensar
• No fim, isso também passa por CSR (responsabilidade social corporativa), e é justamente o CSR que torna essa transição possível; a regulação do EU Cyber Residence Act pode mudar bastante o ecossistema open source, porque agora empresas que oferecem comercialmente produtos baseados em open source terão de seguir regras rígidas de segurança e documentação; projetos puramente open source não entram nisso, mas ao distribuir mediante pagamento surge responsabilidade legal, então vender frameworks de compliance como serviço parece ser a nova oportunidade
  • O CSR não obriga necessariamente a fornecer apenas imagens seguras pagas; se quiserem, ainda podem oferecer de graça, ou cobrar só do uso comercial
  • Se a proposta é vender open source mais serviços em uso comercial, então o trabalho de compliance alinhado ao CSR é indispensável; no fim, seja aberto ou comercial, o esforço necessário é o mesmo
• Se for preciso uma alternativa, a equipe da Twistlock lançou o Minimus, que faz builds direto do código-fonte e fornece continuamente imagens com quase nenhuma vulnerabilidade; também oferece substituição drop-in igual à Bitnami; se alguém tiver dúvidas sobre uso, ferramentas ou casos de clientes, perguntas são bem-vindas; vale ver este post de comparação e orientação
  • O formulário de cadastro do Minimus distingue entre "pessoa física" e "organização", mas é estranho exigir o nome da empresa; parece algo feito só para marketing
  • Vou tentar organizar de forma mais fácil de entender, com base no blog, a comparação entre Minimus e Bitnami Secure Images: as Bitnami Secure Images são construídas sobre Photon, e sempre que sai uma vulnerabilidade ou uma nova versão elas são automaticamente buildadas, testadas e publicadas; o usuário só precisa usar a versão mais recente, sem se preocupar com monitoramento de CVE nem com patch manual
  • O maior problema é o preço; eu já perdi o interesse em Chainguard e Docker secure images quando ouvi os valores, e como o preço do Minimus não aparece em lugar nenhum no site, fica a suspeita de que provavelmente seja caro demais para a maioria usar
  • Fico na dúvida se o Minimus é um sistema operacional; a Bitnami continua sendo um projeto open source, então ainda dá para buildar as imagens direto do código-fonte
  • Seria bom se o pessoal do Minimus implementasse um docker-credential helper próprio, tomando como referência o docker-credential-cgr da Chainguard, em vez de só dizer “o Docker suporta credential store, então se virem”; referência
• Pelo que vi do custo da licença, é algo acima de US$ 50.000 por ano, então não é o meu mercado-alvo
  • Na explicação oficial está escrito que o BSI “democratiza” segurança e compliance em open source, mas US$ 50.000 está longe de qualquer ideia de “democratização”
  • A terminologia é confusa, mas na prática estão convertendo para pago várias imagens que antes eram gratuitas; ainda dá para pegar os Dockerfiles e continuar usando imagens do Docker Hub, só que a parte gratuita fica limitada a “desenvolvimento” e não para produção; as imagens realmente “secure” são buildadas sobre Photon OS e passam por processos de segurança, mas não há bloqueio fora do serviço oferecido
  • É a estratégia mais fácil para monetizar uma base de usuários existente deixando-a sem atualizações, o que tem um lado até meio cômico
• Quase dois anos atrás eu recomendei, no ambiente enterprise, sair da Bitnami, e justo agora esse projeto deve estar terminando, então dá uma sensação boa de ter previsto corretamente
• Junto com as mudanças de licenciamento da VMware, parece claro que a Broadcom quer ocupar o lugar da Oracle, o que é uma pena num momento de concorrência cada vez mais acirrada
  • Fico na expectativa (?) de como a Broadcom vai monetizar o ecossistema Spring; praticamente todas as grandes empresas usam Spring, então parece algo inevitável em breve
  • Na prática, a Broadcom de hoje é a Avago Technologies, que comprou só o nome em 2015–2016; a área e a propriedade intelectual da Broadcom original já foram em grande parte vendidas
  • Quando se entende o quão “perversa” a Broadcom pode ser na prática, talvez esse caso nem pareça tão grave assim; ainda assim, no curto prazo pode até haver algum benefício para usuários
  • Parece improvável que muitos dos engenheiros da Bitnami concordem plenamente com esse tipo de decisão
  • Enquanto a Microsoft existir, Broadcom e Oracle ficam competindo pelo 2º lugar no ranking do mal
• Projetos de software acabam sendo compostos apenas de (1) código que você mesmo administra ou mantém pagando por isso, e (2) código descartável que um dia terá de ser substituído por uma versão incompatível; mesmo juntar só esse código descartável ainda pode ser uma aposta inteligente, mas se o código-fonte das dependências vem de terceiros, nunca se deve esperar que eles o mantenham quase para sempre; gestão real de risco é assumir que o ciclo de vida do seu projeto será mais curto que o das dependências
• É uma pena que a Broadcom nem consiga fazer padding decente no mobile; dito isso, se criassem docker.io/bsi separado e deixassem /bitnami como legado, nada quebraria e os usuários poderiam migrar no próprio ritmo, com uma explicação natural de por que não haveria upgrades
  • Se a Bitnami tivesse sinalizado claramente que deixaria de fornecer atualizações de segurança gratuitas, os usuários poderiam ao menos aceitar explicitamente esse risco; depois de aviso prévio suficiente, até mover /bitnami para /bitnamilegacy seria uma forma razoável de fazer isso
  • O próprio nome "bitnami" tem valor de marca, então continuar usando essa nomenclatura ao vender o novo serviço é uma escolha que faz sentido do ponto de vista comercial
  • Esse problema de padding da Broadcom dá a mesma sensação de ver como o design de UI do Rally está ultrapassado
• Não consigo entender as convenções de imagens e pacotes da Bitnami; na prática, achei tudo complexo demais, com regras customizadas bem incômodas, em vez de pacotes simples em cima de uma base comum; a estrutura é estranha e, quando se tenta mudar alguma coisa, vira um caos total
  • Eles ignoraram várias convenções conhecidas e empilharam scripts complexos; para usar qualquer imagem é preciso ler documentação específica, e como isso não bate com a documentação oficial padrão, fica frustrante
  • Houve uma época em que eu usava imagens da Bitnami para conseguir facilmente uma base rodando em modo rootless, porque antes era difícil configurar coisas como Postgres rootless nos repositórios oficiais; o problema é que cada imagem da Bitnami mudava UID, caminho de config etc., então era sempre necessário ler o Dockerfile inteiro
  • A Bitnami era popular originalmente para rodar Wordpress no Windows, porque facilitava usar isso direto no Windows Server; na época isso era útil, ainda que hoje talvez fosse motivo de demissão, mas naquela fase a popularização do Linux foi mais lenta e esse serviço tinha sua utilidade
  • Fico curioso se existe algum recurso de referência para esse tipo de convenção de empacotamento; a impressão é que a prática mais comum é partir das imagens oficiais de cada projeto, customizar conforme necessário e manter imagens próprias