Menyiapkan GKE Identity Service dengan LDAP
Dokumen ini ditujukan untuk administrator cluster atau operator aplikasi yang menyiapkan GKE Identity Service di cluster mereka. Panduan ini memberitahukan cara menyiapkan GKE Identity Service di cluster Anda dengan penyedia Lightweight Directory Access Protocol (LDAP) pilihan Anda, termasuk Microsoft Active Directory. Hal ini mengasumsikan bahwa Anda atau administrator platform Anda telah mendapatkan detail login untuk penyedia LDAP dengan mengikuti petunjuk dalam Menyiapkan penyedia LDAP untuk GKE Identity Service. Untuk mengetahui lebih lanjut cara kerja GKE Identity Service dan opsi penyiapan lainnya, lihat ringkasan. Untuk mempelajari cara mengakses cluster menggunakan layanan ini sebagai developer atau pengguna cluster lainnya, lihat Mengakses cluster dengan GKE Identity Service. GKE Identity Service dengan LDAP dapat digunakan dengan deployment Google Distributed Cloud di VMware (cluster pengguna) dan on bare metal saja.
Sebelum memulai
- Pastikan Anda telah menginstal alat command line berikut:
- Versi terbaru Google Cloud CLI, yang mencakup
gcloud
, alat command line untuk berinteraksi dengan Google Cloud. Jika Anda perlu menginstal Google Cloud CLI, lihat panduan penginstalan. kubectl
untuk menjalankan perintah terhadap cluster Kubernetes. Jika Anda perlu menginstalkubectl
, lihat panduan penginstalan Jika Anda menggunakan Cloud Shell sebagai lingkungan shell untuk berinteraksi dengan Google Cloud, alat ini akan diinstal untuk Anda.
- Versi terbaru Google Cloud CLI, yang mencakup
- Pastikan Anda telah melakukan inisialisasi gcloud CLI untuk digunakan dengan project Anda.
Selama penyiapan ini, Anda mungkin perlu merujuk ke dokumentasi untuk server LDAP Anda. Panduan administrator berikut menjelaskan konfigurasi untuk beberapa penyedia LDAP populer, termasuk tempat menemukan informasi yang diperlukan untuk login ke server LDAP dan mengonfigurasi cluster:
Mengisi rahasia akun layanan LDAP
GKE Identity Service memerlukan rahasia akun layanan untuk melakukan autentikasi ke server LDAP dan mengambil detail pengguna. Ada dua jenis akun layanan yang diizinkan dalam otentikasi LDAP, auth dasar (menggunakan nama pengguna dan sandi untuk mengotentikasi ke server) atau sertifikat klien (menggunakan kunci pribadi klien dan sertifikat klien). Anda atau administrator platform Anda seharusnya mendapatkan informasi tentang penyedia ini setelah membaca artikel Menyiapkan penyedia LDAP untuk GKE Identity Service.
Agar informasi login server LDAP tersedia untuk GKE Identity Service, Anda perlu membuat resource Kubernetes Secret, dengan detail login dari Menyiapkan penyedia LDAP untuk GKE Identity Service.
Contoh berikut menunjukkan cara mengonfigurasi Secret untuk kedua jenis akun layanan. Contoh ini menunjukkan rahasia yang diterapkan ke namespace anthos-identity-service
.
Ini adalah contoh konfigurasi Secret auth dasar:
apiVersion: v1 kind: Secret metadata: name: SERVICE_ACCOUNT_SECRET_NAME namespace: "anthos-identity-service" type: kubernetes.io/basic-auth # Make sure the type is correct data: username: USERNAME # Use a base64-encoded username password: PASSWORD # Use a base64-encoded password
di mana, SERVICE_ACCOUNT_SECRET_NAME adalah nama yang Anda pilih untuk Secret ini. Ganti nilai nama pengguna dan sandi dengan nama pengguna dan sandi yang Anda dapatkan di langkah sebelumnya. USERNAME adalah nama pengguna berenkode base64 PASSWORD adalah sandi berenkode base64
Ini adalah contoh konfigurasi Secret sertifikat klien:
apiVersion: v1 kind: Secret metadata: name: SERVICE_ACCOUNT_SECRET_NAME namespace: anthos-identity-service type: kubernetes.io/tls # Make sure the type is correct data: # the data is abbreviated in this example tls.crt: | MIIC2DCCAcCgAwIBAgIBATANBgkqh ... tls.key: | MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...
Ganti SERVICE_ACCOUNT_SECRET_NAME dengan nama yang Anda pilih untuk Secret ini. Ganti sertifikat dan nilai kunci TLS dengan sertifikat yang dienkode dan nilai kunci yang Anda dapatkan di langkah sebelumnya.
Contoh ini menunjukkan rahasia yang diterapkan ke namespace anthos-identity-service
, yang merupakan pendekatan yang kami rekomendasikan. Hal ini karena secara default GKE Identity Service memiliki izin untuk membaca Secret di anthos-identity-service
. Jika Anda ingin menggunakan namespace lain, ubah metadata di secret, lalu tambahkan kebijakan RBAC baru untuk memberi GKE Identity Service izin membaca Secret di namespace tersebut, sebagai berikut:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: NAMESPACE name: ais-secret-reader-role rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get","list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ais-secret-reader-role-binding namespace: NAMESPACE roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: ais-secret-reader-role subjects: - kind: ServiceAccount name: default namespace: anthos-identity-service ---
Mengonfigurasi cluster
GKE Identity Service menggunakan Kubernetes khusus
resource kustom
type (CRD) untuk mengonfigurasi cluster Anda
yang disebut ClientConfig
, dengan kolom untuk
informasi tentang penyedia identitas dan parameter yang perlu ditampilkan
informasi pengguna. Konfigurasi ClientConfig
Anda juga mencakup secret
dan namespace dari Secret yang Anda buat dan terapkan dalam
, sehingga GKE Identity Service dapat
melakukan otentikasi ke server LDAP.
Untuk menerapkan konfigurasi ke cluster Anda, edit objek default KRM jenis clientconfig
di namespace kube-public
:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
Ganti USER_CLUSTER_KUBECONFIG
dengan jalur ke
{i>kubeconfig<i} untuk cluster tersebut. Jika ada banyak konteks dalam
{i>kubeconfig<i}, maka konteks saat ini digunakan. Anda mungkin perlu mengatur ulang
konteks ke cluster yang benar sebelum menjalankan perintah.
Berikut ini adalah format untuk konfigurasi ClientConfig
:
apiVersion: authentication.gke.io/v2alpha1 kind: ClientConfig metadata: name: default namespace: kube-public spec: authentication: - name: NAME_STRING ldap: host: HOST_NAME certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA connectionType: CONNECTION_TYPE serviceAccountSecret: name: SERVICE_ACCOUNT_SECRET_NAME namespace: NAMESPACE type: SECRET_FORMAT user: baseDN: BASE_DN filter: FILTER identifierAttribute: IDENTIFIER_ATTRIBUTE loginAttribute: LOGIN_ATTRIBUTE group: baseDN: BASE_DN filter: FILTER identifierAttribute: IDENTIFIER_ATTRIBUTE
Tabel berikut menjelaskan kolom di CRD ClientConfig
:
Kolom | Diperlukan | Deskripsi | Format |
---|---|---|---|
nama | ya | Nama untuk mengidentifikasi konfigurasi LDAP ini | string |
host | ya | Nama host atau alamat IP server LDAP. Port bersifat opsional dan akan ditetapkan secara default ke 389, jika tidak ditentukan. Misalnya ldap.server.example.com atau 10.10.10.10:389 .
|
string |
certificateAuthorityData | Diperlukan untuk jenis koneksi LDAP tertentu | Berisi sertifikat otoritas sertifikat berformat PEM yang dienkode dengan Base64 untuk server LDAP. Kunci ini hanya boleh disediakan untuk koneksi ldaps dan startTLS .
|
string |
connectionType | ya | Jenis koneksi LDAP yang akan digunakan saat terhubung ke server LDAP. Nilai defaultnya adalah startTLS . Mode insecure hanya boleh digunakan untuk pengembangan, karena semua komunikasi dengan server akan berupa teks biasa.
|
string |
serviceAccountSecret | |||
nama | ya | Nama Rahasia Kubernetes yang menyimpan kredensial untuk akun layanan LDAP. | string |
namespace | ya | Namespace Secret Kubernetes yang menyimpan kredensial untuk akun layanan LDAP. | string |
jenis | ya | Menentukan format secret akun layanan untuk mendukung berbagai jenis secret. Jika Anda menentukan basic-auth dalam konfigurasi Secret Anda, nilainya harus basic , atau harus tls . Jika tidak ditentukan, defaultnya adalah basic .
|
string |
pengguna | |||
baseDN | ya | Lokasi subtree di direktori LDAP untuk menelusuri entri pengguna. | string |
filter | tidak | Filter opsional yang akan diterapkan saat menelusuri pengguna. Tindakan ini dapat digunakan untuk lebih membatasi akun pengguna yang diizinkan untuk login. Jika tidak ditentukan, defaultnya adalah (objectClass=User) .
|
string |
identifierAttribute | tidak | Menentukan atribut mana
untuk digunakan sebagai identitas
pengguna setelah mereka diotentikasi.
Ini berbeda dari isian {i>loginAttribute<i} untuk
mengizinkan pengguna untuk {i>login<i} dengan
nama pengguna, tetapi kemudian memiliki
tanda pengenal mereka yang sebenarnya
adalah alamat email atau
{i>Distinguished Name<i} (DN). Misalnya, menyetel loginAttribute
ke sAMAccountName dan IDAttribute ke userPrincipalName
akan mengizinkan pengguna login sebagai bsmith , tetapi sebenarnya
Kebijakan RBAC untuk pengguna akan ditulis sebagai bsmith@example.com .
Sebaiknya gunakan userPrincipalName karena
akan unik untuk setiap pengguna. Jika tidak ditentukan, defaultnya adalah userPrincipalName .
|
string |
loginAttribute | tidak | Nama atribut yang cocok dengan nama pengguna input. Atribut ini digunakan untuk menemukan pengguna di database LDAP, misalnya (<LoginAttribute>=<username>) dan digabungkan dengan kolom filter opsional. Default-nya adalah userPrincipalName .
|
string |
group (Kolom opsional) | |||
baseDN | ya | Lokasi subtree di direktori LDAP untuk menelusuri entri grup. | string |
filter | tidak | Filter opsional yang akan digunakan saat menelusuri grup tempat pengguna berada. Ini dapat digunakan untuk mencocokkan hanya grup tertentu secara eksplisit guna mengurangi jumlah grup yang ditampilkan untuk setiap pengguna. Default-nya adalah (objectClass=Group) .
|
string |
identifierAttribute | tidak | Nama pengidentifikasi setiap grup yang mencakup pengguna. Misalnya, jika ditetapkan ke distinguishedName , RBAC dan ekspektasi grup lainnya harus ditulis sebagai DN lengkap. Jika tidak ditentukan, defaultnya adalah distinguishedName .
|
string |
Apa langkah selanjutnya?
Setelah konfigurasi diterapkan, lanjutkan ke menyiapkan akses pengguna ke cluster dengan GKE Identity Service.