20 năm làm việc trên AWS và chưa bao giờ là công việc của tôi

Tôi đã tạo tài khoản AWS đầu tiên của mình lúc 10:31 tối ngày 10 tháng 4 năm 2006. Tôi đã có nhìn thấy thông báo của Amazon S3 và đã suy nghĩ mơ hồ về vấn đề sao lưu an toàn — mặc dù tôi chưa bắt đầu Tarsnap cho đến vài tháng sau này — và ý tưởng về dịch vụ lưu trữ trực tuyến đã hấp dẫn tôi. Việc nó là một dịch vụ web khiến nó càng trở nên hấp dẫn hơn; tôi đã có đã xây dựng các dịch vụ web từ năm 1998, khi tôi quyết định rằng việc phối hợp lập kỷ lục thế giới việc tính toán Pi qua HTTP sẽ dễ dàng hơn việc tính toán lại email.

Mặc dù tôi tạo tài khoản AWS vì tôi quan tâm đến Amazon S3, thực tế điều đó không có sẵn ngay lập tức đối với tôi: Trong những ngày đầu của AWS, bạn phải yêu cầu cụ thể từng dịch vụ mới được bật cho tài khoản của bạn. Tài khoản AWS mới của tôi có hai dịch vụ được kích hoạt bởi mặc dù vậy, mặc định — Amazon Simple Queue Service, dịch vụ mà hầu hết mọi người được gọi là "dịch vụ AWS đầu tiên" và Dịch vụ thương mại điện tử Amazon, một API cho phép các chi nhánh của Amazon truy cập vào danh mục sản phẩm của Amazon.com — đó là dịch vụ AWS thực đầu tiên, nhưng hầu hết mọi người chưa bao giờ nghe đến và đã bị xóa khỏi AWS một cách lặng lẽ lịch sử.

Nó không mất nhiều thời gian trước khi tôi bắt đầu phàn nàn về mọi thứ. Bằng cách này điểm tôi là Nhân viên Bảo mật FreeBSD, vì vậy mối quan tâm đầu tiên của tôi với mọi thứ trên đám mây đều là bảo mật. Yêu cầu AWS được ký bằng khóa API cung cấp cả xác thực và bảo vệ tính toàn vẹn - xác nhận không chỉ người dùng được ủy quyền mà còn yêu cầu không bị giả mạo. Tuy nhiên, có không có chữ ký tương ứng trên AWS câu trả lời — và tại thời điểm này hiện nay việc thực hiện các yêu cầu AWS qua HTTP vẫn rất phổ biến thay vì HTTPS nên khả năng giả mạo phản hồi là rất thực tế. Tôi không nhớ có ai từ Amazon tỏ ra quan tâm khi tôi đăng không về điều này trên Diễn đàn nhà phát triển AWS (đã biến mất từ lâu), nhưng tôi vẫn nghĩ rằng đó sẽ là một điều tốt nếu có: Với các yêu cầu vượt qua TLS, nó là rõ ràng là bây giờ ít quan trọng hơn, nhưng việc ký kết từ đầu đến cuối luôn diễn ra tốt hơn so với bảo mật lớp vận chuyển.

Tất nhiên, ngay khi Amazon EC2 ra mắt, tôi đã có mục tiêu mới: Tôi muốn để chạy FreeBSD trên đó! Tôi đã liên hệ với Jeff Barr qua blog của anh ấy và anh ấy giúp tôi liên lạc với mọi người trong Amazon và vào đầu năm 2007 tôi đã có NDA đầu tiên của Amazon. (Chuyện buồn cười, năm 2007 Amazon vẫn còn sử dụng fax máy móc — nhưng tôi không có máy fax, nên cuộc họp đầu tiên của tôi đã bị trì hoãn trong khi tôi gửi chữ ký bằng mực ướt xuống Seattle.) Trong số các tính năng mà tôi đã được giới thiệu là "Hạt nhân tùy chỉnh"; giống như thế nào AWS Lambda hoạt động ngày hôm nay, Amazon EC2 đã ra mắt mà không có bất kỳ "mang theo của riêng bạn" hỗ trợ hạt nhân". Rõ ràng, để hỗ trợ FreeBSD cho EC2, tôi đã sẽ cần sử dụng chức năng này và nó đã ra mắt vào tháng 11 2007 khi Amazon EC2 có khả năng chạy Red Hat; ngay sau đó thông báo được đưa ra, tài khoản FreeBSD của tôi đã được đưa vào danh sách cho phép API "xuất bản hình ảnh hạt nhân Amazon" nội bộ.

Nhưng tôi đã không đợi chức năng này được cung cấp trước khi cung cấp thêm phản hồi về Amazon EC2. Vào tháng 3 năm 2007, tôi đã bày tỏ mối quan ngại với một người Amazon về tính bảo mật của Xen — vào thời điểm đó vẫn một hệ thống khá mới và Amazon là công ty đầu tiên triển khai nó một cách thực sự môi trường thù địch - và khuyến khích họ thuê người làm kiểm tra bảo mật kỹ lưỡng của mã. Khi người Amazon tôi đang nói phải thừa nhận rằng họ không biết nên thuê ai cho việc này, tôi đã nghĩ về những người tôi đã làm việc cùng trong thời gian làm Nhân viên An ninh FreeBSD và đã giới thiệu Tavis Ormandy cho họ. Cuối năm đó, Tavis được ghi nhận với việc báo cáo hai lỗ hổng trong Xen (CVE-2007-1320 và CVE-2007-1321); liệu có mối liên hệ nào giữa những sự kiện đó không, tôi không biết.

Tôi cũng đã đề cập - thực tế là tại một trong những cuộc gặp gỡ người dùng AWS của Jeff Barr trong Cuộc sống thứ hai - rằng tôi muốn có một cách để phiên bản EC2 có thể được khởi chạy với đĩa gốc chỉ đọc và đảm bảo xóa sạch tất cả bộ nhớ khi khởi động lại, để cho phép một phiên bản được "thiết lập lại" vào một trạng thái được biết đến là tốt; trường hợp sử dụng dự định của tôi cho việc này là xây dựng Các gói FreeBSD vốn dĩ liên quan đến việc chạy không đáng tin cậy (hoặc tại ít nhất là mã không đáng tin cậy). Phản ứng ban đầu từ người dân Amazon là hơi bối rối một chút (tại sao không chỉ gắn hệ thống tập tin ở chế độ chỉ đọc) mà khi tôi giải thích rằng mối quan tâm của tôi là về việc bảo vệ chống lại những kẻ tấn công đã khai thác hạt nhân cục bộ, họ hiểu trường hợp sử dụng. Tôi đã rất vui mừng khi Chứng thực phiên bản EC2 ra mắt 18 năm sau.

Tôi kết thúc năm 2007 bằng một bài đăng trên blog mà tôi được biết là đã được đọc khá nhiều trong Amazon: Amazon, Dịch vụ web và Sesame Street. Trong bài viết đó tôi đã phàn nàn về vấn đề về tính nhất quán cuối cùng và tranh luận về một sự mạnh mẽ hơn một chút mô hình: Tính nhất quán đã biết cuối cùng, vẫn đưa ra lộ trình "A" của định lý CAP, nhưng thể hiện đủ trạng thái bên trong để người dùng có thể cũng đạt được điểm "C" trên con đường hạnh phúc. Amazon S3 cuối cùng đã chuyển từ trạng thái tồn tại được tối ưu hóa cho Tính khả dụng để được tối ưu hóa cho Tính nhất quán (trong khi vẫn có tính sẵn sàng cực cao) và tất nhiên DynamoDB là nổi tiếng vì cho người dùng lựa chọn giữa Cuối cùng hoặc Mạnh mẽ đọc nhất quán; nhưng tôi vẫn nghĩ mô hình của Last Known Tính nhất quán là mô hình lý thuyết tốt hơn ngay cả khi nó khó khăn hơn cho người dùng lý do về.

Đầu năm 2008, Kip Macy đã nhận được FreeBSD hoạt động trên Xen với PAE — trong khi FreeBSD là một trong những hệ điều hành đầu tiên chạy trên Xen, nhưng nó không hỗ trợ PAE và lúc đó tôi không đủ khả năng để viết những thứ cấp thấp như vậy mã hạt nhân, do đó, mặc dù là động lực thúc đẩy FreeBSD/EC2 những nỗ lực tôi đã phải dựa vào các nhà phát triển có kinh nghiệm hơn để viết mã hạt nhân vào thời điểm đó. Tôi hoàn toàn thoải mái với vùng người dùng mặc dù vậy, đó là mã — vì vậy khi Amazon gửi cho tôi mã "công cụ AMI" nội bộ (cần thiết để sử dụng các API không công khai), tôi đã dành vài tuần để chuyển nó chạy trên FreeBSD. Mẹo nhỏ: Mặc dù nhìn chung tôi là một công cụ chứ không phải chính sách anh bạn, nếu bạn thấy mình đang viết các tập lệnh Ruby để xây dựng và chạy bash, bạn có thể muốn xem xét lại lựa chọn ngôn ngữ của mình.

Thật không may, ngay cả khi tôi đã đóng gói FreeBSD thành AKI (Amazon Hình ảnh hạt nhân) và AMI (Hình ảnh máy của Amazon) nó không khởi động được trong EC2; sau khi trao đổi hàng tá email với Cape Town, chúng tôi xác định được nguyên nhân là do EC2 sử dụng Xen 3.0, có một lỗi ngăn nó hỗ trợ các bảng trang đệ quy - một tối ưu hóa dễ thương mà mã VM của FreeBSD đã sử dụng. Sự cố đã được khắc phục trong Xen 3.1, nhưng Xen không có ABI ổn định vào thời điểm đó, vì vậy việc nâng cấp EC2 chạy trên Xen 3.1 sẽ phá vỡ các AMI hiện có; trong khi đó là Thật không may cho FreeBSD, Amazon đã đưa ra lựa chọn hiển nhiên ở đây bằng cách gắn bó với Xen 3.0 để hỗ trợ khách hàng hiện tại.

