Bantu tingkatkan halaman ini
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Amankan beban kerja dengan sertifikat Kubernetes
Kubernetes Certificates API mengotomatiskan penyediaan kredenal X.509.CertificateSigningRequest
(CSR) untuk meminta penandatangan yang dilambangkan menandatangani sertifikat. Permintaan Anda disetujui atau ditolak sebelum ditandatangani. Kubernetes mendukung penandatangan bawaan dan penandatangan khusus dengan perilaku yang terdefinisi dengan baik. Dengan cara ini, klien dapat memprediksi apa yang terjadi pada mereka CSRs. Untuk mempelajari selengkapnya tentang penandatanganan sertifikat, lihat permintaan penandatanganan
Salah satu penandatangan bawaan adalahkubernetes.io/legacy-unknown
. v1beta1
API sumber daya CSR menghormati penandatangan yang tidak dikenal lama ini. Namun, v1
API CSR yang stabil tidak memungkinkan signerName
untuk disetel kekubernetes.io/legacy-unknown
.
Jika ingin menggunakan Amazon EKS CA untuk membuat sertifikat di klaster, Anda harus menggunakan penandatangan khusus. Untuk menggunakan versi CSR v1
API dan menghasilkan sertifikat baru, Anda harus memigrasikan manifes dan klien API yang ada. Sertifikat yang ada yang dibuat dengan v1beta1
API yang ada valid dan berfungsi hingga sertifikat kedaluwarsa. Ini termasuk yang berikut:
-
Distribusi kepercayaan: Tidak ada. Tidak ada kepercayaan atau distribusi standar untuk penandatangan ini di klaster Kubernetes.
-
Subjek yang diizinkan: Apa saja
-
Ekstensi x509 yang diizinkan: Menghormati subjectAltName dan ekstensi penggunaan kunci dan membuang ekstensi lainnya
-
Penggunaan kunci yang diizinkan: Tidak boleh menyertakan penggunaan di luar ["encipherment kunci”, “tanda tangan digital”, “autentikasi server"]
catatan
Penandatanganan sertifikat klien tidak didukung.
-
Kedaluwarsa/masa pakai sertifikat: 1 tahun (default dan maksimum)
-
CA bit diizinkan/tidak diizinkan: Tidak diizinkan
Contoh pembuatan CSR dengan SignerName
Langkah-langkah ini menunjukkan cara menghasilkan sertifikat penyajian untuk myserver.default.svc
menggunakan signerName: beta.eks.amazonaws.com/app-serving
nama DNS. Gunakan ini sebagai panduan untuk lingkungan Anda sendiri.
-
Jalankan
openssl genrsa -out myserver.key 2048
perintah untuk menghasilkan kunci pribadi RSA.openssl genrsa -out myserver.key 2048
-
Jalankan perintah berikut untuk menghasilkan permintaan sertifikat.
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
-
Hasilkan
base64
nilai untuk permintaan CSR dan simpan dalam variabel untuk digunakan di langkah selanjutnya.base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ")
-
Jalankan perintah berikut untuk membuat file bernama
mycsr.yaml
. Dalam contoh berikut,beta.eks.amazonaws.com/app-serving
adalahsignerName
.cat >mycsr.yaml <<EOF apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: myserver spec: request: $base_64 signerName: beta.eks.amazonaws.com/app-serving usages: - digital signature - key encipherment - server auth EOF
-
Kirim CSR.
kubectl apply -f mycsr.yaml
-
Menyetujui sertifikat penyajian.
kubectl certificate approve myserver
-
Verifikasi bahwa sertifikat telah dikeluarkan.
kubectl get csr myserver
Contoh output adalah sebagai berikut.
NAME AGE SIGNERNAME REQUESTOR CONDITION myserver 3m20s beta.eks.amazonaws.com/app-serving kubernetes-admin Approved,Issued
-
Ekspor sertifikat yang dikeluarkan.
kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt