Identity Center للأشخاص، والـ roles لأحمال العمل

انتهى القسم الأول بمستخدم مدير واحد لشخص واحد في حساب واحد. أما Lantern الآن فلديه ستة متطوّعين، وحساب للتطوير وآخر للإنتاج، ودالة Lambda، ومهمة ليلية على EC2. إذا احتاج كل واحد من هؤلاء إلى مستخدم IAM بمفاتيح وصول، فستنتهي بنحو اثني عشر سرًّا طويل الأمد مبعثرة على الحواسيب والخوادم. هذا الدرس يزيلها كلها إلا القليل.

الأشخاص: IAM Identity Center

AWS IAM Identity Center هو المكان الذي يسجّل فيه فريق عملك الدخول. يحصل كل شخص على هوية واحدة، إما في الدليل المدمج في Identity Center أو مُزامَنة من مزوّد هوية مثل Microsoft Entra ID أو Okta أو Google Workspace. يسجّل الشخص الدخول مرة واحدة، مع MFA، عبر رابط بوابة وصول AWS (AWS access portal)، فيرى كل حساب مسموح له بدخوله.

ما يستطيع فعله في كل حساب يأتي من حزم الصلاحيات (permission sets): حزمة مسمّاة من السياسات، مثل DeveloperAccess أو ReadOnly. عندما تُسند “المتطوّعة Rita، حزمة الصلاحيات DeveloperAccess، الحساب lantern-dev”، ينشئ Identity Center role مطابقًا في ذلك الحساب، وتتقمّصه جلسة Rita. لا أحد لديه مستخدم IAM؛ ولا أحد لديه مفتاح طويل الأمد.

صُمِّم Identity Center ليعمل مع AWS Organizations، الذي يجمع حسابات Lantern تحت حساب إدارة واحد. انتبه إلى عقبة عملية واحدة: في خطة الحساب المجانية، يؤدّي الانضمام إلى مؤسسة (organisation) إلى ترقية الحساب إلى الخطة المدفوعة، لذا فهذه خطوة لوقت انتقال Lantern إلى الإنتاج.

في الـ CLI، يكتب aws configure sso الـ profile، ويفتح aws sso login المتصفّح لتسجيل الدخول:

[sso-session lantern]
sso_start_url = https://lantern.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[profile lantern-dev]
sso_session = lantern
sso_account_id = 444455556666
sso_role_name = DeveloperAccess
region = eu-west-1

aws sso login --sso-session lantern
aws sts get-caller-identity --profile lantern-dev

الـ Arn الذي يعود الآن يُقرأ assumed-role/AWSReservedSSO_DeveloperAccess_…/rita: جلسة role، لا مستخدم.

أحمال العمل: roles لا مفاتيح

يحتاج الكود إلى بيانات اعتماد أيضًا، والجواب دائمًا role تتقمّصه المنصّة نيابة عنك:

• Lambda: لكل دالة execution role (role التنفيذ).
• EC2: يوصل الـ instance profile بيانات اعتماد الـ role عبر خدمة البيانات الوصفية للـ instance (instance metadata service).
• Amazon ECS: task role لكل task definition.
• الـ CI/CD خارج AWS، مثل GitHub Actions: مزوّد هوية OpenID Connect في IAM، فيستبدل الـ pipeline الـ token الخاص به بجلسة role.

للـ role سياستان دائمًا. سياسة الثقة (trust policy) تحدّد من يحق له تقمّصه:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

وسياسة الصلاحيات (permissions policy) تحدّد ما يحق للـ role فعله بعد تقمّصه، وتُكتب تمامًا مثل سياسات الدرس السابق.

عندئذٍ لا يحتوي الكود الخاص بك على أي بيانات اعتماد على الإطلاق. تستخدم حزم AWS SDK سلسلة بيانات اعتماد افتراضية (default credential chain) تعثر على بيانات اعتماد الـ role المؤقتة تلقائيًا:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

// No keys here: the SDK finds the execution role's temporary credentials.
const client = new DynamoDBClient({});
// …handler code that calls client.send(…)

الخطأ الذي ينتهي بفاتورة ضخمة

أحيانًا يكون مفتاح الوصول أمرًا لا مفرّ منه فعلًا، كأداة خارجية لا تقبل إلا المفاتيح. عندئذٍ: مستخدم IAM واحد لكل أداة، وسياسة بأقل الصلاحيات، وشرط aws:SourceIp إذا كانت للأداة عناوين ثابتة، وتدوير للمفتاح وفق جدول زمني.

التخلّص من مفتاح موجود تسلسل دقيق، لأن حذف مفتاح ما زال شيء ما يستخدمه يعطّل الإنتاج. تحقّق من آخر مرة استُخدم فيها:

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

بمجرد أن يثبت أن لا شيء استخدمه منذ تشغيل البديل، عطّله أولًا (وهذا قابل للتراجع)، وانتظر، ولا تحذفه إلا حين لا يشكو شيء. أما المفتاح الذي تشكّ في تسرّبه فأمره مختلف: عطّله فورًا، ثم حقّق في الأمر بعد ذلك.

بهذا تكتمل الهوية. يضعها القسم الثالث موضع التطبيق وأنت تختار قطع الحوسبة والتخزين وقاعدة البيانات والشبكة لـ Lantern.