Vào tháng 3 năm 2008, tôi đã nhận được một trong những email mà dường như thực sự đáng chú ý trong nhận thức muộn màng:

Xin chào Colin,
Đây là Matt Garman từ nhóm EC2 tại Amazon.  […]

Matt đang mời tôi tham gia Alpha riêng của "Elastic Block Storage" (bây giờ thường được gọi là "Cửa hàng khối đàn hồi" - Tôi không chắc liệu Matt đã viết sai tên hoặc nếu tên đã thay đổi). Trong khi tôi đang phấn khích về chức năng mới, như tôi đã giải thích cho Matt thời điểm tốt nhất để hãy nói chuyện với tôi về dịch vụ mới trước khi xây dựng dịch vụ đó. Tôi xuất thân từ nền tảng toán học và lý thuyết; Tôi có thể cung cấp xa phản hồi hữu ích hơn về tài liệu thiết kế so với truy cập thử nghiệm alpha.

Đến tháng 4 năm 2008, tôi đã có Tarsnap ở phiên bản beta riêng tư và tôi đang nghiên cứu nó. mã kế toán - sử dụng Amazon SimpleDB làm nơi lưu trữ phía sau để ghi lại việc sử dụng và số dư tài khoản. Tất nhiên điều này có nghĩa là tôi phải đọc tài liệu API và viết mã để ký SimpleDB yêu cầu - hồi đó điều đó là cần thiết, nhưng tôi vẫn viết yêu cầu của riêng mình Mã giao diện AWS thay vì sử dụng bất kỳ SDK nào của họ — và chi tiết về kế hoạch ký kết khiến tôi chú ý: Việc chuẩn hóa sơ đồ đã có xung đột. Tôi không có bất kỳ liên hệ nào trên SimpleDB nhóm — và Amazon vào thời điểm đó không có bất kỳ "báo cáo bảo mật nào vấn đề ở đây" liên hệ — vì vậy vào ngày 1 tháng 5 tôi đã gửi email cho Jeff Barr bắt đầu bằng dòng "Bạn có thể chuyển tiếp cái này cho ai đó từ nhóm SimpleDB?"

Mặc dù vấn đề này mãi đến tháng 12 mới được khắc phục nhưng Amazon đã làm rất tốt xử lý việc này - và giữ liên lạc với tôi trong suốt thời gian đó. Họ yêu cầu tôi xem lại sơ đồ "chữ ký phiên bản 2" được đề xuất của họ; đã sửa tài liệu của họ khi tôi chỉ ra sự mơ hồ; đã sửa những gì tôi được gọi một cách hoa mỹ là "một quyết định thiết kế rất kỳ lạ"; và đưa tài khoản của tôi vào danh sách cho phép để tôi có thể kiểm tra mã của mình (mà tôi đã viết dựa trên tài liệu của họ) dựa trên back-end API của họ. (Tôi đã viết thêm về điều này trong bài viết trên blog của tôi AWS chữ ký phiên bản 1 không an toàn.)

Vào tháng 6 năm 2008, tôi nhận thấy rằng các giá trị NextToken — được trả về bởi SimpleDB khi một truy vấn trả về quá nhiều kết quả và sau đó được trả về sang SimpleDB để nhận được nhiều kết quả hơn — được mã hóa đơn giản bằng base64 các đối tượng Java được tuần tự hóa. Đây vốn là vấn đề vệ sinh an ninh kém: Những cookie như vậy cần được mã hóa (để tránh rò rỉ thông tin nội bộ chi tiết) và ký tên (để bảo vệ chống giả mạo). Tôi đã không biết Trình giải tuần tự hóa đối tượng Java của Amazon mạnh đến mức nào, nhưng điều này có vẻ như có điều gì đó có thể là một vấn đề (và lẽ ra phải xảy ra đã được sửa bất chấp, vì quyết định thiết kế kém ngay cả khi không thể khai thác được), vì vậy tôi đã báo cáo điều đó với một trong những người mà tôi đang liên lạc trên nhóm SimpleDB... và không nhận được phản hồi gì. Sáu tháng sau, khi một kỹ sư (có lẽ quan tâm đến bảo mật hơn) mà tôi đã từng làm việc cùng vấn đề ký kết có nội dung "hãy cho tôi biết nếu bạn tìm thấy thêm vấn đề bảo mật; vì chúng tôi chưa có trang phản hồi bảo mật nên hãy gửi email cho tôi" Tôi đã báo cáo lại vấn đề tương tự và anh ấy đã viết nó lên nội bộ. (Thậm chí sau đó tôi vẫn chưa bao giờ nhận được bất kỳ phản hồi nào, bạn nhớ nhé.)

