मार्गदर्शिका

बिजनेस यूनिट्स को प्रशासनिक स्वायत्तता प्रदान करते हुए बिलिंग और नीति प्रवर्तन को केंद्रीकृत करें।

→प्रत्येक बिजनेस यूनिट के लिए फ़ोल्डरों के साथ एक ऑर्गनाइजेशन नोड का उपयोग करें। फ़ोल्डरों के भीतर प्रोजेक्ट बनाएं। सभी प्रोजेक्ट्स को एक सिंगल बिलिंग अकाउंट से लिंक करें।

क्यों: फ़ोल्डर प्रशासनिक सीमाएँ और नीति विरासत प्रदान करते हैं। एक सिंगल बिलिंग अकाउंट लागत प्रबंधन को केंद्रीकृत करता है और ऑर्गनाइजेशन-वाइड छूट की अनुमति देता है।

संदर्भ↗

वित्तीय विभाग को तब सूचित करें जब प्रोजेक्ट का खर्च बजट के निश्चित प्रतिशत तक पहुँच जाए।

→Cloud Billing में, प्रोजेक्ट के लिए एक बजट बनाएं। कई अलर्ट थ्रेशोल्ड नियम (जैसे, 50%, 90%, 100%) सेट करें जो Pub/Sub टॉपिक या ईमेल पर सूचनाएं भेजते हैं।

क्यों: बजट अलर्ट करने के लिए हैं, खर्च रोकने के लिए नहीं। खर्च को स्वचालित रूप से सीमित करने के लिए, एक Pub/Sub नोटिफिकेशन को Cloud Function को ट्रिगर करना होगा ताकि बिलिंग को अक्षम किया जा सके या संसाधनों को बंद किया जा सके।

संदर्भ↗

बारीक, संसाधन-स्तर की क्लाउड लागतों का विश्लेषण करें और लागत केंद्र के अनुसार खर्च को ट्रैक करें।

→BigQuery डेटासेट में विस्तृत बिलिंग एक्सपोर्ट सक्षम करें। संसाधनों पर लेबल (जैसे, `cost-center: "finance"`) लागू करें। BigQuery टेबल को क्वेरी करें और विश्लेषण के लिए लेबल द्वारा ग्रुप करें।

क्यों: BigQuery को बिलिंग एक्सपोर्ट सबसे विस्तृत लागत डेटा प्रदान करता है, जिसमें लेबल शामिल हैं, जो कस्टम चार्जबैक और शोबैक मॉडल के लिए आवश्यक है।

संदर्भ↗

एक ऑर्गनाइजेशन के सभी प्रोजेक्ट्स में सुरक्षा और कॉन्फ़िगरेशन मानकों को लागू करें (जैसे, संसाधन स्थानों को प्रतिबंधित करना, यूनिफॉर्म बकेट एक्सेस की आवश्यकता, सार्वजनिक आईपी को अक्षम करना)।

→ऑर्गनाइजेशन या फ़ोल्डर स्तर पर ऑर्गनाइजेशन पॉलिसी कंस्ट्रेंट्स लागू करें। उदाहरण: डेटा रेज़िडेंसी के लिए `gcp.resourceLocations`, GCS सुरक्षा के लिए `storage.uniformBucketLevelAccess`, सार्वजनिक आईपी को रोकने के लिए `compute.vmExternalIpAccess`।

क्यों: ऑर्गनाइजेशन पॉलिसी विरासत में मिलती हैं और निवारक नियंत्रण प्रदान करती हैं, गैर-अनुपालन वाली कार्रवाइयों को होने से पहले ही रोक देती हैं। यह प्रतिक्रियाशील ऑडिटिंग से अधिक प्रभावी है।

संदर्भ↗

एक महत्वपूर्ण प्रोडक्शन प्रोजेक्ट के आकस्मिक विलोपन को रोकें।

→`gcloud alpha resource-manager liens create` का उपयोग करके प्रोजेक्ट पर एक lien लगाएं।

क्यों: एक lien एक प्रॉपर्टी है जो प्रोजेक्ट के विलोपन को रोकती है। इसे प्रोजेक्ट को डिलीट करने से पहले `resourcemanager.lienModifier` रोल वाले उपयोगकर्ता द्वारा स्पष्ट रूप से हटाना होगा।

gcloud CLI का उपयोग करते समय विभिन्न प्रोजेक्ट्स और उपयोगकर्ता खातों के बीच कुशलता से स्विच करें।

→प्रत्येक प्रोजेक्ट/खाते के लिए नामांकित कॉन्फ़िगरेशन बनाने के लिए `gcloud config configurations create` का उपयोग करें। `gcloud config configurations activate [CONFIG_NAME]` का उपयोग करके उनके बीच स्विच करें।

क्यों: कॉन्फ़िगरेशन प्रोजेक्ट, खाता, क्षेत्र और ज़ोन जैसी सेटिंग्स को स्टोर करते हैं, जिससे हर कमांड के साथ उन्हें निर्दिष्ट करने की आवश्यकता नहीं होती है।

परिवर्तनीय ट्रैफिक के साथ एक स्टेटलेस, कंटेनरीकृत HTTP माइक्रोसर्विस चलाएँ, परिचालन ओवरहेड और लागत को कम करें।

→कंटेनर को Cloud Run पर डिप्लॉय करें।

क्यों: Cloud Run पूरी तरह से प्रबंधित है, शून्य पर स्केल करता है (निष्क्रिय अवधियों के लिए लागत को समाप्त करता है), और आने वाले अनुरोधों के आधार पर स्वचालित रूप से स्केल करता है। यह स्टेटलेस वेब सेवाओं के लिए आदर्श है।

संदर्भ↗

सबसे कम संभव लागत पर एक फॉल्ट-टॉलरेंट, समय-लचीला बैच प्रोसेसिंग जॉब चलाएँ।

→एक Managed Instance Group में Spot VMs (पूर्व में Preemptible VMs) का उपयोग करें।

क्यों: Spot VMs ऑन-डिमांड मूल्य निर्धारण की तुलना में 91% तक की छूट प्रदान करते हैं। वे उन वर्कलोड के लिए उपयुक्त हैं जिन्हें रोका और पुनरारंभ किया जा सकता है, जैसे कई बैच प्रोसेसिंग जॉब्स।

एक वेब एप्लिकेशन डिप्लॉय करें जिसे उच्च उपलब्धता (उदाहरण के लिए, 99.9%) और ऑटोस्केलिंग की आवश्यकता है।

→एक ऑटोस्केलिंग पॉलिसी के साथ एक रीजनल Managed Instance Group (MIG) का उपयोग करें, जिसे Global External HTTP(S) Load Balancer के पीछे डिप्लॉय किया गया हो।

क्यों: एक रीजनल MIG फॉल्ट टॉलरेंस के लिए इंस्टेंस को कई ज़ोनों में स्वचालित रूप से वितरित करता है। ऑटोस्केलिंग मांग को पूरा करने के लिए क्षमता को समायोजित करता है, और लोड बैलेंसर एक सिंगल एंट्री पॉइंट प्रदान करता है।

उस डेटा को स्टोर करें जिसे 30 दिनों तक बार-बार एक्सेस किया जाता है, फिर एक साल के लिए कभी-कभी, फिर संग्रहीत किया जाता है।

→एक Cloud Storage Standard क्लास बकेट में स्टोर करें। 30 दिनों के बाद Nearline/Coldline में और 365 दिनों के बाद Archive में ऑब्जेक्ट्स को ट्रांज़िशन करने के लिए एक लाइफसाइकल नियम बनाएँ।

क्यों: लाइफसाइकल नियम उम्र या अन्य स्थितियों के आधार पर डेटा को सस्ती स्टोरेज क्लास में ले जाकर लागत अनुकूलन को स्वचालित करते हैं, बिना मैन्युअल हस्तक्षेप के।

संदर्भ↗

एक विश्व स्तर पर वितरित एप्लिकेशन को क्षैतिज स्केलेबिलिटी और मजबूत कंसिस्टेंसी के साथ एक रिलेशनल डेटाबेस की आवश्यकता है।

→Cloud Spanner का उपयोग करें।

क्यों: Cloud Spanner एकमात्र सेवा है जो SQL सपोर्ट के साथ विश्व स्तर पर वितरित, मजबूत कंसिस्टेंट, रिलेशनल डेटाबेस प्रदान करती है। Cloud SQL रीजनल है।

एक एप्लिकेशन को 99.95% उपलब्धता SLA और स्वचालित फेलओवर के साथ एक प्रबंधित PostgreSQL या MySQL डेटाबेस की आवश्यकता है।

→High Availability (HA) कॉन्फ़िगरेशन सक्षम के साथ Cloud SQL का उपयोग करें।

क्यों: HA कॉन्फ़िगरेशन एक प्राइमरी इंस्टेंस और एक अलग ज़ोन में एक स्टैंडबाय इंस्टेंस बनाता है। डेटा को सिंक्रोनस रूप से रेप्लिकेट किया जाता है, और फेलओवर स्वचालित होता है।

एक 3-टियर एप्लिकेशन (वेब, ऐप, डीबी) के लिए एक VPC डिज़ाइन करें जहाँ डेटाबेस टियर इंटरनेट से एक्सेस नहीं होना चाहिए।

→प्रत्येक टियर के लिए एक अलग सबनेट के साथ एक कस्टम-मोड VPC बनाएँ। डेटाबेस इंस्टेंस को उनके समर्पित सबनेट में केवल प्राइवेट IP एड्रेस के साथ प्रोविज़न करें।

क्यों: अलग-अलग सबनेट में टियर्स को आइसोलेट करने से ग्रेन्युलर फ़ायरवॉल नियमों की अनुमति मिलती है। डेटाबेस इंस्टेंस पर बाहरी आईपी को छोड़ना इंटरनेट एक्सेस को रोकने का सबसे सीधा तरीका है।

GKE पर एक स्टेटफुल एप्लिकेशन (उदाहरण के लिए, एक डेटाबेस) डिप्लॉय करें जिसे स्थिर नेटवर्क पहचानकर्ताओं और परसिस्टेंट स्टोरेज की आवश्यकता है।

→PersistentVolumeClaim टेम्प्लेट के साथ एक StatefulSet का उपयोग करें।

क्यों: StatefulSets को स्टेटफुल वर्कलोड के लिए डिज़ाइन किया गया है, जो स्थिर होस्टनाम (जैसे, `pod-0`, `pod-1`) प्रदान करता है और प्रत्येक रेप्लिका के लिए स्वचालित रूप से एक अद्वितीय PersistentVolume प्रोविज़न करता है।

एक लेटेंसी-सेंसिटिव Cloud Run सेवा को ट्रैफिक स्पाइक्स के दौरान कोल्ड स्टार्ट से बचना चाहिए।

→सेवा को `--min-instances` फ्लैग को 1 या उससे अधिक पर सेट करके डिप्लॉय करें।

क्यों: न्यूनतम इंस्टेंस सेट करने से निर्दिष्ट संख्या में कंटेनर "वार्म" और अनुरोधों को पूरा करने के लिए तैयार रहते हैं, जिससे एक नया कंटेनर शुरू करने से जुड़ी लेटेंसी समाप्त हो जाती है।

जब भी Cloud Storage बकेट में कोई नई फ़ाइल अपलोड की जाती है, तो सर्वरलेस फ़ंक्शन को स्वचालित रूप से निष्पादित करें।

→निर्दिष्ट बकेट पर `google.cloud.storage.object.v1.finalized` इवेंट के लिए Eventarc ट्रिगर के साथ एक Cloud Function (2nd Gen) डिप्लॉय करें।

