Bottlerocket - um Linux OS mínimo e imutável com boot verificado
(bottlerocket.dev)- Bottlerocket é um sistema operacional baseado em Linux voltado para hospedagem de contêineres, usado como sistema operacional base para nós workers de clusters gerenciados por orquestradores como o Kubernetes
- Com uma configuração mínima que remove pacotes, ferramentas e interpretadores típicos de distribuições de uso geral, reduz a carga operacional e a superfície de ataque, oferecendo apenas as combinações necessárias por meio de variants específicas para cada ambiente
- Não inclui shell nem gerenciador de pacotes; o sistema é operado por contêineres de host com privilégios e por uma API, e as atualizações são aplicadas de forma atômica com imagens e troca de partições
- As configurações são gerenciadas via API, permitindo migração entre versões e rollback, e o gerenciamento de atualizações pode ser feito manualmente ou com ferramentas específicas de cada orquestrador
- O sistema de arquivos raiz imutável, dm-verity, SELinux restritivo, e a implementação em Rust com algumas partes em Golang reduzem a adulteração do sistema e os caminhos de execução de código não verificado
OS base para clusters de contêineres
- Bottlerocket é um sistema operacional baseado em Linux otimizado para hospedagem de contêineres
- É software livre e de código aberto, desenvolvido publicamente no GitHub
- É instalado como o sistema operacional base das máquinas ou instâncias em que os contêineres são executados
- Foi projetado para funcionar com orquestradores de contêineres como o Kubernetes, dando suporte à automação do ciclo de vida dos contêineres dentro de um cluster
- Pode ser executado na nuvem e em datacenters
- Os objetivos de design se resumem em três pontos: Minimal, Safe Updates e Security Focused
Configuração mínima e variants por ambiente
- Como o foco é apenas hospedagem de contêineres, remove muitos pacotes, ferramentas, interpretadores e dependências que normalmente vêm por padrão em distribuições Linux de uso geral
- Com menos software desnecessário, também diminuem a sobrecarga operacional e a sobrecarga de segurança
- Requisitos de diferentes orquestradores, plataformas e arquiteturas são gerenciados por variants compiladas para cada combinação compatível
- Uma variant é um conjunto montado com os elementos necessários para rodar em um ambiente específico
- Ao escolher a variant adequada, não é necessário nenhum componente adicional para entrar no cluster
- O Bottlerocket em si não tem shell
- O acesso ao sistema é possível por meio de contêineres de host com privilégios e shell disponível
- Nesses contêineres de host, é possível explorar o sistema operacional subjacente e alterar a configuração do sistema em execução via API
Atualizações seguras baseadas em imagem
- O Bottlerocket foi projetado para ser atualizável, mas não inclui gerenciador de pacotes
- As atualizações são distribuídas como imagens baixadas para uma partição específica
- Durante a atualização, o orquestrador drena o nó e depois instrui o Bottlerocket a aplicar a atualização e reiniciar
- O Bottlerocket troca a partição e inicializa atomicamente na nova versão
- A configuração do sistema é gerenciada por API, permitindo que o Bottlerocket cuide da migração de configurações entre versões
- Se surgir algum problema durante a atualização, é possível voltar para a versão anterior que funcionava, mantendo a configuração
- O gerenciamento de atualizações pode ser feito manualmente ou com ferramentas específicas de cada orquestrador
Design com foco em segurança
- A configuração mínima e a forma de atualização sustentam o design com foco em segurança do Bottlerocket
- Como as variants são entregues como imagens, não há necessidade de registro de pacotes nem gerenciador que possa modificar o sistema e criar problemas de segurança
- Os recursos próprios do Bottlerocket são escritos em Rust e parcialmente em Golang
- Ambas são linguagens compiladas e oferecem proteções embutidas contra problemas de segurança de memória
- Todo o código é entregue em imagens pré-compiladas, dispensando shell e interpretadores e reduzindo os caminhos de execução de código não verificado
- O sistema de arquivos raiz é imutável
- O dm-verity fornece verificação transparente de integridade do sistema de arquivos raiz
- Se uma alteração no dispositivo de bloco subjacente for detectada, o kernel reinicia
- Nos sistemas de arquivos graváveis, aplica-se uma política restritiva de SELinux, sempre ativa e obrigatória
- Essa política ajuda a impedir que contêineres executem operações perigosas, mesmo quando rodam como root
1 comentários
Opiniões do Hacker News
Ainda parece ter um caráter forte de projeto da AWS/Amazon, e não parece haver um caminho claro para se tornar um projeto independente
Por exemplo, se você precisar de varredura de vulnerabilidades do OS, basta usar um produto da Amazon; caso contrário, o caminho fica meio ambíguo https://bottlerocket.dev/en/faq/#4_2
Se a ideia for rodar o Bottlerocket apenas na AWS, tudo bem, mas para virar um produto que “roda na nuvem ou em datacenters”, como o site diz, esses pontos precisam ser resolvidos
Se quiser saber se há patches aplicados, basta verificar se você está rodando a versão mais recente; se estiver, todos os patches disponíveis já foram aplicados
Porém, em setores regulados, isso pode ser um problema porque é preciso preencher o item “gestão de vulnerabilidades” nas listas de verificação de compliance
Um dos grandes motivos pelos quais a gestão de vulnerabilidades é necessária em sistemas operacionais tradicionais é que o espaço de configuração é muito amplo, e a composição de software mistura arbitrariamente várias fontes e fornecedores, com cada versão evoluindo de forma independente
Mas um OS para contêineres não é algo usado dessa maneira
Encontrar vulnerabilidades adicionais no “latest” está mais próximo do trabalho de pesquisadores de segurança do que do trabalho do proprietário do sistema de aplicar patches upstream em tempo hábil
É um projeto mais antigo que o Bottlerocket
Pergunta sincera: se houver uma forma de entrar via SSM ou usar um contêiner admin para executar a varredura, não daria para fazer do mesmo jeito?
Isso é algo que pode ser feito antes de implantar a imagem na máquina host
O Bottlerocket, ao contrário da maioria das distribuições *nix empresariais, não oferece modo FIPS
Se você usa um programa de compliance que exige criptografia aprovada pelo FIPS no OS host de produção, poupe seu tempo
Por isso, o Bottlerocket não é uma opção para nós, e embora a issue relacionada esteja aberta e ativa há mais de 2 anos, a equipe de desenvolvimento parece não estar convencida de que isso seja importante
Também conversamos com a equipe de desenvolvimento por meio do nosso contato dedicado na AWS, mas eles não pareceram dispostos a adicionar isso
A thread aberta há mais de 2 anos está aqui: https://github.com/bottlerocket-os/bottlerocket/issues/1667
O suporte a FIPS ainda é, de longe, a solicitação nº 1 dos clientes
Mas o momento não é bom para uma nova distribuição sem histórico anterior de oferta de FIPS
Novas certificações FIPS 140-2 não podem mais ser obtidas, e novas certificações FIPS 140-3 precisam enfrentar uma longa fila enquanto todo o setor faz a transição
Se fosse algo que a equipe de desenvolvimento pudesse simplesmente forçar e resolver, já teria sido feito
Peço desculpas se passamos a impressão de que isso não é importante; de fato é importante, mas, neste caso, isso não ajuda no cronograma
Se você precisa dela, não há muito o que fazer, mas, pessoalmente, vejo a existência da certificação como um sinal um pouco ruim
Não sou o único a pensar assim; a equipe do Microsoft Windows parece ver de forma parecida: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
Mesmo que o FIPS em si não seja maligno, é bom lembrar que ele opera com pessoas mal-intencionadas e em ambientes ruins https://threadreaderapp.com/thread/1433451378391883782.html
Parece muito interessante, mas, como outros comentários disseram, o caminho para executar por conta própria parece pouco claro
A página do GitHub também só aparece na página principal
Encontrei as instruções para VMware aqui: https://github.com/bottlerocket-os/bottlerocket/blob/develop...
É muito parecido com a direção do CoreOS https://fedoraproject.org/coreos/
Em nenhum lugar do “Get Started” ou do FAQ aparece como executar
É um bom projeto, mas existe desde 2020: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...
Fico curioso para saber se há alguém usando isso com sucesso fora da AWS
Parece bastante útil para casos como AMD SEV-SNP
Porque, para garantir um determinado comportamento da máquina, é preciso ter medições do kernel + initrd + argumentos
Idealmente, seria bom usar isso como hipervisor de contêineres e conseguir gerar uma atestação vinculada ao hash do contêiner em execução
Só que não pode haver escape de contêiner, e não sei bem qual é o estado da arte nessa área hoje
Eu preferiria simplesmente usar CoreOS
Eles já lançaram algum open source amplamente usado fora da AWS?
O site diz que o OS não tem shell
É difícil imaginar um contêiner Docker útil que não tenha pelo menos um script de shell
Então, o fato de não ter shell não significa que o Bottlerocket é, em geral, inutilizável exceto em alguns cenários de nicho?
Quem não tem shell é a máquina host; se você trouxer um contêiner Docker que contenha shell e executá-lo com privilégios, pode usar um shell no host
Não é comum fornecer o binário de shell da máquina host para um contêiner em execução no host
Em vez disso, essa responsabilidade é delegada ao contêiner admin, e o acesso real é feito nele via SSM/SSH
Se você precisar de um shell root ali, pode usar o utilitário
sheltieUm exemplo é o distroless
shells | containers | Bottlerocket | kernel do OS