AWS में बिताए 20 साल, एक बार भी नहीं कहा "यह मेरा काम नहीं है"

 (daemonology.net)
9 पॉइंट द्वारा GN⁺ 18 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • 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" की भूमिका निभाई

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.