کد لبه تصویر ظرف امضا شده

1. بررسی اجمالی

این آزمایشگاه کد بر روی آزمایشگاه کد فضای محرمانه ساخته شده است. پشتیبانی از تصویر کانتینر امضا شده گزینه ای برای احراز هویت یک ظرف با استفاده از یک کلید عمومی تأیید شده به جای تعیین خلاصه تصویر در خط مشی Workload Identity Pool (WIP) ارائه می شود.

چه چیزی با پشتیبانی از تصویر ظرف امضا شده در فضای محرمانه تغییر کرد:

قابلیت استفاده بهبودیافته: با معرفی ویژگی تصویر ظرف امضا شده، اکنون می‌توانیم از رویکرد خلاصه تصویر حجم کاری به رویکرد امضای ظرف برای همکاران/حسابرسانی که یک تصویر را مجاز می‌کنند تغییر دهیم.

• هنگام استفاده مستقیم از خلاصه تصویر، صاحبان منابع باید هر بار که یک تصویر جدید را مجاز می کنند، خط مشی های خود را با خلاصه تصویر به روز کنند. با استفاده از امضای تصویر، این خط‌مشی حاوی اثرانگشت کلید عمومی است که کلید خصوصی مربوطه متعلق به همکار/حساب‌رس است و برای امضای تصاویر ممیزی‌شده استفاده می‌شود.
• برای برخی از مدل‌های امنیتی، ارجاع به یک کلید امضای تصویر قابل اعتماد راحت‌تر از به‌روزرسانی فهرستی از مقادیر جدید خلاصه تصویر است.

توجه: استفاده از امضای تصویر جایگزین استفاده از خلاصه تصویر برای همه کاربران نخواهد شد. با این حال، ممکن است بهتر باشد محیط‌هایی با سرعت تغییر تصویر بالا یا بسیاری از صاحبان منابع هماهنگ شوند.

بدون رگرسیون امنیتی: این رویکرد امضای کانتینر هیچ رگرسیون امنیتی نسبت به رویکرد خلاصه تصویر قبلی ایجاد نمی کند زیرا مرزهای اعتماد یکسان باقی می مانند. در رویکرد امضای کانتینر، مالک منبع با تعیین اثر انگشت کلید عمومی قابل اعتماد در خط‌مشی WIP، کلید تأیید را تأیید می‌کند و بررسی مجوز توسط سرویس تأییدکننده تأیید و WIP انجام می‌شود. سرویس تأیید صحت تأیید می‌کند که امضا با حجم کار در حال اجرا مرتبط است، و خط‌مشی WIP بررسی می‌کند که کلید عمومی اعلام‌شده توسط سرویس توسط خط‌مشی مجاز باشد.

امنیت قوی: استفاده از امضاهای تصویر کانتینر به شخص اجازه می‌دهد تا حدی اعتماد را به امضاکننده تصویر واگذار کند. با مشخص کردن اثر انگشت کلید عمومی امضاکننده معتمد در خط‌مشی تأیید، مالک منبع به امضاکننده اجازه می‌دهد تأییدیه‌هایی را انجام دهد که تصاویر ظرف مطابق با یک خط‌مشی است. سرویس تأییدکننده تأیید تأیید می‌کند که امضا با حجم کار در حال اجرا مرتبط است، و خط‌مشی بررسی می‌کند که کلید عمومی که امضا را ایجاد کرده توسط خط‌مشی مجاز باشد. از این طریق، لایه اضافی غیرمستقیم که امضای تصویر ارائه می‌کند، تضمین‌های امنیتی قوی فضای محرمانه را حفظ می‌کند.

تنها تفاوت بین این رویکردها این است که رویکرد دوم از یک لایه اضافی غیرمستقیم استفاده می کند که در آن تصاویر بار کاری با یک کلید امضا مجاز هستند. این هیچ آسیب‌پذیری امنیتی جدیدی ایجاد نمی‌کند زیرا مرزهای اعتماد یکسان باقی می‌مانند.

چیزی که یاد خواهید گرفت

در این کد لبه، یاد خواهید گرفت که چگونه از امضای تصویر ظرف برای اجازه دسترسی به منابع محافظت شده استفاده کنید:

