AWS Private CA adalah layanan AWS yang dapat menyiapkan dan mengelola CA privat, serta menerbitkan sertifikat privat.
cert-manager adalah add-on Kubernetes untuk mengotomatiskan pengelolaan dan penerbitan sertifikat TLS dari berbagai sumber penerbit. Hal ini akan memastikan sertifikat valid, diperbarui secara berkala dan berupaya memperbarui sertifikat pada waktu yang tepat sebelum masa berlakunya habis.
Proyek ini bertindak sebagai tambahan (lihat https://cert-manager.io/docs/configuration/external/) untuk cert-manager yang menandatangani permintaan sertifikat menggunakan AWS Private CA.
Instal cert-manager terlebih dahulu (https://cert-manager.io/docs/installation/kubernetes/).
Kemudian instal Penerbit AWS PCA menggunakan Helm:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name
Anda dapat memeriksa konfigurasi bagan di file nilai default.
Penerbit AWS PCA mendukung ARM mulai dari versi 1.3.0
Penerbit AWS PCA memelihara ECR pengujian yang berisi versi yang sesuai dengan setiap penerapan di cabang utama. Gambar-gambar ini dapat diakses dengan mengatur repo gambar ke public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test
dan tag gambar ke latest
. Contoh bagaimana hal ini dilakukan ditunjukkan di bawah ini:
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
Saat ini, satu-satunya pengaturan yang dapat dikonfigurasi adalah akses ke AWS. Jadi Anda dapat menggunakan AWS_REGION
, AWS_ACCESS_KEY_ID
atau AWS_SECRET_ACCESS_KEY
.
Alternatifnya, Anda dapat memberikan rahasia arbitrer untuk access dan kunci rahasia dengan bidang accessKeyIDSelector
dan secretAccessKeySelector
di manifes clusterissuer dan/atau penerbit.
Akses ke AWS juga dapat dikonfigurasi menggunakan peran instans EC2 atau [IAM Roles for Service Accounts] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html ).
Kebijakan minimal untuk menggunakan penerbit yang berwenang adalah sebagai berikut:
{
"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>"
}
]
}
Operator ini menyediakan dua sumber daya khusus yang dapat Anda gunakan.
Contohnya dapat ditemukan di direktori contoh dan sampel.
Ini adalah penerbit dengan namespace reguler yang dapat digunakan sebagai referensi dalam CR Sertifikat Anda.
CR ini identik dengan Penerbit AWSPCAI. Satu-satunya perbedaan adalah bahwa hal itu tidak diberi spasi nama dan dapat direferensikan dari mana saja.
Anotasi cert-manager.io/cluster-issuer
tidak dapat digunakan untuk menunjuk ke AWSPCAClusterIssuer
. Sebagai gantinya, gunakan cert-manager.io/issuer:
. Silakan lihat masalah ini untuk informasi lebih lanjut.
Penerbit AWSPCA akan menunggu CertificateRequests menetapkan ketentuan yang disetujui sebelum penandatanganan. Jika menggunakan versi cert-manager yang lebih lama (sebelum v1.3), Anda dapat menonaktifkan pemeriksaan ini dengan memberikan tanda baris perintah -disable-approved-check
ke Issuer Deployment.
Penerbit AWSPCA akan membatasi laju permintaan ke server API kubernetes menjadi 5 kueri per detik secara default. Hal ini tidak diperlukan untuk Kubernetes versi baru yang telah mengimplementasikan Prioritas dan Kewajaran API. Jika menggunakan Kubernetes versi terbaru, Anda dapat menonaktifkan pembatasan tarif sisi klien ini dengan memberikan tanda baris perintah -disable-client-side-rate-limiting
ke Issuer Deployment.
Harap dicatat bahwa jika Anda menggunakan KIAM untuk otentikasi, plugin ini telah diuji pada KIAM v4.0. IRSA juga diuji dan didukung.
Ada metode autentikasi AWS khusus yang telah kami kodekan ke dalam plugin kami yang memungkinkan pengguna menentukan rahasia Kubernetes dengan AWS Creds yang diteruskan, misalnya di sini. Pengguna menerapkan file tersebut dengan kredibilitasnya dan kemudian mereferensikan rahasianya di CRD Penerbitnya saat menjalankan plugin, contoh di sini.
Plugin Penerbit AWS Private Certificate Authority (PCA) mendukung integrasi dan kasus penggunaan berikut:
Integrasi dengan cert-manager 1.4+ dan versi Kubernetes yang sesuai.
Metode otentikasi:
Fitur AWS Private CA:
Kode terjemahannya dapat ditemukan di sini.
Bergantung pada UsageTypes yang diatur dalam sertifikat Cert-Manager, templat AWS PCA yang berbeda akan digunakan. Tabel ini menunjukkan bagaimana UsageTypes diterjemahkan ke dalam templat mana yang akan digunakan saat membuat permintaan IssueCertificate:
Jenis Penggunaan Manajer Sertifikat | ARN Templat PCA AWS |
---|---|
Penandatanganan Kode | acm-pca:::template/CodeSigningCertificate/V1 |
KlienAuth | acm-pca:::template/EndEntityClientAuthCertificate/V1 |
ServerAuth | acm-pca:::template/EndEntityServerAuthCertificate/V1 |
Penandatanganan OCPS | acm-pca:::template/OCSPSigningCertificate/V1 |
ClientAuth, ServerAuth | acm-pca:::template/EndEntityCertificate/V1 |
Segalanya Lainnya | acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
Menjalankan make test
akan menjalankan pengujian unit tertulis
Jika Anda mengalami masalah seperti
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
Hal ini dapat diperbaiki dengan a
brew install gcc@5
CATATAN: Menjalankan tes ini akan dikenakan biaya di Akun AWS Anda .
Menjalankan make e2etest
akan mengambil artefak kode saat ini dan mengubahnya menjadi image Docker yang akan berjalan di cluster sejenis dan memastikan bahwa versi kode saat ini masih berfungsi dengan Alur Kerja yang Didukung
Cara termudah untuk menjalankan pengujian adalah dengan menggunakan target make berikut: make cluster && make install-eks-webhook && make e2etest
make cluster
untuk dijalankan make cluster
akan membuat cluster yang baik pada mesin Anda yang telah menginstal Cert-Manager serta plugin aws-pca-issuer (menggunakan HEAD dari cabang saat ini)
Sebelum menjalankan make cluster
kita perlu melakukan hal berikut:
- Miliki alat berikut di mesin Anda:
- (Opsional) Anda memerlukan Pengguna AWS IAM untuk menguji autentikasi melalui rahasia K8. Anda dapat memasukkan pengguna yang sudah ada ke dalam pengujian melalui export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name>
. Pengguna IAM ini harus memiliki kebijakan yang melekat padanya yang mengikuti kebijakan yang tercantum dalam Konfigurasi. Pengguna ini akan digunakan untuk menguji otentikasi di plugin melalui rahasia K8.
- Bucket S3 dengan BPA dinonaktifkan di us-east-1. Setelah membuat keranjang, export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- Anda memerlukan kredensial AWS yang dimuat ke terminal Anda yang, melalui CLI, minimal mengizinkan tindakan berikut melalui kebijakan IAM:
acm-pca:*
: Ini agar Private CA dapat dibuat dan dihapus melalui API yang sesuai untuk pengujianiam:CreatePolicy
, iam:CreateUser
, dan iam:AttachUserPolicy
iam:CreateAccessKey
dan iam:DeleteAccessKey
: Ini memungkinkan kami membuat dan menghapus kunci akses yang akan digunakan untuk memvalidasi bahwa otentikasi melalui rahasia K8 berfungsi. Jika pengguna ditetapkan melalui $PLUGIN_USER_NAME_OVERRIDEs3:PutObject
dan s3::PutObjectAcl
ini dapat dicakup ke bucket s3 yang Anda buat di atas - Penyedia OIDC AWS IAM. Sebelum membuat penyedia OIDC, tetapkan nilai sementara untuk $OIDC_IAM_ROLE ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role
dan jalankan make cluster && make install-eks-webhook && make kind-cluster-delete
). Ini perlu dilakukan jika tidak, Anda mungkin melihat kesalahan yang mengeluhkan tidak adanya file .well-known/openid-configuration. Menjalankan perintah ini membantu mem-bootstrap bucket S3 sehingga penyedia OIDC dapat dibuat. Tetapkan url penyedia penyedia OIDC menjadi $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster
. Tetapkan audiens menjadi sts.amazonaws.com
.
- IAM role yang memiliki hubungan kepercayaan dengan Penyedia IAM OIDC yang baru saja dibuat. Kebijakan inline untuk peran ini dapat diambil dari Konfigurasi kecuali Anda tidak dapat mencakupnya ke CA tertentu karena kebijakan tersebut akan dibuat selama pengujian dijalankan. Peran ini akan digunakan untuk menguji otentikasi di plugin melalui IRSA. Hubungan kepercayaan akan terlihat seperti:
{
"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"
}
}
}
]
}
Setelah membuat peran ini, jalankan export OIDC_IAM_ROLE=<IAM role arn you created above>
- make cluster
membuat ulang cluster dengan semua variabel lingkungan yang sesuai ditetapkan
- make install-eks-webhook
akan menginstal webhook di cluster semacam itu yang memungkinkan penggunaan IRSA
- make e2etest
akan menjalankan pengujian end-to-end terhadap jenis cluster yang dibuat melalui make cluster
.
- Setelah Anda memperbarui kode pengontrol secara lokal, cara mudah untuk menerapkan ulang kode pengontrol baru dan menjalankan kembali pengujian end-to-end adalah dengan menjalankan:: make upgrade-local && make e2etest
Membuat IRSA mengerjakan Kind sangat terinspirasi oleh blog berikut: https://reece.tech/posts/oidc-k8s-to-aws/
Jika Anda juga ingin menguji apakah penerbit lintas akun berfungsi, Anda memerlukan:
- Akun AWS terpisah yang memiliki peran yang memercayai pemanggil yang memulai pengujian end-to-end melalui CLI, peran tersebut memerlukan kebijakan dengan izin berikut
acm-pca:*
: Ini agar pengujian dapat membuat Private CA pada akun lainnyaram:GetResourceShareAssociations
, ram:CreateResourceShare
, dan ram:DeleteResourceShare
: Ini memungkinkan pembuatan CA yang dapat dibagikan dengan akun sumber (pemanggil)export PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above>
. Jika Anda tidak melakukan ini, Anda akan melihat pesan tentang pengujian lintas akun dilewati karena variabel lingkungan ini tidak disetel.Pengujian ini akan segera dijalankan secara otomatis pada setiap PR, namun untuk saat ini setiap PR akan memiliki kolaborator inti untuk proyek tersebut, jalankan pengujian secara manual untuk memastikan tidak ada regresi pada alur kerja yang didukung
Pengujiannya cukup mudah, mereka akan mengambil satu set "templat penerbit" (Nama dasar untuk penerbit aws-pca serta AWSIssuerSpec) dan satu set "templat sertifikat" (Nama dasar untuk jenis sertifikat serta spesifikasi sertifikat). Pengujian kemudian akan mengambil setiap spesifikasi sertifikat dan menerapkannya pada setiap spesifikasi penerbit. Pengujian ini akan memastikan semua penerbit yang dibuat berdasarkan spesifikasi penerbit mencapai status siap serta memastikan bahwa setiap sertifikat yang diterbitkan penerbit mencapai status siap. Penerbit dengan sertifikat berbeda diverifikasi berfungsi untuk penerbit klaster dan namespace.
Umumnya, pembaruan end-to-end berarti memperbarui "spesifikasi penerbit" dan "spesifikasi sertifikat" yang berada dalam e2e/e2e_test.go. Jika pengujian perlu diperbarui lebih dari itu, logika inti pengujian juga tertanam di e2e/e2e_test.go. File lain dalam folder e2e sebagian besar adalah utilitas yang tidak memerlukan pembaruan sering
Uji untuk memastikan bahwa alur kerja yang dijelaskan dalam blog Menyiapkan enkripsi TLS end-to-end di Amazon EKS dengan AWS Load Balancer Controller yang baru berfungsi. Untuk menjalankan pengujian: make cluster && make install-eks-webhook && make blog-test
Tes yang menarik rilis terbaru melalui Helm, memeriksa apakah plugin telah diinstal dengan benar, dengan versi yang benar, kemudian dihapus dengan benar. Untuk menjalankan pengujian make cluster && make install-eks-webhook && make helm-test
Periksa rahasianya dengan kredensial AWS: nilai AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY harus dikodekan base64.
Jika CertificateRequest yang dihasilkan tidak menunjukkan peristiwa apa pun, kemungkinan besar Anda menggunakan manajer sertifikat versi lama yang tidak mendukung pemeriksaan persetujuan. Nonaktifkan pemeriksaan persetujuan pada penerapan penerbit.
Untuk bantuan, silakan pertimbangkan tempat berikut (secara berurutan):
Kami menyambut kontribusi komunitas dan permintaan penarikan.
Lihat panduan kontribusi kami untuk informasi selengkapnya tentang cara melaporkan masalah, menyiapkan lingkungan pengembangan, dan mengirimkan kode.
Kami mematuhi Kode Etik Sumber Terbuka Amazon.