Menggunakan certificate authority cluster kustom

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.

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

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.

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

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

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

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