• نحوه امضای تصویر کانتینر ممیزی شده با استفاده از cosign
• نحوه آپلود امضاهای تصویر کانتینر در رجیستری های OCI برای کشف و ذخیره امضا
• نحوه پیکربندی منابع ابری لازم برای اجرای Confidential Space
• نحوه اجرای حجم کار در یک فضای محرمانه با پشتیبانی از تصویر ظرف امضا شده

این لبه کد به شما نشان می دهد که چگونه از فضای محرمانه برای تأیید از راه دور یک تصویر ظرف امضا شده توسط یک کلید قابل اعتماد در حال اجرا در موتور محاسباتی Google استفاده کنید.

آنچه شما نیاز دارید

• آزمایشگاه کد فضای محرمانه را کامل کنید
• یک پروژه Google Cloud Platform
• یک مرورگر، مانند کروم یا فایرفاکس
• آشنایی با ویرایشگرهای متن استاندارد لینوکس مانند Vim، Emacs یا Nano
• دانش اولیه Sigstore cosign
• دانش اولیه موتور محاسباتی گوگل ( کد لبه )، VM محرمانه ، کانتینرها و مخازن راه دور
• دانش اولیه Cloud KMS ( کدآلب )
• دانش اولیه حساب های خدماتی ، فدراسیون هویت بار کاری و شرایط ویژگی .
• آشنایی اولیه با رجیستری مصنوعات
• دانش اولیه امضای دیجیتال

نقش های درگیر در یک فضای محرمانه با تصویر ظرف امضا شده

در این کد لبه، بانک پریموس حسابرس و مالک منبع خواهد بود که مسئولیت موارد زیر را بر عهده خواهد داشت:

1. تنظیم منابع مورد نیاز با داده های نمونه
2. ممیزی کد حجم کار
3. استفاده از cosign برای امضای تصویر حجم کار.
4. آپلود امضا در یک مخزن.
5. پیکربندی خط مشی WIP برای محافظت از داده های مشتری.

Secundus Bank نویسنده و اپراتور حجم کار خواهد بود و مسئول موارد زیر خواهد بود:

1. تنظیم منابع مورد نیاز برای ذخیره نتیجه
2. نوشتن کد حجم کار
3. انتشار تصویر حجم کار
4. اجرای حجم کاری در فضای محرمانه با پشتیبانی از تصویر ظرف امضا شده.

بانک Secundus حجم کاری ایجاد و منتشر خواهد کرد که اطلاعات مشتری ذخیره شده در یک سطل ذخیره سازی ابری و متعلق به بانک Primus را جویا می شود. بانک Primus حجم کار را بررسی می‌کند، تصویر ظرف را امضا می‌کند و خط‌مشی‌های WIP را پیکربندی می‌کند تا امکان دسترسی به داده‌های آن‌ها توسط بارهای کاری تأیید شده را فراهم کند. نتیجه اجرای این حجم کاری در یک سطل ذخیره سازی ابری متعلق به بانک سکوندوس ذخیره می شود.

منابع درگیر در تنظیم فضای محرمانه