क्यों: Eventarc एक एकीकृत, इवेंट-ड्रिवन आर्किटेक्चर प्रदान करता है। GCS ट्रिगर स्टोरेज इवेंट्स को सर्वरलेस कंप्यूट से बिना पोलिंग के कनेक्ट करने का मानक, प्रबंधित तरीका है।

परीक्षण के लिए App Engine एप्लिकेशन का एक नया संस्करण डिप्लॉय करें, बिना तुरंत प्रोडक्शन ट्रैफिक को उस पर भेजे।

→`gcloud app deploy --no-promote` का उपयोग करके नया संस्करण डिप्लॉय करें।

क्यों: `--no-promote` फ्लैग नया संस्करण बनाता है लेकिन उस पर कोई ट्रैफिक शिफ्ट नहीं करता है। आप इसे इसके संस्करण-विशिष्ट URL का उपयोग करके परीक्षण कर सकते हैं और तैयार होने पर मैन्युअल रूप से ट्रैफिक माइग्रेट कर सकते हैं।

Compute Engine इंस्टेंस पर चल रहे एक वेब एप्लिकेशन के लिए एक ग्लोबल HTTP(S) लोड बैलेंसर बनाएँ।

→इन घटकों को क्रम में बनाएँ: Instance Group (VMs के साथ), Health Check, Backend Service (IG और HC की ओर इशारा करते हुए), URL Map, Target HTTP(S) Proxy, और एक Global Forwarding Rule (सार्वजनिक IP के साथ)।

क्यों: यह अनुक्रम बैकएंड (इंस्टेंस) से फ्रंटएंड (फ़ॉरवर्डिंग रूल) तक लोड बैलेंसर को सही ढंग से बनाता है। प्रत्येक घटक रूटिंग और हेल्थ चेकिंग में एक विशिष्ट उद्देश्य पूरा करता है।

एक टीम को सहयोगात्मक रूप से Terraform स्टेट का प्रबंधन करने की आवश्यकता है, सुरक्षा सुनिश्चित करना और समवर्ती संशोधनों को रोकना।

→Terraform बैकएंड के रूप में एक Cloud Storage बकेट का उपयोग करें। इतिहास और रिकवरी के लिए ऑब्जेक्ट संस्करण सक्षम करें। GCS बैकएंड द्वारा स्टेट लॉकिंग स्वचालित रूप से संभाली जाती है।

क्यों: एक रिमोट GCS बैकएंड GCP पर टीम सहयोग के लिए मानक है। यह स्टेट करप्शन को रोकने के लिए लॉकिंग और रोलबैक क्षमताओं के लिए संस्करण प्रदान करता है।

जब किसी समूह में किसी भी VM पर CPU उपयोग 80% से अधिक एक निरंतर अवधि (जैसे, 5 मिनट) के लिए हो, तो एक सूचना प्राप्त करें।

→Cloud Monitoring में, एक Alerting Policy बनाएँ। शर्त को `Metric: CPU utilization > 80%` `Duration: 5 minutes` के लिए सेट करें। एक नोटिफिकेशन चैनल (जैसे, ईमेल, PagerDuty) कॉन्फ़िगर करें।

क्यों: Cloud Monitoring मेट्रिक-आधारित अलर्ट बनाने के लिए देशी सेवा है। उपयोग में संक्षिप्त, सामान्य स्पाइक्स से "फ्लैपिंग" अलर्ट से बचने के लिए अवधि की स्थिति महत्वपूर्ण है।

अनुपालन के लिए 7 साल तक विशिष्ट ऑडिट लॉग बनाए रखें, जबकि अन्य लॉग को 30 दिनों के लिए रखें।

→ऑडिट लॉग के लिए एक फ़िल्टर के साथ एक लॉग सिंक बनाएँ। सिंक को Cloud Storage बकेट में एक्सपोर्ट करने के लिए कॉन्फ़िगर करें। बकेट पर 7 साल की रिटेंशन पॉलिसी लागू करें।

क्यों: Cloud Logging की सीमित रिटेंशन अवधि है (एडमिन एक्टिविटी के लिए अधिकतम 400 दिन)। सिंक लॉग को लंबी अवधि के, सस्ते स्टोरेज जैसे GCS या BigQuery में विश्लेषण के लिए रूट करने का तंत्र हैं।

एक GKE पॉड `CrashLoopBackOff` स्थिति में है। आपको कंटेनर के क्रैश होने से ठीक पहले के लॉग देखने की आवश्यकता है।

→`kubectl logs [POD_NAME] --previous` कमांड का उपयोग करें।

क्यों: जब कोई कंटेनर क्रैश होता है और पुनरारंभ होता है, तो `kubectl logs` *नए* कंटेनर के लॉग दिखाता है। क्रैश का निदान करने के लिए समाप्त इंस्टेंस के लॉग देखने के लिए `--previous` फ्लैग आवश्यक है।

एक प्रबंधित इंस्टेंस समूह को उन इंस्टेंस को स्वचालित रूप से बदलना चाहिए जो अनुत्तरदायी हो जाते हैं।

→एक हेल्थ चेक (उदाहरण के लिए, HTTP, TCP) कॉन्फ़िगर करें और इसे प्रबंधित इंस्टेंस समूह की ऑटोहीलिंग पॉलिसी पर लागू करें।

क्यों: MIG हेल्थ चेक के आधार पर इंस्टेंस को समय-समय पर जांचता है। यदि कोई इंस्टेंस लगातार जांचों में विफल रहता है, तो MIG स्वचालित रूप से उसे टेम्प्लेट से हटा देता है और फिर से बनाता है, जिससे एप्लिकेशन की उपलब्धता सुनिश्चित होती है।

Cloud SQL डेटाबेस में एक डेटा करप्शन इवेंट हुआ। आपको डेटाबेस को घटना से 5 मिनट पहले की स्थिति में पुनर्स्थापित करने की आवश्यकता है।

→यह सुनिश्चित करें कि Point-in-Time Recovery (PITR) इंस्टेंस पर पहले से सक्षम हो। एक रिस्टोर ऑपरेशन करें, रिकवर करने के लिए सटीक टाइमस्टैम्प निर्दिष्ट करें।

क्यों: PITR बाइनरी लॉगिंग के सक्षम होने पर निर्भर करता है। यह रिटेंशन विंडो के भीतर किसी भी समय बिंदु पर ग्रेन्युलर रिकवरी की अनुमति देता है, जो डेटा हानि को कम करने के लिए महत्वपूर्ण है (कम RPO)।

Compute Engine परसिस्टेंट डिस्क के दैनिक बैकअप को स्वचालित करें और उन्हें 14 दिनों के लिए बनाए रखें।

→डिस्क स्नैपशॉट के लिए एक Resource Policy बनाएँ। एक दैनिक शेड्यूल और 14-दिवसीय रिटेंशन पॉलिसी कॉन्फ़िगर करें। इस पॉलिसी को टारगेट परसिस्टेंट डिस्क से अटैच करें।

क्यों: स्नैपशॉट शेड्यूल GCE बैकअप को स्वचालित करने का प्रबंधित, "फायर-एंड-फॉरगेट" तरीका है। यह cron जॉब या कस्टम स्क्रिप्ट का उपयोग करने की तुलना में अधिक विश्वसनीय और रखरखाव योग्य है।

एक Compute Engine इंस्टेंस को Cloud Storage बकेट से पढ़ने और BigQuery टेबल में लिखने की आवश्यकता है। न्यूनतम आवश्यक अनुमतियाँ प्रदान करें।

→एक कस्टम सर्विस अकाउंट बनाएँ। इसे `roles/storage.objectViewer` और `roles/bigquery.dataEditor` रोल प्रदान करें। इस सर्विस अकाउंट को इंस्टेंस से अटैच करें।

क्यों: विशिष्ट, पूर्वनिर्धारित भूमिकाओं के साथ एक कस्टम सर्विस अकाउंट का उपयोग करने से डिफ़ॉल्ट Compute Engine सर्विस अकाउंट की अत्यधिक अनुमति देने वाली प्रकृति से बचा जाता है, जिससे कम विशेषाधिकार के सिद्धांत का पालन होता है।

किसी उपयोगकर्ता को GCE इंस्टेंस प्रबंधित करने की अनुमति दें, लेकिन उन्हें हटाने की नहीं।

→एक कस्टम IAM रोल बनाएँ। `roles/compute.instanceAdmin.v1` रोल से अनुमतियों के साथ शुरू करें और `compute.instances.delete` अनुमति हटा दें।

क्यों: कस्टम रोल विशिष्ट जॉब फ़ंक्शन के लिए पूर्वनिर्धारित रोल बहुत व्यापक या बहुत प्रतिबंधात्मक होने पर अनुमतियों का एक सटीक सेट प्रदान करने की लचीलापन प्रदान करते हैं।

एक डेवलपर को सुरक्षा नीति के अनुसार Compute Engine इंस्टेंस में SSH करने की आवश्यकता है जिसका कोई बाहरी IP एड्रेस नहीं है।

→डेवलपर को `roles/iap.tunnelResourceAccessor` रोल प्रदान करें। वे फिर `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap` का उपयोग करके कनेक्ट कर सकते हैं।

क्यों: Identity-Aware Proxy (IAP) TCP फॉरवर्डिंग बैस्टियन होस्ट्स, VPNs, या सार्वजनिक IP के बिना आंतरिक इंस्टेंस तक पहुंचने के लिए एक सुरक्षित, पहचान-आधारित विधि प्रदान करती है।

संदर्भ↗

केवल कॉर्पोरेट ऑफिस IP रेंज से विशिष्ट VMs पर इनबाउंड SSH (पोर्ट 22) ट्रैफिक की अनुमति दें।

→`direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]`, और `target tags: [उदाहरण के लिए, "allow-ssh"]` के साथ एक VPC फ़ायरवॉल नियम बनाएँ। टैग को इच्छित VMs पर लागू करें।

क्यों: सोर्स रेंज और टारगेट टैग्स को मिलाकर ट्रैफिक को नियंत्रित करने का एक सटीक और स्केलेबल तरीका मिलता है। यह प्रतिबंधित करता है कि *कौन* कनेक्ट कर सकता है और *किससे* कनेक्ट कर सकता है।

संवेदनशील BigQuery प्रोजेक्ट से डेटा को एक विश्वसनीय नेटवर्क सीमा के बाहर से कॉपी या एक्सेस होने से रोकें, भले ही वैध क्रेडेंशियल्स हों।

→VPC Service Controls कॉन्फ़िगर करें। एक सर्विस पेरिमेटर बनाएँ जिसमें संवेदनशील प्रोजेक्ट शामिल हो और BigQuery API को प्रतिबंधित करे।

क्यों: VPC Service Controls एक वर्चुअल "डेटा पेरिमेटर" बनाते हैं जो API-स्तर के एक्सेस को नियंत्रित करता है, डेटा एक्सफ़िल्ट्रेशन के खिलाफ एक मजबूत बचाव प्रदान करता है जो फ़ायरवॉल नियम नहीं कर सकते।

एक तृतीय-पक्ष एप्लिकेशन को Cloud Storage बकेट में एक विशिष्ट प्राइवेट ऑब्जेक्ट तक अस्थायी, समय-सीमित रीड एक्सेस प्रदान करें।

→रीड अनुमतियों वाले एक सर्विस अकाउंट का उपयोग करके एक छोटी समाप्ति अवधि (जैसे, 15 मिनट) के साथ ऑब्जेक्ट के लिए एक साइन्ड URL जनरेट करें।

