Menggunakan otoritas sertifikat cluster kustom

Certificate authority (CA) cluster menerbitkan dan menandatangani sertifikat untuk mengaktifkan autentikasi dan enkripsi yang aman antara komponen cluster. Secara default, di Google Distributed Cloud, Cluster API membuat CA cluster saat Anda membuat cluster baru. Dokumen ini menjelaskan cara menggunakan otoritas sertifikat Anda sendiri dengan Google Distributed Cloud. Dengan menggunakan CA cluster kustom, Anda akan memiliki kontrol yang lebih besar atas penerbitan dan pengelolaan sertifikat cluster. Anda juga dapat mengontrol kepercayaan, parameter algoritma enkripsi, kedalaman sertifikat subordinat, dan tujuannya.

Untuk menggunakan CA kustom, Anda harus menyediakan CA root, yang terdiri dari file sertifikat CA dan file kunci pribadinya yang sesuai. Anda memberikan pasangan file kunci dan sertifikat CA untuk setiap CA cluster yang diperlukan berikut:

• CA etcd: sertifikat untuk sertifikat CA etcd mengamankan komunikasi dari server Kubernetes API ke replika etcd dan juga komunikasi antara replika etcd.

• CA cluster: sertifikat untuk CA cluster mengamankan komunikasi antara server Kubernetes API dan semua klien Kubernetes API internal. Klien mencakup kubelet, pengelola pengontrol, dan penjadwal.

• CA proxy depan: sertifikat untuk CA proxy depan mengamankan komunikasi dengan API gabungan.

Anda dapat memberikan pasangan kunci-sertifikat unik untuk setiap CA atau menggunakan kembali pasangan kunci-sertifikat untuk lebih dari satu CA.

Anda menerapkan pasangan kunci sertifikat selama pembuatan cluster (khusus metode bmctl) dan rotasi CA. Fitur CA Cluster Kustom berfungsi dengan semua jenis cluster: admin, pengguna, hybrid, dan mandiri.

Catatan: Saat membuat cluster pengguna dengan bmctl, Anda biasanya menghapus bagian kredensial dari file konfigurasi cluster. Untuk menentukan CA cluster kustom saat Anda membuat cluster pengguna, tentukan hanya jalur kunci pribadi dan sertifikat CA cluster kustom di bagian kredensial.

Prasyarat

Anda bertanggung jawab untuk menyiapkan CA root Anda sendiri sesuai dengan aturan berikut:

• CA kustom adalah CA root, yang masing-masing terdiri dari file sertifikat yang ditandatangani sendiri dan file kunci pribadi.

• Untuk sertifikat Anda, sebaiknya gunakan format Distinguished Encoding Rules (DER) (lihat rekomendasi X.690 untuk aturan encoding ASN.1). File sertifikat Anda harus berisi data berenkode base64 yang diawali dengan ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑ dan diikuti dengan ‑‑‑‑END CERTIFICATE‑‑‑‑‑.

• Untuk kunci pribadi, sebaiknya gunakan format Public-Key Cryptography Standards (PKCS) #1. File kunci Anda harus berisi data berenkode base64 yang diawali dengan ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ dan diikuti dengan ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

• Untuk meminimalkan potensi gangguan cluster, CA kustom tidak boleh habis masa berlakunya lebih cepat dari lima tahun. Sebaiknya pilih periode habis masa berlaku yang lebih lama, seperti 10 hingga 30 tahun.

• Pastikan file sertifikat dan kunci ada di workstation admin tempat Anda menjalankan perintah bmctl.

• Pengguna yang menjalankan perintah bmctl harus memiliki akses ke direktori tempat Anda menyimpan file. Sebaiknya Anda menempatkan file di direktori yang sudah ada dan digunakan untuk sertifikat dan kunci. Misalnya, Anda dapat menyimpan file di ~/baremetal/bmctl-workspace/.sa-keys bersama dengan kunci akun layanan Anda.

• Pengguna yang menjalankan perintah bmctl harus memiliki akses baca ke file.

Menggunakan CA kustom selama pembuatan cluster

