برنامه نویسی

GitLab، Azure، OpenTofu، و هیچ راز!

Summarize this content to 400 words in Persian Lang باور کنید یا نه، می توانید هر منبعی را با استفاده از Terraform از خط لوله GitLab به ابر Azure بدون هیچ رازی مستقر کنید!

تصور کنید… بدون راز، بدون تعمیر و نگهداری، بدون KeyVaults، بدون هیچ زحمتی.

اجازه دهید به شما نشان دهم چگونه!

پروژه GitLab

برای نشان دادن این تکنیک از این پروژه gitlab-azure-oidc-opentofu استفاده خواهم کرد.

چه کاری انجام می دهد؟ این یک گروه منبع در یکی از اشتراک های Azure ایجاد می کند. خیلی ساده است؟ بله همینطور است. با این حال، هدف اصلی نشان دادن نحوه تنظیم احراز هویت OpenID Connect (OIDC) است.

همه چیز راه اندازی و اجرا شد. اما با خواندن این مطلب، اشتراک Azure احتمالا لغو شده است. فقط در صورتی که کسی موفق به ادغام کدهای ترافورم شود که 100 گره خوشه Azure Kubernetes را فشار می دهد :).

و یه نکته دیگه که باید بهش اشاره کنم

فناوری OIDC با Terraform به خوبی کار می کند. در این پروژه اما من استفاده از OpenTofu را انتخاب کردم. در کامپوننتی که توسط GitLab پشتیبانی می شود ادغام شده است.

بنابراین، خط لوله در این پروژه ممکن است نمونه خوبی از استفاده از مؤلفه OpenTofu به همراه سرویس وضعیت GitLab Terraform باشد.

از آخر شروع کنیم…

کد Terraform

اینجا کامل است providers.tf فایل

به کد terraform نگاهی بیندازیم؟

provider “azurerm” {
features {}

tenant_id = var.tenant_id
subscription_id = var.subscription_id
client_id = var.client_id

use_oidc = true
oidc_token = var.oidc_token
}

تمام این تنظیمات ارائه دهنده برای احراز هویت استفاده می شود. و دو خط آخر باعث می شود Terraform (OpenTofu) از OIDC استفاده کند!

این متغیرها کجا تنظیم می شوند و چه مقادیری استفاده می شوند؟ سوال عالی!

کد خط لوله Gitlab

متغیرها در کد خط لوله تنظیم می شوند! اینجا لینک خط لوله است.

چندین جزئیات وجود دارد که مایلم به آنها اشاره کنم.

توکن OIDC

بله در عنوان دروغ گفتم رازی در این فناوری استفاده شده است. با این حال، این راز توسط خود فناوری تنظیم شده است. OpenID Connect کد شما را با یک رمز موقت OIDC ارائه می کند. این دقیقاً همان چیزی است که قرار است در آن قرار داده شود oidc_token متغیر اما چگونه؟

ساده!

هر کاری که نیاز به احراز هویت دارد چندین خط دارد:


id_tokens:
TF_VAR_oidc_token:
aud: https://gitlab.com

این خطوط یک متغیر محیطی ایجاد می کنند TF_VAR_oidc_token و آن را با مقدار رمز پر کنید.

و این تمام چیزی است که شما نیاز دارید! از دیدگاه کد Terraform. باشه تقریبا تمام چیزی که نیاز دارید

از آنجایی که متغیر محیطی به صورت تنظیم شده است TF_VAR_<something>، Terraform (OpenTofu) مقدار خود را می گیرد و یک متغیر داخلی را با آن تنظیم می کند <something> نام خواهد بود oidc_token در مورد ما

و این دقیقا همان چیزی است که کد Terraform ما انتظار دارد!

سایر متغیرهای Terraform (OpenTofu).

درسته تنظیم فقط یک نشانه کافی نیست. کد نیاز دارد tenant_id، subscription_id، و client_id. اینها کجا راه اندازی شدند؟

ساده اینها متغیرهای سراسری خط لوله هستند.