Cuối năm 2008, sau khi Tarsnap ở phiên bản beta công khai (nhưng trước đó nó có nhiều lực kéo) - và sau sự thúc đẩy đáng kể từ Jeff Barr - Tôi đã cân nhắc khả năng làm việc cho Amazon. Tôi đã có cuộc phỏng vấn qua điện thoại với Al Vermeulen và biết được điều đó hơi muộn một bài học quan trọng: Trong một cuộc phỏng vấn 45 phút, hãy dành 30 phút tranh luận về giá trị của các trường hợp ngoại lệ với tác giả cuốn Những yếu tố của Java Style có lẽ không phải là cách sử dụng thời gian tốt nhất. Tôi vẫn kiên quyết tin rằng tôi đã đúng - ngoại lệ vốn dĩ là nghèo cách xử lý lỗi vì chúng làm cho việc viết lỗi dễ dàng hơn sẽ không rõ ràng ngay lập tức khi kiểm tra mã thông thường - nhưng tôi cũng biết điều đó không cần thiết phải sửa cho mọi người ai sai.

Cuối cùng vào tháng 11 năm 2008, tôi lái xe xuống Seattle cho một công ty khởi nghiệp AWS Sự kiện tham quan và gặp gỡ trực tiếp người dân Amazon lần đầu tiên; đối với tôi, Điểm nổi bật của chuyến đi là gặp được người kỹ sư mà tôi đang làm việc với lỗ hổng ký yêu cầu. Chúng tôi đã có một cuộc thảo luận dài về bảo mật và đặc biệt là mong muốn của tôi về quyền truy cập AWS bị hạn chế khóa: Tôi lo ngại về khóa cấp quyền truy cập vào toàn bộ tài khoản và mức độ phơi nhiễm mà nó sẽ tạo ra nếu chúng bị rò rỉ. Tôi biện hộ cho các khóa có nguồn gốc từ mật mã (ví dụ: băm bí mật chính bằng "service=SimpleDB" để nhận khóa truy cập chỉ dành cho SimpleDB) trong khi anh ấy ưa thích thiết kế dựa trên bộ quy tắc, linh hoạt hơn nhưng có liên quan tôi vì lý do phức tạp. Cuối cùng, tôi hoàn toàn không ngạc nhiên khi tôi được mời tham gia phiên bản beta riêng tư của IAM vào tháng 1 năm 2010 — và cũng có phần thích thú khi SigV4 ra mắt vào năm 2012 bằng cách sử dụng các khóa dẫn xuất.

Trong phần lớn thời gian của năm 2009, tôi bận rộn với việc phát triển Tarsnap. Nhóm EC2 đã thành lập một số máy chủ Xen 3.1 để thử nghiệm và đến giữa tháng 1 tôi đã có thể khởi chạy và SSH vào FreeBSD; nhưng vì EC2 không có kế hoạch nâng cấp cụ thể Ngoài Xen 3.0, toàn bộ dự án FreeBSD/EC2 vẫn còn bị chặn. Tuy nhiên tôi đã nhận thấy và báo cáo sự cố với EC2 tường lửa: Bộ quy tắc mặc định đã chặn ICMP, bao gồm cả Đích Tin nhắn không thể truy cập (Yêu cầu phân mảnh) - do đó phá vỡ Đường dẫn khám phá MTU. Vào tháng 12 năm 2009, một người quản lý ở EC2 đã đồng ý với ý kiến của tôi giải pháp được đề xuất (thêm quy tắc vào bộ quy tắc mặc định) và viết "Tôi sẽ cho bạn biết ngay khi tôi có kế hoạch thực hiện và tôi tin rằng điều đó sẽ sớm xảy ra". Điều này cuối cùng đã được sửa trong 2012, ngay sau tôi đã nêu vấn đề một cách công khai.

Đến đầu năm 2010, EC2 vẫn còn mắc kẹt trên phiên bản cổ xưa của Xen, tôi bắt đầu thất vọng về việc chạy FreeBSD, vì vậy Tôi chuyển sang lựa chọn tốt nhất tiếp theo: NetBSD, chạy nổi tiếng trên bất cứ điều gì. Tôi chỉ mất một tuần - và một vài email khứ hồi tới Cape Town để yêu cầu nhật ký bảng điều khiển — để tạo NetBSD AMI có thể khởi động, gắn hệ thống tập tin gốc, cấu hình mạng, và khởi chạy sshd. Trong khi Amazon có chút cảnh giác về việc tôi thông báo điều này một cách công khai - có lý do là họ không muốn tôi nói bất cứ điều gì có thể được hiểu là thay mặt họ đưa ra lời hứa -- họ đồng ý rằng tôi có thể thảo luận công việc với các nhà phát triển bên ngoài NDA và nhóm NetBSD rất vui mừng khi biết về tiến trình... mặc dù có chút bối rối về lý do tại sao Amazon vẫn sử dụng Xen ảo hóa thay vì HVM.