این لبه کد به تعدادی از متغیرها اشاره می کند که باید آنها را روی مقادیر مناسب برای پروژه GCP خود تنظیم کنید. دستورات این کد لبه فرض می کنند که این متغیرها تنظیم شده اند. (به عنوان مثال، export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' می توان برای تنظیم نام سطل ذخیره ورودی بانک Primus استفاده کرد.) اگر متغیرهای نام منابع تنظیم نشده باشند، بر اساس آن ایجاد می شود. شناسه پروژه GCP.

موارد زیر را در پروژه Primus پیکربندی کنید:

• $PRIMUS_INPUT_STORAGE_BUCKET : سطلی که فایل اطلاعات مشتری را ذخیره می کند.
• $PRIMUS_WORKLOAD_IDENTITY_POOL : مجموعه شناسایی حجم کاری (WIP) که ادعاها را تأیید می‌کند.
• $PRIMUS_WIP_PROVIDER : ارائه‌دهنده مجموعه شناسایی حجم کاری که شامل شرایط مجوز برای استفاده برای نشانه‌های امضا شده توسط سرویس تأییدکننده گواهی است.
• $PRIMUS_SERVICEACCOUNT : حساب سرویسی که $PRIMUS_WORKLOAD_IDENTITY_POOL برای دسترسی به منابع محافظت شده استفاده می‌کند. در این مرحله اجازه مشاهده داده های مشتری که در سطل $PRIMUS_INPUT_STORAGE_BUCKET ذخیره شده است را دارد.
• $PRIMUS_ENC_KEY : کلید KMS که برای رمزگذاری داده های ذخیره شده در $PRIMUS_INPUT_STORAGE_BUCKET استفاده می شود.

منابع جدید برای این کد لبه:

• $PRIMUS_COSIGN_REPOSITORY : رجیستری مصنوع برای ذخیره امضاهای تصویر حجم کاری.
• $PRIMUS_SIGNING_KEY : کلید KMS که برای امضای تصویر حجم کاری توسط حسابرس/همکاران داده (مثلاً در این مورد بانک primus) استفاده می‌شود.

موارد زیر را در پروژه Secundus پیکربندی کنید:

• $SECUNDUS_ARTIFACT_REGISTRY : رجیستری مصنوع که در آن تصویر بارانداز بار کاری فشار داده می شود.
• $WORKLOAD_IMAGE_NAME : نام تصویر داکر حجم کاری.
• $WORKLOAD_IMAGE_TAG : برچسب تصویر بارانداز بار کار.
• $WORKLOAD_SERVICEACCOUNT : حساب سرویسی که اجازه دسترسی به VM محرمانه را دارد که حجم کار را اجرا می کند.
• $SECUNDUS_RESULT_BUCKET : سطلی که نتایج حجم کار را ذخیره می کند.

سایر منابع:

• primus_customer_list.csv حاوی داده های مشتری است. ما این داده ها را در $PRIMUS_INPUT_STORAGE_BUCKET آپلود می کنیم و یک بار کاری ایجاد می کنیم که این داده ها را پرس و جو می کند.

گردش کار موجود

هنگامی که حجم کاری را در فضای محرمانه اجرا می کنید، با استفاده از منابع پیکربندی شده، فرآیند زیر انجام می شود:

1. حجم کاری یک رمز دسترسی عمومی Google برای $PRIMUS_SERVICEACCOUNT از WIP درخواست می کند. این توکن خدمات تأیید صحت را با حجم کار و ادعاهای محیطی ارائه می دهد.
2. اگر ادعاهای اندازه‌گیری حجم کاری در نشانه خدمات تأییدکننده تأیید با شرایط ویژگی در WIP مطابقت داشته باشد، رمز دسترسی را برای $PRIMUS_SERVICEACCOUNT.
3. حجم کار از رمز دسترسی به حساب سرویس مرتبط با $PRIMUS_SERVICEACCOUNT برای دسترسی به داده های مشتری در سطل $PRIMUS_INPUT_STORAGE_BUCKET استفاده می کند.
4. حجم کار عملیاتی را روی آن داده انجام می دهد.
5. حجم کار از حساب سرویس $WORKLOAD_SERVICEACCOUNT برای نوشتن نتایج آن عملیات در سطل $SECUNDUS_RESULT_STORAGE_BUCKET استفاده می کند.

گردش کار جدید با پشتیبانی کانتینر امضا شده

پشتیبانی کانتینر امضا شده، همانطور که در زیر مشخص شده است، در جریان کار موجود یکپارچه خواهد شد. هنگامی که حجم کار را در فضای محرمانه با پشتیبانی از تصویر ظرف امضا شده اجرا می کنید، با استفاده از منابع پیکربندی شده، فرآیند زیر انجام می شود:

1. Confidential Space هرگونه امضای محفظه مربوط به تصویر بار کاری جاری را کشف می‌کند و آن‌ها را به تأییدکننده گواهی ارسال می‌کند. تصدیق کننده تصدیق، امضا را تأیید می کند و هر گونه امضای معتبری را در ادعاهای گواهی درج می کند.
2. حجم کاری یک رمز دسترسی عمومی Google برای $PRIMUS_SERVICEACCOUNT از WIP درخواست می کند. این توکن خدمات تأیید صحت را با حجم کار و ادعاهای محیطی ارائه می دهد.
3. اگر ادعای امضای کانتینر در نشانه خدمات تأیید صحت با شرایط مشخصه در WIP مطابقت داشته باشد، رمز دسترسی برای $PRIMUS_SERVICEACCOUNT را برمی‌گرداند .
4. حجم کار از رمز دسترسی به حساب سرویس مرتبط با $PRIMUS_SERVICEACCOUNT برای دسترسی به داده های مشتری در سطل $PRIMUS_INPUT_STORAGE_BUCKET استفاده می کند.
5. حجم کار عملیاتی را روی آن داده انجام می دهد.
6. حجم کار از $WORKLOAD_SERVICEACCOUNT برای نوشتن نتایج آن عملیات در سطل $SECUNDUS_RESULT_STORAGE_BUCKET استفاده می کند.

2. راه اندازی منابع ابری

به عنوان بخشی از راه اندازی فضای محرمانه، ابتدا منابع ابری مورد نیاز را تحت پروژه های GCP بانک Primus و Secundus ایجاد خواهید کرد. اینها منابع جدید این کد لبه هستند:

در پروژه پریموس:

• کلید امضای KMS برای امضای بارهای کاری Secundus، پس از ممیزی کد استفاده می شود.
• مخزن رجیستری مصنوع برای ذخیره امضاهای Cosign.

هیچ منبع جدیدی در پروژه سکوندوس وجود ندارد. پس از راه‌اندازی این منابع، یک حساب سرویس برای حجم کاری با نقش‌ها و مجوزهای لازم ایجاد خواهید کرد. سپس یک تصویر حجم کار ایجاد می کنید و حسابرس، بانک Primus، تصویر حجم کار را امضا می کند. سپس حجم کار توسط همکاران داده مجاز می شود (بانک Primus در این کد لبه) و اپراتور حجم کاری (در این مورد بانک سکوندوس) حجم کار را اجرا می کند.

به عنوان بخشی از راه اندازی فضای محرمانه، شما منابع ابری مورد نیاز را در پروژه های Primus و Secundus GCP ایجاد خواهید کرد.

قبل از شروع

• این مخزن را با استفاده از دستور زیر کلون کنید تا اسکریپت های مورد نیازی که به عنوان بخشی از این کد لبه استفاده می شود را دریافت کنید.

$ git clone https://github.com/GoogleCloudPlatform/confidential-space

• مطمئن شوید که پروژه های مورد نیاز را مطابق شکل زیر تنظیم کرده اید.

$ export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
$ export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>

• با استفاده از این دستور، متغیرها را برای نام منابع ذکر شده در بالا تنظیم کنید. می توانید با استفاده از این متغیرها نام منابع را لغو کنید (به عنوان مثال export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' )
• اسکریپت زیر را اجرا کنید تا نام متغیرهای باقیمانده را بر اساس شناسه پروژه خود برای نام منابع تنظیم کنید.

$ source config_env.sh

• نصب cosign زیر دستورالعمل ها از اینجا .

منابع بانک Primus را تنظیم کنید

به عنوان بخشی از این مرحله، منابع ابری مورد نیاز را برای بانک Primus تنظیم می کنید. اسکریپت زیر را برای تنظیم منابع بانک Primus اجرا کنید. به عنوان بخشی از این مراحل، منابع ذکر شده در زیر ایجاد خواهد شد:

• سطل ذخیره سازی ابری ( $PRIMUS_INPUT_STORAGE_BUCKET ) برای ذخیره فایل رمزگذاری شده اطلاعات مشتری بانک Primus.
• کلید رمزگذاری ( $PRIMUS_ENC_KEY ) و کلید ( $PRIMUS_ENC_KEYRING ) در KMS برای رمزگذاری فایل داده بانک Primus.
• مجموعه هویت بار کاری ( $PRIMUS_WORKLOAD_IDENTITY_POOL ) برای اعتبارسنجی ادعاها بر اساس شرایط ویژگی‌هایی که تحت ارائه‌دهنده آن پیکربندی شده‌اند.
• حساب سرویس ( $PRIMUS_SERVICEACCOUNT ) متصل به مجموعه هویت بار کاری ذکر شده در بالا ( $PRIMUS_WORKLOAD_IDENTITY_POOL ) با دسترسی IAM زیر:
• roles/cloudkms.cryptoKeyDecrypter برای رمزگشایی داده ها با استفاده از کلید KMS.
• objectViewer برای خواندن داده ها از سطل ذخیره سازی ابری.
• roles/iam.workloadIdentityUser برای اتصال این حساب سرویس به مخزن هویت بار کاری.

$ ./setup_primus_bank_resources.sh

منابع بانک سکوندوس را تنظیم کنید

به عنوان بخشی از این مرحله، منابع ابری مورد نیاز را برای بانک سکوندوس تنظیم خواهید کرد. اسکریپت زیر را برای تنظیم منابع بانک سکوندوس اجرا کنید. به عنوان بخشی از این مراحل منابع ذکر شده در زیر ایجاد خواهد شد:

• سطل ذخیره سازی ابری ( $SECUNDUS_RESULT_STORAGE_BUCKET ) برای ذخیره نتیجه اجرای حجم کاری توسط بانک سکوندوس.

$ ./setup_secundus_bank_resources.sh

3. بار کاری را ایجاد و امضا کنید

حساب سرویس حجم کاری ایجاد کنید

اکنون، یک حساب کاربری برای حجم کاری با نقش ها و مجوزهای مورد نیاز ایجاد خواهید کرد. اسکریپت زیر را برای ایجاد یک حساب خدمات بار کاری در پروژه بانک سکوندوس اجرا کنید. این حساب سرویس توسط VM که حجم کار را اجرا می کند استفاده می شود.

• این حساب سرویس حجم کاری ( $WORKLOAD_SERVICEACCOUNT ) نقش های زیر را خواهد داشت:
• confidentialcomputing.workloadUser برای دریافت نشانه گواهی
• logging.logWriter برای نوشتن گزارش در Cloud Logging.
• objectViewer برای خواندن داده ها از سطل ذخیره سازی ابری $PRIMUS_INPUT_STORAGE_BUCKET .
• objectAdmin برای نوشتن نتیجه بار کاری در سطل ذخیره سازی ابری $SECUNDUS_RESULT_STORAGE_BUCKET .

$ ./create_workload_serviceaccount.sh

حجم کار ایجاد کنید

به عنوان بخشی از این مرحله، یک تصویر Docker حجم کاری ایجاد می کنید. حجم کاری مورد استفاده در این Codelab یک برنامه Go ساده مبتنی بر CLI است که مشتریان (از داده‌های مشتریان بانک Primus) را از یک مکان جغرافیایی ارائه‌شده در آرگومان شمارش می‌کند. اسکریپت زیر را اجرا کنید تا یک بار کاری ایجاد کنید که در آن مراحل زیر در حال انجام است:

• ایجاد رجیستری مصنوع ( $SECUNDUS_ARTIFACT_REGISTRY ) متعلق به بانک Secundus.
• کد حجم کار را با نام منابع مورد نیاز به روز کنید. در اینجا کد حجم کاری مورد استفاده برای این کد لبه وجود دارد.
• باینری Go را بسازید و Dockerfile را برای ساختن یک تصویر داکر از کد بار کاری ایجاد کنید. در اینجا Dockerfile مورد استفاده برای این Codelab است.
• تصویر Docker را در رجیستری مصنوع ( $SECUNDUS_ARTIFACT_REGISTRY ) متعلق به بانک سکوندوس بسازید و منتشر کنید.
• به $WORKLOAD_SERVICEACCOUNT اجازه خواندن برای $SECUNDUS_ARTIFACT_REGISTRY اعطا کنید. این برای محفظه بار کاری لازم است تا تصویر داکر بار کاری را از رجیستری مصنوع بیرون بکشد.

$ ./create_workload.sh

بار کاری را علامت بزنید

ما از Cosign برای امضای تصویر حجم کار استفاده خواهیم کرد. Cosign به طور پیش فرض امضاها را در همان مخزن تصویری که امضا می کند ذخیره می کند. برای تعیین مخزن دیگری برای امضاها، می توانید متغیر محیطی COSIGN_REPOSITORY را تنظیم کنید.

در اینجا ما از Artifact Registry به عنوان مثال استفاده خواهیم کرد. همچنین می توانید سایر رجیستری های مبتنی بر OCI مانند Docker Hub، AWS CodeArtifact را بر اساس اولویت خود انتخاب کنید.

توجه: این مرحله برای موارد استفاده که امضاکننده مجوز نوشتن در مخزن حجم کاری ندارد، به شدت توصیه می شود.

1. یک مخزن docker Registry Artifact ایجاد کنید.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=us

2. یک کلید و کلید زیر KMS برای امضای تصویر حجم کاری ایجاد کنید.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=global

$ gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256
  --location=us

3. برای رجیستری مصنوع، یک نام کامل تصویر مانند $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME انتظار می‌رود. می توانید هر تصویر ظرف را برای ذخیره امضا در مخزن آپلود کنید.

$ export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo

توجه: ممکن است رجیستری های مختلف فرمت های متفاوتی را برای "مخزن" انتظار داشته باشند.

• یک رجیستری GCR فرمت هایی مانند زیر را انتظار دارد:

$ export COSIGN_REPOSITORY=gcr.io/primus-signatures

• یک رجیستری مصنوع انتظار یک نام کامل تصویر مانند $LOCATION-docker.pkg.dev/$PROJECT/$REPOSITORY/$STORAGE_IMAGE را دارد، نه فقط یک مخزن. به عنوان مثال،

$ export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo

فقط تعیین مخزن مانند us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY} در رجیستری مصنوع کار نخواهد کرد.

4. نقش Viewer را در مخزن $PRIMUS_COSIGN_REPOSITORY به حساب سرویس $WORKLOAD_SERVICEACCOUNT اعطا کنید. این اجازه می دهد تا Confidential Space هر گونه امضای تصویر ظرف بارگذاری شده در $PRIMUS_COSIGN_REPOSITORY را کشف کند.

$ gcloud artifacts repositories add-iam-policy-binding ${PRIMUS_COSIGN_REPOSITORY} \
--project=${PRIMUS_PROJECT_ID} --role='roles/viewer' --location=us \
--member="serviceAccount:${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com"

Cosign یک ابزار قدرتمند با ویژگی های امضای متعدد است. برای مورد استفاده ما، ما فقط به Cosign نیاز داریم که با یک جفت کلید امضا کند. امضای بدون کلید Cosign برای این ویژگی تصویر ظرف امضا شده پشتیبانی نمی‌شود.

هنگام امضا کردن با یک جفت کلید، دو گزینه وجود دارد:

1. با یک جفت کلید محلی تولید شده توسط Cosign امضا کنید.
2. با یک جفت کلید ذخیره شده در جای دیگر (مثلاً در KMS) امضا کنید.

توجه: فضای محرمانه با پشتیبانی از تصویر ظرف امضا شده فقط از علامت Cosign با کلیدهای RSA و ECDSA پشتیبانی می‌کند.

1. اگر یک جفت کلید در Cosign ندارید، ایجاد کنید. برای جزئیات بیشتر به امضا با کلیدهای خود مدیریت مراجعه کنید.

// Set Application Default Credentials.
$ gcloud auth application-default login 

// Generate keys using a KMS provider.
$ cosign generate-key-pair --kms <provider>://<key>

// Generate keys using Cosign.
$ cosign generate-key-pair

در قسمت بالا، <provider>://<key> را با gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

• <provider> : به راه حل KMS که استفاده می کنید اشاره دارد
• <key> : به مسیر کلید در KMS اشاره دارد

2. کلید عمومی را برای تأیید بازیابی کنید.

// For KMS providers.
$ cosign public-key --key <some provider>://<some key> > pub.pem

// For local key pair signing.
$ cosign public-key --key cosign.key > pub.pem

3. حجم کار را با استفاده از Cosign امضا کنید. رمزگذاری base64 بدون صفحه را روی کلید عمومی انجام دهید

$ PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
$ PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')

توجه: ما از طرح بدون لایه RFC4648 برای رمزگذاری کلید عمومی PEM استفاده می کنیم، زیرا Cosign اجازه هیچ علامت "=" اضافی را در حاشیه نویسی بار نمی دهد.

4. حجم کار را با استفاده از Cosign با کلید عمومی صادر شده و الگوریتم‌های امضای پیوست امضا کنید.

$ IMAGE_REFERENCE=us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/$SECUNDUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG

// Sign with KMS support.
$ cosign sign --key <some provider>://<some key> $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

// Sign with a local key pair.
$ cosign sign --key cosign.key $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

• --key [لازم است] مشخص می کند که از کدام کلید امضا استفاده شود. هنگام مراجعه به کلیدی که توسط ارائه‌دهنده KMS مدیریت می‌شود، لطفاً فرمت URI خاص را از پشتیبانی Sigstore KMS دنبال کنید. هنگامی که به یک کلید تولید شده توسط Cosign اشاره می کنید، به جای آن از cosign.key استفاده کنید.
• $IMAGE_REFERENCE [لازم است] مشخص می کند که کدام تصویر ظرف را امضا کند. قالب IMAGE_REFERENCE را می توان با تگ یا خلاصه تصویر شناسایی کرد. برای مثال: us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container:latest or us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container [IMAGE-digest]
• -a [لازم است] حاشیه نویسی متصل به محموله امضا را مشخص می کند. برای تصاویر کانتینر امضا شده با فضای محرمانه، کلید عمومی و الگوریتم‌های امضا لازم است به محموله امضاء متصل شوند.

هشدار: dev.cosignproject.cosign/pub و dev.cosignproject.cosign/sigalg را تغییر ندهید زیرا Confidential Space فقط این نام‌های کلیدی را می‌پذیرد.

• dev.cosignproject.cosign/sigalg فقط سه مقدار را می پذیرد:
• RSASSA_PSS_SHA256: الگوریتم RSASSA با padding PSS با خلاصه SHA256.
• RSASSA_PKCS1V15_SHA256: الگوریتم RSASSA با پوشش PKCS#1 v1.5 با خلاصه SHA256.
• ECDSA_P256_SHA256: ECDSA روی منحنی P-256 با هضم SHA256. این همچنین الگوریتم امضای پیش‌فرض برای جفت‌های کلید تولید شده توسط Cosign است.

توجه: لطفاً هنگام استفاده از Cosign برای امضا، الگوریتم امضای مربوطه را انتخاب کنید. همچنین برای کلیدهای RSA، طول آنها باید حداقل 2048 بیت باشد.

5. امضاها را در مخزن docker آپلود کنید

علامت Cosign به طور خودکار امضاها را در COSIGN_REPOSITORY.

4. مجوز و اجرای Workload

مجوز بار کاری

به‌عنوان بخشی از این مرحله، ما ارائه‌دهنده هویت حجم کاری را در زیر مجموعه شناسایی حجم کاری ( $PRIMUS_WORKLOAD_IDENTITY_POOL ) راه‌اندازی می‌کنیم. شرایط مشخصه ای برای هویت بار کاری پیکربندی شده است که در زیر نشان داده شده است. یکی از شرایط این است که اثر انگشت امضای تصویر حجم کار را در مقابل امضای اثر انگشت کلید عمومی اعتبار سنجی کنید. با این شرط مشخصه، هنگامی که Secundus Bank یک تصویر بار کاری جدید منتشر می کند، Primus Bank کد حجم کار را بررسی می کند و بدون نیاز به به روز رسانی خط مشی WIP با خلاصه تصویر، تصویر بار کاری جدید را امضا می کند.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ PUBLIC_KEY_FINGERPRINT=$(openssl pkey -pubin -in pub.pem -outform DER | openssl sha256 | cut -d' ' -f2)

$ gcloud iam workload-identity-pools providers create-oidc ${PRIMUS_WIP_PROVIDER} \
   --location="global" \
   --workload-identity-pool="${PRIMUS_WORKLOAD_IDENTITY_POOL}" \
   --issuer-uri="https://confidentialcomputing.googleapis.com/" \
   --allowed-audiences="https://sts.googleapis.com" \
   --attribute-mapping="google.subject='assertion.sub'" \
   --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' &&
  'STABLE' in assertion.submods.confidential_space.support_attributes
     && '${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com' in
     assertion.google_service_accounts
     && ['ECDSA_P256_SHA256:${PUBLIC_KEY_FINGERPRINT}']
       .exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig,sig.signature_algorithm+':'+sig.key_id))"

