Cluster certificate authority (CA) menerbitkan dan menandatangani sertifikat untuk mengaktifkan autentikasi dan enkripsi yang aman di antara komponen cluster. Secara {i>default<i}, di Google Distributed Cloud, Cluster API membuat cluster CA saat Anda membuat cluster baru. Dokumen ini menjelaskan cara menggunakan sertifikat Anda sendiri dengan Google Distributed Cloud. Menggunakan CA cluster kustom akan memberi Anda lebih banyak kontrol atas penerbitan dan pengelolaan sertifikat cluster Anda. Anda juga dapat kontrol kepercayaan, parameter algoritma enkripsi, kedalaman subordinate sertifikat, dan tujuannya.
Untuk menggunakan CA khusus, Anda memberikan CA {i>root<i}, yang terdiri dari file sertifikat CA dan file kunci pribadi yang sesuai. Anda memberikan sertifikat CA dan file kunci untuk setiap CA cluster yang diperlukan berikut:
etcd CA: sertifikat untuk sertifikat CA etcd yang mengamankan komunikasi dari server Kubernetes API ke replika etcd dan juga komunikasi antara replika dll.
cluster CA: sertifikat untuk CA cluster yang mengamankan komunikasi antara server Kubernetes API dan semua klien Kubernetes API internal. Klien termasuk kubelet, pengelola pengontrol, dan penjadwal.
front-proxy CA: sertifikat untuk CA front-proxy mengamankan komunikasi dengan API gabungan.
Anda dapat memberikan pasangan kunci sertifikat unik untuk setiap CA atau Anda dapat menggunakan kembali pasangan kunci sertifikat untuk lebih dari satu CA.
Anda menerapkan pasangan kunci sertifikat selama
pembuatan cluster (khusus metode bmctl
)
dan rotasi CA. CA Cluster Kustom
berfungsi dengan semua jenis cluster: admin, pengguna, hybrid, dan mandiri.
Prasyarat
Anda bertanggung jawab untuk menyiapkan root CA Anda sendiri sesuai dengan hal berikut aturan:
CA kustom adalah CA root, 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 oleh‑‑‑‑END CERTIFICATE‑‑‑‑‑
.Untuk kunci pribadi, sebaiknya Anda menggunakan metode Standar Kriptografi Kunci Publik (PKCS) #1 format font. File kunci Anda harus berisi data berenkode base64 yang didahului oleh
‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑
dan diikuti oleh‑‑‑‑END RSA PRIVATE KEY‑‑‑‑
.Untuk meminimalkan potensi gangguan cluster, masa berlaku CA kustom tidak boleh berakhir lebih cepat dari lima tahun. Sebaiknya gunakan periode habis masa berlaku yang lebih lama, seperti 10 hingga 30 bertahun-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 di tempat Anda menyimpan file. Sebaiknya Anda meletakkan file dalam direktori direktori yang digunakan untuk sertifikat dan kunci. Sebagai contoh, Anda dapat simpan file di~/baremetal/bmctl-workspace/.sa-keys
bersama dengan akun layanan sendiri.Pengguna yang menjalankan perintah
bmctl
harus memiliki akses baca ke file.
Menggunakan CA kustom selama pembuatan cluster
Saat Anda membuat
kelompok
dengan bmctl
, Anda harus terlebih dahulu mengupdate file konfigurasi cluster untuk mendeskripsikan
fitur dan setelan cluster. Untuk menggunakan fitur CA Cluster Kustom selama
pembuatan cluster, Anda memiliki dua opsi untuk menentukan CA cluster kustom
file konfigurasi cluster:
- Menentukan jalur untuk file sertifikat CA dan kunci pribadi file
- Menentukan jalur untuk file kunci pribadi saja
Jika Anda menentukan kunci pribadi saja, bmctl
akan mencari CA yang sesuai
file sertifikat di direktori yang sama. File sertifikat harus memiliki
sebagai file kunci pribadi yang sesuai dan ekstensi file .crt
. Sebagai
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 ditetapkan di bagian kredensial dari file konfigurasi seperti yang ditunjukkan dalam contoh berikut.
Contoh 1: Menentukan sertifikat dan jalur kunci
Cuplikan berikut yang berasal dari file konfigurasi cluster menunjukkan cara menentukan jalur ke sertifikat dan file kunci untuk setiap CA cluster. Di sini misalnya, sertifikat CA dan file kunci berada di direktori yang sama dengan file kunci JSON akun layanan tertentu.
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 yang berasal dari file konfigurasi cluster menunjukkan cara menentukan
ke file kunci saja. Dalam contoh ini, file kunci pribadi CA berada di
direktori yang sama dengan file kunci JSON akun layanan. CA yang sesuai
file sertifikat 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 dst. memiliki nama etcd_ca.crt
.
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 sepasang file kunci dan sertifikat CA
Cuplikan berikut yang berasal dari file konfigurasi cluster menunjukkan cara menentukan
ke file kunci saja. Dalam contoh ini, pasangan kunci sertifikat tunggal digunakan
untuk semua CA cluster. Sertifikat CA dan file kunci
pribadi keduanya berada di
Direktori /custom-ca
. Berdasarkan konvensi penamaan, sertifikat CA
Nama filenya adalah custom_ca.crt
.
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
untuk sertifikat CA cluster kustom dan file kunci pribadi. Opsi
mirip dengan opsi untuk menentukan CA cluster kustom selama
pembuatan cluster. Saat menjalankan perintah bmctl update credentials
certificate-authorities rotate
, Anda memiliki opsi berikut:
- Menentukan jalur untuk file sertifikat CA kustom dan file pribadi file kunci.
- Tentukan jalur untuk file kunci pribadi CA kustom saja. Tujuan
file sertifikat CA yang sesuai harus berada di direktori yang sama, memiliki
sama dengan nama file kunci, dan memiliki ekstensi file
.crt
. - Gunakan kembali pasangan kunci sertifikat CA dengan menentukan sertifikat dan kunci yang sama untuk lebih dari satu CA cluster.
- Hapus argumen untuk jalur CA kustom. Jika Anda tidak menentukan CA kustom saat Anda merotasi CA, Google Distributed Cloud akan membuat dan menggunakan CA cluster standar.
Contoh 1: Menentukan sertifikat CA dan jalur 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 Anda inginkan untuk merotasi CA.
- ADMIN_KUBECONFIG: jalur ke cluster admin {i>kubeconfig<i}. Untuk mengelola sendiri cluster, file ini adalah milik {i>kubeconfig<i}.
- CLUSTER_CA_CERT_PATH: jalur cluster CA sertifikat Google Cloud.
- CLUSTER_CA_KEY_PATH: jalur cluster CA pribadi kunci.
- ETCD_CA_CERT_PATH: jalur sertifikat CA etcd .
- ETCD_CA_KEY_PATH: jalur kunci pribadi CA etcd .
- FRONT_PROXY_CA_CERT_PATH: jalur front-proxy sertifikat Google Cloud.
- FRONT_PROXY_CA_KEY_PATH: jalur front-proxy file kunci pribadi.
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 Anda inginkan untuk merotasi CA.
- ADMIN_KUBECONFIG: jalur ke cluster admin {i>kubeconfig<i}. Untuk mengelola sendiri cluster, file ini adalah milik {i>kubeconfig<i}.
- CLUSTER_CA_KEY_PATH: jalur cluster CA pribadi kunci.
- ETCD_CA_KEY_PATH: jalur kunci pribadi CA etcd .
- FRONT_PROXY_CA_KEY_PATH: jalur front-proxy file kunci pribadi.
CA Menengah
Cluster versi 1.29 mendukung penggunaan CA perantara sebagai Kemampuan Preview. Kemampuan ini tidak berada di 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 {i>root<i} untuk CA khusus, untuk menggunakan CA perantara, harus menyiapkan tiga set CA. Setiap CA terdiri dari file sertifikat CA dan file kunci pribadi yang sesuai. Anda memberikan sertifikat CA dan file kunci untuk setiap CA cluster yang diperlukan berikut:
- dll., CA
- cluster CA
- CA {i>front-proxy<i}
Seperti halnya CA {i>root<i}, Anda dapat memberikan pasangan kunci sertifikat yang unik untuk setiap CA atau Anda dapat menggunakan kembali pasangan kunci sertifikat untuk lebih dari satu CA dengan menetapkan jalur file yang sama di konfigurasi CA.
Bila Anda menggunakan CA perantara, file sertifikat CA harus berisi seluruh rantai sertifikat, yang mencakup sertifikat dari CA perantara hingga CA {i>root<i}. Sertifikat dicantumkan dalam urutan terbalik dari bagaimana sertifikat tersebut ditandatangani, dengan sertifikat CA perantara terakhir di bagian atas dan CA {i>root<i} sertifikat di bagian bawah.
Dalam contoh berikut (dimulai dengan CA {i>root<i} di bagian bawah), urutan menunjukkan hal berikut:
- Root CA menandatangani sertifikat Intermediate-A CA
- Intermediate-A CA menandatangani sertifikat Intermediate-B CA
- Rantai tersebut berlanjut ke sertifikat CA Menengah-Y akhir, yang ditandatangani oleh Intermediate-X CA
-----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 sertifikat CA rantai 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 sertifikat dalam rahasia 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