Saat membuat cluster dengan bmctl, Anda harus memperbarui file konfigurasi cluster terlebih dahulu untuk menjelaskan fitur dan setelan cluster. Untuk menggunakan fitur CA Cluster Kustom selama pembuatan cluster, Anda memiliki dua opsi untuk menentukan CA cluster kustom di file konfigurasi cluster:

• Tentukan jalur untuk file sertifikat CA dan file kunci pribadi
• Tentukan jalur untuk file kunci pribadi saja

Jika Anda hanya menentukan kunci pribadi, bmctl akan mencari file sertifikat CA yang sesuai di direktori yang sama. File sertifikat harus memiliki nama yang sama dengan file kunci pribadi yang sesuai dan ekstensi file .crt. Misalnya, jika jalur kunci pribadi adalah /custom-ca/cluster_ca.key, maka bmctl mengharapkan jalur sertifikat menjadi /custom-ca/cluster_ca.crt.

Dalam kedua kasus tersebut, jalur ditentukan di bagian kredensial file konfigurasi seperti yang ditunjukkan dalam contoh berikut.

Contoh 1: Menentukan jalur sertifikat dan kunci

Kutipan berikut dari file konfigurasi cluster menunjukkan cara menentukan jalur ke file sertifikat dan kunci untuk setiap CA cluster. Dalam contoh ini, file kunci dan sertifikat CA berada di direktori yang sama dengan file kunci JSON akun layanan.

Catatan: Untuk cluster pengguna, hapus akun layanan dan jalur kunci SSH dari bagian kredensial.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Contoh 2: Hanya menentukan jalur kunci pribadi

Cuplikan berikut dari file konfigurasi cluster menunjukkan cara menentukan jalur ke file kunci saja. Dalam contoh ini, file kunci pribadi CA berada di direktori yang sama dengan file kunci JSON akun layanan. File sertifikat CA yang sesuai juga harus ada di direktori /.sa-keys. File sertifikat memiliki nama file yang sama dengan file kunci, tetapi dengan ekstensi .crt. Jadi, file sertifikat CA etcd memiliki nama etcd_ca.crt.

Catatan: Untuk cluster pengguna, hapus akun layanan dan jalur kunci SSH dari bagian kredensial.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Contoh 3: Menggunakan kembali satu pasangan file sertifikat dan kunci CA

Cuplikan berikut dari file konfigurasi cluster menunjukkan cara menentukan jalur ke file kunci saja. Dalam contoh ini, satu pasangan kunci sertifikat digunakan untuk semua CA cluster. File kunci pribadi dan sertifikat CA berada di direktori /custom-ca. Dengan mengikuti konvensi penamaan, nama file sertifikat CA adalah custom_ca.crt.

Catatan: Untuk cluster pengguna, hapus akun layanan dan jalur kunci SSH dari bagian kredensial.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

Menggunakan CA kustom selama rotasi CA

Saat merotasi CA, Anda dapat menentukan jalur untuk file kunci pribadi dan sertifikat CA cluster kustom. Opsi yang Anda miliki serupa dengan opsi untuk menentukan CA cluster kustom selama pembuatan cluster. Saat menjalankan perintah bmctl update credentials certificate-authorities rotate, Anda memiliki opsi berikut:

• Tentukan jalur untuk file sertifikat CA kustom dan file kunci pribadi.
• Tentukan jalur untuk file kunci pribadi CA kustom saja. File sertifikat CA yang sesuai harus berada di direktori yang sama, memiliki nama yang sama dengan file kunci, dan memiliki ekstensi file .crt.
• Gunakan kembali pasangan kunci-sertifikat CA dengan menentukan jalur sertifikat dan kunci yang sama untuk lebih dari satu CA cluster.
• Hilangkan argumen untuk jalur CA kustom. Jika Anda tidak menentukan jalur CA kustom saat Anda mengganti CA, Google Distributed Cloud akan membuat dan menggunakan CA cluster standar.

Contoh 1: Menentukan jalur sertifikat CA dan kunci pribadi

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Ganti kode berikut:

• CLUSTER_NAME: nama cluster yang ingin Anda ganti CA-nya.
• ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. Untuk cluster yang dikelola sendiri, file ini adalah file kubeconfig cluster.
• CLUSTER_CA_CERT_PATH: jalur file sertifikat CA cluster.
• CLUSTER_CA_KEY_PATH: jalur file kunci pribadi CA cluster.
• ETCD_CA_CERT_PATH: jalur file sertifikat CA etcd.
• ETCD_CA_KEY_PATH: jalur file kunci pribadi CA etcd.
• FRONT_PROXY_CA_CERT_PATH: jalur file sertifikat front-proxy.
• FRONT_PROXY_CA_KEY_PATH: jalur file kunci pribadi front-proxy.

Contoh 2: Hanya menentukan jalur kunci pribadi

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

Ganti kode berikut:

• CLUSTER_NAME: nama cluster yang ingin Anda ganti CA-nya.
• ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. Untuk cluster yang dikelola sendiri, file ini adalah file kubeconfig cluster.
• CLUSTER_CA_KEY_PATH: jalur file kunci pribadi CA cluster.
• ETCD_CA_KEY_PATH: jalur file kunci pribadi CA etcd.
• FRONT_PROXY_CA_KEY_PATH: jalur file kunci pribadi front-proxy.

CA Menengah

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Cluster versi 1.29 mendukung penggunaan CA perantara sebagai kemampuan Pratinjau. Kemampuan ini tidak berada pada tahap peluncuran yang sama untuk semua versi produk yang didukung:

• 1.29: Pratinjau
• 1.28: Tidak tersedia
• 1.16: Tidak tersedia

Mirip dengan persyaratan CA root untuk CA kustom, untuk menggunakan CA perantara, Anda harus menyiapkan tiga set CA. Setiap CA terdiri dari file sertifikat CA dan file kunci pribadinya yang sesuai. Anda memberikan pasangan file kunci dan sertifikat CA untuk setiap CA cluster yang diperlukan berikut:

• CA etcd
• CA cluster
• CA proxy depan

Seperti halnya CA root, Anda dapat memberikan pasangan kunci sertifikat yang unik untuk setiap CA atau menggunakan kembali pasangan kunci sertifikat untuk lebih dari satu CA dengan menentukan jalur file yang sama dalam konfigurasi CA.

Saat Anda menggunakan CA perantara, file sertifikat CA harus berisi seluruh rantai sertifikat, yang mencakup sertifikat dari CA perantara hingga CA root. Sertifikat dicantumkan dalam urutan terbalik dari cara sertifikat tersebut ditandatangani, dengan sertifikat CA perantara terakhir di bagian atas dan sertifikat CA root di bagian bawah.

Dalam contoh berikut (dimulai dengan CA root di bagian bawah), urutannya menunjukkan hal berikut:

• CA Root menandatangani sertifikat CA Perantara-A
• CA Perantara-A menandatangani sertifikat CA Perantara-B
• Rantai ini berlanjut hingga sertifikat CA Intermediate-Y terakhir, yang ditandatangani oleh CA Intermediate-X

-----BEGIN CERTIFICATE-----
<Intermediate-Y CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-X CA CERT CONTENT>
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
<Intermediate-B CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Intermediate-A CA CERT CONTENT>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<ROOT CA CERT CONTENT>
-----END CERTIFICATE----- 

Untuk melanjutkan contoh ini, kunci pribadi yang terkait dengan sertifikat CA Intermediate-Y harus diteruskan bersama dengan rantai sertifikat CA dengan cara yang sama seperti pada CA kustom.

-----BEGIN RSA PRIVATE KEY-----
<Intermediate-Y PRIVATE KEY CONTENT>
-----END RSA PRIVATE KEY-----

Untuk memeriksa apakah cluster menggunakan CA perantara, periksa jumlah sertifikat di secret CA cluster:

kubectl get secret CLUSTER_NAME-ca \
    --kubeconfig ADMIN_KUBECONFIG
    -n cluster-CLUSTER_NAME \
    -o jsonpath='{.data.tls\.crt}' | base64 --decode | grep "BEGIN CERTIFICATE" | wc -l