Thiếu HVM tiếp tục là một điểm nhức nhối - đặc biệt là khi tôi biết EC2 đã cung cấp Xen/HVM cho các phiên bản Windows — nhưng vào tháng 7 2010 Amazon ra mắt phiên bản "Điện toán cụm" hỗ trợ HVM ngay cả đối với hình ảnh "Linux". Tôi không thể khởi động FreeBSD trên những thứ này ngay lập tức — trong khi HVM giải quyết vấn đề bảng phân trang, thì có vẫn là những vấn đề về trình điều khiển cần giải quyết — nhưng điều này mang lại cho tôi chút hy vọng vì sự tiến bộ nên khi Matt Garman đề cập đến họ đang "suy nghĩ về" làm cho HVM trở nên phổ biến rộng rãi hơn, tôi ngay lập tức viết thư lại để khuyến khích những suy nghĩ như vậy; đến thời điểm này, rõ ràng PV là một công nghệ ngõ cụt và tôi không muốn Amazon mắc sai lầm công nghệ lâu hơn mức cần thiết.

Tuy nhiên, bước đột phá thực sự đầu tiên lại đến với việc ra mắt sản phẩm mới. loại phiên bản t1.micro vào tháng 9. Trong khi nó không được công bố rộng rãi vào thời điểm đó, dòng phiên bản mới này đã tiếp tục hoạt động Xen 3.4.2 — thiếu lỗi khiến không thể chạy được BSD miễn phí. Đến giữa tháng 11, tôi đã có thể SSH vào FreeBSD/EC2 t1.micro Ví dụ, và vào ngày 13 tháng 12 năm 2010, Tôi đã thông báo rằng FreeBSD hiện có sẵn cho các phiên bản EC2 t1.micro.

Khi tôi đã tiến xa đến thế, mọi việc đột nhiên trở nên dễ dàng hơn. Amazon bây giờ đã có khách hàng sử dụng FreeBSD — và họ muốn có thêm FreeBSD. A Solutions Architect đã giúp tôi liên hệ với một người dùng FreeBSD muốn hỗ trợ cho các phiên bản lớn hơn và họ đã trả tiền cho tôi theo thời gian đó đã nhận được FreeBSD hoạt động trên các phiên bản Điện toán cụm; sau đó nó được chỉ cho tôi biết rằng EC2 không thực sự biết chúng tôi là hệ điều hành nào đang chạy và tôi đã tiến hành cung cấp FreeBSD trên tất cả các phiên bản 64-bit các loại phiên bản thông qua sự phản bội. Rõ ràng điều này có nghĩa trả "thuế windows" để chạy FreeBSD — điều mà Amazon không hài lòng lắm! - nhưng ngay cả khi được thêm vào chi phí nó đáp ứng một nhu cầu thiết yếu của khách hàng. (Việc hack này cuối cùng đã chấm dứt cần thiết vào tháng 7 năm 2014, khi T2 điền vào bản ổn định loại hỗ trợ chạy "Linux" trên HVM.)

Năm 2012 là một năm thú vị. Vào tháng Tư, tôi đã có bộ râu xám cổ điển kinh nghiệm sửa lỗi mạng; Tôi thấy rằng một điều đáng kể tỷ lệ yêu cầu S3 của tôi tới một điểm cuối cụ thể không thành công với các lỗi đặc biệt, bao gồm cả lỗi SignatureDoesNotMatch. Những cái này phản hồi lỗi từ Amazon S3 có chứa StringToSign một cách hữu ích, và tôi có thể thấy rằng những thứ này không khớp với những gì tôi gửi tới S3. Tôi có đủ lỗi để xác định lỗi là "bit bị kẹt"; vì vậy tôi đã rút ra traceroute - đây là tiền SRD nên các gói của tôi đã được đi qua một con đường nhất quán xuyên qua trung tâm dữ liệu — và sau đó đã tiến hành gửi vài triệu ping đến mỗi máy chủ dọc theo đường dẫn. Những người Amazon trên Diễn đàn nhà phát triển AWS là hơi bối rối khi Tôi đã đăng để báo cáo rằng một bộ định tuyến cụ thể đã gặp lỗi phần cứng... và càng bất ngờ hơn khi họ đã có thể xác nhận thất bại và thay thế phần cứng bị lỗi vài ngày sau đó.

