Menggunakan otoritas sertifikat cluster kustom

Certificate authority (CA) cluster menerbitkan dan menandatangani sertifikat untuk mengaktifkan autentikasi dan enkripsi yang aman di 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. Menggunakan CA cluster kustom memberi Anda 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 root CA, yang terdiri dari file sertifikat CA dan file kunci pribadi yang sesuai. Anda memberikan pasangan file kunci dan sertifikat CA untuk setiap CA cluster yang diperlukan berikut:

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

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

• CA front-proxy: sertifikat untuk CA front-proxy 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, campuran, dan mandiri.

Catatan: Saat membuat cluster pengguna dengan bmctl, Anda biasanya menghapus bagian kredensial dari file konfigurasi cluster. Untuk menentukan CA cluster kustom saat membuat cluster pengguna, tentukan hanya sertifikat CA cluster kustom dan jalur kunci pribadi 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, sebaiknya gunakan format Distinguished Encoding Rules (DER) (lihat rekomendasi X.690 untuk aturan encoding ASN.1). File sertifikat Anda harus berisi data yang dienkode dengan 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 yang dienkode dengan base64 yang diawali dengan ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑ dan diikuti dengan ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑.

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

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

• Pengguna yang menjalankan perintah bmctl harus memiliki akses ke direktori tempat Anda menyimpan file. Sebaiknya tempatkan file di direktori yang 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 mendeskripsikan fitur dan setelan cluster. Untuk menggunakan fitur CA Cluster Kustom selama pembuatan cluster, Anda memiliki dua opsi untuk menentukan CA cluster kustom dalam file konfigurasi cluster:

• Menentukan jalur untuk file sertifikat CA dan file kunci pribadi
• Menentukan jalur hanya untuk file kunci pribadi

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, bmctl akan 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

Cuplikan 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, Anda menghapus 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: Menentukan jalur kunci pribadi saja

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 berada 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, Anda menghapus 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 kunci dan sertifikat 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 sertifikat CA dan kunci pribadi berada di direktori /custom-ca. Mengikuti konvensi penamaan, nama file sertifikat CA adalah custom_ca.crt.

Catatan: Untuk cluster pengguna, Anda menghapus 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 memutar CA, Anda dapat menentukan jalur untuk file kunci pribadi dan sertifikat CA cluster kustom. Opsi yang Anda miliki mirip 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 hanya untuk file kunci pribadi CA kustom. 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 kunci dan sertifikat yang sama untuk lebih dari satu CA cluster.
• Hapus argumen untuk jalur CA kustom. Jika Anda tidak menentukan jalur CA kustom saat memutar 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 CA-nya ingin Anda putar.
• ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. Untuk cluster yang mengelola 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: Menentukan jalur kunci pribadi saja

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 CA-nya ingin Anda putar.
• ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin. Untuk cluster yang mengelola 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 Perantara

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di 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

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

• CA etcd
• CA cluster
• CA front-proxy

Seperti halnya root CA, Anda dapat memberikan pasangan kunci sertifikat unik untuk setiap CA atau Anda dapat 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 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), urutan menunjukkan hal berikut:

• CA Root menandatangani sertifikat CA Perantara-A
• CA Perantara-A menandatangani sertifikat CA Perantara-B
• Rantai berlanjut hingga sertifikat CA Perantara-Y akhir, yang ditandatangani oleh CA Perantara-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 Perantara-Y harus diteruskan bersama dengan rantai sertifikat CA dengan cara yang sama seperti di 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