aws privateca issuer
v1.4.0
AWS Private CA هي إحدى خدمات AWS التي يمكنها إعداد المراجع المصدقة الخاصة وإدارتها، بالإضافة إلى إصدار شهادات خاصة.
cert-manager عبارة عن وظيفة إضافية من Kubernetes لأتمتة إدارة وإصدار شهادات TLS من مصادر الإصدار المختلفة. وسيتأكد من صلاحية الشهادات وتحديثها دوريًا ومحاولة تجديد الشهادات في وقت مناسب قبل انتهاء صلاحيتها.
يعمل هذا المشروع كملحق (راجع https://cert-manager.io/docs/configuration/external/) لمدير الشهادات الذي يقوم بتسجيل طلبات الشهادات باستخدام AWS Private CA.
قم بتثبيت مدير الشهادة أولاً (https://cert-manager.io/docs/installation/kubernetes/).
ثم قم بتثبيت AWS PCA Issuer باستخدام Helm:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-nameيمكنك التحقق من تكوين المخطط في ملف القيم الافتراضية.
يدعم AWS PCA Issuer ARM بدءًا من الإصدار 1.3.0
تحتفظ جهة إصدار AWS PCA باختبار ECR يحتوي على إصدارات تتوافق مع كل التزام على الفرع الرئيسي. يمكن الوصول إلى هذه الصور عن طريق تعيين مستودع الصورة على public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test وعلامة الصورة على latest . ويرد أدناه مثال على كيفية القيام بذلك:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name
--set image.repository=public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test
--set image.tag=latest اعتبارًا من الآن، الإعدادات الوحيدة القابلة للتكوين هي الوصول إلى AWS. لذا يمكنك استخدام AWS_REGION أو AWS_ACCESS_KEY_ID أو AWS_SECRET_ACCESS_KEY .
وبدلاً من ذلك، يمكنك توفير أسرار عشوائية لمفاتيح الوصول والمفاتيح السرية باستخدام حقلي accessKeyIDSelector و secretAccessKeySelector في بيان المجموعة و/أو بيانات المُصدر.
يمكن أيضًا تكوين الوصول إلى AWS باستخدام دور مثيل EC2 أو [أدوار IAM لحسابات الخدمة] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html ).
قد تبدو سياسة الحد الأدنى لاستخدام المُصدر مع السلطة كما يلي:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "awspcaissuer",
"Action": [
"acm-pca:DescribeCertificateAuthority",
"acm-pca:GetCertificate",
"acm-pca:IssueCertificate"
],
"Effect": "Allow",
"Resource": "arn:aws:acm-pca:<region>:<account_id>:certificate-authority/<resource_id>"
}
]
}
يوفر عامل التشغيل هذا مصدرين مخصصين يمكنك استخدامهما.
يمكن العثور على الأمثلة في أدلة الأمثلة والعينات.
هذا مُصدر عادي لمساحة الاسم ويمكن استخدامه كمرجع في سجلات الشهادات الخاصة بك.
هذا السجل التجاري مطابق لـ AWSPCAIssuer. والفرق الوحيد هو أنها ليست ذات مساحة اسمية ويمكن الرجوع إليها من أي مكان.
لا يمكن استخدام التعليق التوضيحي cert-manager.io/cluster-issuer للإشارة إلى AWSPCAClusterIssuer . بدلاً من ذلك، استخدم cert-manager.io/issuer: . يرجى الاطلاع على هذه المشكلة لمزيد من المعلومات.
سينتظر مصدر AWSPCA حتى يتم تعيين شرط معتمد لطلبات الشهادات قبل التوقيع. إذا كنت تستخدم إصدارًا قديمًا من cert-manager (ما قبل الإصدار 1.3)، فيمكنك تعطيل هذا التحقق عن طريق توفير علامة سطر الأوامر -disable-approved-check إلى جهة النشر.
سيقوم مصدر AWSPCA بتخفيض معدل الطلبات إلى خادم kubernetes API إلى 5 استعلامات في الثانية بشكل افتراضي. وهذا ليس ضروريًا للإصدارات الأحدث من Kubernetes التي طبقت أولوية واجهة برمجة التطبيقات (API Priority and Fairness). إذا كنت تستخدم إصدارًا أحدث من Kubernetes، فيمكنك تعطيل تقييد المعدل من جانب العميل عن طريق توفير علامة سطر الأوامر -disable-client-side-rate-limiting إلى عملية نشر المُصدر.
يرجى ملاحظة أنه إذا كنت تستخدم KIAM للمصادقة، فقد تم اختبار هذا البرنامج الإضافي على KIAM v4.0. تم أيضًا اختبار ودعم IRSA.
هناك طريقة مصادقة AWS مخصصة قمنا بترميزها في المكون الإضافي الخاص بنا والتي تسمح للمستخدم بتحديد سر Kubernetes من خلال AWS Creds التي تم تمريرها، مثال هنا. يقوم المستخدم بتطبيق هذا الملف باستخدام بياناته ثم يشير إلى السر في CRD الخاص بمصدره عند تشغيل المكون الإضافي، المثال هنا.
يدعم المكون الإضافي لإصدار AWS Private Certified Authority(PCA) عمليات التكامل وحالات الاستخدام التالية:
التكامل مع cert-manager 1.4+ وإصدارات Kubernetes المقابلة.
طرق المصادقة:
ميزات CA الخاصة في AWS:
يمكن العثور على رمز الترجمة هنا.
اعتمادًا على أنواع الاستخدام التي تم تعيينها في شهادة Cert-Manager، سيتم استخدام قوالب AWS PCA مختلفة. يوضح هذا الجدول كيفية ترجمة UseTypes إلى القالب الذي سيتم استخدامه عند تقديم طلب IssueCertificate:
| أنواع استخدام مدير الشهادات | قالب AWS PCA ARN |
|---|---|
| توقيع الكود | acm-pca:::template/CodeSigningCertificate/V1 |
| ClientAuth | acm-pca:::قالب/EndEntityClientAuthCertificate/V1 |
| مصادقة الخادم | acm-pca:::قالب/EndEntityServerAuthCertificate/V1 |
| OCSPSigning | acm-pca:::template/OCSPSigningCertificate/V1 |
| ClientAuth، ServerAuth | acm-pca:::template/EndEntityCertificate/V1 |
| كل شيء آخر | acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
سيؤدي تشغيل make test إلى تشغيل اختبار الوحدة المكتوب
إذا واجهت مشكلة مثل
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
يمكن إصلاح ذلك باستخدام أ
brew install gcc@5
ملاحظة: سيؤدي إجراء هذه الاختبارات إلى فرض رسوم على حساب AWS الخاص بك .
سيؤدي تشغيل make e2etest إلى أخذ عناصر التعليمات البرمجية الحالية وتحويلها إلى صورة Docker التي سيتم تشغيلها على مجموعة نوع والتأكد من أن الإصدار الحالي من التعليمات البرمجية لا يزال يعمل مع مسارات العمل المدعومة
تتمثل أسهل طريقة لتشغيل الاختبار في استخدام أهداف الإنشاء التالية: make cluster && make install-eks-webhook && make e2etest
make cluster للتشغيل ستؤدي make cluster إلى إنشاء مجموعة لطيفة على جهازك تم تثبيت Cert-Manager بالإضافة إلى المكون الإضافي aws-pca-issuer (باستخدام رأس الفرع الحالي)
قبل تشغيل make cluster سنحتاج إلى القيام بما يلي:
- امتلك الأدوات التالية على جهازك:
- (اختياري) ستحتاج إلى مستخدم AWS IAM لاختبار المصادقة عبر أسرار K8. يمكنك تقديم مستخدم موجود بالفعل في الاختبار عبر export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> . يجب أن يكون لدى مستخدم IAM هذا سياسة مرفقة به تتبع السياسة المدرجة في التكوين. سيتم استخدام هذا المستخدم لاختبار المصادقة في البرنامج المساعد عبر أسرار K8.
- دلو S3 مع تعطيل BPA في شرق الولايات المتحدة 1. بعد إنشاء الحاوية، قم export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- ستحتاج إلى تحميل بيانات اعتماد AWS في جهازك الطرفي، والتي تسمح، من خلال واجهة سطر الأوامر (CLI)، بالحد الأدنى من الإجراءات التالية عبر سياسة IAM:
acm-pca:* : هذا حتى يتم إنشاء وحذف CA الخاصة عبر واجهات برمجة التطبيقات المناسبة للاختبارiam:CreatePolicy و iam:CreateUser و iam:AttachUserPolicyiam:CreateAccessKey و iam:DeleteAccessKey : يتيح لنا ذلك إنشاء وحذف مفاتيح الوصول لاستخدامها في التحقق من أن المصادقة عبر أسرار K8 فعالة. إذا تم تعيين المستخدم عبر $PLUGIN_USER_NAME_OVERRIDEs3:PutObject و s3::PutObjectAcl يمكن تحديد نطاقهما وصولاً إلى مجموعة s3 التي قمت بإنشائها أعلاه - موفر AWS IAM OIDC. قبل إنشاء موفر OIDC، قم بتعيين قيمة مؤقتة لـ $OIDC_IAM_ROLE ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role وتشغيل make cluster && make install-eks-webhook && make kind-cluster-delete ). يجب القيام بذلك وإلا فقد ترى خطأً يشكو من عدم وجود ملف .well-known/openid-configuration. يساعد تشغيل هذه الأوامر في تشغيل مجموعة S3 بحيث يمكن إنشاء موفر OIDC. قم بتعيين عنوان URL الخاص بموفر OIDC ليكون $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster . قم بتعيين الجمهور ليكون sts.amazonaws.com .
- دور IAM له علاقة ثقة مع موفر IAM OIDC الذي تم إنشاؤه للتو. يمكن الحصول على سياسة مضمّنة لهذا الدور من التكوين باستثناء أنه لا يمكنك توسيع نطاقها إلى مرجع مصدق معين حيث سيتم إنشاؤها أثناء التشغيل التجريبي. سيتم استخدام هذا الدور لاختبار المصادقة في البرنامج المساعد عبر IRSA. يجب أن تبدو علاقة الثقة كما يلي:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${OIDC_ARN}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${OIDC_URL}:sub": "system:serviceaccount:aws-privateca-issuer:aws-privateca-issuer-sa"
}
}
}
]
}
بعد إنشاء هذا الدور، قم بتشغيل export OIDC_IAM_ROLE=<IAM role arn you created above>
- make cluster تعيد إنشاء المجموعة مع مجموعة متغيرات البيئة المناسبة
- make install-eks-webhook إلى تثبيت خطاف ويب في تلك المجموعة التي ستمكن من استخدام IRSA
- سيتم إجراء اختبار make e2etest على مجموعة النوع التي تم إنشاؤها عبر make cluster .
- بعد تحديث رمز وحدة التحكم محليًا، تتمثل إحدى الطرق السهلة لإعادة نشر رمز وحدة التحكم الجديد وإعادة تشغيل الاختبار الشامل في تشغيل:: make upgrade-local && make e2etest
كان الحصول على IRSA للعمل على Kind مستوحى بشكل كبير من المدونة التالية: https://reece.tech/posts/oidc-k8s-to-aws/
إذا كنت تريد أيضًا اختبار عمل جهات إصدار الحسابات المشتركة، فستحتاج إلى ما يلي:
- حساب AWS منفصل له دور يثق في المتصل الذي يبدأ الاختبار الشامل عبر واجهة سطر الأوامر (CLI)، وسيحتاج الدور إلى سياسة بالأذونات التالية
acm-pca:* : هذا حتى يتمكن الاختبار من إنشاء CA خاص هو الحساب الآخرram:GetResourceShareAssociations و ram:CreateResourceShare و ram:DeleteResourceShare : تسمح هذه بإنشاء مرجع مصدق (CA) يمكن مشاركته مع حساب المصدر (المتصل)export PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> . إذا لم تقم بذلك، فسترى رسالة حول تخطي الاختبار عبر الحسابات بسبب عدم تعيين متغير البيئة هذا.من المفترض أن يتم تشغيل هذه الاختبارات تلقائيًا على كل PR قريبًا، ولكن في الوقت الحالي سيكون لكل PR متعاون أساسي للمشروع، ويقوم بإجراء الاختبارات يدويًا لضمان عدم وجود تراجعات في سير العمل المدعوم.
الاختبار واضح ومباشر إلى حد ما، حيث سيأخذ مجموعة من "قوالب جهة الإصدار" (الاسم الأساسي لمصدر aws-pca بالإضافة إلى AWSIssuerSpec) ومجموعة من "قوالب الشهادات" (الاسم الأساسي لنوع الشهادة بالإضافة إلى مواصفات الشهادة). ستقوم الاختبارات بعد ذلك بأخذ كل مواصفات الشهادة وتطبيقها على كل مواصفات جهة الإصدار. سيضمن الاختبار وصول جميع جهات الإصدار المستندة إلى مواصفات جهة الإصدار إلى حالة الاستعداد بالإضافة إلى التأكد من أن كل شهادة تم إصدارها من جهة إصدار تصل إلى حالة الاستعداد. تم التحقق من أن جهات الإصدار ذات الشهادات المختلفة تعمل مع جهات إصدار المجموعة ومساحة الاسم.
بالنسبة للجزء الأكبر، سيؤدي التحديث الشامل إلى تحديث "مواصفات جهة الإصدار" و"مواصفات الشهادة" الموجودة ضمن e2e/e2e_test.go. إذا كان الاختبار بحاجة إلى التحديث بعد ذلك، فسيتم أيضًا تضمين المنطق الأساسي للاختبار في e2e/e2e_test.go. الملفات الأخرى الموجودة في مجلد e2e هي في الأساس أدوات مساعدة لا ينبغي أن تتطلب تحديثًا متكررًا
اختبار للتأكد من أن سير العمل الموضح في المدونة يعمل على إعداد تشفير TLS الشامل على Amazon EKS باستخدام وحدة التحكم AWS Load Balancer الجديدة. لإجراء الاختبار: make cluster && make install-eks-webhook && make blog-test
اختبار يقوم بسحب أحدث إصدار عبر Helm، ويتحقق من تثبيت المكون الإضافي بشكل صحيح، مع الإصدار الصحيح، ثم يتم حذفه بشكل صحيح. لإجراء الاختبار make cluster && make install-eks-webhook && make helm-test
تحقق من السر باستخدام بيانات اعتماد AWS: يجب أن تكون قيم AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY مشفرة بالأساس 64.
إذا لم يعرض طلب الشهادة الذي تم إنشاؤه أي أحداث، فمن المحتمل جدًا أنك تستخدم إصدارًا أقدم من مدير الشهادات الذي لا يدعم التحقق من الموافقة. تعطيل التحقق من الموافقة عند نشر جهة الإصدار.
للمساعدة، يرجى النظر في الأماكن التالية (بالترتيب):
نحن نرحب بمساهمات المجتمع وطلبات السحب.
راجع دليل المساهمة الخاص بنا للحصول على مزيد من المعلومات حول كيفية الإبلاغ عن المشكلات وإعداد بيئة التطوير وإرسال التعليمات البرمجية.
نحن نلتزم بمدونة قواعد السلوك الخاصة بأمازون مفتوحة المصدر.