Tuy nhiên, điểm nổi bật của năm 2012 là re:Invent đầu tiên - được phát hành thiếu nội dung mang tính kỹ thuật và có tỷ lệ giữa áo thun và bộ vest khủng khiếp, nhưng đã cho tôi cơ hội nói chuyện trực tiếp với một số người Amazon mặt. Vào một dịp đáng nhớ, sau khi tham dự buổi nói chuyện của Intel về "bảo mật máy ảo" (được cung cấp bởi một VP, người đáp ứng yêu cầu của tôi thẩm vấn, tuyên bố không biết gì về "các cuộc tấn công kênh bên" hoặc cách chúng có thể ảnh hưởng đến máy ảo) Tôi đã đến gian hàng EC2 trong hội trường triển lãm để phàn nàn... và hoàn toàn vô tình lại nói chuyện cho một kỹ sư chính. tôi đã nói về tác phẩm của tôi khai thác HyperThreading để đánh cắp khóa RSA và giải thích rằng, mặc dù cách khai thác chính xác mà tôi tìm thấy đã được vá, tôi hoàn toàn tin tưởng chắc chắn có nhiều cách khác để thông tin có thể bị rò rỉ giữa hai luồng chia sẻ một lõi. Tôi kết thúc bằng một lời khuyên mạnh mẽ: Dựa trên chuyên môn của tôi trong lĩnh vực này, tôi sẽ không bao giờ chạy hai phiên bản EC2 song song trên hai luồng của cùng một lõi. Nhiều năm sau, tôi được biết rằng khuyến nghị này là lý do khiến nhiều dòng phiên bản EC2 tăng vọt thẳng tới hai vCPU ("lớn") và bỏ qua kích thước "trung bình".

Thời gian trôi qua. Với FreeBSD về cơ bản đang hoạt động, tôi đã chuyển sang chế độ "tốt to hass": hợp nhất các bản vá FreeBSD của tôi, đơn giản hóa việc cập nhật bảo mật đường dẫn (bao gồm tự động cài đặt các bản cập nhật trong lần khởi động đầu tiên) và thay đổi kích thước hệ thống tập tin gốc trong lần khởi động đầu tiên. Vào tháng 4 năm 2015, tôi đã hoàn thành tích hợp quy trình xây dựng AMI FreeBSD/EC2 vào cây src FreeBSD và bàn giao các bản dựng hình ảnh cho nhóm kỹ thuật phát hành FreeBSD — di chuyển FreeBSD/EC2 qua ngưỡng tượng trưng từ "Colin" dự án thành "FreeBSD chính thức". Trên thực tế tôi vẫn là chủ sở hữu của nền tảng, bạn nhớ nhé - nhưng ít nhất tôi không chịu trách nhiệm về chạy tất cả các bản dựng.

Vào tháng 10 năm 2016, tôi đã xem xét kỹ hơn Vai trò IAM dành cho Amazon EC2, đã ra mắt vào giữa năm 2012. Tôi càng nghĩ về nó thì càng tôi có liên quan; hiển thị thông tin đăng nhập qua IMDS - một giao diện chạy trên HTTP không được xác thực và được cảnh báo trong tài liệu của nó chống lại việc lưu trữ "dữ liệu nhạy cảm, chẳng hạn như mật khẩu" - có vẻ như một công thức cho cú sút chân vô tình. Tôi đã viết một bài đăng trên blog "EC2 nhất tính năng nguy hiểm" nêu lên mối lo ngại này (và những vấn đề khác, chẳng hạn như chính sách IAM quá rộng), nhưng không thấy phản hồi từ Amazon... nghĩa là, phải đến tháng 7 năm 2019, khi Capital One bị xâm phạm do khai thác rủi ro chính xác mà tôi đã mô tả, dẫn đến 106 triệu khách hàng thông tin bị đánh cắp. Vào tháng 11 năm 2019, tôi có một cuộc điện thoại với một kỹ sư của Amazon để thảo luận về kế hoạch giải quyết vấn đề của họ vấn đề, và hai tuần sau, IMDSv2 ra mắt — một cải tiến hữu ích (đặc biệt là do tính cấp bách sau vụ vi phạm Capital One) nhưng theo ý kiến của tôi chỉ xem việc giảm thiểu một đường dẫn khai thác cụ thể hơn là giải quyết vấn đề cơ bản là thông tin xác thực đã bị lộ thông qua một giao diện hoàn toàn không phù hợp với điều đó mục đích.

Vào tháng 5 năm 2019, tôi được mời tham gia Anh hùng AWS chương trình công nhận những người không phải người Amazon có đóng góp quan trọng đóng góp cho AWS. (Trò đùa giữa các Anh hùng là Anh hùng là người làm việc cho Amazon nhưng không được Amazon trả tiền.) Chương trình này tập trung chủ yếu vào những người giúp đỡ các nhà phát triển tìm hiểu cách sử dụng AWS (thông qua các bài đăng trên blog, video trên YouTube, hội thảo, v.v. cetera), vậy nên tôi là một kẻ ngoại lệ; thực sự tôi đã được bảo rằng khi tôi được đề cử họ không chắc chắn về tôi sẽ như thế nào, nhưng kể từ khi tôi được đề cử bởi một Kỹ sư xuất sắc và một cao cấp Kỹ sư trưởng, họ cảm thấy không thể nói không được.