حجم کار را اجرا کنید

به عنوان بخشی از این مرحله، حجم کار را روی Confidential VM اجرا خواهیم کرد. آرگومان های TEE مورد نیاز با استفاده از پرچم ابرداده منتقل می شوند. آرگومان‌های محفظه حجم کاری با استفاده از بخش « tee-cmd » پرچم ارسال می‌شوند. حجم کار برای انتشار نتیجه در $SECUNDUS_RESULT_STORAGE_BUCKET کدگذاری شده است.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gcloud compute instances create signed-container-vm \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform --zone=us-west1-b \
 --image-project=confidential-space-images \
 --image-family=confidential-space \ --service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/${SECUNDUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]"~tee-signed-image-repos=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo"

مشاهده نتایج

در پروژه سکوندوس، نتایج حجم کار را مشاهده کنید.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

نتیجه باید 3 باشد، زیرا تعداد افراد سیاتل در فایل primus_customer_list.csv فهرست شده است!

5. پاکسازی کنید

در اینجا اسکریپتی است که می تواند برای پاکسازی منابعی که به عنوان بخشی از این کد لبه ایجاد کرده ایم استفاده شود. به عنوان بخشی از این پاکسازی، منابع زیر حذف خواهند شد:

• سطل ذخیره‌سازی ورودی بانک Primus ( $PRIMUS_INPUT_STORAGE_BUCKET ).
• حساب سرویس بانک Primus ( $PRIMUS_SERVICEACCOUNT ).
• رجیستری مصنوع بانک Primus که دارای امضای تصویر است ( $PRIMUS_COSIGN_REPOSITORY ).
• مجموعه هویت بار کاری بانک Primus ( $PRIMUS_WORKLOAD_IDENTITY_POOL ).
• حساب خدمات بار کاری بانک Secundus ( $WORKLOAD_SERVICEACCOUNT ).
• نمونه محاسبه حجم کار.
• سطل ذخیره سازی نتایج Secundus Bank ( $SECUNDUS_RESULT_STORAGE_BUCKET $).
• ثبت مصنوعات بانک سکوندوس ( $SECUNDUS_ARTIFACT_REGISTRY ).

// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

اگر کاوش را تمام کرده اید، لطفاً پروژه خود را حذف کنید.

• به کنسول Cloud Platform بروید
• پروژه‌ای را که می‌خواهید تعطیل کنید انتخاب کنید، سپس روی «حذف» در بالا کلیک کنید: با این کار، پروژه برای حذف برنامه‌ریزی می‌شود.

تبریک میگم

تبریک می‌گوییم، شما با موفقیت برنامه کد را تکمیل کردید!

شما یاد گرفتید که چگونه از ویژگی تصویر ظرف امضا شده برای بهبود قابلیت استفاده از فضای محرمانه استفاده کنید.

بعدش چی؟

برخی از این کدهای مشابه را بررسی کنید...

• داده های مشترک ایمن در حال استفاده با فضای محرمانه
• نحوه معامله دارایی های دیجیتال با محاسبات چند طرفه و فضاهای محرمانه
• داده های محرمانه را با فضاهای محرمانه تجزیه و تحلیل کنید

در ادامه مطلب

• احساس انزوا می کنید؟ محاسبات محرمانه برای نجات
• محاسبات محرمانه در GCP
• فضای محرمانه: آینده همکاری برای حفظ حریم خصوصی
• چگونه گوگل و اینتل محاسبات محرمانه را ایمن تر می کنند
• حریم خصوصی در مقابل پیشرفت - ارتقای امنیت با محاسبات محرمانه Google Cloud