Bottlerocket - 검증된 부팅을 가진 최소한의 불변 Linux OS

 (bottlerocket.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Bottlerocket은 컨테이너 호스팅에 맞춘 Linux 기반 OS로, Kubernetes 같은 오케스트레이터가 관리하는 클러스터 워커 노드의 기본 운영체제로 쓰임
  • 범용 배포판의 패키지, 도구, 인터프리터를 덜어낸 최소 구성으로 운영 부담과 공격 표면을 줄이고, 환경별 variant로 필요한 조합만 제공함
  • 셸과 패키지 관리자를 두지 않고, 권한 있는 host 컨테이너와 API로 시스템을 다루며 업데이트는 이미지와 파티션 전환으로 원자적으로 적용됨
  • 설정은 API 기반으로 관리되어 버전 간 마이그레이션과 롤백이 가능하고, 업데이트 관리는 수동 또는 오케스트레이터별 도구로 처리할 수 있음
  • 불변 루트 파일시스템, dm-verity, 제한적 SELinux, Rust와 일부 Golang 구현을 통해 시스템 변조와 검증되지 않은 코드 실행 경로를 줄임

컨테이너 클러스터용 기본 OS

  • Bottlerocket은 컨테이너 호스팅에 최적화된 Linux 기반 운영체제임
    • 무료 오픈소스 소프트웨어이며 GitHub에서 공개 개발됨
    • 컨테이너가 실행되는 머신이나 인스턴스의 기본 운영체제로 설치됨
    • Kubernetes 같은 컨테이너 오케스트레이터와 함께 동작하도록 설계되어, 클러스터 안의 컨테이너 수명주기 자동화를 지원함
    • 클라우드와 데이터센터에서 실행 가능함
  • 설계 목표는 Minimal, Safe Updates, Security Focused 세 가지로 정리됨

최소 구성과 환경별 variant

  • 컨테이너 호스팅만 목표로 하므로 범용 Linux 배포판에 기본 포함되는 많은 패키지, 도구, 인터프리터, 의존성을 제거함
    • 불필요한 소프트웨어가 줄어들어 운영 오버헤드와 보안 오버헤드도 함께 낮아짐
  • 다양한 오케스트레이터, 플랫폼, 아키텍처 요구사항은 호환 조합별 빌드인 variant로 관리됨
    • variant는 특정 환경에서 실행하는 데 필요한 요소를 조립한 형태임
    • 적절한 variant를 선택하면 클러스터에 조인하는 데 추가 요소가 필요하지 않음
  • Bottlerocket 자체에는 셸이 없음
    • 시스템 접근은 셸이 있는 권한 있는 host 컨테이너를 통해 가능함
    • host 컨테이너에서는 기반 OS를 탐색하고 API로 실행 중인 시스템 설정을 변경할 수 있음

이미지 기반 안전 업데이트

  • Bottlerocket은 업데이트 가능하도록 설계됐지만 패키지 관리자를 포함하지 않음
  • 업데이트는 특정 파티션으로 다운로드되는 이미지로 전달됨
    • 업데이트 시 오케스트레이터가 노드를 drain한 뒤 Bottlerocket에 업데이트 적용과 재부팅을 지시함
    • Bottlerocket은 파티션을 교체하고 새 버전으로 원자적으로 부팅함
  • 시스템 설정은 API로 관리되어 Bottlerocket이 버전 간 설정 마이그레이션을 처리할 수 있음
    • 업데이트 중 문제가 생기면 설정을 유지한 채 이전에 동작하던 버전으로 되돌릴 수 있음
  • 업데이트 관리는 수동으로 하거나 오케스트레이터별 도구를 사용할 수 있음

보안 중심 설계

  • 최소 구성과 업데이트 방식은 Bottlerocket의 보안 중심 설계를 뒷받침함
  • variant가 이미지로 전달되므로 시스템을 변경해 보안 문제를 만들 수 있는 패키지 레지스트리나 관리자가 필요하지 않음
  • Bottlerocket의 고유 기능은 Rust와 일부 Golang으로 작성됨
    • 두 언어는 컴파일 언어이며 메모리 안전 문제에 대한 내장 보호를 제공함
    • 모든 코드가 미리 컴파일된 이미지로 전달되어 셸과 인터프리터가 필요하지 않고, 검증되지 않은 코드 실행 경로가 줄어듦
  • 루트 파일시스템은 불변임
    • dm-verity가 루트 파일시스템의 투명한 무결성 검사를 제공함
    • 기반 블록 디바이스 변경이 감지되면 커널이 재시작함
  • 변경 가능한 파일시스템에는 항상 활성화되고 강제되는 제한적 SELinux 정책이 적용됨
    • 컨테이너가 root로 실행되더라도 위험한 작업을 실행하지 못하도록 돕는 정책임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여전히 AWS/Amazon 프로젝트 성격이 강하고, 독립적인 프로젝트가 될 경로는 뚜렷하지 않아 보임
    예를 들어 OS 취약점 스캔이 필요하면 Amazon 제품을 쓰면 되고, 아니면 방법이 애매함 https://bottlerocket.dev/en/faq/#4_2
    Bottlerocket을 AWS에서만 돌릴 생각이면 괜찮겠지만, 웹사이트에서 말하는 것처럼 “클라우드나 데이터센터에서 실행”되는 제품이 되려면 이런 부분을 해결해야 함

    • 공정하게 보면 Flatcar / BottleRocket / CoreOS 같은 OS에서의 취약점 관리는 RHEL 같은 전통적 OS와 같은 방식으로 필요하진 않다고 봄
      패치 여부를 알고 싶다면 최신 버전을 돌리고 있는지만 보면 되고, 최신이면 사용 가능한 패치는 모두 적용된 상태임
      다만 규제 산업에서는 컴플라이언스 체크리스트에 “취약점 관리” 항목을 채워야 해서 문제가 될 수 있음
      전통적 OS에서 취약점 관리가 필요한 큰 이유는 구성 공간이 매우 넓고, 소프트웨어 구성이 여러 출처와 공급업체에서 임의로 섞이며 각 버전이 독립적으로 움직이기 때문임
      하지만 컨테이너 OS는 그렇게 쓰는 물건이 아님
      “latest”에서 취약점을 추가로 찾아내는 일은 시스템 소유자가 제때 업스트림 패치를 적용하는 일이 아니라 보안 연구자의 일에 가까움
    • AWS가 아닌 걸 찾는다면 Talos도 볼 만함 https://www.talos.dev/
      Bottlerocket보다 더 오래된 프로젝트임
    • 취약점 스캔 자체를 막는 건 아니지 않나 싶음
      SSM으로 들어가거나 admin 컨테이너를 써서 스캔을 실행하는 방식이 있다면, 같은 식으로 할 수 있지 않을까 하는 순수한 질문임
    • 불변 OS 이미지에 호스트에서 취약점 스캔이 왜 필요한지 모르겠음
      이미지를 호스트 머신에 배포하기 전에 하면 되는 일임

  • Bottlerocket은 대부분의 엔터프라이즈 *nix 배포판과 달리 FIPS 모드를 제공하지 않음
    업무용 호스트 OS에 FIPS 승인 암호화가 필요한 컴플라이언스 프로그램을 쓰는 사람이라면 시간을 아끼기 바람
    이 때문에 우리에겐 Bottlerocket이 선택지가 아니고, 관련 이슈는 2년 넘게 활발히 열려 있지만 개발팀은 중요하다고 확신하지 않는 듯함
    AWS 전담 담당자를 통해 개발팀과도 이야기했지만 추가할 의지가 없어 보였음
    2년 넘게 열린 스레드는 여기임: https://github.com/bottlerocket-os/bottlerocket/issues/1667

    • 공개: Amazon에서 일하고 있으며 Bottlerocket의 수석 엔지니어임
      FIPS 지원은 여전히 고객 요청 중 압도적인 1순위임
      다만 이전 FIPS 제공 이력이 없는 새 배포판에는 시기가 좋지 않음
      신규 FIPS 140-2 인증은 더 이상 받을 수 없고, 신규 FIPS 140-3 인증은 업계 전체가 전환 중이라 긴 대기열을 거쳐야 함
      개발팀이 밀어붙여서 해결할 수 있는 일이었다면 이미 됐을 것임
      중요하지 않다는 인상을 줬다면 사과하고, 실제로 중요하지만 이 경우 일정에는 도움이 되지 않음
    • FIPS 인증은 보통 보안을 약화시키는 변경을 요구하는 경우가 많았음
      필요하면 어쩔 수 없지만, 인증이 있다는 건 개인적으로는 약간 나쁜 신호라고 봄
      이런 생각은 혼자만의 생각이 아니고, Microsoft Windows 팀도 비슷하게 보는 듯함: https://techcommunity.microsoft.com/t5/microsoft-security-ba...
    • “FIPS는 ‘모든 암호화 소프트웨어를 정부 위원회 승인 대상으로 강제하려면 어떻게 해야 하나?’라는 질문의 답”임 https://twitter.com/matthew_d_green/status/41279364233232384...
      FIPS 자체가 악하지 않더라도, 악한 사람들과 악한 환경에서 움직인다는 점은 기억해야 함 https://threadreaderapp.com/thread/1433451378391883782.html

  • 매우 흥미로워 보이지만, 다른 댓글들처럼 직접 실행하는 경로가 흐릿해 보임
    GitHub 페이지도 메인 페이지에만 올라와 있음
    VMware 안내는 여기서 찾았음: https://github.com/bottlerocket-os/bottlerocket/blob/develop...

  • CoreOS의 방향성과 매우 비슷함 https://fedoraproject.org/coreos/

    • 그리고 CoreOS에서 파생된 Flatcar Linux도 있음 https://www.flatcar.org/
    • 멍청한 질문일 수 있지만, Alpine 같은 대안 대비 CoreOS의 장점이 무엇인지 궁금함
    • Bottlerocket이 업데이트에 쓰는 A/B 파티션 방식과 ostree는 어떻게 비교되는지 궁금함

  • “Get Started”나 FAQ 어디에도 실행 방법이 나오지 않음

  • 좋은 프로젝트지만 2020년부터 있던 것임: https://aws.amazon.com/about-aws/whats-new/2020/08/announcin...

  • AWS 밖에서 이걸 성공적으로 쓰는 사람이 있는지 궁금함

    • 단일 사례지만, Hetzner Cloud에서는 동작시키지 못했음

  • AMD SEV-SNP 같은 용도에 꽤 유용해 보임
    머신의 특정 동작을 보장하려면 커널 + initrd + 인자에 대한 측정값이 필요하기 때문임
    이상적으로는 이걸 컨테이너 하이퍼바이저로 쓰고, 실행 중인 컨테이너의 해시에 묶인 증명을 생성할 수 있으면 좋겠음
    다만 컨테이너 탈출이 없어야 하는데, 이 분야의 최신 상태가 지금 어떤지는 잘 모르겠음

  • 차라리 CoreOS를 쓰고 싶음
    AWS 밖에서 널리 쓰이는 오픈소스를 이들이 내놓은 게 있나?

  • 웹사이트에는 OS에 셸이 없다고 되어 있음
    적어도 셸 스크립트 하나 없는 유용한 Docker 컨테이너는 상상하기 어려움
    그렇다면 셸이 없다는 건 Bottlerocket이 일부 틈새 시나리오를 제외하면 대체로 쓸 수 없다는 뜻 아닌가?

    • Docker 컨테이너 안에는 셸 스크립트가 있을 수 있음
      셸이 없는 건 호스트 머신이고, 셸이 들어 있는 Docker 컨테이너를 가져와 권한 있게 실행하면 호스트에서 셸을 쓸 수 있음
    • 셸 스크립트를 포함한 컨테이너는 셸 자체도 함께 포함
      호스트 머신의 셸 바이너리를 호스트에서 실행 중인 컨테이너에 제공하는 방식은 일반적이지 않음
    • Bottlerocket의 아이디어는 호스트 자체에 직접 셸도 없고 SSH나 다른 방법으로 접근하는 경로도 없다는 것임
      대신 이 책임을 admin 컨테이너에 위임하고, 실제 접속은 SSM/SSH로 거기에 하게 됨
      여기서 루트 셸이 필요하면 sheltie 유틸리티를 쓰면 됨
    • 보안 이유로 셸 없는 Docker 컨테이너를 쓰는 건 드문 일이 아님
      예를 들면 distroless가 있음
    • 하위 시스템 구조를 그리면 이렇고, Bottlerocket에는 컨테이너 안의 셸에서 호출할 수 있는 API가 있음
      shells | containers | Bottlerocket | OS kernel
답변달기