Vào tháng 3 năm 2021, EC2 đã bổ sung tính năng hỗ trợ khởi động phiên bản x86 bằng UEFI; tham số "BootMode" có thể được chỉ định trong khi đăng ký hình ảnh để khai báo xem nó nên được khởi động bằng BIOS cũ hay BIOS hiện đại UEFI. Đối với FreeBSD, đây là một tin tuyệt vời: Chuyển sang chế độ UEFI tăng tốc đáng kể quá trình khởi động - thực hiện I/O của trình tải ở chế độ 16 bit yêu cầu chuyển dữ liệu qua một bộ đệm nhỏ và chi phí chúng tôi có thêm 7 giây thời gian khởi động. Vấn đề duy nhất là trong khi tất cả các loại phiên bản x86 hỗ trợ khả năng khởi động BIOS truyền thống, không phải tất cả các loại phiên bản đều hỗ trợ UEFI — vì vậy tôi phải quyết định xem có nên giảm trải nghiệm ở một số lượng nhỏ hay không của người dùng để cung cấp tốc độ tăng tốc đáng kể cho hầu hết người dùng. Vào tháng Sáu, Tôi đã yêu cầu Cài đặt BootMode=polyglot cho biết hình ảnh đã được có thể khởi động theo một trong hai cách (trên thực tế, hình ảnh FreeBSD đã có thể) và hướng dẫn EC2 chọn chế độ khởi động thích hợp dựa trên ví dụ. Vào tháng 3 năm 2023, tính năng này có tên là "BootMode=uefi-preferred", mà tôi phải thừa nhận là một cái tên thân thiện hơn, mặc dù ít lập dị hơn.

Một trong những điều quan trọng nhất về chương trình AWS Heroes là các cuộc họp giao ban mà các Anh hùng nhận được, đặc biệt là tại "Hội nghị thượng đỉnh anh hùng" hàng năm. trong Vào tháng 8 năm 2023, chúng tôi đã có buổi thuyết trình về OCI có thể tìm kiếm và xem xét thiết kế mà tôi đã tự nhủ "đợi đã, họ đang thiếu thứ gì đó ở đây": Diễn giả đã đưa ra những tuyên bố về tính bảo mật đúng trong hầu hết các trường hợp hoàn cảnh, nhưng không đúng trong một trường hợp sử dụng cụ thể. tôi đã viết cho nhóm Bảo mật AWS (không giống như năm 2008, hiện tại đã có một đội ngũ nhân viên tốt nhóm với hướng dẫn rõ ràng về cách liên lạc), một phần nói rằng, “Tôi không chắc có phải họ không hiểu về [kiểu tấn công] hay không. hoặc nếu đó chỉ là vấn đề tiếp thị nhầm lẫn, nhưng tôi cảm thấy như ai đó cần phải nói chuyện với họ". Cảm giác của tôi là điều này có thể có thể được giải quyết bằng tài liệu rõ ràng nói rằng "đừng làm điều này điều thực sự kỳ lạ mà bạn có thể không định làm dù sao đi nữa", nhưng vì tôi không đặc biệt quen thuộc với dịch vụ này nên tôi không muốn đưa ra giả định về cách nó được sử dụng. Sau một vài chuyến đi khứ hồi qua email tôi được đảm bảo rằng vấn đề đã được khắc phục nội bộ và bản sửa lỗi sẽ được hợp nhất ra công chúng Kho lưu trữ GitHub sớm. Tôi chấp nhận những đảm bảo này - qua trong nhiều năm, tôi đã phát triển mối quan hệ tốt với những người thuộc bộ phận Bảo mật của AWS và hãy tin tưởng họ sẽ giải quyết những vấn đề như vậy - và gạt nó ra khỏi tâm trí tôi.

Tuy nhiên, vào tháng 12 năm 2023, tôi đã nói chuyện với một số người Amazon tại re:Invent và đã được nhắc nhở về vấn đề này. Tôi chưa nghe được gì thêm, điều đó làm tôi ngạc nhiên khi sửa lỗi này trong mã (chứ không phải trong tài liệu) sẽ khá xâm phạm. Tôi yêu cầu họ kiểm tra vấn đề này và họ hứa sẽ báo cáo lại cho tôi vào tháng Giêng, nhưng họ chưa bao giờ làm vậy, và một lần nữa tôi ngừng nghĩ về nó. Sau đây là re:Invent, trong Tháng 12 năm 2024, tôi gặp Kỹ sư trưởng làm việc về OCI và đề cập vấn đề với anh ấy - "này, chuyện gì đã xảy ra với vấn đề này vậy?" - nhưng anh ấy không hề biết điều đó. Tháng 1 năm 2025 tôi nuôi lại với Kỹ sư bảo mật; anh ấy đã tìm thấy chiếc vé gốc từ năm 2023 và đã nói chuyện với nhóm, họ đã chỉ ra một cam kết git mà họ nghĩ đã sửa nó.