variables:

TF_VAR_client_id: $AZURE_CLIENT_ID
TF_VAR_tenant_id: $AZURE_TENANT_ID
TF_VAR_subscription_id: $AZURE_SUBSCRIPTION_ID

و در اینجا من از همان استفاده می کنم TF_VAR_<something> نشانه گذاری بنابراین، Terraform (OpenTofu) هر چیزی که بعد از «TF_VAR_» باشد را می گیرد و یک متغیر داخلی با <something> نام

به عنوان مثال، Terraform (OpenTofu) خواهد گرفت

TF_VAR_client_id: $AZURE_CLIENT_ID

خط، ایجاد متغیر client_id و آن را با مقدار پر کنید $AZURE_CLIENT_ID متغیر

عالیه اما، چه هستند $AZURE_CLIENT_ID، $AZURE_TENANT_ID، $AZURE_SUBSCRIPTION_ID?

یه سوال خیلی خوب دوباره! ده امتیاز به گریفیندور! اما من اهل اسلیترین هستم! باشه منهای ده امتیاز به اسلیترین!

ابتدا اجازه دهید توضیح دهم که این متغیرها در کجا تنظیم شده اند. و سپس ارزش های آنها از کجا گرفته شده است.

متغیرهای GitLab CI/CD

اینها متغیرهای GitLab CI/CD هستند. برای ایجاد آنها، باید از آن استفاده کنید Settings / CI/CI / Variables رابط GitLab

احتمالا یکی دو سوال دیگر دارید.

چرا از متغیرهای CI/CD استفاده می کنید؟

این یک سوال واقعی نیست. مفهوم جدایی وجود دارد
داده ها و منطق حدود 75 سال سن دارد. 🙂

بله، امکان قرار دادن این شناسه ها مستقیماً در کد وجود دارد. این باعث می شود کد منحصر به فرد و انعطاف پذیری کمتری داشته باشد و استفاده از کد را محدود می کند.

و چرا آنها را در آن ایجاد نمی کنید TF_VAR_<something> نشانه گذاری؟

این یک مفهوم دیگر است. هرگز از متغیرهای سراسری در یک برنامه فرعی استفاده نکنید. 🙂

امکان تنظیم متغیرهای CI/CD با TF_VAR_<something> نشانه گذاری با این حال، این متغیرها را پنهان می کند. باید منبع داده ها را حدس زد. اکنون همه چیز قابل مشاهده است و درک کد بسیار ساده تر است.

سمت Azure یا بهتر بگوییم Entra ID

بیایید به معنی و منبع آن بپردازیم $AZURE_CLIENT_ID، $AZURE_TENANT_ID، $AZURE_SUBSCRIPTION_ID متغیرها

من معتقدم Subscription ID و Tenant ID خود توضیحی هستند، درست است؟ فقط در مورد، Subscription ID تقریباً در هر رابط کاربری portal.azure.com قابل مشاهده است.

کشف شناسه مستاجر کمی سخت تر است. سریعترین راه این است که “Entra ID” را در پورتال جستجو کنید، “Entra ID” را باز کنید و بلافاصله آن را خواهید دید:

هنوز نبندش

چیست $AZURE_CLIENT_ID?

این یک شناسه اصلی سرویس (یا ثبت برنامه) است که برای احراز هویت خط لوله خود ایجاد کرده اید.

اگر این کار را نکردید، در اینجا نحوه انجام آن آمده است. پورتال Entra ID خود را باز کنید، آن را پیدا کنید App Registrations تیغه، و فشار دهید New Registration.

سپس یک نام معنی دار وارد کنید و “ثبت نام” را فشار دهید.

در مورد من، نام است sp_azure_subscription_contributor. همیشه می توانید مدیر سرویس خود را در این قسمت پیدا کنید App Registrations رابط Entra ID.

اینجا جایی است که می توانید شناسه مشتری مدیر سرویس خود را پیدا کنید.

چگونه و از کجا می توانم به سرویس اصلی دسترسی به اشتراک Azure ارائه دهم؟

شما هویت را ایجاد کرده اید و باید مجوز دسترسی به اشتراک شما را داشته باشد. چگونه آن را انجام دهیم؟ ساده

اشتراک خود را در پورتال باز کنید، آن را باز کنید Access control (IAM) تیغه، و Add role assignment:

سپس انتخاب کنید Contributor نقش داشته باشید، مدیر سرویس تازه ایجاد شده خود را پیدا و انتخاب کنید و آن را اختصاص دهید.

بنابراین، در حال حاضر، ما همه چیز داریم به جز آخرین و مهمترین عنصر OIDC.

اعتبارنامه هویت فدرال، جادویی Open ID Connect است

و هیچ جادویی وجود ندارد. شما باید ایجاد کنید Federated Credentials تا به خط لوله شما اجازه دهید بدون راز مشترک به اعتبارنامه اصلی سرویس شما دسترسی داشته باشد.

خودت را باز کن App Registrations اطلاعاتی در مورد مدیر سرویس شما را باز کنید Certificates & Secrets تیغه بر روی کلیک کنید Federated credentials را برگه و فشار دهید + Add credential

در اینجا “سس جادویی” آمده است:

شما می توانید هر آنچه را که می خواهید در نام یا توضیحات وارد کنید. اما ارائه اطلاعات صحیح در زمینه های بعدی بسیار مهم است:

صادرکننده:

https://gitlab.com

شناسه موضوع:

project_path:<gitlab_user_name>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

یا

project_path:<gitlab_project_group>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

در مورد من این است:

project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:main

مخاطب:

https://gitlab.com

و این همه است. در اینجا گروه منابع ایجاد شده توسط خط لوله آزمایشی است:

لینک های مفید

GitLab رسمی Azure AD هویت فدرال مستندات
کامپوننت GitLab OpenTofu

باور کنید یا نه، می توانید هر منبعی را با استفاده از Terraform از خط لوله GitLab به ابر Azure بدون هیچ رازی مستقر کنید!

تصور کنید… بدون راز، بدون تعمیر و نگهداری، بدون KeyVaults، بدون هیچ زحمتی.

اجازه دهید به شما نشان دهم چگونه!

پروژه GitLab

برای نشان دادن این تکنیک از این پروژه gitlab-azure-oidc-opentofu استفاده خواهم کرد.

چه کاری انجام می دهد؟ این یک گروه منبع در یکی از اشتراک های Azure ایجاد می کند. خیلی ساده است؟ بله همینطور است. با این حال، هدف اصلی نشان دادن نحوه تنظیم احراز هویت OpenID Connect (OIDC) است.

همه چیز راه اندازی و اجرا شد. اما با خواندن این مطلب، اشتراک Azure احتمالا لغو شده است. فقط در صورتی که کسی موفق به ادغام کدهای ترافورم شود که 100 گره خوشه Azure Kubernetes را فشار می دهد :).

و یه نکته دیگه که باید بهش اشاره کنم

فناوری OIDC با Terraform به خوبی کار می کند. در این پروژه اما من استفاده از OpenTofu را انتخاب کردم. در کامپوننتی که توسط GitLab پشتیبانی می شود ادغام شده است.

بنابراین، خط لوله در این پروژه ممکن است نمونه خوبی از استفاده از مؤلفه OpenTofu به همراه سرویس وضعیت GitLab Terraform باشد.

از آخر شروع کنیم…

کد Terraform

اینجا کامل است providers.tf فایل

به کد terraform نگاهی بیندازیم؟

provider "azurerm" {
  features {}

  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
  client_id       = var.client_id

  use_oidc        = true
  oidc_token      = var.oidc_token
}

تمام این تنظیمات ارائه دهنده برای احراز هویت استفاده می شود. و دو خط آخر باعث می شود Terraform (OpenTofu) از OIDC استفاده کند!

این متغیرها کجا تنظیم می شوند و چه مقادیری استفاده می شوند؟ سوال عالی!

کد خط لوله Gitlab

