Penandatanganan sertifikat - Amazon EKS
Contoh CSRCSR di Kubernetes 1.24

Bantu tingkatkan halaman ini

Ingin berkontribusi pada panduan pengguna ini? Gulir ke bagian bawah halaman ini dan pilih Edit halaman ini GitHub. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penandatanganan sertifikat

API Kubernetes Sertifikat mengotomatiskan penyediaan kredensi X.509. API ini memiliki antarmuka baris perintah untuk klien Kubernetes API untuk meminta dan memperoleh sertifikat X.509 dari Certificate Authority (CA). Anda dapat menggunakan sumber daya CertificateSigningRequest (CSR) untuk meminta tanda tangan yang dilambangkan menandatangani sertifikat. Permintaan Anda disetujui atau ditolak sebelum ditandatangani. Kubernetesmendukung penandatangan bawaan dan penandatangan khusus dengan perilaku yang terdefinisi dengan baik. Dengan cara ini, klien dapat memprediksi apa yang terjadi pada CSR mereka. Untuk mempelajari lebih lanjut tentang penandatanganan sertifikat, lihat permintaan penandatanganan.

Salah satu penandatangan bawaan adalahkubernetes.io/legacy-unknown. v1beta1API 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.

Versi Amazon EKS 1.21 dan sebelumnya mengizinkan legacy-unknown nilai seperti signerName di v1beta1 CSR API. API ini memungkinkan Amazon EKS Certificate Authority (CA) untuk menghasilkan sertifikat. Namun, dalam Kubernetes versi1.22, v1beta1 CSR API digantikan oleh v1 CSR API. API ini tidak mendukung signerName dari “legacy-unknown.” Jika ingin menggunakan Amazon EKS CA untuk membuat sertifikat di klaster, Anda harus menggunakan penandatangan khusus. Itu diperkenalkan dalam versi Amazon EKS1.22. 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 dalam sebuah Kubernetes cluster.

  • 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.

  1. Jalankan openssl genrsa -out myserver.key 2048 perintah untuk menghasilkan kunci pribadi RSA.

    openssl genrsa -out myserver.key 2048

  2. Jalankan perintah berikut untuk menghasilkan permintaan sertifikat.

    openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"

  3. 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 "\n")

  4. Jalankan perintah berikut untuk membuat file bernamamycsr.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

  5. Kirim CSR.

    kubectl apply -f mycsr.yaml

  6. Menyetujui sertifikat penyajian.

    kubectl certificate approve myserver

  7. 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

  8. Ekspor sertifikat yang dikeluarkan.

    kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt

Pertimbangan penandatanganan sertifikat sebelum meningkatkan klaster Anda ke 1,24 Kubernetes

Di dalam Kubernetes 1.23 dan sebelumnya, sertifikat kubelet penyajian dengan IP yang tidak dapat diverifikasi dan Nama Alternatif Subjek DNS (SAN) secara otomatis dikeluarkan dengan SAN yang tidak dapat diverifikasi. SAN dihilangkan dari sertifikat yang disediakan. Di klaster 1.24 dan yang lebih baru, sertifikat kubelet penyajian tidak dikeluarkan jika SAN tidak dapat diverifikasi. Ini mencegah kubectl exec dan kubectl logs perintah bekerja.

Sebelum memutakhirkan klaster ke1.24, tentukan apakah klaster Anda memiliki permintaan penandatanganan sertifikat (CSR) yang belum disetujui dengan menyelesaikan langkah-langkah berikut:

  1. Jalankan perintah berikut.

    kubectl get csr -A

    Contoh output adalah sebagai berikut.

    NAME        AGE   SIGNERNAME                      REQUESTOR                                                  REQUESTEDDURATION   CONDITION
csr-7znmf   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-42-149.region.compute.internal      <none>              Approved
csr-9xx5q   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-65-38.region.compute.internal      <none>              Approved, Issued

    Jika output yang dikembalikan menunjukkan CSR dengan kubernetes.io/kubelet-servingpenandatangan yang Approved tetapi tidak Issued untuk node, maka Anda harus menyetujui permintaan tersebut.

  2. Menyetujui CSR secara manual. Ganti csr-7znmf dengan nilai Anda sendiri.

    kubectl certificate approve csr-7znmf

Untuk menyetujui CSR secara otomatis di masa mendatang, sebaiknya Anda menulis pengontrol persetujuan yang dapat secara otomatis memvalidasi dan menyetujui CSR yang berisi IP atau DNS SAN yang tidak dapat diverifikasi oleh Amazon EKS.