요약
네임스페이스가 맥북 수백 대를 데이터센터 랙에 넣어 macOS 가상머신을 운영하는 방법을 공개했습니다.
개발용 클라우드 플랫폼 네임스페이스의 엔지니어 키릴 니콜라예프가 쓴 글입니다. 1월에 주문한 Mac mini 수백 대가 7월에야 도착하자, 고객에게 최신 맥을 빨리 내주려고 맥북을 랙에 넣기로 했다고 밝혔습니다.
왜 중요한가
- iOS 시뮬레이터와 앱 스토어 배포용 최신 Xcode는 맥에서만 돌아가서, iOS 개발과 코딩 에이전트에는 실제 맥이 꼭 필요합니다.
- 노트북을 서버로 쓰려면 원격 관리와 배선, 디스크 잠금 해제까지 업체가 하나하나 직접 풀어야 한다는 점이 드러났습니다.
핵심 내용
- 애플은 맥 한 대에 macOS VM을 두 개까지만 허용합니다. 그래서 18코어 맥북은 호스트 몫 2코어를 빼고 8코어 VM 두 개로 나눕니다.
- Xcode 베타와 여러 iOS 런타임을 담은 VM 이미지는 500GB까지 커져서, 노드끼리 블록을 나눠 받는 비트토렌트식 배포를 만들었습니다.
- 맥북마다 IP KVM(원격으로 화면과 키보드를 다루는 장치)과 외장 10G 이더넷을 달았고, 가장 말썽인 부품은 쉽게 빠지는 HDMI 케이블이었습니다.
- 예기치 않게 재부팅되면 FileVault 잠금 해제 화면이 5분 만에 사라져, 직접 전원 버튼을 눌러야 했습니다.
- 로컬 SSD는 APFS의 희소 파일(비어 있는 영역을 디스크에 쓰지 않는 파일)과 복제 기능으로 아낍니다.
HN 반응
- 애플이 데이터센터용 맥을 내면 비싸도 팔릴 것이라는 의견이 많았지만, 아이폰에 비해 시장이 작아 애플이 관심을 두지 않는다는 반론도 나왔습니다.
- 다른 맥 호스팅 업체 직원은 Mac mini를 21U 랙에 넣고 이중 전원과 10G 스위치로 운영하는 자사 구성을 자세히 공유했습니다.
대단한 글입니다. 애플 자체의 버그와 한계를 피해 가려고 얼마나 많은 문제를 풀고 있는지 잘 보여 주네요. 애플이 맥 미니와 성능은 같고 가격은 두 배인 새 Xserve를 내놓아도 사람들은 여전히 살 거라고 장담합니다. 데이터센터 운영을 직접 해결하는 데 돈이 많이 들거든요.
제가 듣기로 애플은 지금도 iCloud를 Puppet으로 관리하는, 보안 강화를 하지 않은 데스크톱용 리눅스 배포판에서 돌리고 있습니다. 대부분의 데브옵스 엔지니어가 각자의 ssh 키로 그 전부에 평문 상태의 신과 같은 권한을 갖고 있고요.
호스팅 인프라를 맡기기에 가장 믿으면 안 되는 회사 중 하나입니다.
보안에 관한 대담한 주장이 대개 그렇듯이, 그런 일이 가능하도록 해 주는 수많은 통제 장치는 빼놓고 말씀하시네요.
가축-반려동물 비유군요. 영리합니다!
셸이 있고 opensshd가 돌아가는 서버는 전부 반려동물(pet)이고, 민감한 프로덕션 워크로드 근처에 있을 자격이 없습니다.
거기에 낡고 지독히 안전하지 않은, ssh 기반에 루비로 만든 중앙집중식 인프라 관리 솔루션까지 더해지면, 관련된 모든 사람이 10년 넘게 업계 모범 사례에 대해 졸고 있었다고밖에 결론 내릴 수 없습니다.
프로덕션 서버는 한 번 배포하면 변경할 수 없어야 하고, 언제든 원격으로 증명(attestation)할 수 있어야 하며, 어느 한 명의 관리자도 신뢰하지 않는 정족수 서명 방식으로 비밀을 관리해야 합니다. 모든 워크로드는 커널, reaper, 대상 데몬만 있는 전용 VM에서 돌리고, 그 밑에는 접근할 수 없는 오프라인 기본 OS를 두고, 최초 부팅 이후 시스템이 조금이라도 바뀌면 닫힌 채로 실패하는 TPM 기반 전체 디스크 암호화를 걸어야 합니다.
그리고 이 모두가 최소한입니다. 안타깝게도 태만이 업계 표준인 건, 시스템 하드닝을 정말로 아는 보안 엔지니어가 베이 에어리어에서 극도로 드물기 때문입니다.
사람들은 위협 모델이 무엇인지 정의하지도 않은 채 “민감한 프로덕션 워크로드”에 알맞은 자신만의 “최고 보안” 구성이라며 이런 유행어를 던지기를 좋아합니다.
가장 거슬리는 건 모든 워크로드를 전용 VM에 넣으라는 요구입니다. 성능을 엄청나게 버리는 일이거든요. 어떤 위협 모델이어야 이게 정당화됩니까? 대개는 위협 모델 분석이 아예 없습니다.
opensshd를 금지하는 것도 대체로 어리석은 짓입니다. opensshd가 읽는 authorized_keys 파일을 써 주는 시스템을 설계하는 편이 훨씬 생산적입니다. 예를 들어 내 키가 authorized_keys에 쓰이기 전에 동료의 승인을 요구하는 시스템을 설계할 수 있습니다.
국가 단위 공격자나 최첨단 AI를 쓰는 공격자를 끌어들일 가능성이 있는 서비스라면, 어느 직원이나 워크스테이션 하나도 신뢰하지 않는 위협 모델을 반드시 갖춰야 합니다.
거기서부터는 제가 말한 사양이 저절로 나옵니다. 일단 가동된 시스템은 누구도 변경할 수 없어야 합니다.
새 서버 사양은 서명된 변경으로 정의하고, 서명된 리뷰로 승인하고, 소스에서 결정론적으로 컴파일해 독립적으로 통제되는 여러 시스템이 서명해야 하며 이 시스템들의 결과가 서로 일치해야 합니다. 그런 다음 다시 여러 서명을 받습니다. 그러면 어떤 엔지니어든 그 불변 이미지를 배포할 수 있고, 다른 엔지니어들은 독립적으로 서명된 빌드에서 나온 기대 PCR 값을 원격으로 증명할 수 있습니다. 마지막으로 m-of-n 승인 서명을 검증하는 HSM이 그 머신에 비밀을 내어 줍니다.
이게 제로 트러스트 배포의 기본 요건이고, 다시 말하지만 최소한입니다.
사람이 프로덕션 머신에 직접 ssh로 들어가 명령을 실행하는 건 90년대식 시스템 관리 방식이고, 바로 그래서 바이낸스가 방금 뚫렸고 그 전에도 수천 개 조직이 뚫렸습니다. 생존자 편향은 합리적인 보안 태세가 아닙니다.
그리고 최신 하드웨어에서는 중첩 가상화를 써도 성능 손실이 미미합니다. 워크로드마다 별도 서버를 두는 것도 괜찮고요. 최소한 gvisor 같은 것으로 워크로드를 샌드박싱하세요. 끝없이 나오는 익스플로잇이 보여 주듯 리눅스 커널 네임스페이스로는 부족합니다.
저도 말한 대로 실천합니다. 지난 10년 동안 수천억 달러 규모의 가치를 책임지는 고위험 조직을 위해 이 방식으로 만들어 왔습니다. 다른 사람들이 이 기본 전술을 더 쉽게 따를 수 있도록 https://stagex.tools 를 만들었고 https://distrust.co 와 https://caution.co 도 공동 창업했습니다. 곧 더 많은 소식을 전하겠습니다. 물론 전부 FOSS입니다.
AI로 무장한 초보 해커 군단 속에서 인터넷이 살아남으려면, 이런 전술이 TLS만큼 널리 퍼져야 합니다.
출처가 필요합니다. 검증 가능한 사실이라면 더 듣고 싶네요.
애플은 리눅스를 쓴다고 자랑하지 않습니다. 대단히 좋은 자료라서 누구를 콕 집어 말하지는 않겠지만, 현직·전직 애플 데브옵스/보안 엔지니어들이 자기가 어떤 일을 했는지 적어 둔 이력서를 보면 꽤 많은 걸 알 수 있습니다.
그런 식으로 온갖 회사에 대한 온갖 정보를 얻을 수 있어요.
그래도 그건 전해 들은 얘기일 뿐이잖아요? 제 처음 요지를 다시 말씀드리면, 당신 말에 반대하는 게 아닙니다. 다만 애플의 이런 허술하다는 보안 관행에 대한 문서나 확실한 증거를 보고 싶다는 겁니다.
자기네 허술한 보안 관행을 공개적으로 문서화하는 회사가 어디 있습니까?
그게 업계 전체의 문제입니다. 기준도 없고 책임도 없어요. 돈줄을 쥔 쪽은 마케팅이 되거나 지식재산을 지켜 주는 보안에만 투자합니다. 원격 증명이 가능하고 정족수로 관리된다는 것이 입증되는 시스템에 제대로 투자한 곳이라면 그걸 자랑할 테고, 고객의 신뢰를 얻으려고 기꺼이 증거를 보여 줄 겁니다. 저는 그렇게 합니다.
아무도 이런 걸 한다고 자랑하지 않는다면, 하지 않기 때문입니다. 그저 프로덕션 시스템이나 여러분 노트북에 깔릴 바이너리에서 원하는 코드를 마음대로 실행할 수 있는 신 같은 권한을 쥔 사람들이 우글거리는 겁니다.
내부 관행을 짐작해 보려면, 모두가 지켜보는 공개 환경에서 이들이 뭘 하는지 보면 됩니다.
https://github.com/apple/foundationdb/commits/main/
서명된 커밋도 없고 서명된 리뷰도 없습니다. 머지는 브라우저로 합니다. GitHub API 토큰 하나만 털리면 공급망 공격을 당합니다. 또 최근 사용자 이름 중 하나를 “비밀번호 찾기”에 넣어 보면 하드웨어 2FA를 의무화하지 않는다는 걸 확인할 수 있습니다. 이메일 계정 하나만 뚫리면 아무나로 PR을 올리고, 그걸 애플 계정으로 머지할 수 있습니다. 그러면 애플 내부에서 쓰는 핵심 저장소에 코드가 들어가는 거죠. 게다가 릴리스는 서명도 없고 재현 가능하지도 않으며 그냥 GitHub Actions가 만들어 냅니다. API 키 하나만 더 있으면 훨씬 은밀하게 공격할 수 있습니다.
커뮤니티가 관리하는 웬만한 리눅스 배포판이 이보다 훨씬 잘합니다. 그만한 자원을 가진 조직으로서는 변명할 수 없는 수준입니다.
애플이 공개된 곳에서 공급망 무결성을 이렇게 허술하게 다루는데, 내부에서는 이 중 무엇이라도 한다고 누가 믿겠습니까? 저는 이런 일에 가까운 현직·전직 애플 직원 여러 명과 비공식으로 이야기를 나누기도 했지만, 당연히 누구인지는 밝히지 않겠습니다.
실례지만 제 요점을 놓치고 계신 것 같습니다. 누군가 주장을 내놓으면 그 증거를 대야 할 책임은 주장하는 쪽에 있다는 것을 이해하시길 바랍니다. 특별한 주장에는 특별한 증거가 필요합니다. 저도 어제 오후에 목성에서 온 외계인들이 저를 찾아와 차를 마셨다고 얼마든지 주장할 수 있지만, 당신도 전적으로 동의하기 전에 증거를 보고 싶어 하시겠죠. 다시 말하지만 “평문 신 모드 접근”이 거짓말이라고 생각하는 건 아닙니다. 다만 증거를 보여 주셨으면 하는 겁니다. “그냥 날 믿어”로는 부족합니다.
저는 애플이 널리 의존하는 소프트웨어 라이브러리 최소 하나에서 공급망 보안에 심각한 구멍이 있다는 명확한 공개 증거를 드렸습니다. 애플의 다른 공개 저장소와 코드도 모두 마찬가지고요.
이보다 더 나은 증거가 뭐가 있겠습니까?
그리고 이 스레드에서 자신이 애플 전직 계약직이었다고 밝히며 애플이 Jenkins를 쓴다고 인정한 다른 댓글 작성자도 보세요. Jenkins를요.
위로 스크롤해 보세요. 제가 증거를 요구한 건 정확히 이것입니다. 이건 꽤 심각한 의혹이고, 수많은 사용자에게 미치는 보안상 영향을 생각하면 더 검토해 볼 가치가 있습니다. 솔직히 관련 없는 공개 저장소에서 그들이 하는 일은 다른 맥락에서는 우려스럽지만, 위 주장과는 전혀 상관이 없습니다.
예상보다 공개된 증거를 찾기가 쉬웠습니다.
https://jobs.apple.com/en-us/details/200440680-3337/senior-linux-system-engineer-acs?team=HRDWR
Puppet은 정족수 서명이나 승인을 지원하지 않습니다. 설계상 모든 관리자의 모든 ssh 키를 궁극적으로 신뢰하는 서버 하나가 2005년처럼 ssh로 변조 가능한 레드햇 서버 무리를 변경한다는 뜻입니다.
그래도 공격 체인 하나만 예로 들어 드리죠.
악의적인 자가 애플 엔지니어의 ssh 키 하나를 손에 넣습니다(아니면 그냥 이메일 계정만 있어도 됩니다. 서명하는 게 없으니 키를 잠시 바꿔치기할 수 있습니다).
애플 GitHub에 있는, 프로덕션 서버에서 거의 확실히 쓰이는 애플 핵심 컴포넌트 저장소 중 아무 곳에나 은밀하게 악성 의존성을 심는 PR을 올립니다.
훔친 키로 그 PR을 머지합니다.
코드는 다음 릴리스에 들어가고 결국 애플 프로덕션 서버에 도달합니다. 서명된 게 하나도 없으니 누가 알아차리겠습니까?
우리는 xz 사건에서 아무것도 배우지 못했습니다.
이상적인 건 2U에 맥 미니 8대가 들어가고, 10Gb 이더넷 두 개와 공유 이중 전원 공급 장치가 있고, 진짜 데이터센터용 방열 구조를 갖춘 제품일 것 같아요. 훌륭한 CI 플랫폼이 될 텐데요.
그게 1년에 몇 대나 팔리고, 총매출이 아이폰 매출에 비하면 어느 정도일까요?
그건 쓸모 있는 기준선이 아닙니다. 애플 제품 대부분이 아이폰 매출 근처에도 못 갑니다.
그러니까 애플이 왜 그 시장에 신경 안 쓰는지 알 수 있다는 얘기죠 ㅋㅋ
맥 미니나 맥북보다 마진을 높게 팔 수 있다면 충분히 말이 되죠.
이런 호스팅형 맥 인스턴스의 존재 이유는 사람들이 자기 맥을 사지 않게 돕는 겁니다. 마진이 더 높더라도 그 잠식분을 애플에 보상해 줄 만큼은 되어야 하죠.
꼭 그렇진 않습니다. 이건 주로 어차피 개인 머신이 될 일이 없었던 CI를 돌리는 용도예요. 지금은 개발자가 자기 소프트웨어를 맥에서 자동 테스트하기 어렵게 만들 뿐이고요.
그건 애플이 단독으로 AI에 올인하지 않기로 했을 때 시장의 목소리를 듣지 않았다고 말하는 것과 같습니다.
소비자가 원한다고 생각하는 것만 중요한 게 아닙니다. 납품 능력이나 공급망 관리처럼 더 시급한 다른 요인들이 있고, 이런 것들이 장기적으로 전략에 영향을 줍니다.
내부용 서버를 살 때는 얼마나 절약할 수 있을까요?
사실인지는 모르겠지만, 애플이 맥 미니나 맥 스튜디오 플랫폼을 기반으로 한 미공개 서버 모델을 만들어 특정 고객을 위한 데이터센터에 배치해 뒀다 해도 놀랍지 않을 것 같습니다.
애플이 2024년에 그 서버 설계에 관한 글을 공개했습니다. 맞춤 하드웨어에 맞춤 OS입니다.
https://security.apple.com/blog/private-cloud-compute/
아쉽게도 그 글에는 소프트웨어 이야기밖에 없어요.
있습니다. AI와 프라이빗 클라우드용으로 쓰는 자체 제작 2U 랙 머신이 있어요.
저는 NoMac 클라우드 호스팅에서 일하는데, 저희가 어떻게 하는지 흥미로우실 수도 있겠네요. 간단히 말씀드리면 이렇습니다.
데이터센터에 21U 랙이 있습니다(현재 EU에 2개). 2U 간격으로 MyElectronics 1.25U 스틸 마운트 3개가 들어가고(마운트당 맥 미니 3대, 후면 포트, 아래쪽 흡기를 위해 바닥을 개방, 총 18슬롯), M5 Pro 15코어/24GB/1TB/10GbE인 NoMac Sendbox 호스트 12대가 각각 6vCPU/8GB VM 2개를 돌리고, M5 Pro 48GB인 NoMac Simulator 호스트 4대가 각각 폰 20대쯤을 돌립니다.
전원은 A, B 급전선에 연결된 Netio PowerPDU 8KS 2대(8 × C13, API로 콘센트별 스위칭과 계측 가능)에서 들어옵니다. 호스트는 두 급전선에 고르게 나누고 C14-C7 코드로 연결하며, APC AP4421 트랜스퍼 스위치는 네트워크 장비에만 전원을 공급합니다. 랙의 피크 전력은 약 1.3kW, 평균은 약 0.3kW입니다.
네트워크는 MikroTik RB5009가 유일한 공인 IP를 갖고 아웃바운드 NAT와 인바운드 WireGuard만 처리하고, MikroTik CRS312가 1Gbit/s 업링크 위에서 모든 맥에 10GbE를 제공합니다. VLAN은 세 개로, 관리(PDU, KVM), 호스트(포트 격리로 게이트웨이, R2, 공용 인터넷에만 접근 가능)입니다.
모든 호스트는 FileVault를 끄고 pmset autorestartatconnect 1, autorestart 1, sleep 0으로 구성해 투입하며, 폰 호스트는 자동 로그인을 켜고, hostd를 LaunchDaemon으로 두고, Mosyle로 제로터치 MDM 등록을 하고, 업데이트는 90일 미룹니다.
기본적으로는 이게 전부입니다. 다행히 공급 문제는 없었는데, 저희는 규모가 더 작기도 하죠.
맥용 10G 외장 이더넷으로 추천하실 만한 게 있나요?