aws privateca issuer
v1.4.0
AWS Private CA เป็นบริการของ AWS ที่สามารถติดตั้งและจัดการ CA ส่วนตัว รวมถึงออกใบรับรองส่วนตัวได้
cert-manager เป็นส่วนเสริมของ Kubernetes เพื่อทำให้การจัดการและการออกใบรับรอง TLS เป็นแบบอัตโนมัติจากแหล่งที่ออกใบรับรองต่างๆ โดยจะตรวจสอบให้แน่ใจว่าใบรับรองถูกต้อง มีการอัปเดตเป็นระยะ และพยายามต่ออายุใบรับรองในเวลาที่เหมาะสมก่อนหมดอายุ
โปรเจ็กต์นี้ทำหน้าที่เป็นส่วนเสริม (ดู https://cert-manager.io/docs/configuration/external/) ให้กับ cert-manager ที่ลงนามคำขอใบรับรองโดยใช้ AWS Private CA
ติดตั้ง cert-manager ก่อน (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 รองรับ 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>"
}
]
}
ตัวดำเนินการนี้มีทรัพยากรแบบกำหนดเองสองรายการที่คุณสามารถใช้ได้
ตัวอย่างสามารถพบได้ในตัวอย่างและไดเร็กทอรีตัวอย่าง
นี่คือผู้ออกเนมสเปซปกติที่สามารถใช้เป็นข้อมูลอ้างอิงใน CR ใบรับรองของคุณได้
CR นี้เหมือนกับ AWSPCAIssuer ข้อแตกต่างเพียงอย่างเดียวคือไม่มีเนมสเปซและสามารถอ้างอิงได้จากทุกที่
ไม่สามารถใช้คำอธิบายประกอบ cert-manager.io/cluster-issuer เพื่อชี้ไปที่ AWSPCAClusterIssuer ให้ใช้ cert-manager.io/issuer: โปรดดูปัญหานี้สำหรับข้อมูลเพิ่มเติม
ผู้ออก AWSPCA จะรอให้ CertificateRequests มีการกำหนดเงื่อนไขที่ได้รับอนุมัติก่อนลงนาม หากใช้ cert-manager เวอร์ชันเก่า (ก่อน v1.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 Certificate Authority(PCA) รองรับการผสานรวมและกรณีการใช้งานต่อไปนี้:
การผสานรวมกับ cert-manager 1.4+ และเวอร์ชัน Kubernetes ที่เกี่ยวข้อง
วิธีการรับรองความถูกต้อง:
คุณสมบัติ AWS Private CA:
รหัสสำหรับการแปลสามารถพบได้ที่นี่
ขึ้นอยู่กับประเภทการใช้งานที่ตั้งค่าไว้ในใบรับรอง Cert-Manager จะใช้เทมเพลต AWS PCA ที่แตกต่างกัน ตารางนี้แสดงวิธีการแปล UseTypes เป็นเทมเพลตที่จะใช้เมื่อส่งคำขอ IssueCertificate:
| ประเภทการใช้งาน Cert-Manager | เทมเพลต AWS PCA ARN |
|---|---|
| การลงนามโค้ด | acm-pca:::แม่แบบ/CodeSigningCertificate/V1 |
| ClientAuth | acm-pca:::แม่แบบ/EndEntityClientAuthCertificate/V1 |
| เซิร์ฟเวอร์รับรองความถูกต้อง | acm-pca:::แม่แบบ/EndEntityServerAuthCertificate/V1 |
| OCPSการลงนาม | acm-pca:::แม่แบบ/OCSPSigningCertificate/V1 |
| ClientAuth, ServerAuth | acm-pca:::แม่แบบ/EndEntityCertificate/V1 |
| ทุกสิ่งทุกอย่างอื่น | acm-pca:::แม่แบบ/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 ต่อไปนี้: make cluster && make install-eks-webhook && make e2etest
make cluster ให้ทำงาน make cluster จะสร้างคลัสเตอร์ชนิดบนเครื่องของคุณที่ติดตั้ง Cert-Manager รวมถึงปลั๊กอิน aws-pca-issuer (โดยใช้ HEAD ของสาขาปัจจุบัน)
ก่อนที่จะรัน make cluster เราจะต้องทำสิ่งต่อไปนี้:
- มีเครื่องมือต่อไปนี้ในเครื่องของคุณ:
- (ไม่บังคับ) คุณจะต้องมีผู้ใช้ AWS IAM เพื่อทดสอบการรับรองความถูกต้องผ่านความลับ K8 คุณสามารถให้ผู้ใช้ที่มีอยู่แล้วเข้าร่วมการทดสอบได้ผ่าน export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> ผู้ใช้ IAM นี้ควรมีนโยบายแนบมาด้วยซึ่งตามด้วยนโยบายที่แสดงอยู่ในการกำหนดค่า ผู้ใช้รายนี้จะถูกใช้เพื่อทดสอบการรับรองความถูกต้องในปลั๊กอินผ่านความลับ K8
- S3 Bucket ที่ปิดการใช้งาน BPA ใน us-east-1 หลังจากสร้างที่เก็บข้อมูลแล้ว ให้เรียกใช้ export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- คุณจะต้องโหลดข้อมูลรับรอง AWS ลงในเทอร์มินัลของคุณ ซึ่งผ่าน CLI อนุญาตให้ดำเนินการต่อไปนี้น้อยที่สุดผ่านนโยบาย IAM:
acm-pca:* : เพื่อให้สามารถสร้างและลบ CA ส่วนตัวผ่าน API ที่เหมาะสมสำหรับการทดสอบ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 ที่เพิ่งสร้างขึ้น นโยบายอินไลน์สำหรับบทบาทนี้สามารถดึงมาจากการกำหนดค่าได้ ยกเว้นว่าคุณไม่สามารถกำหนดขอบเขตให้กับ CA ใดโดยเฉพาะได้ เนื่องจากนโยบายเหล่านี้จะถูกสร้างขึ้นในระหว่างการทดสอบการทำงาน บทบาทนี้จะใช้เพื่อทดสอบการตรวจสอบสิทธิ์ในปลั๊กอินผ่าน 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 จะติดตั้ง webhook ในคลัสเตอร์ประเภทนั้นที่จะเปิดใช้งานการใช้ IRSA
- make e2etest จะทำการทดสอบแบบ end-to-end กับคลัสเตอร์ชนิดที่สร้างผ่าน make cluster
- หลังจากที่คุณอัปเดตโค้ดคอนโทรลเลอร์ในเครื่องแล้ว วิธีง่ายๆ ในการปรับใช้โค้ดคอนโทรลเลอร์ใหม่อีกครั้งและรันการทดสอบแบบ end-to-end อีกครั้งคือการรัน:: make upgrade-local && make e2etest
การให้ IRSA ทำงานกับ Kind ได้รับแรงบันดาลใจอย่างมากจากบล็อกต่อไปนี้: https://reece.tech/posts/oidc-k8s-to-aws/
หากคุณต้องการทดสอบว่าผู้ออกบัญชีข้ามบัญชีใช้งานได้ คุณจะต้อง:
- บัญชี AWS แยกกันที่มีบทบาทที่เชื่อถือผู้เรียกที่เริ่มการทดสอบแบบ end-to-end ผ่าน CLI บทบาทนี้จะต้องมีนโยบายที่มีสิทธิ์ดังต่อไปนี้
acm-pca:* : เพื่อให้การทดสอบสามารถสร้าง Private 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 Controller ใหม่นั้นทำงานได้ วิธีรันการทดสอบ: 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 จะต้องเข้ารหัส base64
หาก CertificateRequest ที่สร้างขึ้นไม่แสดงเหตุการณ์ใด ๆ เลย เป็นไปได้มากว่าคุณกำลังใช้ตัวจัดการใบรับรองเวอร์ชันเก่าซึ่งไม่รองรับการตรวจสอบการอนุมัติ ปิดใช้งานการตรวจสอบการอนุมัติในการใช้งานของผู้ออก
หากต้องการความช่วยเหลือ โปรดพิจารณาสถานที่ต่อไปนี้ (ตามลำดับ):
เรายินดีรับการสนับสนุนจากชุมชนและดึงคำขอ
ดูคู่มือการสนับสนุนของเราสำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการรายงานปัญหา ตั้งค่าสภาพแวดล้อมการพัฒนา และส่งรหัส
เราปฏิบัติตามหลักจรรยาบรรณของ Amazon Open Source
