Amankan beban kerja dengan sertifikat Kubernetes - Amazon EKS
Contoh pembuatan CSR dengan SignerNamePertimbangan penandatanganan sertifikat sebelum meningkatkan klaster Anda ke Kubernetes 1.24

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. API ini memiliki antarmuka baris perintah untuk klien API Kubernetes untuk meminta dan memperoleh sertifikat X.509 dari Certificate Authority (CA). Anda dapat menggunakan sumber daya 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. 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 versi Kubernetes1.22, v1beta1 CSR API digantikan oleh CSR API. v1 API ini tidak mendukung signerName dari “legacy-unknown.” Jika Anda ingin menggunakan Amazon EKS CA untuk membuat sertifikat di kluster Anda, 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 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.

  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 "
")

  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. Kirimkan 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 Kubernetes 1.24

Di Kubernetes 1.23 dan sebelumnya, sertifikat kubelet penyajian dengan IP yang tidak dapat diverifikasi dan Nama Alternatif Subjek DNS () SANs secara otomatis diterbitkan dengan tidak dapat diverifikasi. SANs SANs Ini 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 tanda tangan kubernetes.io/kubelet-serving itu Approved tetapi tidak Issued untuk sebuah node, maka Anda perlu menyetujui permintaan tersebut.

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

    kubectl certificate approve csr-7znmf

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