Terraform 0.11

S3




terraform

S3

तरह: मानक (DynamoDB के माध्यम से लॉक करने के साथ)

अमेज़न S3 पर दिए गए बकेट में दिए गए कुंजी के रूप में राज्य को संग्रहीत करता है । यह बैकएंड डायनमो डीबी के माध्यम से स्टेट लॉकिंग और कंसिस्टेंसी चेकिंग का भी समर्थन करता है, जिसे dynamodb_table क्षेत्र को मौजूदा डायनेमोडी टेबल के नाम पर सेट करके सक्षम किया जा सकता है।

उदाहरण विन्यास

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key"
    region = "us-east-1"
  }
}

यह माना जाता है कि हमारे पास एक बाल्टी है जिसे mybucket कहा जाता है। टेराफॉर्म राज्य कुंजी path/to/my/key को लिखा गया है।

ध्यान दें कि एक्सेस क्रेडेंशियल्स के लिए हम एक आंशिक कॉन्फ़िगरेशन का उपयोग करने की सलाह देते हैं।

S3 बाल्टी अनुमतियाँ

Terraform को लक्ष्य बैकएंड बाल्टी पर निम्नलिखित AWS IAM अनुमतियों की आवश्यकता होगी:

यह निम्नलिखित AWS IAM कथन में देखा गया है:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mybucket"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::mybucket/path/to/my/key"
    }
  ]
}

डायनेमोबीडी टेबल अनुमतियाँ

यदि आप राज्य लॉकिंग का उपयोग कर रहे हैं, तो Terraform को डायनमोबडी टेबल पर निम्नलिखित AWS IAM अनुमतियों की आवश्यकता होगी ( arn:aws:dynamodb:::table/mytable ):

यह निम्नलिखित AWS IAM कथन में देखा गया है:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": "arn:aws:dynamodb:*:*:table/mytable"
    }
  ]
}

S3 दूरस्थ स्थिति का उपयोग करना

S3 दूरस्थ स्थिति का उपयोग करने के लिए हम terraform_remote_state डेटा स्रोत का उपयोग कर सकते हैं।

