AWS - Basic Information
Last updated
Last updated
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
AWS में एक रूट खाता होता है, जो आपके संगठन के सभी खातों के लिए माता-पिता कंटेनर है। हालाँकि, आपको संसाधनों को तैनात करने के लिए उस खाते का उपयोग करने की आवश्यकता नहीं है, आप विभिन्न AWS अवसंरचनाओं को अलग करने के लिए अन्य खाते बना सकते हैं।
यह सुरक्षा के दृष्टिकोण से बहुत दिलचस्प है, क्योंकि एक खाता अन्य खाते के संसाधनों तक पहुँच नहीं पाएगा (जब तक कि पुल विशेष रूप से बनाए नहीं गए हों), इसलिए इस तरह आप तैनातियों के बीच सीमाएँ बना सकते हैं।
इसलिए, एक संगठन में दो प्रकार के खाते होते हैं (हम AWS खातों की बात कर रहे हैं, उपयोगकर्ता खातों की नहीं): एक एकल खाता जिसे प्रबंधन खाता के रूप में नामित किया गया है, और एक या अधिक सदस्य खाते।
प्रबंधन खाता (रूट खाता) वह खाता है जिसका उपयोग आप संगठन बनाने के लिए करते हैं। संगठन के प्रबंधन खाते से, आप निम्नलिखित कर सकते हैं:
संगठन में खाते बनाना
संगठन में अन्य मौजूदा खातों को आमंत्रित करना
संगठन से खातों को हटाना
आमंत्रण प्रबंधित करना
संगठन के भीतर संस्थाओं (रूट, OU, या खातों) पर नीतियाँ लागू करना
संगठन में सभी खातों के लिए सेवा कार्यक्षमता प्रदान करने के लिए समर्थित AWS सेवाओं के साथ एकीकरण सक्षम करना।
आप इस रूट खाते/संगठन को बनाने के लिए उपयोग किए गए ईमेल और पासवर्ड का उपयोग करके रूट उपयोगकर्ता के रूप में लॉगिन करना संभव है।
प्रबंधन खाते की भुगतानकर्ता खाते की जिम्मेदारियाँ होती हैं और यह सदस्य खातों द्वारा उत्पन्न सभी शुल्कों का भुगतान करने के लिए जिम्मेदार होता है। आप संगठन के प्रबंधन खाते को नहीं बदल सकते।
सदस्य खाते संगठन में सभी अन्य खातों का निर्माण करते हैं। एक खाता एक समय में केवल एक संगठन का सदस्य हो सकता है। आप एक खाते पर नियंत्रण लागू करने के लिए एक नीति संलग्न कर सकते हैं।
सदस्य खातों को एक मान्य ईमेल पता का उपयोग करना चाहिए और एक नाम हो सकता है, सामान्यतः वे बिलिंग का प्रबंधन नहीं कर पाएंगे (लेकिन उन्हें इसके लिए पहुँच दी जा सकती है)।
खातों को Organization Units (OU) में समूहित किया जा सकता है। इस तरह, आप उस Organization Unit के लिए नीतियाँ बना सकते हैं जो सभी बच्चों के खातों पर लागू होंगी। ध्यान दें कि एक OU के पास अन्य OUs भी हो सकते हैं।
एक सेवा नियंत्रण नीति (SCP) एक नीति है जो उन सेवाओं और क्रियाओं को निर्दिष्ट करती है जिन्हें उपयोगकर्ता और भूमिकाएँ उन खातों में उपयोग कर सकते हैं जिन पर SCP प्रभाव डालती है। SCPs IAM अनुमतियों की नीतियों के समान हैं, सिवाय इसके कि वे कोई अनुमतियाँ नहीं देतीं। इसके बजाय, SCPs एक संगठन, संगठनात्मक इकाई (OU), या खाते के लिए अधिकतम अनुमतियाँ निर्दिष्ट करती हैं। जब आप अपने संगठन की जड़ या एक OU पर SCP संलग्न करते हैं, तो SCP सदस्य खातों में संस्थाओं के लिए अनुमतियों को सीमित करती है।
यह एकमात्र तरीका है कि रूट उपयोगकर्ता को कुछ करने से रोका जा सकता है। उदाहरण के लिए, इसका उपयोग उपयोगकर्ताओं को CloudTrail को निष्क्रिय करने या बैकअप हटाने से रोकने के लिए किया जा सकता है। इससे बचने का एकमात्र तरीका यह है कि मास्टर खाता भी समझौता किया जाए जो SCPs को कॉन्फ़िगर करता है (मास्टर खाता को अवरुद्ध नहीं किया जा सकता)।
ध्यान दें कि SCPs केवल खाते में प्रिंसिपल को प्रतिबंधित करती हैं, इसलिए अन्य खाते प्रभावित नहीं होते। इसका मतलब है कि s3:GetObject को अस्वीकार करने से लोगों को आपके खाते में एक सार्वजनिक S3 बकेट तक पहुँचने से नहीं रोका जाएगा।
SCP उदाहरण:
रूट खाते को पूरी तरह से अस्वीकार करें
केवल विशिष्ट क्षेत्रों की अनुमति दें
केवल श्वेत-पत्रित सेवाओं की अनुमति दें
GuardDuty, CloudTrail, और S3 सार्वजनिक ब्लॉक एक्सेस को निष्क्रिय करने से अस्वीकार करें
सुरक्षा/घटना प्रतिक्रिया भूमिकाओं को हटाने या संशोधित करने से अस्वीकार करें।
बैकअप को हटाने से अस्वीकार करें।
IAM उपयोगकर्ताओं और एक्सेस कुंजियों को बनाने से अस्वीकार करें
JSON उदाहरण https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html में खोजें
Amazon Resource Name वह विशिष्ट नाम है जो AWS के अंदर हर संसाधन का होता है, यह इस तरह से बना होता है:
Note that there are 4 partitions in AWS but only 3 ways to call them:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM वह सेवा है जो आपको अपने AWS खाते के भीतर प्रमाणीकरण, अधिकार और पहुँच नियंत्रण प्रबंधित करने की अनुमति देती है।
प्रमाणीकरण - एक पहचान को परिभाषित करने और उस पहचान के सत्यापन की प्रक्रिया। इस प्रक्रिया को पहचान और सत्यापन में विभाजित किया जा सकता है।
अधिकार - यह निर्धारित करता है कि एक पहचान एक प्रणाली के भीतर क्या पहुँच सकती है जब इसे प्रमाणित किया गया हो।
पहुँच नियंत्रण - सुरक्षित संसाधन तक पहुँच कैसे दी जाती है, इसकी विधि और प्रक्रिया।
IAM को इसकी क्षमता द्वारा परिभाषित किया जा सकता है कि यह आपके AWS खाते के भीतर पहचान के प्रमाणीकरण, अधिकार और पहुँच नियंत्रण तंत्रों का प्रबंधन, नियंत्रण और शासन कैसे करता है।
जब आप पहली बार एक Amazon Web Services (AWS) खाता बनाते हैं, तो आप एक सिंगल साइन-इन पहचान के साथ शुरू करते हैं जिसके पास खाते में सभी AWS सेवाओं और संसाधनों तक पूर्ण पहुँच होती है। यह AWS खाता रूट उपयोगकर्ता है और इसे उस ईमेल पते और पासवर्ड के साथ साइन इन करके एक्सेस किया जाता है जिसका उपयोग आपने खाता बनाने के लिए किया था।
ध्यान दें कि एक नया व्यवस्थापक उपयोगकर्ता के पास रूट उपयोगकर्ता की तुलना में कम अनुमतियाँ होंगी।
सुरक्षा के दृष्टिकोण से, अन्य उपयोगकर्ताओं को बनाना और इस एक का उपयोग करने से बचना अनुशंसित है।
एक IAM उपयोगकर्ता एक इकाई है जिसे आप AWS में उस व्यक्ति या एप्लिकेशन का प्रतिनिधित्व करने के लिए बनाते हैं जो इसका उपयोग AWS के साथ बातचीत करने के लिए करता है। AWS में एक उपयोगकर्ता में एक नाम और क्रेडेंशियल (पासवर्ड और दो तक पहुँच कुंजी) होते हैं।
जब आप एक IAM उपयोगकर्ता बनाते हैं, तो आप इसे अनुमतियाँ प्रदान करते हैं, इसे एक उपयोगकर्ता समूह का सदस्य बनाकर जो उपयुक्त अनुमति नीतियों से जुड़ा होता है (अनुशंसित), या प्रत्यक्ष रूप से नीतियाँ उपयोगकर्ता से जोड़कर।
उपयोगकर्ताओं के पास कंसोल के माध्यम से लॉगिन करने के लिए MFA सक्षम हो सकता है। MFA सक्षम उपयोगकर्ताओं के API टोकन MFA द्वारा सुरक्षित नहीं होते हैं। यदि आप MFA का उपयोग करके उपयोगकर्ताओं की API कुंजियों की पहुँच को प्रतिबंधित करना चाहते हैं तो आपको नीति में यह इंगित करना होगा कि कुछ कार्य करने के लिए MFA की आवश्यकता है (उदाहरण यहाँ)।
एक्सेस कुंजी आईडी: 20 यादृच्छिक अपरकेस अल्फ़ान्यूमेरिक वर्ण जैसे AKHDNAPO86BSHKDIRYT
गुप्त एक्सेस कुंजी आईडी: 40 यादृच्छिक अपर और लोअरकेस वर्ण: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (खोई हुई गुप्त एक्सेस कुंजी आईडी को पुनः प्राप्त करना संभव नहीं है)।
जब भी आपको एक्सेस कुंजी बदलने की आवश्यकता हो तो आपको इस प्रक्रिया का पालन करना चाहिए: &#xNAN;Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key
यह आपके मौजूदा तरीकों, जैसे पासवर्ड के अलावा प्रमाणीकरण के लिए एक अतिरिक्त कारक बनाने के लिए उपयोग किया जाता है, इस प्रकार, प्रमाणीकरण का एक मल्टी-फैक्टर स्तर बनाता है। आप एक नि:शुल्क वर्चुअल एप्लिकेशन या एक भौतिक उपकरण का उपयोग कर सकते हैं। आप AWS में MFA सक्रिय करने के लिए मुफ्त में गूगल प्रमाणीकरण जैसे ऐप्स का उपयोग कर सकते हैं।
MFA शर्तों वाली नीतियाँ निम्नलिखित से जोड़ी जा सकती हैं:
एक IAM उपयोगकर्ता या समूह
एक संसाधन जैसे Amazon S3 बकेट, Amazon SQS कतार, या Amazon SNS विषय
एक IAM भूमिका की ट्रस्ट नीति जिसे एक उपयोगकर्ता द्वारा ग्रहण किया जा सकता है
यदि आप CLI के माध्यम से पहुँच करना चाहते हैं एक संसाधन जो MFA की जाँच करता है तो आपको GetSessionToken कॉल करना होगा। यह आपको MFA के बारे में जानकारी के साथ एक टोकन देगा।
ध्यान दें कि AssumeRole क्रेडेंशियल्स में यह जानकारी नहीं होती।
As यहां कहा गया है, कई अलग-अलग मामले हैं जहां MFA का उपयोग नहीं किया जा सकता।
एक IAM उपयोगकर्ता समूह एक ऐसा तरीका है जिससे एक समय में कई उपयोगकर्ताओं के लिए नीतियों को संलग्न किया जा सकता है, जिससे उन उपयोगकर्ताओं के लिए अनुमतियों का प्रबंधन करना आसान हो सकता है। भूमिकाएँ और समूह समूह का हिस्सा नहीं हो सकते।
आप एक पहचान-आधारित नीति को एक उपयोगकर्ता समूह में संलग्न कर सकते हैं ताकि उपयोगकर्ता समूह में सभी उपयोगकर्ताओं को नीति की अनुमतियाँ प्राप्त हों। आप एक उपयोगकर्ता समूह को Principal के रूप में नीति (जैसे संसाधन-आधारित नीति) में पहचान नहीं सकते क्योंकि समूह अनुमतियों से संबंधित होते हैं, प्रमाणीकरण से नहीं, और प्रिंसिपल प्रमाणीकरण किए गए IAM संस्थाएँ हैं।
यहाँ उपयोगकर्ता समूहों की कुछ महत्वपूर्ण विशेषताएँ हैं:
एक उपयोगकर्ता समूह कई उपयोगकर्ताओं को शामिल कर सकता है, और एक उपयोगकर्ता कई समूहों का भाग हो सकता है।
उपयोगकर्ता समूहों को नेस्ट नहीं किया जा सकता; वे केवल उपयोगकर्ताओं को शामिल कर सकते हैं, अन्य उपयोगकर्ता समूहों को नहीं।
AWS खाते में सभी उपयोगकर्ताओं को स्वचालित रूप से शामिल करने वाला कोई डिफ़ॉल्ट उपयोगकर्ता समूह नहीं है। यदि आप ऐसा उपयोगकर्ता समूह रखना चाहते हैं, तो आपको इसे बनाना होगा और प्रत्येक नए उपयोगकर्ता को इसमें असाइन करना होगा।
AWS खाते में IAM संसाधनों की संख्या और आकार, जैसे समूहों की संख्या, और एक उपयोगकर्ता जिस समूह का सदस्य हो सकता है, सीमित हैं। अधिक जानकारी के लिए, IAM और AWS STS कोटा देखें।
एक IAM भूमिका एक उपयोगकर्ता के समान है, क्योंकि यह एक पहचान है जिसमें अनुमति नीतियाँ होती हैं जो यह निर्धारित करती हैं कि यह AWS में क्या कर सकता है और क्या नहीं। हालाँकि, एक भूमिका के साथ कोई प्रमाण-पत्र (पासवर्ड या एक्सेस कुंजी) नहीं होता है। एक व्यक्ति के साथ विशेष रूप से जुड़ने के बजाय, एक भूमिका को किसी भी व्यक्ति द्वारा अपनाने के लिए डिज़ाइन किया गया है जिसे इसकी आवश्यकता है (और जिसके पास पर्याप्त अनुमतियाँ हैं)। एक IAM उपयोगकर्ता एक भूमिका को अस्थायी रूप से एक विशिष्ट कार्य के लिए विभिन्न अनुमतियाँ लेने के लिए अपना सकता है। एक भूमिका को एक संघीय उपयोगकर्ता को असाइन किया जा सकता है जो IAM के बजाय एक बाहरी पहचान प्रदाता का उपयोग करके साइन इन करता है।
एक IAM भूमिका में दो प्रकार की नीतियाँ होती हैं: एक विश्वास नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि कौन भूमिका को अपना सकता है, और एक अनुमति नीति, जो खाली नहीं हो सकती, यह परिभाषित करती है कि यह क्या एक्सेस कर सकता है।
AWS सुरक्षा टोकन सेवा (STS) एक वेब सेवा है जो अस्थायी, सीमित-विशेषाधिकार प्रमाण-पत्रों के जारी करने की सुविधा प्रदान करती है। यह विशेष रूप से निम्नलिखित के लिए तैयार की गई है:
अस्थायी प्रमाण-पत्र मुख्य रूप से IAM भूमिकाओं के साथ उपयोग किए जाते हैं, लेकिन इसके अन्य उपयोग भी हैं। आप अस्थायी प्रमाण-पत्रों के लिए अनुरोध कर सकते हैं जिनमें आपके मानक IAM उपयोगकर्ता की तुलना में अधिक सीमित अनुमतियों का सेट होता है। यह आपको अनुमति नहीं दिए गए कार्यों को गलती से करने से रोकता है। अस्थायी प्रमाण-पत्रों का एक लाभ यह है कि वे एक निर्धारित समय के बाद स्वचालित रूप से समाप्त हो जाते हैं। आपके पास यह नियंत्रित करने की क्षमता है कि प्रमाण-पत्र कितने समय तक मान्य हैं।
अनुमतियों को असाइन करने के लिए उपयोग की जाती हैं। 2 प्रकार हैं:
AWS प्रबंधित नीतियाँ (AWS द्वारा पूर्व-निर्धारित)
ग्राहक प्रबंधित नीतियाँ: आपके द्वारा कॉन्फ़िगर की गई। आप AWS प्रबंधित नीतियों के आधार पर नीतियाँ बना सकते हैं (उनमें से एक को संशोधित करके और अपनी खुद की बनाकर), नीति जनरेटर का उपयोग करके (एक GUI दृश्य जो आपको अनुमतियाँ देने और अस्वीकार करने में मदद करता है) या अपनी खुद की लिखकर।
डिफ़ॉल्ट रूप से पहुँच अस्वीकृत है, पहुँच तब दी जाएगी जब एक स्पष्ट भूमिका निर्दिष्ट की गई हो। यदि एकल "Deny" मौजूद है, तो यह "Allow" को ओवरराइड करेगा, सिवाय उन अनुरोधों के जो AWS खाते की रूट सुरक्षा प्रमाण-पत्रों का उपयोग करते हैं (जो डिफ़ॉल्ट रूप से अनुमति दी जाती हैं)।
The global fields that can be used for conditions in any service are documented here. The specific fields that can be used for conditions per service are documented here.
इस प्रकार की नीतियाँ प्रत्यक्ष रूप से एक उपयोगकर्ता, समूह या भूमिका को असाइन की जाती हैं। फिर, वे नीतियों की सूची में नहीं दिखाई देती हैं क्योंकि कोई अन्य उनका उपयोग कर सकता है। इनलाइन नीतियाँ उपयोगी होती हैं यदि आप एक नीति और उस पहचान के बीच एक सख्त एक-से-एक संबंध बनाए रखना चाहते हैं जिस पर इसे लागू किया गया है। उदाहरण के लिए, आप यह सुनिश्चित करना चाहते हैं कि एक नीति में अनुमतियाँ अनजाने में किसी अन्य पहचान को असाइन नहीं की गई हैं। जब आप एक इनलाइन नीति का उपयोग करते हैं, तो नीति में अनुमतियाँ अनजाने में गलत पहचान से नहीं जुड़ सकती हैं। इसके अलावा, जब आप AWS प्रबंधन कंसोल का उपयोग करके उस पहचान को हटाते हैं, तो पहचान में निहित नीतियाँ भी हटा दी जाती हैं। इसका कारण यह है कि वे प्रमुख इकाई का हिस्सा हैं।
ये नीतियाँ हैं जिन्हें संसाधनों में परिभाषित किया जा सकता है। AWS के सभी संसाधन उनका समर्थन नहीं करते हैं।
यदि एक प्रमुख के पास उन पर स्पष्ट अस्वीकृति नहीं है, और एक संसाधन नीति उन्हें पहुँच प्रदान करती है, तो उन्हें अनुमति दी जाती है।
IAM सीमाएँ एक उपयोगकर्ता या भूमिका को पहुँच की अनुमतियों को सीमित करने के लिए उपयोग की जा सकती हैं। इस तरह, भले ही उपयोगकर्ता को एक अलग नीति द्वारा अनुमतियों का एक अलग सेट दिया गया हो, यदि वह उनका उपयोग करने की कोशिश करता है तो संचालन विफल हो जाएगा।
एक सीमा बस एक नीति है जो एक उपयोगकर्ता से जुड़ी होती है जो यह संकेत करती है कि उपयोगकर्ता या भूमिका के पास अधिकतम अनुमतियों का स्तर क्या हो सकता है। इसलिए, भले ही उपयोगकर्ता के पास व्यवस्थापक पहुँच हो, यदि सीमा संकेत करती है कि वह केवल S· बकेट पढ़ सकता है, तो यही अधिकतम है जो वह कर सकता है।
यह, SCPs और कम से कम विशेषाधिकार सिद्धांत का पालन करना उन तरीकों में से हैं जिनसे यह नियंत्रित किया जा सकता है कि उपयोगकर्ताओं के पास उनकी आवश्यकताओं से अधिक अनुमतियाँ नहीं हैं।
एक सत्र नीति एक नीति है जो तब सेट की जाती है जब किसी भूमिका को किसी तरह से ग्रहण किया जाता है। यह उस सत्र के लिए एक IAM सीमा की तरह होगी: इसका मतलब है कि सत्र नीति अनुमतियाँ नहीं देती है बल्कि उन्हें नीति में निर्दिष्ट अनुमतियों तक सीमित करती है (अधिकतम अनुमतियाँ वे होती हैं जो भूमिका के पास होती हैं)।
यह सुरक्षा उपायों के लिए उपयोगी है: जब एक व्यवस्थापक एक बहुत विशेषाधिकार प्राप्त भूमिका ग्रहण करने जा रहा है, तो वह सत्र नीति में निर्दिष्ट अनुमतियों तक ही अनुमति को सीमित कर सकता है यदि सत्र से समझौता किया जाता है।
Note that by default AWS might add session policies to sessions that are going to be generated because of third reasons. For example, in unauthenticated cognito assumed roles by default (using enhanced authentication), AWS will generate session credentials with a session policy that limits the services that session can access to the following list.
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because there is a session policy preventing it.
Identity federation allows users from identity providers which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account. An example of an identity provider can be your own corporate Microsoft Active Directory (via SAML) or OpenID services (like Google). Federated access will then allow the users within it to access AWS.
To configure this trust, an IAM Identity Provider is generated (SAML or OAuth) that will trust the other platform. Then, at least one IAM role is assigned (trusting) to the Identity Provider. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
However, you will usually want to give a different role depending on the group of the user in the third party platform. Then, several IAM roles can trust the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a central place that brings together administration of users and their access to AWS accounts and cloud applications.
The login domain is going to be something like <user_input>.awsapps.com.
To login users, there are 3 identity sources that can be used:
Identity Center Directory: Regular AWS users
Active Directory: Supports different connectors
External Identity Provider: All users and groups come from an external Identity Provider (IdP)
In the simplest case of Identity Center directory, the Identity Center will have a list of users & groups and will be able to assign policies to them to any of the accounts of the organization.
In order to give access to a Identity Center user/group to an account a SAML Identity Provider trusting the Identity Center will be created, and a role trusting the Identity Provider with the indicated policies will be created in the destination account.
It's possible to give permissions via inline policies to roles created via IAM Identity Center. The roles created in the accounts being given inline policies in AWS Identity Center will have these permissions in an inline policy called AwsSSOInlinePolicy.
Therefore, even if you see 2 roles with an inline policy called AwsSSOInlinePolicy, it doesn't mean it has the same permissions.
A user (trusting) can create a Cross Account Role with some policies and then, allow another user (trusted) to access his account but only having the access indicated in the new role policies. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account. It's recommended to specify the user who is trusted and not put some generic thing because if not, other authenticated users like federated users will be able to also abuse this trust.
Not supported:
Trust Relations
AD Admin Center
Full PS API support
AD Recycle Bin
Group Managed Service Accounts
Schema Extensions
No Direct access to OS or Instances
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
You can set a password policy setting options like minimum length and password requirements.
You can download "Credential Report" with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every four hours.
AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
In this page you can find the IAM ID prefixed of keys depending on their nature:
ACCA
Context-specific credential
AGPA
User group
AIDA
IAM user
AIPA
Amazon EC2 instance profile
AKIA
Access key
ANPA
Managed policy
ANVA
Version in a managed policy
APKA
Public key
AROA
Role
ASCA
Certificate
ASIA
Temporary (AWS STS) access key IDs use this prefix, but are unique only in combination with the secret access key and the session token.
The following privileges grant various read access of metadata:
arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
codebuild:ListProjects
config:Describe*
cloudformation:ListStacks
logs:DescribeMetricFilters
directconnect:DescribeConnections
dynamodb:ListTables
In order for a regular user authenticate to AWS via CLI you need to have local credentials. By default you can configure them manually in ~/.aws/credentials or by running aws configure.
In that file you can have more than one profile, if no profile is specified using the aws cli, the one called [default] in that file will be used.
Example of credentials file with more than 1 profile:
If you need to access different AWS accounts and your profile was given access to assume a role inside those accounts, you don't need to call manually STS every time (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) and configure the credentials.
आप ~/.aws/config फ़ाइल का उपयोग कर सकते हैं यह इंगित करने के लिए कि कौन से भूमिकाएँ ग्रहण करनी हैं, और फिर सामान्य रूप से --profile पैरामीटर का उपयोग करें (ग्रहण-भूमिका उपयोगकर्ता के लिए पारदर्शी तरीके से की जाएगी)।
एक कॉन्फ़िग फ़ाइल का उदाहरण:
इस कॉन्फ़िग फ़ाइल के साथ आप aws cli का उपयोग कर सकते हैं जैसे:
यदि आप इसके लिए कुछ समान ढूंढ रहे हैं लेकिन ब्राउज़र के लिए, तो आप विस्तार AWS Extend Switch Roles देख सकते हैं।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
