Halaman ini diterjemahkan oleh Cloud Translation API.

Menyiapkan Identity Service GKE dengan LDAP

Dokumen ini ditujukan bagi administrator cluster atau operator aplikasi yang menyiapkan Identity Service GKE di cluster mereka. Panduan ini menjelaskan cara menyiapkan Layanan Identitas GKE di cluster dengan penyedia Lightweight Directory Access Protocol (LDAP) pilihan Anda, termasuk Microsoft Active Directory. Ini mengasumsikan bahwa Anda atau administrator platform Anda telah memiliki detail login untuk penyedia LDAP dengan mengikuti petunjuk di Menyiapkan penyedia LDAP untuk GKE Identity Service. Untuk mengetahui lebih lanjut cara kerja Layanan Identitas GKE dan opsi penyiapan lainnya, lihat ringkasan. Untuk mempelajari cara mengakses cluster menggunakan layanan ini sebagai developer atau pengguna cluster lainnya, lihat Mengakses cluster dengan Layanan Identitas GKE. Identity Service GKE dengan LDAP dapat digunakan dengan deployment Google Distributed Cloud di VMware (cluster pengguna) dan di bare metal saja.

Sebelum memulai

Pastikan Anda telah menginstal alat command line berikut:
- Google Cloud CLI versi terbaru, yang menyertakan 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 menginstal kubectl, lihat panduan penginstalan. Jika Anda menggunakan Cloud Shell sebagai lingkungan shell untuk berinteraksi dengan Google Cloud, alat ini akan diinstal untuk Anda.
Pastikan Anda telah melakukan inisialisasi gcloud CLI untuk digunakan dengan project Anda.

Selama penyiapan ini, Anda mungkin perlu melihat 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 secret akun layanan LDAP

Layanan Identitas GKE memerlukan secret akun layanan untuk mengautentikasi ke server LDAP dan mengambil detail pengguna. Ada dua jenis akun layanan yang diizinkan dalam autentikasi LDAP, autentikasi dasar (menggunakan nama pengguna dan sandi untuk melakukan autentikasi ke server) atau sertifikat klien (menggunakan kunci pribadi klien dan sertifikat klien). Anda atau administrator platform Anda harus memiliki informasi ini tentang penyedia Anda dengan mengikuti Menyiapkan penyedia LDAP untuk Identity Service GKE. Agar informasi login server LDAP tersedia untuk Layanan Identitas GKE, Anda harus membuat resource Kubernetes Secret, dengan detail login dari Menyiapkan penyedia LDAP untuk Layanan Identitas GKE. Contoh berikut menunjukkan cara mengonfigurasi Secret untuk kedua jenis akun layanan. Contoh menunjukkan secret yang diterapkan ke namespace anthos-identity-service.

Berikut adalah contoh konfigurasi Secret autentikasi 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

dengan, 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 yang dienkode base64 PASSWORD adalah sandi yang dienkode base64

Berikut 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 telah Anda pilih untuk Secret ini. Ganti sertifikat TLS dan nilai kunci dengan sertifikat dan nilai kunci yang dienkode yang Anda dapatkan di langkah sebelumnya.

Contoh menunjukkan secret yang diterapkan ke namespace anthos-identity-service, yang merupakan pendekatan yang kami rekomendasikan. Hal ini karena secara default, Identity Service GKE 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 memberikan izin Layanan Identitas GKE guna 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

Identity Service GKE menggunakan jenis resource kustom Kubernetes (CRD) khusus untuk mengonfigurasi cluster Anda yang disebut ClientConfig, dengan kolom untuk informasi tentang penyedia identitas dan parameter yang diperlukan untuk menampilkan informasi pengguna. Konfigurasi ClientConfig Anda juga menyertakan nama secret dan namespace dari Secret yang Anda buat dan terapkan di bagian sebelumnya, sehingga GKE Identity Service dapat melakukan autentikasi ke server LDAP.

Untuk menerapkan konfigurasi ke cluster, edit objek default KRM dari jenis clientconfig di namespace kube-public:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig untuk cluster. Jika ada beberapa konteks dalam kubeconfig, konteks saat ini akan digunakan. Anda mungkin perlu mereset konteks saat ini ke cluster yang benar sebelum menjalankan perintah.

Berikut ini 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	Wajib untuk jenis koneksi LDAP tertentu	Berisi sertifikat Certificate Authority berformat PEM yang dienkode Base64 untuk server LDAP. Ini hanya boleh diberikan 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 menggunakan teks biasa.	string
serviceAccountSecret
nama	ya	Nama Secret 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, nilainya harus `basic`, jika tidak, nilainya harus `tls`. Jika tidak ditentukan, setelan defaultnya adalah `basic`.	string
pengguna
baseDN	ya	Lokasi sub-pohon di direktori LDAP untuk menelusuri entri pengguna.	string
filter	tidak	Filter opsional yang akan diterapkan saat menelusuri pengguna. Hal ini dapat digunakan untuk lebih membatasi akun pengguna yang diizinkan untuk login. Jika tidak ditentukan, setelan defaultnya adalah `(objectClass=User)`.	string
identifierAttribute	tidak	Menentukan atribut mana yang akan digunakan sebagai identitas pengguna setelah diautentikasi. Kolom ini berbeda dengan kolom loginAttribute untuk mengizinkan pengguna login dengan nama pengguna, tetapi kemudian ID sebenarnya adalah alamat email atau Nama yang Dibedakan (DN) lengkap. Misalnya, menetapkan loginAttribute ke `sAMAccountName` dan identifierAttribute ke `userPrincipalName` akan memungkinkan pengguna login sebagai `bsmith`, tetapi kebijakan RBAC yang sebenarnya untuk pengguna akan ditulis sebagai `bsmith@example.com`. Sebaiknya gunakan `userPrincipalName` karena akan unik untuk setiap pengguna. Jika tidak ditentukan, setelan defaultnya adalah `userPrincipalName`.	string
loginAttribute	tidak	Nama atribut yang cocok dengan nama pengguna input. Ini digunakan untuk menemukan pengguna di database LDAP, misalnya `(<LoginAttribute>=<username>)` dan digabungkan dengan kolom filter opsional. Nilai defaultnya adalah `userPrincipalName`.	string
group (Kolom opsional)
baseDN	ya	Lokasi sub-pohon di direktori LDAP untuk menelusuri entri grup.	string
filter	tidak	Filter opsional yang akan digunakan saat menelusuri grup tempat pengguna bergabung. Ini dapat digunakan untuk mencocokkan secara eksplisit hanya grup tertentu untuk mengurangi jumlah grup yang ditampilkan untuk setiap pengguna. Nilai defaultnya adalah `(objectClass=Group)`.	string
identifierAttribute	tidak	Nama identitas setiap grup yang mencakup pengguna. Misalnya, jika ditetapkan ke `distinguishedName`, RBAC dan ekspektasi grup lainnya harus ditulis sebagai DN lengkap. Jika tidak ditentukan, setelan defaultnya adalah `distinguishedName`.	string

Apa langkah selanjutnya?

Setelah konfigurasi diterapkan, lanjutkan untuk menyiapkan akses pengguna ke cluster dengan Identity Service GKE.