data "terraform_remote_state" "network" {
  backend = "s3"
  config {
    bucket = "terraform-state-prod"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

terraform_remote_state डेटा स्रोत संदर्भित दूरस्थ स्थिति में परिभाषित सभी रूट आउटपुट को लौटाएगा, एक उदाहरण आउटपुट जैसा दिख सकता है:

data.terraform_remote_state.network:
  id = 2016-10-29 01:57:59.780010914 +0000 UTC
  addresses.# = 2
  addresses.0 = 52.207.220.222
  addresses.1 = 54.196.78.166
  backend = s3
  config.% = 3
  config.bucket = terraform-state-prod
  config.key = network/terraform.tfstate
  config.region = us-east-1
  elb_address = web-elb-790251200.us-east-1.elb.amazonaws.com
  public_subnet_id = subnet-1e05dd33

कॉन्फ़िगरेशन चर

निम्नलिखित कॉन्फ़िगरेशन विकल्प या पर्यावरण चर समर्थित हैं:

  • bucket - (आवश्यक) S3 बाल्टी का नाम।
  • key - (आवश्यक) बाल्टी के अंदर राज्य फ़ाइल का पथ। एक गैर-डिफ़ॉल्ट workspace का उपयोग करते समय, राज्य पथ /workspace_key_prefix/workspace_name/key
  • region / AWS_DEFAULT_REGION - (वैकल्पिक) S3 बाल्टी का क्षेत्र।
  • endpoint / AWS_S3_ENDPOINT - (वैकल्पिक) S3 API के लिए एक कस्टम समापन बिंदु।
  • encrypt - (वैकल्पिक) राज्य फ़ाइल के सर्वर साइड एन्क्रिप्शन को सक्षम करना है या नहीं।
  • acl - डिब्बाबंद ACL को राज्य फ़ाइल में लागू किया जाएगा।
  • access_key / AWS_ACCESS_KEY_ID - (वैकल्पिक) AWS पहुंच कुंजी।
  • secret_key / AWS_SECRET_ACCESS_KEY - (वैकल्पिक) AWS गुप्त पहुँच कुंजी।
  • kms_key_id - (वैकल्पिक) राज्य को एन्क्रिप्ट करने के लिए उपयोग करने के लिए KMS कुंजी का ARN।
  • lock_table - (वैकल्पिक, पदावनत) इसके बजाय dynamodb_table उपयोग करें।
  • dynamodb_table - (ऑप्शनल) डायनामोडीबी टेबल का नाम राज्य लॉकिंग और स्थिरता के लिए उपयोग करना। तालिका में एक प्राथमिक कुंजी होनी चाहिए जिसका नाम लॉकआईडी है। यदि मौजूद नहीं है, तो लॉकिंग अक्षम हो जाएगा।
  • profile - (वैकल्पिक) यह एडब्ल्यूएस प्रोफाइल नाम है जैसा कि साझा क्रेडेंशियल फ़ाइल में सेट किया गया है।
  • shared_credentials_file - (वैकल्पिक) यह साझा क्रेडेंशियल फ़ाइल का पथ है। यदि यह सेट नहीं है और एक प्रोफ़ाइल निर्दिष्ट है, तो ~/.aws/credentials का उपयोग किया जाएगा।
  • token - (वैकल्पिक) MFA टोकन सेट करने के लिए इसका उपयोग करें। यह AWS_SESSION_TOKEN पर्यावरण चर से भी प्राप्त किया जा सकता है।
  • role_arn - (वैकल्पिक) मान ली जाने वाली भूमिका।
  • assume_role_policy - (वैकल्पिक) भूमिका मानने के दौरान अनुमतियाँ लागू।
  • external_id - (वैकल्पिक) भूमिका ग्रहण करते समय उपयोग करने के लिए बाहरी आईडी।
  • session_name - (वैकल्पिक) भूमिका मानने के दौरान सत्र का नाम।
  • workspace_key_prefix - (वैकल्पिक) बाल्टी के अंदर राज्य पथ पर उपसर्ग लगाया। यह केवल तब ही प्रासंगिक होता है जब एक गैर-डिफ़ॉल्ट कार्यक्षेत्र का उपयोग किया जाता है। यह चूक "env:"
  • skip_credentials_validation - (वैकल्पिक) STS API के माध्यम से क्रेडेंशियल्स सत्यापन छोड़ें।
  • skip_get_ec2_platforms - (वैकल्पिक) समर्थित EC2 प्लेटफ़ॉर्म प्राप्त करना छोड़ें।
  • skip_region_validation - (वैकल्पिक) प्रदान किए गए क्षेत्र के नाम के सत्यापन को छोड़ दें।
  • skip_requesting_account_id - (वैकल्पिक) खाता आईडी का अनुरोध करना छोड़ें।
  • skip_metadata_api_check - (वैकल्पिक) AWS मेटाडेटा API चेक छोड़ें।

मल्टी-अकाउंट AWS आर्किटेक्चर

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

S3 बैकेंड का उपयोग कई अलग-अलग तरीकों से किया जा सकता है जो इस तरह के संगठन में सुविधा, सुरक्षा और अलगाव के बीच अलग-अलग ट्रेडऑफ़ बनाते हैं। यह खंड एक ऐसे दृष्टिकोण का वर्णन करता है जिसका उद्देश्य इन व्यापारों के बीच एक अच्छा समझौता करना है, जिससे एक ही विन्यास के कई अलग-अलग तैनाती के बीच आसानी से स्विच करने के लिए workspace उपयोग करने की अनुमति मिलती है।

इस अनुभाग का उपयोग अपने दृष्टिकोण के लिए एक प्रारंभिक बिंदु के रूप में करें, लेकिन ध्यान दें कि संभवतः आपको अपने संगठन पर लागू होने वाले अद्वितीय मानकों और नियमों के लिए समायोजन करने की आवश्यकता होगी। आपको अपने संगठन के भीतर मौजूदा प्रथाओं के लिए इस दृष्टिकोण के लिए कुछ समायोजन करने की आवश्यकता होगी, यदि उदाहरण के लिए अन्य उपकरण पहले बुनियादी ढांचे का प्रबंधन करने के लिए उपयोग किए गए हैं।

टेराफॉर्म एक प्रशासनिक उपकरण है जो आपके बुनियादी ढांचे का प्रबंधन करता है, और इसलिए आदर्श रूप से टेराफॉर्म द्वारा उपयोग किया जाने वाला बुनियादी ढांचा टेराफॉर्म के बुनियादी ढांचे के बाहर मौजूद होना चाहिए। यह एक अलग प्रशासनिक AWS खाता बनाकर प्राप्त किया जा सकता है जिसमें मानव ऑपरेटरों द्वारा उपयोग किए जाने वाले उपयोगकर्ता खाते और अन्य खातों को प्रबंधित करने के लिए उपयोग किए जाने वाले किसी भी बुनियादी ढांचे और उपकरण शामिल हैं। अपने मुख्य वातावरण से साझा किए गए प्रशासनिक टूल को अलग करने के कई फायदे हैं, जैसे कि लक्ष्य के बुनियादी ढाँचे को बदलते समय प्रशासनिक अवसंरचना को नुकसान पहुँचाने से बचना, और जोखिम को कम करना जो एक हमलावर उत्पादन बुनियादी ढांचे का दुरुपयोग कर सकता है (आमतौर पर अधिक विशेषाधिकार प्राप्त) तक पहुँचने के लिए आधारिक संरचना।

प्रशासनिक खाता सेटअप

आपके प्रशासनिक AWS खाते में कम से कम निम्नलिखित आइटम होंगे:

  • सिस्टम प्रशासकों के लिए एक या एक से अधिक IAM उपयोगकर्ता जो अन्य खातों में बुनियादी ढांचे को बनाए रखने के लिए लॉग इन करेंगे।
  • वैकल्पिक रूप से, एक या एक से अधिक IAM समूह उपयोगकर्ताओं के विभिन्न समूहों के बीच अंतर करने के लिए जिनके पास अन्य AWS खातों तक पहुंच के विभिन्न स्तर हैं।
  • एक S3 बाल्टी जिसमें प्रत्येक कार्यक्षेत्र के लिए टेराफॉर्म राज्य फाइलें होंगी।
  • डायनेमोबडी टेबल जिसका उपयोग एकल कार्यक्षेत्र पर समवर्ती संचालन को रोकने के लिए लॉकिंग के लिए किया जाएगा।

क्रमशः S3 बैकएंड कॉन्फ़िगरेशन के भीतर S3 बकेट नाम और डायनमोबडी टेबल नाम को टेरफॉर्म में प्रदान करें, bucket और dynamodb_table तर्कों का उपयोग करके, और इस कॉन्फ़िगरेशन के लिए बाद में बनाए जाने वाले विभिन्न स्थानों के राज्यों को समाहित करने के लिए एक उपयुक्त workspace_key_prefix कॉन्फ़िगर करें।

पर्यावरण खाता सेटअप

इस अनुभाग के लिए, "पर्यावरण खाता" शब्द उन खातों में से एक है, जिनकी सामग्री टेराफॉर्म द्वारा प्रबंधित की जाती है, जो ऊपर वर्णित प्रशासनिक खाते से अलग है।

आपके पर्यावरण खातों में अंततः आपका अपना उत्पाद-विशिष्ट बुनियादी ढांचा होगा। इसके साथ ही इसमें एक या एक से अधिक IAM भूमिकाएं होनी चाहिए जो वांछित प्रबंधन कार्यों को करने के लिए Terraform के लिए पर्याप्त पहुंच प्रदान करती हैं।

प्रतिनिधि पहुँच

प्रत्येक प्रशासक प्रशासनिक खाते में अपने IAM उपयोगकर्ता के लिए क्रेडेंशियल्स का उपयोग करके Terraform चलाएगा। IAM रोल डेलिगेशन का उपयोग इन उपयोगकर्ताओं को प्रत्येक पर्यावरण खाते में बनाई गई भूमिकाओं तक पहुंच प्रदान करने के लिए किया जाता है।

भूमिका से जुड़े प्रतिनिधिमंडल का पूरा विवरण ऊपर दिए गए AWS प्रलेखन में शामिल है। सबसे महत्वपूर्ण विवरण हैं:

  • प्रत्येक भूमिका की एश्यूम रोल पॉलिसी को प्रशासनिक AWS खाते तक पहुंच प्रदान करनी चाहिए, जो प्रशासनिक AWS खाते के साथ विश्वास संबंध बनाता है ताकि उसके उपयोगकर्ता भूमिका मान सकें।
  • प्रशासनिक खाते के भीतर उपयोगकर्ताओं या समूहों के पास एक नीति भी होनी चाहिए, जो इन संबंधों या समूहों को उस भूमिका को मानने की अनुमति देती है।

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

Terraform को कॉन्फ़िगर करते समय, प्रशासक उपयोगकर्ता के IAM क्रेडेंशियल्स को S3 बैकएंड और Terraform के AWS प्रदाता दोनों को प्रशासकीय खाते में प्रदान करने के लिए या तो पर्यावरण चर या मानक क्रेडेंशियल फ़ाइल ~/.aws/credentials का उपयोग करें।

चयनित कार्यस्थान के आधार पर AWS प्रदाता के लिए एक अलग assume_role मान को पास करने के लिए सशर्त कॉन्फ़िगरेशन का उपयोग करें। उदाहरण के लिए:

variable "workspace_iam_roles" {
  default = {
    staging    = "arn:aws:iam::STAGING-ACCOUNT-ID:role/Terraform"
    production = "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/Terraform"
  }
}

provider "aws" {
  # No credentials explicitly set here because they come from either the
  # environment or the global credentials file.

  assume_role = "${var.workspace_iam_roles[terraform.workspace]}"
}

यदि कार्यक्षेत्र IAM भूमिकाओं को केंद्रीय रूप से प्रबंधित और कई अलग-अलग Terraform कॉन्फ़िगरेशन में साझा किया जाता है, तो ARNs को इन मानों को दोहराने से बचने के लिए terraform_remote_state जैसे डेटा स्रोत के माध्यम से भी प्राप्त किया जा सकता है।

कार्यक्षेत्र बनाना और चुनना

बनाई गई आवश्यक वस्तुओं और बैकएंड को कॉन्फ़िगर करने के साथ, बैकएंड को इनिशियलाइज़ करने के लिए terraform init चलाएं और "डिफ़ॉल्ट" नामक एक प्रारंभिक कार्यक्षेत्र स्थापित करें। इस कार्यक्षेत्र का उपयोग नहीं किया जाएगा, लेकिन स्वचालित रूप से टेराफॉर्म द्वारा उन उपयोगकर्ताओं के लिए एक सुविधा के रूप में बनाया गया है जो कार्यस्थान सुविधा का उपयोग नहीं कर रहे हैं।

ऊपर दिए गए workspace_iam_roles चर मान में दी गई प्रत्येक कुंजी के अनुरूप कार्यक्षेत्र बनाएँ:

$ terraform workspace new staging
Created and switched to workspace "staging"!

...

$ terraform workspace new production
Created and switched to workspace "production"!

...

AWS प्रदाता कॉन्फ़िगरेशन में assume_role सेटिंग के कारण, AWS संसाधनों के लिए कोई भी प्रबंधन संचालन उपयुक्त वातावरण AWS खाते में कॉन्फ़िगर की गई भूमिका के माध्यम से किया जाएगा। S3 से राज्य को पढ़ने और लिखने जैसे बैकएंड संचालन, सीधे प्रशासनिक खाते के भीतर व्यवस्थापक के स्वयं के उपयोगकर्ता के रूप में किए जाएंगे।

$ terraform workspace select staging
$ terraform apply
...

अमेज़न EC2 में टेराफॉर्म चल रहा है

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

अमेज़ॅन EC2 इंस्टेंस पर चल रहे एक ऑटोमेशन टूल में टेराफ़ॉर्म चलाते समय, इस उदाहरण को प्रशासनिक खाते में चलाने और ऊपर दिए गए विभिन्न व्यवस्थापक IAM उपयोगकर्ताओं के स्थान पर एक इंस्टेंस प्रोफ़ाइल का उपयोग करने पर विचार करें। एक IAM उदाहरण प्रोफ़ाइल को IAM नीति के माध्यम से क्रॉस-अकाउंट डेलिगेशन एक्सेस भी प्रदान किया जा सकता है, इस उदाहरण को यह एक्सेस प्रदान करता है कि इसे Teradform चलाने की आवश्यकता है।

विभिन्न पर्यावरण खातों तक पहुंच को अलग करने के लिए, प्रत्येक लक्ष्य खाते के लिए एक अलग EC2 उदाहरण का उपयोग करें ताकि इसकी पहुंच केवल एकल खाते तक सीमित हो सके।

इसी तरह के दृष्टिकोण को अन्य AWS कंप्यूट सेवाओं में समान सुविधाओं के साथ लिया जा सकता है, जैसे ECS।

कार्यक्षेत्र राज्य तक पहुंच की सुरक्षा करना

पूर्व अनुभागों में वर्णित पैटर्न के एक सरल कार्यान्वयन में, सभी उपयोगकर्ताओं को सभी कार्यक्षेत्रों के लिए राज्यों को पढ़ने और लिखने की पहुंच है। कई मामलों में एस 3 में टेराफॉर्म राज्य वस्तुओं के लिए अधिक सटीक पहुंच बाधाओं को लागू करना वांछनीय है, ताकि उदाहरण के लिए केवल विश्वसनीय प्रशासकों को उत्पादन राज्य को संशोधित करने, या संवेदनशील जानकारी वाले राज्य के पढ़ने को नियंत्रित करने की अनुमति दी जाए।

अमेज़ॅन एस 3 आईएएम नीति का उपयोग करके प्रति-ऑब्जेक्ट-पथ के आधार पर ठीक-ठीक अभिगम नियंत्रण का समर्थन करता है। S3 के अभिगम नियंत्रण तंत्र का पूर्ण विवरण इस मार्गदर्शिका के दायरे से परे है, लेकिन एक उदाहरण IAM नीति जो S3 बाल्टी के भीतर केवल एक ही राज्य वस्तु तक पहुंच प्रदान करती है, नीचे दिखाया गया है:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::myorg-terraform-states"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::myorg-terraform-states/myapp/production/tfstate"
    }
  ]
}

लॉकिंग के लिए उपयोग किए जाने वाले डायनमोडी टेबल पर इस तरह के बारीक-से-अभिगम नियंत्रण को लागू करना संभव नहीं है, इसलिए टेराफॉर्म के साथ किसी भी उपयोगकर्ता के लिए किसी भी कार्यक्षेत्र राज्य को लॉक करना संभव है, भले ही उनके पास उस राज्य को पढ़ने या लिखने के लिए उपयोग न हो। यदि दुर्भावनापूर्ण उपयोगकर्ता के पास ऐसी पहुँच है, तो वे बैकएंड कॉन्फ़िगरेशन में लॉकिंग सक्षम होने तक आपके या आपके सभी कार्यक्षेत्रों के विरुद्ध टेराफ़ॉर्म का उपयोग करने के प्रयासों को रोक सकते हैं।