AWS में बिताए 20 साल, एक बार भी नहीं कहा "यह मेरा काम नहीं है"
(daemonology.net)- FreeBSD Security Officer और Tarsnap के संस्थापक Colin Percival ने 2006 में अपना पहला AWS खाता बनाने से लेकर आज तक 20 वर्षों में, आधिकारिक कर्मचारी नहीं बल्कि एक बाहरी योगदानकर्ता के रूप में FreeBSD के लिए EC2 support तैयार करने, सुरक्षा कमजोरियों को पहले से पहचानकर रिपोर्ट करने, और service design पर feedback देने तक AWS के विकास में व्यापक रूप से शामिल रहने की अपनी यात्रा को कालक्रमानुसार याद किया है
- शुरुआती AWS में हर service को अलग-अलग सक्रिय करना पड़ता था, और शुरुआत में डिफ़ॉल्ट रूप से सक्रिय सेवाएँ सिर्फ Amazon SQS और ज़्यादातर लोगों के लिए अज्ञात Amazon E-Commerce Service थीं
- FreeBSD को EC2 पर चलाने के लिए Xen version compatibility, PAE support, और HVM transition जैसी कई वर्षों तक चलने वाली तकनीकी कठिनाइयों को हल करना पड़ा, और 2010 में t1.micro पर पहली बार इसे सफलतापूर्वक चलाया गया
- AWS request signature system में normalization collision vulnerability, IMDS के ज़रिए credentials उजागर होने का जोखिम (जो 2019 के Capital One breach में वास्तविकता बना), और Seekable OCI security issue सहित कई सुरक्षा समस्याएँ पहले से खोजकर रिपोर्ट की गईं
- 2024 से Amazon के GitHub Sponsors समर्थन के साथ FreeBSD/EC2 maintenance जारी है, और यह इस बात का उदाहरण है कि एक बाहरी योगदानकर्ता भी आंतरिक सिस्टम access के बिना Amazon engineers के सहयोग से बड़े परिणाम ला सकता है
AWS खाता बनाना और शुरुआती सेवाएँ
- 10 अप्रैल 2006 को Amazon S3 की घोषणा देखकर पहला AWS खाता बनाया; ऑनलाइन storage service में रुचि इसकी वजह थी, और इससे पहले भी 1998 से HTTP-based web services बनाने का अनुभव था
- शुरुआती AWS में हर service को अलग से खाते पर सक्रिय कराने का अनुरोध करना पड़ता था, और डिफ़ॉल्ट रूप से उपलब्ध सेवाएँ सिर्फ Amazon SQS और Amazon E-Commerce Service (Amazon affiliate उपयोग के लिए product catalog API) थीं
- Amazon E-Commerce Service वास्तव में पहली AWS service कही जा सकती थी, लेकिन यह ज़्यादातर लोगों को ज्ञात नहीं थी और बाद में AWS के इतिहास से भी चुपचाप हटा दी गई
सुरक्षा पर शुरुआती रुचि और feedback
- FreeBSD Security Officer के अनुभव के आधार पर AWS की security architecture में तुरंत रुचि ली; AWS requests API key से sign की जाती थीं जिससे authentication और integrity सुनिश्चित होती थी, लेकिन responses पर signature नहीं होता था—इस समस्या की ओर इशारा किया
- उस समय HTTP के ज़रिए AWS requests आम थीं, इसलिए response tampering का जोखिम वास्तविक था; TLS पर जाने के बाद भी उनका मानना रहा कि end-to-end signing, transport-layer security से बेहतर है
FreeBSD on EC2 — शुरुआती चुनौती
- Amazon EC2 लॉन्च होने के तुरंत बाद FreeBSD चलाने को लक्ष्य बनाया, Jeff Barr के माध्यम से Amazon के अंदर ज़िम्मेदार लोगों से संपर्क हुआ, और 2007 की शुरुआत में पहला Amazon NDA साइन किया
- उस समय Amazon fax का उपयोग करता था, लेकिन fax न होने के कारण हस्ताक्षरित मूल प्रति डाक से भेजनी पड़ी और पहली briefing में देरी हुई
- EC2 की शुरुआत custom kernel support के बिना हुई थी (कुछ-कुछ आज के AWS Lambda जैसी शैली में), और नवंबर 2007 में Red Hat support के साथ यह feature सक्षम होने पर FreeBSD खाते को भी अंदरूनी "Amazon Kernel Images publish" API access दिया गया
Xen security audit और side-channel attack चेतावनी
- मार्च 2007 में Amazon संपर्क व्यक्ति से Xen का security audit कराने की ज़रूरत उठाई, और जब उपयुक्त auditor ज्ञात नहीं था तो Tavis Ormandy की सिफारिश की
- उसी साल Tavis ने Xen की 2 vulnerabilities (CVE-2007-1320, CVE-2007-1321) रिपोर्ट कीं, लेकिन यह स्पष्ट नहीं कि इसका उनकी सिफारिश से कोई संबंध था या नहीं
- Jeff Barr की Second Life के भीतर आयोजित AWS user meeting में read-only root disk और reboot के समय memory zeroing guarantee जैसी सुविधाएँ माँगीं; यह untrusted code execution (जैसे FreeBSD package builds) वाले scenario के लिए था, और EC2 Instance Attestation 18 साल बाद आया
- 2012 के re:Invent में HyperThreading का उपयोग कर RSA key चोरी करने वाले शोध के बारे में EC2 Principal Engineer को समझाते हुए ज़ोरदार सलाह दी कि एक ही core के दो threads पर EC2 instances को साथ न चलाया जाए
- कहा जाता है कि इसी सलाह की वजह से कई EC2 instance families में "medium" size को छोड़कर सीधे 2 vCPU वाले "large" से शुरुआत हुई
Eventual Consistency और सैद्धांतिक प्रस्ताव
- 2007 के अंत में Amazon के भीतर व्यापक रूप से पढ़े गए एक blog post में Eventual Consistency की समस्या उठाई और Eventually Known Consistency नाम के थोड़ा अधिक मज़बूत model का पक्ष लिया
- CAP theorem में "A" (availability) वाला रास्ता बनाए रखते हुए भी internal state को उजागर करके सामान्य path में "C" (consistency) भी हासिल की जा सकती है—ऐसा model
- Amazon S3 ने बाद में availability optimization से consistency optimization की ओर बदलाव किया, और DynamoDB ने Eventual/Strongly Consistent reads का विकल्प दिया
Xen compatibility समस्या और FreeBSD boot failure
- 2008 की शुरुआत में Kip Macy ने Xen PAE support वाला FreeBSD kernel लिखा, और internal AMI tools को FreeBSD पर port करने में कई हफ्ते लगे
- Ruby scripts का bash scripts बनाना और चलाना—इस संरचना को देखते हुए language choice पर पुनर्विचार की ज़रूरत बताई गई
- FreeBSD AMI EC2 पर boot नहीं हुआ; कारण यह था कि EC2 जिस Xen 3.0 का उपयोग कर रहा था उसमें FreeBSD VM code के recursive page tables को support न करने वाला bug था
- Xen 3.1 में यह ठीक हो गया था, लेकिन stable ABI न होने के कारण पुराने AMI compatibility को बनाए रखने के लिए Amazon ने Xen 3.0 पर बने रहना चुना
AWS signature vulnerability की खोज और सुधार
- अप्रैल 2008 में Tarsnap beta के लिए Amazon SimpleDB का उपयोग करते समय signature system में normalization collision खोजी
- उस समय Amazon में security issue report करने का चैनल नहीं था, इसलिए Jeff Barr के ज़रिए यह बात पहुँचाई गई
- Amazon ने Signature Version 2 design review का अनुरोध किया, और documentation ambiguity ठीक करने, design decisions सुधारने, तथा account allowlist जोड़ने जैसी प्रक्रियाओं के बाद दिसंबर में fix पूरा हुआ
SimpleDB NextToken की security hygiene समस्या
- जून 2008 में पता चला कि SimpleDB का NextToken value सिर्फ base64-encoded Java serialized object था
- internal information leakage रोकने के लिए encryption और tampering रोकने के लिए signature की ज़रूरत होने की रिपोर्ट दी गई, लेकिन कोई जवाब नहीं मिला
- 6 महीने बाद एक अन्य engineer के माध्यम से फिर रिपोर्ट किया गया और internal ticket बना, लेकिन उसके बाद भी कोई आधिकारिक प्रतिक्रिया नहीं आई
EBS alpha test और design feedback का सही समय
- मार्च 2008 में EC2 team के Matt Garman ने Elastic Block Storage (आज का Elastic Block Store) के private alpha में आमंत्रित किया
- किसी नई service के लिए सबसे उपयोगी feedback बनाने से पहले के design stage में दिया जा सकता है; उनका मानना था कि math और theory background होने के कारण alpha testing से अधिक प्रभावी काम design documents की समीक्षा है
Amazon में नौकरी के इंटरव्यू का प्रसंग
- 2008 में Jeff Barr के कहने पर Amazon में शामिल होने पर विचार किया; Al Vermeulen के साथ phone interview में 45 मिनट में से 30 मिनट exceptions के फायदे-नुकसान पर चर्चा में बीते
- उनका मत बना रहा कि exceptions ऐसा मूलतः अनुपयुक्त error handling तरीका हैं जो casual code review में पकड़ में न आने वाले bugs पैदा करना आसान बनाते हैं
IAM और सीमित access keys — SigV4 तक की यात्रा
- नवंबर 2008 में Seattle AWS Start-up Tour में Amazon engineers से सीधे मिलकर सीमित AWS access keys की ज़रूरत पर चर्चा की
- master secret से service-specific keys को hash के माध्यम से निकालने वाली cryptographic derived keys की वकालत की, जबकि Amazon की ओर से rule-based design को तरजीह दी गई
- जनवरी 2010 में IAM private beta का निमंत्रण मिला, और 2012 में SigV4 रिलीज़ होने पर derived-key approach अपनाई गई
EC2 firewall समस्या और Path MTU Discovery
- 2009 में पाया और रिपोर्ट किया कि EC2 के default firewall rules ICMP Destination Unreachable(Fragmentation Required) messages को block कर रहे थे, जिससे Path MTU Discovery काम नहीं कर रही थी
- दिसंबर 2009 में EC2 manager समाधान पर सहमत हुआ, लेकिन असली fix 2012 में सार्वजनिक रूप से मुद्दा उठाने के बाद लागू हुआ
NetBSD के रास्ते workaround और HVM transition
- 2010 की शुरुआत में EC2 अभी भी पुराने Xen version पर था, इसलिए NetBSD की ओर मुड़ने की कोशिश की; एक हफ्ते में boot, filesystem mount, network setup और
sshdचलाने तक सफलता मिल गई - जुलाई 2010 में Cluster Compute instances ने HVM support दिया, जिससे FreeBSD के लिए भी उम्मीद जगी, और यह स्पष्ट हो गया कि PV (paravirtualization) तकनीकी dead end है
FreeBSD/EC2 की पहली सफलता — t1.micro
- सितंबर 2010 में आए t1.micro instance family के अंदर Xen 3.4.2 चल रहा था, जिससे FreeBSD boot को रोकने वाला bug खत्म हो गया
- नवंबर 2010 के मध्य में FreeBSD/EC2 t1.micro instance पर SSH login सफल हुआ, और 13 दिसंबर को FreeBSD EC2 t1.micro support की आधिकारिक घोषणा की गई
instance types का विस्तार और "Defenestration" hack
- Amazon Solutions Architect ने बड़े instances चाहने वाले FreeBSD users को उनसे जोड़ा, जिससे Cluster Compute instances support लागू किया गया
- इस तथ्य का लाभ उठाकर कि EC2 वास्तव में यह नहीं जानता था कि कौन-सा OS चल रहा है, defenestration (Windows instance के रूप में disguise) के ज़रिए सभी 64-bit instance types पर FreeBSD चलाना संभव हुआ
- इसके लिए "Windows tax" देना पड़ता था, और Amazon भी इससे खुश नहीं था, लेकिन customer demand पूरी करने के लिए यह ज़रूरी था; जुलाई 2014 में T2 instances के HVM "Linux" support पूरा होने के बाद यह hack अनावश्यक हो गया
S3 router hardware failure की पहचान
- अप्रैल 2012 में एक खास S3 endpoint पर SignatureDoesNotMatch errors सहित कई requests fail होने लगीं
- error responses में StringToSign का value भेजे गए value से अलग होने के pattern से stuck bit की पहचान हुई, और traceroute तथा लाखों ping के आधार पर route में एक खास router की hardware failure को pinpoint किया गया
- AWS Developer Forums में रिपोर्ट करने के बाद Amazon ने कुछ ही दिनों में fault की पुष्टि की और hardware बदल दिया
re:Invent 2012 और side-channel attack चेतावनी
- पहला re:Invent तकनीकी content के लिहाज़ से कमज़ोर और suits पहने लोगों से भरा हुआ था, लेकिन इसने कई Amazon engineers से आमने-सामने बात करने का अवसर दिया
- Intel के "virtual machine security" session के presenter VP ने जब कहा कि उन्हें side-channel attacks के बारे में जानकारी नहीं है, तो EC2 booth पर Principal Engineer को संबंधित research सीधे समझाई गई
FreeBSD/EC2 का आधिकारिककरण और release engineering
- अप्रैल 2015 में FreeBSD/EC2 AMI build process को FreeBSD src tree में integrate किया गया, और image builds को FreeBSD release engineering team को सौंपकर इसे निजी project से आधिकारिक FreeBSD project में बदला गया
- सितंबर 2020 में FreeBSD Release Engineering Lead Glen Barber के अनुरोध पर Deputy Release Engineer की भूमिका स्वीकार की
- 2022 के अंत में Glen pneumonia के कारण अस्पताल में भर्ती हुए, और लंबे समय तक रहने वाले दुष्प्रभावों के कारण वापसी कठिन होने पर 17 नवंबर 2023 को FreeBSD Release Engineering Lead की ज़िम्मेदारी स्वयं संभाली
- weekly snapshot builds, schedule tightening, और predictable fast release cycle स्थापित कर साल में 4 releases संभालीं
IMDS security warning और Capital One breach
- अक्टूबर 2016 में IAM Roles for Amazon EC2 का विश्लेषण कर blog में लिखा कि IMDS के ज़रिए credentials का उजागर होना जोखिम भरा है; यह unauthenticated HTTP पर चलता है और documentation में "sensitive data store न करें" जैसी चेतावनी दी जाती है
- जुलाई 2019 में Capital One ने ठीक इसी जोखिम के शोषण से 106 million customers का data breach झेला; उसी साल नवंबर में Amazon से बातचीत के 2 हफ्ते बाद IMDSv2 जारी हुआ
- उनका मत रहा कि IMDSv2 कुछ attack paths को mitigate करता है, लेकिन ऐसे interface के ज़रिए credentials उजागर होने की मूल समस्या का समाधान नहीं है जो इसके लिए उपयुक्त ही नहीं है
AWS Heroes program
- मई 2019 में एक non-Amazon contributor के रूप में AWS के लिए महत्वपूर्ण योगदान को मान्यता देने वाले AWS Heroes program में आमंत्रित किया गया
- यह चयन असामान्य था क्योंकि program मुख्यतः developer education (blogs, YouTube, workshops) में योगदान देने वालों पर केंद्रित था; अनुमोदन Distinguished Engineer और Senior Principal Engineer की सिफारिश पर हुआ
UEFI boot और BootMode=uefi-preferred
- मार्च 2021 में EC2 ने x86 instances पर UEFI boot support जोड़ा; FreeBSD में UEFI पर जाने से 16-bit mode I/O की ज़रूरत खत्म हुई और boot time 7 seconds कम हुआ
- सभी instance types UEFI support नहीं करते थे, इसलिए legacy BIOS और UEFI दोनों पर boot होने वाली images के लिए BootMode=polyglot setting का अनुरोध किया गया
- मार्च 2023 में इसे BootMode=uefi-preferred नाम से लागू किया गया
Seekable OCI security issue की खोज और fix में देरी
- अगस्त 2023 के Heroes Summit में Seekable OCI design देखकर पाया कि कुछ specific use cases में उसके security claims टिकते नहीं हैं, और यह बात AWS Security team को रिपोर्ट की गई
- internal fix का आश्वासन मिला, लेकिन असली प्रगति नहीं हुई; 2024 के re:Invent में फिर पुष्टि माँगी गई, और जनवरी 2025 में दोबारा रिपोर्ट करने पर यह स्पष्ट हुआ कि 2023 का commit सिर्फ accidental data corruption रोकता था, जानबूझकर किए गए attacks को नहीं
- मुद्दा फिर उठाने के बाद तेज़ी से कार्रवाई हुई, और फरवरी 2025 के अंत तक यह feature ज़्यादातर customers के लिए disable कर दिया गया; अब "major revision" का इंतज़ार है
Amazon sponsorship और सहयोग का मॉडल
- अप्रैल 2024 में Amazon को बताया कि वे FreeBSD/EC2 maintenance के लिए पर्याप्त समय नहीं दे पा रहे हैं और funding support माँगा; कुछ ही हफ्तों में GitHub Sponsors के माध्यम से प्रति सप्ताह 10 घंटे, 1 साल की sponsorship तय हो गई
- कई unresolved issues निपटाने के बाद 6 महीने के विराम (जिसमें अधिकांश समय बिना भुगतान के FreeBSD 15.0 release engineering पर ध्यान दिया) के बाद दूसरी 12-महीने की sponsorship शुरू हुई
- उन्होंने ज़ोर देकर कहा कि 20 वर्षों का यह योगदान अकेले उनका काम नहीं था; AWS के अंदरूनी सिस्टम access के बिना भी Amazon engineers ने tickets बनाकर, सही internal contacts ढूँढकर, API logs जाँचकर, और technical documents जुटाकर "remote hands" की भूमिका निभाई
1 टिप्पणियां
Hacker News की राय
लेखक ने मज़ाक में कहा कि ‘Heroes असल में बिना वेतन वाले Amazon कर्मचारी हैं’, लेकिन यह मज़ाक नहीं बल्कि हक़ीक़त है
मैं अपना निजी शोध सार्वजनिक नहीं करता। क्योंकि मैं पहले से ही काफ़ी efficient value extraction machine को मुफ़्त R&D नहीं देना चाहता
Amazon ने open source की आर्थिक बुनियाद को तोड़ दिया है, और नतीजतन कई projects Business Source License पर जा रहे हैं
ये developers जानते हैं कि Amazon कितना लालची है। आख़िरकार community contribution, mega-corporations के लिए बिना वेतन की मज़दूरी बन जाती है, और Amazon managed service के ज़रिए users को खींच लेता है, जिससे original project का support और community कमज़ोर हो जाते हैं
“Amazon को छोड़कर कोई भी इसे freely इस्तेमाल कर सकता है” ऐसा लिख दें, तो Amazon legal risk की वजह से इसका इस्तेमाल नहीं करेगा
हाँ, अगर उसे ज़रूरी लगा तो Amazon अपना version नए सिरे से बना सकता है
Redis case की तरह, API surface पर legal protection साफ़ नहीं है
मुझे याद है कि पहले Google v. Oracle फ़ैसला ऐसी protection स्थापित कर सकता था, लेकिन बात टल गई
सच तो यह है कि BSL चुनने वाली कंपनियों ने शायद open source की सच्ची भावना से ज़्यादा image management या developers की goodwill पाने के लिए source खोला होगा
फिर भी मैं पूरी तरह सहमत हूँ। अब जो code मैं public करूँगा, वह या तो पूरी तरह open source होगा या पूरी तरह private
अगर किसी के उससे पैसा कमाने की संभावना है, तो मैं उसे public नहीं करूँगा
मैं यह नज़रिया समझता हूँ कि बड़ी कंपनियों को अपना समय नहीं देना चाहिए, लेकिन मैं एक अलग दृष्टिकोण रखना चाहता हूँ
2006 में मैंने जो project name बनाया था, 2012 में एक दूसरे developer ने कहा कि वह उसे इस्तेमाल करना चाहता है, और मैंने खुशी-खुशी दे दिया
वही project था scrypt, और वह developer Colin था
इस तरह की community kindness, commercial expectation के बिना भी, अच्छा karma बनाती है
यह बात काफ़ी दिलचस्प है कि “Jeff Barr की AWS user meetup, Second Life में हुई थी”
Second Life, AWS के शुरुआती users में से था, और Jeff Bezos ने 2005 की funding round में सीधे भाग लिया था
उसी की वजह से Jeff Barr, Second Life के भीतर AWS meetup कर पाए, और वह वही दौर था जब Reuters और Jonathan Coulton जैसे groups भी virtual spaces में जा रहे थे
हम Evolution Robotics booth पर ER1 robot का demo दे रहे थे, और Second Life सचमुच काफ़ी प्रभावशाली लगा था
वह अच्छी याद बनकर रह गया है
बेशक, laptop screen के अंदर का Second Life और VR headset, पूरी तरह अलग अनुभव थे
“Amazon के लिए मुफ़्त मज़दूरी” वाला frame असल मुद्दे को चूक रहा है
Colin कोई charity नहीं कर रहे थे; Tarsnap, FreeBSD/EC2 पर निर्भर है, इसलिए वे उसी को बेहतर बना रहे थे
यह model open source के सबसे healthy रूपों में से एक है — अपने product की नींव को ठीक करना, और उसका नतीजा सबके लिए फ़ायदेमंद होना
Amazon के ख़ुद दिलचस्पी लेने का इंतज़ार करना, हमेशा इंतज़ार करते रहना जैसा है
यह पढ़कर हैरानी हुई कि Amazon ने GitHub Sponsors के ज़रिए हफ़्ते में 10 घंटे, 1 साल तक sponsorship दी थी
$300 प्रति घंटा तो Google L6 engineer की salary level जैसा है
अब उम्मीद है कि उन्हें इससे भी ज़्यादा मिले
जर्मन-भाषी यूरोप में 120 यूरो में बहुत अच्छा engineer मिल सकता है। पूर्वी यूरोप में इससे भी सस्ता है
मैं EC2 के लिए IAM Roles पर लेखक की आलोचना से सहमत नहीं हूँ
IAM वह core feature है जो credentials को policy-based तरीके से manage करने देता है
यह Outlook, Slack, Teams से कहीं ज़्यादा सुरक्षित है, और गणितीय रूप से यह साबित भी किया जा सकता है कि team members signing keys नहीं देख सकते
Azure भी इसी तरह की concept का इस्तेमाल करके MSSQL access को काफ़ी साफ़ तरीके से handle करता है
पहले मैंने सुझाव दिया था कि XenStore के ज़रिए kernel को credentials दिए जाएँ। Nitro-based setup में तो अब यह और आसान होना चाहिए
kernel credentials लेकर उन्हें ऐसे virtual filesystem के रूप में expose कर सकता है जहाँ ownership और permissions सेट की जा सकें
यह बात थोड़ी मज़ेदार है कि सिर्फ़ CAP_NET_BIND_SERVICE permission वाले process ही इसे access कर सकते हैं
अगर vsock(7) socket इस्तेमाल किया जाए, तो यह धोखा देना मुश्किल connection method बन जाता है और ज़्यादा सुरक्षित होता है
इससे आगे, अगर DMI data में bootstrap credentials रखे जाएँ, तो वे sysfs directory में होंगे जिन्हें सिर्फ़ root पढ़ सकता है
2007 के emails देखकर पता चला कि शुरुआती दौर में AWS services का access अलग-अलग request करके लेना पड़ता था, यह सच था
शुरुआत में सिर्फ़ “Amazon E-Commerce Service” की approval मिली थी, फिर बाद में S3 और उसके बाद EC2 beta का access मिला
उस समय “Alexa Web Information Service”, voice assistant नहीं बल्कि web search API था। वह दौर सचमुच दिलचस्प था
यह सच में एक दिलचस्प तकनीकी इतिहास का रिकॉर्ड है
यह देखकर असर हुआ कि Tavis Ormandy जैसे मशहूर engineer भी interview में ग़लती कर सकते हैं
इस तरह की अनुभव-आधारित blog posts बहुत अच्छी लगती हैं
यह बात काफ़ी अर्थपूर्ण है कि 20 साल की इस समीक्षा में Hetzner या OVH का ज़िक्र नहीं है
मैं AWS, Hetzner और छोटे cloud providers को साथ में इस्तेमाल करता हूँ, और कीमत का फ़र्क़ बहुत बड़ा है
AWS पर $350 महीना लगता है, जबकि Hetzner में 20~25 यूरो में लगभग वैसी ही specs और 20TB traffic शामिल है
AWS अब compute नहीं, बल्कि IAM model, global infrastructure और संगठन के भीतर consensus बेच रहा है
“AWS चुनो तो किसी की नौकरी नहीं जाएगी” वाली धारणा ही असली product है
मैं हाल में AWS से workloads हटाने वाले लोगों से पूछना चाहता हूँ — कौन-सा हिस्सा उम्मीद से ज़्यादा तकलीफ़देह निकला?