Trên thực tế, vấn đề vẫn chưa được khắc phục: Cam kết năm 2023 đã ngăn cản vấn đề được kích hoạt do vô tình làm hỏng dữ liệu, nhưng đã không làm gì để ngăn chặn một cuộc tấn công có chủ ý. Một khi tôi đã chỉ ra điều này, mọi thứ diễn ra nhanh chóng; Tôi đã có cuộc gọi Zoom với nhóm kỹ thuật vài ngày sau, và đến cuối tháng 2, tính năng có vấn đề đã bị vô hiệu hóa đối với hầu hết khách hàng đang chờ "bản sửa đổi lớn".

Thay đổi lớn nhất trong 20 năm làm việc với Amazon của tôi bắt đầu out như một thứ hoàn toàn nội bộ của FreeBSD. Vào tháng 9 năm 2020, Trưởng nhóm kỹ thuật phát hành FreeBSD, Glen Barber, đã hỏi tôi liệu tôi có thể đảm nhận về vai trò Phó Kỹ sư phát hành - nói cách khác, Hot Kỹ sư phát hành dự phòng. Với tư cách là chủ sở hữu của nền tảng FreeBSD/EC2, tôi đã làm việc với nhóm Kỹ thuật phát hành trong nhiều năm và Glen cảm thấy tôi là ứng cử viên lý tưởng: đáng tin cậy, đáng tin cậy trong dự án và đủ quen thuộc với các quy trình kỹ thuật phát hành để thực hiện liệu anh ta có bị "xe buýt đâm" hay không. Trong khi tôi đưa ra quan điểm tìm hiểu nhiều nhất có thể về cách Glen quản lý các bản phát hành FreeBSD, giống như hầu hết các phụ tùng hot nhất mà tôi không bao giờ mong đợi sẽ được thăng chức.

Thật không may, vào cuối năm 2022 Glen phải nhập viện vì bệnh viêm phổi, và trong khi anh ấy đã hồi phục đủ để xuất viện vài tháng sau đó, trở nên rõ ràng rằng những ảnh hưởng lâu dài của việc nhập viện của anh ấy đã khiến anh ta không nên tiếp tục làm kỹ sư phát hành; sớm tháng mười một Vào ngày 17 tháng 1 năm 2023, Glen quyết định rút lui khỏi vai trò này và tôi đảm nhận vai trò này. Trưởng nhóm kỹ thuật phát hành FreeBSD. Tôi muốn nghĩ rằng kể từ đó tôi đã làm rất tốt - chạy xây dựng ảnh chụp nhanh hàng tuần, thắt chặt lịch trình, thiết lập một nhịp độ phát hành có thể dự đoán được và nhanh hơn, đồng thời quản lý bốn bản phát hành một năm - nhưng số giờ tình nguyện của tôi không phải là không giới hạn, và nó đã trở thành rõ ràng rằng các cam kết về kỹ thuật phát hành của tôi đã khiến điều đó không thể thực hiện được để theo kịp sự hỗ trợ của EC2 như tôi mong muốn.

Vào tháng 4 năm 2024, tôi tâm sự với một người Amazon rằng tôi “không thực sự làm việc sở hữu FreeBSD/EC2 ngay bây giờ là rất tốt" và hỏi liệu anh ấy có thể tìm được một số nguồn tài trợ để hỗ trợ công việc của tôi, trên lý thuyết rằng tại một thời điểm nhất định thời gian và đô la có thể thay thế được. Anh ấy bắt đầu làm việc, và trong vòng vài phút nhiều tuần các chi tiết cốt lõi đã được sắp xếp; Tôi đã nhận được tài trợ từ Amazon thông qua Nhà tài trợ GitHub trong 10 giờ mỗi tuần trong một năm và đã giải quyết một số lượng lớn vấn đề còn tồn đọng. Sau sáu tháng gián đoạn - hầu hết trong số đó tôi đã dành làm việc toàn thời gian, không được trả lương, trên FreeBSD Kỹ thuật phát hành 15.0 — Bây giờ tôi đã bắt đầu 12 tháng thứ hai thời hạn tài trợ.

Mặc dù tôi muốn nghĩ rằng mình đã có những đóng góp quan trọng cho AWS trong 20 năm qua, điều quan trọng cần lưu ý là điều này không hề có nghĩa công việc của tôi một mình. Đôi khi tôi đã phải nhắc nhở người dân Amazon rằng tôi không có quyền truy cập trực tiếp vào các hệ thống AWS nội bộ, nhưng một số người Amazon có can thiệp với tư cách "tay từ xa" để sắp xếp vé, tìm liên hệ nội bộ, kiểm tra nhật ký API và lấy tài liệu kỹ thuật cho tôi. Ngay cả khi mọi người - bao gồm cả những kỹ sư rất cao cấp - đã rõ ràng đề nghị giúp đỡ, tôi ý thức được thời gian của họ và kêu gọi họ ít nhất như tôi có thể; nhưng thực tế là tôi thậm chí còn không thể làm được điều gì một phần nhỏ những gì tôi đã hoàn thành mà không cần sự giúp đỡ của họ.

nhận xét trên blog được cung cấp bởi Disqus