متغیرها در کد خط لوله تنظیم می شوند! اینجا لینک خط لوله است.

چندین جزئیات وجود دارد که مایلم به آنها اشاره کنم.

توکن OIDC

بله در عنوان دروغ گفتم رازی در این فناوری استفاده شده است. با این حال، این راز توسط خود فناوری تنظیم شده است. OpenID Connect کد شما را با یک رمز موقت OIDC ارائه می کند. این دقیقاً همان چیزی است که قرار است در آن قرار داده شود oidc_token متغیر اما چگونه؟

ساده!

هر کاری که نیاز به احراز هویت دارد چندین خط دارد:

...
  id_tokens:
    TF_VAR_oidc_token:
      aud: https://gitlab.com
...

این خطوط یک متغیر محیطی ایجاد می کنند TF_VAR_oidc_token و آن را با مقدار رمز پر کنید.

و این تمام چیزی است که شما نیاز دارید! از دیدگاه کد Terraform. باشه تقریبا تمام چیزی که نیاز دارید

از آنجایی که متغیر محیطی به صورت تنظیم شده است TF_VAR_<something>، Terraform (OpenTofu) مقدار خود را می گیرد و یک متغیر داخلی را با آن تنظیم می کند <something> نام خواهد بود oidc_token در مورد ما

و این دقیقا همان چیزی است که کد Terraform ما انتظار دارد!

سایر متغیرهای Terraform (OpenTofu).

درسته تنظیم فقط یک نشانه کافی نیست. کد نیاز دارد tenant_id، subscription_id، و client_id. اینها کجا راه اندازی شدند؟

ساده اینها متغیرهای سراسری خط لوله هستند.

variables:
...
  TF_VAR_client_id: $AZURE_CLIENT_ID
  TF_VAR_tenant_id: $AZURE_TENANT_ID
  TF_VAR_subscription_id: $AZURE_SUBSCRIPTION_ID
...

و در اینجا من از همان استفاده می کنم TF_VAR_<something> نشانه گذاری بنابراین، Terraform (OpenTofu) هر چیزی که بعد از «TF_VAR_» باشد را می گیرد و یک متغیر داخلی با <something> نام

به عنوان مثال، Terraform (OpenTofu) خواهد گرفت

TF_VAR_client_id: $AZURE_CLIENT_ID

خط، ایجاد متغیر client_id و آن را با مقدار پر کنید $AZURE_CLIENT_ID متغیر

عالیه اما، چه هستند $AZURE_CLIENT_ID، $AZURE_TENANT_ID، $AZURE_SUBSCRIPTION_ID?

یه سوال خیلی خوب دوباره! ده امتیاز به گریفیندور! اما من اهل اسلیترین هستم! باشه منهای ده امتیاز به اسلیترین!

ابتدا اجازه دهید توضیح دهم که این متغیرها در کجا تنظیم شده اند. و سپس ارزش های آنها از کجا گرفته شده است.

متغیرهای GitLab CI/CD

اینها متغیرهای GitLab CI/CD هستند. برای ایجاد آنها، باید از آن استفاده کنید Settings / CI/CI / Variables رابط GitLab

احتمالا یکی دو سوال دیگر دارید.

  • چرا از متغیرهای CI/CD استفاده می کنید؟

این یک سوال واقعی نیست. مفهوم جدایی وجود دارد
داده ها و منطق حدود 75 سال سن دارد. 🙂

بله، امکان قرار دادن این شناسه ها مستقیماً در کد وجود دارد. این باعث می شود کد منحصر به فرد و انعطاف پذیری کمتری داشته باشد و استفاده از کد را محدود می کند.

  • و چرا آنها را در آن ایجاد نمی کنید TF_VAR_<something> نشانه گذاری؟

این یک مفهوم دیگر است. هرگز از متغیرهای سراسری در یک برنامه فرعی استفاده نکنید. 🙂