क्यों: साइन्ड URL अस्थायी, प्रति-ऑब्जेक्ट एक्सेस प्रदान करते हैं, बिना तीसरे पक्ष को Google अकाउंट या IAM अनुमतियों की आवश्यकता के। यह इस उपयोग के मामले के लिए सबसे सुरक्षित तरीका है।

एक GKE पॉड को Google Cloud APIs (जैसे, Pub/Sub) को सुरक्षित रूप से एक्सेस करने की आवश्यकता है, बिना सर्विस अकाउंट कीज़ को Kubernetes सीक्रेट्स के रूप में स्टोर किए।

→GKE क्लस्टर पर Workload Identity सक्षम करें। एक Google Service Account (GSA) और एक Kubernetes Service Account (KSA) बनाएँ। IAM पॉलिसी का उपयोग करके KSA को GSA से बाइंड करें। पॉड को KSA का उपयोग करने के लिए कॉन्फ़िगर करें।

क्यों: Workload Identity GKE एप्लिकेशन के लिए Google Cloud सेवाओं के लिए प्रमाणीकरण का अनुशंसित, कीलेस तरीका है। यह KSA पहचानों को GSA पहचानों से मैप करता है, जो कुंजी फ़ाइलों को प्रबंधित और घुमाने से अधिक सुरक्षित है।

संदर्भ↗

एक ऑर्गनाइजेशन नीति की आवश्यकता है कि Cloud Storage बकेट में सभी डेटा को एक एन्क्रिप्शन कुंजी का उपयोग करके एन्क्रिप्ट किया जाए जिसे ऑर्गनाइजेशन नियंत्रित करता है।

→Cloud KMS में एक क्रिप्टोग्राफिक कुंजी बनाएँ। Cloud Storage बकेट बनाते समय, इस कुंजी को Customer-Managed Encryption Key (CMEK) के रूप में निर्दिष्ट करें।

क्यों: CMEK आपको एन्क्रिप्शन के लिए उपयोग की जाने वाली कुंजी पर नियंत्रण प्रदान करता है, जिसमें रोटेशन और निरस्तीकरण शामिल है, जबकि अभी भी Google के प्रबंधित एन्क्रिप्शन इन्फ्रास्ट्रक्चर का लाभ उठा रहा है।

कर्मचारियों को Google Cloud संसाधनों तक पहुंचने के लिए अपनी मौजूदा ऑन-प्रिमाइसेस Active Directory क्रेडेंशियल्स का उपयोग करने की अनुमति दें।

→SAML 2.0 का उपयोग करके Active Directory के साथ फेडरेट करने के लिए Cloud Identity को कॉन्फ़िगर करें। उपयोगकर्ता AD के साथ प्रमाणित करते हैं, जो फिर एक्सेस के लिए अपनी पहचान Google Cloud को बताता है।

क्यों: फेडरेशन सिंगल साइन-ऑन (SSO) की अनुमति देता है और मौजूदा IdP (Active Directory) में पहचान प्रबंधन को केंद्रीकृत करता है, जिससे Google Cloud में पासवर्ड के एक अलग सेट का प्रबंधन करने की आवश्यकता नहीं होती है।

एक बाहरी ठेकेदार को एक प्रोजेक्ट तक अस्थायी एक्सेस प्रदान करें, जो 30 दिनों के बाद स्वचालित रूप से समाप्त हो जाना चाहिए।

→ठेकेदार को आवश्यक भूमिका के साथ एक IAM सदस्य के रूप में जोड़ें। एक समाप्ति टाइमस्टैम्प (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`) के साथ भूमिका बाइंडिंग में एक शर्त जोड़ें।

क्यों: IAM Conditions एट्रिब्यूट-आधारित एक्सेस कंट्रोल प्रदान करती हैं। समय-आधारित शर्तें अस्थायी एक्सेस के लिए एकदम सही हैं, क्योंकि वे मैन्युअल सफाई के बिना अनुमतियों को स्वचालित रूप से रद्द कर देती हैं।