इस कोडलैब में, IAM की शर्तों और कस्टम रोल का इस्तेमाल करके, Cloud DNS में अलग-अलग डीएनएस रिकॉर्ड सेट के लिए, सटीक ऐक्सेस कंट्रोल लागू करने का तरीका बताया गया है.
परिचय
Cloud DNS में, पारंपरिक तौर पर प्रोजेक्ट और मैनेज किए गए ज़ोन के लेवल पर IAM की अनुमतियां सेट की जा सकती हैं. इससे, किसी ज़ोन में मौजूद सभी रिकॉर्ड का ऐक्सेस मिल जाता है. हालांकि, बड़े कारोबारों के लिए, यह "कम से कम अधिकारों के सिद्धांत" के मुताबिक नहीं है.
इस कोडलैब में, Cloud DNS में हर रिकॉर्ड सेट के लिए IAM की अनुमतियां कॉन्फ़िगर करने का तरीका बताया जाएगा. इस सुविधा की मदद से, मैनेज किए गए एक ही ज़ोन में, अलग-अलग टीमों को खास सबडोमेन या रिकॉर्ड टाइप मैनेज करने की अनुमति दी जा सकती है.
इस कोडलैब में आपको ये बातें सीखने को मिलेंगी
- डीएनएस रिकॉर्ड के मैनेजमेंट को सीमित करने के लिए, IAM की शर्तों का इस्तेमाल करने का तरीका.
- कस्टम रोल बनाने की वजह और तरीका.
- सबडोमेन और खास रिकॉर्ड टाइप (उदाहरण के लिए: A, MX) को डेलिगेट करने का तरीका.
--skip-soa-updateफ़्लैग का इस्तेमाल करके, शर्तों के हिसाब से अनुमतियों के साथ डीएनएस लेन-देन को मैनेज करने का तरीका.
ज़रूरी शर्तें
- एक Google खाता
- बिलिंग की सुविधा वाला Google Cloud प्रोजेक्ट
- Google Cloud CLI का नया वर्शन इंस्टॉल और कॉन्फ़िगर किया गया हो
- डीएनएस और IAM के कॉन्सेप्ट की बुनियादी जानकारी
सेट अप करना
अवधि: 03:00
Cloud DNS API को चालू करना
gcloud CLI में लॉग इन करें और एपीआई को चालू करें.
gcloud auth login
gcloud services enable dns.googleapis.com
कोई टेस्ट प्रोजेक्ट बनाना
अगर आपके पास कोई प्रोजेक्ट नहीं है, तो अभी एक प्रोजेक्ट बनाएं और gcloud कॉन्फ़िगरेशन को उस प्रोजेक्ट पर सेट करें, ताकि सभी कमांड उस प्रोजेक्ट को टारगेट करें.
gcloud projects create my-dns-per-rrset-lab
gcloud config set project my-dns-per-rrset-lab
अलग-अलग तरीकों के बारे में जानकारी
अवधि: 02:00
डीएनएस रिकॉर्ड में बदलाव करने के लिए, मुख्य खाते के पास रिकॉर्ड में बदलाव करने और 'बदलाव' रिसॉर्स पर उससे जुड़ी कार्रवाइयां करने की अनुमति होनी चाहिए.
इसे दो तरीकों से कॉन्फ़िगर किया जा सकता है:
पहला विकल्प: स्टैंडर्ड रोल का इस्तेमाल करना (सुझाया गया)
IAM की शर्त को सीधे तौर पर, स्टैंडर्ड roles/dns.admin रोल से जोड़ा जा सकता है. रिकॉर्ड में बदलाव करने और 'बदलाव' रिसॉर्स पर कार्रवाइयां करने, दोनों के लिए, ज़्यादा व्यापक CEL शर्त का इस्तेमाल किया जाता है. इससे, रिकॉर्ड सेट के अलावा अन्य ज़रूरी रिसॉर्स का ऐक्सेस मिलता है.
- अनुमति देने वाली शर्त: इससे, डीएनएस से जुड़ी अन्य सभी एडमिन कार्रवाइयां की जा सकती हैं. अगर पूरक रोल में, एडमिन से जुड़ी अन्य सभी स्टैंडर्ड अनुमतियां शामिल हैं, तो यह दूसरे विकल्प के बराबर है.
cel (resource.type == 'dns.googleapis.com/ResourceRecordSet' && <RRSET_CONDITION>) || (resource.type != 'dns.googleapis.com/ResourceRecordSet') - सीमित करने वाली शर्त: इससे, सिर्फ़ रिकॉर्ड सेट में बदलाव किया जा सकता है और 'बदलाव' रिसॉर्स पर कार्रवाइयां की जा सकती हैं. एडमिन से जुड़ी अन्य कार्रवाइयां ब्लॉक कर दी जाती हैं. इनमें रिकॉर्ड सेट की सूची देखना (
dns.resourceRecordSets.list) और मैनेज किए गए ज़ोन की जानकारी देखना शामिल है.cel (resource.type == 'dns.googleapis.com/ResourceRecordSet' && <RRSET_CONDITION>) || (resource.type == 'dns.googleapis.com/Change')
हमारा सुझाव है कि आप यह तरीका अपनाएं, क्योंकि इसके लिए कस्टम रोल बनाने और उन्हें मैनेज करने की ज़रूरत नहीं होती.
दूसरा विकल्प: कस्टम रोल का इस्तेमाल करना
अगर आपको आसान शर्तों का इस्तेमाल करना है, तो रिकॉर्ड सेट के मैनेजमेंट को एडमिन से जुड़े अन्य टास्क से अलग किया जा सकता है. इसके लिए, दो कस्टम रोल का इस्तेमाल करें:
- DnsRecordSetAdmin: इसमें, रिसॉर्स रिकॉर्ड सेट बनाने, मिटाने, पाने, और अपडेट करने की अनुमतियां शामिल होती हैं. यह रोल शर्तों के हिसाब से दिया जाएगा.
- DnsNonRecordSetAdmin: इसमें, डीएनएस से जुड़ी एडमिन की अन्य सभी अनुमतियां शामिल होती हैं. जैसे, ज़ोन मैनेज करना, रिकॉर्ड की सूची देखना, और प्रोजेक्ट की जानकारी देखना. यह रोल बिना किसी शर्त के दिया जाएगा.
कस्टम रोल बनाना
अवधि: 05:00
[!NOTE] यह चरण सिर्फ़ तब ज़रूरी है, जब आपने दूसरा विकल्प: कस्टम रोल का इस्तेमाल करना चुना हो. अगर आपने पहला विकल्प: स्टैंडर्ड रोल का इस्तेमाल करना चुना है, तो इस चरण को छोड़ा जा सकता है.
अपने प्रोजेक्ट में ज़रूरी कस्टम रोल बनाने के लिए, ये कमांड चलाएं.
अनुमतियों के सेट तय करना
# Record set management permissions
rs_perms="dns.resourceRecordSets.create,dns.resourceRecordSets.delete,dns.resourceRecordSets.get,dns.resourceRecordSets.update"
# Complementary administrative permissions
comp_perms="compute.networks.get,compute.networks.list,dns.changes.create,dns.changes.get,dns.changes.list,dns.dnsKeys.get,dns.dnsKeys.list,dns.gkeClusters.bindDNSResponsePolicy,dns.gkeClusters.bindPrivateDNSZone,dns.managedZoneOperations.get,dns.managedZoneOperations.list,dns.managedZones.create,dns.managedZones.delete,dns.managedZones.get,dns.managedZones.getIamPolicy,dns.managedZones.list,dns.managedZones.update,dns.networks.bindDNSResponsePolicy,dns.networks.bindPrivateDNSPolicy,dns.networks.bindPrivateDNSZone,dns.networks.targetWithPeeringZone,dns.networks.useHealthSignals,dns.policies.create,dns.policies.createTagBinding,dns.policies.delete,dns.policies.deleteTagBinding,dns.policies.get,dns.policies.list,dns.policies.listEffectiveTags,dns.policies.listTagBindings,dns.policies.update,dns.projects.get,dns.resourceRecordSets.list,dns.responsePolicies.create,dns.responsePolicies.delete,dns.responsePolicies.get,dns.responsePolicies.list,dns.responsePolicies.update,dns.responsePolicyRules.create,dns.responsePolicyRules.delete,dns.responsePolicyRules.get,dns.responsePolicyRules.list,dns.responsePolicyRules.update,resourcemanager.projects.get"
Gcloud में रोल बनाना
gcloud iam roles create DnsRecordSetAdmin --project=$(gcloud config get-value project) \
--title="DNS Record Set Admin (Conditional)" --permissions="${rs_perms}"
gcloud iam roles create DnsNonRecordSetAdmin --project=$(gcloud config get-value project) \
--title="DNS Complimentary Admin" --permissions="${comp_perms}"
Scenario 1: रिकॉर्ड का सटीक मिलान
अवधि: 05:00
इस स्थिति में, आपको किसी टीम को सिर्फ़ api.example.com. के लिए A रिकॉर्ड मैनेज करने की अनुमति देनी है.
मैनेज किया गया ज़ोन बनाना
gcloud dns managed-zones create example-zone \
--description="Lab zone for per-RRSet permissions" \
--dns-name=example.com. --visibility=private \
--networks=default
कोई टेस्ट सेवा खाता बनाना
सीमित की गई अनुमतियों की पुष्टि करने के लिए, इस सेवा खाते का इस्तेमाल किया जाएगा.
gcloud iam service-accounts create dns-restricted-sa \
--display-name="Restricted DNS SA"
SA_EMAIL="dns-restricted-sa@$(gcloud config get-value project).iam.gserviceaccount.com"
शर्तों के हिसाब से IAM की नीति लागू करना
नीति लागू करने के लिए, इनमें से कोई एक विकल्प चुनें.
पहला विकल्प: स्टैंडर्ड रोल का इस्तेमाल करना (सुझाया गया)
इस विकल्प में, अनुमति देने वाली शर्त के साथ dns.admin स्टैंडर्ड रोल का इस्तेमाल किया जाता है.
cat << EOF > policy.json
{
"bindings": [
{
"role": "roles/dns.admin",
"members": ["serviceAccount:${SA_EMAIL}"],
"condition": {
"expression": "(resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/rrsets/api.example.com./A')) || (resource.type != 'dns.googleapis.com/ResourceRecordSet')",
"title": "Exact Record Match (Standard Role)"
}
}
],
"version": 3
}
EOF
gcloud dns managed-zones set-iam-policy example-zone --policy-file=policy.json
दूसरा विकल्प: कस्टम रोल का इस्तेमाल करना
इस विकल्प में, पिछले चरण में बनाए गए कस्टम रोल का इस्तेमाल किया जाता है.
cat << EOF > policy_custom.json
{
"bindings": [
{
"role": "projects/$(gcloud config get-value project)/roles/DnsRecordSetAdmin",
"members": ["serviceAccount:${SA_EMAIL}"],
"condition": {
"expression": "resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.endsWith('/rrsets/api.example.com./A')",
"title": "Exact Record Match (Custom Roles)"
}
},
{
"role": "projects/$(gcloud config get-value project)/roles/DnsNonRecordSetAdmin",
"members": ["serviceAccount:${SA_EMAIL}"]
}
],
"version": 3
}
EOF
gcloud dns managed-zones set-iam-policy example-zone --policy-file=policy_custom.json
सीमा की पुष्टि करना
अनुमति वाले रिकॉर्ड को बनाने की कोशिश करें. इसके बाद, बिना अनुमति वाले रिकॉर्ड को बनाने की कोशिश करें.
# ALLOWED: Create the specific A record
gcloud dns record-sets create api.example.com. --zone=example-zone --type=A --rrdatas="1.2.3.4" --ttl=300 --impersonate-service-account=${SA_EMAIL}
# DENIED: Create an unauthorized name
gcloud dns record-sets create www.example.com. --zone=example-zone --type=A --rrdatas="5.6.7.8" --ttl=300 --impersonate-service-account=${SA_EMAIL}
Scenario 2: सबडोमेन को डेलिगेट करना
अवधि: 05:00
अब, p.example.com. सबडोमेन में मौजूद किसी भी रिकॉर्ड को मैनेज करने की अनुमति दें.
IAM की नीति अपडेट करना
नीति अपडेट करने के लिए, इनमें से कोई एक विकल्प चुनें.
पहला विकल्प: स्टैंडर्ड रोल का इस्तेमाल करना (सुझाया गया)
cat << EOF > policy_subdomain.json
{
"bindings": [
{
"role": "roles/dns.admin",
"members": ["serviceAccount:${SA_EMAIL}"],
"condition": {
"expression": "(resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.extract('/rrsets/{name}/').endsWith('.p.example.com.')) || (resource.type != 'dns.googleapis.com/ResourceRecordSet')",
"title": "Subdomain Delegation (Standard Role)"
}
}
],
"version": 3
}
EOF
gcloud dns managed-zones set-iam-policy example-zone --policy-file=policy_subdomain.json
दूसरा विकल्प: कस्टम रोल का इस्तेमाल करना
cat << EOF > policy_subdomain_custom.json
{
"bindings": [
{
"role": "projects/$(gcloud config get-value project)/roles/DnsRecordSetAdmin",
"members": ["serviceAccount:${SA_EMAIL}"],
"condition": {
"expression": "resource.type == 'dns.googleapis.com/ResourceRecordSet' && resource.name.extract('/rrsets/{name}/').endsWith('.p.example.com.')",
"title": "Subdomain Delegation (Custom Roles)"
}
},
{
"role": "projects/$(gcloud config get-value project)/roles/DnsNonRecordSetAdmin",
"members": ["serviceAccount:${SA_EMAIL}"]
}
],
"version": 3
}
EOF
gcloud dns managed-zones set-iam-policy example-zone --policy-file=policy_subdomain_custom.json
डेलिगेशन की पुष्टि करना
# ALLOWED: Create any record in the subdomain
gcloud dns record-sets create test.p.example.com. --zone=example-zone --type=A --rrdatas="192.168.1.1" --ttl=300 --impersonate-service-account=${SA_EMAIL}
# DENIED: Create a record outside the subdomain
gcloud dns record-sets create news.example.com. --zone=example-zone --type=A --rrdatas="192.168.1.2" --ttl=300 --impersonate-service-account=${SA_EMAIL}
Scenario 3: बैच में बदलाव करना और लेन-देन करना
अवधि: 03:00
शर्तों के हिसाब से अनुमतियों का इस्तेमाल करते समय, लेन-देन के लिए एक ज़रूरी जानकारी होती है.
डिफ़ॉल्ट रूप से, डीएनएस लेन-देन में SOA रिकॉर्ड को अपडेट करने की कोशिश की जाती है. अगर IAM की शर्त के तहत, उपयोगकर्ताओं को सिर्फ़ खास रिकॉर्ड (जैसे, api.example.com.) मैनेज करने की अनुमति मिलती है, तो लेन-देन पूरा नहीं हो पाएगा. ऐसा इसलिए, क्योंकि उपयोगकर्ता के पास SOA रिकॉर्ड में बदलाव करने की अनुमति नहीं है.
--skip-soa-update फ़्लैग
किसी लेन-देन में अनुमति वाले रिकॉर्ड में बदलाव करने के लिए, आपको या तो अपनी शर्त में बदलाव करके, SOA अपडेट की अनुमति देनी चाहिए (resource.name.endsWith('/SOA')) या --skip-soa-update फ़्लैग का इस्तेमाल करना चाहिए.
gcloud dns record-sets transaction start --zone=example-zone --skip-soa-update
gcloud dns record-sets transaction add --zone=example-zone --name="api.example.com." --type=A --ttl=300 "10.0.0.1"
gcloud dns record-sets transaction execute --zone=example-zone --impersonate-service-account=${SA_EMAIL}
ध्यान दें: अगर किसी लेन-देन में, बिना अनुमति वाले रिकॉर्ड में एक भी बदलाव किया जाता है, तो पूरे लेन-देन को अस्वीकार कर दिया जाएगा.
स्टोरेज में जगह बनाएं
अवधि: 01:00
इस कोडलैब में बनाए गए रिसॉर्स मिटाएं, ताकि आपसे शुल्क न लिया जाए.
# Delete record sets
gcloud dns record-sets delete api.example.com. --zone=example-zone --type=A
gcloud dns record-sets delete test.p.example.com. --zone=example-zone --type=A
# Delete managed zone
gcloud dns managed-zones delete example-zone
# Delete custom roles (only if you created them in Option 2)
gcloud iam roles delete DnsRecordSetAdmin --project=$(gcloud config get-value project) || true
gcloud iam roles delete DnsNonRecordSetAdmin --project=$(gcloud config get-value project) || true
# Delete service account
gcloud iam service-accounts delete ${SA_EMAIL}
बधाई हो
बधाई हो! आपने Cloud DNS में, हर रिकॉर्ड सेट के लिए विस्तृत IAM अनुमतियां लागू करने का तरीका सीख लिया है.
हमने इस कोडलैब में क्या-क्या कवर किया
- रिकॉर्ड सेट की अनुमतियों को ज़ोन-लेवल के एडमिन टास्क से अलग करने के लिए, कस्टम रोल बनाए.
- रिकॉर्ड के खास नामों और टाइप के लिए, सटीक मिलान की शर्त लागू की.
- IAM की शर्तों में स्ट्रिंग एक्सट्रैक्शन का इस्तेमाल करके, सबडोमेन को डेलिगेट करने की सुविधा लागू की.
- शर्तों के हिसाब से अनुमतियां पाने वाले उपयोगकर्ताओं को बैच में बदलाव करने की अनुमति देने के लिए,
--skip-soa-updateफ़्लैग का इस्तेमाल किया.