امکان تنظیم متغیرهای CI/CD با TF_VAR_<something> نشانه گذاری با این حال، این متغیرها را پنهان می کند. باید منبع داده ها را حدس زد. اکنون همه چیز قابل مشاهده است و درک کد بسیار ساده تر است.

سمت Azure یا بهتر بگوییم Entra ID

بیایید به معنی و منبع آن بپردازیم $AZURE_CLIENT_ID، $AZURE_TENANT_ID، $AZURE_SUBSCRIPTION_ID متغیرها

من معتقدم Subscription ID و Tenant ID خود توضیحی هستند، درست است؟ فقط در مورد، Subscription ID تقریباً در هر رابط کاربری portal.azure.com قابل مشاهده است.

شناسه اشتراک

کشف شناسه مستاجر کمی سخت تر است. سریعترین راه این است که “Entra ID” را در پورتال جستجو کنید، “Entra ID” را باز کنید و بلافاصله آن را خواهید دید:

شناسه مستاجر

هنوز نبندش

چیست $AZURE_CLIENT_ID?

این یک شناسه اصلی سرویس (یا ثبت برنامه) است که برای احراز هویت خط لوله خود ایجاد کرده اید.

اگر این کار را نکردید، در اینجا نحوه انجام آن آمده است. پورتال Entra ID خود را باز کنید، آن را پیدا کنید App Registrations تیغه، و فشار دهید New Registration.

ثبت نام برنامه به نام Service Principal

سپس یک نام معنی دار وارد کنید و “ثبت نام” را فشار دهید.

در مورد من، نام است sp_azure_subscription_contributor. همیشه می توانید مدیر سرویس خود را در این قسمت پیدا کنید App Registrations رابط Entra ID.

اینجا جایی است که می توانید شناسه مشتری مدیر سرویس خود را پیدا کنید.

اطلاعات در مورد مدیر سرویس

چگونه و از کجا می توانم به سرویس اصلی دسترسی به اشتراک Azure ارائه دهم؟

شما هویت را ایجاد کرده اید و باید مجوز دسترسی به اشتراک شما را داشته باشد. چگونه آن را انجام دهیم؟ ساده

اشتراک خود را در پورتال باز کنید، آن را باز کنید Access control (IAM) تیغه، و Add role assignment:

توضیحات تصویر

سپس انتخاب کنید Contributor نقش داشته باشید، مدیر سرویس تازه ایجاد شده خود را پیدا و انتخاب کنید و آن را اختصاص دهید.

توضیحات تصویر

بنابراین، در حال حاضر، ما همه چیز داریم به جز آخرین و مهمترین عنصر OIDC.

اعتبارنامه هویت فدرال، جادویی Open ID Connect است

و هیچ جادویی وجود ندارد. شما باید ایجاد کنید Federated Credentials تا به خط لوله شما اجازه دهید بدون راز مشترک به اعتبارنامه اصلی سرویس شما دسترسی داشته باشد.

خودت را باز کن App Registrations اطلاعاتی در مورد مدیر سرویس شما را باز کنید Certificates & Secrets تیغه بر روی کلیک کنید Federated credentials را برگه و فشار دهید + Add credential

توضیحات تصویر

در اینجا “سس جادویی” آمده است:

توضیحات تصویر

شما می توانید هر آنچه را که می خواهید در نام یا توضیحات وارد کنید. اما ارائه اطلاعات صحیح در زمینه های بعدی بسیار مهم است:

صادرکننده:

https://gitlab.com

شناسه موضوع:

project_path:<gitlab_user_name>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

یا

project_path:<gitlab_project_group>/<gitlab_project_name>:ref_type:branch:ref:<pipeline_branch_name>

در مورد من این است:

project_path:rokicool/gitlab-azure-oidc-opentofu:ref_type:branch:ref:main

مخاطب:

https://gitlab.com

و این همه است. در اینجا گروه منابع ایجاد شده توسط خط لوله آزمایشی است:

توضیحات تصویر

لینک های مفید

GitLab رسمی Azure AD هویت فدرال مستندات
کامپوننت GitLab OpenTofu

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا